開發

跨平臺開發的救星-讓我們來了解一下flutter

廣告
廣告

第一次看文章的朋友可以關注我,會不定期發布Android面試內容、進階專題等等。

簡介

很多人已經用上了flutter,今天就來介紹一下

Flutter 架構

Flutter框架分三層 
Framework,Engine, Embedder

Framework使用dart語言實現,包括UI,文本,圖片,按鈕等Widgets,渲染,動畫,手勢等。此部分的核心代碼是flutter倉庫下的flutter package,以及sky_engine倉庫下的 io, async, ui(dart:ui庫提供了Flutter框架和引擎之間的接口)等package。

Engine使用C++實現,主要包括:Skia, Dart 和 Text。

  • Skia是開源的二維圖形庫,提供了適用于多種軟硬件平臺的通用API。其已作為Google Chrome,Chrome OS,Android, Mozilla Firefox, Firefox OS等其他眾多產品的圖形引擎,支持平臺還包括Windows, macOS, iOS,Android,Ubuntu等。
  • Dart 部分主要包括:Dart Runtime,Garbage Collection(GC),如果是Debug模式的話,還包括JIT(Just In Time)支持。Release和Profile模式下,是AOT(Ahead Of Time)編譯成了原生的arm代碼,并不存在JIT部分。
  • Text 即文本渲染,其渲染層次如下:衍生自 Minikin的libtxt庫(用于字體選擇,分隔行);HartBuzz用于字形選擇和成型;Skia作為渲染/GPU后端,在Android和Fuchsia上使用FreeType渲染,在iOS上使用CoreGraphics來渲染字體。

Embedder是一個嵌入層,通過該層把Flutter嵌入到各個平臺上去,Embedder的主要工作包括渲染Surface設置, 線程設置,以及插件等。平臺(如iOS)只是提供一個畫布,剩余的所有渲染相關的邏輯都在Flutter內部,這就使得它具有了很好的跨端一致性。

Dart語言

Dart 也是一種VM語言,所以在每個運行flutter的app中都有一個dart的運行環境。編譯模式支持AOT和JIT。 
Dart最開始是google設計出來替代javascript的,但是并沒有湊效。后面Flutter選擇了Dart, 才使Dart活躍起來。

Dart語言的特點:

  • 單進程異步事件模型
  • 強類型,可以類型推斷
  • 具有極高的運行效率和優秀的代碼運行優化的VM,根據早前的基準測試,性能比肩 Java7 的JVM;
  • 獨特的隔離區( Isolate ),可以實現多線程
  • 面向對象編程,一切數據類型均派生自 Object
  • 運算符重載,泛型支持
  • 強大的 Future 和 Stream 模型,可以簡單實現高效的代碼
  • Minix 特性,可以更好的實現方法復用
  • 全平臺語言,可以很好的勝任移動和前后端的開發
  • 在語法上,Dart 提供了很多便捷的操作

Flutter線程管理

Flutter Engine自己不創建, 管理線程。Flutter Engine線程的創建和管理是由embedder負責的

Embeder提供四個Task Runner, 每個Task Runner負責不同的任務,Flutter Engine不在乎Task Runner具體跑在哪個線程,但是它需要線程配置在整一個生命周期里面保持穩定。也就是說一個Runner最好始終保持在同一線程運行

Platform Task Runner

是Flutter Engine的主Task Runner,運行Platform Task Runner的線程可以理解為是主線程。類似于Android Main Thread或者iOS的Main Thread。對于Flutter Engine來說Platform Runner所在的線程跟其它線程并沒有實質上的區別。 可以同時啟動多個Engine實例,每個Engine對應一個Platform Runner,每個Runner跑在各自的線程里。這也是Fuchsia(Google正在開發的操作引擎)里Content Handler的工作原理。一般情況下,一個Flutter應用啟動的時候會創建一個Engine實例,Engine創建的時候會創建一個線程供Platform Runner使用。

跟Flutter Engine的所有交互(接口調用)必須發生在Platform Thread,試圖在其它線程中調用Flutter Engine會導致無法預期的異常。這跟Android和IOS對于UI的操作都必須在主線程進行相類似。需要注意的是在Flutter Engine中有很多模塊都是非線程安全的。一旦引擎正常啟動運行起來,所有引擎API調用都將在Platform Thread里發生。

