注冊登錄

小程序無限層級路由方案

2018-09-20
導(dǎo)讀:小程序無限層級路由方案 小程序原生頁面存在層級限制,超過一定層數(shù)就會無法打開新頁面。一開始這個限制為不超過5層,目前是不超過10層。 這個限制對于體量較大的小程序來說,...

小程序原生頁面存在層級限制,超過一定層數(shù)就會無法打開新頁面。一開始這個限制為不超過5層,目前是不超過10層。

這個限制對于體量較大的小程序來說,挺難受的。特別是只能打開5層那會兒,業(yè)務(wù)流程很容易一不小心就超了,比如:首頁-搜索結(jié)果頁-商品詳情頁-聊天頁-下單頁-地址選擇頁-...;更有訪問回路防不勝防,比如:商品詳情頁-查看更多頁-商品詳情頁-查看更多頁-...、商品詳情頁-聊天頁-個人主頁-商品詳情頁-聊天頁-個人主頁-商品詳情頁-...、諸如此類。即使后來放寬至了10層,還是很容易遭遇層級溢出。

一種處理思路是調(diào)整交互路徑,嚴(yán)格控制層級數(shù)量。但是這種處理方案,一則很多時候會犧牲用戶體驗,比如為避免個人主頁和商品詳情頁的訪問回路,要么不能在個人主頁中訪問用戶商品,要么不能在商品詳情頁中訪問賣家主頁,要么訪問時需要替換當(dāng)前不能返回繼續(xù)瀏覽,不管怎么取舍都會犧牲某些用戶的瀏覽訴求;二則維護成本特別高,業(yè)務(wù)邏輯越來越復(fù)雜,交互路徑越來越發(fā)散,路徑的統(tǒng)一梳理和規(guī)劃就會越來越困難,而且管理過程對業(yè)務(wù)不透明,業(yè)務(wù)方在設(shè)計需求時要受到交互路徑的種種限制,甚至一個需求的交互調(diào)整很可能無意中造成另一個需求層級溢出,維護成本高且不斷膨脹。

因而本文考慮并實現(xiàn)了另一種處理思路:在小程序中支持不限層級的路由過程。

策略
  • 修改小程序默認導(dǎo)航行為,自行維護完整歷史記錄
  • 頁面層級小于等于10時,導(dǎo)航行為與原生導(dǎo)航行為一致
  • 請求打開第11層及以上時,邏輯層級記錄完整歷史,實際層級每次都是直接將第10層替換為目標(biāo)頁面
  • 返回時,邏輯層級相應(yīng)回退;若回退后邏輯層級大于等于10,則實際層級將第10層替換為目標(biāo)頁面,否則實際層級回退到相應(yīng)頁面
  • demo:
  邏輯層級 1 - 2 - ... - 8 - 9 - 10
  實際層級 1 - 2 - ... - 8 - 9 - 10
  
  打開
  
  邏輯層級 1 - 2 - ... - 8 - 9 - 10 - 11
  實際層級 1 - 2 - ... - 8 - 9 - 11
  
  打開,打開,打開
  
  邏輯層級 1 - 2 - ... - 8 - 9 - 10 - 11 - 12 - 13 - 14
  實際層級 1 - 2 - ... - 8 - 9 - 14
  
  返回
  
  邏輯層級 1 - 2 - ... - 8 - 9 - 10 - 11 - 12 - 13
  實際層級 1 - 2 - ... - 8 - 9 - 13
  
  返回,返回,返回
  
  邏輯層級 1 - 2 - ... - 8 - 9 - 10
  實際層級 1 - 2 - ... - 8 - 9 - 10
  
  返回
  
  邏輯層級 1 - 2 - ... - 8 - 9
  實際層級 1 - 2 - ... - 8 - 9
實現(xiàn)

轉(zhuǎn)轉(zhuǎn) 實現(xiàn)了上述策略,并提供開源使用,地址:https://github.com/zhuanzhuanfe/fancy-mini,歡迎使用或參閱。

