本篇文章為大家?guī)砹岁P(guān)於微信小程式的相關(guān)問題，其中主要介紹了關(guān)於基礎(chǔ)架構(gòu)原理的相關(guān)內(nèi)容，其中包括了宿主環(huán)境、執(zhí)行環(huán)境、小程式整體架構(gòu)、運(yùn)作機(jī)制、更新機(jī)制、數(shù)據(jù)通訊機(jī)制等等內(nèi)容，下面一起來看一下，希望對(duì)大家有幫助。

【相關(guān)學(xué)習(xí)推薦：小程式學(xué)習(xí)教學(xué)】

下圖為微信小程式的整體架構(gòu)圖：

發(fā)展由來

我們先來簡(jiǎn)單講講微信小程式的發(fā)展歷，知己知彼方能百戰(zhàn)不殆。微信小程式簡(jiǎn)稱小程式。張小龍於2017年01月09日在微信公開課上宣布正式上線。小程式英文名為 Mini Program，是一種不需要下載安裝即可使用的應(yīng)用，它實(shí)現(xiàn)了應(yīng)用程式「觸手可及」的夢(mèng)想，用戶掃一掃或搜尋即可開啟應(yīng)用程式。

小程式上線以來，一直被稱為便攜版的 APP，關(guān)於兩者之間的區(qū)別，無外乎是小程式相對(duì)輕巧、開發(fā)成本低、開發(fā)週期短、收效快。

小程式並非憑空冒出來的一個(gè)概念，當(dāng)微信中的 WebView 逐漸成為行動(dòng) Web 的一個(gè)重要入口時(shí)，微信就有相關(guān)的 JS API 了。

WebView 是行動(dòng)端（手機(jī)、IPad）提供的運(yùn)行JavaScript 的環(huán)境，是系統(tǒng)渲染W(wǎng)eb 網(wǎng)頁(yè)的一個(gè)控件，可與頁(yè)面JavaScript 交互，實(shí)現(xiàn)APP 與Web 的混合開發(fā)，WebView 渲染W(wǎng)eb 頁(yè)面需要強(qiáng)大的渲染核心支持，這其中Android 與IOS 系統(tǒng)的核心又有所不一樣。

根據(jù)了解，小程式誕生的背景主要推動(dòng)力是由於行動(dòng)網(wǎng)頁(yè)在微信內(nèi)傳播體驗(yàn)不良，能力不強(qiáng)，當(dāng)然我覺得這其中也有原生APP 缺點(diǎn)原因的推動(dòng)，例如每次都要從App Store 或其他應(yīng)用程式市場(chǎng)下載，即使下載了，也佔(zhàn)據(jù)系統(tǒng)很大的空間，如果不常用，被使用者刪掉的可能性也非常大。

我們先拋開原生APP的問題不談，對(duì)於行動(dòng)網(wǎng)頁(yè)在微信內(nèi)傳播體驗(yàn)不良，能力不強(qiáng)的問題，即使後來微信團(tuán)隊(duì)推出了JS-SDK 來解決行動(dòng)網(wǎng)頁(yè)能力不足的問題，但JS-SDK 的模式並沒有解決使用行動(dòng)網(wǎng)頁(yè)遇到的體驗(yàn)不良的問題，這其中的原因大概能概括為這三個(gè)點(diǎn)：白屏問題、頁(yè)面切換的生硬和點(diǎn)擊的遲滯感。

為了解決這些問題，微信團(tuán)隊(duì)面臨的問題是如何設(shè)計(jì)一個(gè)比較好的系統(tǒng)，使得所有開發(fā)者在微信中都能獲得比較好的體驗(yàn)。這個(gè)問題是之前的 JS-SDK 所處理不了的，需要一個(gè)全新的系統(tǒng)來完成，它需要讓所有的開發(fā)者都能做到：

• 快速的載入。

• 更強(qiáng)大的能力。

• 原生的體驗(yàn)。

• 易用且安全的微信資料開放。

• 有效率且簡(jiǎn)單的開發(fā)。

這就是小程式的由來。文件

宿主環(huán)境

微信小程式的宿主環(huán)境為微信客戶端，它是依賴微信客戶端上執(zhí)行的，並且跟小程式 基礎(chǔ)庫(kù) 版本有重大關(guān)聯(lián)關(guān)係。

