本篇文章帶大家理解一下微信小程序中的雙線程模型，聊聊什么是小程序的雙線程模型？為什么小程序不使用瀏覽器的線程模型，而使用雙線程模型，希望對(duì)大家有所幫助！

有過微信小程序開發(fā)經(jīng)驗(yàn)的朋友應(yīng)該都知道“雙線程模型”這個(gè)概念，本文簡(jiǎn)單梳理一下雙線程模型的一些科普知識(shí)，學(xué)識(shí)淺薄，若有錯(cuò)誤歡迎指正。

我以前就職于「小程序·云開發(fā)」團(tuán)隊(duì)，在對(duì)外的一些培訓(xùn)和技術(shù)分享里經(jīng)常被人問到這樣一個(gè)問題：“微信小程序與 Web 網(wǎng)站在技術(shù)層面的主要區(qū)別是什么？”，在編程語言和范式上，小程序開發(fā)與 Web 前端開發(fā)非常相似（比如都用 JavaScript 語言、與 HTML/CSS 非常相似的 WXML/WXSS 等），可它卻沒有直接用原生的前端技術(shù)?！鞠嚓P(guān)學(xué)習(xí)推薦：小程序開發(fā)教程】

與 Web 網(wǎng)站相比，以微信為宿主的小程序更需要考慮安全、性能等因素，保障小程序不會(huì)對(duì)微信App本身產(chǎn)生安全隱患，同時(shí)要盡量達(dá)到接近原生應(yīng)用的性能和用戶體驗(yàn)。這是為什么小程序不直接用瀏覽器的線程模型，非要自己弄一套雙線程模型最主要的兩個(gè)原因。

那什么是小程序的雙線程模型呢？

理解一個(gè)新概念或技術(shù)的最好的方法就是給它一個(gè)參照物，所以要搞清楚小程序的線程模型，首先要對(duì)瀏覽器的線程模型有一定的了解。

瀏覽器是多進(jìn)程的

可能每個(gè)前端工程師在剛?cè)胄械臅r(shí)候都不止一次地被面試官問到“怎么理解前端的單線程？”，因?yàn)榍岸撕诵募寄苤坏?JavaScript 語言是單線程的，充分理解并掌握J(rèn)S單線程的運(yùn)作方式對(duì)一個(gè)前端工程師來說是最基本的要求。但是很多初學(xué)者容易走入的一個(gè)誤區(qū)：錯(cuò)誤地把 “JavaScript 單線程”理解為“瀏覽器單線程”。

事實(shí)上，瀏覽器內(nèi)部架構(gòu)很復(fù)雜，只不過在處理 GUI 渲染線程和 JavaScript 邏輯腳本線程上用了互斥、阻塞的管理模式，讓一些開發(fā)者產(chǎn)生了誤解。

以 Chrome 瀏覽器為例，點(diǎn)擊右上角的設(shè)置按鈕然后進(jìn)入“更多工具”->“任務(wù)管理器”會(huì)看到這樣的彈窗：

能看到Chrome 開啟了多個(gè)進(jìn)程，包括瀏覽器進(jìn)程、網(wǎng)絡(luò)進(jìn)程、GPU 進(jìn)程等，這些都是通用的進(jìn)程。請(qǐng)注意，上圖里有兩個(gè)標(biāo)簽頁(yè)進(jìn)程，Chrome 為每個(gè)標(biāo)簽頁(yè)開啟了一個(gè)獨(dú)立的渲染進(jìn)程（ Renderer Process ），每個(gè)進(jìn)程之間的資源（ CPU、內(nèi)存等）和行為（ UI、邏輯等）互不共享，所以即便某個(gè)標(biāo)簽頁(yè)崩潰了也不會(huì)影響其他標(biāo)簽頁(yè)。

而在每個(gè)標(biāo)簽頁(yè)進(jìn)程中，瀏覽器會(huì)把不同的工作交給對(duì)應(yīng)的線程，比如 GUI 渲染線程負(fù)責(zé)把 HTML 渲染成可視化的 UI；JavaScript 引擎線程負(fù)責(zé)解析和運(yùn)行 JavaScript 代碼邏輯；定時(shí)觸發(fā)器線程負(fù)責(zé)處理 setTimeout/setInterval 定時(shí)器等。

