整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
近前端屆多端框架頻出，相信很多有代碼多端運行需求的開發者都會產生一些疑惑：這些框架都有什么優缺點？到底應該用哪個？
作為 Taro 開發團隊一員，筆者想在本文盡量站在一個客觀公正的角度去評價各個框架的選型和優劣。但宥于利益相關，本文的觀點很可能是帶有偏向性的，大家可以帶著批判的眼光去看待，權當拋磚引玉。
那么，當我們在討論多端框架時，我們在談論什么：
多端
筆者以為，現在流行的多端框架可以大致分為三類：
1. 全包型
這類框架最大的特點就是從底層的渲染引擎、布局引擎，到中層的 DSL，再到上層的框架全部由自己開發，代表框架是 Qt 和 Flutter。這類框架優點非常明顯：性能（的上限）高；各平臺渲染結果一致。缺點也非常明顯：需要完全重新學習 DSL（QML/Dart），以及難以適配中國特色的端：小程序。
這類框架是最原始也是最純正的的多端開發框架，由于底層到上層每個環節都掌握在自己手里，也能最大可能地去保證開發和跨端體驗一致。但它們的框架研發成本巨大，渲染引擎、布局引擎、DSL、上層框架每個部分都需要大量人力開發維護。
2. Web 技術型
這類框架把 Web 技術（JavaScript，CSS）帶到移動開發中，自研布局引擎處理 CSS，使用 JavaScript 寫業務邏輯，使用流行的前端框架作為 DSL，各端分別使用各自的原生組件渲染。代表框架是 React Native 和 Weex，這樣做的優點有：
缺點有：
1. 交互復雜時難以寫出高性能的代碼，這類框架的設計就必然導致 JS 和 Native 之間需要通信，類似于手勢操作這樣頻繁地觸發通信就很可能使得 UI 無法在 16ms 內及時繪制。React Native 有一些聲明式的組件可以避免這個問題，但聲明式的寫法很難滿足復雜交互的需求。
2. 由于沒有渲染引擎，使用各端的原生組件渲染，相同代碼渲染的一致性沒有第一種高。
3. JavaScript 編譯型
這類框架就是我們這篇文章的主角們：Taro、WePY 、uni-app 、 mpvue 、 chameleon，它們的原理也都大同小異：先以 JavaScript 作為基礎選定一個 DSL 框架，以這個 DSL 框架為標準在各端分別編譯為不同的代碼，各端分別有一個運行時框架或兼容組件庫保證代碼正確運行。
這類框架最大優點和創造的最大原因就是小程序，因為第一第二種框架其實除了可以跨系統平臺之外，也都能編譯運行在瀏覽器中。(Qt 有 Qt for WebAssembly, Flutter 有 Hummingbird，React Native 有 react-native-web, Weex 原生支持)
另外一個優點是在移動端一般會編譯到 React Native/Weex，所以它們也都擁有 Web 技術型框架的優點。這看起來很美好，但實際上 React Native/Weex 的缺點編譯型框架也無法避免。除此之外，編譯型框架的抽象也不是免費的：當 bug 出現時，問題的根源可能出在運行時、編譯時、組件庫以及三者依賴的庫等等各個方面。在 Taro 開源的過程中，我們就遇到過 Babel 的 bug，React Native 的 bug，JavaScript 引擎的 bug，當然也少不了 Taro 本身的 bug。相信其它原理相同的框架也無法避免這一問題。
但這并不意味著這類為了小程序而設計的多端框架就都不堪大用。首先現在各巨頭超級 App 的小程序百花齊放，框架會為了抹平小程序做了許多工作，這些工作在大部分情況下是不需要開發者關心的。其次是許多業務類型并不需要復雜的邏輯和交互，沒那么容易觸發到框架底層依賴的 bug。
那么當你的業務適合選擇編譯型框架時，在筆者看來首先要考慮的就是選擇 DSL 的起點。因為有多端需求業務通常都希望能快速開發，一個能夠快速適應團隊開發節奏的 DSL 就至關重要。不管是 React 還是 Vue（或者類 Vue）都有它們的優缺點，大家可以根據團隊技術棧和偏好自行選擇。
如果不管什么 DSL 都能接受，那就可以進入下一個環節。
生態
以下內容均以各框架現在（2019 年 3 月 11 日）已發布穩定版為標準進行討論。
開發工具
就開發工具而言 uni-app 應該是一騎絕塵，它的文檔內容最為翔實豐富，還自帶了 IDE 圖形化開發工具，鼠標點點點就能編譯測試發布。
其它的框架都是使用 CLI 命令行工具，但值得注意的是 chameleon 有獨立的語法檢查工具，Taro 則單獨寫了 ESLint 規則和規則集。
在語法支持方面，mpvue、uni-app、Taro 、WePY 均支持 TypeScript，四者也都能通過 typing 實現編輯器自動補全。除了 API 補全之外，得益于 TypeScript 對于 JSX 的良好支持，Taro 也能對組件進行自動補全。
CSS 方面，所有框架均支持 SASS、LESS、Stylus，Taro 則多一個 CSS Modules 的支持。
所以這一輪比拼的結果應該是：
uni-app > Taro > chameleon > WePY、mpvue
多端支持度
只從支持端的數量來看，Taro 和 uni-app 以六端略微領先（移動端、H5、微信小程序、百度小程序、支付寶小程序、頭條小程序），chameleon 少了頭條小程序緊隨其后。
但值得一提的是 chameleon 有一套自研多態協議，編寫多端代碼的體驗會好許多，可以說是一個能戳到多端開發痛點的功能。uni-app 則有一套獨立的條件編譯語法，這套語法能同時作用于 js、樣式和模板文件。Taro 可以在業務邏輯中根據環境變量使用條件編譯，也可以直接使用條件編譯文件（類似 React Native 的方式）。
在移動端方面，uni-app 基于 weex 定制了一套 nvue 方案 彌補 weex API 的不足；Taro 則是暫時基于 expo 達到同樣的效果；chameleon 在移動端則有一套 SDK 配合多端協議與原生語言通信。
H5 方面，chameleon 同樣是由多態協議實現支持，uni-app 和 Taro 則是都在 H5 實現了一套兼容的組件庫和 API。
mpvue 和 WePY 都提供了轉換各端小程序的功能，但都沒有 h5 和移動端的支持。
所以最后一輪對比的結果是：
chameleon > Taro、uni-app > mpvue > WePY
組件庫 / 工具庫 /demo
作為開源時間最長的框架，WePY 不管從 Demo，組件庫數量 ，工具庫來看都占有一定優勢。
uni-app 則有自己的插件市場和 UI 庫，如果算上收費的框架和插件比起 WePy 也是完全不遑多讓的。
Taro 也有官方維護的跨端 UI 庫 taro-ui ，另外在狀態管理工具上也有非常豐富的選擇（Redux、MobX、dva），但 demo 的數量不如前兩個。但 Taro 有一個轉換微信小程序代碼為 Taro 代碼的工具，可以彌補這一問題。
而 mpvue 沒有官方維護的 UI 庫，chameleon 第三方的 demo 和工具庫也還基本沒有。
所以這輪的排序是：
WePY > uni-app 、taro > mpvue > chameleon
接入成本
接入成本有兩個方面：
第一是框架接入原有微信小程序生態。由于目前微信小程序已呈一家獨大之勢，開源的組件和庫（例如 wxparse、echart、zan-ui 等）多是基于原生微信小程序框架語法寫成的。目前看來 uni-app 、Taro、mpvue 均有文檔或 demo 在框架中直接使用原生小程序組件 / 庫，WePY 由于運行機制的問題，很多情況需要小改一下目標庫的源碼，chameleon 則是提供了一個按步驟大改目標庫源碼的遷移方式。
第二是原有微信小程序項目部分接入框架重構。在這個方面 Taro 在京東購物小程序上進行了大膽的實踐，具體可以查看文章《Taro 在京東購物小程序上的實踐》。其它框架則沒有提到相關內容。
而對于兩種接入方式 Taro 都提供了 taro convert 功能，既可以將原有微信小程序項目轉換為 Taro 多端代碼，也可以將微信小程序生態的組件轉換為 Taro 組件。
所以這輪的排序是：
Taro > mpvue 、 uni-app > WePY > chameleon
流行度
從 GitHub 的 star 來看，mpvue 、Taro、WePY 的差距非常小。從 NPM 和 CNPM 的 CLI 工具下載量來看，是 Taro（3k/week）> mpvue (2k/w) > WePY (1k/w)。但發布時間也剛好反過來。筆者估計三家的流行程度和案例都差不太多。
uni-app 則號稱有上萬案例，但不像其它框架一樣有一些大廠應用案例。另外從開發者的數量來看也是 uni-app 領先，它擁有 20+ 個 QQ 交流群（最大人數 2000）。
所以從流行程度來看應該是：
uni-app > Taro、WePY、mpvue > chameleon
開源建設
一個開源作品能走多遠是由框架維護團隊和第三方開發者共同決定的。雖然開源建設不能具體地量化，但依然是衡量一個框架 / 庫生命力的非常重要的標準。
從第三方貢獻者數量來看，Taro 在這一方面領先，并且 Taro 的一些核心包 / 功能（MobX、CSS Modules、alias）也是由第三方開發者貢獻的。除此之外，騰訊開源的 omi 框架小程序部分也是基于 Taro 完成的。
WePY 在騰訊開源計劃的加持下在這一方面也有不錯的表現；mpvue 由于停滯開發了很久就比較落后了；可能是產品策略的原因，uni-app 在開源建設上并不熱心，甚至有些部分代碼都沒有開源；chameleon 剛剛開源不久，但它的代碼和測試用例都非常規范，以后或許會有不錯的表現。
那么這一輪的對比結果是：
Taro > WePY > mpvue > chameleon > uni-app
最后補一個總的生態對比圖表：
未來
從各框架已經公布的規劃來看：
WePY 已經發布了 v2.0.alpha 版本，雖然沒有公開的文檔可以查閱到 2.0 版本有什么新功能 / 特性，但據其作者介紹，WePY 2.0 會放大招，是一個「對得起開發者」的版本。筆者也非常期待 2.0 正式發布后 WePY 的表現。
mpvue 已經發布了 2.0 的版本，主要是更新了其它端小程序的支持。但從代碼提交， issue 的回復 / 解決率來看，mpvue 要想在未來有作為首先要打消社區對于 mpvue 不管不顧不更新的質疑。
uni-app 已經在生態上建設得很好了，應該會在此基礎之上繼續穩步發展。如果 uni-app 能加強開源開放，再加強與大廠的合作，相信未來還能更上一層樓。
chameleon 的規劃比較宏大，雖然是最后發的框架，但已經在規劃或正在實現的功能有：
如果 chameleon 把這些功能都做出來的話，再繼續完善生態，爭取更多第三方開發者，那么在未來 chameleon 將大有可為。
Taro 的未來也一樣值得憧憬。Taro 即將要發布的 1.3 版本就會支持以下功能：
同時 Taro 也正在對移動端進行大規模重構；開發圖形化開發工具；開發組件 / 物料平臺以及圖形化頁面搭建工具。
結語
那說了那么多，到底用哪個呢？
如果不介意嘗鮮和學習 DSL 的話，完全可以嘗試 WePY 2.0 和 chameleon ，一個是醞釀了很久的 2.0 全新升級，一個有專門針對多端開發的多態協議。
uni-app 和 Taro 相比起來就更像是「水桶型」框架，從工具、UI 庫，開發體驗、多端支持等各方面來看都沒有明顯的短板。而 mpvue 由于開發一度停滯，現在看來各個方面都不如在小程序端基于它的 uni-app 。
當然，Talk is cheap。如果對這個話題有更多興趣的同學可以去 GitHub 另行研究，有空看代碼，沒空看提交：
編寫代碼只是軟件開發的一小部分，更多的時間往往花在構建（build）和測試（test）。 為了提高軟件開發的效率，構建和測試的自動化工具層出不窮，Travis就是這類工具，用好這個工具不僅可以提高效率，還能使開發流程更可靠和專業。
CI（Continuous Integration，持續集成）：指的是只要代碼有變更，就自動運行構建和測試，反饋運行結果。確保符合預期以后，再將新代碼集成到主干。 持續集成的好處在于，每次代碼的小幅變更，就能看到運行結果，從而不斷累積小的變更，而不是在開發周期結束時，一下子合并一大塊代碼。
Travis CI提供的是持續集成服務。它綁定GitHub上面的項目，只要有新的代碼，就會自動抓取，然后，提供一個運行環境，執行測試，完成構建，還能部署到服務器。 Travis CI與Github結合比較緊密，對GitHub上的開源Repo是免費的，私有Repo收費。
免費Travis-CI：https://travis-ci.org
收費Travis-CI：https://travis-ci.com
Step1：使用GitHub賬戶授權登錄Travis CI。
Step2：同步GitHub上的庫，對指定的庫啟用Travis CI
配置.travis.yml
Travis要求項目的根目錄下面，必須有一個 .travis.yml文件。這是配置文件，指定了Travis的行為。該文件必須保存在GitHub倉庫里面，一旦代碼倉庫有新的Commit，Travis就會去找這個文件，執行里面的命令。
代碼語言：javascript
復制
language: android jdk: oraclejdk8 # 開啟基于容器的Travis CI任務，讓編譯效率更高 sudo: false android: components: # 構建項目所用的BuildTools版本 - build-tools-28.0.3 # 用來編譯項目的SDK版本 - android-28 # 添加Android Support Repository組件 - extra-android-m2repository # 添加Support Library組件 - extra-android-support before_script: - chmod +x gradlew script: # 生成release apk包 - ./gradlew assembleRelease
Travis生命周期：
Android項目發布需要證書文件和密碼，將原始正常和密碼放入到代碼庫是很不安全的。 Travis CI為此提供了兩種解決方案：
因為Travis CI控制臺無法上傳文件，因此涉及到文件加密的部分，選擇第一種方案。
Step1：本地安裝Travis CLI命令行工具
代碼語言：javascript
復制
gem install travis
Step2：命令行登錄Travis（第一次登錄才要），并輸入GitHub的用戶名和密碼
代碼語言：javascript
復制
travis login --org
Step3：進入項目根目錄，加密證書
代碼語言：javascript
復制
travis encrypt-file xch_android.jks --add
命令執行結果：
1. 在Travis CI控制臺自動生成一對秘鑰，形如： encrypted_d71df9144721_iv、 encrypted_d71df9144721_key
2. 基于秘鑰通過 openssl對文件進行加密，并在根目錄生成 xch_android.jks.enc文件
3. 在 .travis.yml中自動生成Travis CI環境下解密文件的配置。
Step1. 在Travis CI控制臺配置 KEYSTORE_PASS、 ALIAS_NAME、 ALIAS_PASS三個環境變量。
Step2. 在項目的根目錄下創建一個名為 keystore.properties文件（用于本地命令打包），并包含以下信息：
代碼語言：javascript
復制
KEYSTORE_PASS=myStorePassword ALIAS_NAME=myKeyAlias ALIAS_PASS=myKeyPassword
Step3. 在 app module 的 build.gradle配置簽名信息， System.getenv()用來獲取Travis CI控制臺配置的變量。
代碼語言：javascript
復制
apply plugin: 'com.android.application' // 加載本地keystore.properties中的簽名配置 def keyPropertiesFile = rootProject.file("keystore.properties") def keyProperties = new Properties() if (keyPropertiesFile.exists()) { keyProperties.load(new FileInputStream(keyPropertiesFile)) } android { compileSdkVersion 28 defaultConfig { applicationId "com.github.xch168.androidtravisci" minSdkVersion 16 targetSdkVersion 28 versionCode 1 versionName "1.0" testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner" } signingConfigs { release { storeFile file("../xch_android.jks") storePassword keyProperties.containsKey("KEYSTORE_PASS") ? keyProperties['KEYSTORE_PASS'] : System.getenv("KEYSTORE_PASS") keyAlias keyProperties.containsKey("ALIAS_NAME") ? keyProperties['ALIAS_NAME'] : System.getenv("ALIAS_NAME") keyPassword keyProperties.containsKey("ALIAS_PASS") ? keyProperties['ALIAS_PASS'] : System.getenv("ALIAS_PASS") } } buildTypes { release { minifyEnabled false signingConfig signingConfigs.release proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro' } } }
Travis CI在每次構建完成后，就會刪除所有文件，設置緩存機制，可以保證規定的緩存文件不需要每次下載，提高每次構建的速度；但是如果在更好的基礎配置的情況（比如更新Gradle版本等，建議先清除緩存在跑CI）。
在 .travis.yml文件添加如下配置：
代碼語言：javascript
復制
before_cache: - rm -f $HOME/.gradle/caches/modules-2/modules-2.lock - rm -fr $HOME/.gradle/caches/*/plugin-resolution/ cache: #指定緩存目錄 directories: - $HOME/.gradle/caches/ - $HOME/.gradle/wrapper/ - $HOME/.android/build-cache
可以在后臺手動刪除Travis CI Cache：
Travis CI自動發布apk到GitHub Release
Step1. 執行travis命令自動生成deploy配置
代碼語言：javascript
復制
travis setup releases
命令執行完后會自動在 .travis.yml添加如下配置：
代碼語言：javascript
復制
deploy: provider: releases api_key: secure: b7dhz7j5tY73qbQo2GNccev7NgI6BNWNeEpEfmLTxRZ7DJptxtQuJIHF026zhHtXfRom/pSXw7qlRJXamPWl7Bc1i1lUNKX7Mdt3Fo7Z70ZAyT/6vak3EGlKqDU7Ta96MOB2+5+2nQ7nlTX4kkkeObSTbD6py4eUzktoxsPSwtjiWrq7KM4KgcJTAEGnZx4LJdFm6pgE3drkbN83J0ZP3fT7sf+5Ggv4WLa8y3l/gM3rQ0tARebDo4OuigJOmknOfcxkiAlTtVt1qw1STMaW4H/M47K1mSvQK9DxSHUCD7ngvxEJlUMtqvYSIqQItyT7D8SvDxUqpZZM6y6qAcp+q5qrnA/uC7Qa3kju3skH1XBXyA20TN/pLYKk1yuH7TLg9W+512Pmgtpr4AiZayChnNn4morhhhncsdnQf1T6ziWUNGHmMK8QcUzjBdZHOVsNHGUuaGk4hOPeTRi7ozHYMnNF1E8HJEhtLf7/BHH4o17x5wI2QuSmgwqlCbhAYEwL8m9ZtyJ7saqimGo6m37XfBlomBgaTMrCDIybqOABjPxASlMVRh84XZeeAHHLgjSRMoP2cb+lksiyhO2TsCOvQEOmofFcjj4+iN+qIynPMb3bonuce/iD9nNC2cusibYaIrr1+r2VWE61EdIiLlamw99fFT1VZtliJuJe9tugMgA= file: app/build/outputs/apk/app-release.apk # 這句手動添加 skip_cleanup: true on: repo: xch168/AndroidTravisCI # 這句手動添加 tags: true
說明：
Step2: 打 tag
代碼語言：javascript
復制
git tag -a v0.0.1-alpha.1 -m "這里是Tag注釋，說清楚這個版本的主要改動，也可以省略-m參數直接寫長文本" git push origin --tags
Step3: 自動化構建、部署
蒲公英是APP內測分發平臺，提供免費的APP內測分發托管，不但允許游客下載，還提供了二維碼，下載速度快。
Step1. 使用GitHub授權登錄https://www.pgyer.com/user/login
Step2. 獲取API Key
Step3. 將獲取的API Key配置到Travis CI的環境變量 PGYER_API_KEY：
Step4. 在 .travis.yml文件中，添加如下配置：
代碼語言：javascript
復制
# 添加蒲公英上傳腳本 before_install: - cd $TRAVIS_BUILD_DIR - wget -c https://raw.githubusercontent.com/Pgyer/TravisFile/master/pgyer_upload.sh -O pgyer_upload.sh - chmod +x pgyer_upload.sh # 在apk上傳到GitHub后，使用蒲公英的上傳腳本將apk上傳到蒲公英 after_deploy: - set -e - $TRAVIS_BUILD_DIR/pgyer_upload.sh "${TRAVIS_BUILD_DIR}/app/build/outputs/apk/release/app-release.apk" $PGYER_API_KEY
Step5. 打完tag，Travis CI自動構建后，將在蒲公英的控制臺看到上傳的apk
上傳apk到http://fir.im
http://fir.im和蒲公英的一樣，都是免費的應用內測分發平臺。
Step1. 登錄https://fir.im/
Step2. 獲取API Token。
Step3. 將獲取的API Token配置到Travis CI的環境變量 FIR_API_TOKEN。
Step4. 在 .travis.yml文件中，添加如下配置：
代碼語言：javascript
復制
before_install: - gem install fir-cli after_deploy: - fir p app/build/outputs/apk/release/app-release.apk -T $FIR_API_TOKEN -c "`git cat-file tag $TRAVIS_TAG`"
Step5. 打完tag，Travis CI自動構建后，將在http://fir.im的控制臺看到上傳的apk
發送完畢后自動發送郵件通知
雖然Travis CI也有郵件通知功能，但是不能定制模板，通知內容僅僅為提示CI運行的結果，顯然更適合開發人員。我們希望最終能以更友好的方式通知團隊成員，同時考慮到郵件送達率，可優先選擇 Submail、SendCloud等國內郵件發送服務。
這里以Submail為例：
Step1. 注冊登錄Submail
Step2. 添加發信域名（這需要有自己的域名）
Step3. 創建APPID，并將APPKEY配置到Travis CI控制臺的環境變量 SUBMAIL_SIGN。
Step4. 創建一封觸發式郵件模板
代碼語言：javascript
復制
@var(TRAVIS_REPO_SLUG)新版本@var(TRAVIS_TAG)已經發布了，功能更新： @var(TAG_DESCRIPTION) 去下載： https://fir.im/gkq1
Step5. 配置 .travis.yml
代碼語言：javascript
復制
- curl -d "appid=14017&to=xucanhui168@gmail.com&subject=[自動通知] 安卓新版本$TRAVIS_TAG發布&project=Cpyvk2&signature=$SUBMAIL_SIGN&vars={\"TRAVIS_REPO_SLUG\":\"$TRAVIS_REPO_SLUG\",\"TRAVIS_TAG\":\"$TRAVIS_TAG\",\"TAG_DESCRIPTION\":\"$(git cat-file tag $TRAVIS_TAG | awk 1 ORS='<br>')\"}" https://api.submail.cn/mail/xsend.json
Step5. 運行結果
本文Demo：https://github.com/xch168/AndroidTravisCI
近前端屆多端框架頻出，相信很多有代碼多端運行需求的開發者都會產生一些疑惑：這些框架都有什么優缺點？到底應該用哪個？那么有請我們今天的主角：Taro、WePY 、uni-app 、 mpvue 、 chameleon。下面小編將從多個角度詳細為大伙分析說明各個框架的優缺點。
全包型
這類框架最大的特點就是從底層的渲染引擎、布局引擎，到中層的 DSL，再到上層的框架全部由自己開發，代表框架是 Qt 和 Flutter。這類框架優點非常明顯：性能（的上限）高；各平臺渲染結果一致。缺點也非常明顯：需要完全重新學習 DSL（QML/Dart），以及難以適配中國特色的端：小程序。
這類框架是最原始也是最純正的的多端開發框架，由于底層到上層每個環節都掌握在自己手里，也能最大可能地去保證開發和跨端體驗一致。但它們的框架研發成本巨大，渲染引擎、布局引擎、DSL、上層框架每個部分都需要大量人力開發維護。
Web 技術型
這類框架把 Web 技術（JavaScript，CSS）帶到移動開發中，自研布局引擎處理 CSS，使用 JavaScript 寫業務邏輯，使用流行的前端框架作為 DSL，各端分別使用各自的原生組件渲染。代表框架是 React Native 和 Weex，這樣做的優點有：
缺點有：
JavaScript 編譯型
像我們今天要介紹的幾大框架，它們的原理也都大同小異：先以 JavaScript 作為基礎選定一個 DSL 框架，以這個 DSL 框架為標準在各端分別編譯為不同的代碼，各端分別有一個運行時框架或兼容組件庫保證代碼正確運行。
這類框架的一個優點是在移動端一般會編譯到 React Native/Weex，所以它們也都擁有 Web 技術型框架的優點。這看起來很美好，但實際上 React Native/Weex 的缺點編譯型框架也無法避免。除此之外，編譯型框架的抽象也不是免費的：當 bug 出現時，問題的根源可能出在運行時、編譯時、組件庫以及三者依賴的庫等等各個方面。
但這并不意味著這類為了小程序而設計的多端框架就都不堪大用。首先現在各巨頭超級 App 的小程序百花齊放，框架會為了抹平小程序做了許多工作，這些工作在大部分情況下是不需要開發者關心的。其次是許多業務類型并不需要復雜的邏輯和交互，沒那么容易觸發到框架底層依賴的 bug。
那么當你的業務適合選擇編譯型框架時，在筆者看來首先要考慮的就是選擇 DSL 的起點。因為有多端需求業務通常都希望能快速開發，一個能夠快速適應團隊開發節奏的 DSL 就至關重要。不管是 React 還是 Vue（或者類 Vue）都有它們的優缺點，大家可以根據團隊技術棧和偏好自行選擇。
以下內容均以各框架現在（2019 年 3 月 11日）已發布穩定版為標準進行討論。
開發工具
就開發工具而言 uni-app 應該是一騎絕塵，它的文檔內容最為翔實豐富，還自帶了 IDE 圖形化開發工具，鼠標點點點就能編譯測試發布。
其它的框架都是使用 CLI 命令行工具，但值得注意的是 chameleon 有獨立的語法檢查工具，Taro 則單獨寫了 ESLint 規則和規則集。
在語法支持方面，mpvue、uni-app、Taro 、WePY 均支持 TypeScript，四者也都能通過 typing 實現編輯器自動補全。除了 API 補全之外，得益于 TypeScript 對于 JSX 的良好支持，Taro 也能對組件進行自動補全。
CSS 方面，所有框架均支持 SASS、LESS、Stylus，Taro 則多一個 CSS Modules 的支持。
所以這一輪比拼的結果應該是（排序僅為筆者個人結論）：
uni-app > Taro > chameleon > WePY、mpvue
下面我們一起來看一張表格：
多端支持度
只從支持端的數量來看，Taro 和 uni-app 以六端略微領先（移動端、H5、微信小程序、百度小程序、支付寶小程序、頭條小程序），chameleon 少了頭條小程序緊隨其后。
但值得一提的是 chameleon 有一套自研多態協議，編寫多端代碼的體驗會好許多，可以說是一個能戳到多端開發痛點的功能。uni-app 則有一套獨立的條件編譯語法，這套語法能同時作用于 js、樣式和模板文件。Taro 可以在業務邏輯中根據環境變量使用條件編譯，也可以直接使用條件編譯文件（類似 React Native 的方式）。
在移動端方面，uni-app 基于 weex 定制了一套 nvue 方案 彌補 weex API 的不足；Taro 則是暫時基于 expo 達到同樣的效果；chameleon 在移動端則有一套 SDK 配合多端協議與原生語言通信。
H5 方面，chameleon 同樣是由多態協議實現支持，uni-app 和 Taro 則是都在 H5 實現了一套兼容的組件庫和 API。
mpvue 和 WePY 都提供了轉換各端小程序的功能，但都沒有 h5 和移動端的支持。
所以最后一輪對比的結果是（排序僅為筆者個人結論）：
chameleon > Taro、uni-app > mpvue、WePY
下面我們一起來看一張表格：
組件庫/工具庫/demo
作為開源時間最長的框架，WePY 不管從 Demo，組件庫數量 ，工具庫來看都占有一定優勢。
uni-app 則有自己的插件市場和 UI 庫，如果算上收費的框架和插件比起 WePy 也是完全不遑多讓的。
Taro 也有官方維護的跨端 UI 庫 taro-ui ，另外在狀態管理工具上也有非常豐富的選擇（Redux、MobX、dva），但 demo 的數量不如前兩個。但 Taro 有一個轉換微信小程序代碼為 Taro 代碼的工具，可以彌補這一問題。
而 mpvue 沒有官方維護的 UI 庫，chameleon 第三方的 demo 和工具庫也還基本沒有。
所以這輪的排序是（排序僅為筆者個人結論）：
WePY > uni-app 、taro > mpvue > chameleon
下面我們一起來看一張表格：
接入成本
接入成本有兩個方面：
第一是框架接入原有微信小程序生態。由于目前微信小程序已呈一家獨大之勢，開源的組件和庫（例如 wxparse、echart、zan-ui 等）多是基于原生微信小程序框架語法寫成的。目前看來 uni-app 、Taro、mpvue 均有文檔或 demo 在框架中直接使用原生小程序組件/庫，WePY 由于運行機制的問題，很多情況需要小改一下目標庫的源碼，chameleon 則是提供了一個按步驟大改目標庫源碼的遷移方式。
第二是原有微信小程序項目部分接入框架重構。在這個方面 Taro 在京東購物小程序上進行了大膽的實踐，具體可以查看文章《Taro 在京東購物小程序上的實踐》。其它框架則沒有提到相關內容。
而對于兩種接入方式 Taro 都提供了 taro convert 功能，既可以將原有微信小程序項目轉換為 Taro 多端代碼，也可以將微信小程序生態的組件轉換為 Taro 組件。
所以這輪的排序是（排序僅為筆者個人結論）：
Taro > mpvue 、 uni-app > WePY > chameleon
流行度
從 GitHub 的 star 來看，mpvue 、Taro、WePY 的差距非常小。從 NPM 和 CNPM 的 CLI 工具下載量來看，是 Taro（3k/week）> mpvue (2k/w) > WePY (1k/w)。但發布時間也剛好反過來。筆者估計三家的流行程度和案例都差不太多。
uni-app 則號稱有上萬案例，但不像其它框架一樣有一些大廠應用案例。另外從開發者的數量來看也是 uni-app 領先，它擁有 20+ 個 QQ 交流群（最大人數 2000）。
所以從流行程度來看應該是（排序僅為筆者個人結論）：
uni-app > Taro、WePY、mpvue > chameleon
下面我們一起來看一張表格：
開源建設
一個開源作品能走多遠是由框架維護團隊和第三方開發者共同決定的。雖然開源建設不能具體地量化，但依然是衡量一個框架/庫生命力的非常重要的標準。
從第三方貢獻者數量來看，Taro 在這一方面領先，并且 Taro 的一些核心包/功能（MobX、CSS Modules、alias）也是由第三方開發者貢獻的。除此之外，騰訊開源的 omi 框架小程序部分也是基于 Taro 完成的。
WePY 在騰訊開源計劃的加持下在這一方面也有不錯的表現；mpvue 由于停滯開發了很久就比較落后了；可能是產品策略的原因，uni-app 在開源建設上并不熱心，甚至有些部分代碼都沒有開源；chameleon 剛剛開源不久，但它的代碼和測試用例都非常規范，以后或許會有不錯的表現。
那么這一輪的對比結果是：
Taro > WePY > mpvue > chameleon > uni-app
最后補一個總的生態對比圖表：
從各框架已經公布的規劃來看：
WePY 已經發布了 v2.0.alpha 版本，雖然沒有公開的文檔可以查閱到 2.0 版本有什么新功能/特性，但據其作者介紹，WePY 2.0 會放大招，是一個「對得起開發者」的版本。筆者也非常期待 2.0 正式發布后 WePY 的表現。
mpvue 已經發布了 2.0 的版本，主要是更新了其它端小程序的支持。但從代碼提交， issue 的回復/解決率來看，mpvue 要想在未來有作為首先要打消社區對于 mpvue 不管不顧不更新的質疑。
uni-app 已經在生態上建設得很好了，應該會在此基礎之上繼續穩步發展。如果 uni-app 能加強開源開放，再加強與大廠的合作，相信未來還能更上一層樓。
chameleon 的規劃比較宏大，雖然是最后發的框架，但已經在規劃或正在實現的功能有：
如果 chameleon 把這些功能都做出來的話，再繼續完善生態，爭取更多第三方開發者，那么在未來 chameleon 將大有可為。
同時 Taro 也正在對移動端進行大規模重構；開發圖形化開發工具；開發組件/物料平臺以及圖形化頁面搭建工具。
那說了那么多，希望能讓你在選擇框架的同時給你一點意見和啟發。小編覺得如果不介意嘗鮮和學習 DSL 的話，完全可以嘗試 WePY 2.0 和 chameleon ，一個是醞釀了很久的 2.0 全新升級，一個有專門針對多端開發的多態協議。
uni-app 和 Taro 相比起來就更像是水桶型框架，從工具、UI 庫，開發體驗、多端支持等各方面來看都沒有明顯的短板。而 mpvue 由于開發一度停滯，現在看來各個方面都不如在小程序端基于它的 uni-app 。
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