我們可以把 微信客戶端 以及 小程式基礎(chǔ)庫(kù) 簡(jiǎn)稱為微信小程式的宿主環(huán)境。

微信小程式可以呼叫宿主環(huán)境提供的微信客戶端的能力，可以完成許多普通網(wǎng)頁(yè)無法完成的功能，這使得小程式比普通網(wǎng)頁(yè)擁有更多的能力。小程式會(huì)運(yùn)行在不同版本（不同的微信客戶端 不同基礎(chǔ)庫(kù)）的宿主環(huán)境下，因此針對(duì)各個(gè)版本的宿主環(huán)境做程式上的相容也是在所難免的。

執(zhí)行環(huán)境

小程式的主要開發(fā)語(yǔ)言是Javascript，它與傳統(tǒng)網(wǎng)頁(yè)開發(fā)具有相似性但還是有一定區(qū)別：

• 網(wǎng)頁(yè)開發(fā)，渲染執(zhí)行緒和腳本是互斥的，這也是為什麼長(zhǎng)時(shí)間的腳本運(yùn)行可能會(huì)導(dǎo)致頁(yè)面失去回應(yīng)的原因，本質(zhì)就是我們常說的JS 是單執(zhí)行緒的。

• 小程序，視圖層和邏輯層是分開的，雙執(zhí)行緒同時(shí)運(yùn)行，視圖層的介面使用 WebView 進(jìn)行渲染，邏輯層運(yùn)行在 JSCore 中。

• 網(wǎng)頁(yè)開發(fā)，主要面對(duì)各廠商的瀏覽器，在行動(dòng)端還需要面對(duì) Safari、Chrome 以及 iOS、Android 系統(tǒng)中的各式 WebView。

• 小程序，主要面對(duì)兩大作業(yè)系統(tǒng)IOS和Android的微信客戶端，還有開發(fā)工具、PC端（window）、Mac。開發(fā)時(shí)候要注意的是微信客戶端的版本號(hào)碼和小程式API 支援的基礎(chǔ)函式庫(kù)版本號(hào)。

微信小程式運(yùn)行在多種平臺(tái)上：iOS（iPhone/iPad）微信客戶端、Android 微信客戶端、PC 微信客戶端、Mac 微信客戶端和用於調(diào)試的微信開發(fā)者工具。

各平臺(tái)腳本執(zhí)行環(huán)境以及用於渲染非原生元件的環(huán)境是各不相同的，具體區(qū)別如下：

小程式整體架構(gòu)

透過上面的內(nèi)容，你應(yīng)該大致了解小程式誕生的情況和所處的環(huán)境了，下面我們就來聊聊小程式的整體設(shè)計(jì)架構(gòu)情況。

整個(gè)小程式系統(tǒng)架構(gòu)分成兩個(gè)部分：視圖層(WebView) 和 邏輯層(App Service)，這兩個(gè)部分分別由兩個(gè)獨(dú)立執(zhí)行緒管理。

• 視圖層：也稱為渲染層，渲染層用來渲染頁(yè)面結(jié)構(gòu)，主要由WebView 進(jìn)行渲染，一個(gè)小程式可以存在多個(gè)介面，所以渲染層可能存在很多個(gè)WebView 線程。

• 邏輯層：邏輯層採(cǎi)用 JSCore 執(zhí)行緒執(zhí)行 JS 腳本。邏輯層主要用來邏輯處理、資料請(qǐng)求、介面呼叫等。

視圖層和邏輯層之間的溝通則需要藉助系統(tǒng)層(WeixinJsBridage) 進(jìn)行通信，邏輯層把資料變化通知到視圖層，觸發(fā)視圖層頁(yè)面更新，視圖層把觸發(fā)的事件通知到邏輯層進(jìn)行業(yè)務(wù)邏輯處理。

頁(yè)面渲染大致過程為：我們把專案進(jìn)行編譯會(huì)把WXML 轉(zhuǎn)換成對(duì)應(yīng)的JS 物件（Virtual DOM），在邏輯層發(fā)生資料變化的時(shí)候，我們會(huì)透過setData() 方法把資料從邏輯層傳遞到視圖層，視圖層接收到資料後，會(huì)內(nèi)部進(jìn)行差異對(duì)比，把差異應(yīng)用在原來的Dom 樹上，再正確的渲染出UI 介面，完成頁(yè)面的渲染過程。

透過上面的分析，你是否能理解開頭放置的架構(gòu)圖了

