Flutter支持穩(wěn)定的桌面設(shè)備開(kāi)發(fā)已經(jīng)一段時(shí)間了,不得不說(shuō),F(xiàn)lutter多平臺(tái)支持的特性真的很香。我本人并沒(méi)有任何桌面開(kāi)發(fā)的經(jīng)驗(yàn),但仍然使用Flutter開(kāi)發(fā)出了一個(gè)桌面版小程序,功能很簡(jiǎn)單,就是對(duì)輸入的json做格式化處理和轉(zhuǎn)模型。
專注于為中小企業(yè)提供成都網(wǎng)站設(shè)計(jì)、成都網(wǎng)站制作服務(wù),電腦端+手機(jī)端+微信端的三站合一,更高效的管理,為中小企業(yè)克東免費(fèi)做網(wǎng)站提供優(yōu)質(zhì)的服務(wù)。我們立足成都,凝聚了一批互聯(lián)網(wǎng)行業(yè)人才,有力地推動(dòng)了上千企業(yè)的穩(wěn)健成長(zhǎng),幫助中小企業(yè)通過(guò)網(wǎng)站建設(shè)實(shí)現(xiàn)規(guī)模擴(kuò)充和轉(zhuǎn)變。
話不多說(shuō),先來(lái)看看實(shí)際效果。 項(xiàng)目源碼地址
開(kāi)發(fā)環(huán)境如下:
Flutter : 2.8.1
Dart : 2.15.1
IDE : VSCode
JSON作為我們?nèi)粘i_(kāi)發(fā)工作中經(jīng)常要打交道的一種數(shù)據(jù)格式,它共有6種數(shù)據(jù)類型: null , num , string , object , array , bool 。我們勢(shì)必對(duì)它又愛(ài)又恨。愛(ài)他因?yàn)樗鳛閿?shù)據(jù)處理的一種格式確實(shí)非常方便簡(jiǎn)潔。但是在我們做Flutter開(kāi)發(fā)中,又需要接觸到j(luò)son解析時(shí),就會(huì)感覺(jué)非常棘手,因?yàn)閒lutter沒(méi)有反射,導(dǎo)致json轉(zhuǎn)模型這塊需要手寫(xiě)那繁雜的映射關(guān)系。就像下面這樣子。
數(shù)據(jù)量少還能接受,一旦量大,那么光手寫(xiě)這個(gè)解析方法都能讓你懷疑人生。更何況手寫(xiě)還有出錯(cuò)的可能。好在官方有個(gè)工具**json_serializable**可以自動(dòng)生成這塊轉(zhuǎn)換代碼,也解決了flutter界json轉(zhuǎn)模型的空缺。當(dāng)然,業(yè)界也有專門(mén)解析json的網(wǎng)站,可以自動(dòng)生成dart代碼,使用者在生成后復(fù)制進(jìn)項(xiàng)目中即可,也是非常方便的。
本項(xiàng)目以json解析為切入點(diǎn),和大家一起來(lái)看下flutter是如何開(kāi)發(fā)桌面應(yīng)用的。
要讓我們的flutter項(xiàng)目支持桌面設(shè)備。我們首先需要修改下flutter的設(shè)置。如下,讓我們的項(xiàng)目支持 windows 和 macos 系統(tǒng)。
接下來(lái)使用 flutter create 命令創(chuàng)建我們的模版工程。
創(chuàng)建完項(xiàng)目后,我們就可以 run 起來(lái)了。
先來(lái)看下整體界面,界面四塊,分別為功能模塊、文件選擇模塊、輸入模塊、輸出模塊。
我們?cè)谛陆ㄒ粋€(gè)桌面應(yīng)用時(shí),默認(rèn)的模版又一個(gè)Appbar,此時(shí)應(yīng)用可以用鼠標(biāo)拖拽移動(dòng),放大縮小,還可以縮到很小。但是,我們一旦去掉這個(gè)導(dǎo)航欄,那么窗口就不能用鼠標(biāo)拖動(dòng)了,并且我們往往不希望用戶將我們的窗口縮放的很小,這會(huì)導(dǎo)致頁(yè)面異常,一些重要信息都展示不全。因此這里需要借助第三方組件 bitsdojo_window 。通過(guò) bitsdojo_window ,我們可以實(shí)現(xiàn)窗口的定制化,拖動(dòng),最小尺寸,最大尺寸,窗口邊框,窗口頂部放大、縮小、關(guān)閉的按鈕等。
通過(guò) InkWell 組件,可以捕捉到手勢(shì)、鼠標(biāo)、觸控筆的移動(dòng)和停留位置
這個(gè)功能是鼠標(biāo)移動(dòng)后的UI交互界面。要在窗口上顯示一個(gè)提示框,可以使用 Overlay 。需要注意的是,由于在 Overlay 上的 text 的根結(jié)點(diǎn)不是 Material 風(fēng)格的組件,因此會(huì)出現(xiàn)黃色的下劃線。因此一定要用 Material 包一下 text 。并且你必須給創(chuàng)建的 OverlayEntry 一個(gè)位置,否則它將全屏顯示。
讀取說(shuō)表拖拽的文件一開(kāi)始想嘗試使用 InkWell 組件,但是這個(gè)組件無(wú)法識(shí)別拖拽中的鼠標(biāo),并且也無(wú)法從中拿到文件信息。因此放棄。后來(lái)從文章《Flutter-2天寫(xiě)個(gè)桌面端APP》中發(fā)現(xiàn)一個(gè)可讀取拖拽文件的組件 desktop_drop ,能滿足要求。
使用開(kāi)源組件 file_picker ,選完圖片后的操作和拖拽選擇圖片后的操作一致。
Textfield 如果要顯示富文本,那么需要自定義 TextEditingController 。并重寫(xiě) buildTextSpan 方法。
在做導(dǎo)出功能時(shí)遇到下列報(bào)錯(cuò),保存提示為沒(méi)有權(quán)限訪問(wèn)對(duì)應(yīng)目錄下的文件。
通過(guò)Apple的開(kāi)發(fā)文檔找到有關(guān)權(quán)限問(wèn)題的說(shuō)明。其中有個(gè)授權(quán)私鑰的key為 com.apple.security.files.downloads.read-write ,表示 對(duì)用戶的下載文件夾的讀/寫(xiě)訪問(wèn)權(quán)限 。那么,使用Xcode打開(kāi)Flutter項(xiàng)目中的mac應(yīng)用,修改工程目錄下的 DebugProfile.entitlements 文件,向 entitlements 文件中添加 com.apple.security.files.downloads.read-write ,并將值設(shè)置為YES,保存后重啟Flutter項(xiàng)目。發(fā)現(xiàn)已經(jīng)可以向下載目錄中讀寫(xiě)文件了。
當(dāng)然,這是正常操作。還有個(gè)騷操作就是關(guān)閉系統(tǒng)的沙盒機(jī)制。將 entitlements 文件的 App Sandbox 設(shè)置為NO。這樣我們就可以訪問(wèn)任意路徑了。當(dāng)然關(guān)閉應(yīng)用的沙盒也就相當(dāng)于關(guān)閉了應(yīng)用的防護(hù)機(jī)制,因此這個(gè)選項(xiàng)慎用。
原文地址:
使用這個(gè)版本的GetX寫(xiě)了Demo之后,發(fā)現(xiàn)有幾個(gè)問(wèn)題:
感覺(jué)不太像是穩(wěn)定版本,存在一些比較明顯的問(wèn)題;而且2.0.6到2.0.7只是一個(gè)小版本,全局狀態(tài)管理邏輯似乎就有比較大的改動(dòng)。
不支持響應(yīng)式編程,這個(gè)版本的狀態(tài)管理還是基于state的邏輯;因?yàn)橄胍容^高效的解耦頁(yè)面和邏輯,可能需要搭配響應(yīng)式編程框架。
相關(guān)功能可能比較少,沒(méi)有最新版本的功能那么全面。
Flutter是Google開(kāi)源的構(gòu)建用戶界面(UI)工具包,幫助開(kāi)發(fā)者通過(guò)一套代碼庫(kù)高效構(gòu)建多平臺(tái)精美應(yīng)用,支持移動(dòng)、Web、桌面和嵌入式平臺(tái)。
Flutter 開(kāi)源、免費(fèi),擁有寬松的開(kāi)源協(xié)議,適合商業(yè)項(xiàng)目。Flutter已推出穩(wěn)定的2.0版本。
產(chǎn)生背景:
Flutter可以方便的加入現(xiàn)有的工程中。在全世界,F(xiàn)lutter 正在被越來(lái)越多的開(kāi)發(fā)者和組織使用,并且 Flutter是完全免費(fèi)、開(kāi)源的。它也是構(gòu)建未來(lái)的 Google Fuchsia 應(yīng)用的主要方式。
Flutter組件采用現(xiàn)代響應(yīng)式框架構(gòu)建,這是從React中獲得的靈感,中心思想是用組件(widget)構(gòu)建你的UI。
組件描述了在給定其當(dāng)前配置和狀態(tài)時(shí)他們顯示的樣子。當(dāng)組件狀態(tài)改變,組件會(huì)重構(gòu)它的描述(description),F(xiàn)lutter 會(huì)對(duì)比之前的描述, 以確定底層渲染樹(shù)從當(dāng)前狀態(tài)轉(zhuǎn)換到下一個(gè)狀態(tài)所需要的最小更改。
前言
為什么跨平臺(tái)是發(fā)展趨勢(shì)?
同一個(gè)應(yīng)用,各個(gè)“端”獨(dú)立開(kāi)發(fā),不僅開(kāi)發(fā)周期長(zhǎng),而且人員成本高。同時(shí),作為技術(shù)人員,也不應(yīng)該滿足于這種重復(fù)、低能的工作狀態(tài)。在這樣的形勢(shì)下,跨平臺(tái)的技術(shù)方案也受到越來(lái)越多人和企業(yè)的關(guān)注。
本篇文章我將從原理、優(yōu)缺點(diǎn)等方面為大家分享跨平臺(tái)技術(shù)
一. H5
說(shuō)到跨平臺(tái),沒(méi)人不知道H5。不管是在Mac、Windows、Linux、iOS、Android還是其他平臺(tái),只要給一個(gè)瀏覽器,連“月球”上它都能跑。
1.瀏覽器架構(gòu)
下面,我們來(lái)看看讓H5如此橫行霸道的瀏覽器的架構(gòu):
瀏覽器由以上7個(gè)部分組成,而“渲染引擎”是性能優(yōu)化的重中之重,一起了解其中的渲染原理。
2.渲染引擎原理
不同的瀏覽器內(nèi)核不同,渲染過(guò)程會(huì)不太一樣,但主要流程還是一致的。
分為下面6步驟:
從以上6步,我們可以總結(jié)渲染優(yōu)化的要點(diǎn):
以上就是瀏覽器端的內(nèi)容。但H5作為跨平臺(tái)技術(shù)的載體,是如何與不同平臺(tái)的App進(jìn)行交互的呢?這時(shí)候JSBridge就該出場(chǎng)了。
3.JSBridge原理
JSBridge,顧名思義,是JS和Native之間的橋梁,用來(lái)進(jìn)行JS和Native之間的通信。
通信分為以下兩個(gè)維度:
那么App內(nèi)加載H5的過(guò)程是什么樣的呢?
4.App打開(kāi)H5過(guò)程
打開(kāi)H5分為4個(gè)階段:
這四步,對(duì)應(yīng)的過(guò)程如上圖所以,我們可以針對(duì)性的做性能優(yōu)化。
5.優(yōu)缺點(diǎn)分析
下面,我們進(jìn)行H5的優(yōu)缺點(diǎn)分析:
優(yōu)點(diǎn)
缺點(diǎn)
雖然H5目前還存在不足,但隨著PWA、WebAssembly等技術(shù)的進(jìn)步,相信H5在未來(lái)能夠得到越來(lái)也好的發(fā)展。
二.小程序
2018年是微信小程序飛速發(fā)展的一年,19年,各大廠商快速跟進(jìn),已經(jīng)有了很大的影響力。下面,我們以微信小程序?yàn)槔?,分析小程序的技術(shù)架構(gòu)。
小程序跟H5一樣,也是基于Webview實(shí)現(xiàn)。但它包含View視圖層、App Service邏輯層兩部分,分別獨(dú)立運(yùn)行在各自的WebView線程中。
1.View
可以理解為h5的頁(yè)面,提供UI渲染。由WAWebview.js來(lái)提供底層的功能,具體如下:
每個(gè)窗口都有一個(gè)獨(dú)立的WebView進(jìn)程,因此微信限制不能打開(kāi)超過(guò)5個(gè)層級(jí)的頁(yè)面來(lái)保障用戶體驗(yàn)。
2. App Service
提供邏輯處理、數(shù)據(jù)請(qǐng)求、接口調(diào)用。由WAService.js來(lái)提供底層的功能,具體如下:
運(yùn)行環(huán)境:
僅有一個(gè)WebView進(jìn)程
3.View App Service通信
視圖層和邏輯層通過(guò)系統(tǒng)層的JSBridage進(jìn)行通信,邏輯層把數(shù)據(jù)變化通知到視圖層,觸發(fā)視圖層頁(yè)面更新,視圖層將觸發(fā)的事件通知到邏輯層進(jìn)行業(yè)務(wù)處理。
4. 優(yōu)缺點(diǎn)分析
優(yōu)點(diǎn)
缺點(diǎn)
既然WebView性能不佳,那有沒(méi)有更好的方案呢?下面我們看看React Native。
三.React Native
RN的理念是在不同平臺(tái)上編寫(xiě)基于React的代碼,實(shí)現(xiàn)Learn once, write anywhere。
Virtual DOM在內(nèi)存中,可以通過(guò)不同的渲染引擎生成不同平臺(tái)下的UI,JS和Native之間通過(guò)Bridge通信
1.React Native 工作原理
在 React 框架中,JSX 源碼通過(guò) React 框架最終渲染到了瀏覽器的真實(shí) DOM 中,而在 React Native 框架中,JSX 源碼通過(guò) React Native 框架編譯后,與Native原生的UI組件進(jìn)行映射,用原生代替DOM元素來(lái)渲染,在UI渲染上非常接近Native App。
2.React Native 與Native平臺(tái)通信
3.優(yōu)缺點(diǎn)分析
優(yōu)點(diǎn)
缺點(diǎn)
4.RN展望
雖然RN還存在不足,但RN新版本已經(jīng)做了如下改進(jìn),并且RN團(tuán)隊(duì)也在積極準(zhǔn)備大版本重構(gòu),能否成為開(kāi)發(fā)者們所信賴的跨平臺(tái)方案,讓我們拭目以待。
既然React Native在渲染方面還擺脫不了原生,那有沒(méi)有一種方案是直接操控GPU,自制引擎渲染呢,我們終于迎來(lái)了Flutter!
四.Flutter
Flutter是Google開(kāi)發(fā)的一套全新的跨平臺(tái)、開(kāi)源UI框架,支持iOS、Android系統(tǒng)開(kāi)發(fā),并且是未來(lái)新操作系統(tǒng)Fuchsia的默認(rèn)開(kāi)發(fā)套件。渲染引擎依靠跨平臺(tái)的Skia圖形庫(kù)來(lái)實(shí)現(xiàn),依賴系統(tǒng)的只有圖形繪制相關(guān)的接口,可以在最大程度上保證不同平臺(tái)、不同設(shè)備的體驗(yàn)一致性,邏輯處理使用支持AOT的Dart語(yǔ)言,執(zhí)行效率也比JavaScript高得多。
1.Flutter架構(gòu)原理
2.Dart優(yōu)勢(shì)
很多人會(huì)好奇,為什么Flutter要用Dart,而不是用JavaScript開(kāi)發(fā),這里列下Dart的優(yōu)勢(shì)
3.優(yōu)缺點(diǎn)分析
優(yōu)點(diǎn)
缺點(diǎn)
Flutter:支持多平臺(tái)的輕量級(jí)UI框架
詳見(jiàn) Fuchsia 于2021年8月8日發(fā)布的文章: 為什么說(shuō) Flutter 充滿機(jī)會(huì):細(xì)數(shù) Flutter 的優(yōu)異特性和革命性創(chuàng)新之處
文/陳爐軍
整理/LiveVideoStack
大家好,我是阿里巴巴閑魚(yú)事業(yè)部的陳爐軍,本次分享的主題是Flutter浪潮下的音視頻研發(fā)探索,主要內(nèi)容是針對(duì)閑魚(yú)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ì)閑魚(yú)在音視頻實(shí)踐過(guò)程中碰到的一些Flutter問(wèn)題提出了一些解決方案——TPM音視頻框架。最后是閑魚(yú)Flutter多媒體開(kāi)源組件的介紹。
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)開(kāi)發(fā)??梢灶A(yù)想的是未Flutter發(fā)展的好的話,會(huì)逐漸變?yōu)橐粋€(gè)從底層到UI層的一個(gè)全鏈路的跨平臺(tái)開(kāi)發(fā),技術(shù)人員分別負(fù)責(zé)SDK和UI層的開(kāi)發(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為例,蘋(píng)果的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ì)者和開(kāi)發(fā)者。至于現(xiàn)在到底是一個(gè)什么狀況:
在閑魚(yú)的實(shí)踐中,我們發(fā)現(xiàn)在正常的開(kāi)發(fā)沒(méi)有特意的去優(yōu)化UI代碼的情況下,在一些低端機(jī)上,F(xiàn)lutter界面的流暢性是比Native界面要好的。
雖然現(xiàn)在閑魚(yú)某些場(chǎng)景下會(huì)有卡頓閃退等情況,但是這是一個(gè)新事物發(fā)展過(guò)程中的必然問(wèn)題,我們相信未來(lái)性能肯定不會(huì)成為限制Flutter發(fā)展的瓶頸的。
在閑魚(yú)實(shí)踐Flutter的過(guò)程中,混合棧和音視頻是其中比較難解決的兩個(gè)問(wèn)題,混合棧是指一個(gè)APP在Flutter過(guò)程中不可能一口氣將所有業(yè)務(wù)全部重寫(xiě)為Flutter,所以這是一個(gè)逐步迭代的過(guò)程,這期間原生native界面與Flutter界面共存的狀態(tài)就稱之為混合棧。閑魚(yú)在混合棧上也有一些比較好的輸出,例如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樹(shù),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提出了一種讓第三方開(kāi)發(fā)者來(lái)實(shí)現(xiàn)音視頻組件的方式,而這些音視頻組件的視頻渲染出口,就是TextureLayer。
在整個(gè)Layer Tree渲染的過(guò)程中,TextureLayer的數(shù)據(jù)紋理需要由外部第三方開(kāi)發(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)聽(tīng)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后再寫(xiě)入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è)線程下資源是互相可見(jiàn)可以共享的。
Platform線程是主線程,F(xiàn)lutter中有一個(gè)很奇怪的設(shè)定,GPU線程和主線程共用一個(gè)Context。并且在主線程也有很多OpenGL 操作。
這樣的設(shè)計(jì)會(huì)給音視頻開(kāi)發(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)用到閑魚(yú)音視頻組件中,但改造過(guò)程中發(fā)現(xiàn)了一些問(wèn)題。
上圖是攝像頭采集數(shù)據(jù)轉(zhuǎn)換為紋理的一段代碼,其中有兩個(gè)操作:首先是切進(jìn)程,將后面的OpenGL操作都切到cameraQueue中。然后是設(shè)置一次上下文。然后這種限制條件或者說(shuō)是潛規(guī)則往往在開(kāi)發(fā)過(guò)程中容易被忽略的。而這個(gè)條件一旦忽略后果就是出現(xiàn)一些莫名其妙的詭異問(wèn)題極難排查。因此我們就希望能抽象出一套框架,由框架本身實(shí)現(xiàn)線程的切換、上下文和模塊生命周期等的管理,開(kāi)發(fā)者接入框架以后只需要安心實(shí)現(xiàn)自己的算法,而不需要關(guān)心這些潛規(guī)則還有其他一些重復(fù)的邏輯操作。
在引入Flutter之前閑魚(yú)的音視頻架構(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音視頻框架的抽象。
咸魚(yú)Flutter多媒體開(kāi)源組件
整個(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)建和銷(xiāo)毀紋理帶來(lái)的性能開(kāi)銷(xiāo)以及多線程訪問(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è)模塊之間資源都是共享可見(jiàn)的,F(xiàn)lutter和音視頻native之間也是互相共享可見(jiàn)的。
基于上述框架如果要實(shí)現(xiàn)一個(gè)簡(jiǎn)單的場(chǎng)景,比如畫(huà)面實(shí)時(shí)預(yù)覽和濾鏡處理功能,
1:需要選擇功能模塊,功能模塊包括攝像頭模塊、濾鏡處理模塊和Flutter畫(huà)面渲染模塊,
2:需要配置模塊參數(shù),比如采集分辨率、濾鏡參數(shù)和前后攝像頭設(shè)置等,
3:在創(chuàng)建視頻管線后使用已配置的參數(shù)創(chuàng)建模塊
4:最后管線搭載模塊,開(kāi)啟管線就可以實(shí)現(xiàn)這樣簡(jiǎn)單的功能。
上圖為整個(gè)功能實(shí)現(xiàn)的代碼和結(jié)構(gòu)圖。
結(jié)合上述音視頻框架,閑魚(yú)實(shí)現(xiàn)了Flutter多媒體開(kāi)源組件。
組要包含四個(gè)基本組件分別是:
1:視頻圖像拍攝組件
2:播放器組件
3:視頻圖像編輯組件
4:相冊(cè)選擇組件
現(xiàn)在這些組件正在走內(nèi)部開(kāi)源流程。預(yù)計(jì)9月份,相冊(cè)和播放器會(huì)實(shí)現(xiàn)開(kāi)源。
后續(xù)展望和規(guī)劃
1:實(shí)現(xiàn)開(kāi)頭所說(shuō)的從底層SDK到UI的全鏈路的跨端開(kāi)發(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)容為開(kāi)源共建,閑魚(yú)開(kāi)源的內(nèi)容不僅包括拍攝、編輯組件,還包括了很多底層模塊,希望有開(kāi)發(fā)者在基于Flutter開(kāi)發(fā)音視頻應(yīng)用時(shí)可以充分利用閑魚(yú)開(kāi)源出的音視頻模塊能力,搭建APP框架,開(kāi)發(fā)者只要去負(fù)責(zé)實(shí)現(xiàn)特殊需求模塊就可以,盡可能的減少重復(fù)勞動(dòng)。
Flutter是谷歌的移動(dòng)UI框架,可以快速在iOS和Android上構(gòu)建高質(zhì)量的原生用戶界面。 Flutter可以與現(xiàn)有的代碼一起工作。在全世界,F(xiàn)lutter正在被越來(lái)越多的開(kāi)發(fā)者和組織使用,并且Flutter是完全免費(fèi)、開(kāi)源的。(-中文網(wǎng);-英文網(wǎng))
Flutter是一種趨勢(shì),勢(shì)必會(huì)取代RN,成為最主流的跨平臺(tái)開(kāi)發(fā)框架,基于Dart語(yǔ)言。ios開(kāi)發(fā)必須Mac電腦。android開(kāi)發(fā)window、linux、Mac均可。