今天是學(xué)習(xí)前端的第一天之小程序的雙線程架構(gòu)

微信小程序的誕生

小程序是期望的產(chǎn)物。

在沒有小程序的時候，企業(yè)們都在微信用什么？答案是H5。因?yàn)楣娞枺娞柺切〕绦虻那吧恚獺5也有自己的缺點(diǎn)，無法自己獲取很多底層 APP 擁有的功能。

隨著微信提供一系列的JS-SDK給Web開發(fā)使用，(JS-SDK就是一套調(diào)用微信能力的工具包。比如微信支付等等的微信功能)

WebView 的使用頻率越來越高。而Webview的加載體驗(yàn)相對比較糟糕。

微信作為一個平臺，具有優(yōu)化用戶體驗(yàn)的責(zé)任。微信面臨的問題是如何設(shè)計一個比較好的系統(tǒng)，使得所有開發(fā)者在微信中都能獲得比較好的體驗(yàn)。這個問題是之前的 JS-SDK 所處理不了的，需要一個新的系統(tǒng)來完成。小程序就是在這種期待中誕生的。

一方面，小程序是基于 WebView 開發(fā)的，其目的是減少開發(fā)的成本，實(shí)現(xiàn)異步加載的方式，允許開發(fā)者在線的版本更新和 Bug 修復(fù)，而前面說的使用 Webview 容易導(dǎo)致加載體驗(yàn)不好，小程序使用了雙線程的方式來使頁面渲染和邏輯代碼加載分開，降低頁面卡殼的可能性。

小程序與web開發(fā)的區(qū)別

我們都知道，傳統(tǒng)web的架構(gòu)模型是單線程架構(gòu)，其渲染線程和腳本線程是互斥的，這也就是說為什么長時間的腳本運(yùn)行可能會使頁面失去響應(yīng)，而小程序的架構(gòu)模型有別于傳統(tǒng)web，小程序?yàn)殡p線程架構(gòu)，其渲染線程和腳本線程是分開運(yùn)行的。

傳統(tǒng)web開發(fā)者可以使用各種瀏覽器暴露出來的DOM API來進(jìn)行DOM操作，但由于小程序的邏輯層和渲染層是分開的，邏輯層并沒有一個完整的瀏覽器對象，因而缺少相關(guān)的DOM API和BOM API

傳統(tǒng)web開發(fā)者需要面對的是各式各樣的瀏覽器，PC 端需要面對 IE、Chrome、火狐瀏覽器等，在移動端需要面對Safari、Chrome以及 iOS、Android 系統(tǒng)中的各式 WebView 。而小程序開發(fā)過程中需要面對的是兩大操作系統(tǒng) iOS 和 Android 的微信客戶端，以及用于輔助開發(fā)的小程序開發(fā)者工具。

各平臺的腳本執(zhí)行環(huán)境以及渲染非原生組件的環(huán)境都是各不相同的，如下表所示：

平臺渲染層邏輯層

iOS

JsCore

Android

定制內(nèi)核

小程序開發(fā)者工具

Chrome WebView

NWJS

雙線程架構(gòu)

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

小程序中為了達(dá)到多頁面體驗(yàn)的功能，需要使用到多個WebView，每個WebView對應(yīng)的就是一個小程序的頁面。WebView和JsCore這兩個線程的通信會經(jīng)由微信客戶端（下文中也會采用Native來代指微信客戶端）做中轉(zhuǎn)，線程之間的通訊、數(shù)據(jù)的傳遞以及邏輯層發(fā)送網(wǎng)絡(luò)請求也都是經(jīng)由Native轉(zhuǎn)發(fā)，小程序的通信模型下圖所示。

在這里插入圖片描述

WebView是什么

這里需要解釋一下WebView是什么，WebView直譯是網(wǎng)頁視圖，我們可以簡單地看作一個可以嵌套到界面上的一個瀏覽器控件。

我們通常是用瀏覽器來瀏覽網(wǎng)頁，你很清楚的知道你正在使用瀏覽器，要么是PC客戶端，要么是手機(jī)上的app。但是webview是一個嵌入式的瀏覽器，是嵌入在原生應(yīng)用中的，你可能都意識不到你在用瀏覽器。傳統(tǒng)瀏覽器分為兩個部分，UI(地址欄、導(dǎo)航欄)和瀏覽器引擎。webview就是原生應(yīng)用中的瀏覽器引擎。

