摘要：穩(wěn)定性中大部分異常是不會(huì)引起應(yīng)用崩潰，更多會(huì)在上體現(xiàn)為紅色錯(cuò)誤堆棧，上異常等等。它是的實(shí)現(xiàn)類，實(shí)現(xiàn)跨幀保存的就是存放在這里，同時(shí)它也充當(dāng)了和之間的橋梁。一整塊的重繪區(qū)域，決定重繪的影響區(qū)域。手勢(shì)在手勢(shì)中引入了競(jìng)技的概念事件在中尤為重要。

大家好，我是郭樹(shù)煜，Github GSY 系列開(kāi)源項(xiàng)目的作者，系列包括有 GSYVideoPlayer 、GSYGitGithubApp(FlutterReactNativeKotlinWeex)四大版本，目前總 star 在 17 k+ 左右，主要活躍在掘金社區(qū)，id 是戀貓的小郭，主要專欄有《Flutter完整開(kāi)發(fā)實(shí)戰(zhàn)詳解》系列等，平時(shí)工作負(fù)責(zé)移動(dòng)端項(xiàng)目的開(kāi)發(fā)，工作經(jīng)歷從 Android 到 React Native 、Weex 再到如今的 Flutter ，期間也參與過(guò) React 、 Vue 、小程序等相關(guān)的開(kāi)發(fā)，算是一個(gè)大前端的選手吧。

這次主要是給大家分享 Flutter 相關(guān)的內(nèi)容，主要涉及做一些實(shí)戰(zhàn)和科普性質(zhì)的內(nèi)容。

一、移動(dòng)開(kāi)發(fā)的現(xiàn)狀

恰逢最近谷歌 IO 大會(huì)結(jié)束，大會(huì)后也在線上線下和大家有過(guò)交流，總結(jié)了下大家最關(guān)系的問(wèn)題有：

這個(gè)問(wèn)題算是被問(wèn)得最多的一個(gè)，先說(shuō)觀點(diǎn)：我個(gè)人認(rèn)為其實(shí)這并不沖突，因?yàn)橛袀€(gè) 誤區(qū)就是認(rèn)為跨平臺(tái)開(kāi)發(fā)就可以拋棄原生開(kāi)發(fā)！

如果從事過(guò)跨平臺(tái)開(kāi)發(fā)的同學(xué)應(yīng)該知道，平臺(tái)提供的功能向來(lái)是有限的，而面對(duì)產(chǎn)品經(jīng)理的各種 “點(diǎn)歪技能樹(shù)” 的需求，很多時(shí)候你是需要基于框架外提供支持，常見(jiàn)的就是 混合開(kāi)發(fā)或者原生插件支持 。

所以這里我表達(dá)的是，目前 Kotlin 和 Dart 更多是相輔相成 ，而一旦業(yè)務(wù)復(fù)雜度到一定程度，跨平臺(tái)框架還可能存在降低工作效率的問(wèn)題，比如針對(duì)新需求，需要重復(fù)開(kāi)發(fā) Android/IOS 的原生插件做支持，這也是 Aribnb 曾經(jīng)選擇放棄 React Native 的原因之一。

與我而言，跨平臺(tái)的意義在于解決的是端邏輯的統(tǒng)一 ，至少避免了邏輯重復(fù)實(shí)現(xiàn)，或者 IOS 和 Android 之間爭(zhēng)論 誰(shuí)對(duì)誰(shuí)錯(cuò) 的問(wèn)題，甚至可以統(tǒng)一到 web 端等等。

2、React Native 和 Flutter 之間的對(duì)比

Flutter 作為后來(lái)者，難免會(huì)被用來(lái)和 React Native 進(jìn)行對(duì)比，在這個(gè)萬(wàn)物皆是 JS 的時(shí)代，Dart 和 Flutter 的出現(xiàn)顯得尤為扎眼。

在設(shè)計(jì)上它們有著許多相似之處，響應(yīng)式設(shè)計(jì)/async支持/setState更新 等等，同時(shí)也有著各種的差異，而大家最為關(guān)心的，無(wú)非 性能、支持、上手難易、穩(wěn)定性程度 這四方面：

