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

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

創(chuàng)新互聯(lián)建站 - 大邑服務(wù)器托管，四川服務(wù)器租用，成都服務(wù)器租用，四川網(wǎng)通托管,綿陽(yáng)服務(wù)器托管，德陽(yáng)服務(wù)器托管，遂寧服務(wù)器托管，綿陽(yáng)服務(wù)器托管，四川云主機(jī)，成都云主機(jī)，西南云主機(jī)，大邑服務(wù)器托管，西南服務(wù)器托管，四川/成都大帶寬，大帶寬服務(wù)器，四川老牌ＩＤＣ服務(wù)商

工具安裝：

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可以省略不寫，為了便于維護(hù)和管理，開發(fā)中建議加上泛型。

輸出結(jié)果是：

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

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

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)聽器(listener)之前， future 不會(huì)延遲報(bào)告錯(cuò)誤。如果第一個(gè) then 或 catchError 調(diào)用在 future 完成后發(fā)生 error ，那么 error 將報(bào)告為未處理的錯(cuò)誤。

Flutter 開發(fā)筆記

下面這種情況下，為 InkWell 設(shè)置的 splashColor 不會(huì)生效：

需要用 Material 去除背景色，然后將顏色設(shè)置在 InkWell 外部：

在 Dialog builder 中使用 WillPopScope 禁用返回鍵返回：

注意：使用此方法同時(shí)也會(huì)禁用 iOS 上的手勢(shì)滑動(dòng)返回功能，推薦判斷平臺(tái)后再使用。

修改對(duì)話框中的復(fù)選框狀態(tài)，最簡(jiǎn)便的方法是通過(guò) Element 中的 markNeedsBuild 方法：

當(dāng)然，更推薦的做法是通過(guò) StatefulBuilder ，然后就可以在 Dialog 中調(diào)用 setState 方法了，不過(guò)在調(diào)用 setState 時(shí)需要判斷 Dialog 是否已經(jīng)關(guān)閉，否則會(huì)造成 setState() called after dispose() 的錯(cuò)誤，可以通過(guò)添加一個(gè)標(biāo)志位來(lái)解決，如下：

在 Web 中加載網(wǎng)絡(luò)圖片有時(shí)會(huì)失敗，遇到這樣的報(bào)錯(cuò)： Exception caught by image resource service... ，造成該錯(cuò)誤的原因通常是，圖片跨域了（見 跨域資源共享 ）。最簡(jiǎn)單的解決辦法是， 使用 HTML 渲染加載 ，而不是默認(rèn)的 CanvasKit。

Flutter 中所有的 list 默認(rèn)都是沒(méi)有 ScrollBar 的，必須使用 ScrollBar 組件。ScrollBar 組件通過(guò)監(jiān)聽 ScrollView 的 ScrollNotification 來(lái)刷新位置，所以 List 的長(zhǎng)度必須是固定的。

當(dāng)使用 WebView 等高度不定的組件時(shí)會(huì)出現(xiàn)內(nèi)容被截?cái)嗟那闆r，通常可以使用 NestedScrollView 來(lái)解決該問(wèn)題，需要在 WebView 外部嵌套 SingleChildScrollView。

雖然使用了緩存，而且也是用 builder 加載圖片的，但是發(fā)現(xiàn)一個(gè)現(xiàn)象：滑動(dòng)屏幕后圖片短暫消失并重新加載了。圖片高度很高時(shí)這種現(xiàn)象更加明顯，其原因是超出屏幕范圍一定距離的組件被重新渲染了。解決方法是在 ListView 上設(shè)置 cacheExtent 參數(shù):

該參數(shù)的作用是改變超出屏幕高度后繼續(xù)渲染的范圍（以像素為單位），比如設(shè)置成 9999 后意味著超出屏幕 10000 像素以內(nèi)的內(nèi)容都會(huì)被保留下來(lái)。

借助 IntrinsicHeight 組件：

另外，IntrinsicHeight 還可以用于 Dialog 或者 BottomSheet 中，使得其中的元素 顯示內(nèi)在元素的高度 ，從而避免元素因?yàn)榧s束的存在而不顯示或者高度太高（比如在使用了 Column 或者 Row 的時(shí)候）。

