Rumah >hujung hadapan web >html tutorial >有关单页应用的体验问题

有关单页应用的体验问题

一个新手
一个新手asal
2017-10-02 19:42:231420semak imbas

---恢复内容开始---

##什么是单页应用
所谓单页应用,指的是在一个页面上集成多种功能,甚至整个系统就只有一个页面(一个html),所有的业务功能都是它的子模块,通过特定的方式挂接到主界面上。

##为什么会有单页应用
我们知道ajax技术的产生,一部分原因就是为了让访问网页的用户在不刷新页面的情况下,在页面上查看数据的变更。我们可以说ajax提升了体验。

随着互联网的发展,浏览器端承载的业务愈发复杂,web前端早已不再是一个简单页面,ajax局部刷一刷的小玩意。动辄数十个子页面的应用市面上随处可见。而这些子页面享有许多共用的资源(静态、动态),加载它们需要不少的时间,要想不重复加载这些资源,有一个显而易见的办法 —— 把他们放到一个html中。

所以说它是ajax技术的进一步升华,把ajax的无刷新机制发挥到极致,因此能造就与桌面程序媲美的流畅用户体验。

##单页应用带来的困扰
我们知道,把十几个二十几个子页面的程序,放在一个html里面,不是cut+paste就能搞定的。原本不相关的程序,放在一起的结果,就是程序世界的质能方程 Errors = (More Code)^2

##单页应用的体验
言归正传,如何尽可能增强单页应用的操作体验?

那我们先来看一下,对于用户来说,影响体验的,包括哪些

1. 页面初始的加载速度
2. 交互的响应
3. 页面数据的正确性(尤其是网络异常状况下)

--
前两点其实很多文章谈的都比较多了,这里我尽量一笔带过,重点谈一谈第三点。

####页面初始加载速度
- 静态资源的按需加载 (良好的模块化前提下,使用webpack、 systemjs这类module bundler工具)
- 动态资源的按需获取 (需要前端数据层的良好架构)
- 服务端渲染 (把页面加载过程中,前端“获取”数据,并“生成”页面的过程,放在服务端完成。不适用于首屏过于复杂的应用)

####交互的响应
- 速度:后端请求回来的数据,前端缓存,后续同步。避免同样的数据重复请求。
- 异常处理:现今移动办公普及,如何在网络状况欠佳时,在ui上给用户良好的等待或者提示,也不可小视

####页面数据的正确性
这个是我比较想谈的,也是我们在实践过程中遇到过很多问题,也尝试过一些解决方案的。

我个人觉得,对于这件事,想要做好,就这几个字: **“良好的缓存管理”**,这里的缓存,指的是前端缓存的模型。

别看就这几个字,做起来相当有难度。为何?

####先说内存的来源,有以下几种:

- 浏览器缓存(indexDB,localStorage之流)
- http请求
- webSocket推送

不同的来源,影响同一份数据,需要良好的抽象,让业务层屏蔽对数据来源的感知,现有的被广泛应用的解决此问题的库有RxJs, CycleJS等,早先也有人提出MVI的概念,皆为此生。

####再说内存的变更

正常状态的变更,无需赘言,这里只说几类异常状态。

#####http请求失败

这里需要提到一个词,叫**“操作补偿”**

什么是操作补偿呢?

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

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

我们的产品一样遇到这个问题。我们的做法是 —— **“折中”**,对于重要数据,做单步补偿,或者两步补偿。如果遇到前端模型从属关系复杂且上级模型的写操作失败,抑或是过多步的补偿,就提早通知用户,并在ui上锁死用户的交互入口,避免后续写操作的发生。

这里如果继续再做也是有的做,和离线应用思路相似,把操作的结果记录在客户端本地,等到网络正常,再和后台进行数据同步。


#####断线重连

网络抖动、网络的切换、电脑休眠再打开等等,导致我们需要面对更复杂的网络状况,那当用户再次联网的时候,应用需要去重新链接。

这时,一个理想的单页应用,会在重新连接的时候,把之前所有发生的事件产生的最终结果,也就是最新的状态,同步回来。

我们的应用是有协作业务的,同一企业的用户间,享有同样的模型,通过webSocket进行同步,保证模型的即时性和正确性。所以这也是我们遇到的一大挑战。我们解决的方式是webSocket的重发。

#####热更新

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

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

#####最后
曾经听过一个说法,如何判断一个单页面产品的技术水准呢?
连续开几天不关,不需要刷新页面,应用一样可以正常、正确、流畅的使用。

这里面的含义,相信做过单页应用的同学们心里都懂。

##小结

说了不少,总结一下。我们提到了一些问题和针对问题的能够提升单页应用体验的方式,如果实现出来,肯定是可以让使用者非常开心的,但需要冷静权衡理想与现实之间的差距。我们做的是软件工程,必须适当放弃美学,将有限的人力精力投入到要害所在。

---恢复内容结束---

Atas ialah kandungan terperinci 有关单页应用的体验问题. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!

Kenyataan:
Kandungan artikel ini disumbangkan secara sukarela oleh netizen, dan hak cipta adalah milik pengarang asal. Laman web ini tidak memikul tanggungjawab undang-undang yang sepadan. Jika anda menemui sebarang kandungan yang disyaki plagiarisme atau pelanggaran, sila hubungi admin@php.cn