為什么Flutter開(kāi)發(fā)APP性能最接近原生，前端程序員請(qǐng)關(guān)注

Flutter是谷歌公司推出的跨終端的開(kāi)發(fā)框架，支持Android、iOS和WEB終端。1.0版在2018年12月5日發(fā)布，目前的最新版本是1.5，它采用的開(kāi)發(fā)語(yǔ)言是Dart，Dart也是谷歌開(kāi)發(fā)的計(jì)算機(jī)編程語(yǔ)言，語(yǔ)法類(lèi)似C，是編譯型語(yǔ)言：

創(chuàng)新互聯(lián)是一家專(zhuān)注網(wǎng)站建設(shè)、網(wǎng)絡(luò)營(yíng)銷(xiāo)策劃、微信平臺(tái)小程序開(kāi)發(fā)、電子商務(wù)建設(shè)、網(wǎng)絡(luò)推廣、移動(dòng)互聯(lián)開(kāi)發(fā)、研究、服務(wù)為一體的技術(shù)型公司。公司成立10多年以來(lái)，已經(jīng)為上1000家成都VR全景各業(yè)的企業(yè)公司提供互聯(lián)網(wǎng)服務(wù)。現(xiàn)在，服務(wù)的上1000家客戶(hù)與我們一路同行，見(jiàn)證我們的成長(zhǎng)；未來(lái)，我們一起分享成功的喜悅。

hello world例子，打印字符串“Hello World!”：

1、沒(méi)有橋接層

React Native、Weex等技術(shù)都是跨終端的框架，然而性能跟原生App存在很大差距。這是由于它們的工作原理決定的：

React Native、Weex等技術(shù)多了一個(gè)橋接層，所以界面渲染會(huì)慢一些，由于UI渲染非常頻繁，想要不卡頓，基本上比較難，性能和用戶(hù)體驗(yàn)跟原生代碼有差距。而這恰恰是Flutter的優(yōu)勢(shì)所在：

Dart可以被編譯成不同平臺(tái)的本地代碼，讓Flutter不通過(guò)橋接層直接跟平臺(tái)通信，自然性能會(huì)快一些。

2、編譯執(zhí)行

JavaScript是解釋執(zhí)行的，Dart是編譯執(zhí)行的，性能誰(shuí)好一目了然。

3、Flutter Engine虛擬機(jī)

Flutter是依靠Flutter Engine虛擬機(jī)在iOS和Android上運(yùn)行的，F(xiàn)lutter Engine使用C/C++編寫(xiě)，開(kāi)發(fā)人員通過(guò)Flutter框架直接和API在內(nèi)部進(jìn)行交互，所以具有輸入低延遲和UI渲染高幀速率的特點(diǎn)。除了這特點(diǎn)之外，F(xiàn)lutter還提供了自己的小部件，F(xiàn)lutter小部件是使用從React獲取靈感的現(xiàn)代框架構(gòu)建的。 中心思想是您使用小部件構(gòu)建UI。

窗口小部件根據(jù)其當(dāng)前配置和狀態(tài)描述了它們的視圖。 當(dāng)窗口小部件的狀態(tài)發(fā)生更改時(shí)，窗口小部件會(huì)重建其描述，框架將根據(jù)前面的描述進(jìn)行區(qū)分，以確定底層呈現(xiàn)樹(shù)從一個(gè)狀態(tài)轉(zhuǎn)換到下一個(gè)狀態(tài)所需的最小更改。可以直接在OS平臺(tái)提供的畫(huà)布上進(jìn)行描繪，也就是一些核心類(lèi)庫(kù)直接放到虛擬機(jī)里面，調(diào)用起來(lái)更快。

從它的系統(tǒng)結(jié)構(gòu)可以看出，類(lèi)似安卓的ART(Android Run Time)虛擬機(jī)，同樣采用AOT(Ahead of TIme)技術(shù)，會(huì)在APP安裝時(shí)就編譯成機(jī)器語(yǔ)言，不再解釋執(zhí)行，從而優(yōu)化了APP運(yùn)行的性能。

