Android原生和Flutter使用過程的差異對比（二）

1、常用布局的對比

成都創(chuàng)新互聯(lián)公司專注于山陽企業(yè)網(wǎng)站建設(shè),成都響應(yīng)式網(wǎng)站建設(shè)公司,成都做商城網(wǎng)站。山陽網(wǎng)站建設(shè)公司,為山陽等地區(qū)提供建站服務(wù)。全流程按需策劃，專業(yè)設(shè)計，全程項目跟蹤，成都創(chuàng)新互聯(lián)公司專業(yè)和態(tài)度為您提供的服務(wù)

使用下來其他組件大致還算方便，但是相對布局而言使用便利程度上Android原生完勝，ConstraintLayout內(nèi)部的所有子View可以設(shè)置互相之間的位置依賴關(guān)系。

而Flutter的Stack組件內(nèi)部的Children只能通過外層包裹 Align后 固定位置，比如 Alignment.topLeft、Alignment.bottomRight 等。遇到復(fù)雜的堆疊布局需要通過外層包裹 Positioned 組件后設(shè)置固定的 top 和 left 距離以達到效果，內(nèi)部子組件之間無法設(shè)置位置關(guān)聯(lián)關(guān)系。

2、一些常用屬性設(shè)置上的差異：

Margin外邊距

Android：直接在布局文件對View設(shè)置android:layout_marginStart、android:layout_marginTop

Flutter：需嵌套 Container 組件并在內(nèi)部設(shè)置具體的 margin 值

Padding內(nèi)邊距

Android：TextView、ImageView、各種Layout都可以直接在屬性上設(shè)置android:paddingStart

Flutter：需嵌套 Padding 組件并在內(nèi)部設(shè)置具體的值

組件的可見性

Android：每個view都可以通過setVisibility來設(shè)置可見、隱藏或者隱藏但占位

Flutter：沒有單獨設(shè)置組件是否顯示的api，只能通過 bool 值控制是否添加該組件

事件監(jiān)聽

Android：常規(guī)的setOnClickListener和setOnLongClickListener設(shè)置單擊和長按事件

Flutter：在需要添加事件監(jiān)聽的組件外層嵌套 InkWell 或 GestureDetector 并設(shè)置 onTap 等

3、生命周期

Android：

Activity和Fragment各自有完整的生命周期鏈路onCreate、onStart、onResume、onPause、onDestroy等

Flutter：

萬物皆組件，組件繼承 WidgetsBindingObserver 并重寫 didChangeAppLifecycleState 函數(shù)進行監(jiān)聽

退回桌面依次執(zhí)行inactive 》= paused，此時界面不可見用戶不可操作，從桌面重新進入app執(zhí)行resumed，狀態(tài)較少如需在某些條件下觸發(fā)特定操作可能要找別的方案，比如發(fā)通知之類的

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

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

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

1、沒有橋接層

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

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

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

2、編譯執(zhí)行

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

3、Flutter Engine虛擬機

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

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

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

4、自帶渲染引擎

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

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

Flutter/IOS混和開發(fā)情況下，項目內(nèi)首個Flutter頁面導(dǎo)航無返回問題

在Flutter內(nèi)部機制中，默認使用自動管理導(dǎo)航機制，該機制在Flutter與原生混和開發(fā)情況下，F(xiàn)lutter頁面不一定作為項目的首頁面，所以出現(xiàn)需要在首個Flutter頁面使用導(dǎo)航返回的需求。

Flutter的AppBar中定義有屬性：

該屬性默認為YES，即默認為自動管理導(dǎo)航欄，該情況下其會在非第一個Flutter頁面創(chuàng)建導(dǎo)航返回按鈕，我們在AppBar中將其設(shè)置為false：

并且手動添加導(dǎo)航返回按鈕：

完成

Flutter組件（Widget）的局部刷新方式

Flutter中有兩個常用的狀態(tài)Widget分為StatefulWidget和StatelessWidget，分別為動態(tài)視圖和靜態(tài)視圖，視圖的更新需要調(diào)用StatefulWidget的setState方法，這會遍歷調(diào)用子Widget的build方法。如果一個頁面內(nèi)容比較復(fù)雜時，會包含多個widget，如果直接調(diào)用setState，會遍歷所有子Widget的build，這樣會造成很多不必要的開銷，所以非常有必要了解Flutter中局部刷新的方式：

