看點：Flutter 的爭議
成都創(chuàng)新互聯(lián)堅持“要么做到，要么別承諾”的工作理念，服務領(lǐng)域包括：網(wǎng)站設(shè)計制作、成都網(wǎng)站設(shè)計、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣等服務，滿足客戶于互聯(lián)網(wǎng)時代的殷都網(wǎng)站設(shè)計、移動媒體設(shè)計的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡(luò)建設(shè)合作伙伴！
InfoQ：我們在看到一些比較比較消極的看法，他們認為 Flutter 正在被悄悄放棄，怎么看待這些聲音？
宗心：Gartner 將每個技術(shù)成熟度曲線都將技術(shù)的生命周期劃分為五個關(guān)鍵階段。技術(shù)萌芽期：潛在的技術(shù)突破即將開始。早期的概念驗證報道和媒體關(guān)注引發(fā)廣泛宣傳。通常不存在可用的產(chǎn)品，商業(yè)可行性未得到證明。期望膨脹期：早期宣傳產(chǎn)生了許多成功案例 — 通常也伴隨著多次失敗。某些公司會采取行動，但大多數(shù)不會。泡沫破裂谷底期：隨著實驗和實施失敗，人們的興趣逐漸減弱。技術(shù)創(chuàng)造者被拋棄或失敗。只有幸存的提供商改進產(chǎn)品，使早期采用者滿意，投資才會繼續(xù)。穩(wěn)步爬升復蘇期：有關(guān)該技術(shù)如何使企業(yè)受益的更多實例開始具體化，并獲得更廣泛的認識。技術(shù)提供商推出第二代和第三代產(chǎn)品。更多企業(yè)投資試驗；保守的公司依然很謹慎。生產(chǎn)成熟期：主流采用開始激增。評估提供商生存能力的標準更加明確。該技術(shù)的廣泛市場適用性和相關(guān)性明顯得到回報。基于這個理論，F(xiàn)lutter 應該處于期望膨脹和泡沫破裂之間，一方面看好的人還會繼續(xù)大力宣傳和投入解決問題，同時在嘗試落地失敗后的公司和個人會極力唱衰，因此我們應該回歸本質(zhì)去看，跨平臺技術(shù)本身有其特定場景下存在的價值，多平臺的研發(fā)效能收益是真實的公司需求，目前行業(yè)的龍頭企業(yè)都仍然在持續(xù)投入和改進中，談被放棄為之尚早。
所謂原生級別的流暢，但實際很卡，體驗差，而且有些跨端項目一開始用 Flutter，結(jié)果性能卡脖子，無奈又回到 Android 和 iOS 分開搞的局面嵌套之美，難以欣賞Flutter 是 KPI 項目，負責人升職完了，華麗轉(zhuǎn)身，留下一地爛攤子……
出現(xiàn)此情況的原因有兩種
解決:
找到 \app\src\main\res\drawable\launch_background.xml 文件，這個里面初始化了布局標簽,只需要把圖片替換為我們自己的就可以。
或者根據(jù)不同手機的分辨率 在mipmap下放置圖片例如：
之后前往 styles.xml 文件設(shè)置啟動頁
重新打包就可以看到 剛剛設(shè)置的啟動頁了
效果例如：
[圖片上傳失敗...(image-7e5c2-1586668143446)]
至此可以流暢的打開啟動頁了
Stateful（有狀態(tài)） 和 stateless（無狀態(tài)） widgets
stateless widget 沒有內(nèi)部狀態(tài). Icon、 IconButton, 和Text 都是無狀態(tài)widget, 他們都是 StatelessWidget的子類。
stateful widget 是動態(tài)的. 用戶可以和其交互 (例如輸入一個表單、 或者移動一個slider滑塊),或者可以隨時間改變 (也許是數(shù)據(jù)改變導致的UI更新). Checkbox, Radio, Slider, InkWell, Form, and TextField 都是 stateful widgets, 他們都是 StatefulWidget的子類。
StatefulWidget類
具有可變狀態(tài)的小部件。
狀態(tài)是（1）在構(gòu)建窗口小部件時可以同步讀取的信息，以及（2）在窗口小部件的生命周期內(nèi)可能會更改的信息。這是小工具實施者的責任，以確保國家的及時通知當這種狀態(tài)的改變，使用State.setState。
有狀態(tài)窗口小部件是一個窗口小部件，它通過構(gòu)建一個更具體地描述用戶界面的其他窗口小部件來描述用戶界面的一部分。構(gòu)建過程以遞歸方式繼續(xù)，直到用戶界面的描述完全具體（例如，完全由RenderObjectWidget組成，其描述具體的RenderObject）。
當您描述的用戶界面部分可以動態(tài)更改時（例如由于具有內(nèi)部時鐘驅(qū)動狀態(tài)或依賴于某些系統(tǒng)狀態(tài)），狀態(tài)窗口小部件非常有用。對于僅依賴于對象本身中的配置信息以及窗口小部件膨脹的 BuildContext的組合，請考慮使用 StatelessWidget。
StatefulWidget實例本身是不可變的，并且將它們的可變狀態(tài)存儲在由createState方法創(chuàng)建的單獨State對象中 ，或者存儲在State訂閱的對象中，例如Stream或ChangeNotifier對象，其引用存儲在StatefulWidget的最終字段中本身。
框架在膨脹StatefulWidget時 調(diào)用createState，這意味著如果該窗口小部件已插入到多個位置的樹中，則多個State對象可能與同一StatefulWidget關(guān)聯(lián)。同樣，如果StatefulWidget從樹中移除，后來在樹再次插入時，框架將調(diào)用createState再創(chuàng)建一個新的國家目標，簡化的生命周期狀態(tài)的對象。
如果StatefulWidget的創(chuàng)建者使用GlobalKey作為其 鍵，則StatefulWidget在從樹中的一個位置移動到另一個位置時保持相同的State對象。由于具有GlobalKey的窗口小部件可以在樹中的至多一個位置使用，因此使用GlobalKey的窗口小部件最多只有一個關(guān)聯(lián)元素。當通過將與該窗口小部件關(guān)聯(lián)的（唯一）子樹從舊位置移植到新位置（而不是在該位置重新創(chuàng)建子樹）時，框架利用此屬性將全局鍵從樹中的一個位置移動到另一個位置時利用此屬性。新的位置）。與StatefulWidget關(guān)聯(lián)的State對象與子樹的其余部分一起被移植，這意味著State對象在新位置被重用（而不是被重新創(chuàng)建）。但是，為了有資格進行嫁接，必須將窗口小部件插入到從舊位置移除它的同一動畫幀中的新位置。
StatefulWidget有兩個主要類別。
首先是其中一個分配資源State.initState并在他們的處置State.dispose，但不依賴于InheritedWidget S或致電State.setState。這些小部件通常在應用程序或頁面的根目錄中使用，并通過ChangeNotifier， Stream或其他此類對象與子小部件進行通信。遵循這種模式的有狀態(tài)小部件相對便宜（就CPU和GPU周期而言），因為它們構(gòu)建一次然后永不更新。因此，它們可能有一些復雜和深刻的構(gòu)建方法。
第二類是使用State.setState或依賴于 InheritedWidget的小部件。這些通常會在應用程序的生命周期內(nèi)重建多次，因此最小化重建此類窗口小部件的影響非常重要。（他們也可以使用State.initState或 State.didChangeDependencies并分配資源，但重要的是他們重建。）
可以使用幾種技術(shù)來最小化重建有狀態(tài)窗口小部件的影響：
StatelessWidget類
一個不需要可變狀態(tài)的小部件。
無狀態(tài)窗口小部件是一個窗口小部件，它通過構(gòu)建一個更具體地描述用戶界面的其他窗口小部件來描述用戶界面的一部分。構(gòu)建過程以遞歸方式繼續(xù)，直到用戶界面的描述完全具體（例如，完全由RenderObjectWidget組成，其描述具體的RenderObject）。
當您描述的用戶界面部分不依賴于對象本身的配置信息以及窗口小部件膨脹的BuildContext時，無狀態(tài)窗口小部件非常有用。對于可以動態(tài)更改的組合，例如由于具有內(nèi)部時鐘驅(qū)動狀態(tài)或依賴于某些系統(tǒng)狀態(tài)，請考慮使用StatefulWidget。
無狀態(tài)窗口小部件的構(gòu)建方法通常僅在以下三種情況下調(diào)用：第一次將窗口小部件插入樹中，窗口小部件的父窗口更改其配置時，以及何時依賴于更改的InheritedWidget。
如果窗口小部件的父級將定期更改窗口小部件的配置，或者它依賴于經(jīng)常更改的繼承窗口小部件，則優(yōu)化構(gòu)建方法的性能以保持流暢的呈現(xiàn)性能非常重要。
可以使用幾種技術(shù)來最小化重建無狀態(tài)窗口小部件的影響：
對于任何一款應用來說，頁面的流暢度是用戶體驗最重要的幾個指標之一。我們需要用數(shù)據(jù)的形式標識出頁面的流暢程度。
對于大部分人而言，當每秒的畫面達到60，也就是俗稱60FPS的時候，整個過程就是流暢的。一秒 60 幀，也就意味著平均兩幀之間的間隔為 16.7ms。但并不意味著一秒低于60幀，人眼就會感覺到卡頓。小轟將查閱到的資料列出如下：
官方SDK為開發(fā)者提供的幀率檢測工具，使用非常簡單，在 MaterialApp 下添加屬性 showPerformanceOverlay:true 。
如圖，PerformanceOverLay 會分別為我們展示了構(gòu)建（UI）耗時和渲染（Raster）耗時。
一款pub上的開源工具，鏈接地址： fps_monitor
文/陳爐軍
整理/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ā)?？梢灶A想的是未Flutter發(fā)展的好的話，會逐漸變?yōu)橐粋€從底層到UI層的一個全鏈路的跨平臺開發(fā)，技術(shù)人員分別負責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è)務全部重寫為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主要負責屏幕圖片的渲染，F(xiàn)lutter內(nèi)部實現(xiàn)了一套圖片解碼邏輯，在IO線程將圖片讀取或者從網(wǎng)絡(luò)上拉取之后，通過解碼能夠在IO線程上加載出紋理，交給GPU線程將圖片渲染到屏幕上。但是由于音視頻場景下系統(tǒng)API太過繁多，業(yè)務場景過于復雜。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線程，主要負責GPU發(fā)出的VSync信號時候用當前Dart編譯的機器碼和當前運行環(huán)境創(chuàng)建出Layer Tree。
還有就是IO線程和GPU線程。和大部分OpenGL處理解決方案中一樣，F(xiàn)lutter也采取一個線程責資源加載，一部分負責資源渲染這種思路。
兩個線程之間紋理共享有兩種方式。一種是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驗證之后，我們將這個方案應用到閑魚音視頻組件中，但改造過程中發(fā)現(xiàn)了一些問題。
上圖是攝像頭采集數(shù)據(jù)轉(zhuǎn)換為紋理的一段代碼，其中有兩個操作：首先是切進程，將后面的OpenGL操作都切到cameraQueue中。然后是設(shè)置一次上下文。然后這種限制條件或者說是潛規(guī)則往往在開發(fā)過程中容易被忽略的。而這個條件一旦忽略后果就是出現(xiàn)一些莫名其妙的詭異問題極難排查。因此我們就希望能抽象出一套框架，由框架本身實現(xiàn)線程的切換、上下文和模塊生命周期等的管理，開發(fā)者接入框架以后只需要安心實現(xiàn)自己的算法，而不需要關(guān)心這些潛規(guī)則還有其他一些重復的邏輯操作。
在引入Flutter之前閑魚的音視頻架構(gòu)與大部分音視頻邏輯一樣采用分層架構(gòu)：
1：底層是一些獨立模塊
2：SDK層是對底層模塊的封裝
3：最上層是UI層。
引入Flutter之后，通過分析各個模塊的使用場景，我們可以得出一個假設(shè)或者說是抽象：音視頻應用在終端上可以歸納為視頻幀解碼之后視頻數(shù)據(jù)幀在各個模塊之間流動的過程，基于這種假設(shè)去做Flutter音視頻框架的抽象。
咸魚Flutter多媒體開源組件
整個Flutter音視頻框架抽象分為管線和數(shù)據(jù)的抽象、模塊的抽象、線程統(tǒng)一管理和上下文同一管理四部分。
管線，其實就是視頻幀流動的管道。數(shù)據(jù)，音視頻中涉及到的數(shù)據(jù)包括紋理、Bit Map以及時間戳等。結(jié)合現(xiàn)有的應用場景我們定義了管線流通數(shù)據(jù)以Texture為主數(shù)據(jù)，同時可以選擇性的添加Bit Map等作為輔助數(shù)據(jù)。這樣的數(shù)據(jù)定義方式，避免重復的創(chuàng)建和銷毀紋理帶來的性能開銷以及多線程訪問紋理帶來的一些問題。也滿足一些特殊模塊對特殊數(shù)據(jù)的需求。同時也設(shè)計了紋理池來管理管線中的紋理數(shù)據(jù)。
模塊：如果把管線和數(shù)據(jù)比喻成血管和血液，那框架音視頻的場景就可以比喻成器官，我們根據(jù)模塊所在管線的位置抽象出采集、處理和輸出三個基類。這三個基類里實現(xiàn)了剛才說的線程切換，上下文切換，格式轉(zhuǎn)換等等共同邏輯，各個功能模塊通過集成自這些基類，可以避免很多重復勞動。
線程：每一個模塊初始化的時候，初始化函數(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)一個簡單的場景，比如畫面實時預覽和濾鏡處理功能，
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)部開源流程。預計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ā)音視頻應用時可以充分利用閑魚開源出的音視頻模塊能力，搭建APP框架，開發(fā)者只要去負責實現(xiàn)特殊需求模塊就可以，盡可能的減少重復勞動。
重慶分公司
重慶分公司
