與目前業(yè)內(nèi)的幾個(gè)小程序框架相比較而言，mpx 開(kāi)發(fā)設(shè)計(jì)的出發(fā)點(diǎn)就是基于原生的小程序去做功能增強(qiáng)。所以從開(kāi)發(fā)框架的角度來(lái)說(shuō)，是沒(méi)有任何“包袱”，圍繞著原生小程序這個(gè) core 去做不同功能的 patch 工作，使得開(kāi)發(fā)小程序的體驗(yàn)更好。

于是我挑了一些我非常感興趣的點(diǎn)去學(xué)習(xí)了下 mpx 在相關(guān)功能上的設(shè)計(jì)與實(shí)現(xiàn)。

編譯環(huán)節(jié)

動(dòng)態(tài)入口編譯

不同于 web 規(guī)范，我們都知道小程序每個(gè) page/component 需要被最終在 webview 上渲染出來(lái)的內(nèi)容是需要包含這幾個(gè)獨(dú)立的文件的：js/json/wxml/wxss。為了提升小程序的開(kāi)發(fā)體驗(yàn)，mpx 參考 vue 的 SFC(single file component)的設(shè)計(jì)思路，采用單文件的代碼組織方式進(jìn)行開(kāi)發(fā)。既然采用這種方式去組織代碼的話，那么模板、邏輯代碼、json配置文件、style樣式等都放到了同一個(gè)文件當(dāng)中。那么 mpx 需要做的一個(gè)工作就是如何將 SFC 在代碼編譯后拆分為 js/json/wxml/wxss 以滿足小程序技術(shù)規(guī)范。熟悉 vue 生態(tài)的同學(xué)都知道，vue-loader 里面就做了這樣一個(gè)編譯轉(zhuǎn)化工作。具體有關(guān) vue-loader 的工作流程可以參見(jiàn)我寫(xiě)的文章。

這里會(huì)遇到這樣一個(gè)問(wèn)題，就是在 vue 當(dāng)中，如果你要引入一個(gè)頁(yè)面/組件的話，直接通過(guò)import語(yǔ)法去引入對(duì)應(yīng)的 vue 文件即可。但是在小程序的標(biāo)準(zhǔn)規(guī)范里面，它有自己一套組件系統(tǒng)，即如果你在某個(gè)頁(yè)面/組件里面想要使用另外一個(gè)組件，那么需要在你的 json 配置文件當(dāng)中去聲明usingComponents這個(gè)字段，對(duì)應(yīng)的值為這個(gè)組件的路徑。

在 vue 里面 import 一個(gè) vue 文件，那么這個(gè)文件會(huì)被當(dāng)做一個(gè) dependency 去加入到 webpack 的編譯流程當(dāng)中。但是 mpx 是保持小程序原有的功能，去進(jìn)行功能的增強(qiáng)。因此一個(gè) mpx 文件當(dāng)中如果需要引入其他頁(yè)面/組件，那么就是遵照小程序的組件規(guī)范需要在usingComponents定義好組件名:路徑即可，mpx 提供的 webpack 插件來(lái)完成確定依賴(lài)關(guān)系，同時(shí)將被引入的頁(yè)面/組件加入到編譯構(gòu)建的環(huán)節(jié)當(dāng)中。

接下來(lái)就來(lái)看下具體的實(shí)現(xiàn)，mpx webpack-plugin 暴露出來(lái)的插件上也提供了靜態(tài)方法去使用 loader。這個(gè) loader 的作用和 vue-loader 的作用類(lèi)似，首先就是拿到 mpx 原始的文件后轉(zhuǎn)化一個(gè) js 文本的文件。例如一個(gè) list.mpx 文件里面有關(guān) json 的配置會(huì)被編譯為：

require("!!../../node_modules/@mpxjs/webpack-plugin/lib/extractor?type=json&index=0!../../node_modules/@mpxjs/webpack-plugin/lib/json-compiler/index?root=!../../node_modules/@mpxjs/webpack-plugin/lib/selector?type=json&index=0!./list.mpx")復(fù)制代碼