簡單來說 webview 是手機(jī)中內(nèi)置了一款高性能 webkit 內(nèi)核瀏覽器，不過沒有提供UI(地址欄、導(dǎo)航欄)，只是單純的展示一個網(wǎng)頁界面。

為什么要多個WebView

接著上文說，那么為什么要用多個WebView呢？多個WebView可以理解為多頁面應(yīng)用，其實(shí)是有區(qū)別于單頁面應(yīng)用SPA的，SPA渲染頁面是通過路由識別以后去動態(tài)地將頁面掛載到root節(jié)點(diǎn)里，如果SPA打開一個新頁面，是需要卸載掉當(dāng)前的頁面，然后重新渲染。很顯然，只有通過多個WebView才能更加接近原生應(yīng)用APP的用戶體驗(yàn)。

管控與安全

微信小程序是什么架構(gòu)_微信小程序架構(gòu)_微信小程序系統(tǒng)架構(gòu)

雙線程架構(gòu)的另一個好處就是安全管控。我們都知道基于web技術(shù)來渲染小程序，是存在一些不可控因素和安全風(fēng)險的。因?yàn)閣eb技術(shù)非常靈活開放，我們可以使用去任意地控制頁面的跳轉(zhuǎn)或者改變頁面上的任何內(nèi)容，還可以通過操作DOM，直接獲取小程序內(nèi)部的一些敏感數(shù)據(jù)，比如用戶信息等等，那么小程序?qū)⒑翢o安全可言。

為了解決安全管控的問題，小程序從設(shè)計上就阻止了開發(fā)者去使用一些瀏覽器提供的開放性api，比如說跳轉(zhuǎn)頁面、操作DOM等等。如果把這些東西一個一個地去加入到黑名單，那么勢必會陷入一個非常糟糕的循環(huán)，因?yàn)闉g覽器的接口也非常豐富，那么就很容易遺漏一些危險的接口，而且就算是禁用掉了所有的接口，也防不住瀏覽器內(nèi)核的下次更新。

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

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

雙線程通信

既然渲染層和邏輯層分別由兩個線程管理，那么二者之間的交互就涉及到線程間的通信過程了。二者通信過程如下圖所示：

在這里插入圖片描述

可以看出，線程的通信是通過Native做中轉(zhuǎn)，具體表現(xiàn)是：

通信原理

上面說到提供了渲染層與Native、Native與邏輯層之間消息通訊的機(jī)制。機(jī)制是機(jī)制，具體的通信手段又是什么呢？

這層通信機(jī)制在iOS和安卓系統(tǒng)的實(shí)現(xiàn)方式并不一樣，iOS是利用了的提供特性，而在安卓則是往WebView的window對象中注入一個原生方法，最終會封裝成這樣一個兼容層。

（在微信開發(fā)者工具中則是使用了進(jìn)行了封裝，詳情見）

微信開發(fā)者工具雙線程通信的設(shè)計

回到上上文中，我們提到線程的通信是通過Native做中轉(zhuǎn)，我們知道Native理論上是微信客戶端，但是對于微信開發(fā)者工具而言，它并不是微信客戶端，沒有Native。那么它是怎么實(shí)現(xiàn)渲染層和邏輯層之間的通信的呢？是的，它是使用來完成線程間通信。

在這里插入圖片描述

微信開發(fā)者工具有一個消息中心底層模塊維持著一個服務(wù)器，小程序邏輯層的WebView和渲染層的WebView通過與開發(fā)者工具底層建立長連，使用的字段來區(qū)分Socket的來源。

// 通過userAgent中獲取開發(fā)者工具WebSocket服務(wù)器監(jiān)聽的端口
const port = window.navigator.userAgent.match(/port\/(\d*)/)[1];
// 通過指定 protocol == 'APPSERVICE' 告知開發(fā)者工具這個鏈接是來自邏輯層
const ws = new WebSocket(`ws://127.0.0.1:${port}`, 'APPSERVICE');
ws.onmessage = (evt) => {
  let msg = JSON.parse(evt.data);
  // 處理來自開發(fā)者工具的信息
}
// 調(diào)用API接口 wx.navigateBack
ws.send(JSON.stringify({
  command: 'APPSERVICE_INVOKE'，
  data: {
     api: 'navigateBack',
     args: {}
  }
}))

