单页面应用

1.传统的网页应用

目前绝大部分的网站都还采用这种形式。单个 HTML 页面作为功能元件，通过刷新，超链接、表单提交等方式，组合排列这些 HTML 页面，来为用户提供服务。

在传统的网页应用中，浏览器更多的是充当一个展示层，路由处理、服务调用、页面跳转流程都由服务端来处理。即 MVC 都放在服务器端，而 V 作为用户界面则通过网络发送到浏览器端，作为 UI 与用户交互。

这样的范式有以下特点：

• 重服务端，由于 MVC 都存在于服务器上，因此这类应用在开发资源和开发的重心都偏向后端，往往是后端工程师来主导整个项目开发；
• 页面频繁刷新，由于浏览器端只是一个展现层，当页面功能有所变化的时，页面就刷新，这会导致资源的浪费，用户需要花费额外的时间等待页面刷新，用户体验不佳。

当然，上面表达的是一种普遍的范式，而 Ajax 则是这个范式的异类。Ajax 的出现使得网页可以局部更新，使得网页上的一部分可以作为一个功能元件来为用户提供服务。这种形式的网页应用已经具备单页应用的雏型，但并不是标准的单页应用。

2.单页应用

单页Web应用（single-page application，简称SPA）是一种特殊的Web应用。

它将所有的活动局限于一个Web页面中，仅在该Web页面初始化时加载相应的HTML、JavaScript 和 CSS。一旦页面加载完成了，SPA不会因为用户的操作而进行页面的重新加载或跳转。而是利用 JavaScript 动态的变换HTML的内（采用的是div切换显示和隐藏），从而实现UI与用户的交互。

由于避免了页面的重新加载，SPA 可以提供较为流畅的用户体验。得益于ajax，我们可以实现无跳转刷新，又多亏了浏览器的histroy机制，我们用hash的变化从而可以实现推动界面变化。

相较于传统网页应用，单页应用将MVC前置到了浏览器端：

• 控制器前置，单页应用将路由处理放在浏览器前端，即在浏览器端直接响应浏览器地址的变化，分发到对应的路由，向用户呈现对应的界面。
• 以小块组件未功能元件，类似于传统网页中的Ajax组件，单页应用以小的组件为功能元件，在路由变化时，不再刷新整个页面，而是组合这些小的组件，替换变化的部分。
• 数据层前置，与Ajax组件一个明显的区别是，单页应用在浏览器端通常有一层实实在在的数据层，而服务端则退化成了完全的数据API。浏览器端的数据层会封装服务端API，供上层的视图层调用。

看上去有点类似于客户端（Android、iOS）开发，交互全都放在客户端，服务端仅仅提供 API。

3.单页应用的好与坏

我们先说说好的地方：

• 无刷新体验，这个应该是最显著的有点，由于路由分发直接在浏览器端完成，页面是不刷新，对用户的响应非常及时，因此提升了用户体验；
• 完全的前端组件化，前端开发不再以页面为单位，更多地采用组件化的思想，代码结构和组织方式更加规范化，便于修改和调整；
• API共享，如果你的服务是多端的（浏览器端、Android、iOS、微信等），单页应用的模式便于你在多个端共用 API，可以显著减少服务端的工作量。容易变化的 UI 部分都已经前置到了多端，只受到业务数据模型影响的 API，更容易稳定下来，便于提供鲁棒的服务；
• 组件共享，在某些对性能体验要求不高的场景，或者产品处于快速试错阶段，借助于一些技术（Hybrid、React Native），可以在多端共享组件，便于产品的快速迭代，节约资源。

单页应用的优点有时候也是缺点：

• 首次加载大量资源，要在一个页面上为用户提供产品的所有功能，在这个页面加载的时候，首先要加载大量的静态资源，这个加载时间相对比较长；
• 较高的前端开发门槛，MVC 前置，对前端工程师的要求提高了，不再是『切切图，画画页面这么简单』；同时工作量也会增加数倍，开发这类应用前端工程师的数量往往多于后端；
• 不利于 SEO，单页页面，数据在前端渲染，就意味着没有 SEO，或者需要使用变通的方案。

4.总结

在笔者看来，单页应用是对原来 Ajax 组件的一种延伸，相较于传统的网页应用，将 MVC 前置到了浏览器端，浏览器就相当于 iOS 系统，单页应用就像是应用，与服务端仅仅通过 API 来沟通。每种技术方案都有利弊，是否要使用单页应用技术，需要通过对产品需求（跨平台、SEO、性能、用户群属性？）、资源（工程师配比，能力？）时间要求等的评估来做出选择。