這樣可以清楚的看到 list.mpx 這個(gè)文件首先 selector(抽離list.mpx當(dāng)中有關(guān) json 的配置，并傳入到 json-compiler 當(dāng)中) --->>> json-compiler(對(duì) json 配置進(jìn)行處理，添加動(dòng)態(tài)入口等) --->>> extractor(利用 child compiler 單獨(dú)生成 json 配置文件)

其中動(dòng)態(tài)添加入口的處理流程是在 json-compiler 當(dāng)中去完成的。例如在你的 page/home.mpx 文件當(dāng)中的json配置中使用了局部組件 components/list.mpx:

在 json-compiler 當(dāng)中：

這里需要解釋說(shuō)明下有關(guān) webpack 提供的 SingleEntryPlugin 插件。這個(gè)插件是 webpack 提供的一個(gè)內(nèi)置插件，當(dāng)這個(gè)插件被掛載到 webpack 的編譯流程的過(guò)程中是，會(huì)綁定compiler.hooks.make.tapAsynchook，當(dāng)這個(gè) hook 觸發(fā)后會(huì)調(diào)用這個(gè)插件上的 SingleEntryPlugin.createDependency 靜態(tài)方法去創(chuàng)建一個(gè)入口依賴(lài)，然后調(diào)用compilation.addEntry將這個(gè)依賴(lài)加入到編譯的流程當(dāng)中，這個(gè)是單入口文件的編譯流程的最開(kāi)始的一個(gè)步驟。

Mpx 正是利用了 webpack 提供的這樣一種能力，在遵照小程序的自定義組件的規(guī)范的前提下，解析 mpx json 配置文件的過(guò)程中，手動(dòng)的調(diào)用 SingleEntryPlugin 相關(guān)的方法去完成動(dòng)態(tài)入口的添加工作。這樣也就串聯(lián)起了所有的 mpx 文件的編譯工作。

Render Function

Render Function 這塊的內(nèi)容我覺(jué)得是 Mpx 設(shè)計(jì)上的一大亮點(diǎn)內(nèi)容。Mpx 引入 Render Function 主要解決的問(wèn)題是性能優(yōu)化方向相關(guān)的，因?yàn)樾〕绦虻募軜?gòu)設(shè)計(jì)，邏輯層和渲染層是2個(gè)獨(dú)立的。

這里直接引用 Mpx 有關(guān) Render Function 對(duì)于性能優(yōu)化相關(guān)開(kāi)發(fā)工作的描述：

作為一個(gè)接管了小程序setData的數(shù)據(jù)響應(yīng)開(kāi)發(fā)框架，我們高度重視Mpx的渲染性能，通過(guò)小程序官方文檔中提到的性能優(yōu)化建議可以得知，setData對(duì)于小程序性能來(lái)說(shuō)是重中之重，setData優(yōu)化的方向主要有兩個(gè)：

盡可能減少setData調(diào)用的頻次

盡可能減少單次setData傳輸?shù)臄?shù)據(jù) 為了實(shí)現(xiàn)以上兩個(gè)優(yōu)化方向，我們做了以下幾項(xiàng)工作：

將組件的靜態(tài)模板編譯為可執(zhí)行的render函數(shù)，通過(guò)render函數(shù)收集模板數(shù)據(jù)依賴(lài)，只有當(dāng)render函數(shù)中的依賴(lài)數(shù)據(jù)發(fā)生變化時(shí)才會(huì)觸發(fā)小程序組件的setData，同時(shí)通過(guò)一個(gè)異步隊(duì)列確保一個(gè)tick中最多只會(huì)進(jìn)行一次setData，這個(gè)機(jī)制和Vue中的render機(jī)制非常類(lèi)似，大大降低了setData的調(diào)用頻次；

將模板編譯render函數(shù)的過(guò)程中，我們還記錄輸出了模板中使用的數(shù)據(jù)路徑，在每次需要setData時(shí)會(huì)根據(jù)這些數(shù)據(jù)路徑與上一次的數(shù)據(jù)進(jìn)行diff，僅將發(fā)生變化的數(shù)據(jù)通過(guò)數(shù)據(jù)路徑的方式進(jìn)行setData，這樣確保了每次setData傳輸?shù)臄?shù)據(jù)量最低，同時(shí)避免了不必要的setData操作，進(jìn)一步降低了setData的頻次。