globalkey唯一定義了某個element，它使你能夠訪問與element相關(guān)聯(lián)的其他對象，例如buildContext、state等。應(yīng)用場景：跨widget訪問狀態(tài)。

例如：可以通過key.currentState拿到它的狀態(tài)對象，然后就可以調(diào)用其中的onPressed方法。

Flutter框架內(nèi)部提供了一個非常小巧精致的組件，專門用于局部組件的刷新。適用于值改動的刷新。

實現(xiàn)原理：在 initState 中對傳入的可監(jiān)聽對象進行監(jiān)聽，執(zhí)行 _valueChanged 方法，_valueChanged 中進行了 setState 來觸發(fā)當前狀態(tài)的刷新。觸發(fā) build 方法，從而觸發(fā) widget.builder 回調(diào)，這樣就實現(xiàn)了局部刷新。可以看到這里回調(diào)的 child 是組件傳入的 child，所以直接使用，這就是對 child 的優(yōu)化的根源。

可以看到 ValueListenableBuilder 實現(xiàn)局部刷新的本質(zhì)，也是進行組件的抽離，讓組件狀態(tài)的改變框定在狀態(tài)內(nèi)部，并通過 builder 回調(diào)控制局部刷新，暴露給用戶使用。

通過這個可以創(chuàng)建一個支持局部刷新的widget樹，比如你可以在StatelessWidget里面刷新某個布局，但是不需要改變成StatefulWidget；也可以在StatefulWidget中使用做部分刷新而不需要刷新整個頁面，這個刷新是不會調(diào)用Widget build（BuildContext context）刷新整個布局樹的。

異步UI更新：

很多時候我們會依賴一些異步數(shù)據(jù)來動態(tài)更新UI，比如在打開一個頁面時我們需要先從互聯(lián)網(wǎng)上獲取數(shù)據(jù)，在獲取數(shù)據(jù)的過程中顯示一個加載框，等獲取到數(shù)據(jù)時我們再渲染頁面；又比如我們想展示Stream（比如文件流、互聯(lián)網(wǎng)數(shù)據(jù)接收流）的進度。當然StatefulWidget我們完全可以實現(xiàn)以上功能。但由于在實際開發(fā)中依賴異步數(shù)據(jù)更新UI的這種場景非常常見，并且當StatefulWidget中控件樹較大時，更新一個屬性導(dǎo)致整個樹重建，消耗性能，因此Flutter專門提供了FutureBuilder和SteamBuilder兩個組件來快速實現(xiàn)這種功能。

通常情況下，子Widget無法單獨感知父Widget的變化，當父state變化時，通過其build重建所有子widget；

InheriteddWidget可以避免這種全局創(chuàng)建，實現(xiàn)局部子Widget更新。InheritedWidget提供了一種在Widget樹中從上到下傳遞、共享數(shù)據(jù)的方式。Flutter SDK正是通過InheritedWidget來共享應(yīng)用主題和Locale等信息。

InheritedWidgetData

TestData

InheritedTest1Page

provider是Google I/O 2019大會上宣布的現(xiàn)在官方推薦的管理方式，而ChangeNotifierProvider可以說是Provider的一種：

yaml文件需要引入provider: ^3.1.0

頂層嵌套ChangeNotifierProvider

創(chuàng)建共享數(shù)據(jù)類DataInfo：

數(shù)據(jù)類需要with ChangeNotifier 以使用 notifyListeners()函數(shù)通知監(jiān)聽者更新界面。

使用Provider.of(context)獲取DataInfo

nextPage：

使用Consumer包住需要使用共享數(shù)據(jù)的Widget

RepaintBoundary就是重繪邊界，用于重繪時獨立于父視圖。頁面需要更新的頁面結(jié)構(gòu)可以用 RepaintBoundary組件嵌套,flutter 會將包含的組件獨立出一層"畫布"，去繪制。官方很多組件 外層也包了層 RepaintBoundary 標簽。如果你的自定義view比較復(fù)雜，應(yīng)該盡可能的避免重繪。

