微信小程式分包載入實戰
"離線包"機制
微信小程式採用的是類似離線包載入方案，以 轉轉 小程式為例，當用戶第一次開啟時會先下載好所有程式碼，然後再載入頁面；當用戶再次進入轉轉小程式時，會直接使用已下載的程式碼，省去了程式碼下載的過程，開啟速度更快。
看似很美好的設計，但有兩個問題：
第一次開啟轉轉小程式時白屏時間很長，因為要下載接近2.5M的程式碼量，也就是說你的程式碼越多，白屏時間越長，而轉轉APP採用的網頁離線機制體驗更佳：在使用者開啟APP時就下載/更新離線包，這樣在使用者進入對應的網頁時，程式碼已經下載好了，沒有漫長的白屏過程。
程式碼有部分更新時，沒辦法進行增量更新，導致每次發版後，使用者都需要重新下載全部程式碼
問題看似不大，但對轉轉有很大影響，例如進行微信廣告投放時，使用者從點選廣告到載入第一個頁面之間的流失率竟能到達40%，這顯然是FE無法接受的效能，而小程式分包載入機制能夠在一定程度上解決上述問題。
分包載入
小程式的分包載入機制實際上是離線包和M頁的一種結合機制，即你可以把程式碼劃分成主包+N個分包，官方定義：
在小程式啟動時，預設會下載主包並啟動主包內頁面，如果使用者需要開啟分包內某個頁面，客戶端會把對應分包下載下來，下載完成後再進行展示。
總結如下：
開啟小程式，預設先載入主包
進入分包頁面時，再載入對應分包
這樣的好處是進入主包頁面時，需要下載的程式碼量小了很多，白屏時間更短，體驗更佳。
特性
1.7.3 及以上基礎庫開始支援，不支援的版本預設使用整包的方式
整個小程式所有分包大小不超過 4M，單個分包/主包大小不能超過 2M
分包數量目前沒有限制，也就是說你可以放N個分包，甚至每個頁面一個分包
入口頁面/TAB頁面必須在主包裡
關於主包
第一次進入小程式，預設下載主包程式碼
分包以外的所有程式碼，都會被打入主包
分包內程式碼可以引用主包內程式碼
關於分包
因為存在資源依賴關係，微信的機制是先下載主包，後下載分包
分包目錄不能在主包目錄下面
分包可以引用自己包內、主包內的資源，不能引用其他分包內的資源
坑
小程式的打包機制僅僅是根據檔案目錄打包，分包內require/import的任何檔案，只要不在同一個目錄下面，都不會被打進分包，也就是說，類庫及一些公共檔案，只能放在主包裡面，如果主包分包劃分不好的話，主包的大小也很難降下來
安卓系統進入分包頁面時，會出現一個醜陋的系統級的loading層，這一定程度上影響了安卓的體驗
轉轉的分包載入
轉轉小程式在使用分包之前，壓縮後的程式碼量大概是2.45M，也就是說，每個新使用者第一次都需要下載的2.45M程式碼才能進入頁面，使用分包機制後，主包大小降為1M左右，也就是說，如果是進入主包頁面， 下載時間大約降低了60%
檔案結構：
我們根據使用者訪問的軌跡，分成了20個左右的分包。 例如trade包，裡面包含詳情頁、下單頁、支付頁、支付成功頁等，這條線的頁面，使用者可能不需要一進入小程式就使用，但一旦使用可能是使用整個鏈條，因此可以作為一個分包。
歷史入口相容
一個頁面放入分包之後，路徑會發生變化，例如詳情頁由/pages/detail變為/subPages/trade/detail，意味著如果使用者訪問了以前的page則得不到正確的頁面響應（例如：分享出去的小程式卡片、二維碼、公眾號推送訊息等），這些靜態不可改變的歷史入口怎麼辦？我們目前採用如下方案：
原來主包內的每個頁面都保留，但程式碼只保留跳轉邏輯，使用者進來後立即跳到對應的分包頁面，使用者幾乎是無感知的
這樣也會產生一點小問題：這些跳轉頁面也佔用一定的空間，接下來我們會優化成在onLaunch、頁面跳轉時進行判斷，直接跳入正確的分包頁面。