原生開發(fā)

原生應(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)勢(shì)：

• 可訪問平臺(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ù)場(chǎng)景并不復(fù)雜，原生開發(fā)還可以應(yīng)對(duì)產(chǎn)品需求迭代。 但近幾年，隨著物聯(lián)網(wǎng)時(shí)代到來、移動(dòng)互聯(lián)網(wǎng)高歌猛進(jìn)，日新月異，在很多業(yè)務(wù)場(chǎng)景中，傳統(tǒng)的純?cè)_發(fā)已經(jīng)不能滿足日益增長(zhǎng)的業(yè)務(wù)需求。主要表現(xiàn)在：

• 動(dòng)態(tài)化內(nèi)容需求增大；當(dāng)需求發(fā)生變化時(shí)，純?cè)鷳?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í)，無論人力成本，還是測(cè)試成本都會(huì)變大。

總結(jié)一下，純?cè)_發(fā)主要面臨動(dòng)態(tài)化和開發(fā)成本兩個(gè)問題，而針對(duì)這兩個(gè)問題，誕生了一些跨平臺(tái)的動(dòng)態(tài)化框架。

跨平臺(tái)開發(fā)

針對(duì)原生開發(fā)面臨問題，人們一直都在努力尋找好的解決方案，而時(shí)至今日，已經(jīng)有很多跨平臺(tái)框架(注意，本書中所指的“跨平臺(tái)”若無特殊說明，即特指Android和iOS兩個(gè)平臺(tái))，根據(jù)其原理，主要分為三類：

• H5+原生（Cordova、Ionic、微信小程序）
• JavaScript開發(fā)+原生渲染 （React Native、Weex、快應(yīng)用）
• 自繪UI+原生(QT for mobile、Flutter)

一、H5+原生混合開發(fā)

這類框架主要原理就是將APP的一部分需要?jiǎng)討B(tài)變動(dòng)的內(nèi)容通過H5來實(shí)現(xiàn)，通過原生的網(wǎng)頁加載控件WebView (Android)或WKWebView（ios）來加載。這樣一來，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)用或Hybrid APP ，如果一個(gè)應(yīng)用的大多數(shù)功能都是H5實(shí)現(xiàn)的話，我們稱其為Web APP 。

目前混合開發(fā)框架的典型代表有：Cordova、Ionic 和微信小程序，值得一提的是微信小程序目前是在webview中渲染的，并非原生渲染，但將來有可能會(huì)采用原生渲染。

如之前所述，原生開發(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之間通信的橋梁，主要負(fù)責(zé)JavaScript與原生之間傳遞調(diào)用消息，而消息的傳遞必須遵守一個(gè)標(biāo)準(zhǔn)的協(xié)議，它規(guī)定了消息的格式與含義，我們把依賴于WebView的用于在JavaScript與原生之間通信并實(shí)現(xiàn)了某種消息傳輸協(xié)議的工具稱之為WebView JavaScript Bridge, 簡(jiǎn)稱 JsBridge，它也是混合開發(fā)框架的核心。

混合應(yīng)用的優(yōu)點(diǎn)是動(dòng)態(tài)內(nèi)容是H5，web技術(shù)棧，社區(qū)及資源豐富，缺點(diǎn)是性能不好，對(duì)于復(fù)雜用戶界面或動(dòng)畫，webview不堪重任。

二、JavaScript開發(fā)+原生渲染

1、React Native

React Native (簡(jiǎn)稱RN)是Facebook于2015年4月開源的跨平臺(tái)移動(dòng)應(yīng)用開發(fā)框架，是Facebook早先開源的JS框架 React 在原生移動(dòng)應(yīng)用平臺(tái)的衍生產(chǎn)物，目前支持iOS和Android兩個(gè)平臺(tái)。RN使用Javascript語言，類似于HTML的JSX，以及CSS來開發(fā)移動(dòng)應(yīng)用，因此熟悉Web前端開發(fā)的技術(shù)人員只需很少的學(xué)習(xí)就可以進(jìn)入移動(dòng)應(yīng)用開發(fā)領(lǐng)域。

由于RN和React原理相通，并且Flutter也是受React啟發(fā)，很多思想也都是相通的，萬丈高樓平地起，我們有必要深入了解一下React原理。React是一個(gè)響應(yīng)式的Web框架，我們先了解一下兩個(gè)重要的概念：Dom樹與響應(yīng)式編程。

DOM樹與控件樹

文檔對(duì)象模型（Document Object Model，簡(jiǎn)稱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)接口。簡(jiǎn)單來說，DOM就是文檔樹，與用戶界面控件樹對(duì)應(yīng)，在前端開發(fā)中通常指HTML對(duì)應(yīng)的渲染樹，但廣義的DOM也可以指Android中的XML布局文件對(duì)應(yīng)的控件樹，而術(shù)語DOM操作就是指直接來操作渲染樹（或控件樹）， 因此，可以看到其實(shí)DOM樹和控件樹是等價(jià)的概念，只不過前者常用語Web開發(fā)中，而后者常用于原生開發(fā)中。

