引言

上一篇介紹了微信頁面技術(shù)的發(fā)展以及小程序的技術(shù)選型，還有小程序的雙線程模型，小程序的javascript的運(yùn)行環(huán)境. 大家可以回顧：我從小程序?qū)W到了什么（一）

這里先說明以下，本系列一定不只是對小程序的官方文檔進(jìn)行歸納總結(jié)，前面幾篇先讓大家熟悉小程序的技術(shù)體系，后面的內(nèi)容會結(jié)合公司自身的移動(dòng)技術(shù)體系與小程序做對比以及相應(yīng)的技術(shù)調(diào)研，當(dāng)然最后還會跟大家分享本司小程序的技術(shù)生態(tài)發(fā)展情況。

多WebView的頁面架構(gòu)

與大部分的hybrid只用一個(gè)WebView不同，小程序是多個(gè)WebView架構(gòu)，所以小程序在實(shí)現(xiàn)雙線程模型時(shí)的js解析和執(zhí)行部分選擇的并不是HTML5中的ServiceWorker，因?yàn)椴豢赡茏屍渲幸粋€(gè)WebView的ServiceWorker來管理多個(gè)頁面，如下圖：

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

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

引用微信官方文檔原文：

小程序宿主環(huán)境限制了這個(gè)頁面棧的最大層級為10層 ，也就是當(dāng)頁面棧到達(dá)10層之后就沒有辦法再推入新的頁面了

其中“頁面棧“的概念會在下面給大家描述，這里也能看出小程序?qū)τ诙鄠€(gè)WebView造成內(nèi)存消耗的擔(dān)心。

頁面層級

先引用一段官方原文：

在視圖層內(nèi)，小程序的每一個(gè)頁面都獨(dú)立運(yùn)行在一個(gè)頁面層級上。小程序啟動(dòng)時(shí)僅有一個(gè)頁面層級，每次調(diào)用wx.navigateTo，都會創(chuàng)建一個(gè)新的頁面層級；相對地，wx.navigateBack會銷毀一個(gè)頁面層級。

每個(gè)頁面打開之前小程序都會準(zhǔn)備一個(gè)對應(yīng)的頁面層級，所以層級在這里是一個(gè)初始化的概念。

引用一個(gè)官方原文的圖（侵刪）：

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

補(bǔ)充一點(diǎn)，這里注入小程序的WXML和WXSS應(yīng)該是在編譯期間已經(jīng)準(zhǔn)備好了的html與css。WXML與WXSS相關(guān)的請各位讀者在官方文檔了解。

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

總結(jié)：

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