无码人妻精一区二区三区,eeuss影院www在线观看,无码精品久久久久久人妻中字,日韩av高清在线看片

Mpx是一款致力于提高小程序開發(fā)體驗(yàn)的增強(qiáng)型小程序框架，通過Mpx，我們能夠以最先進(jìn)的web開發(fā)體驗(yàn)(Vue + Webpack)來開發(fā)生產(chǎn)性能深度優(yōu)化的小程序，Mpx具有以下一些優(yōu)秀特性：

• 數(shù)據(jù)響應(yīng)特性(watch/computed)
• 增強(qiáng)的模板語法(動(dòng)態(tài)組件/樣式綁定/類名綁定/內(nèi)聯(lián)事件函數(shù)/雙向綁定等)
• 深度性能優(yōu)化(原生自定義組件/基于依賴收集和數(shù)據(jù)變化的setData)
• Webpack編譯(npm/循環(huán)依賴/Babel/ESLint/css預(yù)編譯/代碼優(yōu)化等)
• 單文件組件開發(fā)
• 狀態(tài)管理(Vuex規(guī)范/多實(shí)例/可合并)
• 跨團(tuán)隊(duì)合作(packages)
• 邏輯復(fù)用能力(mixins)
• 腳手架支持
• 小程序自身規(guī)范的完全支持
• 支付寶小程序的支持

設(shè)計(jì)思路

目前業(yè)界主流的小程序框架主要有WePY，mpvue和Taro，這三者都是將其他的語法規(guī)范轉(zhuǎn)譯為小程序語法規(guī)范，我們稱其為轉(zhuǎn)譯型框架。不同于上述三者，Mpx是一款基于小程序語法規(guī)范的增強(qiáng)型框架，我們使用Vue中優(yōu)秀的語法特性增強(qiáng)了小程序，而不是讓用戶直接使用vue語法來開發(fā)小程序，之所以采用這種設(shè)計(jì)主要是基于如下考慮：

• 轉(zhuǎn)譯型框架無法支持源框架的所有語法特性(如Vue模板中的動(dòng)態(tài)特性或React中動(dòng)態(tài)生成的jsx)，用戶在使用源框架語法進(jìn)行開發(fā)時(shí)可能會(huì)遇到不可預(yù)期的錯(cuò)誤，具有不確定性
• 小程序本身的技術(shù)規(guī)范在不斷地更新進(jìn)步，許多新的技術(shù)規(guī)范在轉(zhuǎn)譯型框架中無法支持或需要很高的支持成本，而對于增強(qiáng)型框架來說只要新的技術(shù)規(guī)范不與增強(qiáng)特性沖突，就能夠直接支持

技術(shù)實(shí)現(xiàn)

小程序剛推出時(shí)不支持自定義組件，無法進(jìn)行組件化開發(fā)，WePY和mpvue做了一系列的工作來支持了這一關(guān)鍵特性，大大提高了用戶的開發(fā)體驗(yàn)和效率。WePY和mpvue的組件化支持是基于編譯做的組件化封裝，用戶編寫的組件模板會(huì)被編譯為Page中模板的一部分，在組件中定義的數(shù)據(jù)會(huì)被編譯為Page中的數(shù)據(jù)，對組件進(jìn)行數(shù)據(jù)更新也會(huì)基于路徑映射調(diào)用Page.setData。這在當(dāng)時(shí)的技術(shù)條件下是很棒的技術(shù)方案，但該方案在復(fù)雜的小程序應(yīng)用中存在性能問題，原因在于該方案中頁面的數(shù)據(jù)量會(huì)很大，而且每個(gè)組件的局部更新實(shí)際上都會(huì)成為頁面級別的全局更新，在組件較多的頁面中產(chǎn)生很大的性能開銷。

在小程序自定義組件推出后，我們通過性能測試確認(rèn)了小程序自定義組件支持組件級別的局部更新，具有良好的更新性能。由于自定義組件在當(dāng)時(shí)是最新的技術(shù)標(biāo)準(zhǔn)，業(yè)內(nèi)的小程序框架都未支持，而我們在業(yè)務(wù)上又有復(fù)雜小程序的開發(fā)需求，于是我們就基于小程序自定義組件啟動(dòng)了Mpx框架的設(shè)計(jì)與開發(fā)

Page與Component setData性能對照