接下來(lái)我們看下 Mpx 是如何實(shí)現(xiàn) Render Function 的。這里我們從一個(gè)簡(jiǎn)單的 demo 來(lái)說(shuō)起：

.mpx 文件經(jīng)過(guò) loader 編譯轉(zhuǎn)換的過(guò)程中。對(duì)于 template 模塊的處理和 vue 類(lèi)似，首先將 template 轉(zhuǎn)化為 AST，然后再將 AST 轉(zhuǎn)化為 code 的過(guò)程中做相關(guān)轉(zhuǎn)化的工作，最終得到我們需要的 template 模板代碼。

packages/webpack-plugin/lib/template-compiler.js模板處理 loader 當(dāng)中:

在render方法內(nèi)部，創(chuàng)建renderData局部變量，調(diào)用compiler.genNode(ast)方法完成 Render Function 核心代碼的生成工作，最終將這個(gè) renderData 返回。例如在上面給出來(lái)的 demo 實(shí)例當(dāng)中，通過(guò)compiler.genNode(ast)方法最終生成的代碼為：

mpx 文件當(dāng)中的 template 模塊被初步處理成上面的代碼后，可以看到這是一段可執(zhí)行的js代碼。那么這段 js 代碼到底是用作何處呢？可以看到compiler.genNode方法是被包裹至bindThis方法當(dāng)中的。即這段 js 代碼還會(huì)被bindThis方法做進(jìn)一步的處理。打開(kāi) bind-this.js 文件可以看到內(nèi)部的實(shí)現(xiàn)其實(shí)就是一個(gè) babel 的 transform plugin。在處理上面這段 js 代碼的 AST 的過(guò)程中，通過(guò)這個(gè)插件對(duì) js 代碼做進(jìn)一步的處理。

bindThis 方法對(duì)于 js 代碼的轉(zhuǎn)化規(guī)則就是：

• 一個(gè)變量的訪問(wèn)形式，改造成 this.xxx 的形式；
• 對(duì)象屬性的訪問(wèn)形式，改造成 this.__get(object, property) 的形式(this.__get方法為運(yùn)行時(shí) mpx runtime 提供的方法)

這里的 this 為 mpx 構(gòu)造的一個(gè)代理對(duì)象，在你業(yè)務(wù)代碼當(dāng)中調(diào)用 createComponent/createPage 方法傳入的配置項(xiàng)，例如 data，都會(huì)通過(guò)這個(gè)代理對(duì)象轉(zhuǎn)化為響應(yīng)式的數(shù)據(jù)。

需要注意的是不管哪種數(shù)據(jù)形式的改造，最終需要達(dá)到的效果就是確保在 Render Function 執(zhí)行的過(guò)程當(dāng)中，這些被模板使用到的數(shù)據(jù)能被正常的訪問(wèn)到，在訪問(wèn)的階段中，這些被訪問(wèn)到的數(shù)據(jù)即被加入到 mpx 構(gòu)建的整個(gè)響應(yīng)式的系統(tǒng)當(dāng)中。

只要在 template 當(dāng)中使用到的 data 數(shù)據(jù)(包括衍生的 computed 數(shù)據(jù))，最終都會(huì)被 renderData 所記錄，而記錄的數(shù)據(jù)形式是例如：

以上就是 mpx 生成 Render Function 的整個(gè)過(guò)程?？偨Y(jié)下 Render Function 所做的工作：

• 執(zhí)行 render 函數(shù)，將渲染模板使用到的數(shù)據(jù)加入到響應(yīng)式的系統(tǒng)當(dāng)中；
• 返回 renderData 用以接下來(lái)的數(shù)據(jù) diff 以及調(diào)用小程序的 setData 方法來(lái)完成視圖的更新

Wxs Module