以上總結(jié)了幾種Flutter的局部刷新的方式，可根據(jù)實際需要使用不同的方式，最適合的才是最好的。

Flutter浪潮下的音視頻研發(fā)探索

文/陳爐軍

整理/LiveVideoStack

大家好，我是阿里巴巴閑魚事業(yè)部的陳爐軍，本次分享的主題是Flutter浪潮下的音視頻研發(fā)探索，主要內(nèi)容是針對閑魚APP在當下流行的跨平臺框架Flutter的大規(guī)模實踐，介紹其在音視頻領(lǐng)域碰到的一些困難以及解決方案。

分享內(nèi)容主要分為四個方面，首先會對Flutter有一個簡單介紹以及選擇Flutter作為跨平臺框架的原因，其次會介紹Flutter中與音視頻關(guān)系非常大的外接紋理概念，以及對它做出的一些優(yōu)化。之后會對閑魚在音視頻實踐過程中碰到的一些Flutter問題提出了一些解決方案——TPM音視頻框架。最后是閑魚Flutter多媒體開源組件的介紹。

Flutter

Flutter是一個跨平臺框架，以往的做法是將音頻、視頻和網(wǎng)絡(luò)這些模塊都下沉到C++層或者ARM層，在其上封裝成一個音視頻的SDK，供UI層的PC、iOS和Android調(diào)用。

而Flutter做為一個UI層的跨平臺框架，顧名思義就是在UI層也實現(xiàn)了一個跨平臺開發(fā)。可以預(yù)想的是未Flutter發(fā)展的好的話，會逐漸變?yōu)橐粋€從底層到UI層的一個全鏈路的跨平臺開發(fā)，技術(shù)人員分別負責(zé)SDK和UI層的開發(fā)。

在Flutter之前已經(jīng)有很多跨平臺UI解決方案，那為什么選擇Flutter呢？

我們主要考慮性能和跨平臺的能力。

以往的跨平臺方案比如Weex，ReactNative，Cordova等等因為架構(gòu)的原因無法滿足性能要求，尤其是在音視頻這種性能要求幾乎苛刻的場景。

而諸如Xamarin等，雖然性能可以和原生App一致，但是大部分邏輯還是需要分平臺實現(xiàn)。

我們可以看一下，為什么Flutter可以實現(xiàn)高性能：

原生的native組件渲染以IOS為例，蘋果的UIKit通過調(diào)用平臺自己的繪制框架QuaztCore來實現(xiàn)UI的繪制，圖形繪制也是調(diào)用底層的API,比如OpenGL、Metal等。

而Flutter也是和原生API邏輯一致，也是通過調(diào)用底層的繪制框架層SKIA實現(xiàn)UI層。這樣相當于Flutter他自己實現(xiàn)了一套UI框架，提供了一種性能超越原生API的跨平臺可能性。

但是我們說一個框架最終性能怎樣，其實取決于設(shè)計者和開發(fā)者。至于現(xiàn)在到底是一個什么狀況：

在閑魚的實踐中，我們發(fā)現(xiàn)在正常的開發(fā)沒有特意的去優(yōu)化UI代碼的情況下，在一些低端機上，F(xiàn)lutter界面的流暢性是比Native界面要好的。

雖然現(xiàn)在閑魚某些場景下會有卡頓閃退等情況，但是這是一個新事物發(fā)展過程中的必然問題，我們相信未來性能肯定不會成為限制Flutter發(fā)展的瓶頸的。

在閑魚實踐Flutter的過程中，混合棧和音視頻是其中比較難解決的兩個問題，混合棧是指一個APP在Flutter過程中不可能一口氣將所有業(yè)務(wù)全部重寫為Flutter，所以這是一個逐步迭代的過程，這期間原生native界面與Flutter界面共存的狀態(tài)就稱之為混合棧。閑魚在混合棧上也有一些比較好的輸出，例如FlutterBoost。

外接紋理

在講音視頻之前需要簡要介紹一下外接紋理的概念，我們將它稱之為是Flutter和Frame之間的橋梁。