Platform Runner所在的Thread不僅僅處理與Engine交互,它還處理來自平臺的消息。這樣的處理比較方便的,因為幾乎所有引擎的調用都只有在Platform Thread進行才能是安全的,Native Plugins不必要做額外的線程操作就可以保證操作能夠在Platform Thread進行。如果Plugin自己啟動了額外的線程,那么它需要負責將返回結果派發回Platform Thread以便Dart能夠安全地處理。規則很簡單,對于Flutter Engine的接口調用都需保證在Platform Thread進行。

阻塞Platform Thread不會直接導致Flutter應用的卡頓(跟iOS android主線程不同)。盡管如此,平臺對Platform Thread還是有強制執行限制。所以建議復雜計算邏輯操作不要放在Platform Thread而是放在其它線程(不包括我們現在討論的這個四個線程)。其他線程處理完畢后將結果轉發回Platform Thread。長時間卡住Platform Thread應用有可能會被系統Watchdot強行殺死。

UI Task Runner

Flutter Engine用于執行Dart root isolate代碼。Root isolate比較特殊,它綁定了不少Flutter需要的函數方法。Root isolate運行應用的main code。引擎啟動的時候為其增加了必要的綁定,使其具備調度提交渲染幀的能力。

  1. 對于每一幀,引擎要做的事情有:
  2. Root isolate通知Flutter Engine有幀需要渲染。
  3. Flutter Engine通知平臺,需要在下一個vsync的時候得到通知。
  4. 平臺等待下一個vsync
  5. 對創建的對象和Widgets進行Layout并生成一個Layer Tree,Layer Tree馬上被提交給Flutter Engine。當前階段沒有進行任何光柵化,這個步驟僅是生成了對需要繪制內容的描述。
  6. 創建或者更新Tree,這個Tree包含了用于屏幕上顯示Widgets的語義信息。這個東西主要用于平臺相關的輔助Accessibility元素的配置和渲染。

除了渲染相關邏輯之外Root Isolate還是處理來自Native Plugins的消息響應,Timers,MicroTasks和異步IO。 
Root Isolate負責創建管理的Layer Tree最終決定什么內容要繪制到屏幕上。因此這個線程的過載會直接導致卡頓掉幀。 
如果確實有無法避免的繁重計算,建議將其放到獨立的Isolate去執行,比如使用compute關鍵字或者放到非Root Isolate,這樣可以避免應用UI卡頓。但是需要注意的是非Root Isolate缺少Flutter引擎需要的一些函數綁定,你無法在這個Isolate直接與Flutter Engine交互。所以只在需要大量計算的時候采用獨立Isolate。

GPU Task Runner

用于執行設備GPU的相關調用。UI Task Runner創建的Layer Tree信息是平臺不相關,也就是說Layer Tree提供了繪制所需要的信息,具體如何實現繪制取決于具體平臺和方式,可以是OpenGL,Vulkan,軟件繪制或者其他Skia配置的繪圖實現。GPU Task Runner中的模塊負責將Layer Tree提供的信息轉化為實際的GPU指令。GPU Task Runner同時也負責配置管理每一幀繪制所需要的GPU資源,這包括平臺Framebuffer的創建,Surface生命周期管理,保證Texture和Buffers在繪制的時候是可用的。

基于Layer Tree的處理時長和GPU幀顯示到屏幕的耗時,GPU Task Runner可能會延遲下一幀在UI Task Runner的調度。一般來說UI Runner和GPU Runner跑在不同的線程。存在這種可能,UI Runner在已經準備好了下一幀的情況下,GPU Runner卻還正在向GPU提交上一幀。這種延遲調度機制確保不讓UI Runner分配過多的任務給GPU Runner。

GPU Runner可以導致UI Runner的幀調度的延遲,GPU Runner的過載會導致Flutter應用的卡頓。一般來說用戶沒有機會向GPU Runner直接提交任務,因為平臺和Dart代碼都無法跑進GPU Runner。但是Embeder還是可以向GPU Runner提交任務的。因此建議為每一個Engine實例都新建一個專用的GPU Runner線程。

IO Task Runner

主要功能是從圖片存儲(比如磁盤)中讀取壓縮的圖片格式,將圖片數據進行處理為GPU Runner的渲染做好準備。在Texture的準備過程中,IO Runner首先要讀取壓縮的圖片二進制數據(比如PNG,JPEG),將其解壓轉換成GPU能夠處理的格式然后將數據上傳到GPU。這些復雜操作如果跑在GPU線程的話會導致Flutter應用UI卡頓。但是只有GPU Runner能夠訪問GPU,所以IO Runner模塊在引擎啟動的時候配置了一個特殊的Context,這個Context跟GPU Runner使用的Context在同一個ShareGroup。事實上圖片數據的讀取和解壓是可以放到一個線程池里面去做的,但是這個Context的訪問只能在特定線程才能保證安全。這也是為什么需要有一個專門的Runner來處理IO任務的原因。獲取諸如ui.Image這樣的資源只有通過async call,當這個調用發生的時候Flutter Framework告訴IO Runner進行剛剛提到的那些圖片異步操作。這樣GPU Runner可以使用IO Runner準備好的圖片數據而不用進行額外的操作。

