摘要：小程序的基礎(chǔ)庫(kù)不會(huì)被打包在某個(gè)小程序的代碼包里邊，它會(huì)被提前內(nèi)置在微信客戶端。小程序沒(méi)有重啟的概念當(dāng)小程序進(jìn)入后臺(tái)，客戶端會(huì)維持一段時(shí)間的運(yùn)行狀態(tài)，超過(guò)一定時(shí)間后目前是分鐘會(huì)被微信主動(dòng)銷(xiāo)毀當(dāng)短時(shí)間內(nèi)連續(xù)收到兩次

接觸小程序有一段時(shí)間了，總得來(lái)說(shuō)小程序開(kāi)發(fā)門(mén)檻比較低，但其中基本的運(yùn)行機(jī)制和原理還是要懂的?！氨热缥以诿嬖嚨臅r(shí)候問(wèn)到一個(gè)關(guān)于小程序的問(wèn)題，問(wèn)小程序有window對(duì)象嗎？他說(shuō)有吧”，但其實(shí)是沒(méi)有的。感覺(jué)他并沒(méi)有了解小程序底層的一些東西，歸根結(jié)底來(lái)說(shuō)應(yīng)該只能算會(huì)使用這個(gè)工具，但并不明白其中的道理。

小程序與普通網(wǎng)頁(yè)開(kāi)發(fā)是有很大差別的，這就要從它的技術(shù)架構(gòu)底層去剖析了。還有比如習(xí)慣Vue，react開(kāi)發(fā)的開(kāi)發(fā)者會(huì)吐槽小程序新建頁(yè)面的繁瑣，page必須由多個(gè)文件組成、組件化支持不完善、每次更改 data 里的數(shù)據(jù)都得setData、沒(méi)有像Vue方便的watch監(jiān)聽(tīng)、不能操作Dom，對(duì)于復(fù)雜性場(chǎng)景不太好，之前不支持npm，不支持sass，less預(yù)編譯處理語(yǔ)言。

“有的人說(shuō)小程序就像被閹割的Vue”，哈哈當(dāng)然了，他們從設(shè)計(jì)的出發(fā)點(diǎn)就不同，咱也得理解小程序設(shè)計(jì)的初衷，通過(guò)它的使用場(chǎng)景，它為什么采用這種技術(shù)架構(gòu)，這種技術(shù)架構(gòu)有什么好處，相信在你了解完這些之后，就會(huì)理解了。下面我會(huì)從以下幾個(gè)角度去分析小程序的運(yùn)行機(jī)制和它的整體技術(shù)架構(gòu)。

在小程序沒(méi)有出來(lái)之前，最初微信WebView逐漸成為移動(dòng)web重要入口，微信發(fā)布了一整套網(wǎng)頁(yè)開(kāi)發(fā)工具包，稱之為 JS-SDK，給所有的 Web 開(kāi)發(fā)者打開(kāi)了一扇全新的窗戶，讓所有開(kāi)發(fā)者都可以使用到微信的原生能力，去完成一些之前做不到或者難以做到的事情。

但JS-SDK 的模式并沒(méi)有解決使用移動(dòng)網(wǎng)頁(yè)遇到的體驗(yàn)不良的問(wèn)題，比如受限于設(shè)備性能和網(wǎng)絡(luò)速度，會(huì)出現(xiàn)白屏的可能。因此又設(shè)計(jì)了一個(gè)增強(qiáng)版JS-SDK，也就是“微信 Web 資源離線存儲(chǔ)”，但在復(fù)雜的頁(yè)面上依然會(huì)出現(xiàn)白屏的問(wèn)題，原因表現(xiàn)在頁(yè)面切換的生硬和點(diǎn)擊的遲滯感。這個(gè)時(shí)候需要一個(gè) JS-SDK 所處理不了的，使用戶體驗(yàn)更好的一個(gè)系統(tǒng)，小程序應(yīng)運(yùn)而生。

快速的加載

更強(qiáng)大的能力

原生的體驗(yàn)

易用且安全的微信數(shù)據(jù)開(kāi)放

高效和簡(jiǎn)單的開(kāi)發(fā)

