@徐飞分享：从8个方面增强单页面体验方式及优势？

前言

今日分享内容由@徐飞提供，文章对提升单页面使用感受进行了概述，涉及八个关键点，详细内容敬请向下浏览。

正文从这开始～

什么是单页应用

所谓单页应用，即指在单一页面上整合了众多功能，有时整个系统仅由一个页面构成。其中，所有业务功能均作为其子模块存在，并通过特定方式附加至主界面之上。这种应用是AJAX技术的深度拓展，将AJAX的无刷新特性发挥到了极致，从而实现了与桌面程序相媲美的流畅用户体验。

单页应用的优势

操作过程顺畅，给人一种如同使用本地应用般的体验，在切换时，不会频繁感受到被打断的干扰。

由于界面架构完全部署在本地，与服务器的交互主要涉及数据传输，因此易于进行迁移操作。这样的特性使得我们可以以较低的成本，将产品顺利转变为桌面应用程序，亦或是各类混合型移动端应用。

单页应用的弱点

如何尽可能增强单页应用的操作体验？

1. 什么叫做路由？

路由可以理解为url与界面状态的对应关系。

我们必须认识到，在理想情况之下，URL与界面状态之间应当保持精确的匹配。例如，针对同一用户，若两次通过相同的URL访问界面，其显示的状态理应毫无差异。而对同一界面执行相同的操作后，URL应能准确反映此时的状态。

然而，我们必须认识到，若每一项细致的操作都需与路由同步，这无疑将变得极为复杂，因此在设计阶段，我们应当有所选择，摒弃那些与路由同步过于繁琐的状态。

2. 服务端推送

推送功能意味着在某些特定情境下，即便网页处于静止状态，服务器端仍会主动发送信息，确保用户界面能够相应地展示这些内容。一般情况下，我们通过WebSocket等类似技术来达成这一交互体验。

有时，我们会在网页上遇到推送的应用场景，其中最普遍的便是即时通讯信息。

在应用中增设一个聊天界面，当他人发送信息时，我们这边能够立即显示出消息内容。

若追求极致的用户体验，我们可选择通过推送功能来实现应用内各项业务调整，例如：

当我浏览某项任务时，发现有人对其进行了编辑，按照预期，无需我进行任何操作，其修改内容便能自动在我这边显现。

若对整个业务范围的调整均实施推送式管理，用户的操作感受将显著提升；然而，这也会导致实施过程中的难度和代码的复杂性迅速增加。

3. 断线重连机制

要如何评价一个单页面产品的技术水平呢？这可以通过以下方法来确定：

连续多日开启且未关闭设备，无需执行“刷新”这一步骤来处理某些常见故障。

为何此事能彰显技术实力？这是因为要将此事做到极致，必须确保以下几点：

由于移动办公的广泛应用等因素，我们或许会遇到一些状况，例如网络切换、电脑从休眠状态唤醒等，此时在重新连接网络后，必须对在此过程中产生的业务变动进行补充学习，并将这些变动逐一反映在界面上，确保界面保持最新状态。

4. 操作补偿机制

什么是操作补偿呢？

从理论角度分析，在用户界面进行操作并创建任务时，新任务不应立即在界面上显现，而应待服务端确认无误后，再将其添加至界面。然而，由于网络状况可能不佳，用户可能需要较长时间等待这一过程的完成。从用户感受的层面来看，这样的做法并不可取，因此我们应当先将界面呈现出来，待收到创建成功的反馈信息后，再将那些具有唯一性的标识信息补充至内存数据之中。

操作补偿对于单步操作尚属简单，但涉及多步操作则变得相当复杂。以一个极端情形为例，当用户在服务端未反馈前便在新增任务下创建子任务，此时子任务却缺乏父任务的ID。若要对此步骤同样进行补偿，则过程会变得异常繁琐。甚至到了这样的地步，在完成了一系列步骤之后，我们遗憾地发现先前的尝试并未成功，这导致接下来的处理过程将会变得异常繁琐。

5. 本地缓存的使用

如前所述，若在多阶段连续操作过程中遭遇失败，情况将变得相当棘手；例如，你填入大量信息后，在提交时却遭遇网络故障，这无疑令人头疼不已。在这种时刻，用户迫切希望所填数据能够得到保存，以便网络恢复后能够重新尝试。

我们可以利用本地缓存暂时存放这些信息。若在此环节达到极致，并辅以精心设计的操作补偿系统，甚至能够让用户在没有网络的情况下使用我们的应用，将所有产生的变动先保存于缓存之中，待联网后统一进行同步和合并。

6. 热更新

先前提及，用户可能持续使用我们的应用程序而未进行刷新。在常规情形下，业务上的任何变动理应全面推送至用户端，界面显示的状态应当是实时更新且与实际情况相符。然而，我们必须面对一个额外的问题，即系统升级后如何处理？

我们完全有能力发送一条信息告知：本系统已进行升级，请进行页面刷新。然而，我们是否能够做得更加出色？答案是有可能的。为了实现这一目标，我们必须采用热更新技术，将代码的模块化以及变更管理推向极致。同时，每次更新的代码模块也应一并推送，并作为补丁直接应用于现有系统。然而，这种机制对开发团队的专业能力提出了相当高的要求。

7. 良好的内存管理

要想让用户能够长期开着应用，还需要管理好内存。

数据波动、路径转换、模块的生成与淘汰，均会引起内存的相应调整。实现完美的内存管理实属不易，若致力于在此领域追求极致，将对开发流程产生显著影响，且往往成本高昂。因此，我们可采取一些优化措施，解决一些常见问题，并对不再需要的资源进行及时清理。

8. 服务端预渲染

此类单页应用常采用一种经典架构，即前端与后端彻底分离。前端负责加载界面及处理逻辑，而后端则负责响应数据。前端根据接收到的数据，进而“生成”相应的界面变化。

我们这里存在一个“生成”的环节，通常也将其称作“渲染”。其运作原理是依据数据信息来构建相应的界面。若在浏览器端进行界面生成，首先需加载界面模板或逻辑，这需要发起一次网络请求；界面准备就绪后，还需再次请求所需数据，从而产生第二次网络请求。网络请求的响应速度往往不及“界面生成”迅速，而且这种延迟的时间波动较大，这可能会导致用户首次看到界面的时间被推迟。

尽管单页应用与服务器端渲染之间存在冲突，我们依然能够对这一问题进行一定程度的改进，例如，将某些页面直接由服务器端提供数据生成。目前，一些开发框架正尝试从不同角度着手解决此问题，即通过提取客户端与服务器端渲染的共性，运用恰当的抽象方法来共同描述这两种渲染方式，使得仅通过配置的调整便能够实现渲染机制的切换。

小结

我们谈到了那些有助于改善单页应用使用感受的方法，若成功实施，无疑能极大地提升用户的满意度，然而，我们必须冷静地衡量理想与实际情况之间的差距，慎重作出决策。

这些在文中提到的体验增强手段，必须经过深思熟虑后方可实施；实施得越多，对技术操控的熟练度要求也就越高，同时出错的可能性也随之增大。

有一句著名的表达式：

E = MC^2

我们可以对此有不一样的解读：

Errors = (More Code) ^ 2