4、自帶渲染引擎

Flutter使用谷歌自己的Skia渲染引擎，而Android系統(tǒng)自帶Skia引擎，iOS平臺(tái)上Flutter也會(huì)把Skia引擎打包到APP中，從而實(shí)現(xiàn)了高效渲染。而React Native通過(guò)橋接層訪(fǎng)問(wèn)原生UI，操作頻繁就容易出性能問(wèn)題。

綜合所述，F(xiàn)lutter 是性能最接近原生代碼 的一種開(kāi)發(fā)框架，未來(lái)也會(huì)是構(gòu)建谷歌Fuchsia應(yīng)用的主要方式，前途不可限量，唯一的問(wèn)題就是需要學(xué)習(xí)一門(mén)新的語(yǔ)言：Dart，而有Java或者C#語(yǔ)言基礎(chǔ)的程序員會(huì)比較容易學(xué)習(xí)。

Flutter 小技巧之優(yōu)化你使用的 BuildContext

Flutter 里的 BuildContext 相信大家都不會(huì)陌生，雖然它叫 Context，但是它實(shí)際是 Element 的抽象對(duì)象，而在 Flutter 里，它主要來(lái)自于 ComponentElement 。

關(guān)于 ComponentElement 可以簡(jiǎn)單介紹一下，在 Flutter 里根據(jù) Element 可以簡(jiǎn)單地被歸納為兩類(lèi)：

所以一般情況下，我們?cè)? build 方法或者 State 里獲取到的 BuildContext 其實(shí)就是 ComponentElement 。

那使用 BuildContext 有什么需要注意的問(wèn)題 ？

首先如下代碼所示，在該例子里當(dāng)用戶(hù)點(diǎn)擊 FloatingActionButton 的時(shí)候，代碼里做了一個(gè) 2秒的延遲，然后才調(diào)用 pop 退出當(dāng)前頁(yè)面。

正常情況下是不會(huì)有什么問(wèn)題，但是當(dāng)用戶(hù)在點(diǎn)擊了 FloatingActionButton 之后，又馬上點(diǎn)擊了 AppBar 返回退出應(yīng)用，這時(shí)候就會(huì)出現(xiàn)以下的錯(cuò)誤提示。

可以看到此時(shí) log 說(shuō)，Widget 對(duì)應(yīng)的 Element 已經(jīng)不在了，因?yàn)樵? Navigator.of(context) 被調(diào)用時(shí)， context 對(duì)應(yīng)的 Element 已經(jīng)隨著我們的退出銷(xiāo)毀。

一般情況下處理這個(gè)問(wèn)題也很簡(jiǎn)單， 那就是增加 mounted 判斷，通過(guò) mounted 判斷就可以避免上述的錯(cuò)誤 。

上面代碼里的 mounted 標(biāo)識(shí)位來(lái)自于 State ， 因?yàn)? State 是依附于 Element 創(chuàng)建，所以它可以感知 Element 的生命周期 ，例如 mounted 就是判斷 _element != null; 。

那么到這里我們收獲了一個(gè)小技巧： 使用 BuildContext 時(shí)，在必須時(shí)我們需要通過(guò) mounted 來(lái)保證它的有效性 。

那么單純使用 mounted 就可以滿(mǎn)足 context 優(yōu)化的要求了嗎 ？

如下代碼所示，在這個(gè)例子里：

由于在 5 秒之內(nèi)，Item 被劃出了屏幕，所以對(duì)應(yīng)的 Elment 其實(shí)是被釋放了，從而由于 mounted 判斷， SnackBar 不會(huì)被彈出。

那如果假設(shè)需要在開(kāi)發(fā)時(shí)展示點(diǎn)擊數(shù)據(jù)上報(bào)的結(jié)果，也就是 Item 被釋放了還需要彈出，這時(shí)候需要如何處理 ？