多說一句，這里有一個(gè)很容易搞混的地方，其實(shí)setTimeout/setInterval 并不是 JavaScript 語言的一部分，而是運(yùn)行時(shí)（最初是瀏覽器，后來 Node.js 也支持）提供的能力。

GUI 渲染線程和 JavaScript 引擎線程是互斥的，JavaScript 在執(zhí)行期間會(huì)阻塞 UI 的渲染，甚至如果腳本執(zhí)行時(shí)間太長(zhǎng)會(huì)由于頁(yè)面長(zhǎng)時(shí)間無響應(yīng)然后崩潰，正是 GUI 渲染線程和 JavaScript 引擎線程之間的這種互斥、阻塞的線程管理方式，讓一部分前端開發(fā)者以為瀏覽器是單線程的。

那為什么 JavaScript 被設(shè)計(jì)成單線程的呢？

JavaScript 祖師爺只用了 10 天就創(chuàng)造了這門語言，最初他的想法只是在瀏覽器中提供一些簡(jiǎn)單的腳本邏輯用來處理用戶交互、DOM 操作等，所以從設(shè)計(jì)上必須遵循兩點(diǎn)：

• 語法簡(jiǎn)單；

• 運(yùn)行機(jī)制簡(jiǎn)單。

在語法上，JavaScript 借鑒了 Java，但是去除了很多復(fù)雜的設(shè)定，比如類型聲明、模塊體系（后來加入）等。

在運(yùn)行機(jī)制上，JavaScript 并沒有像 Java 那樣提供多線程能力，最主要就是為了避免多線程操作 DOM 造成 UI 沖突。比如存在多個(gè)線程同時(shí)操作同一個(gè) DOM，瀏覽器該如何判斷最終的 UI 效果是采用哪個(gè)線程的結(jié)果？這是經(jīng)典的線程安全（也稱為線程同步）問題，在多線程編程領(lǐng)域有很多解決方案，比如加入鎖機(jī)制，但這樣卻又帶來了更多的復(fù)雜性，與 JavaScript 簡(jiǎn)單易用的設(shè)計(jì)初衷相違背。

這同時(shí)也解釋了為什么 GUI 渲染線程與 JavaScript 引擎線程是互斥的：JavaScript 代碼有修改DOM 的權(quán)限。

當(dāng) JavaScript 代碼被執(zhí)行時(shí)，GUI 渲染線程會(huì)被掛起，等待 JavaScript 引擎線程空閑時(shí)再被執(zhí)行，以免在渲染期間被 JavaScript 重復(fù)地修改 DOM 造成不必要的渲染壓力。采用互斥的模式等待 JavaScript 代碼執(zhí)行完畢后，可以保證渲染是最終的執(zhí)行結(jié)果。所以瀏覽器的空閑（Idle）時(shí)長(zhǎng)也成了衡量網(wǎng)站性能的重要指標(biāo)之一，空閑時(shí)長(zhǎng)多代表 JavaScript 邏輯不密集以及 DOM改動(dòng)頻率低，這種情況下瀏覽器可以更快速順暢地響應(yīng)用戶的交互行為，如下圖：

React Fiber就是利用idle時(shí)間進(jìn)行分片任務(wù)處理。

后來，HTML5 引入了 Web Worker，提供多線程執(zhí)行 JavaScript 代碼的能力，但是與其他編程語言不同的是，Worker 線程與主線程并不是平行的，而是一種主從（ Master-Slave）多線程模型。

Worker 內(nèi)的 JavaScript 代碼不能操作 DOM，可以將其理解為線程安全的。要記住這一點(diǎn)，這是后面講小程序雙線程模型一個(gè)重要的基礎(chǔ)。

那么為什么微信小程序不直接使用瀏覽器的線程模型呢？這需要從產(chǎn)品和技術(shù)兩個(gè)角度對(duì)比小程序與 Web 網(wǎng)站的差異。

為什么小程序不使用瀏覽器的線程模型

我剛接觸小程序開發(fā)時(shí)，經(jīng)?！跋訔墶彼?Web 相比閹割弱化的能力、跟 Vue 相比簡(jiǎn)單到過分的語法等。當(dāng)時(shí)，我?guī)缀跤X得小程序就是微信仗著自己龐大的用戶量搞技術(shù)壟斷。