用戶操作,無論是Dart Code還是Native Plugins都是沒有辦法直接訪問IO Runner。盡管Embeder可以將一些一般復雜任務調度到IO Runner,這不會直接導致Flutter應用卡頓,但是可能會導致圖片和其它一些資源加載的延遲間接影響性能。所以建議為IO Runner創建一個專用的線程

android & iOS平臺上面每一個Engine實例啟動的時候會為UI,GPU,IO Runner各自創建一個新的線程。所有Engine實例共享同一個Platform Runner線程

isolate

An isolated Dart execution context

isolate是Dart對actor并發模式的實現。運行中的Dart程序由一個或多個actor組成,actor也就是Dart概念里面的isolate。isolate是隔離的,每個isolate有自己的內存和單線程運行的實體. isolate之間不互相共享內存,且獨立GC。 
isolate中的代碼是順序執行的,且是單線程,所以不存在資源競爭和變量狀態同步的問題,也就不需要鎖。Dart中的并發都是多個isolate并行實現的

由于isolate不共享內存,所以isolate之間不能直接互相通信,只能通過Port進行通信,而且是異步的

Flutter Engine Runners與Dart Isolate

Dart的Isolate是Dart虛擬機自己管理的,Flutter Engine無法直接訪問。Root Isolate通過Dart的C++調用能力把UI渲染相關的任務提交到UI Runner執行, 這樣就可以跟Flutter Engine相關模塊進行交互,Flutter UI相關的任務也被提交到UI Runner也可以相應的給Isolate一些事件通知,UI Runner同時也處理來自App方面Native Plugin的任務。 Dart isolate跟Flutter Runner是相互獨立的,它們通過任務調度機制相互協作。

Dart內存管理

Dart VM將內存管理分為新生代(New Generation)和老年代(Old Generation)

  • 新生代:初次分配的對象都位于新生代中,該區域主要是存放內存較小并且生命周期較短的對象,比如局部變量。新生代會頻繁執行內存回收(GC),回收采用“復制-清除”算法,將內存分為兩塊,運行時每次只使用其中的一塊,另一塊備用。當發生GC時,將當前使用的內存塊中存活的對象拷貝到備用內存塊中,然后清除當前使用內存塊,最后,交換兩塊內存的角色。
  • 老年代: 在新生代的GC中“幸存”下來的對象,它們會被轉移到老年代中。老年代存放生命力周期較長,內存較大的對象。老年代的GC回收采用“標記-清除”算法,分成標記和清除兩個階段。在標記階段會觸發停頓,多線程并發的完成對垃圾對象的標記,降低標記階段耗時。在清理階段,由GC線程負責清理回收對象,和應用線程同時執行,不影響應用運行。

Flutter中的image所占的內存

Android將中內存分java內存或native內存,通常在代碼中的申請的內存都在這兩個范圍內

java內存是指java或kotlin分配的內存對象 
native內存是指由C/C++中分配的內存,也包括一些android原生系統占用的內存,如圖像資源和其他圖形等

Flutter中的image占用的不用這兩種內存,而是Graphics內存,Graphics內存內存是指圖形緩沖區隊列向屏幕顯示像素所使用的內存,圖形緩沖區是指GL表面,GL紋理等。Graphics內存是與CPU共享的內存,而不是GPU專用的內存

Flutter運行模式

Flutter常見的種運行模式:Debug,Release和Profile

Release和Profile模式比較類似,不用之處在于Profile模式的服務擴展的支持,支持跟蹤,以及最小化使用跟蹤信息需要的依賴。Profile并不支持模擬器,原因在于模擬器上的診斷并不代表真實的性能。所有重點截介紹 
Debug和Release的差異

  • Debug模式:使用JIT編譯,支持模擬器和設備。打開了斷言支持,包括所有的調試信息,服務擴展和Observatory等調試輔助。此模式為快速開發和運行做了優化,但并未對執行速度,包大小和部署做優化。 
    所以能實現秒級別的hot reload
  • Release模式:使用AOT編譯,只支持真機,不支持模擬器。關閉了所有斷言,盡可能多地去掉了調試信息,關閉了所有調試工具。為快速啟動,快速執行,包大小做了優化。禁止了所有調試輔助手段,服務擴展。

