下面這種情況下,為 InkWell 設(shè)置的 splashColor 不會生效:
在巫山等地區(qū),都構(gòu)建了全面的區(qū)域性戰(zhàn)略布局,加強發(fā)展的系統(tǒng)性、市場前瞻性、產(chǎn)品創(chuàng)新能力,以專注、極致的服務(wù)理念,為客戶提供成都做網(wǎng)站、網(wǎng)站建設(shè) 網(wǎng)站設(shè)計制作定制制作,公司網(wǎng)站建設(shè),企業(yè)網(wǎng)站建設(shè),品牌網(wǎng)站建設(shè),網(wǎng)絡(luò)營銷推廣,成都外貿(mào)網(wǎng)站建設(shè),巫山網(wǎng)站建設(shè)費用合理。
需要用 Material 去除背景色,然后將顏色設(shè)置在 InkWell 外部:
在 Dialog builder 中使用 WillPopScope 禁用返回鍵返回:
注意:使用此方法同時也會禁用 iOS 上的手勢滑動返回功能,推薦判斷平臺后再使用。
修改對話框中的復(fù)選框狀態(tài),最簡便的方法是通過 Element 中的 markNeedsBuild 方法:
當然,更推薦的做法是通過 StatefulBuilder ,然后就可以在 Dialog 中調(diào)用 setState 方法了,不過在調(diào)用 setState 時需要判斷 Dialog 是否已經(jīng)關(guān)閉,否則會造成 setState() called after dispose() 的錯誤,可以通過添加一個標志位來解決,如下:
在 Web 中加載網(wǎng)絡(luò)圖片有時會失敗,遇到這樣的報錯: Exception caught by image resource service... ,造成該錯誤的原因通常是,圖片跨域了(見 跨域資源共享 )。最簡單的解決辦法是, 使用 HTML 渲染加載 ,而不是默認的 CanvasKit。
Flutter 中所有的 list 默認都是沒有 ScrollBar 的,必須使用 ScrollBar 組件。ScrollBar 組件通過監(jiān)聽 ScrollView 的 ScrollNotification 來刷新位置,所以 List 的長度必須是固定的。
當使用 WebView 等高度不定的組件時會出現(xiàn)內(nèi)容被截斷的情況,通??梢允褂?NestedScrollView 來解決該問題,需要在 WebView 外部嵌套 SingleChildScrollView。
雖然使用了緩存,而且也是用 builder 加載圖片的,但是發(fā)現(xiàn)一個現(xiàn)象:滑動屏幕后圖片短暫消失并重新加載了。圖片高度很高時這種現(xiàn)象更加明顯,其原因是超出屏幕范圍一定距離的組件被重新渲染了。解決方法是在 ListView 上設(shè)置 cacheExtent 參數(shù):
該參數(shù)的作用是改變超出屏幕高度后繼續(xù)渲染的范圍(以像素為單位),比如設(shè)置成 9999 后意味著超出屏幕 10000 像素以內(nèi)的內(nèi)容都會被保留下來。
借助 IntrinsicHeight 組件:
另外,IntrinsicHeight 還可以用于 Dialog 或者 BottomSheet 中,使得其中的元素 顯示內(nèi)在元素的高度 ,從而避免元素因為約束的存在而不顯示或者高度太高(比如在使用了 Column 或者 Row 的時候)。
在通過 Uri 的 queryParameters 獲取 query 參數(shù)時,發(fā)現(xiàn)有些鏈接會拋出下面異常:
造成該異常的原因是 Uri 默認使用 utf-8 解碼超鏈接字符串,如果鏈接中包含非 utf-8 字符,就會造成上面的錯誤,相關(guān) issue 見: issue #31621 。目前該 issue 處于 open 的狀態(tài),暫時的解決辦法是,在所有使用到 queryParameter 的地方用 try..catch 捕捉可能拋出的異常。
Flutter 開發(fā)非常依賴各種官方或第三方的插件,而在使用這些插件時多少都會遇到一些問題,大部分問題都可以通過搜索和查找 issue 來解決。這里記錄下一些我在使用部分插件時遇到的問題及其解決方法。
目前該庫沒有圖片加載完成的回調(diào)(見 issue #545 ),不過我們可以通過在 imageBuilder 中來添加回調(diào):
這是一個應(yīng)用內(nèi)更新插件,安卓 10 以上安裝時需要在 manifest 中添加以下內(nèi)容:
目前功能最強大的 WebView 插件,基本能滿足絕大部分移動端網(wǎng)頁加載的需求,而且可定制化程度高。
一般通過 CookieManager 修改 Cookie,攔截請求并修改請求對象的 Header 不會生效。
InAppWebViewOptions 的 userAgent 只在 iOS 上生效,而 applicationNameForUserAgent 只在 Android 上生效,所以最好的做法是分平臺設(shè)置 InAppWebViewOptions ,而且需要注意,由于設(shè)置 userAgent 后會覆蓋默認的 UserAgent,所以如果需要在默認的 UserAgent 上添加其它參數(shù),iOS 上需要通過 InAppWebViewController.getDefaultUserAgent() 獲取默認 UserAgent 參數(shù),而 Android 不需要添加。
如果圖片源或者請求是 http 的,為了在 Android 上正常加載請求,必須在 AndroidInAppWebViewOptions 中將 mixedContentMode 設(shè)置為 AndroidMixedContentMode.MIXED_CONTENT_ALWAYS_ALLOW 。
當我們想要設(shè)置全屏圖片的時候,由于默認的 Constraint 會將圖片居中顯示,所以圖片四周會留有空隙。為了去除這個限制,我們需要 Xcode 中打開 LaunchScreen.storyboard,然后在 View Controller 的 View 和 LaunchImage 上的 Safe Area 去掉。
具體設(shè)置方法:右側(cè) Inspector 面板 Show the Size inspector 解選 Layout Margins 中的 Safe Area Relative Margins,拖動圖片占滿全屏,然后根據(jù) View Controller Scene 的 Warning,更新 Constraint 就可以了。
在集成某些三方庫之后,在使用命令行運行 iOS 模擬器的時候可能會遇到下面這個報錯:
這是因為 iOS 模擬器未來將會兼容 arm64 架構(gòu),但是目前還不支持,所以我們需要修改 Build Setting 使得能夠在 x86_64 的模擬器上運行,操作步驟見 這里 。
文/陳爐軍
整理/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(yù)想的是未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è)務(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主要負責屏幕圖片的渲染,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線程,主要負責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驗證之后,我們將這個方案應(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ā)者只要去負責實現(xiàn)特殊需求模塊就可以,盡可能的減少重復(fù)勞動。
場景:多個組件共用一個狀態(tài),子組件通過方法改變父組件狀態(tài)
思路:狀態(tài)和管理方法定義在父組件,通過構(gòu)造函數(shù)傳遞給子組件
其他子組件按照同樣方法接收即可共用該父組件的狀態(tài)。
在Tree中從上往下高效傳遞數(shù)據(jù)的基類widget , 定義為:abstract class InheritedWidget extends ProxyWidget
Flutter的響應(yīng)式開發(fā)與React類似,數(shù)據(jù)都是自頂向下的。
假設(shè)有祖先組點A,中間經(jīng)過結(jié)點B, C,然后到結(jié)點D,D需要從A中獲取數(shù)據(jù)f,那按照自頂向下數(shù)據(jù)流轉(zhuǎn),f需要依次傳遞給B及C,最后才到C。這樣開發(fā)極為不靈活,成本也比較高。所有Flutter需要有跨結(jié)點(只能是祖先后代節(jié)點,不能跨兄弟節(jié)點)高效傳遞數(shù)據(jù)的方案。
大體意思如下:
InheritedWidget 是在樹中高效向下傳遞信息的基類部件;
調(diào)用[BuildContext.inheritFromWidgetOfExactType]方法可以從 BuildContext 中獲取到最近的 InheritedWidget 類型的實例;
在 InheritedWidget 類型的控件被引用,也就是調(diào)用過 inheritFromWidgetOfExactType 方法后,當 InheritedWidget 自身狀態(tài)改變時,會導(dǎo)致引用了 InheritedWidget 類型的子控件重構(gòu)(rebuild)。
這里隨便定義一個人 Person 類。
創(chuàng)建一個類繼承 InheritedWidget,并實現(xiàn) updateShouldNotify 方法。
之前說到調(diào)用[BuildContext.inheritFromWidgetOfExactType]方法可以從 BuildContext 中獲取到最近的 InheritedWidget 類型的實例,所以此處定義一個靜態(tài)的 of 方法,通過傳入的 context 獲取到最近的 InheriedDataWidget 實例。
1.定義數(shù)據(jù)模型
這里隨便定義一個 Person 類。
2.自定義 InheritedWidget 控件類
創(chuàng)建一個類繼承 InheritedWidget,并實現(xiàn) updateShouldNotify 方法。
之前說到調(diào)用[BuildContext.inheritFromWidgetOfExactType]方法可以從 BuildContext 中獲取到最近的 InheritedWidget 類型的實例,所以此處定義一個靜態(tài)的 of 方法,通過傳入的 context 獲取到最近的 InheriedDataWidget 實例。
3.InheriedDataWidget 的使用
InheriedDataWidget 使用起來也很簡單,它本身也是一個控件,只要在任意一個頁面的子控件調(diào)用其構(gòu)造方法就行,這里我們定義一個形如的 Widget 樹。
WidgetA 是一個 StatefulWidget 類型的控件,可以調(diào)用 setState 刷新,如果是繼承人 Stateless 類型的控件,那我們也可以通過 Stream 或者其他方式刷新數(shù)據(jù),感興趣的請看[什么是 Stream? Dart
WidgetA1_1 類
WidgetA1_2 類
WidgetA1_3 類
當我們點擊 floatingActionButton 的時候,WidgetA1, WidgetA1_1, WidgetA1_2 的控件都會更新 Person 的信息,而且每點 floatingActionButton 一次, 當我們點擊 floatingActionButton 的時候,WidgetA1, WidgetA1_1, WidgetA1_2 的控件都會更新 Person 的信息,而且每點 floatingActionButton 一次,都會輸出:
如果我們試圖在和 WidgetA 的同一層級的兄弟節(jié)點去訪問 InheriedDataWidget 的 Person 數(shù)據(jù),是不行的,因為父節(jié)點中并沒有插入 InheriedDataWidget。
把 WidgetB 和 WidgetA 保持同一節(jié)點
這也體現(xiàn)了 Inheried(遺傳) 這一單詞的特性,遺傳只存在于父子。兄弟不存在遺傳的關(guān)系。
這種數(shù)據(jù)共享的方式在某些場景還是很有用的,就比如說全局主題,字體大小,字體顏色的變更,只要在 App 根層級共享出這些配置數(shù)據(jù),然后在觸發(fā)數(shù)據(jù)改變之后,所有引用到這些共享數(shù)據(jù)的地方都會刷新,這換主題,字體是不是就很輕松,事實上 Theme.of(context).primaryColor 之流就是這么干的。
以上就是有關(guān)InheritedWidget的使用。
自己也是從事Android開發(fā)5年有余了;整理了一些Android開發(fā)技術(shù)核心筆記和面經(jīng)題綱,有關(guān)更多Android開發(fā)進階技術(shù)資料、面經(jīng)題綱、核心技術(shù)筆記; 想要進階自己、拿高薪的同學(xué)請私信我回復(fù)“核心筆記”或“面試”領(lǐng)取!
Android 利用surface實現(xiàn)Flutter外接紋理
①Java層FlutterRenderer創(chuàng)建SurfaceTexture和textureId。
②將surfaceTexture和textureId通過JNI向引擎層注冊
③向引擎注冊過程中通過層層方法最后在texture.cc的TextureRegistry由map以鍵值對形式緩存實例對象。
④將需要顯示圖片在SurfaceTexture上離屏渲染。
⑤Java層創(chuàng)建的textureId通過Channel傳遞到Dart層作為Texture組件入?yún)ⅰ?/p>
⑥D(zhuǎn)art的Texture組件接收textureId入?yún)⒑笙蛳聦咏M件實例化。
⑦在SceneBuilder調(diào)用addTexture時執(zhí)行引擎層創(chuàng)建TextureLayer。
⑧最終在texture.cc中TextureRegistry的map根據(jù)TextureId獲取SurfaceTexture實例。
使用Native(以Android為例)播放器構(gòu)建Flutter播放插件
iOS 實現(xiàn)Flutter外接紋理
點擊開始----控制版面-----打印機和傳真機----點擊添加打印機----在彈出的添加打印機向?qū)υ捒蛑悬c下一步----選第一項本地打印機再點下一步----下一步直到出現(xiàn)廠商一欄時,點擊從磁盤安裝.再將你的打印機驅(qū)動放入光驅(qū)中..向下就行了
右鍵單擊要共享的打印機,然后單擊“共享”。 根據(jù)計算機上是否啟用了共享,在“共享”選項卡上的選項會各不相同。要了解下一步怎么做,請在“共享”選項卡上單擊有相應(yīng)說明的選項。 一條消息提示打印機共享必須打開 需要運行“網(wǎng)絡(luò)安裝向?qū)А?,以啟用打印機共享。首先單擊“共享”選項卡上的鏈接,然后執(zhí)行系統(tǒng)指示以啟動共享。一旦啟用了共享,請再次執(zhí)行該過程。 顯示共享或不共享打印機的選項 在“共享”選項卡上,單擊“共享這臺打印機”,然后在“共享名”框中鍵入共享打印機的名稱。 如果與硬件或操作系統(tǒng)不同的用戶共享打印機,請單擊“其他驅(qū)動程序”。單擊其他計算機的環(huán)境和操作系統(tǒng),然后單擊“確定”,以安裝其他驅(qū)動程序。 運行 Windows 其他版本(Windows 95、Windows 98 或者 Windows NT 4.0)的用戶可在支持 CD 中找到驅(qū)動程序。但其中沒有 Windows NT 3.1 和 Windows NT 3.5 的打印機驅(qū)動程序。 單擊“確定”。如果已經(jīng)安裝了其他驅(qū)動程序,則單擊“關(guān)閉”。 如果已遵循上述步驟,但仍無法共享打印機,那么請打開 Windows 防火墻。(要打開“Windows 防火墻”,請依次單擊“開始”、“控制面板”,然后雙擊“Windows 防火墻”。) 然后,在“例外”選項卡上,選擇“文件和打印機共享”復(fù)選框。 注意 要打開“打印機和傳真”,請依次單擊“開始”、“控制面板”,然后雙擊“打印機和傳真”。 還可以在“打印機和傳真”中共享打印機,方法是:單擊要共享的打印機,然后單擊左側(cè)窗格“打印機任務(wù)”下面的“共享此打印機”。只有當文件夾設(shè)置為網(wǎng)頁風(fēng)格,并且當前選中打印機時,該選項才可用。詳細信息,請單擊“相關(guān)主題”。 默認情況下,當打印機安裝在 Windows XP Professional 上時打印機沒有共享,但可以選擇將安裝在計算機上的任何打印機共享。 當在 Active Directory 中發(fā)布打印機后,登錄到 Windows 域的其他用戶可以根據(jù)打印機的位置和特性(諸如每分鐘打印多少頁、是否支持彩色打印等)來搜索打印機。
網(wǎng)頁題目:flutter共享,flutter sharesdk
網(wǎng)頁路徑:http://aaarwkj.com/article12/dsiscgc.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供建站公司、面包屑導(dǎo)航、品牌網(wǎng)站建設(shè)、定制網(wǎng)站、ChatGPT、品牌網(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)