Wxs 是小程序自己推出的一套腳本語(yǔ)言。官方文檔給出的示例，wxs 模塊必須要聲明式的被 wxml 引用。和 js 在 jsCore 當(dāng)中去運(yùn)行不同的是 wxs 是在渲染線程當(dāng)中去運(yùn)行的。因此 wxs 的執(zhí)行便少了一次從 jsCore 執(zhí)行的線程和渲染線程的通訊，從這個(gè)角度來(lái)說(shuō)是對(duì)代碼執(zhí)行效率和性能上的比較大的一個(gè)優(yōu)化手段。

有關(guān)官方提到的有關(guān) wxs 的運(yùn)行效率的問(wèn)題還有待論證：

“在 android 設(shè)備中，小程序里的 wxs 與 js 運(yùn)行效率無(wú)差異，而在 ios 設(shè)備中，小程序里的 wxs 會(huì)比 js 快 2~20倍?！?/p>

因?yàn)閙px 是對(duì)小程序做漸進(jìn)增強(qiáng)，因此 wxs 的使用方式和原生的小程序保持一致。在你的.mpx文件當(dāng)中的 template block 內(nèi)通過(guò)路徑直接去引入 wxs 模塊即可使用：

在template模塊經(jīng)過(guò)template-compiler 處理的過(guò)程中。模板編譯器 compiler 在解析模板的 AST 過(guò)程中會(huì)針對(duì) wxs 標(biāo)簽緩存一份 wxs 模塊的映射表：

當(dāng) compiler 對(duì) template 模板解析完后，template-compiler 接下來(lái)就開(kāi)始處理 wxs 模塊相關(guān)的內(nèi)容：

template/script/style/json 模塊單文件的生成：

不同于 Vue 借助 webpack 是將 Vue 單文件最終打包成單獨(dú)的 js chunk 文件。而小程序的規(guī)范是每個(gè)頁(yè)面/組件需要對(duì)應(yīng)的 wxml/js/wxss/json 4個(gè)文件。因?yàn)?mpx 使用單文件的方式去組織代碼，所以在編譯環(huán)節(jié)所需要做的工作之一就是將 mpx 單文件當(dāng)中不同 block 的內(nèi)容拆解到對(duì)應(yīng)文件類(lèi)型當(dāng)中。在動(dòng)態(tài)入口編譯的小節(jié)里面我們了解到 mpx 會(huì)分析每個(gè) mpx 文件的引用依賴(lài)，從而去給這個(gè)文件創(chuàng)建一個(gè) entry 依賴(lài)(SingleEntryPlugin)并加入到 webpack 的編譯流程當(dāng)中。

接下來(lái)可以看下 styles/json/template 這3個(gè) block 的處理流程是什么樣。

首先來(lái)看下 json block 的處理流程：list.mpx -> json-compiler -> extractor。第一個(gè)階段 list.mpx 文件經(jīng)由 json-compiler 的處理流程在前面的章節(jié)已經(jīng)講過(guò)，主要就是分析依賴(lài)增加動(dòng)態(tài)入口的編譯過(guò)程。當(dāng)所有的依賴(lài)分析完后，調(diào)用 json-compiler loader 的異步回調(diào)函數(shù)：

這里我們可以看到經(jīng)由 json-compiler 處理后，通過(guò)nativeCallback方法傳入下一個(gè) loader 的文本內(nèi)容形如：

即這段文本內(nèi)容會(huì)傳遞到下一個(gè) loader 內(nèi)部進(jìn)行處理，即 extractor。接下來(lái)我們來(lái)看下 extractor 里面主要是實(shí)現(xiàn)了哪些功能：

稍微總結(jié)下上面的處理流程：

構(gòu)建一個(gè)以當(dāng)前模塊路徑及 content-loader 的 resource 路徑

以這個(gè) resource 路徑作為入口模塊，創(chuàng)建一個(gè) childCompiler

childCompiler 啟動(dòng)后，創(chuàng)建 loaderContext 的過(guò)程中，將 content 文本內(nèi)容掛載至 loaderContext.mpx 上，這樣在 content-loader 在處理入口模塊的時(shí)候僅僅就是取出這個(gè) content 文本內(nèi)容并返回。實(shí)際上這個(gè)入口模塊經(jīng)過(guò) loader 的過(guò)程不會(huì)做任何的處理工作，僅僅是將父 compilation 傳入的 content 返回出去。