Flutter Platform Channel

Platform Channel用來實現flutter和Native之間的通訊,實現方式類似遠程通訊。

Flutter定義了三種Channel:

  • BasicMessageChannel:用于傳遞字符串和半結構化的信息
  • MethodChannel:用于傳遞方法調用(method invocation)
  • EventChannel: 用于數據流(event streams)的通信

這三種channel的工作原理都一致,都用三個基本的屬性:

  • name: String類型,代表Channel的名字,也是其唯一標識符
  • Messager:BinaryMessenger類型,代表消息信使,是消息的發送與接收的工具
  • codec: MessageCodec類型或MethodCodec類型,代表消息的編解碼器

BinaryMessenger是Native端與Flutter端通信的工具,其通信使用的消息格式為二進制格式數據。初始化一個Channel,并向該Channel注冊處理消息的Handler時,實際上會生成一個與之對應的BinaryMessageHandler,并以channel name為key,注冊到BinaryMessenger中。當Flutter端發送消息到BinaryMessenger時,BinaryMessenger會根據其入參channel找到對應的BinaryMessageHandler,并交由其處理。

BinaryMessenger只和BinaryMessageHandler通訊。而Channel和BinaryMessageHandler則是一一對應的。由于Channel從BinaryMessageHandler接收到的消息是二進制格式數據,無法直接使用,故Channel會將該二進制消息通過Codec(消息編解碼器)解碼為能識別的消息并傳遞給Handler進行處理。

當Handler處理完消息之后,會通過回調函數返回result,并將result通過編解碼器編碼為二進制格式數據,通過BinaryMessenger發送回Flutter端。

Codec:息編解碼器,主要用來將二進制格式的數據轉化為Handler能夠識別的數據,Flutter定義了兩種Codec:MessageCodec和MethodCodec

MessageCodec用于二進制格式數據與基礎數據之間的編碼和解碼。有多重實現如:BinaryCodec, StringCodec, JSONMessageCodec等

MethodCodec用于二進制數據與方法調用(MethodCall)和返回結果之間的編解碼。MethodChannel和EventChannel所使用的編解碼器均為MethodCodec。

MethodCodec用于MethodCall對象的編解碼,一個MethodCall對象代表一次從Flutter端發起的方法調用。MethodCall有2個成員變量:String類型的method代表需要調用的方法名稱,通用類型(Android中為Object,iOS中為id)的arguments代表需要調用的方法入參。

由于處理的是方法調用,MethodCodec多了對調用結果的處理。當方法調用成功時,使用encodeSuccessEnvelope將result編碼為二進制數據,而當方法調用失敗時,則使用encodeErrorEnvelope將error的code、message、detail編碼為二進制數據。

MethodCodec有兩種實現:JSONMethodCodec和StandardMethodCodec

由于Platform Channel運行在flutter App的UI Task Runner, 對應的native實現運行在Platform Task Runner,而Platform Task Runner運行在主線程,所以在native實現是不能進行耗時的操作,且Platform Task Runner是非線程安全的,所以要保證回調函數在主線程中執行

Platform Channel支持大數據傳遞,傳遞大內存數據塊時,使用BasicMessageChannel以及BinaryCodec。而整個數據傳遞的過程中,唯一可能出現數據拷貝的位置為native二進制數據轉化為Dart語言二進制數據。若二進制數據大于閾值時(目前閾值為1000byte)則不會拷貝數據,直接轉化,否則拷貝一份再轉化。

學習

看到這里,你了解了嗎?點個贊支持一下 
想要學習的朋友可以詳細了解哦

我還沒有學會寫個人說明!

走進希捷無錫工廠 感受智能制造的魅力

上一篇

如何解決云中容器數據存儲的移動性挑戰?

下一篇

你也可能喜歡

跨平臺開發的救星-讓我們來了解一下flutter

長按儲存圖像,分享給朋友

ITPUB 每周精要將以郵件的形式發放至您的郵箱


微信掃一掃

微信掃一掃
双色球常规走势图 七位数近30期开奖结果 山东11选5组选走 河南11选5开奖查询结果 河北十一选五结果 球探比分直播网 福建36选7开奖号码 大赢家比分即时足球比分直播 天津十一选五开奖结果手机板 快乐双彩今天开奖号码 辽宁11选5加奖 nba比赛比分预测 快乐飞艇是不是骗局