小程序開發者，爲何你應該嘗試下MPX

做者：sky-admin

MPX框架(github.com/didi/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://github.com/didi/mpx