loader 處理模塊的環(huán)節(jié)結(jié)束后，進(jìn)入到 module.build 階段，這個(gè)階段對(duì) content 內(nèi)容沒(méi)有太多的處理

createAssets 階段，輸出 chunk。

將輸出的 chunk 構(gòu)建為一個(gè)原生的 node.js 模塊并執(zhí)行，獲取從這個(gè) chunk 導(dǎo)出的內(nèi)容。也就是模塊通過(guò)module.exports導(dǎo)出的內(nèi)容。

所以上面的示例 demo 最終會(huì)輸出一個(gè) json 文件，里面包含的內(nèi)容即為：

以上幾個(gè)章節(jié)主要是分析了幾個(gè) Mpx 在編譯構(gòu)建環(huán)節(jié)所做的工作。接下來(lái)我們來(lái)看下 Mpx 在運(yùn)行時(shí)環(huán)節(jié)做了哪些工作。

響應(yīng)式系統(tǒng)

小程序也是通過(guò)數(shù)據(jù)去驅(qū)動(dòng)視圖的渲染，需要手動(dòng)的調(diào)用setData去完成這樣一個(gè)動(dòng)作。同時(shí)小程序的視圖層也提供了用戶交互的響應(yīng)事件系統(tǒng)，在 js 代碼中可以去注冊(cè)相關(guān)的事件回調(diào)并在回調(diào)中去更改相關(guān)數(shù)據(jù)的值。Mpx 使用 Mobx 作為響應(yīng)式數(shù)據(jù)工具并引入到小程序當(dāng)中，使得小程序也有一套完成的響應(yīng)式的系統(tǒng)，讓小程序的開(kāi)發(fā)有了更好的體驗(yàn)。

還是從組件的角度開(kāi)始分析 mpx 的整個(gè)響應(yīng)式的系統(tǒng)。每次通過(guò)createComponent方法去創(chuàng)建一個(gè)新的組件，這個(gè)方法將原生的小程序創(chuàng)造組件的方法Component做了一層代理，例如在 attched 的生命周期鉤子函數(shù)內(nèi)部會(huì)注入一個(gè) mixin：

在這個(gè)方法內(nèi)部首先調(diào)用transformApiForProxy方法對(duì)組件實(shí)例上下文this做一層代理工作，在 context 上下文上去重置小程序的 setData 方法，同時(shí)拓展 context 相關(guān)的屬性內(nèi)容：

接下來(lái)實(shí)例化一個(gè) mpxProxy 實(shí)例并掛載至 context 上下文的 $mpxProxy 屬性上，并調(diào)用 mpxProxy 的 created 方法完成這個(gè)代理對(duì)象的初始化的工作。在 created 方法內(nèi)部主要是完成了以下的幾個(gè)工作：

• initApi，在組件實(shí)例this上掛載$watch,$forceUpdate,$updated,$nextTick等方法，這樣在你的業(yè)務(wù)代碼當(dāng)中即可直接訪問(wèn)實(shí)例上部署好的這些方法；
• initData
• initComputed，將 computed 計(jì)算屬性字段全部代理至組件實(shí)例 this 上；
• 通過(guò) Mobx observable 方法將 data 數(shù)據(jù)轉(zhuǎn)化為響應(yīng)式的數(shù)據(jù)；
• initWatch，初始化所有的 watcher 實(shí)例；
• initRender，初始化一個(gè) renderWatcher 實(shí)例；

這里我們具體的來(lái)看下 initRender 方法內(nèi)部是如何進(jìn)行工作的：

在 initRender 方法內(nèi)部非常清楚的看到，首先判斷這個(gè) page/component 是否具有 renderFunction，如果有的話那么就直接實(shí)例化一個(gè) renderWatcher：

Watcher 觀察者核心實(shí)現(xiàn)的工作流程就是：

構(gòu)建一個(gè) Reaction 實(shí)例；

