整合營銷服務商
電腦端+手機端+微信端=數(shù)據(jù)同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數(shù)據(jù)同步管理
免費咨詢熱線：
者 | uni-app團隊
責編 | 伍杏玲
【CSDN 編者按】最近前端界多端框架頻出，各巨頭公司紛紛造出各家的輪子，那么開發(fā)者該怎么選呢？
為了讓開發(fā)者能直觀地感受每個框架的差異，uni-app團隊投入一周真實地開發(fā)了6個框架的小程序，從性能、跨端支持、學習門檻、工具等多方面進行深度評測，一起來看看他們的研究結果吧。
之前Taro團隊發(fā)布了一篇
小程序多端框架全面測評
，讓開發(fā)者對業(yè)界主流的跨端框架，有了初步認識，感謝Taro團隊的付出。不過橫評這件事，要想得到更精確的結論，其實非常花費時間。它需要：
真實地動手寫多個平臺的測試Demo，比較各個平臺的功能、性能，它們的實際情況到底是不是如文檔所寫？
真實地學習每個框架，了解它們的學習曲線，在實際開發(fā)中遇到問題時，感受它們的文檔、教程、社區(qū)生態(tài)和技服能力到底怎么樣？
我們 uni-app 團隊投入一周完成了這個深度評測，下面我們分享下實際開發(fā)不同框架的測試例時遇到的問題，以及在各端的兼容測試結果。在本文里，我們團隊基于真實測試數(shù)據(jù)及各框架官網(wǎng)可采集到的公開數(shù)據(jù)，希望客觀公正地評價各個框架的選型和優(yōu)劣。但宥于利益相關，本文的觀點很可能是帶有偏向性的，大家可以帶著批判的眼光去看待。
評測實驗介紹
開發(fā)內容：開發(fā)一個仿微博小程序首頁的復雜長列表，支持下拉刷新、上拉翻頁、點贊。
開發(fā)版本：一共開發(fā)了6個版本，包括微信原生版、WePY版、Mpvue版、Taro版、uni-app版、Chameleon版（以這些產(chǎn)品發(fā)布時間排序，下同），按照官網(wǎng)指引通過cli方式默認安裝。
測試機型：紅米 Redmi 6 Pro、MIUI 10.2.2.0 穩(wěn)定版（最新版）、微信版本 7.0.3（最新版）。
測試環(huán)境：每個框架開始測試前，殺掉各App進程、清空內存，保證測試機環(huán)境基本一致；每次從本地讀取靜態(tài)數(shù)據(jù)，屏蔽網(wǎng)絡差異。
測試維度：
測試界面：
跨端支持度如何
開發(fā)一次，到處運行，是每個程序員的夢想。但現(xiàn)實往往變成開發(fā)一次，到處調錯。
各個待評測框架，是否真得如官宣的那樣，一次開發(fā)、多端發(fā)布？
我們將上述仿微博App依次發(fā)布到各平臺，驗證每個框架在各端的兼容性，結果如下：
測試結果說明：
通過上述例子可以看出，跨端支持度測評結論：uni-app > Taro > Chameleon > Mpvue >WePY、原生微信小程序
但是僅有上面的測試還不全面，實際業(yè)務要比這個測試例復雜很多。但我們沒法開發(fā)很多復雜業(yè)務做評測，所以還需要再對照各家文檔補充一些信息。
由于每個框架的文檔中都描述了各種組件和API的跨端支持程度。我們過了幾家的文檔，發(fā)現(xiàn)各家基本是以微信小程序為基線，然后把各種組件和API在其他端實現(xiàn)了一遍：
跨端框架，一方面要考慮框架提供的通用API跨端支持，同時還要考慮不同端的特色差異如何兼容。畢竟每個端都會有自己的特色，不可能完全一致。
跨端框架，還涉及一個UI框架的跨端問題，評測結果如下：
最后補充跨端案例：
綜合以上信息，本項的最終評測結論：uni-app > Taro > Chameleon > Mpvue > WePY、原生微信小程序
跨端框架性能如何
跨端框架基本都是Compiler + Runtime模式，引入的Runtime是否會降低運行性能？
尤其是與原生微信小程序開發(fā)相比性能怎么樣，這是大家普遍關心的問題。
我們依然以上述仿微博小程序為例，測試2個容易出性能問題的點：長列表加載、大量點贊組件的響應。
長列表加載
仿微博的列表是一個包含很多組件的列表，這種復雜列表對性能的壓力更大，很適合做性能測試。
從觸發(fā)上拉加載到數(shù)據(jù)更新、頁面渲染完成，需要準確計時。人眼視覺計時肯定不行，我們采用程序埋點的方式，制定了如下計時時機：
Tips：setData回調函數(shù)開頭可認為是頁面渲染完成的時間，是因為微信setData定義如下(微信規(guī)范)：
測試方式：從頁面空列表開始，通過程序自動觸發(fā)上拉加載，每次新增20條列表，記錄單次耗時；固定間隔連續(xù)觸發(fā) N 次上拉加載，使得頁面達到 20*N 條列表，計算這 N 次觸發(fā)上拉 -> 渲染完成的平均耗時。
測試結果如下：
說明：以400條微博列表為例，從頁面空列表開始，每隔1秒觸發(fā)一次上拉加載（新增20條微博），記錄單次耗時，觸發(fā)20次后停止（頁面達到400條微博），計算這20次的平均耗時，結果微信原生在這20次觸發(fā)上拉 -> 渲染完成的平均耗時為876毫秒，最快的uni-app是741毫秒，最慢的Mpvue是4493毫秒。
大家初看這個數(shù)據(jù)，可能比較疑惑，別急，下方有詳細說明。
說明1：為何 Mpvue/WePY 測試數(shù)據(jù)不完整?
Mpvue、WePY 誕生之初，微信小程序尚不支持自定義組件，無法進行組件化開發(fā)；Mpvue、WePY 為解決這個問題，將用戶編寫的Vue組件，編譯為WXML中的模板，變相實現(xiàn)了組件化開發(fā)能力，提高代碼復用性，這在當時的技術條件下是很棒的技術方案。
但如此方案，在復雜組件較多的頁面，會大量增加 Dom 節(jié)點數(shù)量，甚至超出微信的 dom 節(jié)點數(shù)限制。我們在紅米手機（Redmi 6 Pro）上實測，頁面組件超過500個時，Mpvue、WePY 實現(xiàn)的仿微博App就會報出如下異常，并停止渲染，故這兩個測試框架在組件較多時，測試數(shù)據(jù)不完整。這也就意味著，當頁面組件太多時，無法使用這2個框架。
dom limit exceeded please check if there’s any mistake you’ve made
Tips：WePY在400條列表以內，為何性能高于微信原生框架，這個跟自定義組件管理開銷及業(yè)務場景有關（WePY編譯為模板，不涉及組件創(chuàng)建及管理開銷），后續(xù)對微博點贊，涉及組件數(shù)據(jù)傳遞時，微信原生框架的性能優(yōu)勢就提現(xiàn)出來了，詳見下方測試數(shù)據(jù)。
說明2：為什么測試數(shù)據(jù)顯示uni-app會比微信原生框架性能略好？
其實，在頁面上有200條記錄（200個組件）時，Taro 性能數(shù)據(jù)也比微信原生框架更好。
微信原生框架耗時主要在setData調用上，開發(fā)者若不單獨優(yōu)化，則每次都會傳遞大量數(shù)據(jù)；而 uni-app、Taro 都在調用setData之前自動做Diff計算，每次僅傳遞有變化的數(shù)據(jù)。
例如當前頁面有20條數(shù)據(jù)，觸發(fā)上拉加載時，會新加載20條數(shù)據(jù)，此時原生框架通過如下代碼測試時，setData會傳輸40條數(shù)據(jù)。
data: {
listData: []
},
onReachBottom() { //上拉加載
let listData = this.data.listData;
listData.push(...Api.getNews());//新增數(shù)據(jù)
this.setData({
listData
}) //全量數(shù)據(jù)，發(fā)送數(shù)據(jù)到視圖層
}
開發(fā)者使用微信原生框架，完全可以自己優(yōu)化，精簡傳遞數(shù)據(jù)，比如修改如下：
data: {
listData: []
},
onReachBottom() { //上拉加載
// 通過長度獲取下一次渲染的索引
let index = this.data.listData.length;
let newData = {}; //新變更數(shù)據(jù)
Api.getNews().forEach((item) => {
newData['listData[' + (index++) + ']'] = item //賦值，索引遞增
})
this.setData(newData) //增量數(shù)據(jù)，發(fā)送數(shù)據(jù)到視圖層
}
經(jīng)過如上優(yōu)化修改后，再次測試，微信原生框架性能數(shù)據(jù)如下：
從測試結果可看出，經(jīng)過開發(fā)者手動優(yōu)化，微信原生框架可達到更好的性能，但 uni-app、Taro 相比微信原生，性能差距并不大。
這個結果和Web開發(fā)類似，Web開發(fā)也有原生JS開發(fā)、Vue、React框架等情況。如果不做特殊優(yōu)化，原生JS寫的網(wǎng)頁，性能經(jīng)常還不如Vue、React框架的性能。
也恰恰是因為Vue、React框架的開發(fā)體驗好，所以原生JS開發(fā)已經(jīng)逐漸減少使用了。
復雜長列表加載下一頁評測結論：微信原生開發(fā)手工優(yōu)化，uni-app>微信原生開發(fā)未手工優(yōu)化，Taro > Chameleon > WePY > Mpvue
點贊組件響應速度
長列表中的某個組件，比如點贊組件，點擊時是否能及時的修改未贊和已贊狀態(tài)？
測試方式：
在紅米手機（Redmi 6 Pro）上進行多次測試，求其平均值，結果如下：
說明：也就是在列表數(shù)量為400時，微信原生開發(fā)的應用，點贊按鈕從點擊到狀態(tài)變化需要111毫秒。
測試結果數(shù)據(jù)說明：
組件數(shù)據(jù)更新性能測評：微信原生開發(fā)，uni-app，Taro > Chameleon > WePY > Mpvue
綜上，本性能測試做了2個測試，長列表加載和組件狀態(tài)更新。綜合2個實驗，結論如下：
微信原生開發(fā)手工優(yōu)化，uni-app>微信原生開發(fā)未手工優(yōu)化，Taro > Chameleon > WePY > Mpvue
學習門檻
DSL語法支持度
主流跨端框架基本都遵循React、Vue（類Vue）語法，其主要目的：復用工程師的現(xiàn)有技術棧，降低學習成本。此時，跨端框架對于原框架（React/Vue）語法的支持度就是一個重要的衡量標準，如果支持度較低、和原框架語法差異較大，則開發(fā)者無異于要學習一門新的框架，成本太高。
實際開發(fā)中發(fā)現(xiàn)，各個多端框架，都沒有完全實現(xiàn)Vue、React在Web上的所有語法：
Taro對于JS 的語法支持是相對完善的，其文檔中描述未來版本計劃：
更多的 JSX語法支持，1.3之后限制生產(chǎn)力的語法只有只能用map創(chuàng)造循環(huán)組件一條
Mpvue、uni-app框架基于Vue.js核心，通過修改Vue.js的Runtime和Compiler，實現(xiàn)了在小程序端的運行，支持絕大部分的Vue語法；uni-app編譯到微信端曾經(jīng)使用過Mpvue，但后來重寫框架，支持了更多vue語法如Filter、復雜JavaScript表達式等。
WePY、Chameleon 都是類Vue的實現(xiàn)，僅支持Vue的部分語法，開發(fā)時需要單獨學習它們的規(guī)則；
DSL語法支持評測：Taro，uni-app > Mpvue > WePY，Chameleon
學習資料完善度
官方文檔、搜索系統(tǒng)的完備度方面（詳見各官網(wǎng)）：
教程方面：
學習資料完善度評測：uni-app > Mpvue，Taro > Chameleon > WePY
技術支持和社區(qū)活躍度
開發(fā)難免遇到問題，官方技術支持和社區(qū)活躍度很重要。
本次評測Demo開發(fā)期間，我們的同學（同時掌握Vue和React），在學習研究各個多端框架時，切實感受到由于語法、學習資料、社區(qū)的差異帶來的學習門檻。
綜合評估，本項評測結論：uni-app > Taro > Mpvue > WePY > Chameleon
Tips：本測評忽略React、Vue兩框架自身的學習門檻
工具和周邊生態(tài)
工具
所有多端框架均支持cli模式，可以在主流前端工具中開發(fā)。
各框架基本都帶有d.ts的語法提示庫。
由于Mpvue、uni-app、Taro直接支持Vue、React語法，配套的IDE工具鏈較豐富，著色、校驗、格式化完善，Chameleon針對部分編輯器推薦了插件，WePY有一些三方維護的Vscode插件。
工具屬性維度，uni-app比較好，其出品公司同時也是HBuilder的出品公司，DCloud.io。
HBuilder/HBuilderX系列是四大主流前端開發(fā)工具（可對比百度指數(shù)），為uni-app做了很多優(yōu)化，故uni-app的開發(fā)效率、易用性非其他框架可及。
當然對于不習慣HBuilderX的開發(fā)者而言，uni-app的這個優(yōu)勢無法體現(xiàn)。
周邊生態(tài)
一個底層框架，其周邊配套非常重要，比如UI庫、JS庫、項目模板。
WePY：出現(xiàn)時間久，開源項目多，占據(jù)一定優(yōu)勢。
Mpvue：發(fā)布時間也較早，歷史積累較多。
Taro：官方提供了Taro UI，GitHub上有一些開源項目。
uni-app：提供了插件市場，UI庫、周邊模板豐富
Chameleon：還沒有形成周邊生態(tài)。
值得注意的是，uni-app和Mpvue的插件生態(tài)是互通的，都是Vue插件。所以雙方還聯(lián)合舉辦了插件大賽。這個聯(lián)合生態(tài)的周邊豐富度，是目前各個框架中最豐富的。
綜上比較，工具和周邊生態(tài)評測結論：uni-app，Mpvue > WePY > Taro > Chameleon
其他常見評測指標
GitHub Star：
GitHub Star 數(shù)對比：Taro > Wepy > Mpvue > uni-app > Chameleon
（Star數(shù)采集時間：2019.04.08 16:30）
百度指數(shù)
百度指數(shù)代表了開發(fā)者的搜索量和包含關鍵字的網(wǎng)頁數(shù)量。如下是各跨端框架近7天（2019-03-24 ~ 2019-03-30）的百度指數(shù)：
WePY未被百度指數(shù)收錄，說明其搜索量和包含該關鍵字的網(wǎng)頁數(shù)量都不夠多。
案例
僅看發(fā)布到微信小程序的案例，數(shù)量和質量綜合對比，WePY > Mpvue > Taro , uni-app > Chameleon
如果看多端案例，綜合對比，uni-app > Taro > Mpvue > Wepy > Chameleon
其他補充說明
App側的補充說明
目前有Taro、uni-app、Chameleon三家框架支持App端。但在App端大多是三方產(chǎn)品，比如Taro使用expo(一個基于React Native的封裝庫），Chameleon使用Weex。
不管React Native還是Weex，其架構與小程序架構完全不同，從排版到API能力都差別很大，所以這類產(chǎn)品跨App端時兼容性較差。
uni-app的App端，內置一個完整小程序引擎，并補充了可選的Weex引擎。這也是uni-app在App端能夠正常運行微信小程序代碼的原因。
整個業(yè)內目前還不存在一個完全開源的小程序引擎（微信、百度、支付寶、頭條的小程序引擎源碼均未開源）。uni-app的小程序引擎不是全開源，而是能力層開源，中控未開源。
所以可能各家的多端框架，在App端都有不完美的地方，需要開發(fā)者使用時注意。
其實App引擎并非前端領域，是原生領域的另一個競技場。
轉換和混寫
Taro提供了原生小程序轉換為Taro工程的轉換器，也支持在原生小程序里部分頁面嵌入Taro編寫的頁面。這是Taro的特色，其他跨端框架沒有提供。這對于降低入門門檻有不少幫助。
結語
真實客觀的永遠是實驗和數(shù)據(jù)，而不是結論。不同需求的開發(fā)者，可以根據(jù)上述實驗數(shù)據(jù)，自行得出自己的選型結論。
但作為一篇完整的評測，我們也必須提供一份總結，雖然它可能加入了我們的主觀感受：
如果你只開發(fā)微信小程序，不做多端，那么使用微信原生開發(fā)、uni-app、Taro是更優(yōu)的選擇。
如果使用微信原生開發(fā)，需要注意手動寫優(yōu)化代碼來控制setData。
如果你是React系，那就用Taro。
如果是Vue系，那就用uni-app，uni-app在性能、周邊生態(tài)和開發(fā)效率上更有優(yōu)勢。
如果你主要為了各家小程序，且不用復雜組件，那除了uni-app和Taro，Mpvue也是不錯的選擇。Mpvue發(fā)布2.0版本后，搜索指數(shù)明顯爬升，希望能持續(xù)更新，迎來二次繁榮。
如果你主要為了微信端和H5端，那么uni-app和Taro都可以。可以根據(jù)自己熟悉的技術棧選擇。
如果你只關心App，不關心小程序和H5，那歡迎關注我們后續(xù)的評測：uni-app和Cordova、React Native、Weex、Flutter的深度比較。
Chameleon發(fā)布時間還短，完善度不如其他框架，但其未來的規(guī)劃比較令人期待，值得關注。
作者：uni-app團隊，即DCloud團隊，專注服務中國的前端開發(fā)者，已發(fā)布產(chǎn)品包括：前端IDE（HBuilder/HBuilderX）、前端ui庫（mui）、跨平臺App引擎（HTML5Plus）、多端框架（uni-app）。
測試代碼：
GitHub：https://github.com/dcloudio/test-framework
原文：https://blog.csdn.net/hbcui1984/article/details/88945790
聲明：本文系作者投稿，版權歸作者所有。
既然我們在開發(fā)中使用前后端分離模式，也就是前端拿到后端的數(shù)據(jù)時怎么處理，怎么輸出都有前端自己來實現(xiàn)，這樣就需要寫大量的js代碼，而為了簡化js的代碼，就衍生出了很多的框架，比如jquery，Angular,Vue,React等。
Vue.js是一個構建數(shù)據(jù)驅動的 web 界面的漸進式框架。Vue.js 的目標是通過盡可能簡單的 API 實現(xiàn)響應的數(shù)據(jù)綁定和組合的視圖組件。核心是一個響應的數(shù)據(jù)綁定系統(tǒng)。
當數(shù)據(jù)發(fā)生改變時，自動更新視圖。
? UI頁面映射出一個組件樹
? 組件可重用，可維護性好。
? vue是輕量級框架、簡單易學、雙向數(shù)據(jù)綁定、組件化、視圖、數(shù)據(jù)和結構的分離、虛擬DOM、運行速度快。
? 而且vue是單頁面應用，使頁面局部刷新，不用每次跳轉頁面都要請求所有數(shù)據(jù)和dom，這樣大大加快了訪問速度和提升用戶體驗。而且他的第三方ui庫很多節(jié)省開發(fā)時間。
? Vue有一個重要特點是當數(shù)據(jù)發(fā)生變化時，可以自動更新視圖，那這個是怎么實現(xiàn)的。這是因為Vue采用了MVVM架構模式。那什么是MVVM呢。
? MVC模式結構圖
? MVVM模式結構圖
可以看到MVVM是一個MVC的增強版，正式連接了視圖和模型，將表示邏輯從Controller移出放到一個新的對象里，即ViewModel。它實現(xiàn)了View和Model的自動同步，即當Model的屬性改變時，我們不用再自己手動操作Dom元素來改變View的顯示，而是改變屬性后該屬性對應的View層顯示會自動改變。
View 是視圖層，也就是用戶界面。前端主要由 HTML 和 CSS 來構建，為了更方便地展現(xiàn) ViewModel 或者 Model 層的數(shù)據(jù)，已經(jīng)產(chǎn)生了各種各樣的前后端模板語言，比如 FreeMarker、Thymeleaf 等等，各大 MVVM 框架如 Vue.js，AngularJS，EJS 等也都有自己用來構建用戶界面的內置模板語言。
Model 是指數(shù)據(jù)模型，泛指后端進行的各種業(yè)務邏輯處理和數(shù)據(jù)操控，主要圍繞數(shù)據(jù)庫系統(tǒng)展開。這里的難點主要在于需要和前端約定統(tǒng)一的 接口規(guī)則
ViewModel 是由前端開發(fā)人員組織生成和維護的視圖數(shù)據(jù)層。在這一層，前端開發(fā)者對從后端獲取的 Model 數(shù)據(jù)進行轉換處理，做二次封裝，以生成符合 View 層使用預期的視圖數(shù)據(jù)模型。
需要注意的是 ViewModel 所封裝出來的數(shù)據(jù)模型包括視圖的狀態(tài)和行為兩部分，而 Model 層的數(shù)據(jù)模型是只包含狀態(tài)的.
比如頁面的這一塊展示什么，那一塊展示什么這些都屬于視圖狀態(tài)(展示);
頁面加載進來時發(fā)生什么，點擊這一塊發(fā)生什么，這一塊滾動時發(fā)生什么這些都屬于視圖行為(交互).
視圖狀態(tài)和行為都封裝在了 ViewModel 里。這樣的封裝使得 ViewModel 可以完整地去描述 View 層。由于實現(xiàn)了雙向綁定，ViewModel 的內容會實時展現(xiàn)在 View 層，這是激動人心的，因為前端開發(fā)者再也不必低效又麻煩地通過操縱 DOM 去更新視圖。
MVVM 框架已經(jīng)把最臟最累的一塊做好了，我們開發(fā)者只需要處理和維護 ViewModel，更新數(shù)據(jù)視圖就會自動得到相應更新，真正實現(xiàn) 事件驅動編程。
View 層展現(xiàn)的不是 Model 層的數(shù)據(jù)，而是 ViewModel 的數(shù)據(jù)，由 ViewModel 負責與 Model 層交互，這就完全解耦了 View 層和 Model 層，這個解耦是至關重要的，它是前后端分離方案實施的重要一環(huán)。
? 方式1：
? Vue官網(wǎng)下載：https://cn.vuejs.org/v2/guide/installation.html
?
?
? 開發(fā)Vue的工具很多，這里我們先使用之前講解web前端時使用的工具Hbuilder
? Vue.js 的核心是實現(xiàn)了 MVVM 模式，它扮演的角色就是 ViewModel 層，那么我們的第一個應用程序就是展示她的 數(shù)據(jù)綁定 功能，操作流程如下：
?
創(chuàng)建出來的項目結構如下：
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<title></title>
<script type="text/javascript" src="js/vue.js" ></script>
</head>
<body>
<div id="d1">
{{message}}
</div>
<script type="text/javascript">
var v=new Vue({
el:'#d1', //注意 這里el里面的是字符l 不是數(shù)字1 d1是上面div的id號
data:{
message:'Hello Daimenglaoshi' //初始數(shù)據(jù)
}
})
</script>
</body>
</html>
說明
new Vue:創(chuàng)建vue對象，里面的el和data是屬性。
el:'#d1'：綁定元素的 ID;
data:{message:'Hello Daimenglaoshi!'}：數(shù)據(jù)對象中有一個名為 `message` 的屬性，并設置了初始值
{{message}}:在綁定的元素中使用 雙花括號 將Vue創(chuàng)建的名為 message 屬性包裹起來，即可實現(xiàn)數(shù)據(jù)綁定功能。不需要自己寫js賦值。
? Vue可以做到當數(shù)據(jù)發(fā)生改變時，自動更新視圖
?
說明：
小程序基礎庫版本 1.6.3 開始，小程序支持簡潔的組件化編程。所有自定義組件相關特性都需要基礎庫版本 1.6.3 或更高。組件化編程的精髓是高內聚低耦合的復用機制，這對任意一家平臺開發(fā)商而言都是降低成本和保證高質量運營的關鍵。
? 封裝粒度小于頁面，是特定業(yè)務面（Business Aspects）的封裝器
一個自定義組件由 json wxml wxss js 4個文件組成，分別代表聲明、模板、樣式和邏輯，這點和頁面相同，組件聲明的格式如下：
json文件
{
"component": true
}
wxml文件
<!-- 這是自定義組件的內部 WXML 結構 -->
<view class="inner">
{{innerText}}
</view>
<slot></slot>
vue玩家這里很熟悉吧，有一個分發(fā)槽，干什么的我就不用說了[大笑]
wxss文件
/* 這里的樣式只應用于這個自定義組件 */
.inner {
color: red;
}
js文件
//構造器
Component({
properties: {
// 這里定義了 innerText 屬性，屬性值可以在組件使用時指定
innerText: {
type: String,
value: 'default value',
}
},
// 私有數(shù)據(jù)，可用于模板渲染
data: {
// 這里是一些組件內部數(shù)據(jù)
someData: {}
},
methods: {
// 這里是一個自定義方法
customMethod: function(){}
},
//公用的代碼段，面向面的編程，比如加載、銷毀時的log等
behaviors: [],
//組件生命周期
lifetimes:{
},
//組件所在頁面生命周期
pageLifetimes:{
}
})
引用組件時，需在引用頁面或組件的json文件中聲明
{
"usingComponents": {
"component-tag-name": "path/to/the/custom/component"
}
}
usingComponents會觸發(fā)Components構造器的調用，因此，我們如果把頁面也作為特殊的組件，則可以通過引入usingComponents和Components的方式使頁面組件化，這樣會潛在的帶來很多好處，比如：如訪問頁面 /pages/index/index?paramA=123¶mB=xyz ，如果聲明有屬性 paramA 或 paramB ，則它們會被賦值為 123 或 xyz，如此等等吧。
? 組件屬性、數(shù)據(jù)的使用和通訊
組件化方法是自治策略的應用，因此，組件機制應解決數(shù)據(jù)傳入、自身渲染和上下文數(shù)據(jù)通訊的問題，在微信小程序里，其分別的實現(xiàn)機制如下：
【1】數(shù)據(jù)傳遞和Vue機制類似，父傳子通過properties，子傳父通過子組件觸發(fā)事件來完成，觸發(fā)事件須使用triggerEvent 方法，指定事件名、detail對象和事件選項，如下例：
Component({
properties: {},
methods: {
onTap: function(){
var myEventDetail = {} // detail對象，提供給事件監(jiān)聽函數(shù)
var myEventOption = {} // 觸發(fā)事件的選項
this.triggerEvent('myevent', myEventDetail, myEventOption)
}
}
})
除了上述兩種情況，還有父組件還可以通過 this.selectComponent 方法獲取子組件實例對象，這樣就可以直接訪問組件的任意數(shù)據(jù)和方法，愛怎么玩怎么玩。但這里要注意，調用時需要傳入一個匹配選擇器 selector，如：this.selectComponent(".my-component")。
【2】組件的生命周期，指的是組件自身的一些函數(shù)，這些函數(shù)在特殊的時間點或遇到一些特殊的框架事件時被自動觸發(fā)。其中，最重要的周期事件是 created、attached、detached ，包含一個組件實例生命流程的最主要時間點。組件的生命周期對應事件寫在組件構造器的lifetimes對象里。
Component({
lifetimes: {
attached: function() {
// 在組件實例進入頁面節(jié)點樹時執(zhí)行
},
detached: function() {
// 在組件實例被從頁面節(jié)點樹移除時執(zhí)行
},
},
// 以下是舊式的定義方式，可以保持對 <2.2.3 版本基礎庫的兼容
attached: function() {
// 在組件實例進入頁面節(jié)點樹時執(zhí)行
},
detached: function() {
// 在組件實例被從頁面節(jié)點樹移除時執(zhí)行
},
// ...
})
組件關聯(lián)頁面的跟蹤和監(jiān)控寫在pageLifetimes里。
Component({
pageLifetimes: {
show: function() {
// 頁面被展示
},
hide: function() {
// 頁面被隱藏
},
resize: function(size) {
// 頁面尺寸變化
}
}
})
組件通過 observers對象提供vue中類似watch的功能以實現(xiàn)數(shù)據(jù)監(jiān)聽，在MVVM模型中，數(shù)據(jù)的變化驅動事件產(chǎn)生必須有數(shù)據(jù)監(jiān)聽機制才行，這里不廢話了，上個例子。
Component({
observers: {
'some.subfield': function(subfield) {
// 使用 setData 設置 this.data.some.subfield 時觸發(fā)
// （除此以外，使用 setData 設置 this.data.some 也會觸發(fā)）
subfield === this.data.some.subfield
},
'arr[12]': function(arr12) {
// 使用 setData 設置 this.data.arr[12] 時觸發(fā)
// （除此以外，使用 setData 設置 this.data.arr 也會觸發(fā)）
arr12 === this.data.arr[12]
},
'numberA, numberB': function(numberA, numberB) {
// 在 numberA 或者 numberB 被設置時，執(zhí)行這個函數(shù)
this.setData({
sum: numberA + numberB
})
}
}
})
? 模塊化
可以將一些公共的代碼抽離成為一個單獨的 js 文件，作為一個模塊。模塊只有通過 module.exports 或者 exports 才能對外暴露接口。
// common.js
function sayHello(name) {
console.log(`Hello ${name} !`)
}
function sayGoodbye(name) {
console.log(`Goodbye ${name} !`)
}
module.exports.sayHello = sayHello
exports.sayGoodbye = sayGoodbye
在需要使用這些模塊的文件中，使用 require 將公共代碼引入
var common = require('common.js')
Page({
helloMINA: function() {
common.sayHello('MINA')
},
goodbyeMINA: function() {
common.sayGoodbye('MINA')
}
})
? 避免異常
出現(xiàn) JavaScript 異常、網(wǎng)絡異常可能導致程序的交互無法進行下去，我們應當追求異常對正常交互的干擾，保證程序的高魯棒性和高可用性。
? 不使用廢棄接口
使用即將廢棄或已廢棄接口，可能導致小程序運行不正常。一般而言，接口不會立即去掉，但保險起見，建議不要使用，避免后續(xù)小程序突然運行異常。不要使用任何文檔中提示廢棄的接口。
? 避免setData數(shù)據(jù)冗余
setData操作會引起框架處理一些渲染界面相關的工作，一個未綁定的變量意味著與界面渲染無關，傳入setData會造成不必要的性能消耗。因此，setData傳入的所有數(shù)據(jù)在模板渲染中都要有相關依賴。
? 最低基礎庫版本
當使用的組件/API 的支持版本大于配置的線上最低基礎庫版本時，可能導致相應功能不可用。開發(fā)者可通過調整最低基礎庫版本或在代碼上兼容的方式解決該問題。不要存在使用的組件/API 的支持版本大于配置的線上最低基礎庫版本的情況。
? 移除不可訪問到的頁面
小程序的包大小會影響加載時間，應該盡量控制包體積大小，避免將不會被使用的文件打包進去。存在訪問不到的頁面被打包到小程序中
? 及時回收定時器
定時器是全局的，并不是跟頁面綁定的，當小程序從一個頁面路由到另一個頁面之后，前一個頁面定時器應注意手動回收。因此，確保所有定時器的回調執(zhí)行時，所在的頁面都與設置定時器的頁面一致。
結合前面一片的小程序開發(fā)，現(xiàn)在相信馬上可以開始干活了，小程序是一個相對完整的封閉開發(fā)環(huán)境，和VUE、HBuilderX的uni-app等還是存在差異的，使用時多摸索多學習，相信一定會開發(fā)出令人眼前一亮的小程序。最后，還是那句話，打賞打賞。
#頭條創(chuàng)作挑戰(zhàn)賽#
*請認真填寫需求信息，我們會在24小時內與您取得聯(lián)系。