我們知道不管是 ScaffoldMessenger.of(context) 還是 Navigator.of(context) ，它本質(zhì)還是通過(guò) context 去往上查找對(duì)應(yīng)的 InheritedWidget 泛型，所以其實(shí)我們可以提前獲取。

所以，如下代碼所示，在 Future.delayed 之前我們就通過(guò) ScaffoldMessenger.of(context); 獲取到 sm 對(duì)象，之后就算你直接退出當(dāng)前的列表頁(yè)面，5秒過(guò)后 SnackBar 也能正常彈出。

為什么頁(yè)面銷(xiāo)毀了，但是 SnackBar 還能正常彈出 ？

因?yàn)榇藭r(shí)通過(guò) of(context); 獲取到的 ScaffoldMessenger 是存在 MaterialApp 里，所以就算頁(yè)面銷(xiāo)毀了也不影響 SnackBar 的執(zhí)行。

但是如果我們修改例子，如下代碼所示，在 Scaffold 上面多嵌套一個(gè) ScaffoldMessenger ，這時(shí)候在 Item 里通過(guò) ScaffoldMessenger.of(context) 獲取到的就會(huì)是當(dāng)前頁(yè)面下的 ScaffoldMessenger 。

這種情況下我們只能保證Item 不可見(jiàn)的時(shí)候 SnackBar 還能正常彈出， 而如果這時(shí)候我們直接退出頁(yè)面，還是會(huì)出現(xiàn)以下的錯(cuò)誤提示，因?yàn)? ScaffoldMessenger 也被銷(xiāo)毀了 。

所以到這里我們收獲第二個(gè)小技巧： 在異步操作里使用 of(context) ，可以提前獲取，之后再做異步操作，這樣可以盡量保證流程可以完整執(zhí)行 。

既然我們說(shuō)到通過(guò) of(context) 去獲取上層共享往下共享的 InheritedWidget ，那在哪里獲取就比較好 ？

還記得前面的 log 嗎？在第一個(gè)例子出錯(cuò)時(shí)，log 里就提示了一個(gè)方法，也就是 State 的 didChangeDependencies 方法。

為什么是官方會(huì)建議在這個(gè)方法里去調(diào)用 of(context) ？

首先前面我們一直說(shuō)，通過(guò) of(context) 獲取到的是 InheritedWidget ，而 當(dāng) InheritedWidget 發(fā)生改變時(shí)，就是通過(guò)觸發(fā)綁定過(guò)的 Element 里 State 的 didChangeDependencies 來(lái)觸發(fā)更新， 所以在 didChangeDependencies 里調(diào)用 of(context) 有較好的因果關(guān)系 。

那我能在 initState 里提前調(diào)用嗎 ？

當(dāng)然不行，首先如果在 initState 直接調(diào)用如 ScaffoldMessenger.of(context).showSnackBar 方法，就會(huì)看到以下的錯(cuò)誤提示。

這是因?yàn)?Element 里會(huì)判斷此時(shí)的 _StateLifecycle 狀態(tài)，如果此時(shí)是 _StateLifecycle.created 或者 _StateLifecycle.defunct ，也就是在 initState 和 dispose ，是不允許執(zhí)行 of(context) 操作。

當(dāng)然，如果你硬是想在 initState 下調(diào)用也行，增加一個(gè) Future 執(zhí)行就可以成功執(zhí)行

那我在 build 里直接調(diào)用不行嗎 ？

直接在 build 里調(diào)用肯定可以，雖然 build 會(huì)被比較頻繁執(zhí)行，但是 of(context) 操作其實(shí)就是在一個(gè) map 里通過(guò) key - value 獲取泛型對(duì)象，所以對(duì)性能不會(huì)有太大的影響。

真正對(duì)性能有影響的是 of(context) 的綁定數(shù)量和獲取到對(duì)象之后的自定義邏輯 ，例如你通過(guò) MediaQuery.of(context).size 獲取到屏幕大小之后，通過(guò)一系列復(fù)雜計(jì)算來(lái)定位你的控件。