響應(yīng)式編程

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操作都有可能引起瀏覽器的重繪或回流：

1. 如果DOM只是外觀風(fēng)格發(fā)生變化，如顏色變化，會(huì)導(dǎo)致瀏覽器重繪界面。
2. 如果DOM樹的結(jié)構(gòu)發(fā)生變化，如尺寸、布局、節(jié)點(diǎn)隱藏等導(dǎo)致，瀏覽器就需要回流（及重新排版布局）。

而瀏覽器的重繪和回流都是比較昂貴的操作，如果每一次改變都直接對(duì)DOM進(jìn)行操作，這會(huì)帶來性能問題，而批量操作只會(huì)觸發(fā)一次DOM更新。

React Native與React的區(qū)別

React中虛擬DOM最終會(huì)映射為瀏覽器DOM樹，而RN中虛擬DOM會(huì)通過 JavaScriptCore 映射為原生控件樹。

JavaScriptCore 是一個(gè)JavaScript解釋器，它在React Native中主要有兩個(gè)作用：

1. 為JavaScript提供運(yùn)行環(huán)境。
2. 是JavaScript與原生應(yīng)用之間通信的橋梁，作用和JsBridge一樣，事實(shí)上，在iOS中，很多JsBridge的實(shí)現(xiàn)都是基于 JavaScriptCore 。

而RN中將虛擬DOM映射為原生控件的過程中分兩步：

1. 布局消息傳遞； 將虛擬DOM布局信息傳遞給原生；
2. 原生根據(jù)布局信息通過對(duì)應(yīng)的原生控件渲染控件樹；

至此，React Native 便實(shí)現(xiàn)了跨平臺(tái)。 相對(duì)于混合應(yīng)用，由于React Native是原生控件渲染，所以性能會(huì)比混合應(yīng)用中H5好很多，同時(shí)React Native是Web開發(fā)技術(shù)棧，也只需維護(hù)一份代碼，同樣是跨平臺(tái)框架。

2、Weex

Weex是阿里巴巴于2016年發(fā)布的跨平臺(tái)移動(dòng)端開發(fā)框架，思想及原理和React Native類似，最大的不同是語法層面，Weex支持Vue語法和Rax語法，Rax 的 DSL 語法是基于 React JSX 語法而創(chuàng)造。與 React 不同，在 Rax 中 JSX 是必選的，它不支持通過其它方式創(chuàng)建組件，所以學(xué)習(xí) JSX 是使用 Rax 的必要基礎(chǔ)。而React Native只支持JSX語法。

3、快應(yīng)用

快應(yīng)用是華為、小米、OPPO、魅族等國(guó)內(nèi)9大主流手機(jī)廠商共同制定的輕量級(jí)應(yīng)用標(biāo)準(zhǔn)，目標(biāo)直指微信小程序。它也是采用JavaScript語言開發(fā)，原生控件渲染，與React Native和Weex相比主要有兩點(diǎn)不同：

1. 快應(yīng)用自身不支持Vue或React語法，其采用原生JavaScript開發(fā)，其開發(fā)框架和微信小程序很像，值得一提的是小程序目前已經(jīng)可以使用Vue語法開發(fā)（mpvue），從原理上來講，Vue的語法也可以移植到快應(yīng)用上。
2. React Native和Weex的渲染/排版引擎是集成到框架中的，每一個(gè)APP都需要打包一份，安裝包體積較大；而快應(yīng)用渲染/排版引擎是集成到ROM中的，應(yīng)用中無需打包，安裝包體積小，正因如此，快應(yīng)用才能在保證性能的同時(shí)做到快速分發(fā)。