前面提到，Native通過分別在渲染層和邏輯層注入來實(shí)現(xiàn)二者與Native的通信，然后Native可以根據(jù)情況進(jìn)行處理或者繼續(xù)向指定線程傳遞消息。為了保持與真實(shí)環(huán)境的一致，微信開發(fā)者工具沒有新增或者刪除的方法，只是在的基礎(chǔ)上進(jìn)行了方法的重構(gòu)。以下是部分源碼：

微信小程序系統(tǒng)架構(gòu)_微信小程序是什么架構(gòu)_微信小程序架構(gòu)

window.WeixinJSBridge = {
  on: c,
  invoke: e,
  publish: t,
  subscribe: o,
}

可以說小程序雙線程通信離不開提供的上面的四個方法，下面淺淺介紹下這四個方法：

主要用來收集小程序開發(fā)者工具觸發(fā)的事件回調(diào)。

當(dāng)小程序開發(fā)者工具要觸發(fā)渲染層的某個動作時，借助服務(wù)向渲染層發(fā)送command: 命令，表示這個命令是來自開發(fā)者工具的，通過來告訴渲染層執(zhí)行什么事件方法。

invoke

在小程序開發(fā)者工具中，以api的方式調(diào)用開發(fā)者工具提供的基礎(chǔ)能力，并提供對應(yīng)api執(zhí)行后的回調(diào)

渲染層統(tǒng)一向服務(wù)發(fā)送command: 的命令，根據(jù)參數(shù)中的api值來確定調(diào)用開發(fā)者工具具體的api方法。

調(diào)用完畢后，服務(wù)向渲染層發(fā)送command: ACK的命令，渲染層根據(jù)此標(biāo)識知道api調(diào)用完畢，然后執(zhí)行對應(yīng)的回調(diào)

publish

主要用來向邏輯層發(fā)送信息，也就是說要調(diào)用邏輯層的事件方法

該過程涉及到雙線程的通信，渲染層通過服務(wù)觸發(fā)邏輯層對應(yīng)的事件方法。

需要強(qiáng)調(diào)的是：publish沒有收集執(zhí)行的回調(diào)，只用來通知邏輯層調(diào)用指定的方法，至于執(zhí)不執(zhí)行以及執(zhí)行結(jié)果，渲染層并不關(guān)注。

渲染層統(tǒng)一向服務(wù)發(fā)送command: 的命令，服務(wù)接到命令就向邏輯層轉(zhuǎn)發(fā)消息

邏輯層收到消息后，根據(jù)消息參數(shù)的值確定具體調(diào)用哪一個方法

主要用來收集邏輯層觸發(fā)的事件回調(diào)，和publish配套，就像中的發(fā)布訂閱模式。

渲染層通過注冊事件方法，事件方法是邏輯層在某個時間段通知要執(zhí)行。

渲染層執(zhí)行回調(diào)的時機(jī)是收到來自服務(wù)的command: 命令，通過來確定要執(zhí)行具體什么事件方法

最后

第一天結(jié)束辣！蕪湖！

淺淺介紹了一下小程序的誕生史，比較了小程序開發(fā)與傳統(tǒng)web開發(fā)的區(qū)別，引出了小程序的雙線程架構(gòu)。

中間也多次提到了雙線程機(jī)制的好處，然鵝不得不說的是雖然雙線程機(jī)制相比web技術(shù)對于小程序來說更加安全，性能也有明顯的提升，但也并不是十全十美的。

web技術(shù)可以在線即時更新，而這種雙線程機(jī)制必須將代碼打包提交到微信官方進(jìn)行審核后才能發(fā)布，這也限制了開發(fā)者的自由度。并且JsCore沒有一個完整的瀏覽器對象，無法使用DOM API和BOM API，導(dǎo)致一些我們常用的js庫就失去了用武之地。

這告訴我們：技術(shù)與架構(gòu)本身就沒有好壞之分，每一種技術(shù)的發(fā)布，其目的都在為開發(fā)提供多元化的方式，理性看待，孰優(yōu)孰劣還需要結(jié)合自身的應(yīng)用環(huán)境。

淺淺期待一下學(xué)習(xí)前端的第二天叭(?????)

參考文章：

在線咨詢

上一篇：基于Java的公交查詢系統(tǒng)
下一篇：2023年為小型企業(yè)建立一個網(wǎng)站需要多少錢

您的項(xiàng)目需求

*請認(rèn)真填寫需求信息，我們會在24小時內(nèi)與您取得聯(lián)系。

整合營銷服務(wù)商

今天是學(xué)習(xí)前端的第一天之小程序的雙線程架構(gòu)

您的項(xiàng)目需求