小程序的開(kāi)發(fā)同普通的網(wǎng)頁(yè)開(kāi)發(fā)相比有很大的相似性，小程序的主要開(kāi)發(fā)語(yǔ)言也是 JavaScript，但是二者還是有些差別的。

普通網(wǎng)頁(yè)開(kāi)發(fā)可以使用各種瀏覽器提供的 DOM API，進(jìn)行 DOM 操作，小程序的邏輯層和渲染層是分開(kāi)的，邏輯層運(yùn)行在 JSCore
中，并沒(méi)有一個(gè)完整瀏覽器對(duì)象，因而缺少相關(guān)的DOM API和BOM
API。

普通網(wǎng)頁(yè)開(kāi)發(fā)渲染線程和腳本線程是互斥的，這也是為什么長(zhǎng)時(shí)間的腳本運(yùn)行可能會(huì)導(dǎo)致頁(yè)面失去響應(yīng)，而在小程序中，二者是分開(kāi)的，分別運(yùn)行在不同的線程中。

網(wǎng)頁(yè)開(kāi)發(fā)者在開(kāi)發(fā)網(wǎng)頁(yè)的時(shí)候，只需要使用到瀏覽器，并且搭配上一些輔助工具或者編輯器即可。小程序的開(kāi)發(fā)則有所不同，需要經(jīng)過(guò)申請(qǐng)小程序帳號(hào)、安裝小程序開(kāi)發(fā)者工具、配置項(xiàng)目等等過(guò)程方可完成。

小程序的執(zhí)行環(huán)境

一般來(lái)說(shuō)，渲染界面的技術(shù)有三種：

用純客戶端原生技術(shù)來(lái)渲染

用純 Web 技術(shù)來(lái)渲染

用客戶端原生技術(shù)與 Web 技術(shù)結(jié)合的混合技術(shù)（簡(jiǎn)稱 Hybrid 技術(shù)）來(lái)渲染

通過(guò)以下幾個(gè)方面分析，小程序采用哪種技術(shù)方案

開(kāi)發(fā)門(mén)檻：Web 門(mén)檻低，Native 也有像 RN 這樣的框架支持

體驗(yàn)：Native 體驗(yàn)比 Web 要好太多，Hybrid 在一定程度上比 Web 接近原生體驗(yàn)

版本更新：Web 支持在線更新，Native 則需要打包到微信一起審核發(fā)布

管控和安全：Web 可跳轉(zhuǎn)或是改變頁(yè)面內(nèi)容，存在一些不可控因素和安全風(fēng)險(xiǎn)

由于小程序的宿主環(huán)境是微信，如果用純客戶端原生技術(shù)來(lái)編寫(xiě)小程序，那么小程序代碼每次都需要與微信代碼一起發(fā)版，這種方式肯定是不行的。

所以需要像web技術(shù)那樣，有一份隨時(shí)可更新的資源包放在云端，通過(guò)下載到本地，動(dòng)態(tài)執(zhí)行后即可渲染出界面。如果用純web技術(shù)來(lái)渲染小程序，在一些復(fù)雜的交互上可能會(huì)面臨一些性能問(wèn)題，這是因?yàn)樵趙eb技術(shù)中，UI渲染跟JavaScript的腳本執(zhí)行都在一個(gè)單線程中執(zhí)行，這就容易導(dǎo)致一些邏輯任務(wù)搶占UI渲染的資源。

所以最終采用了兩者結(jié)合起來(lái)的Hybrid 技術(shù)來(lái)渲染小程序，可以用一種近似web的方式來(lái)開(kāi)發(fā)，并且可以實(shí)現(xiàn)在線更新代碼，同時(shí)引入組件也有以下好處：

擴(kuò)展 Web 的能力。比如像輸入框組件（input, textarea）有更好地控制鍵盤(pán)的能力

體驗(yàn)更好，同時(shí)也減輕 WebView 的渲染工作

繞過(guò) setData、數(shù)據(jù)通信和重渲染流程，使渲染性能更好

用客戶端原生渲染內(nèi)置一些復(fù)雜組件，可以提供更好的性能