總結(jié)

JavaScript開發(fā)+原生渲染的方式主要優(yōu)點(diǎn)如下：

1. 采用Web開發(fā)技術(shù)棧，社區(qū)龐大、上手快、開發(fā)成本相對(duì)較低。
2. 原生渲染，性能相比H5提高很多。
3. 動(dòng)態(tài)化較好，支持熱更新。

不足：

1. 渲染時(shí)需要JavaScript和原生之間通信，在有些場(chǎng)景如拖動(dòng)可能會(huì)因?yàn)橥ㄐ蓬l繁導(dǎo)致卡頓。
2. JavaScript為腳本語言，執(zhí)行時(shí)需要JIT，執(zhí)行效率和AOT代碼仍有差距。
3. 由于渲染依賴原生控件，不同平臺(tái)的控件需要單獨(dú)維護(hù)，并且當(dāng)系統(tǒng)更新時(shí)，社區(qū)控件可能會(huì)滯后；除此之外，其控件系統(tǒng)也會(huì)受到原生UI系統(tǒng)限制，例如，在Android中，手勢(shì)沖突消歧規(guī)則是固定的，這在使用不同人寫的控件嵌套時(shí)，手勢(shì)沖突問題將會(huì)變得非常棘手。

三、自繪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)如下：

1. 性能高；由于自繪引擎是直接調(diào)用系統(tǒng)API來繪制UI，所以性能和原生控件接近。

2. 靈活、組件庫易維護(hù)、UI外觀保真度和一致性高；由于UI渲染不依賴原生控件，也就不需要根據(jù)不同平臺(tái)的控件單獨(dú)維護(hù)一套組件庫，所以代碼容易維護(hù)。由于組件庫是同一套代碼、同一個(gè)渲染引擎，所以在不同平臺(tái)，組件顯示外觀可以做到高保真和高一致性；另外，由于不依賴原生控件，也就不會(huì)受原生布局系統(tǒng)的限制，這樣布局系統(tǒng)會(huì)非常靈活。

不足：

1. 動(dòng)態(tài)性不足；為了保證UI繪制性能，自繪UI系統(tǒng)一般都會(huì)采用AOT模式編譯其發(fā)布包，所以應(yīng)用發(fā)布后，不能像Hybrid和RN那些使用JavaScript（JIT）作為開發(fā)語言的框架那樣動(dòng)態(tài)下發(fā)代碼。

1、QT簡(jiǎn)介

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ā)力較晚，市場(chǎng)已被其它動(dòng)態(tài)化框架占領(lǐng)（Hybrid和RN)。
• 在移動(dòng)開發(fā)中，C++開發(fā)和Web開發(fā)棧相比有著先天的劣勢(shì)，直接結(jié)果就是QT開發(fā)效率太低。

基于此四點(diǎn)，盡管QT是移動(dòng)端開發(fā)跨平臺(tái)自繪引擎的先驅(qū)，但卻成為了烈士。

2、Flutter簡(jiǎn)介

Flutter 是 Google推出并開源的移動(dòng)應(yīng)用開發(fā)框架，主打跨平臺(tái)、高保真、高性能。開發(fā)者可以通過 Dart語言開發(fā) App，一套代碼同時(shí)運(yùn)行在 iOS 和 Android平臺(tái)。 Flutter提供了豐富的組件、接口，開發(fā)者可以很快地為 Flutter添加 native擴(kuò)展。同時(shí) Flutter還使用 Native引擎渲染視圖，這無疑能為用戶提供良好的體驗(yàn)。

跨平臺(tái)自繪引擎

Flutter與用于構(gòu)建移動(dòng)應(yīng)用程序的其它大多數(shù)框架不同，因?yàn)镕lutter既不使用WebView，也不使用操作系統(tǒng)的原生控件。 相反，F(xiàn)lutter使用自己的高性能渲染引擎來繪制widget。這樣不僅可以保證在Android和iOS上UI的一致性，而且也可以避免對(duì)原生控件依賴而帶來的限制及高昂的維護(hù)成本。