但是，隨著對(duì)技術(shù)和產(chǎn)品的不斷深入理解，我對(duì)小程序的態(tài)度也有了轉(zhuǎn)變，由“嫌棄”變成了敬佩，因?yàn)樵诔浞掷斫饬诵〕绦虻漠a(chǎn)品定位后，我發(fā)現(xiàn)雙線程模型是在小程序這類產(chǎn)品場(chǎng)景下的最優(yōu)解。那小程序是一款什么樣的產(chǎn)品呢？

小程序的宿主是微信，但是小程序版本的迭代是獨(dú)立的，升級(jí)更新不依賴宿主，這一點(diǎn)跟 Web 網(wǎng)站是相同的。也就是說，小程序沿襲了 Web 的某些優(yōu)勢(shì)，但它并不是 Web，目前 Web 相關(guān)的技術(shù)已經(jīng)相當(dāng)全面，能夠承載一些非常龐大的應(yīng)用程序，比如 3D 地圖、游戲等。

而小程序的定位是小而美、用完就走，不追求在微信中實(shí)現(xiàn)全部的 Web 能力，所以和 Web 來比能力上肯定差一些，同時(shí)具備一些微信提供的原生能力，比如原生組件、系統(tǒng)級(jí)別和微信生態(tài)的 API 等等。

另外，“小程序-微信”的關(guān)系跟“網(wǎng)站-瀏覽器”的關(guān)系不同，前者更接近 CodePen、JSFiddler 這類在線編程平臺(tái)（課里簡(jiǎn)稱平臺(tái)）中每個(gè)程序案例（簡(jiǎn)稱案例）與平臺(tái)的關(guān)系。

從技術(shù)的角度上，平臺(tái)最核心的一個(gè)考量點(diǎn)是為案例提供足夠能力的前提下，保證案例的邏輯不會(huì)危及平臺(tái)的安全。想象一下，假如你能夠在 CodePen 上編寫一個(gè)程序來獲取 CodePen 的私密信息，可能第二天 CodePen 就崩潰然后炒掉所有員工。

在這樣的產(chǎn)品基調(diào)下進(jìn)行技術(shù)選型，接下來就是架構(gòu)師和程序員的工作了。

還是以 CodePen 為例，假如讓你來設(shè)計(jì)這樣的編程平臺(tái)，你會(huì)用什么技術(shù)呢？可能你第一個(gè)想到的是用 iframe，因?yàn)榭梢栽?iframe 內(nèi)使用全部 Web 能力。事實(shí)上 CodePen 確實(shí)用 iframe 來呈現(xiàn)程序的效果，但是并不會(huì)把輸入的 JavaScript 代碼完全拷貝到 iframe 內(nèi)運(yùn)行，而是代碼會(huì)經(jīng)過一次編譯流程之后才會(huì)被注入 iframe 內(nèi)。這樣做的出發(fā)點(diǎn)主要是基于安全的考慮，在編譯過程中將一些危險(xiǎn)的代碼剔除；其次這樣做還能在平臺(tái)中支持更多語言，比如typescript。當(dāng)然，還有性能，性能問題是 iframe 老生常談的問題了，我就不多說了。

所以，不僅要使用 iframe，還需要引入額外的 JavaScript 編譯器。CodePen 一定要保證每個(gè)案例的 JavaScript 代碼是線程安全的，最基本的就是要禁止程序操作CodePen 網(wǎng)站的 DOM ，實(shí)現(xiàn)這一點(diǎn)有兩個(gè)方法：

• 一個(gè)是 Web Worker；

• 另一個(gè)是使用 Shadow DOM。

Web Worker 是線程安全的，Worker 內(nèi)的 JavaScript 代碼無法獲取 Window 和 Document 對(duì)象，也就無法操作 DOM。除此之外，由于 Worker 的線程安全特性，Worker 內(nèi)的代碼運(yùn)行過程中不會(huì)阻塞外層的 GUI 渲染線程，兩者可以并行。

Shadow DOM 是 Web Components 規(guī)范的一部分，將 ShadowRoot 的模式設(shè)置為 closed 就可以禁止獲取到 ShadowRoot 節(jié)點(diǎn)，從而也無法操作其內(nèi)部的 DOM。