小程序的渲染層和邏輯層分別由 2 個(gè)線程管理：視圖層的界面使用了 WebView 進(jìn)行渲染，邏輯層采用 JsCore 線程運(yùn)行 JS腳本。

那么為什么要這樣設(shè)計(jì)呢，前面也提到了管控和安全，為了解決這些問(wèn)題，我們需要阻止開(kāi)發(fā)者使用一些，例如瀏覽器的window對(duì)象，跳轉(zhuǎn)頁(yè)面、操作DOM、動(dòng)態(tài)執(zhí)行腳本的開(kāi)放性接口。

我們可以使用客戶端系統(tǒng)的 JavaScript 引擎，iOS 下的 JavaScriptCore 框架，安卓下騰訊 x5 內(nèi)核提供的 JsCore 環(huán)境。

這個(gè)沙箱環(huán)境只提供純 JavaScript 的解釋執(zhí)行環(huán)境，沒(méi)有任何瀏覽器相關(guān)接口。

這就是小程序雙線程模型的由來(lái)：

邏輯層：創(chuàng)建一個(gè)多帶帶的線程去執(zhí)行 JavaScript，在這里執(zhí)行的都是有關(guān)小程序業(yè)務(wù)邏輯的代碼，負(fù)責(zé)邏輯處理、數(shù)據(jù)請(qǐng)求、接口調(diào)用等

視圖層：界面渲染相關(guān)的任務(wù)全都在 WebView 線程里執(zhí)行，通過(guò)邏輯層代碼去控制渲染哪些界面。一個(gè)小程序存在多個(gè)界面，所以視圖層存在多個(gè) WebView 線程

JSBridge 起到架起上層開(kāi)發(fā)與Native（系統(tǒng)層）的橋梁，使得小程序可通過(guò)API使用原生的功能，且部分組件為原生組件實(shí)現(xiàn)，從而有良好體驗(yàn)

把開(kāi)發(fā)者的 JS 邏輯代碼放到多帶帶的線程去運(yùn)行，但在 Webview 線程里，開(kāi)發(fā)者就沒(méi)法直接操作 DOM。

那要怎么去實(shí)現(xiàn)動(dòng)態(tài)更改界面呢？

如上圖所示，邏輯層和試圖層的通信會(huì)由 Native （微信客戶端）做中轉(zhuǎn)，邏輯層發(fā)送網(wǎng)絡(luò)請(qǐng)求也經(jīng)由 Native 轉(zhuǎn)發(fā)。

這也就是說(shuō)，我們可以把 DOM 的更新通過(guò)簡(jiǎn)單的數(shù)據(jù)通信來(lái)實(shí)現(xiàn)。

Virtual DOM 相信大家都已有了解，大概是這么個(gè)過(guò)程：用 JS 對(duì)象模擬 DOM 樹(shù) -> 比較兩棵虛擬 DOM 樹(shù)的差異 -> 把差異應(yīng)用到真正的 DOM 樹(shù)上。

如圖所示：

1. 在渲染層把 WXML 轉(zhuǎn)化成對(duì)應(yīng)的 JS 對(duì)象。

2. 在邏輯層發(fā)生數(shù)據(jù)變更的時(shí)候，通過(guò)宿主環(huán)境提供的 setData 方法把數(shù)據(jù)從邏輯層傳遞到 Native，再轉(zhuǎn)發(fā)到渲染層。

3. 經(jīng)過(guò)對(duì)比前后差異，把差異應(yīng)用在原來(lái)的 DOM 樹(shù)上，更新界面。

我們通過(guò)把 WXML 轉(zhuǎn)化為數(shù)據(jù)，通過(guò) Native 進(jìn)行轉(zhuǎn)發(fā)，來(lái)實(shí)現(xiàn)邏輯層和渲染層的交互和通信。

而這樣一個(gè)完整的框架，離不開(kāi)小程序的基礎(chǔ)庫(kù)。

小程序的基礎(chǔ)庫(kù)可以被注入到視圖層和邏輯層運(yùn)行，主要用于以下幾個(gè)方面：

在視圖層，提供各類組件來(lái)組建界面的元素