Flutter渲染一幀屏幕數(shù)據(jù)首先要做的是，GPU發(fā)出的VC信號在Flutter的UI線程，通過AOT編譯的機器碼結(jié)合當前Dart Runtime，生成Layer Tree UI樹，Layer Tree上每一個葉子節(jié)點都代表了當前屏幕上所需要渲染的每一個元素，包含了這些元素渲染所需要的內(nèi)容。將Layer Tree拋給GPU線程，在GPU線程內(nèi)調(diào)用Skia去完成整個UI的渲染過程。Layer Tree中有PictureLayer和TextureLayer兩個比較重要的節(jié)點。PictureLayer主要負責(zé)屏幕圖片的渲染，F(xiàn)lutter內(nèi)部實現(xiàn)了一套圖片解碼邏輯，在IO線程將圖片讀取或者從網(wǎng)絡(luò)上拉取之后，通過解碼能夠在IO線程上加載出紋理，交給GPU線程將圖片渲染到屏幕上。但是由于音視頻場景下系統(tǒng)API太過繁多，業(yè)務(wù)場景過于復(fù)雜。Flutter沒有一套邏輯去實現(xiàn)跨平臺的音視頻組件，所以說Flutter提出了一種讓第三方開發(fā)者來實現(xiàn)音視頻組件的方式，而這些音視頻組件的視頻渲染出口，就是TextureLayer。

在整個Layer Tree渲染的過程中，TextureLayer的數(shù)據(jù)紋理需要由外部第三方開發(fā)者來指定，可以把視頻數(shù)據(jù)和播放器數(shù)據(jù)送到TextureLayer里，由Flutter將這些數(shù)據(jù)渲染出來。

TextureLayer渲染過程：首先判斷Layer是否已經(jīng)初始化，如果沒有就創(chuàng)建一個Texture，然后將Texture Attach到一個SufaceTexture上。

這個SufaceTexture是音視頻的native代碼可以獲取到的對象，通過這個對象創(chuàng)建的Suface，我們可以將視頻數(shù)據(jù)、攝像頭數(shù)據(jù)解碼放到Suface中，然后Flutter端通過監(jiān)聽SufaceTexture的數(shù)據(jù)更新就可以順利把剛才創(chuàng)建的數(shù)據(jù)更新到它的紋理中，然后再將紋理交給SKIA渲染到屏幕上。

然而我們?nèi)绻枰肍lutter實現(xiàn)美顏，濾鏡，人臉貼圖等等功能，就需要將視頻數(shù)據(jù)讀取出來，更新到紋理中，再將GPU紋理經(jīng)過美顏濾鏡處理后生成一個處理后的紋理。按Flutter提供的現(xiàn)有能力，必須先將紋理中的數(shù)據(jù)從GPU讀出到CPU中，生成Bitmap后再寫入Surface中，這樣在Flutter中才能順利的更新到視頻數(shù)據(jù)，這樣做對系統(tǒng)性能的消耗很大。

通過對Flutter渲染過程分析，我們知道Flutter底層需要渲染的數(shù)據(jù)就是GPU紋理，而我們經(jīng)過美顏濾鏡處理完成以后的結(jié)果也是GPU紋理，如果可以將它直接交給Flutter渲染，那就可以避免GPU-CPU-GPU這樣的無用循環(huán)。這樣的方法是可行的，但是需要一個條件，就是OpenGL上下文共享。

OpenGL

在說上下文之前，得提到一個和上線文息息相關(guān)的概念：線程。

Flutter引擎啟動后會啟動四個線程：

第一個線程是UI線程，這是Flutter自己定義的UI線程，主要負責(zé)GPU發(fā)出的VSync信號時候用當前Dart編譯的機器碼和當前運行環(huán)境創(chuàng)建出Layer Tree。

還有就是IO線程和GPU線程。和大部分OpenGL處理解決方案中一樣，F(xiàn)lutter也采取一個線程責(zé)資源加載，一部分負責(zé)資源渲染這種思路。

