一种小程序弱网离线优化的思路

作者:孙然(煮虾)

当我遇到弱网......

  • 电梯中查看钉钉日程详情,但打不开,得走进办公室连上 WiFi,重新操作一遍打开日程
  • 走出办公楼一段距离了,依然连接着公司 WiFi,但信号极弱,又不能自动切换到4G,钉钉里工作台打不开,还得手动把网络设置为4G才能接着使用
  • ……

弱网下的三级用户体验

诚然,要想在弱网下也让移动 App 做到和强网一样的体验是极为困难的,但用户对弱网下的可用性其实是有合理预期的。如果当前没有联网,用户不会指望能拉取到最新的内容;但如果一个功能仅依赖本地数据,并不依赖网络,用户则希望能在弱网下至少能打开。

不同业务页面的弱网表现会给用户带来不同的体验感受。这里,我们把弱网离线下好与坏的体验分成了可打开、可查看、可提交三个级别,用户体验逐级递增:

程序" title="小程序">小程序的三层弱网离线优化模型

在小程序已经被各种业务广泛使用的现状下,针对于小程序,我们提出了三个层面的弱网离线优化思路。

资源

资源的离线可用主要包括小程序离线包和图片两个方面。它们是小程序界面渲染的最基本要素。做到它们的资源离线可用后,可以达到可打开这个级别的离线体验。

小程序离线包

小程序离线包是否可用直接决定了小程序是否可以被打开。实际上小程序的包管理系统已经提供了一部分离线加载能力,比如在 48 小时内的打开都会优先使用现存的离线包,在此时间段内小程序都是可打开的。

但是一旦超过 48 小时,就会触发小程序包管理的强制更新机制,也就是必须等待网络下载最新版本的小程序包后方可打开。这种情况下遇到弱网场景,就可能造成小程序迟迟无法打开的情况。弱网下应当尽可能避开强制更新策略。

图片

小程序里用到的图片资源可能来自于两种地方:

  • 网络:与 H5 的图片类似,可以统一走 H5 的图片优化策略
  • 离线包:图片资源被打在离线包里,跟随离线包一起优化

数据

在做到资源离线可用的基础上,如果小程序所需的数据也能做到离线可用,那么就可以达到可查看这个级别的离线体验。

但这里的数据需要进行区分。对于部分实时性、一致性要求较高的数据,不能盲目进行离线可用,或考虑更优雅的方式提示用户。

小程序里的数据来源大部分都来自于网络请求,也就通过 httpRequest 之类的为数不多的 JSAPI 获取。所以可以考虑对这类 JSAPI 进行统一的离线缓存优化。对于更为定制的需求,可以考虑提供业务自己的本地数据 JSAPI 进行优化。

事务

对于小程序里需要做的一些依赖网络的数据提交事务,如果能够实现弱网下的“假提交”,就可以达到可提交这个级别的用户体验了。

对于这三个层面,我们都可以参考“本地优先”的原则进行优化:在数据层面,对请求的数据进行本地缓存后,下一次请求优先使用本地数据,待网络返回后进行刷新;在事务层面,对用户的数据提交操作先提交到本地队列,待网好后再进行真提交。

对于弱网离线体验,以上三个方面的优先级是:资源 ≥ 数据 ≥ 事务。先保证页面可见,再保证有数据可用,再保证事务可离线提交。

例如,对于一个日程小程序,我们可以设计如下的弱网离线优化方案:

总结

我们基于用户在弱网下的预期,对用户的弱网体验进行了三个级别的分级。面向这三个级别的体验,我们提出了小程序的三层弱网离线优化模型,为后续小程序的弱网离线体验优化提供了一种思路。

关注【阿里巴巴移动技术】微信公众号,每周 3 篇移动技术实践&干货给你思考!

以上是 一种小程序弱网离线优化的思路 的全部内容, 来源链接: utcz.com/z/267829.html

回到顶部