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

文/陳爐軍

創(chuàng)新互聯(lián)是專業(yè)的船營網(wǎng)站建設(shè)公司，船營接單;提供成都網(wǎng)站設(shè)計、成都做網(wǎng)站,網(wǎng)頁設(shè)計,網(wǎng)站設(shè)計,建網(wǎng)站,PHP網(wǎng)站建設(shè)等專業(yè)做網(wǎng)站服務(wù);采用PHP框架,可快速的進(jìn)行船營網(wǎng)站開發(fā)網(wǎng)頁制作和功能擴(kuò)展;專業(yè)做搜索引擎喜愛的網(wǎng)站,專業(yè)的做網(wǎng)站團(tuán)隊,希望更多企業(yè)前來合作!

整理/LiveVideoStack

大家好，我是阿里巴巴閑魚事業(yè)部的陳爐軍，本次分享的主題是Flutter浪潮下的音視頻研發(fā)探索，主要內(nèi)容是針對閑魚APP在當(dāng)下流行的跨平臺框架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ù)人員分別負(fù)責(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層。這樣相當(dāng)于Flutter他自己實現(xiàn)了一套UI框架，提供了一種性能超越原生API的跨平臺可能性。

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

在閑魚的實踐中，我們發(fā)現(xiàn)在正常的開發(fā)沒有特意的去優(yōu)化UI代碼的情況下，在一些低端機(jī)上，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編譯的機(jī)器碼結(jié)合當(dāng)前Dart Runtime，生成Layer Tree UI樹，Layer Tree上每一個葉子節(jié)點都代表了當(dāng)前屏幕上所需要渲染的每一個元素，包含了這些元素渲染所需要的內(nèi)容。將Layer Tree拋給GPU線程，在GPU線程內(nèi)調(diào)用Skia去完成整個UI的渲染過程。Layer Tree中有PictureLayer和TextureLayer兩個比較重要的節(jié)點。PictureLayer主要負(fù)責(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線程，主要負(fù)責(zé)GPU發(fā)出的VSync信號時候用當(dāng)前Dart編譯的機(jī)器碼和當(dāng)前運行環(huán)境創(chuàng)建出Layer Tree。

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

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

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

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

音視頻端美顏處理完成的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)換為紋理的一段代碼，其中有兩個操作：首先是切進(jì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ù)載均衡。第二，多線程并發(fā)式能夠保證模塊內(nèi)的OpenGL操作是在當(dāng)前線程內(nèi)而不會跑到主線程去，徹底避免Flutter的OpenGL 環(huán)境被破壞。第三，多線程并行可以充分利用CPU多核架構(gòu)，提升處理速度。

從Flutter端修改Flutter引擎將Context取出后，根據(jù)Context創(chuàng)建上下文的統(tǒng)一管理模塊，每一個模塊在初始化的時候會獲取它的線程，獲取之后會調(diào)用上下文管理模塊獲取自己的上下文。這樣可以保證每一個模塊的上下文都是與Flutter的上下文進(jìn)行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端進(jìn)行了跨平臺的統(tǒng)一，所以后續(xù)會將底層也按照音視頻常用做法把邏輯下沉到C++層，盡可能的實現(xiàn)全鏈路跨平臺。

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

flutter與原生交互方法和底層原理分析

1.環(huán)境準(zhǔn)備， 參考鏈接

2.添加國內(nèi)環(huán)境配置： 參考鏈接

3.新建

name: String類型，代表Channel的名字，也是其唯一標(biāo)識符。

messager：BinaryMessenger類型，代表消息信使，是消息的發(fā)送與接收的工具。

codec: MessageCodec類型或MethodCodec類型，代表消息的編解碼器。

fluuter中的MessageCodec用于二進(jìn)制格式數(shù)據(jù)與基礎(chǔ)數(shù)據(jù)之間的編解碼。BasicMessageChannel所使用的編解碼器就是MessageCodec。

iOS中，名稱為FlutterMessageCodec，是一個協(xié)議，定義了兩個方法：encode接收一個類型為id的消息，將其編碼為NSData類型，而decode接收NSData類型消息，將其解碼為id類型數(shù)據(jù)。

MessageCodec有多種不同的實現(xiàn)：

與MessageCodec不同的是，MethodCodec用于MethodCall對象的編解碼，一個MethodCall對象代表一次從Flutter端發(fā)起的方法調(diào)用。MethodCall有2個成員變量：String類型的method代表需要調(diào)用的方法名稱，通用類型(Android中為Object，iOS中為id)的arguments代表需要調(diào)用的方法入?yún)?/p>