上面的分析也提及到了一個(gè)系統(tǒng)層(WeixinJsBridage)，一般簡(jiǎn)稱為JSBridge，它起到了一個(gè)中間橋樑的作用，非常重要。它不僅讓視圖層與邏輯層兩個(gè)單獨(dú)執(zhí)行緒能進(jìn)行通信，也架起上層開發(fā)與系統(tǒng)底層功能（Native）的橋樑，使得小程式可以透過呼叫API 使用原生功能，且部分元件用原生元件實(shí)現(xiàn)，從而有良好體驗(yàn)。

邏輯層還有一個(gè)重要的操作，發(fā)送網(wǎng)路請(qǐng)求，它也是經(jīng)由 系統(tǒng)層 轉(zhuǎn)送的。

講到這裡，希望你對(duì)小程式的整體架構(gòu)有一定認(rèn)識(shí)了，下面我們就開始講一下小程式內(nèi)部的一些機(jī)制狀況了。

運(yùn)行機(jī)制

小程式啟動(dòng)運(yùn)行兩種情況：

• #冷啟動(dòng)（重新開始）：使用者首次開啟或小程式被微信主動(dòng)銷毀後再次開啟的情況，此時(shí)小程式需要重新載入啟動(dòng)，即為冷啟動(dòng)。

• 熱啟動(dòng)：用戶已經(jīng)打開過小程序，然後在一定時(shí)間內(nèi)再次打開該小程序，此時(shí)無需重新啟動(dòng)，只需要將後臺(tái)態(tài)的小程序切換到前臺(tái)，這個(gè)過程就是熱啟動(dòng)。

要注意：

1.小程式?jīng)]有重新啟動(dòng)的概念。

2.當(dāng)小程式進(jìn)入後臺(tái)，客戶端會(huì)維持一段時(shí)間的運(yùn)作狀態(tài)，超過一定時(shí)間後會(huì)被微信主動(dòng)銷毀。

3.短時(shí)間內(nèi)收到系統(tǒng)兩次以上記憶體警告，也會(huì)對(duì)小程式進(jìn)行銷毀，這也就為什麼一旦頁(yè)面記憶體溢出，頁(yè)面會(huì)奔潰的本質(zhì)原因了。

更新機(jī)制

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

const updateManager = wx.getUpdateManager()
updateManager.onCheckForUpdate(function (res) {
  // 請(qǐng)求完新版本信息的回調(diào)
  console.log(res.hasUpdate)
})
updateManager.onUpdateReady(function () {
  wx.showModal({
    title: '更新提示',
    content: '新版本已經(jīng)準(zhǔn)備好，是否重啟應(yīng)用？',
    success(res) {
      if (res.confirm) {
        // 新的版本已經(jīng)下載好，調(diào)用 applyUpdate 應(yīng)用新版本并重啟
        updateManager.applyUpdate()
      }
    }
  })
})
updateManager.onUpdateFailed(function () {
  // 新版本下載失敗
})

資料通訊機(jī)制

前面我們講過小程式是基於雙執(zhí)行緒的，那就意味著任何在視圖層和邏輯層之間的資料傳遞都是線程間的通信，也就是會(huì)有一定的延遲。這不像傳統(tǒng)Web一樣，當(dāng)頁(yè)面要更新時(shí)呼叫相關(guān)API就能同步渲染出來，在小程式架構(gòu)裡面，這一切成了非同步操作。

非同步會(huì)使得各部分的運(yùn)行時(shí)序變得複雜一些。例如在渲染首屏的時(shí)候，邏輯層與渲染層會(huì)同時(shí)開始初始化工作，但是渲染層需要有邏輯層的資料才能把介面渲染出來，如果渲染層初始化工作較快完成，就要等邏輯層的指令才能進(jìn)行下一步工作。因此邏輯層與渲染層需要有一定的機(jī)制保證時(shí)序正確，在每個(gè)小程式頁(yè)面的生命週期中，存在著若干次頁(yè)面資料通訊。