主要難點及實現(xiàn)方案:

  • 如何接管路由過程

    • 要求所有頁面不使用<navigator>元素,統(tǒng)一使用js觸發(fā)跳轉(zhuǎn)
    • 要求所有頁面不直接調(diào)用wx.navigateTo、wx.redirectTo等路由相關(guān)接口,統(tǒng)一改用模塊封裝的相應(yīng)接口
  • 如何監(jiān)聽返回行為

    • 統(tǒng)一監(jiān)聽頁面的onUnload函數(shù),結(jié)合路由過程判斷是否用戶返回
  • 如何兼容系統(tǒng)交互

    • 問題:系統(tǒng)交互會跳出正常路由流程,并且難以接管或監(jiān)控,如:用戶點擊右上角返回主頁按鈕、用戶切后臺后又從其它入口進入、用戶強制關(guān)閉小程序進程等
    • 處理:引入校正機制,在合適的時機根據(jù)系統(tǒng)路由棧對自行維護的路由棧進行校正。這樣可以保證10層以內(nèi)路由正確性。系統(tǒng)交互多是回到第1層,會被成功校正。
  • 如何避免/兼容代碼疏漏

    • 問題:接管&監(jiān)聽過程要求所有頁面遵循一些編碼約束,如何保證這些約束切實全面生效;萬一有頁面未遵循約束,能否依然保證健壯性
    • 處理1:編寫并配置相應(yīng)eslint規(guī)則,保證約束被切實遵循
    • 處理2:上一條中的校正機制,保證即使有代碼疏漏,在10層內(nèi)也會被校正;10層外可能會影響返回邏輯正確性,但一般不會造成頁面功能問題。
  • 如何進行狀態(tài)恢復(fù)

    • 問題:返回后邏輯層級大于等于10時,實際是在第10層重新載入目標(biāo)頁面;用戶在前一頁面的表單輸入等狀態(tài)信息并不會像系統(tǒng)返回一樣正常保留
    • 處理:在合適的時機存儲頁面的data,返回時予以恢復(fù)
成本
  • 接入成本

    • 需要引入并配置路由模塊
    • 需要檢查并修改項目中所有頁面跳轉(zhuǎn)過程,統(tǒng)一使用模塊封裝的接口
    • 需要統(tǒng)一監(jiān)聽所有頁面的onUnload函數(shù)
  • 維護成本

    • 新增頁面跳轉(zhuǎn)過程,需統(tǒng)一使用模塊封裝的接口
    • 新增頁面onUnload函數(shù)需接入統(tǒng)一監(jiān)聽
  • 性能成本

    • 模塊執(zhí)行邏輯相對簡單,內(nèi)存開銷相對較小,頁面性能暫未發(fā)現(xiàn)明顯損耗
收益
  • 無限層級

    • 避免復(fù)雜/循環(huán)訪問導(dǎo)致頁面無法打開
    • 可以放心地向用戶提供適合的訪問入口,不必過分擔(dān)心路徑限制
  • 完全的路由管控能力

    • 可以完全監(jiān)控路由過程并實現(xiàn)或引入一些附加功能
    • 附加功能:實例覆蓋自動恢復(fù)

      • 問題:wepy框架存在單實例問題,同一路徑頁面被打開兩次時,其數(shù)據(jù)會相互影響,如:詳情頁A - 詳情頁B - 返回A,點擊查看大圖 - B的圖片(而不是A的圖片)
  詳見issue:[兩級頁面為同一路由時,后者數(shù)據(jù)覆蓋前者](https://github.com/Tencent/wepy/issues/322)
  - 策略:返回時,若判斷目標(biāo)頁面數(shù)據(jù)已被覆蓋,則自動予以恢復(fù)
  - 引入:參見模塊使用說明
  • 附加功能: 免并發(fā)

    - 問題:用戶連續(xù)快速點擊多個/多次按鈕時,會一次性打開多個窗口,一則造成層級膨脹,二則影響瀏覽體驗
    - 策略:第一次點擊造成的跳轉(zhuǎn)完成之前無視后續(xù)點擊產(chǎn)生的跳轉(zhuǎn)請求
    - 引入:參見模塊使用說明
  • 附加功能:數(shù)據(jù)預(yù)先加載

    - 問題:小程序的page1跳轉(zhuǎn)到page2,到page2的onLoad是存在一個300ms ~ 400ms的延時的,在page2的onLoad中才開始獲取數(shù)據(jù)會浪費這個延時
    - 策略:在 page1 中預(yù)先拿取數(shù)據(jù),然后在 page2 中直接使用數(shù)據(jù);wepy框架對此有良好的實現(xiàn),參見[WePY 在小程序性能調(diào)優(yōu)上做出的探究](https://segmentfault.com/a/1190000008975448?winzoom=1) 
    - 引入:參見模塊使用說明

 

 

重磅推薦:小程序開店目錄

第一部分:小商店是什么

第二部分:如何開通一個小商店

第三部分:如何登錄小商店

第四部分:開店任務(wù)常見問題

第五部分:小商店可以賣什么

第六部分:HiShop小程序特色功能

第七部分:小程序直播

第八部分:小程序收貨/物流

第九部分:小程序怎么結(jié)算

第十部分:小程序客服

第十一部分:電商創(chuàng)業(yè)

第十二部分:小程序游戲開發(fā)

電話咨詢 微信咨詢 預(yù)約演示 0元開店