如何增强单页应用的体验

本贴最后更新于 2755 天前,其中的信息可能已经物是人非

作者:徐飞,网名民工精髓 V,Teambition 前端架构师。。有十年以上大型企业应用前端架构及开发经验,熟悉 AngularJS 等框架,对 Web 组件化有一些思考。博客地址:https://github.com/xufei/blog/issues

什么是单页应用

所谓单页应用,指的是在一个页面上集成多种功能,甚至整个系统就只有一个页面,所有的业务功能都是它的子模块,通过特定的方式挂接到主界面上。它是 AJAX 技术的进一步升华,把 AJAX 的无刷新机制发挥到极致,因此能造就与桌面程序媲美的流畅用户体验。

单页应用的优势

操作体验流畅,媲美本地应用的感觉,切换过程中不会频繁有被“打断”的感觉。
因为界面框架都在本地,与服务端的通讯基本只有数据,所以便于迁移,可以用比较小的代价,迁移成桌面产品,或者各种移动端 Hybrid 产品。

单页应用的弱点

  • 对搜索引擎不友好
  • 开发难度相对较高

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

- 路由的规划
- 推送的使用
- 断线重连机制
- 操作补偿机制
- 本地缓存
- 热更新
- 良好的内存管理
- 服务端预渲染

1. 什么叫做路由?

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

我们需要注意到,在理想状态下,url 和界面状态应当是精确对应的。比如说,对同一个用户来说,两次使用同一个 url 所打开的界面,其状态应当是完全一致的。对于同一个界面,进行相同的操作之后,url 应当能够精确反馈当前状态。

但是我们需要注意到,细碎操作如果都需要跟路由保持同步,会是一个非常繁琐的事情,所以在设计过程中应当加以取舍,舍弃那些过于细碎的状态与路由的同步。

2. 服务端推送

推送的意思是,某些情况下,即使页面开着不动,服务端也主动发送消息过来,让界面能够有所体现。通常我们会使用 WebSocket 之类的技术来实现这种体验。

有时候,我们可能会看到一些在页面上使用推送的场景,最常见的是即时消息。

比如说,我们在应用里加一个聊天窗口,其他人发一条消息,自己这边能够实时展现出来。

如果是为了极致的用户体验,我们可以把整个应用的业务变更都使用推送,比如:

我在查看某条任务的时候,有人修改了这条任务,我这里应该不需要做什么操作,就能自动体现出他的修改。

如果对全业务的变更都做推送管理,使用体验会大为加强,但是,实现难度和代码复杂度会急剧上升。

3. 断线重连机制

我们如何判断一个单页面产品的技术水准呢?可以通过这样一种方式:

连续开几天不关,不需要通过“刷新”这个操作来解决一些常见问题。

为什么这个事情能够体现技术水准呢?因为要把这个事情做到极致,需要把这几件事情做好:

  • 断线重连机制
  • 良好的内存管理
  • 版本的自动升级

因为移动办公普及之类的情况,导致我们可能需要面对一些情况,比如,切换了网络,电脑休眠再打开之类,当再次联网的时候,就需要去重新链接,并且,对这个过程中发生的业务变更进行“补课”,然后逐一应用到界面上来,把界面调整到最新状态。

4. 操作补偿机制

什么是操作补偿呢?

从逻辑上来讲,当我们在界面上操作,创建一条任务的时候,新的这条任务不应当立刻显示出来,而是应当等到服务端确认成功了,才加到界面上。但很可能我们的网络不好,这一步用户要等很久。从用户体验的角度,这样是不好的,所以我们可以先把界面放上去,然后等创建成功的消息回来之后,再把一些唯一标识之类的东西回填到内存数据中。

单步的操作补偿还算是不太难,如果有多步的话,就非常麻烦了,举个极端情况的例子来说,用户新增了一条任务,服务端还没返回的时候,他就立刻在这条任务下创建子任务,但子任务这时候没有父任务的 id,如果想给这步也做操作补偿,就比较麻烦了。甚至说,连续进行了几步操作之后,发现之前的操作失败了,后续处理会非常复杂。

5. 本地缓存的使用

上面提到,如果多步连续操作中间出现了失败,局面会比较尴尬,比如你填了好多东西,提交的时候才发现网络坏了,那就非常头疼,这时候,用户会非常期望这些数据能够保存下来,等网络好了再重新尝试。

我们可以使用本地缓存来临时存储这些数据。如果这个层面做到极致,能够结合良好设计的操作补偿机制,甚至可以让用户脱机使用我们的应用,把所有产生的这些变更都缓存,等到联网的时候再批量同步合并回去。

6. 热更新

前面提到,用户有可能长期开着我们的应用,然后中间一直没有刷新。正常情况下,业务变更都应当会被全部推送过来,界面所反馈的状况始终是最新的,符合现状的。但我们需要考虑到另外一个问题,系统升级怎么办?

我们当然可以推送一个通知:本系统已经升级了,请点击刷新。但能不能做得更好?这是有可能的,要达到这种目的,就要使用热更新这种手段,把代码的模块化和变更管理都做到极致,每次更新的代码模块也推送过来,并且作为补丁应用到当前系统上。这种机制对开发团队的水准要求很高。

7. 良好的内存管理

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

数据的变动、路由的切换、组件的创建与销毁,都会带来内存的变化。完美的内存控制是几乎做不到的,如果要追求这方面的极致,对开发过程的影响会非常大,很多情况下是不划算的,所以,可以做一些针对优化,把比较常规的问题解决掉,不用的东西及时销毁。

8. 服务端预渲染

作为一个单页应用,很经典的模式就是前后端完全分离,前端加载界面和逻辑,后端响应数据,前端根据这些数据,“生成”相应的变化。

注意到,我们这里有一个“生成”的过程,通常我们也会把这个过程称为“渲染”。它的机制就是根据数据生成对应的界面,如果是在浏览器侧生成这个界面,首先,加载界面模板或者逻辑,需要一次请求,然后,等这块准备好了,还需要去请求数据,这时候又多了一次网络请求。网络请求通常是比“生成界面”慢的,并且很可能这个时间不稳定,这时候就可能延误了用户第一次看到界面的时间。

虽然单页应用跟服务端渲染是存在矛盾的,但我们仍然可以部分优化这个事情,比如把某些页面由服务端直接代入数据生成。现在有一些开发框架也在尝试从另外一个层面解决这个问题,那就是对客户端和服务端渲染提取共性,使用合适的抽象方式来同时描述这两种机制,从而仅仅依靠配置的变更就可以切换渲染机制。

小结

我们提到了这些能够提升单页应用体验的方式,如果实现出来,肯定是可以让使用者非常愉悦的,但需要冷静权衡理想与现实之间的差距:

  • 我要做的是一个怎样的东西?
  • 我的开发团队是怎样的实力?
  • 我们有怎样的历史负担?
  • 值不值得这么做?
  • 能不能做得了?

本文中提到的这些体验增强方式,都是需要去权衡实现的,做得越多,所需要的技术掌控能力越强,出错概率也越高。

有一句著名的表达式:

E = MC^2

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

Errors = (More Code) ^ 2
  • 前端

    前端技术一般分为前端设计和前端开发,前端设计可以理解为网站的视觉设计,前端开发则是网站的前台代码实现,包括 HTML、CSS 以及 JavaScript 等。

    247 引用 • 1347 回帖

相关帖子

欢迎来到这里!

我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。

注册 关于
请输入回帖内容 ...