由于處理的是方法調(diào)用，故相比于MessageCodec，MethodCodec多了對調(diào)用結(jié)果的處理。當(dāng)方法調(diào)用成功時，使用encodeSuccessEnvelope將result編碼為二進(jìn)制數(shù)據(jù)，而當(dāng)方法調(diào)用失敗時，則使用encodeErrorEnvelope將error的code、message、detail編碼為二進(jìn)制數(shù)據(jù)

MethodCodec有兩種實現(xiàn)：

Flutter踩坑之旅

記錄下自己踩過的坑,怕忘了

一.TextField:

1.去掉輸入數(shù)字的計數(shù):decoration中的counterStyle: TextStyle(color: Colors.transparent).

2.去掉獲取和失去焦點時邊框改變顏色的效果:decoration內(nèi)border: InputBorder.none,

3.去邊框時設(shè)置BorderSide的width為0或color: Colors.transparent后依然存在邊框時,需要設(shè)置為borderSide: BorderSide.none

4.設(shè)置背景色需要在decoration內(nèi) ? ? filled:true, ? fillColor: Colors.blue同時設(shè)置才會顯示

二.Uint8List類型和string類型,Listint的轉(zhuǎn)換

連續(xù)兩次base64解碼時,參數(shù)只能使用string類型,但是base64解碼后是Uint8List類型,此時需要將Uint8List類型轉(zhuǎn)換為string類型,使用:utf8.decode(Uint8List)即可,需要import 'dart:convert';

Listint轉(zhuǎn)Uint8List:讀取接口時獲取的數(shù)據(jù)是Listint的圖片數(shù)據(jù),想顯示時需要轉(zhuǎn)成Uint8List,然后使用Image.memory(),使用:Uint8List.fromList(Listint)即可

三.報錯:DioError [DioErrorType.DEFAULT]: FormatException: Unexpected character (at character 1)MGFlMFo0NEZ3RWNMbE5YbGNGOXZGcUlJdUhIS2x2Q3NlckxqWXlEeG5JWndZdXIrSUpLN3ZOczR...

這是因為dio請求返回的數(shù)據(jù)默認(rèn)是以json的格式讀取的,而返回的數(shù)據(jù)是密文形式,需要修改dio的Options的responseType為ResponseType.PLAIN,這樣返回的數(shù)據(jù)就以字符串形式處理.

四.去掉點擊控件背景出現(xiàn)的水波紋效果,即去掉md的效果:

在main.dart的MaterialApp內(nèi)的theme加上splashColor: Colors.transparent

五.布局去掉沉浸式效果和布局設(shè)置占滿全屏卻無效的問題

使用Scaffold的body的布局默認(rèn)是沉浸式的,將狀態(tài)欄一起包含了,可以通過在body后添加一層SafeArea即可.

布局設(shè)置double.infinity占滿全屏高度卻無效,大部分情況都是因為某一級的父布局的高度已經(jīng)有了限制,所以設(shè)置充滿屏幕只會充滿父布局,有些widget默認(rèn)是按內(nèi)容填充類似wrap_content就會導(dǎo)致寫布局的過程中自己沒有限制高度但最后的布局不是自己想要的,可以給各個父布局設(shè)置不同背景顏色來查看是從哪兒開始被限制了高度來排查問題.

六.占滿剩余空間,類似android的match_parent可以使用double.infinity

七.LinearProgressIndicator

1.LinearProgressIndicator設(shè)置進(jìn)度值的顏色為單一顏色:valueColor : new AlwaysStoppedAnimation(Color(JColor.blue))