在通過(guò) Uri 的 queryParameters 獲取 query 參數(shù)時(shí)，發(fā)現(xiàn)有些鏈接會(huì)拋出下面異常：

造成該異常的原因是 Uri 默認(rèn)使用 utf-8 解碼超鏈接字符串，如果鏈接中包含非 utf-8 字符，就會(huì)造成上面的錯(cuò)誤，相關(guān) issue 見： issue #31621 。目前該 issue 處于 open 的狀態(tài)，暫時(shí)的解決辦法是，在所有使用到 queryParameter 的地方用 try..catch 捕捉可能拋出的異常。

Flutter 開發(fā)非常依賴各種官方或第三方的插件，而在使用這些插件時(shí)多少都會(huì)遇到一些問(wèn)題，大部分問(wèn)題都可以通過(guò)搜索和查找 issue 來(lái)解決。這里記錄下一些我在使用部分插件時(shí)遇到的問(wèn)題及其解決方法。

目前該庫(kù)沒(méi)有圖片加載完成的回調(diào)（見 issue #545 ），不過(guò)我們可以通過(guò)在 imageBuilder 中來(lái)添加回調(diào)：

這是一個(gè)應(yīng)用內(nèi)更新插件，安卓 10 以上安裝時(shí)需要在 manifest 中添加以下內(nèi)容：

目前功能最強(qiáng)大的 WebView 插件，基本能滿足絕大部分移動(dòng)端網(wǎng)頁(yè)加載的需求，而且可定制化程度高。

一般通過(guò) CookieManager 修改 Cookie，攔截請(qǐng)求并修改請(qǐng)求對(duì)象的 Header 不會(huì)生效。

InAppWebViewOptions 的 userAgent 只在 iOS 上生效，而 applicationNameForUserAgent 只在 Android 上生效，所以最好的做法是分平臺(tái)設(shè)置 InAppWebViewOptions ，而且需要注意，由于設(shè)置 userAgent 后會(huì)覆蓋默認(rèn)的 UserAgent，所以如果需要在默認(rèn)的 UserAgent 上添加其它參數(shù)，iOS 上需要通過(guò) InAppWebViewController.getDefaultUserAgent() 獲取默認(rèn) UserAgent 參數(shù)，而 Android 不需要添加。

如果圖片源或者請(qǐng)求是 http 的，為了在 Android 上正常加載請(qǐng)求，必須在 AndroidInAppWebViewOptions 中將 mixedContentMode 設(shè)置為 AndroidMixedContentMode.MIXED_CONTENT_ALWAYS_ALLOW 。

當(dāng)我們想要設(shè)置全屏圖片的時(shí)候，由于默認(rèn)的 Constraint 會(huì)將圖片居中顯示，所以圖片四周會(huì)留有空隙。為了去除這個(gè)限制，我們需要 Xcode 中打開 LaunchScreen.storyboard，然后在 View Controller 的 View 和 LaunchImage 上的 Safe Area 去掉。

具體設(shè)置方法：右側(cè) Inspector 面板 Show the Size inspector 解選 Layout Margins 中的 Safe Area Relative Margins，拖動(dòng)圖片占滿全屏，然后根據(jù) View Controller Scene 的 Warning，更新 Constraint 就可以了。

在集成某些三方庫(kù)之后，在使用命令行運(yùn)行 iOS 模擬器的時(shí)候可能會(huì)遇到下面這個(gè)報(bào)錯(cuò)：

這是因?yàn)?iOS 模擬器未來(lái)將會(huì)兼容 arm64 架構(gòu)，但是目前還不支持，所以我們需要修改 Build Setting 使得能夠在 x86_64 的模擬器上運(yùn)行，操作步驟見 這里 。

第十六章：Flutter數(shù)據(jù)存儲(chǔ)

Flutter的數(shù)據(jù)存儲(chǔ)分為三類

Preference相當(dāng)于iOS的NSUserDefaults,其實(shí)也是按plist的方式存儲(chǔ)的

step1:添加依賴

step2:pub get

step3:導(dǎo)入頭文件

在path_provider中有三個(gè)獲取文件路徑的方法：