調(diào)用 getValue 方法，即 reaction.track，在這個(gè)方法內(nèi)部執(zhí)行過(guò)程中會(huì)調(diào)用 renderFunction，這樣在 renderFunction 方法的執(zhí)行過(guò)程中便會(huì)訪問(wèn)到渲染所需要的響應(yīng)式的數(shù)據(jù)并完成依賴(lài)收集；

根據(jù) immediateAsync 配置來(lái)決定回調(diào)是放到下一幀還是立即執(zhí)行；

當(dāng)響應(yīng)式數(shù)據(jù)發(fā)生變化的時(shí)候，執(zhí)行 reaction 實(shí)例當(dāng)中的回調(diào)函數(shù)，即this.update()方法來(lái)完成頁(yè)面的重新渲染。

mpx 在構(gòu)建這個(gè)響應(yīng)式的系統(tǒng)當(dāng)中，主要有2個(gè)大的環(huán)節(jié)：其一為在構(gòu)建編譯的過(guò)程中，將 template 模塊轉(zhuǎn)化為 renderFunction，提供了渲染模板時(shí)所需響應(yīng)式數(shù)據(jù)的訪問(wèn)機(jī)制，并將 renderFunction 注入到運(yùn)行時(shí)代碼當(dāng)中。

其二就是在運(yùn)行環(huán)節(jié)，mpx 通過(guò)構(gòu)建一個(gè)小程序?qū)嵗拇韺?duì)象，將小程序?qū)嵗系臄?shù)據(jù)訪問(wèn)全部代理至 MPXProxy 實(shí)例上，而 MPXProxy 實(shí)例即 mpx 基于 Mobx 去構(gòu)建的一套響應(yīng)式數(shù)據(jù)對(duì)象，首先將 data 數(shù)據(jù)轉(zhuǎn)化為響應(yīng)式數(shù)據(jù)，其次提供了 computed 計(jì)算屬性，watch 方法等一系列增強(qiáng)的拓展屬性/方法，雖然在你的業(yè)務(wù)代碼當(dāng)中 page/component 實(shí)例 this 都是小程序提供的，但是最終經(jīng)過(guò)代理機(jī)制，實(shí)際上訪問(wèn)的是 MPXProxy 所提供的增強(qiáng)功能，所以 mpx 也是通過(guò)這樣一個(gè)代理對(duì)象去接管了小程序的實(shí)例。

需要特別指出的是，mpx 將小程序官方提供的 setData 方法同樣收斂至內(nèi)部，這也是響應(yīng)式系統(tǒng)提供的基礎(chǔ)能力，即開(kāi)發(fā)者只需要關(guān)注業(yè)務(wù)開(kāi)發(fā)，而有關(guān)小程序渲染運(yùn)行在 mpx 內(nèi)部去幫你完成。

性能優(yōu)化

由于小程序的雙線程的架構(gòu)設(shè)計(jì)，邏輯層和視圖層之間需要橋接 native bridge。如果要完成視圖層的更新，那么邏輯層需要調(diào)用 setData 方法，數(shù)據(jù)經(jīng)由 native bridge，再到渲染層，這個(gè)工程流程為：

小程序邏輯層調(diào)用宿主環(huán)境的 setData 方法；

邏輯層執(zhí)行 JSON.stringify 將待傳輸數(shù)據(jù)轉(zhuǎn)換成字符串并拼接到特定的JS腳本，并通過(guò)evaluateJavascript 執(zhí)行腳本將數(shù)據(jù)傳輸?shù)戒秩緦?#xff1b;

渲染層接收到后， WebView JS 線程會(huì)對(duì)腳本進(jìn)行編譯，得到待更新數(shù)據(jù)后進(jìn)入渲染隊(duì)列等待 WebView 線程空閑時(shí)進(jìn)行頁(yè)面渲染；

WebView 線程開(kāi)始執(zhí)行渲染時(shí)，待更新數(shù)據(jù)會(huì)合并到視圖層保留的原始 data 數(shù)據(jù)，并將新數(shù)據(jù)套用在WXML片段中得到新的虛擬節(jié)點(diǎn)樹(shù)。經(jīng)過(guò)新虛擬節(jié)點(diǎn)樹(shù)與當(dāng)前節(jié)點(diǎn)樹(shù)的 diff 對(duì)比，將差異部分更新到UI視圖。同時(shí)，將新的節(jié)點(diǎn)樹(shù)替換舊節(jié)點(diǎn)樹(shù)，用于下一次重渲染。

