Rumah >hujung hadapan web >html tutorial >有关单页应用的体验问题
---恢复内容开始---
##什么是单页应用
所谓单页应用,指的是在一个页面上集成多种功能,甚至整个系统就只有一个页面(一个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!