作者：孫然(煮蝦)
當我遇到弱網......
- 電梯中檢視釘釘日程詳情，但打不開，得走進辦公室連上 WiFi，重新操作一遍開啟日程
- 走出辦公樓一段距離了，依然連線著公司 WiFi，但訊號極弱，又不能自動切換到4G，釘釘裡工作臺打不開，還得手動把網路設定為4G才能接著使用
- ……
弱網下的三級使用者體驗
誠然，要想在弱網下也讓移動 App 做到和強網一樣的體驗是極為困難的，但使用者對弱網下的可用性其實是有合理預期的。如果當前沒有聯網，使用者不會指望能拉取到最新的內容；但如果一個功能僅依賴本地資料，並不依賴網路，使用者則希望能在弱網下至少能開啟。
不同業務頁面的弱網表現會給使用者帶來不同的體驗感受。這裡，我們把弱網離線下好與壞的體驗分成了可開啟、可檢視、可提交三個級別，使用者體驗逐級遞增：
小程式的三層弱網離線優化模型
在小程式已經被各種業務廣泛使用的現狀下，針對於小程式，我們提出了三個層面的弱網離線優化思路。
資源
資源的離線可用主要包括小程式離線包和圖片兩個方面。它們是小程式介面渲染的最基本要素。做到它們的資源離線可用後，可以達到可開啟這個級別的離線體驗。
小程式離線包
小程式離線包是否可用直接決定了小程式是否可以被開啟。實際上小程式的包管理系統已經提供了一部分離線載入能力，比如在 48 小時內的開啟都會優先使用現存的離線包，在此時間段內小程式都是可開啟的。
但是一旦超過 48 小時，就會觸發小程式包管理的強制更新機制，也就是必須等待網路下載最新版本的小程式包後方可開啟。這種情況下遇到弱網場景，就可能造成小程式遲遲無法開啟的情況。弱網下應當儘可能避開強制更新策略。
圖片
小程式裡用到的圖片資源可能來自於兩種地方：
- 網路：與 H5 的圖片類似，可以統一走 H5 的圖片優化策略
- 離線包：圖片資源被打在離線包裡，跟隨離線包一起優化
資料
在做到資源離線可用的基礎上，如果小程式所需的資料也能做到離線可用，那麼就可以達到可檢視這個級別的離線體驗。
但這裡的資料需要進行區分。對於部分實時性、一致性要求較高的資料，不能盲目進行離線可用，或考慮更優雅的方式提示使用者。
小程式裡的資料來源大部分都來自於網路請求，也就通過 httpRequest 之類的為數不多的 JSAPI 獲取。所以可以考慮對這類 JSAPI 進行統一的離線快取優化。對於更為定製的需求，可以考慮提供業務自己的本地資料 JSAPI 進行優化。
事務
對於小程式裡需要做的一些依賴網路的資料提交事務，如果能夠實現弱網下的“假提交”，就可以達到可提交這個級別的使用者體驗了。
對於這三個層面，我們都可以參考“本地優先”的原則進行優化：在資料層面，對請求的資料進行本地快取後，下一次請求優先使用本地資料，待網路返回後進行重新整理；在事務層面，對使用者的資料提交操作先提交到本地佇列，待網好後再進行真提交。
對於弱網離線體驗，以上三個方面的優先順序是：資源 ≥ 資料 ≥ 事務。先保證頁面可見，再保證有資料可用，再保證事務可離線提交。
例如，對於一個日程小程式，我們可以設計如下的弱網離線優化方案：
總結
我們基於使用者在弱網下的預期，對使用者的弱網體驗進行了三個級別的分級。面向這三個級別的體驗，我們提出了小程式的三層弱網離線優化模型，為後續小程式的弱網離線體驗優化提供了一種思路。
關注【阿里巴巴移動技術】微信公眾號，每週 3 篇移動技術實踐&乾貨給你思考！