知道視圖層與邏輯層的具體通訊過程後，我們也稍微了解一下視圖層和邏輯層的資料傳輸大致是如何的，我們知道這兩者通訊是藉助了系統(tǒng)層的作用，而實(shí)際上是透過兩邊提供的evaluateJavascript 所實(shí)現(xiàn)的。也就是使用者傳輸?shù)臄?shù)據(jù)，需要將其轉(zhuǎn)換為字串形式傳遞，同時(shí)把轉(zhuǎn)換後的數(shù)據(jù)內(nèi)容拼接成一份 JS 腳本，再透過執(zhí)行 JS 腳本的形式傳遞到兩邊獨(dú)立環(huán)境。

關(guān)於evaluateJavascript：

Native 呼叫 JS， 一般就是直接 JS 程式碼字串，有點(diǎn)類似我們呼叫 JS 中的 eval 去執(zhí)行一串程式碼。它一般有 loadUrl、evaluateJavascript 等幾種方法。

這裡就不做過多的介紹了，你只要記住，它是用來呼叫執(zhí)行 JS 字串，是一種 Native 用來識(shí)別 JS 程式碼的方式的就行啦。

登入機(jī)制

做過小程式的鐵汁們應(yīng)該對(duì)這張圖不陌生了：

圖中過程主要是為了獲得微信使用者的唯一openid 與session_key，之後開發(fā)者伺服器可以根據(jù)使用者識(shí)別來產(chǎn)生自訂登入態(tài)，用於後續(xù)業(yè)務(wù)邏輯中前後端互動(dòng)時(shí)識(shí)別使用者身分。

• 呼叫 wx.login() 取得暫時(shí)登入憑證 code，並回傳到開發(fā)者伺服器。

• 調(diào)用auth.code2Session 接口，換取用戶唯一標(biāo)識(shí)openid 、用戶在微信開放平臺(tái)帳號(hào)下的唯一標(biāo)識(shí)UnionID（若當(dāng)前小程式已綁定到微信開放平臺(tái)帳號(hào)）和會(huì)話金鑰session_key。

UnionID 機(jī)制說明

UnionID 是微信不久前新增加的一個(gè)性質(zhì)，其獲取方式和openid 差不多，作用也差不多，都是指用戶唯一標(biāo)識(shí)，但它的範(fàn)圍廣一點(diǎn)。

官方解釋：如果開發(fā)者擁有多個(gè)行動(dòng)應(yīng)用程式、網(wǎng)站應(yīng)用程式、和公用帳號(hào)（包括小程式），可透過UnionID 來區(qū)分使用者的唯一性，因?yàn)橹灰峭粋€(gè)微信開放平臺(tái)帳號(hào)下的行動(dòng)應(yīng)用程式、網(wǎng)站應(yīng)用程式和公眾帳號(hào)（包括小程式），使用者的UnionID 是唯一的。換句話說，同一用戶，對(duì)同一個(gè)微信開放平臺(tái)下的不同應(yīng)用，UnionID是相同的。

不明白？說穿了，就是把小程式綁定 微信開放平臺(tái)帳號(hào) 後，可與該帳號(hào)下綁定的的其他行動(dòng)應(yīng)用程式、網(wǎng)站應(yīng)用程式及公眾號(hào)打通。例如：同個(gè)用戶在PC端的掃描登錄、微信公眾號(hào)開發(fā)的頁(yè)面授權(quán)登錄、微信小程式授權(quán)登錄，這些場(chǎng)景中都能辨識(shí)出是同一個(gè)用戶，取得到的 UnionID 相同的。傳送門

效能問題

透過學(xué)習(xí)了小程式的架構(gòu)原理，我們?cè)賮碛玫讓蛹軜?gòu)的眼光來簡(jiǎn)單分析一下常見的小程式效能問題是如何產(chǎn)生的。

頻繁地呼叫setData()

頻繁地呼叫setData()，這個(gè)問題相信已經(jīng)是很常見的，例如在計(jì)時(shí)器中調(diào)用、在監(jiān)聽頁(yè)面滾動(dòng)的鉤子中調(diào)用，這些場(chǎng)景很容易就會(huì)引起小程式的效能問題，容易出現(xiàn)頁(yè)面卡頓、頁(yè)面資料更新不及時(shí)的情況。

前面在資料通訊機(jī)制中我們講過小程式是基於雙線程的，那就意味著任何在視圖層和邏輯層之間的資料傳遞都是線程間的通信，頻繁的去調(diào)用setData()，會(huì)使得執(zhí)行緒之間一直處?kù)睹β禒顟B(tài)，邏輯層通知到視圖層耗時(shí)就會(huì)上升，視圖層收到訊息的時(shí)候可能已經(jīng)距離發(fā)出的時(shí)間超過一定時(shí)間了，渲染頁(yè)面就不夠及時(shí)了。

龐大的資料量去呼叫setData()

#還是在前面的資料通訊機(jī)制中，我們說過傳輸?shù)馁Y料需要轉(zhuǎn)換成轉(zhuǎn)換為字串的形式傳遞，且透過JS 腳本的形式去執(zhí)行，當(dāng)資料量大時(shí)，執(zhí)行腳本的編譯執(zhí)行時(shí)間也會(huì)上漲，佔(zhàn)用執(zhí)行緒。

頁(yè)面複雜繁多的DOM結(jié)構(gòu)

當(dāng)一個(gè)頁(yè)面DOM 結(jié)構(gòu)複雜且非常多的時(shí)候，這必定帶來頁(yè)面顯示不及時(shí)，頁(yè)面卡頓，甚至可能會(huì)出現(xiàn)頁(yè)面奔潰的情況，這其中的原因可想而知，是過於DOM 繪製、計(jì)算都是需要時(shí)間的，這將使得線程過渡的工作，帶來客戶端內(nèi)存佔(zhàn)用上升，從而觸發(fā)系統(tǒng)回收小程式頁(yè)面。

JSCore

上面我提到說，對(duì)「邏輯層運(yùn)行在JSCore 中」 這句話有點(diǎn)疑問，是因?yàn)槲以诳吹奖砀裰辛信e的邏輯層運(yùn)行的環(huán)境應(yīng)該是依照系統(tǒng)環(huán)境區(qū)分的才對(duì)，那這句話是不是就太籠統(tǒng)了？還是說這句話是指 IOS 的情況呢？因?yàn)槭枪俜轿募懙脑捳Z(yǔ)，所以我沒有直接就否決是寫錯(cuò)了，或是單指IOS 的情況。

經(jīng)過一翻查證，證實(shí)其實(shí)這句話是沒有問題的，要追尋結(jié)果的過程，我們需要寫了解一下瀏覽器的大致情況：

瀏覽器中最核心的部分則是瀏覽器內(nèi)核，每個(gè)瀏覽器都有各自的內(nèi)核，而對(duì)行動(dòng)領(lǐng)域影響最深的則當(dāng)屬WebKit。

WebKit 就是一個(gè)頁(yè)面渲染以及邏輯處理引擎，HTML/CSS/JavaScript 經(jīng)過它的處理，成為可見且可操作的Web頁(yè)面。

WebKit 由多個(gè)重要模組組成，整體架構(gòu)如下圖：

#WebKit 由四個(gè)部分組成，分別是：

• WebKit Embedding API：負(fù)責(zé)瀏覽器UI 與WebKit 互動(dòng)的部分。

• Platform API（WebKit Ports）：讓 Webkit 更方便的移植到各個(gè)作業(yè)系統(tǒng)、平臺(tái)上，提供的一些呼叫Native Library的介面。

• WebCore：整個(gè) WebKit 中最核心的渲染引擎。

• JavascriptCore：JSCore 是 WebKit 預(yù)設(shè)內(nèi)嵌的JS引擎，由蘋果使用 C 開發(fā)。

我們來專注於JSCore 部分，JSCore 是WebKit 預(yù)設(shè)內(nèi)嵌的JS引擎，之所以說是預(yù)設(shè)內(nèi)嵌，是因?yàn)樵S多基於WebKit 分支開發(fā)的瀏覽器引擎都開發(fā)了自家的JS引擎，其中最有名的就是Chrome的V8 引擎。

V8 引擎，相信前端的小夥伴應(yīng)該不會(huì)很陌生了，既然它是基於 WebKit 的，那底層預(yù)設(shè)也是內(nèi)嵌 JSCore 的，而 Android 的邏輯層是運(yùn)行在 V8 上的。

而 IOS 的瀏覽器引擎則是 WebKit，內(nèi)部則是 JSCore。

最後開發(fā)工具的邏輯層是運(yùn)行在NW.js, 上它的官網(wǎng)，看到怎麼一段話：

小程式學(xué)習(xí)教學(xué)】

以上是微信小程式架構(gòu)原理基礎(chǔ)詳解的詳細(xì)內(nèi)容。更多資訊請(qǐng)關(guān)注PHP中文網(wǎng)其他相關(guān)文章！