兩者相比，Shadow DOM 的兼容性比 Web Worker 更差，距大規(guī)模使用的日期還很遙遠(yuǎn)，所以 Web Worker 的方案更現(xiàn)實(shí)一點(diǎn)。

這樣就形成了一個(gè)簡(jiǎn)易的雙線程模型：Worker 線程負(fù)責(zé)計(jì)算，將結(jié)果通過 postMessage 傳遞給主線程，主線程負(fù)責(zé)渲染。

但是這個(gè)模型存在比較嚴(yán)重的性能問題，Web Worker 非常耗費(fèi)資源，除去計(jì)算消耗以外，與主線程的通信過程對(duì)性能的損耗也非常嚴(yán)重。

那有沒有辦法實(shí)現(xiàn)跟 Web Worker 一樣的線程安全，同時(shí)又兼顧性能保證良好的用戶體驗(yàn)?zāi)?？這便是微信小程序采用雙線程模型的主要目的。

安全高效的雙線程模型

雖然前面用了 CodePen 這類編程平臺(tái)做類比，但小程序與 CodePen 的技術(shù)需求并不完全相同，主要區(qū)別在于小程序并不需要支持所有的 HTML 標(biāo)簽，只提供有限的幾類 UI 組件，根據(jù)小程序產(chǎn)品定位，我們可以歸納出小程序的主要技術(shù)需求可以歸納為下面這樣幾點(diǎn)。（任何新技術(shù)或架構(gòu)都是為了解決特定的問題，所以有必要了解小程序的主要技術(shù)需求。）

• 限制 UI 組件類型，只允許聲明指定的幾個(gè)組件

  小程序在聲明組件時(shí)并不是使用原生的 HTML 標(biāo)簽，而是只能夠通過微信提供的幾種內(nèi)置基礎(chǔ)組件，當(dāng)然你也可以自定義組件，但也是通過對(duì)內(nèi)置基礎(chǔ)組件的組合來實(shí)現(xiàn)。

• 保證邏輯線程安全，不允許直接操作 UI 組件

  小程序更新 UI 的方式與 Vue/React 等 MVVM 框架類似，JavaScript 代碼不能直接操作 DOM（僅做類比，事實(shí)上小程序中沒有DOM的概念），而是通過更新狀態(tài)（ setState ）的方式異步更新 UI ，這個(gè)過程中會(huì)用到 VDOM 和高效的 diff 算法（這兩點(diǎn)并不是我們要討論的內(nèi)容，你課下可以自己搜索相關(guān)資料）。

• 能夠在線更新，不依賴微信

  小程序的宿主是微信，如果使用純 Native 實(shí)現(xiàn)，那么小程序的版本更新必須依賴微信，跟微信的代碼一起發(fā)版，這樣肯定是不行的。如果是純 Web 實(shí)現(xiàn)，安全和性能就很難得到保障。

  小程序需要既能夠像 Web 一樣將資源托管在云端，更新獨(dú)立；同時(shí)又能夠保證足夠好的安全性和性能。所以最終小程序采用了一種混合的架構(gòu)模式：使用 Webview 渲染 UI、使用類似Web Worker 的獨(dú)立線程運(yùn)行邏輯，這就是雙線程模型。

• 性能需盡量提升，保證用戶體驗(yàn)

  前面提到的基于 Web Worker 的簡(jiǎn)易雙線程模型性能是很大的問題，小程序的雙線程模型并不是使用 Web Worker 子線程，而是一個(gè)獨(dú)立的“主線程”，這樣能夠保證相對(duì)較好的性能。

渲染線程和邏輯線程

小程序的雙線程指的就是渲染線程和邏輯線程，這兩個(gè)線程分別承擔(dān)UI的渲染和執(zhí)行 JavaScript 代碼的工作。如下圖所示：

渲染線程使用 Webview 進(jìn)行 UI 的渲染呈現(xiàn)。Webview 是一個(gè)完整的類瀏覽器運(yùn)行環(huán)境，本身具備運(yùn)行 JavaScript 的能力，但是小程序并不是將邏輯腳本放到 Webview 中運(yùn)行，而是將邏輯層獨(dú)立為一個(gè)與 Webview 平行的線程，使用客戶端提供的 JavaScript 引擎運(yùn)行代碼，iOS 的JavaScriptCore、安卓是騰訊 X5 內(nèi)核提供的 JsCore 環(huán)境以及 IDE 工具的 nwjs 。