例如上面這段代碼，可能會(huì)導(dǎo)致鍵盤(pán)在彈出的時(shí)候，雖然當(dāng)前頁(yè)面并沒(méi)有完全展示，但是也會(huì)導(dǎo)致你的控件不斷重新計(jì)算從而出現(xiàn)卡頓。

所以到這里我們又收獲了一個(gè)小技巧： 對(duì)于 of(context) 的相關(guān)操作邏輯，可以盡量放到 didChangeDependencies 里去處理 。

Flutter 啟動(dòng)頁(yè)的前世今生適配歷程

APP 啟動(dòng)頁(yè)在國(guó)內(nèi)是最常見(jiàn)也是必備的場(chǎng)景，其中啟動(dòng)頁(yè)在 iOS 上算是強(qiáng)制性的要求，其實(shí)配置啟動(dòng)頁(yè)挺簡(jiǎn)單，因?yàn)樵?Flutter 里現(xiàn)在只需要：

一般只要配置無(wú)誤并且圖片尺寸匹配，基本上就不會(huì)有什么問(wèn)題， 那既然這樣，還有什么需要適配的呢？

事實(shí)上大部分時(shí)候 iOS 是不會(huì)有什么問(wèn)題， 因?yàn)? LaunchScreen.storyboard 的流程本就是 iOS 官方用來(lái)做應(yīng)用啟動(dòng)的過(guò)渡；而對(duì)于 Andorid 而言，直到 12 之前 windowBackground 這種其實(shí)只能算“民間”野路子 ，所以對(duì)于 Andorid 來(lái)說(shuō)，這其中就涉及到一個(gè)點(diǎn)：

所以下面主要介紹 Flutter 在 Android 上為了這個(gè)啟動(dòng)圖做了哪些騷操作～

在已經(jīng)忘記版本的“遠(yuǎn)古時(shí)期” ， FlutterActivity 還在 io.flutter.app.FlutterActivity 路徑下的時(shí)候，那時(shí)啟動(dòng)頁(yè)的邏輯相對(duì)簡(jiǎn)單，主要是通過(guò) App 的 AndroidManifest 文件里是否配置了 SplashScreenUntilFirstFrame 來(lái)進(jìn)行判斷。

在 FlutterActivity 內(nèi)部 FlutterView 被創(chuàng)建的時(shí)候，會(huì)通過(guò)讀取 meta-data 來(lái)判斷是否需要使用 createLaunchView 邏輯 ：

是不是很簡(jiǎn)單，那就會(huì)有人疑問(wèn)為什么要這樣做？我直接配置 Activity 的 android:windowBackground 不就完成了嗎？

這就是上面提到的時(shí)間差問(wèn)題， 因?yàn)閱?dòng)頁(yè)到 Flutter 渲染完第一幀畫(huà)面中間，會(huì)出現(xiàn)概率出現(xiàn)黑屏的情況，所以才需要這個(gè)行為來(lái)實(shí)現(xiàn)過(guò)渡 。

經(jīng)歷了“遠(yuǎn)古時(shí)代”之后， FlutterActivity 來(lái)到了 io.flutter.embedding.android.FlutterActivity ， 在到 2.5 版本發(fā)布之前，F(xiàn)lutter 又針對(duì)這個(gè)啟動(dòng)過(guò)程做了不少調(diào)整和優(yōu)化，其中主要就是 SplashScreen 。

自從開(kāi)始進(jìn)入 embedding 階段后， FlutterActivity 主要用于實(shí)現(xiàn)了一個(gè)叫 Host 的 interface ，其中和我們有關(guān)系的就是 provideSplashScreen 。

默認(rèn)情況下它會(huì)從 AndroidManifest 文件里是否配置了 SplashScreenDrawable 來(lái)進(jìn)行判斷 。

默認(rèn)情況下當(dāng) AndroidManifest 文件里配置了 SplashScreenDrawable ，那么這個(gè) Drawable 就會(huì)在 FlutterActivity 創(chuàng)建 FlutterView 時(shí)被構(gòu)建成 DrawableSplashScreen 。