性能上 Flutter 的確實(shí)會(huì)比 React Native 好 ，如下圖所示，這是由框架底層決定的，當(dāng)然目前 React Native 也在進(jìn)行下一代的優(yōu)化， 而對(duì)此最直觀的數(shù)據(jù)就是：GSY系列 在18年用于閑魚(yú)測(cè)試下的對(duì)比數(shù)據(jù)了 。

同時(shí)注意不要用模擬器測(cè)試性能，特別是IOS模擬器做性能測(cè)試，因?yàn)?Flutter 在 IOS模擬器中純 CPU ，而實(shí)際設(shè)備會(huì)是 GPU 硬件加速，同時(shí)只在 Release 下對(duì)比性能。

支持上 Flutter 和 React Native ， 都存在第三方包質(zhì)量參差不齊的問(wèn)題，而目前在這一塊 Flutter 是弱于 React Native 的 ，畢竟 React Native 發(fā)展已久，雖然版本號(hào)一直不到 1.0，但是在 JS 的加持下生態(tài)豐富，同時(shí)也是因?yàn)槠脚_(tái)特性的原因，諸如 WebView 、地圖等控件的支持上現(xiàn)在依舊不夠好，這個(gè)后面也會(huì)說(shuō)道。

上手難易度上，Flutter 配置環(huán)境和運(yùn)行的“成功率”比 React Native 高不少 ，這里面有 node_module 黑洞這個(gè)坑，也有 React Native 本身依賴平臺(tái)控件導(dǎo)致的，至少我曾經(jīng)試過(guò)接手一個(gè) React Native 跑了一天都沒(méi)跑起來(lái)的經(jīng)歷，同時(shí) Flutter 在運(yùn)行和SDK版本升級(jí)的陣痛也會(huì)少很多。

穩(wěn)定性：Flutter 中大部分異常是不會(huì)引起應(yīng)用崩潰 ，更多會(huì)在 Debug 上體現(xiàn)為紅色錯(cuò)誤堆棧，Release 上 UI 異常等等。

如果你是前端，我會(huì)推薦你先學(xué) React Native，如果你是原生開(kāi)發(fā)，我推薦你學(xué) Flutter 。
在 React Native 0.59.x 版本開(kāi)始，React 已經(jīng)將許多內(nèi)置控件和庫(kù)移出主項(xiàng)目，希望模糊 React 和 React Native 的界線，統(tǒng)一開(kāi)發(fā)，這里的理念和 Flutter 很像。
Flutter 暫時(shí)不支持熱更新！?。。。。。?！

1.1、var 的語(yǔ)法糖和 dynamic

var 的語(yǔ)法糖是在賦值時(shí)才自推導(dǎo)出類型的 ，而 dynamic 是動(dòng)態(tài)聲明，在運(yùn)行時(shí)檢測(cè)，它們的使用有時(shí)候容易出現(xiàn)錯(cuò)誤。

如下圖所以說(shuō)，

var 初始化時(shí)被指定為 dynamic 類型的。

然后賦值的時(shí)候初始化為 String 類型，這時(shí)候進(jìn)行 ++ 操作就會(huì)出現(xiàn)運(yùn)行時(shí)報(bào)錯(cuò)，

如下圖2如果在初始化指定類型的，那么編譯時(shí)就會(huì)告訴你錯(cuò)誤了。

1.2、各類操作符

如下圖所示，Dart 支持很多有意思的操作符，如下圖：

執(zhí)行的時(shí)候首先是判斷 AA 如果為空，就返回 999 ；

之后如果 AA 為空，就為 AA 賦值 999；

之后對(duì) AA 進(jìn)行整除 999 ，輸出結(jié)果 10 。

1.3、支持操作符重載

如下圖所示，Dart 中是支持操作符重載的，這樣可以比較直觀我們的代碼邏輯，并且簡(jiǎn)化代碼時(shí)的調(diào)用。

1.4、方法當(dāng)做參數(shù)傳遞

如下圖所示，在 Dart 中方法時(shí)可以作為參數(shù)傳遞的，這樣的形式可以讓我們更靈活的組織代碼的邏輯。

1.5、async await / async* yield

在 Dart 中 async await / async* yield 等語(yǔ)法糖，代表 Dart 中的 Future 和 Stream 操作，它們對(duì)應(yīng) Dart 中的異步邏輯支持。

