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

文章图片

作者：孙然(煮虾)
当我遇到弱网......

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

弱网下的三级用户体验诚然，要想在弱网下也让移动 App 做到和强网一样的体验是极为困难的，但用户对弱网下的可用性其实是有合理预期的。如果当前没有联网，用户不会指望能拉取到最新的内容；但如果一个功能仅依赖本地数据，并不依赖网络，用户则希望能在弱网下至少能打开。
不同业务页面的弱网表现会给用户带来不同的体验感受。这里，我们把弱网离线下好与坏的体验分成了可打开、可查看、可提交三个级别，用户体验逐级递增：
【一种小程序弱网离线优化的思路】

文章图片

小程序的三层弱网离线优化模型在小程序已经被各种业务广泛使用的现状下，针对于小程序，我们提出了三个层面的弱网离线优化思路。
资源资源的离线可用主要包括小程序离线包和图片两个方面。它们是小程序界面渲染的最基本要素。做到它们的资源离线可用后，可以达到可打开这个级别的离线体验。
小程序离线包
小程序离线包是否可用直接决定了小程序是否可以被打开。实际上小程序的包管理系统已经提供了一部分离线加载能力，比如在 48 小时内的打开都会优先使用现存的离线包，在此时间段内小程序都是可打开的。

文章图片

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

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

数据在做到资源离线可用的基础上，如果小程序所需的数据也能做到离线可用，那么就可以达到可查看这个级别的离线体验。
但这里的数据需要进行区分。对于部分实时性、一致性要求较高的数据，不能盲目进行离线可用，或考虑更优雅的方式提示用户。
小程序里的数据来源大部分都来自于网络请求，也就通过 httpRequest 之类的为数不多的 JSAPI 获取。所以可以考虑对这类 JSAPI 进行统一的离线缓存优化。对于更为定制的需求，可以考虑提供业务自己的本地数据 JSAPI 进行优化。
事务对于小程序里需要做的一些依赖网络的数据提交事务，如果能够实现弱网下的“假提交”，就可以达到可提交这个级别的用户体验了。
对于这三个层面，我们都可以参考“本地优先”的原则进行优化：在数据层面，对请求的数据进行本地缓存后，下一次请求优先使用本地数据，待网络返回后进行刷新；在事务层面，对用户的数据提交操作先提交到本地队列，待网好后再进行真提交。
对于弱网离线体验，以上三个方面的优先级是：资源 ≥ 数据 ≥ 事务。先保证页面可见，再保证有数据可用，再保证事务可离线提交。
例如，对于一个日程小程序，我们可以设计如下的弱网离线优化方案：