DrawableSplashScreen 其實(shí)就是一個(gè)實(shí)現(xiàn)了 io.flutter.embedding.android.SplashScreen 接口的類(lèi)，它的作用就是：

之后 FlutterActivity 內(nèi)會(huì)創(chuàng)建出 FlutterSplashView ，它是個(gè) FrameLayout。

FlutterSplashView 將 FlutterView 和 ImageView 添加到一起， 然后通過(guò) transitionToFlutter 的方法來(lái)執(zhí)行動(dòng)畫(huà)，最后動(dòng)畫(huà)結(jié)束時(shí)通過(guò) onTransitionComplete 移除 splashScreenView 。

所以整體邏輯就是：

當(dāng)然這里也是分狀態(tài)：

當(dāng)然這個(gè)階段的 FlutterActivity 也可以通過(guò) override provideSplashScreen 方法來(lái)自定義 SplashScreen 。

看到?jīng)]有，做了這么多其實(shí)也就是為了彌補(bǔ)啟動(dòng)頁(yè)和 Flutter 渲染之間， 另外還有一個(gè)優(yōu)化，叫 NormalTheme 。

通過(guò)該配置 NormalTheme ，在 Activity 啟動(dòng)時(shí)，就會(huì)首先執(zhí)行 switchLaunchThemeForNormalTheme(); 方法將主題從 LaunchTheme 切換到 NormalTheme 。

大概配置完就是如下樣子， 前面分析那么多其實(shí)就是為了告訴你，如果出現(xiàn)問(wèn)題了，你可以從哪個(gè)地方去找到對(duì)應(yīng)的點(diǎn) 。

講了那么多， Flutter 2.5 之后 provideSplashScreen 和 io.flutter.embedding.android.SplashScreenDrawable 就被棄用了，驚不喜驚喜，意不意外，開(kāi)不開(kāi)心 ？

通過(guò)源碼你會(huì)發(fā)現(xiàn)，當(dāng)你設(shè)置了 splashScreen 的時(shí)候，會(huì)看到一個(gè) log 警告：

為什么會(huì)棄用？

其實(shí)這個(gè)提議是在 這個(gè) issue 上，然后通過(guò) 這個(gè) pr 完成調(diào)整。

大概意思就是： 原本的設(shè)計(jì)搞復(fù)雜了，用 OnPreDrawListener 更精準(zhǔn)，而且不需要為了后面 Andorid12 的啟動(dòng)支持做其他兼容，只需要給 FlutterActivity 等類(lèi)增加接口開(kāi)關(guān)即可 。

也就是2.5之后 Flutter 使用 ViewTreeObserver.OnPreDrawListener 來(lái)實(shí)現(xiàn)延遲直到加載出 Flutter 的第一幀。

為什么說(shuō)默認(rèn)情況？ 因?yàn)檫@個(gè)行為在 FlutterActivity 里，是在 getRenderMode() == RenderMode.surface 才會(huì)被調(diào)用，而 RenderMode 又和 BackgroundMode 有關(guān)心 。

所以在 2.5 版本后， FlutterActivity 內(nèi)部創(chuàng)建完 FlutterView 后就會(huì)執(zhí)行一個(gè) delayFirstAndroidViewDraw 的操作。

這里主要注意一個(gè)參數(shù)： isFlutterUiDisplayed 。

當(dāng) Flutter 被完成展示的時(shí)候， isFlutterUiDisplayed 就會(huì)被設(shè)置為 true。

所以當(dāng) Flutter 沒(méi)有執(zhí)行完成之前， FlutterView 的 onPreDraw 就會(huì)一直返回 false ，這也是 Flutter 2.5 開(kāi)始之后適配啟動(dòng)頁(yè)的新調(diào)整。