sync* / yield  對(duì)應(yīng) Stream  的同步操作。

1.6、Mixins

在 Dart 中支持混入的模式，如下圖所示，混入時(shí)的基礎(chǔ)順序是從右到左依次執(zhí)行的，而且和 super 有關(guān)，同時(shí) Dart 還支持 mixin 關(guān)鍵字的定義。

Flutter 的啟動(dòng)類用的就是 mixins 方式

1.7、isolate

Dart 中單線程模式中增加了 isolate 提供跨線程的真異步操作，而因?yàn)?Dart 中線程不會(huì)共享內(nèi)存，所以也不存在死鎖，從而也導(dǎo)致了 isolate 之間數(shù)據(jù)只能通過(guò) port 的端口方式發(fā)送接口，類似于 Scoket 的方式，同時(shí)提供了 compute 的封裝接口方便調(diào)用。

1.8 call

Dart 為了讓類可以像函數(shù)一樣調(diào)用，默認(rèn)都可以實(shí)現(xiàn) call() 方法，同樣 typedef 定義的方法也是具備 call() 條件。

比如我定義了一個(gè) CallObject

class CallObject {

  List footerButton = [];

  call(int i, double e) => "$i xxxx $e";
}

就可以通過(guò)以下執(zhí)行

CallObject callObject = CallObject();
print(callObject(11, 11.0));
print(callObject");

然后我定義了

typedef void ValueFunction(int i);

  ValueFunction vt = (int i){
    print("zzz $i");
  };

就可以通過(guò)直接執(zhí)行和判空?qǐng)?zhí)行處理

 vt(666);
 vt");

2.1、ChangeNotifier

如下圖所示，ChangeNotifier 模式在 Flutter 中是十分常見(jiàn)的，比如 TextField 控件中，通過(guò) TextEditingController 可以快速設(shè)置值的顯示，這是為什么呢？

如下圖所示，這是因?yàn)?TextEditingController 它是 ChangeNotifier 的子類，而 TextField 的內(nèi)部對(duì)其進(jìn)行了 addListener，同時(shí)我們改變值的時(shí)候調(diào)用了notifyListener，觸發(fā)內(nèi)部 setState。

2.2、InheritedWidget

在 Flutter 中所有的狀態(tài)共享都是通過(guò)它實(shí)現(xiàn)的，如自帶的 Theme ，Localizations ，或者狀態(tài)管理的 scoope_model 、 flutter_redux 等等，都是基于它實(shí)現(xiàn)的。

如下圖是 SliderTheme 的自定義實(shí)現(xiàn)邏輯，默認(rèn) Theme 中是包含了 SliderTheme，但是我們可以通過(guò)覆蓋一個(gè)新的 SliderTheme 嵌套去實(shí)現(xiàn)自定義，然后通過(guò) SliderTheme theme = SliderTheme(context); 獲取，其中而 context 的實(shí)現(xiàn)就是 Element。

在 Element 的 inheritFromWidgetOfExactType 方法實(shí)現(xiàn)里，有一個(gè) Map _inheritedWidgets 的對(duì)象。

_inheritedWidgets 一般情況下是空的，只有當(dāng)父控件是 InheritedWidget 或者本身是 InheritedWidgets 時(shí)才會(huì)有被初始化，而當(dāng)父控件是 InheritedWidget 時(shí)，這個(gè) Map 會(huì)被一級(jí)一級(jí)往下傳遞與合并 。 所以當(dāng)我們通過(guò) context 調(diào)用 inheritFromWidgetOfExactType 時(shí)，就可以往上查找到父控件的 Widget 。

2.3、StreamBuilder

StreamBuilder 一般用于通過(guò) Stream 異步構(gòu)建頁(yè)面的，如下圖所示，通過(guò)點(diǎn)擊之后，綠色方框的文字會(huì)變成 addNewxxx，因?yàn)?Stream 進(jìn)行了 map 變化，同時(shí)一般實(shí)現(xiàn) bloc 模式的時(shí)候，經(jīng)常會(huì)用到它們。

類似的還有 FutureBuilder

2.4、State 中的參數(shù)使用

一般 Widget 都是一幀的，而 State 實(shí)現(xiàn)了 Widget 的跨幀繪制，一般定義的時(shí)候，我們可以如下圖一樣實(shí)現(xiàn)，而如下圖尖頭所示，這時(shí)候我們點(diǎn)擊 setState 改變的時(shí)候，是不會(huì)出現(xiàn)效果的，為什么呢？

其實(shí) State 對(duì)象的創(chuàng)建和更新時(shí)機(jī)導(dǎo)致的：

1、createState 只在 StatefulElement 創(chuàng)建時(shí)才會(huì)被創(chuàng)建的。

2、StatefulElement 的 createElement 一般只在 inflateWidget 調(diào)用。

3、updateChild 執(zhí)行 inflateWidget 時(shí)， 如果 child 存在可以更新的話，不會(huì)執(zhí)行 inflateWidget。

3、四棵樹(shù)

Flutter 中主要有 Widget 、Element 、RenderObject 、Layer 四棵樹(shù)，它們的作用是：

Widget ：就是我們平常寫的控件，Flutter 宇宙中萬(wàn)物皆 Widget ，它們都是不可變一幀，同時(shí)也是被人吐槽很多的嵌套模式，當(dāng)然換個(gè)角度，事實(shí)上你把他當(dāng)作 Widget 配置文件來(lái)寫或者就好理解了。

Element ：它是 BuildContext 的實(shí)現(xiàn)類，Widget 實(shí)現(xiàn)跨幀保存的 state 就是存放在這里，同時(shí)它也充當(dāng)了 Widget 和 RenderObject 之間的橋梁。

RenderObject ：它才是真正干活（layout、paint）等，同時(shí)它才是真實(shí)的 “dom” 。

Layer ：一整塊的重繪區(qū)域（isRepaintBoundary），決定重繪的影響區(qū)域。

skia 在繪制的時(shí)候，saveLayer 是比較消耗性能的，比如透明合成、clipRRect 等等都會(huì)可能需要 saveLayer 的調(diào)用， 而 saveLayer 會(huì)清空GPU繪制的緩存，導(dǎo)致性能上的損耗，所以開(kāi)發(fā)過(guò)程中如果掉幀嚴(yán)重，可以針對(duì)這一塊進(jìn)行優(yōu)化。

4、手勢(shì)

Flutter 在手勢(shì)中引入了競(jìng)技的概念, Down 事件在 Flutter 中尤為重要。

PointerDownEvent 是一切的起源，在 Down 事件中一般不會(huì)決出勝利者。

在 MOVE 和 UP 的時(shí)候才競(jìng)爭(zhēng)得到響應(yīng)。

以點(diǎn)擊為例子：Down 時(shí)添加進(jìn)去參與競(jìng)爭(zhēng)，UP 的時(shí)候才決定誰(shuí)勝利，勝利條件是：

I、UP 的時(shí)候如果只有一個(gè)，那么就是它了。

II、UP 的時(shí)候如果有多個(gè)，那么強(qiáng)制隊(duì)列里第一個(gè)直接勝利。

這里包含了有趣的點(diǎn)就是，都在 UP 的時(shí)候才響應(yīng)，那么 Down 事件怎么先傳遞出去了？

FLutter 在這里做了一個(gè) didExceedDeadline 機(jī)制 ，事實(shí)上在上面的 addPointer 的時(shí)候，會(huì)啟動(dòng)了一個(gè)定時(shí)器，默認(rèn) 100 ms，如果超過(guò)指定時(shí)間沒(méi) UP ，那就先執(zhí)行這個(gè) didExceedDeadline 響應(yīng) Down 事件。

那問(wèn)題又來(lái)了，如果這時(shí)候隊(duì)列里兩個(gè)呢");

它們的 onTapDown 都會(huì)被觸發(fā)，但是 onTap 只有一個(gè)獲得。

如果有兩個(gè)滑動(dòng) ScrollView 嵌套呢？

舉個(gè)簡(jiǎn)單的例子，兩個(gè) SingleChildScrollView 的嵌套時(shí)，在布局會(huì)經(jīng)歷：

performLayout -> applyContentDimensions -> applyNewDimensions -> context.setCanDrag(physics.shouldAcceptUserOffset(this));

只有 shouldAcceptUserOffset 為 ture 時(shí)，才會(huì)添加 VerticalDragGestureRecognizer 去處理手勢(shì)。

