1. 導(dǎo)讀
本文約4688字，閱讀可能需要15分鐘投队。
最早的跨平臺(tái)開(kāi)發(fā)(摘自《Apache Cordova移動(dòng)應(yīng)用開(kāi)發(fā)實(shí)戰(zhàn)》王亞飛块蚌，王洪飛編著)
從廣義上來(lái)說(shuō)，跨平臺(tái)技術(shù)早于移動(dòng)端的出現(xiàn)受葛。因此朱盐，本文標(biāo)題前面也加上了一個(gè)定語(yǔ)：“移動(dòng)端”慕爬。而由上圖也可窺見(jiàn)一二：移動(dòng)端跨平臺(tái)技術(shù)幾乎和移動(dòng)端本身的歷史一樣長(zhǎng)似将。跨平臺(tái)技術(shù)之所以生命力如此強(qiáng)大痹雅，個(gè)人認(rèn)為有以下幾個(gè)原因：
開(kāi)發(fā)效率?: 這也是跨平臺(tái)技術(shù)出現(xiàn)的初衷仰担，理想狀態(tài)下，一次開(kāi)發(fā)绩社，多端運(yùn)行摔蓝，組件復(fù)用，提升效率愉耙。
對(duì)于管理者贮尉，跨平臺(tái)可以降低用人成本，避免了同時(shí)養(yǎng)兩個(gè)（Android/iOS）開(kāi)發(fā)團(tuán)隊(duì)的現(xiàn)狀
對(duì)于開(kāi)發(fā)者朴沿，跨平臺(tái)可以降低學(xué)習(xí)成本猜谚，只需要了解一套框架，就可以實(shí)現(xiàn)雙端開(kāi)發(fā)赌渣，提升了自我價(jià)值
業(yè)務(wù)價(jià)值?: 跨平臺(tái)開(kāi)發(fā)成本更低魏铅，適合產(chǎn)品的快速驗(yàn)證，待功能穩(wěn)定后再進(jìn)行性能體驗(yàn)上的優(yōu)化
二級(jí)生態(tài)?: 舉一個(gè)例子锡垄，JVM在操作系統(tǒng)上建立了自己的二級(jí)生態(tài)沦零，所有的Java開(kāi)發(fā)者只需要面向JVM編程和優(yōu)化，可以忽視操作系統(tǒng)的存在货岭。在原生路操、底層的平臺(tái)上做一層封裝，以很小的性能損失為代價(jià)千贯，為開(kāi)發(fā)者帶來(lái)巨大的效率提升屯仗，這在軟件工業(yè)是屢見(jiàn)不鮮的。二級(jí)生態(tài)有重要的戰(zhàn)略意義搔谴，掌握了二級(jí)生態(tài)魁袜，就掌握了話(huà)語(yǔ)權(quán)和影響力。所以Facebook和Google都在發(fā)力敦第。
平臺(tái)能力?: 乘上第三點(diǎn)峰弹，跨平臺(tái)還有一個(gè)好處就是擁有了自己的生態(tài)就可以開(kāi)放自己的能力，制定游戲規(guī)則讓其他開(kāi)發(fā)者參與芜果，典型有小程序（微信/QQ/支付寶）鞠呈、快應(yīng)用等
跨平臺(tái)好處頗多，但挑戰(zhàn)也不少右钾，主要集中在以下四個(gè)方面：
研發(fā)效率
工具支持程度：補(bǔ)全蚁吝、提示旱爆、構(gòu)建管理等
Debug是否方便，錯(cuò)誤日志是否詳細(xì)
文檔完備窘茁、項(xiàng)目活躍
隱藏平臺(tái)差異怀伦，如React Native需要大量橋接工作
開(kāi)發(fā)語(yǔ)言生態(tài)，js生態(tài)龐大山林，開(kāi)發(fā)者眾房待，Dart則名不見(jiàn)經(jīng)傳
等等
動(dòng)態(tài)化
iOS禁止，但國(guó)內(nèi)平臺(tái)普遍需要
多端一致性
Web方案無(wú)法還原體驗(yàn)
性能
Web方案UI繪制效率低捌朴，網(wǎng)絡(luò)流量消耗高
游戲引擎耗電嚴(yán)重吴攒，不能應(yīng)用在普通應(yīng)用開(kāi)發(fā)中
SDK引入導(dǎo)致的安裝包增量
2. 歷史行程
在過(guò)去的十多年間张抄，主流的(不考慮一些小眾砂蔽、沒(méi)有取得成功的方案)移動(dòng)端跨平臺(tái)技術(shù)經(jīng)歷了三次變革：
Hybrid，代表有：Ionic/Cordova
OEM Wrapper署惯，代表有：React Native/Weex
自渲染左驾，代表有：Flutter
從時(shí)間上看，這三種方案不是孤立的极谊，既有對(duì)前人不足之處的改進(jìn)（如UI繪制策略）诡右，也有對(duì)優(yōu)秀思想的繼承（如React的思想）。如果站在更高的高度上轻猖，我們會(huì)看到這些方案并不是在移動(dòng)端獨(dú)立演進(jìn)的帆吻。在移動(dòng)端普及之前，PC端已經(jīng)積累了很多成熟的方案咙边，對(duì)于移動(dòng)端的探索起到了指導(dǎo)作用猜煮，仔細(xì)比較一下會(huì)發(fā)現(xiàn)每一種方案都能找到已有方案的影子，只不過(guò)結(jié)合了移動(dòng)端的特點(diǎn)做了定制败许。無(wú)論哪種跨平臺(tái)方案王带，都要回答兩個(gè)問(wèn)題：
UI如何繪制
邏輯（包括用戶(hù)交互的邏輯和與宿主系統(tǒng)通訊的邏輯）如何響應(yīng)
對(duì)于這兩個(gè)問(wèn)題，Hybrid給出的答案是webview+js市殷，OEM Wrapper給出的是VirtualDOM轉(zhuǎn)Native組件+js愕撰，自渲染（Flutter）給出的答案是Skia+Dart。下文開(kāi)始詳述醋寝。
2.1. Hybrid
架構(gòu)圖
Hybrid是客戶(hù)端跨平臺(tái)技術(shù)的第一個(gè)階段搞挣，核心原理是
將原生的接口封裝后暴露給 JavaScript，可以運(yùn)行在系統(tǒng)自帶的 WebView中或者其他內(nèi)核中音羞。這種方案在上文提到的評(píng)價(jià)體系里表現(xiàn)如下：
開(kāi)發(fā)效率
對(duì)前端開(kāi)發(fā)者友好囱桨，背靠前端龐大的JavaScript生態(tài)
涉及到Native調(diào)用的部分不可避免要熟悉Android/iOS
能力受限于橋接層，擴(kuò)展性弱
在移動(dòng)端開(kāi)發(fā)黄选，調(diào)試和錯(cuò)誤日志并不是很友好
動(dòng)態(tài)化
Web天生自帶動(dòng)態(tài)能力
多端一致性
瀏覽器內(nèi)核的渲染獨(dú)立于系統(tǒng)組件蝇摸，無(wú)法保證原生體驗(yàn)
涉及宿主的問(wèn)題婶肩，需要開(kāi)發(fā)者處理，做不到完全屏蔽
性能
受限于網(wǎng)絡(luò)環(huán)境貌夕，比Native更加消耗流量
受限于瀏覽器律歼、系統(tǒng)平臺(tái)特性
渲染性能?，Webview性能差
特別指出:對(duì)于列表的支持差啡专，移動(dòng)端幾乎全是列表（feed流）
評(píng)價(jià)：Hybrid是矛盾的結(jié)合體险毁，HTML/CSS 過(guò)于復(fù)雜導(dǎo)致性能問(wèn)題，但其實(shí)這正是 Web 最大的優(yōu)勢(shì)所在们童，因?yàn)?Web 最初的目的就是顯示文檔畔况，如果你想顯示豐富的圖文排版，雖然 iOS/Android 都有富文本組件慧库，但比起 CSS 差太遠(yuǎn)了跷跪，所以在很多 Native 應(yīng)用中是不可避免要嵌 Web 的（比如很多運(yùn)營(yíng)活動(dòng)的頁(yè)面，存在周期短齐板，開(kāi)發(fā)時(shí)間短吵瞻，樣式豐富繁多，適合H5開(kāi)發(fā)）甘磨。
既然Web強(qiáng)大的的繪制能力限制了其在移動(dòng)端的性能橡羞，那么能不能對(duì)此進(jìn)行優(yōu)化? 這是一個(gè)很重要的問(wèn)題，很多看起來(lái)無(wú)關(guān)的方案都是基于這種思想發(fā)源來(lái)的：
React Native使用系統(tǒng)組件封裝济舆，可以認(rèn)為是把原來(lái)的瀏覽器內(nèi)核換成了一個(gè)簡(jiǎn)化版的內(nèi)核：一個(gè)不能做物理渲染卿泽，只能轉(zhuǎn)換成有限原生組件的內(nèi)核。
Flutter的 Engine 模塊也可以認(rèn)為是一個(gè)瀏覽器內(nèi)核的角色滋觉！事實(shí)上Flutter的前身Sky就是打算基于一個(gè)精簡(jiǎn)的Chromium內(nèi)核來(lái)實(shí)現(xiàn)跨平臺(tái)签夭。
2.2. OEM Wrapper
架構(gòu)圖
React Native架構(gòu)圖
大概到了2015年，經(jīng)歷了各種Hybrid方案割據(jù)混戰(zhàn)長(zhǎng)達(dá)數(shù)年后椎瘟，F(xiàn)acebook推出了React Native覆致，這種方案迎合了大前端的趨勢(shì)，一經(jīng)推出就備受關(guān)注肺蔚。核心改變是拋棄了低效的瀏覽器內(nèi)核渲染煌妈，轉(zhuǎn)而使用自己的DSL生成中間格式，進(jìn)而映射到對(duì)應(yīng)的平臺(tái)宣羊。
其實(shí)這個(gè)方案其實(shí)也算不上什么創(chuàng)舉璧诵，在PC時(shí)代，The Standard Widget Toolkit采用的就是這種方案（當(dāng)然要做到React Native這種水平仇冯，非Facebook級(jí)別的公司不能為也）：
From SWT官網(wǎng)
React Native 在評(píng)價(jià)體系表現(xiàn)如下：
開(kāi)發(fā)效率
在Web基礎(chǔ)上引進(jìn)了React等能力之宿，符合前端大趨勢(shì)
版本變動(dòng)頻繁，需要開(kāi)發(fā)者自己優(yōu)化苛坚，工作量大
與Native交互需要開(kāi)發(fā)者自己支持比被，維護(hù)成本高
文檔不完善色难、調(diào)試信息、錯(cuò)誤日志提示不夠友好
動(dòng)態(tài)化
可以支持
多端一致性
渲染成各自平臺(tái)的組件等缀，可以保證Native的體驗(yàn)
由于渲染依賴(lài)原生控件枷莉，不同平臺(tái)的控件需要單獨(dú)維護(hù)，并且當(dāng)系統(tǒng)更新時(shí)尺迂，社區(qū)控件可能會(huì)滯后
其控件系統(tǒng)也會(huì)受到原生UI系統(tǒng)限制笤妙，例如，在Android中噪裕，手勢(shì)沖突消歧規(guī)則是固定的蹲盘，這在使用不同人寫(xiě)的控件嵌套時(shí)，手勢(shì)沖突問(wèn)題將會(huì)變得非常棘手
性能
稍差于Native膳音，但遠(yuǎn)好于Hybrid
渲染時(shí)需要JavaScript和原生之間通信召衔，在有些場(chǎng)景如拖動(dòng)可能會(huì)因?yàn)橥ㄐ蓬l繁導(dǎo)致卡頓
JavaScript為腳本語(yǔ)言，執(zhí)行時(shí)需要JIT严蓖，執(zhí)行效率和AOT代碼仍有差距薄嫡。
評(píng)價(jià)：使用類(lèi)前端的語(yǔ)法氧急，但又不在瀏覽器內(nèi)核直接繪制颗胡，而是轉(zhuǎn)成Native控件，交由系統(tǒng)繪制吩坝。這樣既保留了前端這套開(kāi)發(fā)體系毒姨，又最大限度保證了渲染的性能。咋一看钉寝，React Native解決了 Hybrid 技術(shù)的痛點(diǎn)：渲染性能弧呐，又充分發(fā)揮了Hybrid 的優(yōu)勢(shì)：前端技術(shù)棧。但就在2018年嵌纲，Airbnb和Udacity相繼宣布棄用React Native,Facebook也宣布要大規(guī)模重構(gòu)React Native,導(dǎo)致其前景堪憂(yōu)俘枫，比起React Native的美好愿景，其在開(kāi)發(fā)過(guò)程中需要踩的坑更多逮走，長(zhǎng)期的維護(hù)成本也很高鸠蚪，反而降低了開(kāi)發(fā)效率，此外师溅，庫(kù)的增量也不容忽視茅信。
2.3. 自渲染
架構(gòu)圖
Flutter 在評(píng)價(jià)體系表現(xiàn)如下：
開(kāi)發(fā)效率
開(kāi)發(fā)工具完備，提供了VS Code（最流行的編輯器）墓臭，Intellij IDEA 插件
Google背書(shū)蘸鲸，文檔完備，社區(qū)較完備
Dart語(yǔ)言本身有上手成本窿锉，沒(méi)有前端的生態(tài)酌摇，但Dart語(yǔ)言本身是及其優(yōu)秀的
動(dòng)態(tài)化
動(dòng)態(tài)性不足膝舅，為了保證UI繪制性能，自繪UI系統(tǒng)一般都會(huì)采用AOT模式編譯其發(fā)布包
可能涉及安全政策窑多，F(xiàn)lutter Release目前不支持
國(guó)內(nèi)開(kāi)發(fā)者正在做積極探索
多端一致性
自繪制UI铸史，提供了Material Design和Cupertino兩種風(fēng)格的Widget
性能
性能和Native繪制一樣
評(píng)價(jià)：Flutter站在前人的肩膀上，取長(zhǎng)（React的狀態(tài)管理怯伊、Web的自繪制UI琳轿、React Native的HotReload等）補(bǔ)短（與Native通信的Channel機(jī)制、自渲染耿芹、完備的開(kāi)發(fā)工具鏈）崭篡，并且有Google作為作為支撐，在跨平臺(tái)領(lǐng)域后發(fā)制人吧秕，是目前最被看好的方案琉闪。
關(guān)于Dart，在開(kāi)發(fā)者踩了十幾年坑之后砸彬，Google和Microsoft兩大巨頭似乎看清了需要一種新的颠毙、更現(xiàn)代、更適合UI開(kāi)發(fā)的編程語(yǔ)言來(lái)重新建立秩序砂碉。
谷歌要推Dart蛀蜜，微軟要推Rust，這兩門(mén)語(yǔ)言的年齡比很多開(kāi)發(fā)者的從業(yè)年齡都要小增蹭，大概是要以犧牲一代開(kāi)發(fā)者為代價(jià)換取一個(gè)沒(méi)有歷史包袱（做夢(mèng)）的新生態(tài)吧（手動(dòng)狗頭）滴某。
3. Flutter初探
3.1. Flutter技術(shù)架構(gòu)
在Framework層，有以下內(nèi)容
Foundation?底層庫(kù)負(fù)責(zé)UI繪制和交互處理的?
Animation?滋迈、?Paint?等模塊基于上面的接口實(shí)現(xiàn)的基礎(chǔ)組件?
Widgets基于組件實(shí)現(xiàn)的?
Material?風(fēng)格組件（Google推薦）和?Cupertino?風(fēng)格組件（iOS風(fēng)格）
在Engine層霎奢，有以下內(nèi)容
Skia?圖形處理庫(kù)Dart?運(yùn)行時(shí)Text?文字排版引擎
這張圖和Android自身的架構(gòu)很像
這種設(shè)計(jì)符合Unix哲學(xué)的?正交性?原則（計(jì)算機(jī)網(wǎng)絡(luò)中的OSI模型也是），可以很好地屏蔽每一個(gè)層的細(xì)節(jié)饼灿，接下來(lái)我們基于這個(gè)架構(gòu)圖討論幾個(gè)問(wèn)題
Flutter如何繪制UI
為什么選擇Dart
如何和Native交互
HotReload與動(dòng)態(tài)化
3.2. GUI Framework
在開(kāi)始下文之前幕侠，需要介紹一下現(xiàn)代GUI框架的模型，無(wú)論是Web碍彭、PC晤硕、移動(dòng)端、游戲開(kāi)發(fā)硕旗，都是基于這種框架工作
Widgets（控件窗骑，也叫 View Tree），它是用于描述用戶(hù)界面原始數(shù)據(jù)的樹(shù)狀結(jié)構(gòu)漆枚。通常這一層根本不關(guān)心繪制创译，它只關(guān)心用戶(hù)對(duì)數(shù)據(jù)的操作。
Render Tree墙基，它是一種更為抽象的樹(shù)狀數(shù)據(jù)結(jié)構(gòu)软族，一般來(lái)說(shuō)它是和上一步的 View Tree結(jié)構(gòu)相同刷喜，并且它不關(guān)心原始數(shù)據(jù)，只關(guān)心控件的布局和大小立砸。通過(guò)這一步計(jì)算出控件布局后才能真正地確定控件的外觀掖疮。
Layer Tree 跟 Render Tree是相對(duì)應(yīng)的，這一步會(huì)主動(dòng)觸發(fā) Render Tree中每個(gè)元素的外觀渲染颗祝，在已知控件大小和位置的情況下決定每個(gè)控件的真正外觀浊闪。但 Layer Tree的樹(shù)狀結(jié)構(gòu)不是和 Render Tree一一對(duì)應(yīng)的，Layer Tree有可能因?yàn)?Layer合并優(yōu)化導(dǎo)致一層的 Render Tree葉子節(jié)點(diǎn)最終只對(duì)應(yīng)一個(gè) Layer螺戳。
在已經(jīng)決定好控件的大小位置以及長(zhǎng)相后搁宾，剩下的工作就需要把這些東西組合起來(lái)顯示到屏幕上。這一步原理比較簡(jiǎn)單倔幼，就是將前一步的 Layer合并成一張 Bitmap盖腿，這是一種最簡(jiǎn)單的圖像存儲(chǔ)形式。將 Bitmap光柵化后便可以提交給 GPU渲染损同。
比如Android開(kāi)發(fā)都很熟悉的?measure layout draw?就和前三層吻合翩腐，有了原始數(shù)據(jù)還不夠，屏幕只關(guān)心每個(gè)像素點(diǎn)的值膏燃，所以最后要進(jìn)行一次光柵化茂卦，歷史已經(jīng)證明這種模型是目前來(lái)說(shuō)相對(duì)高效的GUI方案。
3.3. Flutter如何繪制UI
有了以上背景蹄梢，我們來(lái)看Flutter的UI繪制過(guò)程疙筹。
Flutter繪制流程1
Flutter繪制流程2
GPU發(fā)出 Vsync 信號(hào)，Dart捕獲后就開(kāi)始一幀的繪制禁炒。
Throttle: 用來(lái)做節(jié)流，防止短時(shí)間內(nèi)重復(fù)調(diào)用霍比，提高性能幕袱。
Compositor: 這一步進(jìn)行 Layer合成，決定某一塊具體顯示哪一個(gè) Layer的數(shù)據(jù)悠瞬，可以額外的計(jì)算開(kāi)支们豌。
GL or Vulkan: 這一階段過(guò)后得到的將是一份矢量圖數(shù)據(jù)，在進(jìn)行光柵化后提交給 GPU執(zhí)行渲染即可浅妆。
3.4. 為什么選擇Dart
官方解釋?zhuān)?/p>
Developer productivity
JIT + AOT
Dart開(kāi)發(fā)團(tuán)隊(duì)對(duì)于Flutter支持粒度很大
Object-orientation
Predictable, high performance
Fast allocation.
其他聲音：
Dart 的性能更好望迎，對(duì)高幀率下的視圖數(shù)據(jù)計(jì)算很有幫助。
多生代無(wú)鎖垃圾回收器凌外，專(zhuān)門(mén)為UI框架中常見(jiàn)的大量Widgets對(duì)象創(chuàng)建和銷(xiāo)毀優(yōu)化
Native Binding辩尊，在 Android上，v8的 Native Binding可以很好地實(shí)現(xiàn)康辑，但是 iOS上的 JavaScriptCore不可以摄欲，所以如果使用 JavaScript轿亮，F(xiàn)lutter 基礎(chǔ)框架的代碼模式就很難統(tǒng)一了。而 Dart的 Native Binding可以很好地通過(guò) Dart Lib實(shí)現(xiàn)胸墙。
Fuchsia OS（谷歌的野心：5G + IOT）
Dart是類(lèi)型安全的語(yǔ)言我注，擁有完善的包管理和諸多特性。
關(guān)于IOT迟隅，國(guó)內(nèi)已經(jīng)有開(kāi)發(fā)者嘗試在樹(shù)莓派上使用Flutter了但骨。
總的來(lái)說(shuō)，想要挑戰(zhàn)JavaScript的地位還是很難的智袭，JavaScript雖然有很多缺陷嗽冒，但龐大的生態(tài)已經(jīng)為自己建立了穩(wěn)固的堡壘。
有一個(gè)關(guān)于Lisp的笑話(huà)补履，我覺(jué)得也可以改個(gè)Dart版本的：某小偷偷了美國(guó)國(guó)防部機(jī)密軟件的源碼的最后幾頁(yè)打算拿回去好好研究添坊，但等他真的打開(kāi)時(shí)發(fā)現(xiàn)是這樣
3.5. 如何和Native交互
Flutter Platform Channel Demo
通過(guò) Platform Channel機(jī)制進(jìn)行通信，常用的 Platform Channel主要有三種
BasicMessageChannel：傳遞字符串和半結(jié)構(gòu)化數(shù)據(jù)
MethodChannel：方法調(diào)用
EventChannel：數(shù)據(jù)流的通信
每種Channel具有三個(gè)重要的成員變量：
name: String類(lèi)型箫锤，代表Channel的名字贬蛙，也是其唯一標(biāo)識(shí)符。
messager：BinaryMessenger類(lèi)型谚攒，代表消息信使阳准，是消息的發(fā)送與接收的工具。
codec: MessageCodec類(lèi)型或MethodCodec類(lèi)型馏臭，代表消息的編解碼器野蝇。
對(duì)常見(jiàn)的Channel進(jìn)一步封裝成Plugin
3.6. HotReload與動(dòng)態(tài)化
Flutter Hot Demo
Flutter的HotReload確實(shí)讓人耳目一新，但這東西可能只是對(duì)于客戶(hù)端開(kāi)發(fā)比較稀奇括儒，從Instant Run到freeline绕沈，開(kāi)發(fā)者一直希望能提高項(xiàng)目構(gòu)建速度，更快地看到代碼改動(dòng)的結(jié)果帮寻，從原理上來(lái)說(shuō)乍狐，只要這門(mén)語(yǔ)言及其所在平臺(tái)支持解釋執(zhí)行（or JIT）和增量編譯就可以做到很好的HotReload效果，flutter的這一個(gè)特性算是填上了之前Android開(kāi)發(fā)的一個(gè)坑固逗，創(chuàng)舉肯定是算不上的浅蚪。至于動(dòng)態(tài)化，可以算是國(guó)內(nèi)開(kāi)發(fā)者的剛需了烫罩，F(xiàn)lutter之前移除了對(duì)動(dòng)態(tài)化的支持惜傲，可能是擔(dān)心iOS的政策原因，目前不少開(kāi)發(fā)者也對(duì)Flutter展開(kāi)了研究贝攒，后面應(yīng)該有一批魔改方案盗誊。Flutter的HotReload過(guò)程：
首先會(huì)掃描代碼，找到上次編譯之后有變化的Dart代碼；
將這些變化的Dart代碼轉(zhuǎn)化為增量的Dart Kernel文件浊伙；
將增量的Dart Kernel文件發(fā)送到正在移動(dòng)設(shè)備上運(yùn)行的Dart VM撞秋；
觸發(fā)widgets樹(shù)的重新建立、重新布局嚣鄙、重新繪制
不能使用的場(chǎng)景（所以對(duì)這個(gè)功能不能過(guò)于樂(lè)觀吻贿，業(yè)務(wù)復(fù)雜之后能用的場(chǎng)景就不會(huì)太多）：
代碼出現(xiàn)編譯錯(cuò)誤的不能使用 Hot Reload
Widget的狀態(tài)更改不能使用 Hot Reload
在 Flutter 中，全局變量和靜態(tài)字段被視為狀態(tài)哑子，因此在 Hot Reload 期間不會(huì)重新初始化舅列。
修改通用類(lèi)型聲明時(shí)
4. 評(píng)價(jià)
從Hybrid到Flutter，突破性的創(chuàng)新是不會(huì)有的卧蜓，每一個(gè)特性帐要、功能都是扎扎實(shí)實(shí)演進(jìn)過(guò)來(lái)的，這也是標(biāo)題的本意弥奸，F(xiàn)lutter能否成為大前端的答案尚未可知榨惠，谷歌布的局又有多大也不清楚，核心還是要把握住發(fā)展脈絡(luò)盛霎，對(duì)新事物保持警惕和清醒赠橙。浪潮退去才知道誰(shuí)在裸泳，有一天Flutter的替代者來(lái)了愤炸，才知道誰(shuí)是API boy（哭泣臉）期揪。
5. 參考
Web App Hybrid App和 Native App的區(qū)別
跨端開(kāi)發(fā)面面談之基于WebView的Hybrid開(kāi)發(fā)模式 - 知乎
SWT: The Standard Widget Toolkit | The Eclipse Foundation
深入理解react-native | 垂釣江湖
React Native at Airbnb - Airbnb Engineering & Data Science - Medium
Udacity也棄用React Native了 规个！-InfoQ
React Native: A retrospective from the mobile-engineering team at Udacity
Flutter 基礎(chǔ)（一）移動(dòng)開(kāi)發(fā)的跨平臺(tái)技術(shù)演進(jìn) | Flutter 技術(shù)社區(qū)
聊聊移動(dòng)端跨平臺(tái)開(kāi)發(fā)的各種技術(shù) - FEX
閑聊 Flutter ? bang’s blog
Flutter在2019年會(huì)有怎樣的表現(xiàn) - 21CTO - 從程序員到技術(shù)官
Flutter System Architecture - Google 幻燈片
Flutter’s Rendering Engine: A Tutorial — Part 1 - SAUGO 360 - Medium
Why Flutter doesn’t use OEM widgets - Flutter - Medium
Flutter原理與實(shí)踐 - 美團(tuán)技術(shù)團(tuán)隊(duì)
Flutter原理簡(jiǎn)解 · stephenwzl
GUI Framework Inside · stephenwzl
GMTC全球大前端技術(shù)大會(huì)（北京站）2019
FAQ - Flutter
Note |
本文永久鏈接?/?如何發(fā)表評(píng)論?/?關(guān)于本博客?/?關(guān)于作者 |