2.給LinearProgressIndicator設(shè)置圓角:ClipRRect(

borderRadius:BorderRadius.circular(60.0),

child:LinearProgressIndicator(value:0.2,backgroundColor:Color(JColor.grayBg),valueColor:new AlwaysStoppedAnimation(Color(JColor.blue)),

)

八.Expanded:

1.若嵌套多層column且內(nèi)容的高度都不確定需要占滿剩余空間,需要每層的column的內(nèi)容都嵌套一層expanded來申明每層都占滿剩余的空間,否則最里面的內(nèi)容層需要指定高度,不然會報錯

九.Container設(shè)置最小/大寬度或高度:

constraints:BoxConstraints(minHeight:56),

十.滑動的widget嵌套:

1.解決滑動沖突:內(nèi)層嵌套的滑動widget設(shè)置physics:NeverScrollableScrollPhysics()

2.解決滑動嵌套ui顯示不出來或者報錯,內(nèi)層的滑動widget設(shè)置shrinkWrap:true

十一.使用multi_image_picker: ^4.3.4安卓運行報錯Didn't find class "com.sangcomz.fishbun.FishBunFileProvider"

1.需要android工程支持androidx,需要在android工程的gradle.properties內(nèi)添加android.enableJetifier=true和android.useAndroidX=true并點擊右上角的open for editing in android studio,運行成功后就可以了

十二.使用textfield時的文字ui總是很高

使用了maxlength且只是在textfield的InputDecoration設(shè)置counterStyle的顏色為透明使下面的計數(shù)文字消失會導(dǎo)致文字ui很高,counter的計數(shù)文字只是顏色是透明但依然在布局中占了位置所以導(dǎo)致文字很高,直接使用counterText:""即可

十三.使用ListView報錯Vertical viewport was given unbounded height

需要將ListView放入Expanded內(nèi)部

Flutter與原生通信概述

flutter與原生通信主要有三種方式：MethodChannel、EventChannel、BasicMessageChannel，這三種方式均各有適用的場景：MethodChannel用于native與flutter的方法調(diào)用，EventChannel用于native單向的向flutter發(fā)送廣播消息，BasicMessageChannel用于native與flutter之間的消息互發(fā)。

MethodChannel用于雙方之間的方法互調(diào)，使用步驟是：

1.創(chuàng)建一個MethodChannel對象，傳入MethodChannel名稱。

2.使用setMethodHandle對對方調(diào)用自己的方法進(jìn)行監(jiān)聽，通過回調(diào)中的MethodCall對象方法名判斷、獲取方法參數(shù)，并且返回調(diào)用結(jié)果。

3.使用invokeMethod來調(diào)用對方的方法，可傳入方法名，方法參數(shù)，以及監(jiān)聽對方的回調(diào)結(jié)果。

以下是示例：

需要注意的是，MethodChannel的名稱需要雙方保持一致，否則就不是同一個MethodChannel了。另外這里的方法調(diào)用并不是像Java里面反射那樣去先找到class示例對象再解析到相應(yīng)的方法，而是將雙方互發(fā)的消息包裝成了MethodCall對象，拿到這個對象后通過MethodCall里面的方法名去判斷要做什么操作，并不是直接就調(diào)用了自身（native或flutter）相對應(yīng)的方法。具體要做什么操作、調(diào)用什么方法還是得自己去調(diào)用和實現(xiàn)。

EventChannel適用于native向flutter發(fā)送廣播消息，只是單向的消息發(fā)送，native發(fā)，flutter收，返過來flutter并不能向native發(fā)送消息。例如native可將定位數(shù)據(jù)不斷的報給flutter，或者錄像數(shù)據(jù)等等，所有基于原生能力產(chǎn)生的數(shù)據(jù)都可以通過EventChannel進(jìn)行發(fā)送。

步驟：

1.創(chuàng)建一個EventChannel對象，傳入EventChannel名稱。

2.flutter端調(diào)用receiveBroadcastStream進(jìn)行廣播消息注冊，傳入arguments參數(shù)即為廣播名稱，此參數(shù)是告訴native端你要接受的廣播類型，判別是什么廣播發(fā)送的數(shù)據(jù)。

2.native調(diào)用setStreamHandler方法進(jìn)行廣播消息監(jiān)聽，onListen回調(diào)里會有一個arguments參數(shù)，這里及為flutter注冊的廣播類型，若flutter端沒有注冊，則native端不會收到這個回調(diào)，也就無法進(jìn)行消息發(fā)送。收到flutter端的廣播注冊后，根據(jù)arguments可判斷廣播類型，然后根據(jù)EventChannel.EventSink來進(jìn)行消息發(fā)送，EventSink.success()即可將消息發(fā)送給flutter端。

3.flutter進(jìn)行廣播注冊會返回一個streamSubscription類型的對象，該對象可以進(jìn)行消息的停止，native可在onCancel回調(diào)里面收到。

示例如下：

BasicMessageChannel就是比較常用的消息互發(fā)，使用步驟如下：

1.創(chuàng)建BasicMessageChannel對象，傳入BasicMessageChannel名稱。還需傳入編解碼方式（可以自己實現(xiàn)），系統(tǒng)提供了一些列的編解碼方式，后續(xù)會介紹到。

2.使用setMessageHandler方法進(jìn)行消息監(jiān)聽，也可進(jìn)行回復(fù)。

3.使用send方法進(jìn)行消息發(fā)送。

無論哪種方式的消息傳遞，最終都是將自定義數(shù)據(jù)轉(zhuǎn)化為二進(jìn)制數(shù)據(jù)進(jìn)行傳遞，flutter提供的編解碼方式分為MethodCodec和MessageCodec兩種，EventChannel和MethodChannel使用的就是MethodCodec，BasicMessageChannel使用的是MessageCodec。MethodCodec其實就是在MessageCodec的基礎(chǔ)上將數(shù)據(jù)包裝了一下，使其轉(zhuǎn)化為MethodCall對象方便使用。

MethodCodec源碼：

MethodCodec提供了兩種方式：JSONMethodCodec和StandardMethodCodec，前一種就是JSON和MethodCall對象之間的互轉(zhuǎn)，后一種則是根據(jù)傳入的數(shù)據(jù)基本類型（String，Integer等）來進(jìn)行互轉(zhuǎn)。

MessageCodec則提供了四種方式，如下圖，具體就不詳細(xì)講述了，看看名字就知道是怎么回事，可以直接去看源碼。最常用和默認(rèn)的就是StandardMessageCodec方式。

從上面的使用方式可以看出，每一種Channel在創(chuàng)建的時候都需要傳遞一個BinaryMessenger，這個接口可以在FlutterEngine里面拿到，因此需要在FlutterActivity里面實現(xiàn)configFlutterEngine方法里面重寫這個方法。FlutterActivity在attach FlutterEngine之后就會調(diào)用這個configFlutterEngine方法，通過flutterEngine.getPlugins().add(FlutterPlugin)方法可以FlutterPlugin的回調(diào)方法里進(jìn)行數(shù)據(jù)的初始化和銷毀工作。如下圖

這個回調(diào)方法里的FlutterPluginBinding提供了一些我們可能會用到的對象，如下：

Flutter -- JSON解析

由于 Flutter 不支持運行時反射，JSON 解析完全是手動的。

所謂手動解析，是指使用 dart:convert 庫中內(nèi)置的 JSON 解碼器，將 JSON 字符串解析成自定義對象的過程。使用這種方式，我們需要先將 JSON 字符串傳遞給 JSON.decode 方法解析成一個 Map，然后把這個 Map 傳給自定義的類，進(jìn)行相關(guān)屬性的賦值。

下面動手解析一個用戶的信息

首先，我們根據(jù) JSON 結(jié)構(gòu)定義 User類，并創(chuàng)建一個工廠類，來處理 User 類屬性成員與 JSON 字典對象的值之間的映射關(guān)系：

數(shù)據(jù)解析類創(chuàng)建好了，剩下的事情就相對簡單了，我們只需要把 JSON 文本通過 JSON.decode 方法轉(zhuǎn)換成 Map，然后把它交給 User 的工廠類 fromJson 方法，即可完成 User 對象的解析：

項目中往往會碰到 嵌套對象屬性 情況，

面對這種情況，我們需要為每一個非基本類型屬性創(chuàng)建一個解析類。

然后，我們只需要在 User 類中，增加 dog 屬性及對應(yīng)的 JSON 映射規(guī)則即可：

通過這種方法，無論對象有多復(fù)雜的非基本類型屬性，我們都可以創(chuàng)建對應(yīng)的解析類進(jìn)行處理。

不過到現(xiàn)在為止，我們的 JSON 數(shù)據(jù)解析還是在主 Isolate 中完成。如果 JSON 的數(shù)據(jù)格式比較復(fù)雜，數(shù)據(jù)量又大，這種解析方式可能會造成短期 UI 無法響應(yīng)。下面我們可以用 compute 函數(shù)優(yōu)化一下

通過 compute 的改造，我們就不用擔(dān)心 JSON 解析時間過長阻塞 UI 響應(yīng)了。

網(wǎng)站名稱：flutter解碼,flutter破解
鏈接URL：http://chinadenli.net/article41/dsehchd.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站內(nèi)鏈、網(wǎng)站維護(hù)、全網(wǎng)營銷推廣、網(wǎng)站制作、品牌網(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)