微信小程序採用的是相似離線包加載方案,以轉轉小程序爲例,當用戶第一次打開時會先下載好全部代碼,而後再加載頁面;當用戶再次進入轉轉小程序時,會直接使用已下載的代碼,省去了代碼下載的過程,打開速度更快。前端
看似很美好的設計,但有兩個問題:web
問題看似不大,但對轉轉有很大影響,例如進行微信廣告投放時,用戶從點擊廣告到加載第一個頁面之間的流失率竟能到達 40%,這顯然是 FE 沒法接受的性能,而小程序分包加載機制可以在必定程度上解決上述問題。小程序
小程序的分包加載機制其實是離線包和 M 頁的一種結合機制,即你能夠把代碼劃分紅主包 +N 個分包,官方定義:微信小程序
在小程序啓動時,默認會下載主包並啓動主包內頁面,若是用戶須要打開分包內某個頁面,客戶端會把對應分包下載下來,下載完成後再進行展現。bash
總結以下:微信
這樣的好處是進入主包頁面時,須要下載的代碼量小了不少,白屏時間更短,體驗更佳。post
轉轉小程序在使用分包以前,壓縮後的代碼量大概是2.45M,也就是說,每一個新用戶第一次都須要下載的2.45M代碼才能進入頁面,使用分包機制後,主包大小降爲1M左右,也就是說,若是是進入主包頁面,下載時間大約下降了60%性能
文件結構:優化
├── libs
├── components
├── pages 主包根目錄
├────index 首頁
├────post 發佈頁
├────...
├── subPages 分包根目錄
├────trade 交易分包
├────mine 個人頁面分包
├────...
複製代碼
咱們根據用戶訪問的軌跡,分紅了 20 個左右的分包。 例如 trade 包,裏面包含詳情頁、下單頁、支付頁、支付成功頁等,這條線的頁面,用戶可能不須要一進入小程序就使用,但一旦使用多是使用整個鏈條,所以能夠做爲一個分包。ui
一個頁面放入分包以後,路徑會發生變化,例如詳情頁由 /pages/detail 變爲 /subPages/trade/detail,意味着若是用戶訪問了之前的 page 則得不到正確的頁面響應(例如:分享出去的小程序卡片、二維碼、公衆號推送消息等),這些靜態不可改變的歷史入口怎麼辦?咱們目前採用以下方案:
原來主包內的每一個頁面都保留,但代碼只保留跳轉邏輯,用戶進來後當即跳到對應的分包頁面,用戶幾乎是無感知的
這樣也會產生一點小問題:這些跳轉頁面也佔用必定的空間,接下來咱們會優化成在 onLaunch、頁面跳轉時進行判斷,直接跳入正確的分包頁面。
以上是轉轉在分包加載方面的實戰記錄,歡迎小程序開發者與咱們交流經驗。
另外,本文做者轉轉前端負責人張所勇,也會在掘金開發者大會・微信小程序專場分享轉轉小程序開發經驗,演講主題是「小程序 WebView 應用實踐」。
具體內容:從小程序基礎庫 1.6.4 開始,微信小程序支持 web-view 組件。web-view 組件是一個能夠用來承載網頁的容器,會自動鋪滿整個小程序頁面。但在 WebView 實踐中,性能、多端適配、小程序能力、存量 M 頁處理等都是開發中的痛點。我會在這次分享中,向你們介紹轉轉針對這些痛點設計的 Adapter,也會針對方法執行時機、 formID 收集、通訊、支付等問題介紹轉轉的解決方案。
掘金開發者大會 ∙ 微信小程序專場現已開始正式報名,如今正在 8 折優惠中。咱們特地爲本文讀者帶來了參與活動的專屬福利:掃碼進入小程序,輸入專屬優惠碼:zz
,立減 99 元(限量 10 名)!活動中,不只有乾貨滿滿的技術盛宴,還包衆多福利獎品和價值 299 元的自助午飯哦! 活動信息: