本篇文章為大家?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)容，下面一起來看一下，希望對大家有幫助。

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

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

發(fā)展由來

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

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

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

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

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

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

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

• 快速的載入。

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

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

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

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

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

宿主環(huán)境

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

要注意：

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

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

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

更新機(jī)制

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

const updateManager = wx.getUpdateManager()
updateManager.onCheckForUpdate(function (res) {
  // 請求完新版本信息的回調(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í)行緒的，那就意味著任何在視圖層和邏輯層之間的資料傳遞都是線程間的通信，也就是會有一定的延遲。這不像傳統(tǒng)Web一樣，當(dāng)頁面要更新時呼叫相關(guān)API就能同步渲染出來，在小程式架構(gòu)裡面，這一切成了非同步操作。

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

知道視圖層與邏輯層的具體通訊過程後，我們也稍微了解一下視圖層和邏輯層的資料傳輸大致是如何的，我們知道這兩者通訊是藉助了系統(tǒng)層的作用，而實(shí)際上是透過兩邊提供的evaluateJavascript 所實(shí)現(xiàn)的。也就是使用者傳輸?shù)臄?shù)據(jù)，需要將其轉(zhuǎn)換為字串形式傳遞，同時把轉(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 用來識別 JS 程式碼的方式的就行啦。

登入機(jī)制

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

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

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

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

UnionID 機(jī)制說明

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

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

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

效能問題

透過學(xué)習(xí)了小程式的架構(gòu)原理，我們再來用底層架構(gòu)的眼光來簡單分析一下常見的小程式效能問題是如何產(chǎn)生的。

頻繁地呼叫setData()

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

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

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

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

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

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

JSCore

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

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

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

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

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

#WebKit 由四個部分組成，分別是：

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

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

• WebCore：整個 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)該不會很陌生了，既然它是基於 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)容。更多資訊請關(guān)注PHP中文網(wǎng)其他相關(guān)文章！