而判斷條件主要是 return math.max(0.0, child.size.height - size.height); ，也就是如果 child Scroll 的 height 小于父控件 Scroll 的時(shí)候，就會(huì)出現(xiàn) child 不添加 VerticalDragGestureRecognizer 的情況，這時(shí)候根本就沒(méi)有競(jìng)爭(zhēng)了。

Flutter 中的動(dòng)畫是怎么執(zhí)行的呢？

我們先看一段代碼，然后這段代碼執(zhí)行的效果如下圖2所示。

那既然 Widget 都是一幀，那么動(dòng)畫肯定有 setState 的地方了。

首先這里有個(gè)地方可以看下，這時(shí)候 200 這個(gè)數(shù)值執(zhí)行后是會(huì)報(bào)錯(cuò)的，因?yàn)榘卓騼?nèi)可見(jiàn) Tween 中的 T 在這時(shí)候會(huì)出現(xiàn)既有 int 又有 double ，無(wú)法判斷的問(wèn)題，所以真實(shí)應(yīng)該是 200.0 。

同時(shí)你發(fā)現(xiàn)沒(méi)有，代碼中 parent 的 Container 在 只有100的情況下，它的 child 可以正常的畫 200，這是因?yàn)槲覀兊?paint 沒(méi)有跟著 RenerObjcet 的大小走， 所以一般情況下，整個(gè)屏幕都是我們的畫版，Canvas 繪制與父控件大小可以沒(méi)關(guān)系。

同時(shí)動(dòng)畫是通過(guò) vsync 同步信號(hào)去觸發(fā)的，就是我們 mixin 的 SingleTickerProviderStateMixin，它內(nèi)部的 Ticker 會(huì)通過(guò) SchedulerBinding 的 scheduleFrameCallback 同步信號(hào)觸發(fā)重繪 。

動(dòng)畫后的控件的點(diǎn)擊區(qū)域，和你的動(dòng)畫數(shù)據(jù)改變的是 paint 還是 layout 有關(guān) 。

scope_model 、flutter_redux、fish_redux 、甚至還有有 dva_flutter 等等，可以看出狀態(tài)管理在 flutter 中和前端十分相近。

這里簡(jiǎn)單說(shuō)說(shuō) scope_model ，它只有一個(gè)文件，但是很巧妙，它利用的就是 AnimationBuilder 的特性。

如下圖是使用代碼，在前面我們知道，狀態(tài)管理使用的是 InheritedWidget 實(shí)現(xiàn)共享的，而當(dāng)我們對(duì) Model 進(jìn)行數(shù)據(jù)改變時(shí)，通過(guò)調(diào)用 notifyListeners 通知頁(yè)面更新了。

這里的原理是什么呢？

其實(shí) scope_model 內(nèi)部利用了 AnimationBuilder ，而 Model 實(shí)現(xiàn)了 Listenable 接口。

當(dāng) Model 設(shè)置給了 AnimationBuilder 時(shí)， AnimationBuilder 會(huì)執(zhí)行 addListener 添加監(jiān)聽(tīng)，而監(jiān)聽(tīng)方法里會(huì)執(zhí)行 setState。

所以我們改變 set 方法時(shí)調(diào)用 notifyListeners 就觸發(fā)了 setState 去更新了，這樣體現(xiàn)出了前面說(shuō)的 FLutter 常見(jiàn)的開(kāi)發(fā)模式。

三、混合開(kāi)發(fā)

以 Android 的角度來(lái)說(shuō)，從方便調(diào)試和解耦集成上，我們一般會(huì)以 aar 的形式集成混合開(kāi)發(fā)，這里就會(huì)涉及到 gradle 打包的一個(gè)概念。

1、如下代碼所示，在項(xiàng)目中進(jìn)行 gradle 腳本修改，組件化開(kāi)發(fā)模式，用 apk 開(kāi)發(fā)，用 aar 提供集成，正常修改 gradle 代碼即可快速打包。

那如果 Flutter 的項(xiàng)目插件帶有本地代碼呢？

如果開(kāi)發(fā)過(guò) React Native 的應(yīng)該知道，在原生插件安裝時(shí)會(huì)需要執(zhí)行 react-native link ，而這時(shí)候會(huì)修改項(xiàng)目的gradle 和java代碼。