看了這么多，大概可以看到其實(shí)開(kāi)源項(xiàng)目的推進(jìn)并不是一帆風(fēng)順的，沒(méi)有什么是一開(kāi)始就是最優(yōu)解，而是經(jīng)過(guò)多方嘗試和交流，才有了現(xiàn)在的版本，事實(shí)上開(kāi)源項(xiàng)目里，類(lèi)似這樣的經(jīng)歷數(shù)不勝數(shù)：

Flutter ----- Timer(定時(shí)器)

Timer 官網(wǎng)

Timer 類(lèi)存在于dart:async內(nèi)，所以我們需要先導(dǎo)入

回調(diào)只需要一次:

回調(diào)多次的定時(shí)器:

基本用法如上所述，至于倒計(jì)時(shí)，延遲執(zhí)行....... 自由發(fā)揮。

flutter源碼系列 PageView源碼分析以及監(jiān)聽(tīng)事件

最近一個(gè)項(xiàng)目要實(shí)現(xiàn)可以無(wú)限循環(huán)的PageView，主要思路是在初始化pageview的list的時(shí)候在開(kāi)始和結(jié)尾多加一個(gè)結(jié)尾和開(kāi)頭的widget，當(dāng)滑動(dòng)到開(kāi)頭和結(jié)尾的時(shí)候手動(dòng)進(jìn)行頁(yè)面的切換，詳細(xì)可以搜索pageview無(wú)限輪播。

這種方法有一個(gè)要點(diǎn)就是要維護(hù)兩個(gè)索引，一個(gè)是內(nèi)部list的索引，一個(gè)是外部顯示的索引，由于list的容量是比顯示的數(shù)量多2的，所以如果要在外部進(jìn)行一些比如指示器或者計(jì)時(shí)器功能要進(jìn)行和頁(yè)面同步顯示或者切換頁(yè)面操作時(shí)，需要將顯示的索引轉(zhuǎn)換成list的索引。

不過(guò)網(wǎng)上說(shuō)的都是一些比較簡(jiǎn)單的實(shí)現(xiàn)，看到比較多的就是當(dāng)滑動(dòng)到要手動(dòng)切換的時(shí)候進(jìn)行一個(gè)時(shí)延，這樣可以避免直接切換頁(yè)面造成的卡頓和跳動(dòng)現(xiàn)象。但是存在一個(gè)問(wèn)題，如果要同時(shí)實(shí)現(xiàn)一個(gè)跟隨頁(yè)面切換的指示器，就會(huì)出現(xiàn)當(dāng)頁(yè)面切換過(guò)去之后指示器才會(huì)跟著過(guò)去，因?yàn)轫?yè)面切換的時(shí)候執(zhí)行了時(shí)延，而時(shí)延之后才會(huì)真正改變索引，此時(shí)才會(huì)setstate，之后指示器才能響應(yīng)到索引的切換，但是如果在時(shí)延之前就切換的話(huà)又會(huì)出現(xiàn)指示器先行的情況。因此這種方法其實(shí)是存在一些問(wèn)題的。

所以解決這個(gè)問(wèn)題的關(guān)鍵在于如何進(jìn)行頁(yè)面切換的判斷。這里可以有兩種思路實(shí)現(xiàn)，第一種是實(shí)現(xiàn)viewpage的onpagechanged方法，在里面進(jìn)行邏輯的判斷，然后用controller來(lái)進(jìn)行頁(yè)面跳轉(zhuǎn)，不過(guò)這種方法存在當(dāng)controller跳轉(zhuǎn)的時(shí)候又會(huì)回調(diào)onpagechanged，所以就會(huì)出現(xiàn)多次對(duì)索引不必要操作，而且如果有比如計(jì)時(shí)器等額外的功能的話(huà)可能不方便將頁(yè)面邏輯分開(kāi)，而且依舊無(wú)法解決指示器延遲問(wèn)題，同時(shí)也很難進(jìn)行細(xì)粒度的操作。

第二種方法我們就要去看pageview的源碼了，從源碼的角度來(lái)解決問(wèn)題才是正確的方法。首先我們點(diǎn)進(jìn)去pageview的源碼