Flutter使用Skia作為其2D渲染引擎，Skia是Google的一個(gè)2D圖形處理函數(shù)庫，包含字型、坐標(biāo)轉(zhuǎn)換，以及點(diǎn)陣圖都有高效能且簡(jiǎn)潔的表現(xiàn)，Skia是跨平臺(tái)的，并提供了非常友好的API，目前Google Chrome瀏覽器和Android均采用Skia作為其繪圖引擎，值得一提的是，由于Android系統(tǒng)已經(jīng)內(nèi)置了Skia，所以Flutter在打包APK(Android應(yīng)用安裝包)時(shí)，不需要再將Skia打入APK中，但iOS系統(tǒng)并未內(nèi)置Skia，所以構(gòu)建iPA時(shí)，也必須將Skia一起打包，這也是為什么Flutter APP的Android安裝包比iOS安裝包小的主要原因。

高性能

Flutter高性能主要靠?jī)牲c(diǎn)來保證，首先，F(xiàn)lutter APP采用Dart語言開發(fā)。Dart在 JIT（即時(shí)編譯）模式下，速度與 JavaScript基本持平。但是 Dart支持 AOT，當(dāng)以 AOT模式運(yùn)行時(shí)，JavaScript便遠(yuǎn)遠(yuǎn)追不上了。速度的提升對(duì)高幀率下的視圖數(shù)據(jù)計(jì)算很有幫助。其次，F(xiàn)lutter使用自己的渲染引擎來繪制UI，布局?jǐn)?shù)據(jù)等由Dart語言直接控制，所以在布局過程中不需要像RN那樣要在JavaScript和Native之間通信，這在一些滑動(dòng)和拖動(dòng)的場(chǎng)景下具有明顯優(yōu)勢(shì)，因?yàn)樵诨瑒?dòng)和拖動(dòng)過程往往都會(huì)引起布局發(fā)生變化，所以JavaScript需要和Native之間不停的同步布局信息，這和在瀏覽器中要JavaScript頻繁操作DOM所帶來的問題是相同的，都會(huì)帶來比較可觀的性能開銷。

采用Dart語言開發(fā)

這是一個(gè)很有意思，但也很有爭(zhēng)議的問題，在了解Flutter為什么選擇了 Dart而不是 JavaScript之前我們先來介紹兩個(gè)概念：JIT和AOT。

目前，程序主要有兩種運(yùn)行方式：靜態(tài)編譯與動(dòng)態(tài)解釋。靜態(tài)編譯的程序在執(zhí)行前全部被翻譯為機(jī)器碼，通常將這種類型稱為AOT （Ahead of time）即 “提前編譯”；而解釋執(zhí)行的則是一句一句邊翻譯邊運(yùn)行，通常將這種類型稱為JIT（Just-in-time）即“即時(shí)編譯”。AOT程序的典型代表是用C/C++開發(fā)的應(yīng)用，它們必須在執(zhí)行前編譯成機(jī)器碼，而JIT的代表則非常多，如JavaScript、python等，事實(shí)上，所有腳本語言都支持JIT模式。但需要注意的是JIT和AOT指的是程序運(yùn)行方式，和編程語言并非強(qiáng)關(guān)聯(lián)的，有些語言既可以以JIT方式運(yùn)行也可以以AOT方式運(yùn)行，如Java、Python，它們可以在第一次執(zhí)行時(shí)編譯成中間字節(jié)碼、然后在之后執(zhí)行時(shí)可以直接執(zhí)行字節(jié)碼，也許有人會(huì)說，中間字節(jié)碼并非機(jī)器碼，在程序執(zhí)行時(shí)仍然需要?jiǎng)討B(tài)將字節(jié)碼轉(zhuǎn)為機(jī)器碼，是的，這沒有錯(cuò)，不過通常我們區(qū)分是否為AOT的標(biāo)準(zhǔn)就是看代碼在執(zhí)行之前是否需要編譯，只要需要編譯，無論其編譯產(chǎn)物是字節(jié)碼還是機(jī)器碼，都屬于AOT。在此，讀者不必糾結(jié)于概念，概念就是為了傳達(dá)精神而發(fā)明的，只要讀者能夠理解其原理即可，得其神忘其形。

現(xiàn)在我們看看Flutter為什么選擇Dart語言？筆者根據(jù)官方解釋以及自己對(duì)Flutter的理解總結(jié)了以下幾條（由于其它跨平臺(tái)框架都將JavaScript作為其開發(fā)語言，所以主要將Dart和JavaScript做一個(gè)對(duì)比）：

