作者：孙然 (煮虾)
当我遇到弱网 ……
- 电梯中查看钉钉日程详情，但打不开，得走进办公室连上 WiFi，从新操作一遍关上日程
- 走出办公楼一段距离了，仍然连贯着公司 WiFi，但信号极弱，又不能主动切换到 4G，钉钉里工作台打不开，还得手动把网络设置为 4G 能力接着应用
- ……
弱网下的三级用户体验
诚然，要想在弱网下也让挪动 App 做到和强网一样的体验是极为艰难的，但用户对弱网下的可用性其实是有正当预期的。如果以后没有联网，用户不会指望能拉取到最新的内容；但如果一个性能仅依赖本地数据，并不依赖网络，用户则心愿能在弱网下至多能关上。
不同业务页面的弱网体现会给用户带来不同的体验感触。这里，咱们把弱网离线下好与坏的体验分成了可关上、可查看、可提交三个级别，用户体验逐级递增：
小程序的三层弱网离线优化模型
在小程序曾经被各种业务宽泛应用的现状下，针对于小程序，咱们提出了三个层面的弱网离线优化思路。
资源
资源的离线可用次要包含小程序离线包和图片两个方面。它们是小程序界面渲染的最基本要素。做到它们的资源离线可用后，能够达到可关上这个级别的离线体验。
小程序离线包
小程序离线包是否可用间接决定了小程序是否能够被关上。实际上小程序的包管理系统曾经提供了一部分离线加载能力，比方在 48 小时内的关上都会优先应用现存的离线包，在此时间段内小程序都是可关上的。
然而一旦超过 48 小时，就会触发小程序包治理的强制更新机制，也就是必须期待网络下载最新版本的小程序包前方可关上。这种状况下遇到弱网场景，就可能造成小程序迟迟无奈关上的状况。弱网下该当尽可能避开强制更新策略。
图片
小程序里用到的图片资源可能来自于两种中央：
- 网络：与 H5 的图片相似，能够对立走 H5 的图片优化策略
- 离线包：图片资源被打在离线包里，追随离线包一起优化
数据
在做到资源离线可用的根底上，如果小程序所需的数据也能做到离线可用，那么就能够达到可查看这个级别的离线体验。
但这里的数据须要进行辨别。对于局部实时性、一致性要求较高的数据，不能自觉进行离线可用，或思考更优雅的形式提醒用户。
小程序里的数据起源大部分都来自于网络申请，也就通过 httpRequest 之类的为数不多的 JSAPI 获取。所以能够思考对这类 JSAPI 进行对立的离线缓存优化。对于更为定制的需要，能够思考提供业务本人的本地数据 JSAPI 进行优化。
事务
对于小程序里须要做的一些依赖网络的数据提交事务，如果可能实现弱网下的“假提交”，就能够达到可提交这个级别的用户体验了。
对于这三个层面，咱们都能够参考“本地优先”的准则进行优化：在数据层面，对申请的数据进行本地缓存后，下一次申请优先应用本地数据，待网络返回后进行刷新；在事务层面，对用户的数据提交操作先提交到本地队列，待网好后再进行真提交。
对于弱网离线体验，以上三个方面的优先级是：资源 ≥ 数据 ≥ 事务。先保障页面可见，再保障有数据可用，再保障事务可离线提交。
例如，对于一个日程小程序，咱们能够设计如下的弱网离线优化计划：
总结
咱们基于用户在弱网下的预期，对用户的弱网体验进行了三个级别的分级。面向这三个级别的体验，咱们提出了小程序的三层弱网离线优化模型，为后续小程序的弱网离线体验优化提供了一种思路。
关注【阿里巴巴挪动技术】微信公众号，每周 3 篇挪动技术实际 & 干货给你思考！