5.单页面应用进一步思考

开发框架：

为解决大规模单页应用代码逻辑问题，出现了不少MV*（MVC、MVP、MVVM）框架，他们的基本思路都是在JS层创建模块分层和通信机制，为单页面应用开发提供了必需的模版、路径解析和处理、后台服务api访问、DOM操作等功能。这类框架包括Vue（Vue-router），Backbone，Knockout，AngularJS，Avalon等，而且，它们几乎都在这些模式上产生了变异，以适应前端开发的特点。

框架能极大的提高我们开发的便利，但是框架一般都限制过多，所以我们也可以抛弃框架，直接写原生代码。

代码隔离：

单页应用比页面型网站更加依赖于JavaScript，由于页面的单页化，各种子功能的JavaScript代码聚集到了同一个作用域，所以代码的隔离、模块化变得很重要。

代码合并于加载策略：

• 把更多的公共功能放到首次加载，以减少每次加载的载入量。
• 在单页应用中，无需像网站型产品一样，为了防止文件加载阻塞渲染，把js放到html后面加载，因为它的界面基本都是动态生成的。

路由与状态的管理：

• 单页应用中，因为界面上的各种功能区块是动态生成的，所以需要把产品功能划分为若干状态，每个状态映射到相应的路由，然后通过根据不同的url路径动态解析路由，匹配功能界面。

缓存与本地存储：

• 在单页应用的运作机制中，缓存是一个很重要的环节。
• 由于这类系统的前端部分几乎全是静态文件，所以它能够有机会利用浏览器的缓存机制，而比如动态加载的界面模板，也完全可以做一些自定义的缓存机制，在非首次的请求中直接取缓存的版本，以加快加载速度。
• 在单页产品中，业务代码也常常会需要跟本地存储打交道，存储一些临时数据，可以使用localStorage或者localStorageDB来简化自己的业务代码。

服务端通信：

• 传统的Web产品通常使用JSONP或者AJAX这样的方式与服务端通信，但在单页Web应用中，有很大一部分采用WebSocket这样的实时通讯方式。
• WebSocket与传统基于HTTP的通信机制相比，有很大的优势。它可以让服务端很便利地使用反向推送，前端只响应确实产生业务数据的事件，减少一遍又一遍无意义的AJAX轮询。
• 由于WebSocket只在比较先进的浏览器上被支持，有一些库提供了在不同浏览器中的兼容方案，比如socket.io，它在不支持WebSocket的浏览器上会降级成使用AJAX或JSONP等方式，对业务代码完全透明、兼容。

内存管理：

• 传统的Web页面一般是不需要考t虑内存的管理的，因为用户的停留时间相对少，即使出现内存泄漏，可能很快就被刷新页面之类的操作冲掉了，但单页应用是不同的，它的用户很可能会把它开一整天，因此，我们需要对其中的DOM操作、网络连接等部分格外小心。

样式的规划：

在单页应用中，因为页面的集成度高，所有页面聚集到同一作用域，样式的规划也变得重要了。

样式规划主要是几个方面：

• 1.基准样式的分离，这里面主要包括浏览器样式的重设、全局字体的设置、布局的基本约定和响应式支持。
• 2.组件样式的划分，这里面是两个层面的规划，首先是各种界面组件及其子元素的样式，其次是一些修饰样式。组件样式应当尽量减少相互依赖，各组件的样式允许冗余。
• 3.堆叠次序的管理，传统Web页面的特点是元素多，但是层次少，单页应用会有些不同；在单页应用中，需要提前为各种UI组件规划堆叠次序，也就是z-index，比如说，我们可能会有各种弹出对话框，浮动层，它们可能组合成各种堆叠状态。新的对话框的z-index需要比旧的高，才能确保盖在它上面。

6.多页面应用

单页面应用（SinglePage Web Application，SPA）只有一张Web页面的应用，是一种从Web服务器加载的富客户端，单页面跳转仅刷新局部资源 ，公共资源(js、css等)仅需加载一次，常用于PC端官网、购物等网站。

多页面应用（MultiPage Application，MPA）多页面跳转刷新所有资源，每个公共资源(js、css等)需选择性重新加载，常用于 app 或 客户端等。

具体对比分析：

参考文章：
http://tinyambition.com/Single-Page-App-Break/index.html
https://www.jianshu.com/p/bae4f6604549
https://github.com/xufei/blog/issues/5
https://blog.csdn.net/juzipchy/article/details/76862364
https://juejin.im/post/5a0ea4ec6fb9a0450407725c