MPX 框架是滴滴出行推出的一款專注小程式開發的增強型框架。本篇文章將從使用角度談談 MPX 的優勢與好處。如果嫌內容太長，優勢部分每個小節都有簡單的一句話總結，可以快速閱讀。如果想了解更多設計細節，可以閱讀 前一篇文章 - MPX2.0 釋出。

背景

在小程式逐漸火熱的今天，越來越多的開發者需要進行小程式的開發。原生小程式的開發有諸多不便，開發者又需要在眾多的小程式框架中做出抉擇。

那麼今天，我們要給大家安利一款小程式框架：MPX

優勢

之所以建議開發者們考慮使用 MPX 框架來開發小程式，是因為 MPX 框架具有一些別的框架所沒有的優點。

MPX 立足原生小程式，在保證坑少的同時做了很多能力增強，提供了資料響應、模板增強、效能優化、跨平臺開發等能力，以提升使用者的開發體驗及效率。

接下來會從 原生相容 -> 第三方元件支援 -> 按需構建 -> 跨平臺編譯 -> 能力增強 -> 獨特效能優勢 六個點來逐一講述。

原生相容

MPX 完全相容原生，坑少。漸進接入簡單。

從語法風格上，我們可以看到目前市面上流行的小程式框架基本是基於 web 框架（taro/nanachi - react，uniapp/megalo/mpvue - vue）或者是一套全新（chameleon）/ 半全新（wepy）的標準。

使用了這些框架，你所寫的程式碼，並不是小程式程式碼。而是 react/vue 或者另一套程式碼。而這些程式碼原始碼到小程式程式碼，需要經過一次全面的轉換，這個轉換可能會引入一些未知的問題，產生一些坑。

同時隨著時間，小程式自身會逐步迭代，做出更多的功能特性，提供更好的元件、方法。而一些框架可能會受限於精力或框架節奏，沒有辦法第一時間跟進，甚至框架慢慢疏於維護而無法使用。

而 MPX 選擇的是，全面擁抱原生。

口說無憑，我們來看個典型的 MPX 元件長什麼樣。

乍一看好像和 vue 沒什麼區別，也就多了個 json 塊，template 裡寫的是小程式的標籤。

由於這一塊全是符合微信小程式原生語法，我們是不會做任何轉換的，所以你寫什麼就是什麼。（如果使用了 MPX 的增強特性，還是會進行一些必要的轉換的，後續我們也會出文章詳細解釋 MPX 的增強是如何實現的，相對來說，我們的轉換比較輕量、透明、易理解）

當微信出了新的能力、新的標籤、新的生命週期鉤子，使用 MPX 框架來編寫的小程式只需要直接用起來就行。

所以，使用 MPX 框架，你可以輕易地使用 自定義元件的 relations 來搞定元件間關係，使用 wxs 來更好地構建頁面。

MPX 幾乎支援原生的每一個特性，在 .mpx 檔案裡，模板部分寫的是原生小程式的模板語法，指令碼部分寫的是原生小程式的指令碼語法，json 部分寫的是原生小程式的配置資訊。用 MPX，你才是真的在開發小程式。

目前很多原生小程式開發者可能想嘗試下框架，老專案接入框架，選 MPX 肯定是最簡單的了。口說無憑，我們搞了個 demo 來給大家打個樣：在我們 GitHub 專案中有 examples 資料夾，裡面的 原生專案漸進接入 MPX 示例 。

第三方元件庫

MPX 提供了完備的第三方元件庫支援

上面說了 MPX 對原生的極致相容，能讓你想到什麼？對，就是對第三方元件庫的完美支援。

支援第三方元件庫的重要性大家都知道，所以這個能力大部分框架都支援了。但是支援和完美支援還是有區別的。據簡單觀察，taro/mpvue/uniapp 對於第三方元件庫的支援都是以複製的形式進行的，也就是和微信小程式本來的行為很像。

那麼 MPX 是怎麼支援第三方元件庫的呢，這裡有個 demo：也在我們的 GitHub 裡的 examples 資料夾下，MPX 使用第三方元件庫示例 ，核心程式碼見下圖：

乍一眼看不太出來有什麼特別的？沒用過別的框架引第三方元件，簡單找了找其他框架好像也沒提供相應的 demo，用過的朋友可以自行對比下。

在 MPX 裡使用第三方元件庫，僅需要 *像 web 專案一樣 npm 安裝即可，並不需要複製檔案*。然後在 json 裡直接寫包名就會去 node_modules 下面查找了。再配合 webpack alias 可以做到更簡單、更語義化。

