微信小程序開(kāi)發(fā)，多端框架全面測(cè)評(píng)。最近前端屆多端框架頻出，相信很多有代碼多端運(yùn)行需求的開(kāi)發(fā)者都會(huì)產(chǎn)生一些疑惑：這些框架都有什么優(yōu)缺點(diǎn)？到底應(yīng)該用哪個(gè)？作為 Taro 開(kāi)發(fā)團(tuán)隊(duì)一員，筆者想在本文盡量站在一個(gè)客觀公正的角度去評(píng)價(jià)各個(gè)框架的選型和優(yōu)劣。但宥于利益相關(guān)，本文的觀點(diǎn)很可能是帶有偏向性的，大家可以帶著批判的眼光去看待，權(quán)當(dāng)拋磚引玉。那么，當(dāng)我們?cè)谟懻摱喽丝蚣軙r(shí)，我們?cè)撜務(wù)撌裁础９P者以為，現(xiàn)在流行的多端框架可以大致分為三類。
1、全包型
這類框架最大的特點(diǎn)就是從底層的渲染引擎、布局引擎，到中層的 DSL，再到上層的框架全部由自己開(kāi)發(fā)，代表框架是 Qt 和 Flutter。這類框架優(yōu)點(diǎn)非常明顯：性能（的上限）高；各平臺(tái)渲染結(jié)果一致。缺點(diǎn)也非常明顯：需要完全重新學(xué)習(xí) DSL（QML/Dart），以及難以適配中國(guó)特色的端：小程序。這類框架是最原始也是最純正的的多端開(kāi)發(fā)框架，由于底層到上層每個(gè)環(huán)節(jié)都掌握在自己手里，也能最大可能地去保證開(kāi)發(fā)和跨端體驗(yàn)一致。但它們的框架研發(fā)成本巨大，渲染引擎、布局引擎、DSL、上層框架每個(gè)部分都需要大量人力開(kāi)發(fā)維護(hù)。
2、Web 技術(shù)型
這類框架把 Web 技術(shù)（JAVAScript，css）帶到移動(dòng)開(kāi)發(fā)中，自研布局引擎處理 CSS，使用 JavaScript 寫(xiě)業(yè)務(wù)邏輯，使用流行的前端框架作為 DSL，各端分別使用各自的原生組件渲染。代表框架是 React Native 和 Weex，這樣做的優(yōu)點(diǎn)有：開(kāi)發(fā)迅速；復(fù)用前端生態(tài)；易于學(xué)習(xí)上手，不管前端后端移動(dòng)端，多多少少都會(huì)一點(diǎn) JS、CSS。缺點(diǎn)有：交互復(fù)雜時(shí)難以寫(xiě)出高性能的代碼，這類框架的設(shè)計(jì)就必然導(dǎo)致 JS 和 Native 之間需要通信，類似于手勢(shì)操作這樣頻繁地觸發(fā)通信就很可能使得 UI 無(wú)法在 16ms 內(nèi)及時(shí)繪制。React Native 有一些聲明式的組件可以避免這個(gè)問(wèn)題，但聲明式的寫(xiě)法很難滿足復(fù)雜交互的需求。由于沒(méi)有渲染引擎，使用各端的原生組件渲染，相同代碼渲染的一致性沒(méi)有第一種高。
3、JavaScript 編譯型
這類框架就是我們這篇文章的主角們：Taro、WePY 、uni-App 、 mpvue 、 chameleon，它們的原理也都大同小異：先以 JavaScript 作為基礎(chǔ)選定一個(gè) DSL 框架，以這個(gè) DSL 框架為標(biāo)準(zhǔn)在各端分別編譯為不同的代碼，各端分別有一個(gè)運(yùn)行時(shí)框架或兼容組件庫(kù)保證代碼正確運(yùn)行。這類框架最大優(yōu)點(diǎn)和創(chuàng)造的最大原因就是小程序，因?yàn)榈谝坏诙N框架其實(shí)除了可以跨系統(tǒng)平臺(tái)之外，也都能編譯運(yùn)行在瀏覽器中。(Qt 有 Qt for WebAssembly, Flutter 有 Hummingbird，React Native 有 react-native-web, Weex 原生支持)。
另外一個(gè)優(yōu)點(diǎn)是在移動(dòng)端一般會(huì)編譯到 React Native/Weex，所以它們也都擁有 Web 技術(shù)型框架的優(yōu)點(diǎn)。這看起來(lái)很美好，但實(shí)際上 React Native/Weex 的缺點(diǎn)編譯型框架也無(wú)法避免。除此之外，編譯型框架的抽象也不是免費(fèi)的：當(dāng) bug 出現(xiàn)時(shí)，問(wèn)題的根源可能出在運(yùn)行時(shí)、編譯時(shí)、組件庫(kù)以及三者依賴的庫(kù)等等各個(gè)方面。在 Taro 開(kāi)源的過(guò)程中，我們就遇到過(guò) Babel 的 bug，React Native 的 bug，JavaScript 引擎的 bug，當(dāng)然也少不了 Taro 本身的 bug。相信其它原理相同的框架也無(wú)法避免這一問(wèn)題。
但這并不意味著這類為了小程序而設(shè)計(jì)的多端框架就都不堪大用。首先現(xiàn)在各巨頭超級(jí) App 的小程序百花齊放，框架會(huì)為了抹平小程序做了許多工作，這些工作在大部分情況下是不需要開(kāi)發(fā)者關(guān)心的。其次是許多業(yè)務(wù)類型并不需要復(fù)雜的邏輯和交互，沒(méi)那么容易觸發(fā)到框架底層依賴的 bug。那么當(dāng)你的業(yè)務(wù)適合選擇編譯型框架時(shí)，在筆者看來(lái)首先要考慮的就是選擇 DSL 的起點(diǎn)。因?yàn)橛卸喽诵枨髽I(yè)務(wù)通常都希望能快速開(kāi)發(fā)，一個(gè)能夠快速適應(yīng)團(tuán)隊(duì)開(kāi)發(fā)節(jié)奏的 DSL 就至關(guān)重要。不管是 React 還是 Vue（或者類 Vue）都有它們的優(yōu)缺點(diǎn)，大家可以根據(jù)團(tuán)隊(duì)技術(shù)棧和偏好自行選擇。
