引言

上一篇介紹了微信頁面技術的發展以及小程序的技術選型，還有小程序的雙線程模型，小程序的javascript的運行環境. 大家可以回顧：我從小程序學到了什么（一）

這里先說明以下，本系列一定不只是對小程序的官方文檔進行歸納總結，前面幾篇先讓大家熟悉小程序的技術體系，后面的內容會結合公司自身的移動技術體系與小程序做對比以及相應的技術調研，當然最后還會跟大家分享本司小程序的技術生態發展情況。

多WebView的頁面架構

與大部分的hybrid只用一個WebView不同，小程序是多個WebView架構，所以小程序在實現雙線程模型時的js解析和執行部分選擇的并不是HTML5中的ServiceWorker，因為不可能讓其中一個WebView的ServiceWorker來管理多個頁面，如下圖：

所以小程序最終還是使用客戶端的JSCore來處理Javascript。

微信官方并沒有過多的說明選擇多WebView的原因以及處理WebView的方案，我個人憑經驗認為原因如下：
大多數公司為了讓Hybrid更流暢使用的是SPA方案，但使用SPA要花比較多精力和對開發人員要求比較高，而小程序如果想要保證Hybrid的流暢又要降低開發門檻，使用多WebView也許是其中一個選擇，多個WebView在技術方面能降低實現復雜度。拋開開發難易因素，對于特別復雜的頁面，多個WebView也能分擔渲染壓力。

引用微信官方文檔原文：

小程序宿主環境限制了這個頁面棧的最大層級為10層 ，也就是當頁面棧到達10層之后就沒有辦法再推入新的頁面了

其中“頁面棧“的概念會在下面給大家描述，這里也能看出小程序對于多個WebView造成內存消耗的擔心。

頁面層級

先引用一段官方原文：

在視圖層內，小程序的每一個頁面都獨立運行在一個頁面層級上。小程序啟動時僅有一個頁面層級，每次調用wx.navigateTo，都會創建一個新的頁面層級；相對地，wx.navigateBack會銷毀一個頁面層級。

每個頁面打開之前小程序都會準備一個對應的頁面層級，所以層級在這里是一個初始化的概念。

引用一個官方原文的圖（侵刪）：

從圖可以看出這個層級在初始化做了三步：
第一步：啟動WebView。
第二步：初始化小程序基礎庫。
第三步：注入小程序的WXML和WXSS

補充一點，這里注入小程序的WXML和WXSS應該是在編譯期間已經準備好了的html與css。WXML與WXSS相關的請各位讀者在官方文檔了解。

拿目前我司的Hybrid相比，我們并沒有做相應的初始化工作，所以我們也可以試著將WebView做一些初始化，無論是IOS還是Android，啟動WebView都有時間開銷，另外也可以將我們常用的JS庫預先加載，相信做了類似的優化，我們的app在打開頁面時速度會快很多，后續我會與客戶端的同事一起討論，如果有優化效果我會在后續的文章里面分享給大家。
小程序有多個頁面，所以有多個頁面層級，那這些頁面層級的管理是用一個頁面棧來做的，每次打開一個頁面，頁面棧就會增加一個頁面層級，微信客戶端會限制頁面棧里面的頁面層級不能超過10個。

總結：

今天講了小程序多WebView架構，我們自己的Hybrid是否也需要多WebView架構這里值得討論，我個人覺得大部分場景是不需要多WebView架構的，但即使是單WebView架構，我們也可以考慮使用ServiceWorker來專門處理Javascript，也可以考慮WebView預加載。后面我們會逐步深挖，敬請期待。