性能衡量標(biāo)準(zhǔn)說明：
局部更新：文檔中存在1000個(gè)節(jié)點(diǎn)，其中一個(gè)節(jié)點(diǎn)更新1000次的耗時(shí)；
全局更新：文檔中存在5個(gè)節(jié)點(diǎn)，5個(gè)節(jié)點(diǎn)獨(dú)立更新1000次的耗時(shí) 以上數(shù)據(jù)在iphone7微信小程序環(huán)境下測試得出

數(shù)據(jù)響應(yīng)與性能優(yōu)化

數(shù)據(jù)響應(yīng)作為Vue最核心的特性，在我們的日常開發(fā)中被大量使用，能夠極大地提高前端開發(fā)體驗(yàn)和效率，我們在框架設(shè)計(jì)初期最早考慮的就是如何將數(shù)據(jù)響應(yīng)特性加入到小程序開發(fā)中。在數(shù)據(jù)響應(yīng)的實(shí)現(xiàn)上，我們引入了MobX，一個(gè)實(shí)現(xiàn)了純粹數(shù)據(jù)響應(yīng)能力的知名開源項(xiàng)目。借助MobX和mixins，我們在小程序組件創(chuàng)建初期建立了一個(gè)響應(yīng)式數(shù)據(jù)管理系統(tǒng)，該系統(tǒng)觀察著小程序組件中的所有數(shù)據(jù)(data/props/computed)并基于數(shù)據(jù)的變更驅(qū)動(dòng)視圖的渲染(setData)及用戶注冊的watch回調(diào)，實(shí)現(xiàn)了Vue中的數(shù)據(jù)響應(yīng)編程體驗(yàn)。與此同時(shí)，我們基于MobX封裝實(shí)現(xiàn)了一個(gè)Vuex規(guī)范的數(shù)據(jù)管理store，能夠方便地注入組件進(jìn)行全局?jǐn)?shù)據(jù)管理。為了提高跨團(tuán)隊(duì)開發(fā)的體驗(yàn)，我們對store添加了多實(shí)例可合并的特性，不同團(tuán)隊(duì)維護(hù)自己的store，在需要時(shí)能夠合并他人或者公共的store生成新的store實(shí)例，我們認(rèn)為這是一種比Vuex中modules更加靈活便捷的跨團(tuán)隊(duì)數(shù)據(jù)管理模式

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

1. 盡可能減少setData調(diào)用的頻次
2. 盡可能減少單次setData傳輸?shù)臄?shù)據(jù)

為了實(shí)現(xiàn)以上兩個(gè)優(yōu)化方向，我們做了以下幾項(xiàng)工作：

• 將組件的靜態(tài)模板編譯為可執(zhí)行的render函數(shù)，通過render函數(shù)收集模板數(shù)據(jù)依賴，只有當(dāng)render函數(shù)中的依賴數(shù)據(jù)發(fā)生變化時(shí)才會(huì)觸發(fā)小程序組件的setData，同時(shí)通過一個(gè)異步隊(duì)列確保一個(gè)tick中最多只會(huì)進(jìn)行一次setData，這個(gè)機(jī)制和Vue中的render機(jī)制非常類似，大大降低了setData的調(diào)用頻次；
• 將模板編譯render函數(shù)的過程中，我們還記錄輸出了模板中使用的數(shù)據(jù)路徑，在每次需要setData時(shí)會(huì)根據(jù)這些數(shù)據(jù)路徑與上一次的數(shù)據(jù)進(jìn)行diff，僅將發(fā)生變化的數(shù)據(jù)通過數(shù)據(jù)路徑的方式進(jìn)行setData，這樣確保了每次setData傳輸?shù)臄?shù)據(jù)量最低，同時(shí)避免了不必要的setData操作，進(jìn)一步降低了setData的頻次。

基于以上優(yōu)化，我們大大減少了小程序setData的調(diào)用頻次和傳遞數(shù)據(jù)量，與初版Mpx中track全量數(shù)據(jù)的方案相比提示顯著。

Mpx setData優(yōu)化效果

以上數(shù)據(jù)由較復(fù)雜小程序在固定交互流程后統(tǒng)計(jì)得出

Mpx數(shù)據(jù)響應(yīng)機(jī)制流程示意圖

編譯構(gòu)建