而 setData 作為邏輯層和視圖層之間通訊的核心接口，那么對(duì)于這個(gè)接口的使用遵照一些準(zhǔn)則將有助于性能方面的提升。

盡可能的減少 setData 傳輸?shù)臄?shù)據(jù)

Mpx 在這個(gè)方面所做的工作之一就是基于數(shù)據(jù)路徑的 diff。這也是官方所推薦的 setData 的方式。每次響應(yīng)式數(shù)據(jù)發(fā)生了變化，調(diào)用 setData 方法的時(shí)候確保傳遞的數(shù)據(jù)都為 diff 過(guò)后的最小數(shù)據(jù)集，這樣來(lái)減少 setData 傳輸?shù)臄?shù)據(jù)。

接下來(lái)我們就來(lái)看下這個(gè)優(yōu)化手段的具體實(shí)現(xiàn)思路，首先還是從一個(gè)簡(jiǎn)單的 demo 來(lái)看：

在示例 demo 當(dāng)中，聲明了一個(gè) obj 對(duì)象(這個(gè)對(duì)象里面的內(nèi)容在模塊當(dāng)中被使用到了)。然后經(jīng)過(guò) 200ms 后，手動(dòng)修改 obj.a 的值，因?yàn)閷?duì)于 c 字段來(lái)說(shuō)它的值沒(méi)有發(fā)生改變，而 d 字段發(fā)生了改變。因此在 setData 方法當(dāng)中也應(yīng)該只更新 obj.a.d 的值，即：

因?yàn)?mpx 是整體接管了小程序當(dāng)中有關(guān)調(diào)用 setData 方法并驅(qū)動(dòng)視圖更新的機(jī)制。所以當(dāng)你在改變某些數(shù)據(jù)的時(shí)候，mpx 會(huì)幫你完成數(shù)據(jù)的 diff 工作，以保證每次調(diào)用 setData 方法時(shí)，傳入的是最小的更新數(shù)據(jù)集。

這里也簡(jiǎn)單的分析下 mpx 是如何去實(shí)現(xiàn)這樣的功能的。在上文的編譯構(gòu)建階段有分析到 mpx 生成的 Render Function，這個(gè) Render Function 每次執(zhí)行的時(shí)候會(huì)返回一個(gè) renderData，而這個(gè) renderData 即用以接下來(lái)進(jìn)行 setData 驅(qū)動(dòng)視圖渲染的原始數(shù)據(jù)。renderData 的數(shù)據(jù)組織形式是模板當(dāng)中使用到的數(shù)據(jù)路徑作為 key 鍵值，對(duì)應(yīng)的值使用一個(gè)數(shù)組組織，數(shù)組第一項(xiàng)為數(shù)據(jù)的訪問(wèn)路徑(可獲取到對(duì)應(yīng)渲染數(shù)據(jù))，第二項(xiàng)為數(shù)據(jù)路徑的第一個(gè)鍵值，例如在 demo 示例當(dāng)中的 renderData 數(shù)據(jù)如下：

當(dāng)頁(yè)面第一次渲染，或者是響應(yīng)式輸出發(fā)生變化的時(shí)候，Render Function 都會(huì)被執(zhí)行一次用以獲取最新的 renderData 來(lái)進(jìn)行接下來(lái)的頁(yè)面渲染過(guò)程。

其中在 processRenderData 方法內(nèi)部調(diào)用了 diffAndCloneA 方法去完成數(shù)據(jù)的 diff 工作。在這個(gè)方法內(nèi)部判斷新、舊值是否發(fā)生變化，返回的 diff 字段即表示是否發(fā)生了變化，clone 為 diffAndCloneA 接受到的第一個(gè)數(shù)據(jù)的深拷貝值。

這里大致的描述下相關(guān)流程：