- getTemporaryDirectory()

://獲取應(yīng)用緩存目錄，等同iOS的NSTemporaryDirectory()和Android的getCacheDir() 方法。

- getApplicationDocumentsDirectory():

//獲取應(yīng)用文件目錄類似于iOS的NSDocumentDirectory和Android上的 AppData目錄。

step1:添加依賴

step2:pub get

step3:導(dǎo)入頭文件

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

文/陳爐軍

整理/LiveVideoStack

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

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

Flutter

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

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

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

我們主要考慮性能和跨平臺(tái)的能力。

以往的跨平臺(tái)方案比如Weex，ReactNative，Cordova等等因?yàn)榧軜?gòu)的原因無(wú)法滿足性能要求，尤其是在音視頻這種性能要求幾乎苛刻的場(chǎng)景。

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

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

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

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

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

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

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

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

外接紋理

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

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

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

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

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

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

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

OpenGL

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

Flutter引擎啟動(dòng)后會(huì)啟動(dòng)四個(gè)線程：

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

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

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

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

這樣的設(shè)計(jì)會(huì)給音視頻開發(fā)帶來(lái)很多問(wèn)題，后面會(huì)詳細(xì)說(shuō)。

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

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

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

TPM

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

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

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

1：底層是一些獨(dú)立模塊

2：SDK層是對(duì)底層模塊的封裝

3：最上層是UI層。

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

咸魚Flutter多媒體開源組件

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

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

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

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

這樣有三個(gè)好處：

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

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

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

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

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

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

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

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

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

組要包含四個(gè)基本組件分別是：

1：視頻圖像拍攝組件

2：播放器組件

3：視頻圖像編輯組件

4：相冊(cè)選擇組件

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

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

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

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

Flutter開發(fā)--Pub包管理

在原生開發(fā)中， Android 使用 Gradle 來(lái)管理依賴， iOS 用 Cocoapods 來(lái)管理依賴，Node 中通過(guò) npm來(lái)管理依賴。 Flutter 使用配置文件 pubspec.yaml （位于項(xiàng)目根目錄）來(lái)管理第三方依賴包。

Pub 是Google官方的Dart Packages倉(cāng)庫(kù)，類似于node中的npm倉(cāng)庫(kù)，android中的jcenter，我們可以在上面查找我們需要的包和插件，也可以向pub發(fā)布我們的包和插件。

Pub工具 包含管理Package、部署Package和部署命令行應(yīng)用的命令。

如果使用的是Flutter SDK，不要直接使用pub命令。而是使用flutter pub命令，如下：

命令pub get/upgrade/outdated 屬于管理Package的依賴關(guān)系

用于檢索當(dāng)前 Package 所依賴的其它 Package。如果 pubspec.lock 文件已經(jīng)存在，則根據(jù)該文件中保存的依賴項(xiàng)版本獲取對(duì)應(yīng)的依賴項(xiàng)。如有必要，將會(huì)創(chuàng)建或更新該文件。

更新 package 依賴

當(dāng)你添加一個(gè) package 后首次運(yùn)行 flutter pub get， Flutter 將會(huì)保存在 pubspec.lock lockfile 中找到的具體 package 版本。這將確保當(dāng)你或者團(tuán)隊(duì)中其他開發(fā)者運(yùn)行 flutter pub get 后能得到相同版本的 package。

如果你想升級(jí)到 package 的最新版本，比如使用 package 的最新特性，請(qǐng)運(yùn)行 flutter pub upgrade 。這將檢索你在 pubspec.yaml 文件中指定的版本約束所允許的最高可用版本。

案例

在flutter項(xiàng)目中導(dǎo)入hive包，在pubspec.yaml文件中添加配置：

執(zhí)行flutter pub get，可以在 pubspec.lock 中看到 hive 版本是2.1.0，這是因?yàn)槟壳癶ive的最新版本是2.1.0,配置“^”表示向最新版本兼容，具體可查看Package版本管理（ ），所以再執(zhí)行flutter pub upgrade 可以看到版本還是2.1.0，這個(gè)時(shí)候會(huì)發(fā)現(xiàn)pub get和 pub upgrade 效果一樣。

