轉轉小程序分包加載實例分析

本篇內容介紹了“轉轉小程序分包加載實例分析”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

看似很美好的設計，但有兩個問題：

• 第一次打開轉轉小程序時白屏時間很長，因為要下載接近2.5M的代碼量，也就是說你的代碼越多，白屏時間越長，而轉轉APP采用的網頁離線機制體驗更佳：在用戶打開APP時就下載/更新離線包，這樣在用戶進入對應的網頁時，代碼已經下載好了，沒有漫長的白屏過程。

• 代碼有部分更新時，沒辦法進行增量更新，導致每次發版后，用戶都需要重新下載全部代碼

問題看似不大，但對轉轉有很大影響，例如進行微信廣告投放時，用戶從點擊廣告到加載第一個頁面之間的流失率竟能到達 40% ，這顯然是 FE 無法接受的性能，而小程序分包加載機制能夠在一定程度上解決上述問題。

分包加載

小程序的分包加載機制實際上是離線包和 M 頁的一種結合機制，即你可以把代碼劃分成主包 +N 個分包，官方定義：

在小程序啟動時，默認會下載主包并啟動主包內頁面，如果用戶需要打開分包內某個頁面，客戶端會把對應分包下載下來，下載完成后再進行展示。

總結如下：

• 打開小程序，默認先加載主包

• 進入分包頁面時，再加載對應分包

這樣的好處是進入主包頁面時，需要下載的代碼量小了很多，白屏時間更短，體驗更佳。

特性

• 1.7.3 及以上基礎庫開始支持，不支持的版本默認使用整包的方式

• 整個小程序所有分包大小不超過 4M，單個分包/主包大小不能超過 2M

• 分包數量目前沒有限制，也就是說你可以放 N 個分包，甚至每個頁面一個分包

• 入口頁面 / Tab 頁面必須在主包里

關于主包

• 第一次進入小程序，默認下載主包代碼

• 分包以外的所有代碼，都會被打入主包

• 分包內代碼可以引用主包內代碼

關于分包

• 因為存在資源依賴關系，微信的機制是先下載主包，后下載分包

• 分包目錄不能在主包目錄下面

• 分包可以引用自己包內、主包內的資源，不能引用其他分包內的資源

坑

• 小程序的打包機制僅僅是根據文件目錄打包，分包內require/import的任何文件，只要不在同一個目錄下面，都不會被打進分包，也就是說，類庫及一些公共文件，只能放在主包里面，如果主包分包劃分不好的話，主包的大小也很難降下來

• 安卓系統進入分包頁面時，會出現一個丑陋的系統級的loading層，這一定程度上影響了安卓的體驗

轉轉的分包加載

轉轉小程序在使用分包之前，壓縮后的代碼量大概是2.45M，也就是說，每個新用戶第一次都需要下載的2.45M代碼才能進入頁面，使用分包機制后，主包大小降為1M左右，也就是說，如果是進入主包頁面， 下載時間大約降低了60%

文件結構：

├── libs
├── components
├── pages  主包根目錄
├────index 首頁
├────post  發布頁
├────...
├── subPages  分包根目錄
├────trade    交易分包
├────mine     我的頁面分包
├────...
復制代碼

我們根據用戶訪問的軌跡，分成了 20 個左右的分包。 例如 trade 包，里面包含詳情頁、下單頁、支付頁、支付成功頁等，這條線的頁面，用戶可能不需要一進入小程序就使用，但一旦使用可能是使用整個鏈條，因此可以作為一個分包。

歷史入口兼容

一個頁面放入分包之后，路徑會發生變化，例如詳情頁由 /pages/detail 變為 /subPages/trade/detail，意味著如果用戶訪問了以前的 page 則得不到正確的頁面響應（例如：分享出去的小程序卡片、二維碼、公眾號推送消息等），這些靜態不可改變的歷史入口怎么辦？我們目前采用如下方案：

原來主包內的每個頁面都保留，但代碼只保留跳轉邏輯，用戶進來后立即跳到對應的分包頁面，用戶幾乎是無感知的

這樣也會產生一點小問題：這些跳轉頁面也占用一定的空間，接下來我們會優化成在 onLaunch、頁面跳轉時進行判斷，直接跳入正確的分包頁面。

“轉轉小程序分包加載實例分析”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！