在邏輯層，提供各類 API 來(lái)處理各種邏輯

處理數(shù)據(jù)綁定、組件系統(tǒng)、事件系統(tǒng)、通信系統(tǒng)等一系列框架邏輯

由于小程序的渲染層和邏輯層是兩個(gè)線程管理，兩個(gè)線程各自注入了基礎(chǔ)庫(kù)。

小程序的基礎(chǔ)庫(kù)不會(huì)被打包在某個(gè)小程序的代碼包里邊，它會(huì)被提前內(nèi)置在微信客戶端。

這樣可以：

降低業(yè)務(wù)小程序的代碼包大小

可以多帶帶修復(fù)基礎(chǔ)庫(kù)中的 Bug，無(wú)需修改到業(yè)務(wù)小程序的代碼包

Exparser是微信小程序的組件組織框架，內(nèi)置在小程序基礎(chǔ)庫(kù)中，為小程序的各種組件提供基礎(chǔ)的支持。小程序內(nèi)的所有組件，包括內(nèi)置組件和自定義組件，都由Exparser組織管理。

Exparser的主要特點(diǎn)包括以下幾點(diǎn)：

基于Shadow
DOM模型：模型上與WebComponents的ShadowDOM高度相似，但不依賴瀏覽器的原生支持，也沒(méi)有其他依賴庫(kù)；實(shí)現(xiàn)時(shí)，還針對(duì)性地增加了其他API以支持小程序組件編程。

可在純JS環(huán)境中運(yùn)行：這意味著邏輯層也具有一定的組件樹(shù)組織能力。

高效輕量：性能表現(xiàn)好，在組件實(shí)例極多的環(huán)境下表現(xiàn)尤其優(yōu)異，同時(shí)代碼尺寸也較小。

小程序中，所有節(jié)點(diǎn)樹(shù)相關(guān)的操作都依賴于Exparser，包括WXML到頁(yè)面最終節(jié)點(diǎn)樹(shù)的構(gòu)建、createSelectorQuery調(diào)用和自定義組件特性等。

內(nèi)置組件

基于Exparser框架，小程序內(nèi)置了一套組件，提供了視圖容器類、表單類、導(dǎo)航類、媒體類、開(kāi)放類等幾十種組件。有了這么豐富的組件，再配合WXSS，可以搭建出任何效果的界面。在功能層面上，也滿足絕大部分需求。

小程序啟動(dòng)會(huì)有兩種情況，一種是「冷啟動(dòng)」，一種是「熱啟動(dòng)」。假如用戶已經(jīng)打開(kāi)過(guò)某小程序，然后在一定時(shí)間內(nèi)再次打開(kāi)該小程序，此時(shí)無(wú)需重新啟動(dòng)，只需將后臺(tái)狀態(tài)的小程序切換到前臺(tái)，這個(gè)過(guò)程就是熱啟動(dòng)；冷啟動(dòng)指的是用戶首次打開(kāi)或小程序被微信主動(dòng)銷(xiāo)毀后再次打開(kāi)的情況，此時(shí)小程序需要重新加載啟動(dòng)。

小程序沒(méi)有重啟的概念

當(dāng)小程序進(jìn)入后臺(tái)，客戶端會(huì)維持一段時(shí)間的運(yùn)行狀態(tài)，超過(guò)一定時(shí)間后（目前是5分鐘）會(huì)被微信主動(dòng)銷(xiāo)毀

當(dāng)短時(shí)間內(nèi)（5s）連續(xù)收到兩次以上收到系統(tǒng)內(nèi)存告警，會(huì)進(jìn)行小程序的銷(xiāo)毀

小程序冷啟動(dòng)時(shí)如果發(fā)現(xiàn)有新版本，將會(huì)異步下載新版本的代碼包，并同時(shí)用客戶端本地的包進(jìn)行啟動(dòng)，即新版本的小程序需要等下一次冷啟動(dòng)才會(huì)應(yīng)用上。 如果需要馬上應(yīng)用最新版本，可以使用 wx.getUpdateManager API 進(jìn)行處理。

主要的優(yōu)化策略可以歸納為三點(diǎn)：