2、 和 React Native 很有侵入性相比， Flutter 就很巧妙了。

如下圖所示，安裝過(guò)的插件會(huì)出現(xiàn)在 .flutter_plugins 文件中，然后通過(guò)讀取文件，動(dòng)態(tài)在 setting.gradle 和 flutter.gradle 中引入和依賴：

所以這時(shí)候我們可以參考打包，修改我們的gradle腳本，利用 fat-aar 插件將本地 projcet 也打包的 aar 里。

3、混合開(kāi)發(fā)的最大痛點(diǎn)是什么？

肯定是堆棧管理!!! 所以項(xiàng)目開(kāi)發(fā)了 flutter_boost 來(lái)解決這個(gè)問(wèn)題。

堆棧統(tǒng)一到了原生層。

通過(guò)一個(gè)唯一 engine ，切換 Surface 渲染顯示。

每個(gè) Activity 就是一個(gè) Surface ，不渲染的頁(yè)面通過(guò)截圖緩存畫面。

flutter_boost 截止到我測(cè)試的時(shí)間 2019-05-16, 只支持 1.2之前的版本

四、PlatformView

混合開(kāi)發(fā)除了集成到原生工程，也有將原生控件集成到 Flutter 渲染樹(shù)里里的需求。

首先我們看看沒(méi)有 PlatformView 之前是如何實(shí)現(xiàn) WebView 的，這樣會(huì)有什么問(wèn)題？

如下圖所示，事實(shí)上 dart 中僅僅是用了一個(gè) SingleChildRenderObjectWidget 用于占位，將大小傳遞給原生代碼，然后在原生代碼里顯示出來(lái)而已。

這樣的時(shí)候必定會(huì)代碼畫面堆棧問(wèn)題，因?yàn)檫@個(gè)顯示脫離了 Flutter 的渲染樹(shù)，通過(guò)出現(xiàn)動(dòng)畫肯定會(huì)不一致。

AndroidView -> TextureLayer，利用Android 上的副屏顯示與虛擬內(nèi)存顯示原理。

共享內(nèi)存，實(shí)時(shí)截圖渲染技術(shù)。

存在問(wèn)題，耗費(fèi)內(nèi)存，頁(yè)面復(fù)雜時(shí)慢。

這部分因?yàn)橹耙郧傲倪^(guò)，就不贅述了

RN因?yàn)槭窃丶栽趓eact 和react native 整合這件事上存在難度。

flutter 作為一個(gè)UI 框架，與平臺(tái)無(wú)關(guān)，在web上利用的是dart2js的能力。 比如Image

因?yàn)?Flutter 是一套 UI 框架，整體 UI 幾乎和平臺(tái)無(wú)關(guān)，這和 React Native 有很大的區(qū)別。（我在開(kāi)發(fā)過(guò)程中幾乎無(wú)知覺(jué)）

在 flutter_web 中 UI 層面與渲染邏輯和 Flutter 幾乎沒(méi)有什么區(qū)別，底層的一些區(qū)別如： flutter_web 中的 Canvas 是 EngineCanvas 抽象，內(nèi)部會(huì)借助 dart2js 的能力去生成標(biāo)簽。

React Native 平臺(tái)關(guān)聯(lián)性太強(qiáng)，而 Flutter 在多平臺(tái)上優(yōu)勢(shì)明顯。我們期待官方幫我們解決大部分的適配問(wèn)題。

Flutter 的平臺(tái)無(wú)關(guān)能力能帶來(lái)什么？

1、某些功能頁(yè)面，可以一套代碼實(shí)現(xiàn)，利用插件安裝引入，在web、移動(dòng)app、甚至 pc 上，都可以編譯出對(duì)應(yīng)平臺(tái)的高性能代碼，而不會(huì)像 Weex 等一樣存在各種兼容問(wèn)題。

2、在應(yīng)用上可以快速實(shí)現(xiàn)“降級(jí)策略”，比如某種情況下應(yīng)用產(chǎn)生奔潰了，可以替換為同等 UI 的 h5 顯示，而這些代碼只需要維護(hù)一份。

資源推薦

Github ： github.com/CarGuo

RTC社區(qū) ： rtcdeveloper.com