• 響應(yīng)式的數(shù)據(jù)發(fā)生了變化，觸發(fā) Render Function 重新執(zhí)行，獲取最新的 renderData；
• renderData 的預(yù)處理，主要是用以剔除通過(guò)路徑訪問(wèn)時(shí)同時(shí)有父、子路徑情況下的子路徑的 key；
• 判斷是否存在 miniRenderData 最小數(shù)據(jù)渲染集，如果沒(méi)有那么 Mpx 完成 miniRenderData 最小渲染數(shù)據(jù)集的收集，如果有那么使用處理后的 renderData 和 miniRenderData 進(jìn)行數(shù)據(jù)的 diff 工作(diffAndCloneA)，并更新最新的 miniRenderData 的值；
• 調(diào)用 doRender 方法，進(jìn)入到 setData 階段

盡可能的減少 setData 的調(diào)用頻次

每次調(diào)用 setData 方法都會(huì)完成一次從邏輯層 -> native bridge -> 視圖層的通訊，并完成頁(yè)面的更新。因此頻繁的調(diào)用 setData 方法勢(shì)必也會(huì)造成視圖的多次渲染，用戶的交互受阻。

所以對(duì)于 setData 方法另外一個(gè)優(yōu)化角度就是盡可能的減少 setData 的調(diào)用頻次，將多個(gè)同步的 setData 操作合并到一次調(diào)用當(dāng)中。接下來(lái)就來(lái)看下 mpx 在這方面是如何做優(yōu)化的。

還是先來(lái)看一個(gè)簡(jiǎn)單的 demo:

在示例 demo 當(dāng)中，msg 和 obj 都作為模板依賴(lài)的數(shù)據(jù)，這個(gè)組件開(kāi)始展示后的 200ms，更新 obj.a 的值，同時(shí) obj 被 watch，當(dāng) obj 發(fā)生改變后，更新 msg 的值。這里的邏輯處理順序是：

obj.a 變化 -> 將 renderWatch 加入到執(zhí)行隊(duì)列 -> 觸發(fā) obj watch -> 將 obj watch 加入到執(zhí)行隊(duì)列 -> 將執(zhí)行隊(duì)列放到下一幀執(zhí)行 -> 按照 watch id 從小到大依次執(zhí)行 watch.run -> setData 方法調(diào)用一次(即 renderWatch 回調(diào))，統(tǒng)一更新 obj.a 及 msg -> 視圖重新渲染復(fù)制代碼

接下來(lái)就來(lái)具體看下這個(gè)流程：由于 obj 作為模板渲染的依賴(lài)數(shù)據(jù)，自然會(huì)被這個(gè)組件的 renderWatch 作為依賴(lài)而被收集。當(dāng) obj 的值發(fā)生變化后，首先觸發(fā) reaction 的回調(diào)，即 this.update() 方法，如果是個(gè)同步的 watch，那么立即調(diào)用 this.run() 方法，即 watcher 監(jiān)聽(tīng)的回調(diào)方法，否則就通過(guò) queueWatcher(this) 方法將這個(gè) watcher 加入到執(zhí)行隊(duì)列：

而在 queueWatcher 方法中，lockTask 維護(hù)了一個(gè)異步鎖，即將 flushQueue 當(dāng)成微任務(wù)統(tǒng)一放到下一幀去執(zhí)行。所以在 flushQueue 開(kāi)始執(zhí)行之前，還會(huì)有同步的代碼將 watcher 加入到執(zhí)行隊(duì)列當(dāng)中，當(dāng) flushQueue 開(kāi)始執(zhí)行的時(shí)候，依照 watcher.id 升序依次執(zhí)行，這樣去確保 renderWatcher 在執(zhí)行前，其他所有的 watcher 回調(diào)都執(zhí)行完了，即執(zhí)行 renderWatcher 的回調(diào)的時(shí)候獲取到的 renderData 都是最新的，然后再去進(jìn)行 setData 的操作，完成頁(yè)面的更新。

總結(jié)

以上是生活随笔為你收集整理的axure 小程序 lib_详细揭秘微信小程序框架技术——Mpx的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。