精簡(jiǎn)代碼，降低WXML結(jié)構(gòu)和JS代碼的復(fù)雜性；

合理使用setData調(diào)用，減少setData次數(shù)和數(shù)據(jù)量；

必要時(shí)使用分包優(yōu)化。

小程序的視圖層目前使用 WebView 作為渲染載體，而邏輯層是由獨(dú)立的 JavascriptCore 作為運(yùn)行環(huán)境。在架構(gòu)上，WebView 和 JavascriptCore 都是獨(dú)立的模塊，并不具備數(shù)據(jù)直接共享的通道。當(dāng)前，視圖層和邏輯層的數(shù)據(jù)傳輸，實(shí)際上通過(guò)兩邊提供的 evaluateJavascript 所實(shí)現(xiàn)。即用戶傳輸?shù)臄?shù)據(jù)，需要將其轉(zhuǎn)換為字符串形式傳遞，同時(shí)把轉(zhuǎn)換后的數(shù)據(jù)內(nèi)容拼接成一份 JS 腳本，再通過(guò)執(zhí)行 JS 腳本的形式傳遞到兩邊獨(dú)立環(huán)境。

而 evaluateJavascript 的執(zhí)行會(huì)受很多方面的影響，數(shù)據(jù)到達(dá)視圖層并不是實(shí)時(shí)的。

頻繁的去 setData在我們分析過(guò)的一些案例里，部分小程序會(huì)非常頻繁（毫秒級(jí)）的去setData，其導(dǎo)致了兩個(gè)后果：Android下用戶在滑動(dòng)時(shí)會(huì)感覺(jué)到卡頓，操作反饋延遲嚴(yán)重，因?yàn)?JS 線程一直在編譯執(zhí)行渲染，未能及時(shí)將用戶操作事件傳遞到邏輯層，邏輯層亦無(wú)法及時(shí)將操作處理結(jié)果及時(shí)傳遞到視圖層；渲染有出現(xiàn)延時(shí)，由于 WebView 的 JS 線程一直處于忙碌狀態(tài)，邏輯層到頁(yè)面層的通信耗時(shí)上升，視圖層收到的數(shù)據(jù)消息時(shí)距離發(fā)出時(shí)間已經(jīng)過(guò)去了幾百毫秒，渲染的結(jié)果并不實(shí)時(shí)；

每次 setData 都傳遞大量新數(shù)據(jù)由setData的底層實(shí)現(xiàn)可知，我們的數(shù)據(jù)傳輸實(shí)際是一次 evaluateJavascript

腳本過(guò)程，當(dāng)數(shù)據(jù)量過(guò)大時(shí)會(huì)增加腳本的編譯執(zhí)行時(shí)間，占用 WebView JS 線程， 后臺(tái)態(tài)頁(yè)面進(jìn)行
setData當(dāng)頁(yè)面進(jìn)入后臺(tái)態(tài)（用戶不可見(jiàn)），不應(yīng)該繼續(xù)去進(jìn)行setData，后臺(tái)態(tài)頁(yè)面的渲染用戶是無(wú)法感受的，另外后臺(tái)態(tài)頁(yè)面去setData也會(huì)搶占前臺(tái)頁(yè)面的執(zhí)行。

大致從以上幾個(gè)角度分析了小程序的底層架構(gòu)，從小程序的由來(lái)、到雙線程的出現(xiàn)、設(shè)計(jì)、通信、到基礎(chǔ)庫(kù)、Exparser 框架、再到運(yùn)行機(jī)制、性能優(yōu)化等等，都是一個(gè)個(gè)相關(guān)而又相互影響的選擇。關(guān)于小程序的底層框架設(shè)計(jì)，其實(shí)涉及到的還有很多，比如自定義組件，原生組件、性能優(yōu)化等方面，都不是一點(diǎn)能講完的，還要多看源碼，多思考。每一個(gè)框架的誕生都有其意義，我們作為開(kāi)發(fā)者能做的不只是會(huì)使用這個(gè)工具，還應(yīng)理解它的設(shè)計(jì)模式。只有這樣才不會(huì)被工具左右，才能走的更遠(yuǎn)！