一切始于雙線程
技術(shù)選型
目前來說痘昌，頁面渲染的方式主要有三種：
- Web 渲染控汉。
- Native 原生渲染姑子。
- Web 與 Native 兩者摻雜街佑，也即我們常說的 Hybrid 渲染沐旨。
前面也說過磁携，小程序最終的呈現(xiàn)形式谊迄，是 WebView + 原生組件统诺，Hybrid 方式粮呢。我們結(jié)合之前對小程序的期望來看：
- 開發(fā)門檻：Web 門檻低啄寡，不過 Native 也有像 RN 這樣的框架支持
- 體驗(yàn)：Native 體驗(yàn)比 Web 不要好太多，Hybrid 在一定程度上比 Web 接近原生體驗(yàn)
- 版本更新：Web 支持在線更新哩照，Native 則需要打包到微信一起審核發(fā)布
- 管控和安全：Web 可跳轉(zhuǎn)或是改變頁面內(nèi)容挺物，存在一些不可控因素和安全風(fēng)險(xiǎn)
由于小程序的宿主是微信，如果用純客戶端原生技術(shù)來編寫小程序 葡秒，那小程序代碼需要與微信代碼一起編包姻乓，跟隨微信發(fā)版本嵌溢，這種方式跟開發(fā)節(jié)奏必然都是不對的眯牧。
所以方向應(yīng)該是需要像 Web 技術(shù)那樣蹋岩，有一份隨時(shí)可更新的資源包放在云端，通過下載到本地学少，動(dòng)態(tài)執(zhí)行后即可渲染出界面剪个。
如果用純 Web 技術(shù)來渲染小程序，在一些有復(fù)雜交互的頁面上可能會(huì)面臨一些性能問題版确。
這是因?yàn)樵?Web 技術(shù)中侵歇，UI渲染跟 JavaScript 的腳本執(zhí)行都在一個(gè)單線程中執(zhí)行，這就容易導(dǎo)致一些邏輯任務(wù)搶占UI渲染的資源。
總地看來伟叛，小程序選擇了 Hybrid 的渲染方式，可以用一種近似 Web 的方式來開發(fā)，并且還可以實(shí)現(xiàn)在線更新代碼辉哥。同時(shí)饲齐，引入原生組件有以下好處：
- 擴(kuò)展 Web 的能力御雕。比如像輸入框組件（input, textarea）有更好地控制鍵盤的能力
- 體驗(yàn)更好，同時(shí)也減輕 WebView 的渲染工作
- 繞過 setData、數(shù)據(jù)通信和重渲染流程，使渲染性能更好
現(xiàn)在代承，我們還剩下一個(gè)很重要的問題：管控性和安全性意荤。于是，雙線程的設(shè)計(jì)被提出來了。
雙線程的小程序
也不知道是哪位大佬握恳，能想出雙線程這樣的模型匕坯，反正我是佩服得666的锹雏。
雙線程是什么？我們先來看個(gè)官方的圖：
小程序的渲染層和邏輯層分別由 2 個(gè)線程管理：渲染層的界面使用了 WebView 進(jìn)行渲染稼病，邏輯層采用 JsCore 線程運(yùn)行 JS 腳本援制。
為什么要這么設(shè)計(jì)呢洪己？前面提到的管控和安全，為了解決這些問題，我們需要阻止開發(fā)者使用一些瀏覽器提供的哗咆，諸如跳轉(zhuǎn)頁面年碘、操作 DOM娱颊、動(dòng)態(tài)執(zhí)行腳本的開放性接口悟衩。
我們可以使用客戶端系統(tǒng)的 JavaScript 引擎幕与，iOS下的 JavaScriptCore 框架诫给，安卓下騰訊 x5 內(nèi)核提供的 JsCore 環(huán)境胃榕。通過提供一個(gè)沙箱環(huán)境來運(yùn)行開發(fā)者的 JavaScript 代碼來解決赐写。這個(gè)沙箱環(huán)境只提供純 JavaScript 的解釋執(zhí)行環(huán)境泣矛，沒有任何瀏覽器相關(guān)接口几颜。
這就是小程序雙線程模型的由來：
- 邏輯層：創(chuàng)建一個(gè)單獨(dú)的線程去執(zhí)行 JavaScript，在這個(gè)環(huán)境下執(zhí)行的都是有關(guān)小程序業(yè)務(wù)邏輯的代碼
- 渲染層：界面渲染相關(guān)的任務(wù)全都在 WebView 線程里執(zhí)行怜跑，通過邏輯層代碼去控制渲染哪些界面辫樱。一個(gè)小程序存在多個(gè)界面，所以渲染層存在多個(gè) WebView 線程
雙線程通信
把開發(fā)者的 JS 邏輯代碼放到單獨(dú)的線程去運(yùn)行，但在 Webview 線程里敦冬，開發(fā)者就沒法直接操作 DOM甘耿。那要怎么去實(shí)現(xiàn)動(dòng)態(tài)更改界面呢贰剥？
前面我們知道芹缔，邏輯層和渲染層的通信會(huì)由 Native （微信客戶端）做中轉(zhuǎn)拌阴，邏輯層發(fā)送網(wǎng)絡(luò)請求也經(jīng)由 Native 轉(zhuǎn)發(fā)皮官。這是不是意味著，我們可以把 DOM 的更新通過簡單的數(shù)據(jù)通信來實(shí)現(xiàn)呢斋否？
Virtual DOM 相信大家都已有了解茵臭，大概是這么個(gè)過程：用JS對象模擬DOM樹 -> 比較兩棵虛擬DOM樹的差異 -> 把差異應(yīng)用到真正的DOM樹上。
在這里我們可以用上罢低，如圖：
- 在渲染層把 WXML 轉(zhuǎn)化成對應(yīng)的 JS 對象。
- 在邏輯層發(fā)生數(shù)據(jù)變更的時(shí)候，通過宿主環(huán)境提供的 setData 方法把數(shù)據(jù)從邏輯層傳遞到 Native鹿鳖，再轉(zhuǎn)發(fā)到渲染層歼疮。
- 經(jīng)過對比前后差異杂抽，把差異應(yīng)用在原來的 DOM 樹上，更新界面韩脏。
我們通過把 WXML 轉(zhuǎn)化為數(shù)據(jù)缩麸，通過 Native 進(jìn)行轉(zhuǎn)發(fā)，來實(shí)現(xiàn)邏輯層和渲染層的交互和通信赡矢。而這樣完整的一套框架匙睹，基本上都是通過小程序的基礎(chǔ)庫來完成的。
小程序的基礎(chǔ)庫
小程序的基礎(chǔ)庫是 JavaScript 編寫的济竹，它可以被注入到渲染層和邏輯層運(yùn)行痕檬。主要用于：
- 在渲染層，提供各類組件來組建界面的元素
- 在邏輯層送浊，提供各類 API 來處理各種邏輯
- 處理數(shù)據(jù)綁定梦谜、組件系統(tǒng)、事件系統(tǒng)袭景、通信系統(tǒng)等一系列框架邏輯
由于小程序的渲染層和邏輯層是兩個(gè)線程管理唁桩，兩個(gè)線程各自注入了基礎(chǔ)庫。小程序的基礎(chǔ)庫不會(huì)被打包在某個(gè)小程序的代碼包里邊耸棒，它會(huì)被提前內(nèi)置在微信客戶端荒澡。這樣可以：
- 降低業(yè)務(wù)小程序的代碼包大小
- 可以單獨(dú)修復(fù)基礎(chǔ)庫中的 Bug，無需修改到業(yè)務(wù)小程序的代碼包
Exparser 框架
Exparser 是微信小程序的組件組織框架与殃，內(nèi)置在小程序基礎(chǔ)庫中单山，為小程序的各種組件提供基礎(chǔ)的支持。小程序內(nèi)的所有組件幅疼，包括內(nèi)置組件和自定義組件米奸，都由 Exparser 組織管理。Exparser 特點(diǎn)包括：
- 基于 Shadow DOM 模型：模型上與 WebComponents 的 ShadowDOM 高度相似爽篷，但不依賴瀏覽器的原生支持悴晰，也沒有其他依賴庫；實(shí)現(xiàn)時(shí)逐工，還針對性地增加了其他API以支持小程序組件編程铡溪。
- 可在純JS環(huán)境中運(yùn)行：這意味著邏輯層也具有一定的組件樹組織能力。
- 高效輕量：性能表現(xiàn)好泪喊，在組件實(shí)例極多的環(huán)境下表現(xiàn)尤其優(yōu)異棕硫，同時(shí)代碼尺寸也較小。