看到這里其實(shí)已經(jīng)有一些思路了，我們之前難點(diǎn)在于重寫(xiě)了onpagechanged方法導(dǎo)致問(wèn)題無(wú)法很好的解決，現(xiàn)在我們找到了onpagechanged調(diào)用的地方，只要找辦法避免掉就可以實(shí)現(xiàn)了。

當(dāng)然這里我們要說(shuō)到NotificationListener，以及flutter對(duì)應(yīng)的冒泡事件傳輸機(jī)制，這里大家可以去看看這篇 文章 。

我來(lái)總結(jié)一下，其實(shí)就是flutter對(duì)于notification這個(gè)組件，有一中事件規(guī)則叫冒泡傳遞，底層的notification如果在它的 onNotification寫(xiě)的邏輯中返回是false以及它不是根結(jié)點(diǎn)，就會(huì)去向上遍歷尋找它的祖先notification組件，知道遇到root節(jié)點(diǎn)或者某一個(gè)返回true，則事件傳遞結(jié)束。

而且在onNotification中可以對(duì)多種事件進(jìn)行監(jiān)聽(tīng)和處理，所以我們可以把對(duì)viewpage頁(yè)面跳轉(zhuǎn)對(duì)索引處理的邏輯寫(xiě)在這里，而且我們可以分別處理比如滑動(dòng)開(kāi)始的start事件和結(jié)束的end事件，分別進(jìn)行細(xì)粒度的邏輯的處理，這樣就可以在外部進(jìn)行操作和別的功能實(shí)現(xiàn)了。

因此不僅無(wú)限輪播事件可以通過(guò)這種方法來(lái)解決，如果有其他的操作也可以這樣進(jìn)行處理，而且因?yàn)槲覀儧](méi)有傳入onpagechanged方法，所以不存在多次調(diào)用的問(wèn)題，pageview那里判斷onpagechanged是null方法就不會(huì)進(jìn)去了，會(huì)直接我們寫(xiě)在pageview外面的notification的邏輯。

最后的結(jié)構(gòu)大概這樣

Flutter進(jìn)階篇（4）-- Flutter的Future異步詳解

本文首發(fā)在公眾號(hào) Flutter那些事 ，歡迎大家多多關(guān)注。

工具安裝：

Flutter基礎(chǔ)篇：

Flutter進(jìn)階篇：

Dart語(yǔ)法基礎(chǔ)篇：

Dart語(yǔ)法進(jìn)階篇：

說(shuō)明：本文中的所有函數(shù)的引用在 main 函數(shù)中：

這里的執(zhí)行結(jié)果是：

Futue直接new就可以了。我這里沒(méi)有具體的返回?cái)?shù)據(jù)，所以就用匿名函數(shù)代替了， Future future = new Future(() = null); 相當(dāng)于 FutureNull future = new Future(() = null); 泛型如果為null可以省略不寫(xiě)，為了便于維護(hù)和管理，開(kāi)發(fā)中建議加上泛型。

輸出結(jié)果是：

future里面有幾個(gè)函數(shù)：

then ：異步操作邏輯在這里寫(xiě)。

whenComplete ：異步完成時(shí)的回調(diào)。

catchError ：捕獲異常或者異步出錯(cuò)時(shí)的回調(diào)。

因?yàn)檫@里面的異步操作過(guò)程中沒(méi)有遇到什么錯(cuò)誤，所以catchError回調(diào)不會(huì)調(diào)用。

我們可以看到執(zhí)行結(jié)果是：

我們可以看到輸出結(jié)果是： 2 1 3 和我們創(chuàng)建Future對(duì)象的先后順序完全一致。

我們可以看到結(jié)果為 1 2 3 ，和我們調(diào)用then的先后順序無(wú)關(guān)。：

當(dāng)then回調(diào)函數(shù)里面還有then回調(diào)的時(shí)候，這時(shí)候的流程跟前面就不太一樣了，也是一個(gè)大坑，也是面試經(jīng)常會(huì)被問(wèn)到的一個(gè)知識(shí)點(diǎn)。