邏輯線程是一個(gè)只能夠運(yùn)行 JavaScript 的沙箱環(huán)境，不提供 DOM 操作相關(guān)的 API，所以不能直接操作 UI，只能夠通過 setData 更新數(shù)據(jù)的方式異步更新 UI。

事件驅(qū)動(dòng)的通信方式

注意上圖渲染線程和邏輯線程之間的通信方式，與 Vue/React 不同的是，小程序的渲染層與邏輯層之間的通信并不是在兩者之間直接傳遞數(shù)據(jù)或事件，而是由 Native 作為中間媒介進(jìn)行轉(zhuǎn)發(fā)。

整個(gè)過程是典型的事件驅(qū)動(dòng)模式：

• 渲染層（也可以稱為視圖層）通過與用戶的交互觸發(fā)特定的事件 event；

• 然后 event 被傳遞給邏輯層；

• 邏輯層繼而通過一系列的邏輯處理、數(shù)據(jù)請(qǐng)求、接口調(diào)用等行為將加工好的數(shù)據(jù) data 傳遞給渲染層；

• 最后渲染層將 data 渲染為可視化的 UI。

這種數(shù)據(jù)驅(qū)動(dòng) UI 的模式是現(xiàn)在前端編程領(lǐng)域較為推崇的編程范式，如果你是一個(gè)超過 5 年開發(fā)經(jīng)驗(yàn)的前端開發(fā)者的話，那么我相信在最初接觸到這種模式的時(shí)候肯定有一些不適應(yīng)，因?yàn)樵诖酥?JavaScript 操作 DOM 幾乎是一種“業(yè)內(nèi)規(guī)則”，甚至有不少針對(duì)前端入門的圖書、博客和教材都是先從 DOM 操作講起，現(xiàn)在看來這些確實(shí)有些不合時(shí)宜了。

而這樣邏輯與渲染分離的線程分工模式一方面能夠保證運(yùn)行在邏輯線程沙箱內(nèi)的 JavaScript 代碼是線程安全的，另一方面由于渲染線程的計(jì)算量非常小從而保證了對(duì)用戶交互行為的快速響應(yīng)，提高了用戶體驗(yàn)。

總的來說，跟瀏覽器的線程模型相比，小程序的雙線程模型解決了或者說規(guī)避了 Web Worker 堪憂的性能同時(shí)又實(shí)現(xiàn)了與 Web Worker 相同的線程安全，從性能和安全兩個(gè)角度實(shí)現(xiàn)了提升?？梢愿爬ǖ卣f，雙線程模式是受限于瀏覽器現(xiàn)有的進(jìn)程和線程管理模式之下，在小程序這一具體場(chǎng)景之內(nèi)的一種改進(jìn)的架構(gòu)方案。

總結(jié)

在我看來，程序員的核心能力和競(jìng)爭(zhēng)力并不是充分了解某種語言或框架的 API ，而是這些語言和框架底層的原理知識(shí)。對(duì)一個(gè)小程序的開發(fā)者來說，在工作中遇到技術(shù)難題時(shí)的解決方案往往是基于底層原理的（甚至更直白一點(diǎn)，當(dāng)你找工作面試時(shí)，沒人會(huì)問你小程序的語法）。

通過了解小程序雙線程模型的背景、設(shè)計(jì)、通信，希望能夠讓大家更深入地理解小程序的底層架構(gòu)，如果在后續(xù)工作中有類似場(chǎng)景的需求也可以作為借鑒。當(dāng)然，了解小程序的雙線程模型并不是唯一的目標(biāo)，這些知識(shí)在一定程度上能對(duì)日常開發(fā)工作產(chǎn)生一些啟示，主要是性能方面：

• 在保證功能的前提下盡量使用結(jié)構(gòu)簡(jiǎn)單的 UI；

• 盡量降低 JavaScript 邏輯的復(fù)雜度；

• 盡量減少 setData 的調(diào)用頻次和攜帶的數(shù)據(jù)體量。

更多編程相關(guān)知識(shí)，請(qǐng)?jiān)L問：編程視頻！！

以上是深入解析小程序中的的雙線程模型的詳細(xì)內(nèi)容。更多信息請(qǐng)關(guān)注PHP中文網(wǎng)其他相關(guān)文章！