微信小程序開發，多端框架全面測評。最近前端屆多端框架頻出，相信很多有代碼多端運行需求的開發者都會產生一些疑惑：這些框架都有什么優缺點？到底應該用哪個？作為 Taro 開發團隊一員，筆者想在本文盡量站在一個客觀公正的角度去評價各個框架的選型和優劣。但宥于利益相關，本文的觀點很可能是帶有偏向性的，大家可以帶著批判的眼光去看待，權當拋磚引玉。那么，當我們在討論多端框架時，我們該談論什么。筆者以為，現在流行的多端框架可以大致分為三類。
1、全包型
這類框架最大的特點就是從底層的渲染引擎、布局引擎，到中層的 DSL，再到上層的框架全部由自己開發，代表框架是 Qt 和 Flutter。這類框架優點非常明顯：性能（的上限）高；各平臺渲染結果一致。缺點也非常明顯：需要完全重新學習 DSL（QML/Dart），以及難以適配中國特色的端：小程序。這類框架是最原始也是最純正的的多端開發框架，由于底層到上層每個環節都掌握在自己手里，也能最大可能地去保證開發和跨端體驗一致。但它們的框架研發成本巨大，渲染引擎、布局引擎、DSL、上層框架每個部分都需要大量人力開發維護。
2、Web 技術型
這類框架把 Web 技術（JAVAScript，css）帶到移動開發中，自研布局引擎處理 CSS，使用 JavaScript 寫業務邏輯，使用流行的前端框架作為 DSL，各端分別使用各自的原生組件渲染。代表框架是 React Native 和 Weex，這樣做的優點有：開發迅速；復用前端生態；易于學習上手，不管前端后端移動端，多多少少都會一點 JS、CSS。缺點有：交互復雜時難以寫出高性能的代碼，這類框架的設計就必然導致 JS 和 Native 之間需要通信，類似于手勢操作這樣頻繁地觸發通信就很可能使得 UI 無法在 16ms 內及時繪制。React Native 有一些聲明式的組件可以避免這個問題，但聲明式的寫法很難滿足復雜交互的需求。由于沒有渲染引擎，使用各端的原生組件渲染，相同代碼渲染的一致性沒有第一種高。
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）都有它們的優缺點，大家可以根據團隊技術棧和偏好自行選擇。