我們希望使用目前設(shè)計(jì)最強(qiáng)大、生態(tài)最完善的編譯構(gòu)建工具Webpack來實(shí)現(xiàn)小程序的編譯構(gòu)建，讓用戶得到web開發(fā)中先進(jìn)強(qiáng)大的工程化開發(fā)體驗(yàn)。使用過Webpack的同學(xué)都知道，通常來說Webpack都是將項(xiàng)目中使用到的一系列碎片化模塊打包為一個(gè)或幾個(gè)bundle，而小程序所需要的文件結(jié)構(gòu)是非常離散化的，如何調(diào)解這兩者的矛盾成為了我們最大的難題。一種非常直觀簡單的思路在于遍歷整個(gè)src目錄，將其中的每一個(gè).mpx文件都作為一個(gè)entry加入到Webpack中進(jìn)行處理，這樣做的問題主要有兩個(gè)：

1. src目錄中用不到的.mpx文件也會(huì)被編譯輸出，最終也會(huì)被小程序打包進(jìn)項(xiàng)目包中，無意義地增加了包體積；
2. 對于node_modules下的.mpx文件，我們不認(rèn)為遍歷node_modules是一個(gè)好的選擇。

最終我們采用了一種基于依賴分析和動(dòng)態(tài)添加entry的方式來進(jìn)行實(shí)現(xiàn)，用戶在Webpack配置中只需要配置一個(gè)入口文件app.mpx，loader在解析到j(luò)son時(shí)會(huì)解析json中pages域和usingComponents域中聲明的路徑，通過動(dòng)態(tài)添加entry的方式將這些文件添加到Webpack的構(gòu)建系統(tǒng)當(dāng)中（注意這里是添加entry而不是添加依賴，因?yàn)橹挥衑ntry能生成獨(dú)立的文件，滿足小程序的離散化文件結(jié)構(gòu)），并遞歸執(zhí)行這個(gè)過程，直到整個(gè)項(xiàng)目中所有用到的.mpx文件都加入進(jìn)來，在輸出前，我們借助了CommonsChunkPlugin/SplitChunksPlugin的能力將復(fù)用的模塊抽取到一個(gè)外部的bundle中，確保最終生成的包中不包含重復(fù)模塊。我們提供了一個(gè)Webpack插件和一個(gè).mpx文件對應(yīng)的loader來實(shí)現(xiàn)上述操作，用戶只需要將其添加到Webpack配置中就可以以打包web項(xiàng)目的方式正常打包小程序，沒有任何的前置和后置操作，支持Webpack本身的完整生態(tài)。

Mpx編譯構(gòu)建機(jī)制流程示意圖

現(xiàn)狀和未來

目前Mpx框架已經(jīng)在滴滴內(nèi)部大量使用，支撐了滴滴出行、青桔單車、街兔電單車、營銷、車服等業(yè)務(wù)在小程序上的實(shí)現(xiàn)，線上運(yùn)行穩(wěn)定，收到了大量的好評反饋。未來我們在對框架進(jìn)行持續(xù)迭代優(yōu)化的同時(shí)會(huì)持續(xù)跟進(jìn)微信和支付寶最新的技術(shù)標(biāo)準(zhǔn)，同時(shí)也會(huì)將在更多的小程序平臺上進(jìn)行適配。由于我們的設(shè)計(jì)初衷和專注點(diǎn)在于增強(qiáng)小程序開發(fā)體驗(yàn)，Mpx并沒有進(jìn)行跨H5甚至是跨Native的支持，但現(xiàn)實(shí)業(yè)務(wù)當(dāng)中確實(shí)存在這樣的訴求，未來我們會(huì)在Mpx的基礎(chǔ)上對跨端進(jìn)行一定的嘗試，與此同時(shí)我們依然會(huì)持續(xù)維護(hù)升級Mpx，原因在于跨端意味著靈活性受限及能力的缺失，我們希望能給用戶提供第二種選擇。

Mpx與業(yè)內(nèi)主流小程序框架異同對比

結(jié)語

如果你注重開發(fā)體驗(yàn)和產(chǎn)品性能，專注于小程序開發(fā)，那Mpx會(huì)是一個(gè)很好的選擇。最后感謝開源社區(qū)源源不斷涌現(xiàn)出的優(yōu)秀項(xiàng)目，給我們提供了無限的啟發(fā)和巨大的技術(shù)幫助。
 

Github: https://github.com/didi/mpx

使用文檔: https://didi.github.io/mpx/