我們可以看到執(zhí)行結(jié)果如下：

結(jié)果還是一樣的：

運(yùn)行結(jié)果是：

這里再次證明了上面我的猜想： 執(zhí)行順序和和創(chuàng)建Future的先后順序有關(guān)，如果有多個(gè)then嵌套執(zhí)行，先執(zhí)行外面的then，然后執(zhí)行里面的then。

執(zhí)行結(jié)果如下，我們可以看到then內(nèi)部創(chuàng)建的Future要等到then執(zhí)行完了，最后再去執(zhí)行的：

根據(jù)上文總結(jié)的特點(diǎn)，我們可以不用運(yùn)行也能推斷出輸出結(jié)果：

為了驗(yàn)證我們的猜想，我們打印一下輸出結(jié)果，果然我們的證明是正確的。

我們重點(diǎn)看看 then函數(shù)的文檔說(shuō)明：

then 注冊(cè)在 Future 完成時(shí)調(diào)用的回調(diào)。

當(dāng)這個(gè) Future 用一個(gè) value 完成時(shí)，將使用該值調(diào)用 onValue 回調(diào)。

如果 Future 已經(jīng)完成，則不會(huì)立即調(diào)用回調(diào)，而是將在稍后的 microtask（微任務(wù)） 中調(diào)度。

如果回調(diào)返回 Future ，那么 then 返回的 future 將與 callback 返回的 future 結(jié)果相同。

onError 回調(diào)必須接受一個(gè)參數(shù)或兩個(gè)參數(shù)，后者是[StackTrace]。

如果 onError 接受兩個(gè)參數(shù)，則使用錯(cuò)誤和堆棧跟蹤時(shí)調(diào)用它，否則僅使用錯(cuò)誤對(duì)象時(shí)候調(diào)用它。

onError 回調(diào)必須返回一個(gè)可用于完成返回的future的值或future，因此它必須是可賦值給 FutureOr R 的東西。

返回一個(gè)新的 Future ，該 Future 是通過(guò)調(diào)用 onValue (如果這個(gè)Future是通過(guò)一個(gè)value完成的)或' onError (如果這個(gè)Future是通過(guò)一個(gè)error完成的)的結(jié)果完成的。

如果調(diào)用的回調(diào)拋出異常，返回的 future 將使用拋出的錯(cuò)誤和錯(cuò)誤的堆棧跟蹤完成。在 onError 的情況下，如果拋出的異常與 onError 的錯(cuò)誤參數(shù)“相同(identical)”，則視為重新拋出，并使用原始堆棧跟蹤替代

如果回調(diào)返回 Future ，則 then 返回的 Future 將以與回調(diào)返回的 Future 相同的結(jié)果完成。

如果未給出 onError ，并且后續(xù)程序走了剛出現(xiàn)了錯(cuò)誤，則錯(cuò)誤將直接轉(zhuǎn)發(fā)給返回的 Future 。

在大多數(shù)情況下，單獨(dú)使用 catchError 更可讀，可能使用 test 參數(shù)，而不是在單個(gè) then 調(diào)用中同時(shí)處理 value 和 error 。

請(qǐng)注意，在添加監(jiān)聽(tīng)器(listener)之前， future 不會(huì)延遲報(bào)告錯(cuò)誤。如果第一個(gè) then 或 catchError 調(diào)用在 future 完成后發(fā)生 error ，那么 error 將報(bào)告為未處理的錯(cuò)誤。

網(wǎng)站題目：flutter延遲,flutter timer
瀏覽路徑：http://chinadenli.net/article33/dseihss.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站維護(hù)、服務(wù)器托管、關(guān)鍵詞優(yōu)化、手機(jī)網(wǎng)站建設(shè)、網(wǎng)站內(nèi)鏈、全網(wǎng)營(yíng)銷(xiāo)推廣

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶(hù)投稿、用戶(hù)轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀(guān)點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話(huà)：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)