兩個線程之間紋理共享有兩種方式。一種是EGLImage(IOS是 CVOpenGLESTextureCache)。一種是OpenGL Share Context。Flutter通過Share Context來實現(xiàn)紋理共享，將IO線程的Context和GPU線程的Context進行Share，放到同一個Share Group下面，這樣兩個線程下資源是互相可見可以共享的。

Platform線程是主線程，F(xiàn)lutter中有一個很奇怪的設(shè)定，GPU線程和主線程共用一個Context。并且在主線程也有很多OpenGL 操作。

這樣的設(shè)計會給音視頻開發(fā)帶來很多問題，后面會詳細說。

音視頻端美顏處理完成的OpenGL紋理能夠讓Flutter直接使用的條件就是Flutter的上下文需要和平臺音視頻相關(guān)的OpenGL上下文處在一個Share Group下面。

由于Flutter主線程的Context就是GPU的Context，所以在音視頻端主線程中有一些OpenGL操作的話，很有可能使Flutter整個OpenGL被破壞掉。所以需要將所有的OpenGL操作都限制在子線程中。

通過上述這兩個條件的處理，我們就可以在沒有增加GPU消耗的前提下實現(xiàn)美顏和濾鏡等等功能。

TPM

在經(jīng)過demo驗證之后，我們將這個方案應(yīng)用到閑魚音視頻組件中，但改造過程中發(fā)現(xiàn)了一些問題。

上圖是攝像頭采集數(shù)據(jù)轉(zhuǎn)換為紋理的一段代碼，其中有兩個操作：首先是切進程，將后面的OpenGL操作都切到cameraQueue中。然后是設(shè)置一次上下文。然后這種限制條件或者說是潛規(guī)則往往在開發(fā)過程中容易被忽略的。而這個條件一旦忽略后果就是出現(xiàn)一些莫名其妙的詭異問題極難排查。因此我們就希望能抽象出一套框架，由框架本身實現(xiàn)線程的切換、上下文和模塊生命周期等的管理，開發(fā)者接入框架以后只需要安心實現(xiàn)自己的算法，而不需要關(guān)心這些潛規(guī)則還有其他一些重復(fù)的邏輯操作。

在引入Flutter之前閑魚的音視頻架構(gòu)與大部分音視頻邏輯一樣采用分層架構(gòu)：

1：底層是一些獨立模塊

2：SDK層是對底層模塊的封裝

3：最上層是UI層。

引入Flutter之后，通過分析各個模塊的使用場景，我們可以得出一個假設(shè)或者說是抽象：音視頻應(yīng)用在終端上可以歸納為視頻幀解碼之后視頻數(shù)據(jù)幀在各個模塊之間流動的過程，基于這種假設(shè)去做Flutter音視頻框架的抽象。

咸魚Flutter多媒體開源組件

整個Flutter音視頻框架抽象分為管線和數(shù)據(jù)的抽象、模塊的抽象、線程統(tǒng)一管理和上下文同一管理四部分。

管線，其實就是視頻幀流動的管道。數(shù)據(jù)，音視頻中涉及到的數(shù)據(jù)包括紋理、Bit Map以及時間戳等。結(jié)合現(xiàn)有的應(yīng)用場景我們定義了管線流通數(shù)據(jù)以Texture為主數(shù)據(jù)，同時可以選擇性的添加Bit Map等作為輔助數(shù)據(jù)。這樣的數(shù)據(jù)定義方式，避免重復(fù)的創(chuàng)建和銷毀紋理帶來的性能開銷以及多線程訪問紋理帶來的一些問題。也滿足一些特殊模塊對特殊數(shù)據(jù)的需求。同時也設(shè)計了紋理池來管理管線中的紋理數(shù)據(jù)。

模塊：如果把管線和數(shù)據(jù)比喻成血管和血液，那框架音視頻的場景就可以比喻成器官，我們根據(jù)模塊所在管線的位置抽象出采集、處理和輸出三個基類。這三個基類里實現(xiàn)了剛才說的線程切換，上下文切換，格式轉(zhuǎn)換等等共同邏輯，各個功能模塊通過集成自這些基類，可以避免很多重復(fù)勞動。

線程：每一個模塊初始化的時候，初始化函數(shù)就會去線程管理的模塊去獲取自己的線程，線程管理模塊可以決定給初始化函數(shù)分配新的線程或者已經(jīng)分配過其他模塊的線程。

