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

作者：孙然(煮虾)

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

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

弱网下的三级用户体验

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

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

小程序的三层弱网离线优化模型

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

资源

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

小程序离线包

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

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

图片

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

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

数据

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

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

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

事务

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

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

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

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

总结

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

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