前端的框架太多讓人眼花繚亂，很多相似的地方，優(yōu)秀的地方大家都會借鑒，同時又會有各自的一些特點(diǎn)。小程序也好，其他框架也好，理解他們的設(shè)計緣由、實(shí)現(xiàn)原理，還是能學(xué)到很多很多東西的。

一切始于雙線程

技術(shù)選型

目前來說，頁面渲染的方式主要有三種：

1. Web 渲染。
2. Native 原生渲染。
3. Web 與 Native 兩者摻雜，也即我們常說的 Hybrid 渲染。

前面也說過，小程序最終的呈現(xiàn)形式，是 WebView + 原生組件，Hybrid 方式。我們結(jié)合之前對小程序的期望來看：

• 開發(fā)門檻：Web 門檻低，不過 Native 也有像 RN 這樣的框架支持
• 體驗：Native 體驗比 Web 不要好太多，Hybrid 在一定程度上比 Web 接近原生體驗
• 版本更新：Web 支持在線更新，Native 則需要打包到微信一起審核發(fā)布
• 管控和安全：Web 可跳轉(zhuǎn)或是改變頁面內(nèi)容，存在一些不可控因素和安全風(fēng)險

由于小程序的宿主是微信，如果用純客戶端原生技術(shù)來編寫小程序 ，那小程序代碼需要與微信代碼一起編包，跟隨微信發(fā)版本，這種方式跟開發(fā)節(jié)奏必然都是不對的。

所以方向應(yīng)該是需要像 Web 技術(shù)那樣，有一份隨時可更新的資源包放在云端，通過下載到本地，動態(tài)執(zhí)行后即可渲染出界面。

如果用純 Web 技術(shù)來渲染小程序，在一些有復(fù)雜交互的頁面上可能會面臨一些性能問題。

這是因為在 Web 技術(shù)中，UI 渲染跟 JavaScript 的腳本執(zhí)行都在一個單線程中執(zhí)行，這就容易導(dǎo)致一些邏輯任務(wù)搶占 UI 渲染的資源。

總地看來，小程序選擇了 Hybrid 的渲染方式，可以用一種近似 Web 的方式來開發(fā)，并且還可以實(shí)現(xiàn)在線更新代碼。同時，引入原生組件有以下好處：

• 擴(kuò)展 Web 的能力。比如像輸入框組件（input, textarea）有更好地控制鍵盤的能力
• 體驗更好，同時也減輕 WebView 的渲染工作
• 繞過 setData、數(shù)據(jù)通信和重渲染流程，使渲染性能更好

現(xiàn)在，我們還剩下一個很重要的問題：管控性和安全性。于是，雙線程的設(shè)計被提出來了。

雙線程的小程序

也不知道是哪位大佬，能想出雙線程這樣的模型，反正我是佩服得 666 的。

雙線程是什么？我們先來看個官方的圖：

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

為什么要這么設(shè)計呢？前面提到的管控和安全，為了解決這些問題，我們需要阻止開發(fā)者使用一些瀏覽器提供的，諸如跳轉(zhuǎn)頁面、操作 DOM、動態(tài)執(zhí)行腳本的開放性接口。

我們可以使用客戶端系統(tǒng)的 JavaScript 引擎，iOS 下的 JavaScriptCore 框架，安卓下騰訊 x5 內(nèi)核提供的 JsCore 環(huán)境。通過提供一個沙箱環(huán)境來運(yùn)行開發(fā)者的 JavaScript 代碼來解決。這個沙箱環(huán)境只提供純 JavaScript 的解釋執(zhí)行環(huán)境，沒有任何瀏覽器相關(guān)接口。

這就是小程序雙線程模型的由來：

• 邏輯層：創(chuàng)建一個單獨(dú)的線程去執(zhí)行 JavaScript，在這個環(huán)境下執(zhí)行的都是有關(guān)小程序業(yè)務(wù)邏輯的代碼
• 渲染層：界面渲染相關(guān)的任務(wù)全都在 WebView 線程里執(zhí)行，通過邏輯層代碼去控制渲染哪些界面。一個小程序存在多個界面，所以渲染層存在多個 WebView 線程

雙線程通信

把開發(fā)者的 JS 邏輯代碼放到單獨(dú)的線程去運(yùn)行，但在 Webview 線程里，開發(fā)者就沒法直接操作 DOM。那要怎么去實(shí)現(xiàn)動態(tài)更改界面呢？

前面我們知道，邏輯層和渲染層的通信會由 Native （微信客戶端）做中轉(zhuǎn)，邏輯層發(fā)送網(wǎng)絡(luò)請求也經(jīng)由 Native 轉(zhuǎn)發(fā)。這是不是意味著，我們可以把 DOM 的更新通過簡單的數(shù)據(jù)通信來實(shí)現(xiàn)呢？

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

在這里我們可以用上，如圖：

1. 在渲染層把 WXML 轉(zhuǎn)化成對應(yīng)的 JS 對象。
2. 在邏輯層發(fā)生數(shù)據(jù)變更的時候，通過宿主環(huán)境提供的 setData 方法把數(shù)據(jù)從邏輯層傳遞到 Native，再轉(zhuǎn)發(fā)到渲染層。
3. 經(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)等一系列框架邏輯

由于小程序的渲染層和邏輯層是兩個線程管理，兩個線程各自注入了基礎(chǔ)庫。小程序的基礎(chǔ)庫不會被打包在某個小程序的代碼包里邊，它會被提前內(nèi)置在微信客戶端。這樣可以：

• 降低業(yè)務(wù)小程序的代碼包大小
• 可以單獨(dú)修復(fù)基礎(chǔ)庫中的 Bug，無需修改到業(yè)務(wù)小程序的代碼包

Exparser 框架

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

1. 基于 Shadow DOM 模型：模型上與 WebComponents 的 ShadowDOM 高度相似，但不依賴瀏覽器的原生支持，也沒有其他依賴庫；實(shí)現(xiàn)時，還針對性地增加了其他 API 以支持小程序組件編程。
2. 可在純 JS 環(huán)境中運(yùn)行：這意味著邏輯層也具有一定的組件樹組織能力。
3. 高效輕量：性能表現(xiàn)好，在組件實(shí)例極多的環(huán)境下表現(xiàn)尤其優(yōu)異，同時代碼尺寸也較小。

結(jié)束語

這節(jié)里大概講了小程序設(shè)計中比較重要的一個模型——雙線程，關(guān)于雙線程的出現(xiàn)、設(shè)計、數(shù)據(jù)通信，到基礎(chǔ)庫、Exparser 框架，都是一個個相關(guān)而又相互影響的選擇。

關(guān)于小程序的底層框架設(shè)計，其實(shí)還涉及更多更多我們未能一時半會掌握完的內(nèi)容，自定義組件、原生組件，還有他們做了很多的性能優(yōu)化工作，都不是只言片語能講完的。我們能做的，就是多去思考。

來源網(wǎng)絡(luò)，侵權(quán)刪除

新聞名稱：小程序運(yùn)行機(jī)制
文章URL：http://jinyejixie.com/news2/99752.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供微信公眾號、虛擬主機(jī)、動態(tài)網(wǎng)站、電子商務(wù)、商城網(wǎng)站、外貿(mào)建站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)