技術乾貨 | Flutter在線編程實踐總結

作者 / 郭凱旋

編輯 / 李軼楠（實習）

Flutter的架構主要分成三層:Framework，Engine，Embedder。

圖1

對於開發者來説，使用最多的還是framework，我就從Flutter的入口函數開始一步步往下走，分析一下Flutter視圖繪製的原理。

在Flutter應用中，main()函數最簡單的實現如下:

void main() {  runApp(MyApp()); }

runApp方法調用了WidgetsFlutterBinding類ensureInitialized、attachRootWidget(app)、scheduleWarmUpFrame()三個方法，代碼如下

WidgetsFlutterBinding繼承自BindingBase 並混入了很多Binding，查看這些 Binding的源碼可以發現這些Binding中基本都是監聽並處理Window對象（包含了當前設備和系統的一些信息以及Flutter Engine的一些回調）的一些事件，然後將這些事件按照Framework的模型包裝、抽象然後分發。

WidgetsFlutterBinding正是粘連Flutter engine與上層Framework的“膠水”。

WidgetsFlutterBinding.ensureInitialized()負責初始化一個WidgetsBinding的全局單例，代碼如下:

看到這個混入(with)很多的，下面先看父類:BindingBase

看到有句代碼Window get window => ui.window鏈接宿主操作系統的接口，也就是Flutter framework 鏈接宿主操作系統的接口。系統中有一個Window實例，可以從window屬性來獲取，看看源碼：

scheduleAttachRootWidget緊接着會調用WidgetsBinding的attachRootWidget方法，該方法負責將根Widget添加到RenderView上，代碼如下：

renderView變量是一個RenderObject，它是渲染樹的根。renderViewElement變量是renderView對應的Element對象。可見該方法主要完成了根widget到根 RenderObject再到根Element的整個關聯過程。

RenderView get renderView => _pipelineOwner.rootNode! as RenderView;

renderView是RendererBinding中拿到PipelineOwner.rootNode，PipelineOwner在 Rendering Pipeline 中起到重要作用：

隨着 UI 的變化而不斷收集『 Dirty Render Objects 』隨之驅動 Rendering Pipeline 刷新 UI。

簡單講，PipelineOwner是『RenderObject Tree』與『RendererBinding』間的橋樑。

最終調用attachRootWidget，執行會調用RenderObjectToWidgetAdapter的attachToRenderTree方法，該方法負責創建根element，即RenderObjectToWidgetElement，並且將element與widget 進行關聯，即創建出 widget樹對應的element樹。如果element 已經創建過了，則將根element 中關聯的widget 設為新的，由此可以看出element 只會創建一次，後面會進行復用。BuildOwner是widget framework的管理類，它跟蹤哪些widget需要重新構建。代碼如下：

runApp的實現中，當調用完attachRootWidget後，最後一行會調用 WidgetsFlutterBinding 實例的 scheduleWarmUpFrame() 方法，該方法的實現在SchedulerBinding 中，它被調用後會立即進行一次繪製（而不是等待"vsync" 信號），在此次繪製結束前，該方法會鎖定事件分發，也就是説在本次繪製結束完成之前Flutter將不會響應各種事件，這可以保證在繪製過程中不會再觸發新的重繪。

下面是scheduleWarmUpFrame() 方法的部分實現(省略了無關代碼)：