然而這還沒有結束~

細心的朋友會發現，這段示例程式碼中既有 vant 的元件，也有 iview 的元件，如果按照微信的規範，這些元件庫會通過 miniprogram 欄位指定自己的構建檔案生成目錄，開發者工具會把這個目錄完全拷貝到最終釋出的程式碼裡去，我們就會有兩個巨大的元件庫佔據寶貴的空間。

我們當然是希望用多少引多少，而不是一股腦全引進去，對，於是 MPX 提供了按需引用的能力，在下一章按需引用細講。

以及，元件庫目前很少有跨小程式平臺的元件庫啊，如果我用了 vant，支付寶、QQ 裡沒有 vant 怎麼辦？也許這是別的框架不怎麼推薦使用第三方庫的原因，而 MPX 裡，我們幫你把別人的元件庫也轉了，細節看下下章跨小程式平臺

按需引用

通過 webpack 依賴分析收集，使用第三方元件庫或者拆分開發大型專案時 MPX 能保證構建的程式碼全是要用到的程式碼

原生小程式本身的編譯是遍歷專案資料夾裡所有的 JS，包裝成一個 AMD 包，也就是說專案資料夾裡所有的檔案，不論是否被使用，都會佔用包體積並上傳。

同時，原生微信小程式的 npm 支援是基於資料夾複製的，第三方包通過宣告 miniprogram 欄位指定要拷貝的資料夾，不論使用還是未使用的資源（模板 /js/ 樣式 / 圖片），全會被複制到專案資料夾中。

而我們提供了 @mpxjs/webpack-plugin 外掛，藉助 webpack 生態，解析.mpx 檔案的 json 部分或原生的 json 檔案將依賴作為新的入口新增子編譯。基於依賴收集，而不是檔案遍歷。

帶來的好處就是：如果你喜歡 vant 的按鈕，iview 的輸入框，wux 的佈局，歡迎嘗試 MPX，讓你能同時使用多個 UI 框架的同時不用擔心應用的體積過大。

同理，面對一個大型專案，我們可以拆成不同的部分，由不同的團隊完成後發 npm 包，在一個主專案中引入即可，具體內容可以看文件JSON 增強 - packages一節。

收集依賴的細節可以查閱文件編譯構建一節。

跨小程式平臺

MPX 的跨平臺方法能帶著第三方元件庫一起跨小程式平臺，同時提供了充足完善的條件編譯能力。

在 MPX 1.0 時代，MPX 框架是專注提升微信小程式的開發體驗，雖然也提供了支付寶版，但程式碼完全要另寫。

而隨著越來越多的 super app 提供了小程式能力，目前至少有 5 種體系的小程式（微信、支付寶系列、百度系列、頭條系列、QQ），如果每一個平臺都需要維護一份程式碼，工程師人數明顯不夠用了，所以跨小程式平臺的能力也是 MPX 2.0 的主打特性。

我們的跨平臺的方法就是轉換。都是小程式，語法基本一樣，配置、鉤子的差異在 MPX 執行時裡提供了抹平。

而除此之外最大的區別也就是模板上的標籤和指令。所以我們實現了一套轉換的架子，再編寫一份轉換規則，即可完成微信小程式到支付寶、百度、頭條小程式的轉換。

採用這種轉換的模式，非常方便使用者理解我們是如何把微信小程式轉換成支付寶、百度等小程式平臺的。而且只要使用者有需求，可以補齊任一套小程式轉換其他平臺的規則，就可以完成以某個小程式為標準為基礎來編寫小程式程式碼以及進一步轉換成別的平臺的能力。

再結合前面一直在說的我們對原生小程式的支援，就可以撞出一點不一樣的東西，比如，前文提到的第三方元件庫跨小程式平臺。

對，我們能幫你把針對微信編寫的 ui 元件庫在支付寶、百度上執行起來，帶著元件庫一起跨小程式平臺。

那麼一定會有這樣一個問題，就算 MPX 對原生的支援再怎麼牛逼，有的基礎能力只有微信平臺有，別的平臺沒有，MPX 的轉換還能無中生有嗎？

當然不能，其實這個問題對於所有的跨端框架都是一個問題，所以跨端最核心的問題是，如何搞定差異化部分。

MPX 提供了豐富的條件編譯能力，可以以檔案為維度差別構建，可以以程式碼塊為維度，也可以以程式碼維度進行差別構建。

