原生應(yīng)用程序是指某一個(gè)移動(dòng)平臺(tái)（比如iOS或安卓）所特有的應(yīng)用，使用相應(yīng)平臺(tái)支持的開發(fā)工具和語言，并直接調(diào)用系統(tǒng)提供的SDK API。比如Android原生應(yīng)用就是指使用Java或Kotlin語言直接調(diào)用Android SDK開發(fā)的應(yīng)用程序；而iOS原生應(yīng)用就是指通過Objective-C或Swift語言直接調(diào)用iOS SDK開發(fā)的應(yīng)用程序。原生開發(fā)有以下主要優(yōu)勢：
可訪問平臺(tái)全部功能（GPS、攝像頭）；
速度快、性能高、可以實(shí)現(xiàn)復(fù)雜動(dòng)畫及繪制，整體用戶體驗(yàn)好；
主要缺點(diǎn)：
平臺(tái)特定，開發(fā)成本高；不同平臺(tái)必須維護(hù)不同代碼，人力成本隨之變大；
內(nèi)容固定，動(dòng)態(tài)化弱，大多數(shù)情況下，有新功能更新時(shí)只能發(fā)版；
在移動(dòng)互聯(lián)網(wǎng)發(fā)展初期，業(yè)務(wù)場景并不復(fù)雜，原生開發(fā)還可以應(yīng)對(duì)產(chǎn)品需求迭代。 但近幾年，隨著物聯(lián)網(wǎng)時(shí)代到來、移動(dòng)互聯(lián)網(wǎng)高歌猛進(jìn)，日新月異，在很多業(yè)務(wù)場景中，傳統(tǒng)的純原生開發(fā)已經(jīng)不能滿足日益增長的業(yè)務(wù)需求。主要表現(xiàn)在：
動(dòng)態(tài)化內(nèi)容需求增大；當(dāng)需求發(fā)生變化時(shí)，純原生應(yīng)用需要通過版本升級(jí)來更新內(nèi)容，但應(yīng)用上架、審核是需要周期的，這對(duì)高速變化的互聯(lián)網(wǎng)時(shí)代來說是很難接受的，所以，對(duì)應(yīng)用動(dòng)態(tài)化(不發(fā)版也可以更新應(yīng)用內(nèi)容)的需求就變的迫在眉睫。
業(yè)務(wù)需求變化快，開發(fā)成本變大；由于原生開發(fā)一般都要維護(hù)Android、iOS兩個(gè)開發(fā)團(tuán)隊(duì)，版本迭代時(shí)，無論人力成本，還是測試成本都會(huì)變大。
總結(jié)一下，純原生開發(fā)主要面臨動(dòng)態(tài)化和開發(fā)成本兩個(gè)問題，而針對(duì)這兩個(gè)問題，誕生了一些跨平臺(tái)的動(dòng)態(tài)化框架。
針對(duì)原生開發(fā)面臨的問題，業(yè)界一直都在努力尋找好的解決方案，而時(shí)至今日，已經(jīng)有很多跨平臺(tái)框架（注意，本書中所指的“跨平臺(tái)”若無特殊說明，即特指 Android 和 iOS 兩個(gè)平臺(tái)），根據(jù)其原理，主要分為三類：
H5 + 原生（Cordova、Ionic、微信小程序）
JavaScript 開發(fā) + 原生渲染 （React Native、Weex）
自繪UI + 原生 (Qt for mobile、Flutter)
在接下來的章節(jié)中我們逐個(gè)來看看這三類框架的原理及優(yōu)缺點(diǎn)。
這類框架主要原理就是將 App 中需要?jiǎng)討B(tài)變動(dòng)的內(nèi)容通過HTML5（簡稱 H5）來實(shí)現(xiàn)，通過原生的網(wǎng)頁加載控件WebView （Android）或 WKWebView（iOS）來加載（以后若無特殊說明，我們用WebView來統(tǒng)一指代 Android 和 iOS 中的網(wǎng)頁加載控件）。這種方案中，H5 部分是可以隨時(shí)改變而不用發(fā)版，動(dòng)態(tài)化需求能滿足；同時(shí)，由于 H5 代碼只需要一次開發(fā)，就能同時(shí)在 Android 和 iOS 兩個(gè)平臺(tái)運(yùn)行，這也可以減小開發(fā)成本，也就是說，H5 部分功能越多，開發(fā)成本就越小。我們稱這種 H5 + 原生 的開發(fā)模式為混合開發(fā) ，采用混合模式開發(fā)的App我們稱之為混合應(yīng)用或 HTMLybrid App ，如果一個(gè)應(yīng)用的大多數(shù)功能都是 H5 實(shí)現(xiàn)的話，我們稱其為 Web App 。
目前混合開發(fā)框架的典型代表有：Cordova、Ionic 。大多數(shù) App 中都會(huì)有一些功能是 H5 開發(fā)的，至少目前為止，HTMLybrid App 仍然是最通用且最成熟的跨端解決方案。
在此，我們需要提一下小程序，目前國內(nèi)各家公司小程序應(yīng)用層的開發(fā)技術(shù)棧是 Web 技術(shù)棧，而底層渲染方式基本都是 WebView 和原生相結(jié)合的方式。
如之前所述，原生開發(fā)可以訪問平臺(tái)所有功能，而混合開發(fā)中，H5代碼是運(yùn)行在 WebView 中，而 WebView 實(shí)質(zhì)上就是一個(gè)瀏覽器內(nèi)核，其 JavaScript 依然運(yùn)行在一個(gè)權(quán)限受限的沙箱中，所以對(duì)于大多數(shù)系統(tǒng)能力都沒有訪問權(quán)限，如無法訪問文件系統(tǒng)、不能使用藍(lán)牙等。所以，對(duì)于 H5 不能實(shí)現(xiàn)的功能，就需要原生去做了。
混合框架一般都會(huì)在原生代碼中預(yù)先實(shí)現(xiàn)一些訪問系統(tǒng)能力的 API ， 然后暴露給 WebView 以供 JavaScript 調(diào)用。這樣一來，WebView 中 JavaScript 與原生 API 之間就需要一個(gè)通信的橋梁，主要負(fù)責(zé) JavaScript 與原生之間傳遞調(diào)用消息，而消息的傳遞必須遵守一個(gè)標(biāo)準(zhǔn)的協(xié)議，它規(guī)定了消息的格式與含義，我們把依賴于 WebView 的用于在 JavaScript 與原生之間通信并實(shí)現(xiàn)了某種消息傳輸協(xié)議的工具稱之為 WebView JavaScript Bridge , 簡稱 JsBridge，它也是混合開發(fā)框架的核心。
下面我們以 Android 為例，實(shí)現(xiàn)一個(gè)獲取手機(jī)型號(hào)的原生 API 供 JavaScript 調(diào)用。在這個(gè)示例中將展示 JavaScript 調(diào)用原生 API 的流程，讀者可以直觀的感受一下調(diào)用流程。我們選用筆者在Github上開源的 dsBridge作為 JsBridge 來進(jìn)行通信。dsBridge 是筆者實(shí)現(xiàn)的一個(gè)跨平臺(tái)的 JsBridge 庫，此示例中只使用其同步調(diào)用功能。
首先在原生中實(shí)現(xiàn)獲取手機(jī)型號(hào)的API getPhoneModel
class JSAPI {
@JavascriptInterface
public Object getPhoneModel(Object msg) {
return Build.MODEL;
}}將原生API通過WebView注冊到JsBridge中
import wendu.dsbridge.DWebView...//DWebView繼承自WebView，由dsBridge提供 DWebView dwebView = (DWebView) findViewById(R.id.dwebview);//注冊原生API到JsBridgedwebView.addJavascriptObject(new JsAPI(), null);
在JavaScript中調(diào)用原生API
var dsBridge = require("dsbridge")//直接調(diào)用原生API `getPhoneModel`var model = dsBridge.call("getPhoneModel");//打印機(jī)型console.log(model);上面示例演示了 JavaScript 調(diào)用原生 API 的過程，同樣的，一般來說優(yōu)秀的 JsBridge 也支持原生調(diào)用 JavaScript ，dsBridge 也是支持的，如果您感興趣，可以去 Github dsBridge 項(xiàng)目主頁查看。
現(xiàn)在，我們回頭來看一下，混合應(yīng)用無非就是在第一步中預(yù)先實(shí)現(xiàn)一系列 API 供 JavaScript 調(diào)用，讓 JavaScript 有訪問系統(tǒng)功能的能力，看到這里，我相信你也可以自己實(shí)現(xiàn)一個(gè)混合開發(fā)框架了。
混合應(yīng)用的優(yōu)點(diǎn)是動(dòng)態(tài)內(nèi)容是 H5，Web 技術(shù)棧，社區(qū)及資源豐富，缺點(diǎn)是性能體驗(yàn)不佳，對(duì)于復(fù)雜用戶界面或動(dòng)畫，WebView 有時(shí)會(huì)不堪重任。
本篇主要介紹一下 JavaScript開發(fā) + 原生渲染 的跨平臺(tái)框架原理。
React Native （簡稱 RN ）是 Facebook 于 2015 年 4 月開源的跨平臺(tái)移動(dòng)應(yīng)用開發(fā)框架，是 Facebook 早先開源的 Web 框架 React 在原生移動(dòng)應(yīng)用平臺(tái)的衍生產(chǎn)物，目前支持 iOS 和 Android 兩個(gè)平臺(tái)。RN 使用JSX 語言（擴(kuò)展后的 JavaScript，主要是可以在 JavaScript 中寫 HTML標(biāo)簽）和 CSS 來開發(fā)移動(dòng)應(yīng)用。因此，熟悉 Web 前端開發(fā)的技術(shù)人員只需很少的學(xué)習(xí)就可以進(jìn)入移動(dòng)應(yīng)用開發(fā)領(lǐng)域。
由于 RN 和 React 原理相通，并且 Flutter在應(yīng)用層也是受 React 啟發(fā)，很多思想也都是相通的，因此，我們有必要深入了解一下React原理。
React 是一個(gè)響應(yīng)式的 Web 框架，我們先了解一下兩個(gè)重要的概念：DOM 樹與響應(yīng)式編程。
文檔對(duì)象模型（Document Object Model，簡稱DOM），是 W3C 組織推薦的處理可擴(kuò)展標(biāo)志語言的標(biāo)準(zhǔn)編程接口，一種獨(dú)立于平臺(tái)和語言的方式訪問和修改一個(gè)文檔的內(nèi)容和結(jié)構(gòu)。換句話說，這是表示和處理一個(gè) HTML 或XML 文檔的標(biāo)準(zhǔn)接口。簡單來說，DOM 就是文檔樹，與用戶界面控件樹對(duì)應(yīng)，在前端開發(fā)中通常指 HTML 對(duì)應(yīng)的渲染樹，但廣義的 DOM 也可以指 Android 中的 XML 布局文件對(duì)應(yīng)的控件樹，而術(shù)語DOM操作就是指直接來操作渲染樹（或控件樹）， 因此，可以看到其實(shí) DOM 樹和控件樹是等價(jià)的概念，只不過前者常用于 Web 開發(fā)中，而后者常用于原生開發(fā)中。
React 中提出一個(gè)重要思想：狀態(tài)改變則UI隨之自動(dòng)改變。而 React 框架本身就是響應(yīng)用戶狀態(tài)改變的事件而執(zhí)行重新構(gòu)建用戶界面的工作，這就是典型的 響應(yīng)式 編程范式，下面我們總結(jié)一下 React 中響應(yīng)式原理：
開發(fā)者只需關(guān)注狀態(tài)轉(zhuǎn)移（數(shù)據(jù)），當(dāng)狀態(tài)發(fā)生變化，React 框架會(huì)自動(dòng)根據(jù)新的狀態(tài)重新構(gòu)建UI。
React 框架在接收到用戶狀態(tài)改變通知后，會(huì)根據(jù)當(dāng)前渲染樹，結(jié)合最新的狀態(tài)改變，通過 Diff 算法，計(jì)算出樹中變化的部分，然后只更新變化的部分（DOM操作），從而避免整棵樹重構(gòu)，提高性能。
值得注意的是，在第二步中，狀態(tài)變化后 React 框架并不會(huì)立即去計(jì)算并渲染 DOM 樹的變化部分，相反，React會(huì)在 DOM 樹的基礎(chǔ)上建立一個(gè)抽象層，即虛擬DOM樹，對(duì)數(shù)據(jù)和狀態(tài)所做的任何改動(dòng)，都會(huì)被自動(dòng)且高效的同步到虛擬 DOM ，最后再批量同步到真實(shí) DOM 中，而不是每次改變都去操作一下DOM。
為什么不能每次改變都直接去操作 DOM 樹？這是因?yàn)樵跒g覽器中每一次 DOM 操作都有可能引起瀏覽器的重繪或回流（重新排版布局，確定 DOM 節(jié)點(diǎn)的大小和位置）：
如果 DOM 只是外觀風(fēng)格發(fā)生變化，如顏色變化，會(huì)導(dǎo)致瀏覽器重繪界面。
如果 DOM 樹的結(jié)構(gòu)發(fā)生變化，如尺寸、布局、節(jié)點(diǎn)隱藏等導(dǎo)致，瀏覽器就需要回流。
而瀏覽器的重繪和回流都是比較昂貴的操作，如果每一次改變都直接對(duì) DOM 進(jìn)行操作，這會(huì)帶來性能問題，而批量操作只會(huì)觸發(fā)一次 DOM 更新，會(huì)有更高的性能。
思考題：Diff操作和DOM批量更新難道不應(yīng)該是瀏覽器的職責(zé)嗎？第三方框架中去做合不合適？
上文已經(jīng)提到 React Native 是 React 在原生移動(dòng)應(yīng)用平臺(tái)的衍生產(chǎn)物，那兩者主要的區(qū)別是什么呢？其實(shí)，主要的區(qū)別在于虛擬 DOM 映射的對(duì)象是什么。React中虛擬 DOM 最終會(huì)映射為瀏覽器 DOM 樹，而 RN 中虛擬 DOM會(huì)通過 JavaScriptCore 映射為原生控件。
JavaScriptCore 是一個(gè)JavaScript解釋器，它在React Native中主要有兩個(gè)作用：
為 JavaScript 提供運(yùn)行環(huán)境。
是 JavaScript 與原生應(yīng)用之間通信的橋梁，作用和 JsBridge 一樣，事實(shí)上，在 iOS 中，很多 JsBridge 的實(shí)現(xiàn)都是基于 JavaScriptCore 。
而 RN 中將虛擬 DOM 映射為原生控件的過程主要分兩步：
布局消息傳遞； 將虛擬 DOM 布局信息傳遞給原生；
原生根據(jù)布局信息通過對(duì)應(yīng)的原生控件渲染；
至此，React Native 便實(shí)現(xiàn)了跨平臺(tái)。 相對(duì)于混合應(yīng)用，由于React Native是 原生控件渲染，所以性能會(huì)比混合應(yīng)用中 H5 好一些，同時(shí) React Native 提供了很多原生組件對(duì)應(yīng)的 Web 組件，大多數(shù)情況下開發(fā)者只需要使用 Web 技術(shù)棧 就能開發(fā)出 App。我們可以發(fā)現(xiàn)，這樣也就做到了維護(hù)一份代碼，便可以跨平臺(tái)了。
Weex 是阿里巴巴于 2016 年發(fā)布的跨平臺(tái)移動(dòng)端開發(fā)框架，思想及原理和 React Native 類似，底層都是通過原生渲染的，不同是應(yīng)用層開發(fā)語法 （即 DSL，Domain Specific Language）：Weex 支持 Vue 語法和 Rax 語法，Rax 的 DSL(Domain Specific Language) 語法是基于 React JSX 語法而創(chuàng)造，而 RN 的 DSL 是基于 React 的，不支持 Vue。
JavaScript 開發(fā) + 原生渲染 的方式主要優(yōu)點(diǎn)如下：
采用 Web 開發(fā)技術(shù)棧，社區(qū)龐大、上手快、開發(fā)成本相對(duì)較低。
原生渲染，性能相比 H5 提高很多。
動(dòng)態(tài)化較好，支持熱更新。
不足：
渲染時(shí)需要 JavaScript 和原生之間通信，在有些場景如拖動(dòng)可能會(huì)因?yàn)橥ㄐ蓬l繁導(dǎo)致卡頓。
JavaScript 為腳本語言，執(zhí)行時(shí)需要解釋執(zhí)行 （這種執(zhí)行方式通常稱為 JIT，即 Just In Time，指在執(zhí)行時(shí)實(shí)時(shí)生成機(jī)器碼），執(zhí)行效率和編譯類語言（編譯類語言的執(zhí)行方式為 AOT ，即 Ahead Of Time，指在代碼執(zhí)行前已經(jīng)將源碼進(jìn)行了預(yù)處理，這種預(yù)處理通常情況下是將源碼編譯為機(jī)器碼或某種中間碼）仍有差距。
由于渲染依賴原生控件，不同平臺(tái)的控件需要單獨(dú)維護(hù)，并且當(dāng)系統(tǒng)更新時(shí)，社區(qū)控件可能會(huì)滯后；除此之外，其控件系統(tǒng)也會(huì)受到原生UI系統(tǒng)限制，例如，在 Android 中，手勢沖突消歧規(guī)則是固定的，這在使用不同人寫的控件嵌套時(shí)，手勢沖突問題將會(huì)變得非常棘手。這就會(huì)導(dǎo)致，如果需要自定義原生渲染組件時(shí)，開發(fā)和維護(hù)成本過高。
我們看看最后一種跨平臺(tái)技術(shù)：自繪UI + 原生。這種技術(shù)的思路是：通過在不同平臺(tái)實(shí)現(xiàn)一個(gè)統(tǒng)一接口的渲染引擎來繪制UI，而不依賴系統(tǒng)原生控件，所以可以做到不同平臺(tái)UI的一致性。
注意，自繪引擎解決的是 UI 的跨平臺(tái)問題，如果涉及其他系統(tǒng)能力調(diào)用，依然要涉及原生開發(fā)。這種平臺(tái)技術(shù)的優(yōu)點(diǎn)如下：
性能高；由于自繪引擎是直接調(diào)用系統(tǒng)API來繪制UI，所以性能和原生控件接近。
靈活、組件庫易維護(hù)、UI外觀保真度和一致性高；由于UI渲染不依賴原生控件，也就不需要根據(jù)不同平臺(tái)的控件單獨(dú)維護(hù)一套組件庫，所以代碼容易維護(hù)。由于組件庫是同一套代碼、同一個(gè)渲染引擎，所以在不同平臺(tái)，組件顯示外觀可以做到高保真和高一致性；另外，由于不依賴原生控件，也就不會(huì)受原生布局系統(tǒng)的限制，這樣布局系統(tǒng)會(huì)非常靈活。
不足：
動(dòng)態(tài)性不足；為了保證UI繪制性能，自繪UI系統(tǒng)一般都會(huì)采用 AOT 模式編譯其發(fā)布包，所以應(yīng)用發(fā)布后，不能像 Hybrid 和 RN 那些使用 JavaScript（JIT）作為開發(fā)語言的框架那樣動(dòng)態(tài)下發(fā)代碼。
應(yīng)用開發(fā)效率低：Qt 使用 C++ 作為其開發(fā)語言，而編程效率是直接會(huì)影響 App 開發(fā)效率的，C++ 作為一門靜態(tài)語言，在 UI 開發(fā)方面靈活性不及 JavaScript 這樣的動(dòng)態(tài)語言，另外，C++需要開發(fā)者手動(dòng)去管理內(nèi)存分配，沒有 JavaScript 及Java中垃圾回收（GC）的機(jī)制。
也許你已經(jīng)猜到 Flutter 就屬于這一類跨平臺(tái)技術(shù)，沒錯(cuò)，F(xiàn)lutter 正是實(shí)現(xiàn)一套自繪引擎，并擁有一套自己的 UI 布局系統(tǒng)，且同時(shí)在開發(fā)效率上有了很大突破。不過，自繪制引擎的思路并不是什么新概念，F(xiàn)lutter并不是第一個(gè)嘗試這么做的，在它之前有一個(gè)典型的代表，即大名鼎鼎的Qt。
Qt 是一個(gè)1991年由 Qt Company 開發(fā)的跨平臺(tái) C++ 圖形用戶界面應(yīng)用程序開發(fā)框架。2008年，Qt Company 科技被諾基亞公司收購，Qt 也因此成為諾基亞旗下的編程語言工具。2012年，Qt 被 Digia 收購。2014年4月，跨平臺(tái)集成開發(fā)環(huán)境 Qt Creator 3.1.0 正式發(fā)布，實(shí)現(xiàn)了對(duì)于 iOS 的完全支持，新增 WinRT、Beautifier 等插件，廢棄了無 Python 接口的 GDB 調(diào)試支持，集成了基于 Clang 的 C/C++ 代碼模塊，并對(duì) Android 支持做出了調(diào)整，至此實(shí)現(xiàn)了全面支持 iOS、Android、WP，它提供給應(yīng)用程序開發(fā)者構(gòu)建圖形用戶界面所需的所有功能。
但是，Qt 雖然在 PC 端獲得了巨大成功，備受社區(qū)追捧，然而其在移動(dòng)端卻表現(xiàn)不佳，在近幾年，雖然偶爾能聽到 Qt 的聲音，但一直很弱，無論 Qt 本身技術(shù)如何、設(shè)計(jì)思想如何，但事實(shí)上終究是敗了，究其原因，筆者認(rèn)為主要有四：
第一：Qt 移動(dòng)開發(fā)社區(qū)太小，學(xué)習(xí)資料不足，生態(tài)不好。
第二：官方推廣不利，支持不夠。
第三：移動(dòng)端發(fā)力較晚，市場已被其他動(dòng)態(tài)化框架占領(lǐng)（ Hybrid 和 RN )。
第四：在移動(dòng)開發(fā)中，C++ 開發(fā)和Web開發(fā)棧相比有著先天的劣勢，直接結(jié)果就是 Qt 開發(fā)效率太低。
基于此四點(diǎn)，盡管 Qt 是移動(dòng)端開發(fā)跨平臺(tái)自繪引擎的先驅(qū)，但卻成為了烈士。
“千呼萬喚始出來”，鋪墊這么久，現(xiàn)在終于等到本書的主角出場了！
Flutter 是 Google 發(fā)布的一個(gè)用于創(chuàng)建跨平臺(tái)、高性能移動(dòng)應(yīng)用的框架。Flutter 和 Qt mobile 一樣，都沒有使用原生控件，相反都實(shí)現(xiàn)了一個(gè)自繪引擎，使用自身的布局、繪制系統(tǒng)。那么，我們會(huì)擔(dān)心，Qt mobile 面對(duì)的問題Flutter是否也一樣，F(xiàn)lutter會(huì)不會(huì)步入Qt mobile后塵，成為另一個(gè)烈士？要回到這個(gè)問題，我們先來看看Flutter誕生過程：從 2017 年 Google I/O 大會(huì)上，Google 首次發(fā)布 Flutter 到 2021年8月底，已經(jīng)有 127K 的 Star，Star 數(shù)量 Github 上排名前 20 。經(jīng)歷了4年多的時(shí)間，F(xiàn)lutter 生態(tài)系統(tǒng)得以快速增長，國內(nèi)外有非常多基于 Flutter 的成功案例，國內(nèi)的互聯(lián)網(wǎng)公司基本都有專門的 Flutter 團(tuán)隊(duì)?？傊?，歷時(shí) 4 年，F(xiàn)lutter 發(fā)展飛快，已在業(yè)界得到了廣泛的關(guān)注和認(rèn)可，在開發(fā)者中受到了熱烈的歡迎，成為了移動(dòng)跨端開發(fā)中最受歡迎的框架之一。
現(xiàn)在，我們來和 Qt mobile做一個(gè)對(duì)比：
生態(tài)：Flutter 生態(tài)系統(tǒng)發(fā)展迅速，社區(qū)非?；钴S，無論是開發(fā)者數(shù)量還是第三方組件都已經(jīng)非?？捎^。
技術(shù)支持：現(xiàn)在 Google 正在大力推廣Flutter，F(xiàn)lutter 的作者中很多人都是來自Chromium團(tuán)隊(duì)，并且 Github上活躍度很高。另一個(gè)角度，從 Flutter 誕生到現(xiàn)在，頻繁的版本發(fā)布也可以看出 Google 對(duì) Flutter的投入的資源不小，所以在官方技術(shù)支持這方面，大可不必?fù)?dān)心。
開發(fā)效率：一套代碼，多端運(yùn)行；并且在開發(fā)過程中 Flutter 的熱重載可幫助開發(fā)者快速地進(jìn)行測試、構(gòu)建UI、添加功能并更快地修復(fù)錯(cuò)誤。在 iOS 和 Android 模擬器或真機(jī)上可以實(shí)現(xiàn)毫秒級(jí)熱重載，并且不會(huì)丟失狀態(tài)。這真的很棒，相信我，如果你是一名原生開發(fā)者，體驗(yàn)了Flutter開發(fā)流后，很可能就不想重新回去做原生了，畢竟很少有人不吐槽原生開發(fā)的編譯速度。
基于以上三點(diǎn)，相信讀者和筆者一樣，已經(jīng)迫不及待的想要去了解一下 Flutter 了。到現(xiàn)在為止，我們已經(jīng)對(duì)移動(dòng)端開發(fā)技術(shù)有了一個(gè)全面的了解，接下來我們便要進(jìn)入本書的主題，你準(zhǔn)備好了嗎！
本章主要介紹了目前移動(dòng)開發(fā)中三種跨平臺(tái)技術(shù)，現(xiàn)在我們從框架角度對(duì)比一下它們，如表1-1所示：
| 技術(shù)類型 | UI渲染方式 | 性能 | 開發(fā)效率 | 動(dòng)態(tài)化 | 框架代表 |
|---|---|---|---|---|---|
| H5 + 原生 | WebView渲染 | 一般 | 高 | 支持 | Cordova、Ionic |
| JavaScript + 原生渲染 | 原生控件渲染 | 好 | 中 | 支持 | RN、Weex |
| 自繪UI + 原生 | 調(diào)用系統(tǒng)API渲染 | 好 | Flutter高, Qt低 | 默認(rèn)不支持 | Qt、Flutter |
上表中開發(fā)語言主要指應(yīng)用層的開發(fā)語言，而開發(fā)效率，是指整個(gè)開發(fā)周期的效率，包括編碼時(shí)間、調(diào)試時(shí)間、以及排錯(cuò)、處理兼容性問題時(shí)間。動(dòng)態(tài)化主要指是否支持動(dòng)態(tài)下發(fā)代碼和是否支持熱更新。值得注意的是 Flutter 的Release 包默認(rèn)是使用 Dart AOT 模式編譯的，所以不支持動(dòng)態(tài)化，但 Dart 還有 JIT 或 snapshot 運(yùn)行方式，這些模式都是支持動(dòng)態(tài)化的。
聯(lián)系客服