void scheduleWarmUpFrame() {  ...  Timer.run(() {    handleBeginFrame(null);   });  Timer.run(() {    handleDrawFrame();      resetEpoch();  });  // 鎖定事件  lockEvents(() async {    await endOfFrame;    Timeline.finishSync();  }); ...}

該方法中主要調用了handleBeginFrame() 和 handleDrawFrame() 兩個方法。

查看handleBeginFrame() 和 handleDrawFrame() 兩個方法的源碼，可以發現前者主要是執行了transientCallbacks隊列，而後者執行了 persistentCallbacks 和 postFrameCallbacks 隊列。

真正的渲染和繪製邏輯在RendererBinding中實現，查看其源碼，發現在其initInstances()方法中有如下代碼：

我們再來看WidgetsBinding，在initInstances()方法中創建BuildOwner對象，然後執行buildOwner!.onBuildScheduled = _handleBuildScheduled;，這裏將_handleBuildScheduled賦值給了buildOwnder的onBuildScheduled屬性。

BuildOwner對象，它負責跟蹤哪些widgets需要重新構建，並處理應用於widgets樹的其他任務，其內部維護了一個_dirtyElements列表，用以保存被標“髒”的elements。

每一個element被新建時，其BuildOwner就被確定了。一個頁面只有一個buildOwner對象，負責管理該頁面所有的element。

當調用buildOwner.onBuildScheduled()時，便會走下面的流程。

當schedulerPhase處於idle狀態，會調用scheduleFrame，然後經過window.scheduleFrame()中的performDispatcher.scheduleFrame()去註冊一個VSync監聽。

Flutter從啟動到顯示圖像在屏幕主要經過：首先監聽處理window對象的事件，將這些事件處理包裝為Framework模型進行分發，通過widget創建element樹，接着通過scheduleWarmUpFrame進行渲染，接着通過Rendererbinding進行佈局，繪製，最後通過調用ui.window.render(scene)Scene信息發給Flutter engine，Flutter engine最後調用渲染API把圖像畫在屏幕上。

我大致整理了一下Flutter視圖繪製的時序圖，如下

圖 2

在對視圖繪製有一定的瞭解後後，思考一個問題，怎麼在視圖繪製的過程中去把控性能，優化性能，我們先來看一下Flutter官方提供給我們的兩個性能監控工具。

1.observatory

observatory: 在engine/shell/testings/observatory可以找到它的具體實現,它開啟了一個ServiceClient,用於獲取dartvm運行狀態.flutter app啟動的時候會生成一個當前的observatory服務器的地址

圖 3

比方説選擇了timeline後，可以進行性能分析，如圖

圖 4

2.devTools

圖 5

打開後的頁面

圖 6

devtools中的timeline就是performance，我們選擇之後頁面如下，操作體驗上好了很多

圖 7

observatory與devtools都是通過vm_service實現的，網上使用指南比較多，這邊就不多贅述了，我這邊主要介紹一下Dart VM Service （後面 簡稱 ）vm_service，是 Dart 虛擬機內部提供的一套 Web 服務，數據傳輸協議是 JSON-RPC 2.0。

不過我們並不需要要自己去實現數據請求解析，官方已經寫好了一個可用的 Dart SDK 給我們用：vm_service。vm_service 在啟動的時候會在本地開啟一個 WebSocket 服務，服務 URI 可以在對應的平台中獲得：

 1）Android 在 FlutterJNI.getObservatoryUri() 中；

 2）iOS 在 FlutterEngine.observatoryUrl 中。

有了 URI 之後我們就可以使用  的服務了，官方有一個幫我們寫好的SDK: vm_service

獲取frameworkVersion，調用一個VmService實例的callExtensionService，傳入'flutterVersion'，就能拿到當前的flutter framework和engine信息

圖 8

獲取內存信息，調用一個VmService實例的getMemoryUsage，就能拿到當前的內存信息

圖 9

獲取 Flutter APP 的 FPS，官方提供了好幾個辦法來讓我們在開發 Flutter app 的過程中可以使用查看 fps等性能數據，如devtools，具體見文檔 Debugging Flutter apps 、Flutter performance profiling 等。

flutter 的崩潰日誌收集主要有兩個方面：

1）flutter dart 代碼的異常（包含app和framework代碼兩種情況，一般不會引起閃退，你猜為什麼）

2）flutter engine 的崩潰日誌（一般會閃退）

1.Flutter framework 異常捕獲

註冊 FlutterError.onError 回調，用於收集 Flutter framework 外拋的異常。

2.Flutter engine 異常捕獲

flutter engine 部分的異常，以Android 為例，主要為 libfutter.so發生的錯誤。

這部份可以直接交給native崩潰收集sdk來處理，比如 firebase crashlytics、 bugly、xCrash 等等 

我們需要將 dart 異常及堆棧通過 MethodChannel傳遞給 bugly sdk 即可。 

收集到異常之後，需要查符號表(symbols)還原堆棧。

首先需要確認該 flutter engine 所屬版本號，在命令行執行：

flutter --version

輸出如下：

可以看到 Engine 的 revision 為 241c87ad80。

其次，在 flutter infra 上找到對應cpu abi 的 symbols.zip 並下載,解壓後，可以得到帶有符號信息的 debug so 文件—— libflutter.so，然後按照平台文檔上傳進行堆棧還原就可以了，如bugly平台就提供了上傳工具

java -jar buglySymbolAndroid.jar -i  xxx

在業務開發中我們要學會用devtools來檢測工程性能，這樣有助於我們實現健壯性更強的應用，在排查過程中，我發現視頻詳情頁存在渲染耗時的問題，如圖

圖 10

VideoControls控件的build耗時是28.6ms，如圖

圖 11

所以這裏我們的優化方案是提高build效率，降低Widget tree遍歷的出發點，將setState刷新數據儘量下發到底層節點，所以將VideoControl內觸發刷新的子組件抽取成獨立的Widget，setState下發到抽取出的Widget內部

優化後為11.0ms,整體的平均幀率也達到了了60fps，如圖

圖 12

接下來分析下paint過程有沒有可以優化的部分，我們打開debugProfilePaintsEnabled變量分析可以看到Timeline顯示的paint層級，如圖

圖 13

我們發現頻繁更新的_buildPositionTitle和其他Widget在同一個layer中，這裏我們想到的優化點是利用RepaintBoundary提高paint效率，它為經常發生顯示變化的內容提供一個新的隔離layer，新的layer paint不會影響到其他layer

看下優化後的效果，如圖

圖 14

這篇文章主要從三個維度來介紹Flutter這門技術，分別為：

1.繪製原理講解，我們review了一下源碼，發現整個渲染過程就是一個閉環，Framework，Engine，Embedder各司其職，簡單來説就是Embedder不斷拿回Vsync信號，Framework將dart代碼交給Engine翻譯成跨平台代碼，再通過Embedder回調宿主平台；

2.性能監控就是不斷得在這個循環中去插入我們的哨兵，觀察整個生態，獲取異常數據上報；

3.性能優化通過一次項目實踐，學習怎麼用工具提升我們定位問題的效率。

優點：

我們可以看到Flutter在視圖繪製過程中形成了閉環，雙端基本保持了一致性，所以我們的開發效率得到了極大的提升，性能監控和性能優化也比較方便。

缺點： 

1）聲明式開發 動態操作視圖節點不是很友好，不能像原生那樣命令式編程，或者像前端獲取dom節點那般容易；

2）實現動態化機制，目前沒有比較好的開源技術可以去借鑑。

- END -