而且 MPX 的差異化構建能力也是完全基於 webpack 實現的，所以上面提到的第三方元件庫如果確實存在轉換不了的地方，比如 vant 的 picker 元件使用內聯 wxs 寫了一個小方法叫 isSimple 在模板裡呼叫了，但是這個方法的寫法在百度小程式的 filter 指令碼（filter 可以理解為百度小程式的 wxs）裡不支援，因為百度的 filter 要求必須匯出一個物件包裹方法。

最好的解決辦法當然是給 vant-weapp 提 pr 幫他們解決一下這個問題，但時間可能會比較慢，所以在 MPX 裡，可以利用 webpack 的 alias 能力：

當嘗試構建百度小程式時，會優先去查詢 pick/index.swan.wxml，再被 alias 到一個 src 下的檔案，自己修改一下第三方包裡有一些小問題的部分即可。

關於跨平臺的條件編譯，更多具體資訊可以查閱我們的官方文件 - 跨平臺條件編譯

能力增強

通過資料響應、編譯時預處理提供了 computed/watch，完備的樣式型別繫結，雙向資料繫結，動態元件等一系列方便開發者更好開發小程式的能力增強

能力增強應該是一個框架提供的最核心最重要的能力了，而 MPX 也確實在這裡下了很大的力氣，提供了多且好用的能力增強，不過受限於此處的篇幅，就只簡單介紹，細節大家還是查閱我們的文件的好。

別的框架由於往往基於 react/vue 的，會給個列表寫明不支援哪些能力，使用者寫的時候習慣使然，往往用了後可能才反應過來哦這個不支援。MPX 則是原生的小程式語法寫著難受時候突然想起 MPX 有這個能力。

列一下 MPX 增強的能力：

• 模板上的增強
  • 樣式類名繫結
  • 內聯事件傳參
  • 動態元件
  • 雙向繫結
  • 節點獲取 ref
• JS 裡的增強
  • 資料響應
  • setData 優化
  • ES6+
• 樣式上的增強
  • 預處理支援
  • rpx 轉換
• JSON 裡的增強
  • packages
  • 分包資源優化

MPX 最顯著的能力是資料響應，它衍生出 computed/watch，以及雙向資料繫結等。這個能力和 Vue 比較像，不同的是在 MPX 裡是由 mobx 提供的資料響應能力。

而同樣是資料響應，我們做了一些不一樣的優化。

效能優勢

通過對模板的解析抽象出訪問的資料以保證在提供了資料響應能力的同時不至於劣化效能。

mpvue/wepy/megalo 等框架也提供了資料響應的能力，但是資料響應在小程式領域有個較大的問題，微信開發指南里明確提到要注意 setData 的呼叫頻次和資料量的大小。

而資料響應最基本的做法就是資料變了就去 set 資料，這會極大劣化小程式的效能表現。

而 MPX 通過對模板進行解析，抽象出對應的 render 函式，在呼叫 setData 傳送資料前執行 render 函式找到真正需要傳送的資料。

效果如圖：

小程式開發者工具的 audits 面板能輔助使用者分析出可能需要優化的點。正如前文所說，MPX 在紅框部分，尤其是紅框裡的第三條，不將模板上未使用的資料傳送到渲染層上做了極大的優化。

只要不出現渲染函式執行失敗（會有 warning 在 console 裡提示，同時兜底邏輯會進行全量 setData 以保證程式仍可正常執行），使用 MPX 開發的小程式就永遠不用擔心傳送了模板未使用的資料。

雖然只是一個小小的 TODO MVC 示例，但是這個優化和應用的規模沒關係，而且同時大家可以嘗試別家的小 demo 對比看看。

這個優化的細節可以看前一篇文章，或者我們的文件MPX 執行機制 - 資料響應與效能優化

總結

與目前市面上的諸多框架相比，MPX 希望以原生小程式為基礎，全面擁抱原生小程式，在原生小程式的基礎上做增強，通過儘可能少的轉換實現儘可能多的能力增強，在提升小程式開發體驗的同時，保證不因轉換或框架的問題產生過多的坑。

MPX 框架的目標使用者是對小程式質量有較高要求的開發者，如果你是原生小程式開發者，或者厭倦瞭解決某些以 web 框架 DSL 語法為基礎的轉換框架造成的坑，歡迎嘗試 MPX 框架。

MPX GitHub 地址：https://gi