這樣有三個好處：

一是可以根據(jù)需要去決定一個線程可以掛載多少模塊，做到線程間的負載均衡。第二，多線程并發(fā)式能夠保證模塊內(nèi)的OpenGL操作是在當前線程內(nèi)而不會跑到主線程去，徹底避免Flutter的OpenGL 環(huán)境被破壞。第三，多線程并行可以充分利用CPU多核架構(gòu)，提升處理速度。

從Flutter端修改Flutter引擎將Context取出后，根據(jù)Context創(chuàng)建上下文的統(tǒng)一管理模塊，每一個模塊在初始化的時候會獲取它的線程，獲取之后會調(diào)用上下文管理模塊獲取自己的上下文。這樣可以保證每一個模塊的上下文都是與Flutter的上下文進行Share的，每個模塊之間資源都是共享可見的，F(xiàn)lutter和音視頻native之間也是互相共享可見的。

基于上述框架如果要實現(xiàn)一個簡單的場景，比如畫面實時預(yù)覽和濾鏡處理功能，

1：需要選擇功能模塊，功能模塊包括攝像頭模塊、濾鏡處理模塊和Flutter畫面渲染模塊，

2：需要配置模塊參數(shù)，比如采集分辨率、濾鏡參數(shù)和前后攝像頭設(shè)置等，

3：在創(chuàng)建視頻管線后使用已配置的參數(shù)創(chuàng)建模塊

4：最后管線搭載模塊，開啟管線就可以實現(xiàn)這樣簡單的功能。

上圖為整個功能實現(xiàn)的代碼和結(jié)構(gòu)圖。

結(jié)合上述音視頻框架，閑魚實現(xiàn)了Flutter多媒體開源組件。

組要包含四個基本組件分別是：

1：視頻圖像拍攝組件

2：播放器組件

3：視頻圖像編輯組件

4：相冊選擇組件

現(xiàn)在這些組件正在走內(nèi)部開源流程。預(yù)計9月份，相冊和播放器會實現(xiàn)開源。

后續(xù)展望和規(guī)劃

1：實現(xiàn)開頭所說的從底層SDK到UI的全鏈路的跨端開發(fā)。目前底層框架層和模塊層都是各個平臺各自實現(xiàn)，反而是Flutter的UI端進行了跨平臺的統(tǒng)一，所以后續(xù)會將底層也按照音視頻常用做法把邏輯下沉到C++層，盡可能的實現(xiàn)全鏈路跨平臺。

2：第二部分內(nèi)容為開源共建，閑魚開源的內(nèi)容不僅包括拍攝、編輯組件，還包括了很多底層模塊，希望有開發(fā)者在基于Flutter開發(fā)音視頻應(yīng)用時可以充分利用閑魚開源出的音視頻模塊能力，搭建APP框架，開發(fā)者只要去負責(zé)實現(xiàn)特殊需求模塊就可以，盡可能的減少重復(fù)勞動。

Flutter進階篇（4）-- Flutter的Future異步詳解

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

工具安裝：

Flutter基礎(chǔ)篇：

Flutter進階篇：

Dart語法基礎(chǔ)篇：

Dart語法進階篇：

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

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

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

輸出結(jié)果是：

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

then ：異步操作邏輯在這里寫。

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

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

因為這里面的異步操作過程中沒有遇到什么錯誤，所以catchError回調(diào)不會調(diào)用。

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

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

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

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

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

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

運行結(jié)果是：

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

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

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

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

我們重點看看 then函數(shù)的文檔說明：

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

當這個 Future 用一個 value 完成時，將使用該值調(diào)用 onValue 回調(diào)。

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

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

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

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

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

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

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

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

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

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

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

網(wǎng)頁名稱：flutter內(nèi)部,Flutter原理
文章路徑：http://chinadenli.net/article11/dsgdhgd.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供商城網(wǎng)站、Google、企業(yè)網(wǎng)站制作、動態(tài)網(wǎng)站、營銷型網(wǎng)站建設(shè)、網(wǎng)站建設(shè)

廣告

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