但是未來(lái)如果 hive 發(fā)布了2.2.0版本，這個(gè)時(shí)候使用flutter pub get在pubspec.lock中看到hive版本依舊是2.1.0，而執(zhí)行flutter pub upgrade 后在pubspec.lock中看到hive版本就是2.2.0。

現(xiàn)在先在flutter 項(xiàng)目的pubspec.yaml文件添加配置，指定hive版本是2.0.5，如下：

這個(gè)時(shí)候執(zhí)行flutter pub get后，可以在pubspec.lock的文件中看到hive版本是2.0.5，如果這個(gè)時(shí)候更改配置為 hive: ^2.0.5，再執(zhí)行flutter pub get就會(huì)發(fā)現(xiàn)在pubspec.lock的文件中看到hive版本還是2.0.5，這個(gè)時(shí)候可以執(zhí)行flutter pub outdated查看依賴的每個(gè) package，如下圖，

可以看到，Upgrable項(xiàng)hive版本號(hào)為2.1.0，執(zhí)行flutter pub upgrade 后可以看到在pubspec.lock的文件中看到hive版本是2.1.0

在pubspec.yaml文件添加配置：

lxx_package_demo信息如下圖：

執(zhí)行flutter pub get后在pubspec.lock中看到flutter_log版本是0.0.1

現(xiàn)在修改lxx_package_demo版本號(hào)為0.0.2，再執(zhí)行flutter pub get

會(huì)發(fā)現(xiàn)版本會(huì)及時(shí)更新為0.0.2，這個(gè)時(shí)候執(zhí)行flutter pub get/upgrade效果一樣

參考文檔：

Flutter實(shí)現(xiàn)堆疊式卡輪播效果

在本博客中，我們將探討Flutter中的堆疊式卡輪播。 我們還將實(shí)現(xiàn)一個(gè)演示程序，并學(xué)習(xí)在您的flutter應(yīng)用程序中使用 stacked_card_carousel 包創(chuàng)建一個(gè)帶有垂直輪播的堆疊卡。

用于創(chuàng)建帶有堆疊卡片的垂直輪播的小部件。 下面的演示視頻顯示了如何在Flutter中創(chuàng)建帶有垂直旋轉(zhuǎn)木馬的堆疊卡。 它顯示了在您的flutter應(yīng)用程序中如何使用stacked_card_carousel軟件包來(lái)使用堆疊式卡輪播。 它顯示了垂直圓盤傳送帶滑動(dòng)卡的列表，所有卡向上滑動(dòng)并堆疊，稱為堆疊式卡傳送帶。 它會(huì)顯示在您的設(shè)備上。

堆疊式卡輪播的一些屬性是：

在lib文件夾中創(chuàng)建一個(gè)名為style_card.dart的新dart文件。

首先，我們創(chuàng)建StyleCard類，將在后續(xù)的DEMO中調(diào)用它

我們將制作一個(gè) card 控件. 在card控件中, 我們加入一個(gè)elevation 屬性和一個(gè)column控件。 在column中, 我們加入一個(gè)container用于包含image, title 和 description. 然后在stacked_card_demo頁(yè)面中使用它。

在lib文件夾中創(chuàng)建一個(gè)新的名為stacked_card_demo.dart的dart文件。

現(xiàn)在，我們將創(chuàng)建一個(gè)styleCards列表，并在其中添加一個(gè)StyleCard類。

我們創(chuàng)建了八個(gè)卡片控件，并在其中添加了image，title和description。 程序運(yùn)行后，我們將看到一個(gè)卡片列表， 當(dāng)用戶向上滑動(dòng)時(shí)，所有卡片都將堆疊在一起； 當(dāng)用戶向下滑動(dòng)時(shí)，卡片都將回到原始位置；

效果如下：

Demo地址：

網(wǎng)站名稱：flutter獲取堆棧,flutter混合棧
URL地址：http://chinadenli.net/article38/dsiogpp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供企業(yè)網(wǎng)站制作、網(wǎng)站設(shè)計(jì)、微信公眾號(hào)、App設(shè)計(jì)、App開發(fā)、網(wǎng)站制作

廣告

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