1. 開發(fā)效率高
   Dart運(yùn)行時(shí)和編譯器支持Flutter的兩個(gè)關(guān)鍵特性的組合：
   基于JIT的快速開發(fā)周期：Flutter在開發(fā)階段采用，采用JIT模式，這樣就避免了每次改動(dòng)都要進(jìn)行編譯，極大的節(jié)省了開發(fā)時(shí)間；
   基于AOT的發(fā)布包: Flutter在發(fā)布時(shí)可以通過AOT生成高效的ARM代碼以保證應(yīng)用性能。而JavaScript則不具有這個(gè)能力。

2. 高性能
   Flutter旨在提供流暢、高保真的的UI體驗(yàn)。為了實(shí)現(xiàn)這一點(diǎn)，F(xiàn)lutter中需要能夠在每個(gè)動(dòng)畫幀中運(yùn)行大量的代碼。這意味著需要一種既能提供高性能的語言，而不會(huì)出現(xiàn)會(huì)丟幀的周期性暫停，而Dart支持AOT，在這一點(diǎn)上可以做的比JavaScript更好。

3. 快速內(nèi)存分配
   Flutter框架使用函數(shù)式流，這使得它在很大程度上依賴于底層的內(nèi)存分配器。因此，擁有一個(gè)能夠有效地處理瑣碎任務(wù)的內(nèi)存分配器將顯得十分重要，在缺乏此功能的語言中，F(xiàn)lutter將無法有效地工作。當(dāng)然Chrome V8的JavaScript引擎在內(nèi)存分配上也已經(jīng)做的很好，事實(shí)上Dart開發(fā)團(tuán)隊(duì)的很多成員都是來自Chrome團(tuán)隊(duì)的，所以在內(nèi)存分配上Dart并不能作為超越JavaScript的優(yōu)勢(shì)，而對(duì)于Flutter來說，它需要這樣的特性，而Dart也正好滿足而已。

4. 類型安全
   由于Dart是類型安全的語言，支持靜態(tài)類型檢測(cè)，所以可以在編譯前發(fā)現(xiàn)一些類型的錯(cuò)誤，并排除潛在問題，這一點(diǎn)對(duì)于前端開發(fā)者來說可能會(huì)更具有吸引力。與之不同的，JavaScript是一個(gè)弱類型語言，也因此前端社區(qū)出現(xiàn)了很多給JavaScript代碼添加靜態(tài)類型檢測(cè)的擴(kuò)展語言和工具，如：微軟的TypeScript以及Facebook的Flow。相比之下，Dart本身就支持靜態(tài)類型，這是它的一個(gè)重要優(yōu)勢(shì)。

現(xiàn)在，我們來和QT mobile做一個(gè)對(duì)比：

1. 生態(tài)；從Github上來看，目前Flutter活躍用戶正在高速增長(zhǎng)。從Stackoverflow上提問來看，F(xiàn)lutter社區(qū)現(xiàn)在已經(jīng)很龐大。Flutter的文檔、資源也越來越豐富，開發(fā)過程中遇到的很多問題都可以在Stackoverflow或其github issue中找到答案。
2. 技術(shù)支持；現(xiàn)在Google正在大力推廣Flutter，F(xiàn)lutter的作者中很多人都是來自Chromium團(tuán)隊(duì)，并且github上活躍度很高。另一個(gè)角度，從今年上半年Flutter頻繁的版本發(fā)布也可以看出Google對(duì)Flutter的投入的資源不小，所以在官方技術(shù)支持這方面，大可不必?fù)?dān)心。
3. 開發(fā)效率；Flutter的熱重載可幫助開發(fā)者快速地進(jìn)行測(cè)試、構(gòu)建UI、添加功能并更快地修復(fù)錯(cuò)誤。在iOS和Android模擬器或真機(jī)上可以實(shí)現(xiàn)毫秒級(jí)熱重載，并且不會(huì)丟失狀態(tài)。這真的很棒，相信我，如果你是一名原生開發(fā)者，體驗(yàn)了Flutter開發(fā)流后，很可能就不想重新回去做原生了，畢竟很少有人不吐槽原生開發(fā)的編譯速度。

總結(jié)

本章主要介紹了目前移動(dòng)開發(fā)中三種跨平臺(tái)技術(shù)，現(xiàn)在我們從框架角度對(duì)比一下：

上表中開發(fā)語言主要指UI的開發(fā)語言，動(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)化的。