深入理解flutter的編譯原理與優化

正物發表於2018-08-01
Flutter編譯原理優化

問題背景

對於開發者而言，什麼是Flutter？它是用什麼語言編寫的，包含哪幾部分，是如何被編譯，執行到裝置上的呢？Flutter如何做到Debug模式Hot Reload快速生效變更，Release模式原生體驗的呢？Flutter工程和我們的Android/iOS工程有何差別，關係如何，又是如何嵌入Android/iOS的呢？Flutter的渲染和事件傳遞機制如何工作？Flutter支援熱更新嗎？Flutter官方並未提供iOS下的armv7支援，確實如此嗎？在使用Flutter的時候，如果發現了engine的bug，如何去修改和生效？構建緩慢或出錯又如何去定位，修改和生效呢？

凡此種種，都需要對Flutter從設計，開發構建，到最終執行有一個全域性視角的觀察。

本文將以一個簡單的hello_flutter為例，介紹下Flutter相關原理及定製與優化。

Flutter簡介

FlutterArchitecture

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

Framework使用dart實現，包括Material Design風格的Widget,Cupertino(針對iOS)風格的Widgets，文字/圖片/按鈕等基礎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等其他眾多產品的圖形引擎，支援平臺還包括Windows7+,macOS 10.10.5+,iOS8+,Android4.1+,Ubuntu14.04+等。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來渲染字型。

Dart Mode

Embedder是一個嵌入層，即把Flutter嵌入到各個平臺上去，這裡做的主要工作包括渲染Surface設定,執行緒設定，以及外掛等。從這裡可以看出，Flutter的平臺相關層很低，平臺(如iOS)只是提供一個畫布，剩餘的所有渲染相關的邏輯都在Flutter內部，這就使得它具有了很好的跨端一致性。

Flutter工程結構

本文使用開發環境為flutter beta v0.3.1，對應的engine commit:09d05a389。

以hello_flutter工程為例，Flutter工程結構如下所示:

Flutter File Structure

其中ios為iOS部分程式碼，使用CocoaPods管理依賴，android為Android部分程式碼，使用Gradle管理依賴，lib為dart程式碼，使用pub管理依賴。類似iOS中Cocoapods的Podfile和Podfile.lock，pub下對應的是pubspec.yaml和pubspec.lock。

Flutter模式

對於Flutter，它支援常見的debug,release,profile等模式，但它又有其不一樣。

Debug模式：對應了Dart的JIT模式，又稱檢查模式或者慢速模式。支援裝置，模擬器(iOS/Android)，此模式下開啟了斷言，包括所有的除錯資訊，服務擴充套件和Observatory等除錯輔助。此模式為快速開發和執行做了優化，但並未對執行速度，包大小和部署做優化。Debug模式下，編譯使用JIT技術，支援廣受歡迎的亞秒級有狀態的hot reload。

Release模式：對應了Dart的AOT模式，此模式目標即為部署到終端使用者。只支援真機，不包括模擬器。關閉了所有斷言，儘可能多地去掉了除錯資訊，關閉了所有除錯工具。為快速啟動，快速執行，包大小做了優化。禁止了所有除錯輔助手段，服務擴充套件。

Profile模式：類似Release模式，只是多了對於Profile模式的服務擴充套件的支援，支援跟蹤，以及最小化使用跟蹤資訊需要的依賴，例如，observatory可以連線上程式。Profile並不支援模擬器的原因在於，模擬器上的診斷並不代表真實的效能。

鑑於Profile同Release在編譯原理等上無差異，本文只討論Debug和Release模式。

事實上flutter下的iOS/Android工程本質上依然是一個標準的iOS/Android的工程，flutter只是通過在BuildPhase中新增shell來生成和嵌入App.framework和Flutter.framework(iOS),通過gradle來新增flutter.jar和vm/isolate_snapshot_data/instr(Android)來將Flutter相關程式碼編譯和嵌入原生App而已。因此本文主要討論因flutter引入的構建，執行等原理。編譯target雖然包括arm,x64,x86,arm64，但因原理類似，本文只討論arm相關(如無特殊說明，android預設為armv7)。

Flutter程式碼的編譯與執行(iOS)

Release模式下的編譯

Release模式下，flutter下iOS工程dart程式碼構建鏈路如下所示:

iOS compile and embed

其中gen_snapshot是dart編譯器，採用了tree shaking(類似依賴樹邏輯，可生成最小包，也因而在Flutter中禁止了dart支援的反射特性)等技術，負責生成彙編形式機器程式碼。再通過xcrun等工具鏈生成最終的App.framework。所有的dart程式碼，包括業務程式碼，三方package程式碼，它們所依賴的flutter框架程式碼，最終將會編譯成App.framework。

PS.tree shaking功能位於gen_snapshot中，對應邏輯參見: engine/src/third_party/dart/runtime/vm/compiler/aot/precompiler.cc

dart程式碼最終對應到App.framework中的符號如下所示:

dart code to symbol in App.framework

事實上，類似Android Release下的產物(見下文)，App.framework也包含了kDartVmSnapshotData，kDartVmSnapshotInstructions，kDartIsolateSnapshotData，kDartIsolateSnapshotInstructions四個部分。為什麼iOS使用App.framework這種方式，而不是Android的四個檔案的方式呢？原因在於在iOS下，因為系統的限制，Flutter引擎不能夠在執行時將某記憶體頁標記為可執行，而Android是可以的。

Flutter.framework對應了Flutter架構中的engine部分，以及Embedder。實際中Flutter.framework位於flutter倉庫的/bin/cache/artifacts/engine/ios*下，預設從google倉庫拉取。當需要自定義修改的時候，可通過下載engine原始碼，利用Ninja構建系統來生成。

Flutter相關程式碼的最終產物是:App.framework(dart程式碼生成)和Flutter.framework(引擎)。從Xcode工程的視角看，Generated.xcconfig描述了Flutter相關環境的配置資訊，然後Runner工程設定中的Build Phases新增的xcode_backend.sh實現了Flutter.framework的拷貝(從Flutter倉庫的引擎到Runner工程根目錄下的Flutter目錄)與嵌入，App.framework的編譯與嵌入。最終生成的Runner.app中Flutter相關內容如下所示:

Flutter in Runner Release

其中flutter_assets是相關的資源，程式碼則是位於Frameworks下的App.framework和Flutter.framework。

Release模式下的執行

Flutter相關的渲染，事件，通訊處理邏輯如下所示:

Render and event logic

其中dart中的main函式呼叫棧如下:

main in dart callstack

Debug模式下的編譯

Debug模式下flutter的編譯，結構類似Release模式，差異主要表現為兩點:

1.Flutter.framework

因為是Debug，此模式下Framework中是有JIT支援的，而在Release模式下並沒有JIT部分。

2.App.framework

不同於AOT模式下的App.framework是Dart程式碼對應的機器程式碼，JIT模式下，App.framework只有幾個簡單的API，其Dart程式碼存在於snapshot_blob.bin檔案裡。這部分的snapshot是指令碼快照，裡面是簡單的標記化的原始碼。所有的註釋，空白字元都被移除，常量也被規範化，沒有機器碼，tree shaking或混淆。

App.framework中的符號表如下所示:

App in debug symbols

對Runner.app/flutter_assets/snapshot_blob.bin執行strings命令可以看到如下內容:

snapshot bin strings

Debug模式下main入口的呼叫堆疊如下:

debug isolate main callstack

Flutter程式碼的編譯與執行(Android)

鑑於Android和iOS除了部分平臺相關的特性外，其他邏輯如Release對應AOT，Debug對應JIT等均類似，此處只涉及兩者不同。

Release模式下的編譯

release模式下，flutter下Android工程中dart程式碼整個構建鏈路如下所示:

android release build flow

其中vm/isolate_snapshot_data/instr內容均為arm指令，其中vm_中涉及runtime等服務(如gc)，用於初始化DartVM，呼叫入口見Dart_Initialize(dart_api.h)。isolate__則對應了我們的應用dart程式碼，用於建立一個新的isolate,呼叫入口見Dart_CreateIsolate(dart_api.h)。flutter.jar類似iOS的Flutter.framework，包括了Engine部分(Flutter.jar中的libflutter.so)，和Embedder部分(FlutterMain,FlutterView,FlutterNativeView等)。實際中flutter.jar位於flutter倉庫的/bin/cache/artifacts/engine/android*下，預設從google倉庫拉取。需要自定義修改的時候，可通過下載engine原始碼，利用Ninja構建系統來生成flutter.jar。

以isolate_snapshot_data/instr為例，執行disarm命令結果如下:

isolate snapshot data disarm

isolate snapshot instr disarm)

其Apk結構如下所示:

Flutter android release apk structure

APK新安裝之後，會根據一個判斷邏輯(packageinfo中的versionCode結合lastUpdateTime)來決定是否拷貝APK中的assets，拷貝後內容如下所示:

app flutter

isolate/vm_snapshot_data/instr均最後位於app的本地data目錄下，而此部分又屬於可寫內容，可通過下載並替換的方式，完成App的動態更新。

Release模式下的執行

Render&Event in release mode

Debug模式下的編譯

類似iOS的Debug/Release的差別，Android的Debug與Release的差異主要包括以下兩部分:

1.flutter.jar

區別同iOS

2.App程式碼部分

位於flutter_assets下的snapshot_blob.bin，同iOS。

在介紹了iOS/Android下的Flutter編譯原理後，下面介紹下如何定製flutter/engine以完成定製和優化。鑑於Flutter處於敏捷的迭代中，現有的問題後續不一定是問題，因而此部分並不是要解決多少問題，而是說明不同問題下的解決思路。

Flutter構建相關的定製與優化

Flutter是一個很複雜的系統，除了上述提到的三層架構中的內容外，還包括Flutter Android Studio(Intellij)外掛，pub倉庫管理等。但我們的定製和優化往往是flutter的工具鏈相關邏輯，其邏輯位於flutter倉庫的flutter_tools包。下面舉例說明下如何針對此部分做定製。

Android部分

相關內容包括flutter.jar，libflutter.so(位於flutter.jar下)，gen_snapshot，flutter.gradle，flutter(flutter_tools)。

1.限定Android中target為armeabi

此部分屬於構建相關，邏輯位於flutter.gradle下。當App是通過armeabi支援armv7/arm64的時候，需要修改flutter的預設邏輯。如下所示:

android support armeabi only

因為gradle本身的特點，此部分修改後直接構建即可生效。

2.設定Android啟動時預設使用第一個launchable-activity

此部分屬於flutter_tools相關，修改如下:

android launchable activity

這裡的重點不是如何去修改，而是如何去讓修改生效。原理上，flutter run/build/analyze/test/upgrade等命令實際上執行的都是flutter(flutter/bin/flutter)這一指令碼，再透過dart執行flutter_tools.snapshot(通過packages/flutter_tools生成)，邏輯如下:

if [[ ! -f "SNAPSHOT_PATH" ]] || [[ ! -s "STAMP_PATH" ]] || [[ "(cat "STAMP_PATH")" != "revision" ]] || [[ "FLUTTER_TOOLS_DIR/pubspec.yaml" -nt "$FLUTTER_TOOLS_DIR/pubspec.lock" ]]; then
        rm -f "$FLUTTER_ROOT/version"
        touch "$FLUTTER_ROOT/bin/cache/.dartignore"
        "$FLUTTER_ROOT/bin/internal/update_dart_sdk.sh"
        echo Building flutter tool...
    if [[ "$TRAVIS" == "true" ]] || [[ "$BOT" == "true" ]] || [[ "$CONTINUOUS_INTEGRATION" == "true" ]] || [[ "$CHROME_HEADLESS" == "1" ]] || [[ "$APPVEYOR" == "true" ]] || [[ "$CI" == "true" ]]; then
      PUB_ENVIRONMENT="$PUB_ENVIRONMENT:flutter_bot"
    fi
    export PUB_ENVIRONMENT="$PUB_ENVIRONMENT:flutter_install"
    
    if [[ -d "$FLUTTER_ROOT/.pub-cache" ]]; then
      export PUB_CACHE="${PUB_CACHE:-"$FLUTTER_ROOT/.pub-cache"}"
    fi
    
    while : ; do
      cd "$FLUTTER_TOOLS_DIR"
      "$PUB" upgrade --verbosity=error --no-packages-dir && break
      echo Error: Unable to `pub upgrade` flutter tool. Retrying in five seconds...
      sleep 5
    done
    "$DART" --snapshot="$SNAPSHOT_PATH" --packages="$FLUTTER_TOOLS_DIR/.packages" "$SCRIPT_PATH"
    echo "$revision" > "$STAMP_PATH"
    fi

不難看出要重新構建flutter_tools，可以刪除flutter_repo_dir/bin/cache/flutter_tools.stamp(這樣重新生成一次)，或者遮蔽掉if/fi判斷(每一次都會重新生成)。

3.如何在Android工程Debug模式下使用release模式的flutter

研發中如果發現flutter有些卡頓，可能是邏輯的原因，也可能是是Debug模式。此時可以構建release下的apk，也可以將flutter強制修改為release模式如下:

flutter in android always release

iOS部分

相關內容包括:Flutter.framework，gen_snapshot，xcode_backend.sh，flutter(flutter_tools)。

1.優化構建過程中反覆替換Flutter.framework導致的重新編譯

此部分邏輯屬於構建相關，位於xcode_backend.sh中，Flutter為了保證獲取到正確的Flutter.framework,每次都會基於配置(見Generated.xcconfig配置)查詢和替換Flutter.framework，這也導致工程中對此Framework有依賴程式碼的重新編譯，修改如下:

xcode_backend not always replace Flutter

2.如何在iOS工程Debug模式下使用release模式的flutter

​ 將Generated.xcconfig中的FLUTTER_BUILD_MODE修改為release，FLUTTER_FRAMEWORK_DIR修改為release對應的路徑即可。

3.armv7的支援

原始文章請參見:https://github.com/flutter/engine/wiki/iOS-Builds-Supporting-ARMv7

事實上flutter本身是支援iOS下的armv7的，但v0.3.1下並未提供官方支援，需自行修改相關邏輯，具體如下:

a.預設的邏輯可以生成Flutter.framework(arm64)

b.修改flutter以使得flutter_tools可以每次重新構建，修改build_aot.dart和mac.dart，將針對iOS的arm64修改為armv7,修改gen_snapshot為i386架構。

其中i386架構下的gen_snapshot可通過以下命令生成:

./flutter/tools/gn --runtime-mode=release --ios --ios-cpu=arm
ninja -C out/ios_release_arm

這裡有一個隱含邏輯:

構建gen_snapshot的CPU相關預定義巨集(x86_64/i386等)，目標gen_snapshot的arch，最終的App.framework的架構整體上要保持一致。即x86_64->x86_64->arm64或者i386->i386->armv7。

c.在iPhone4S上，會發生因gen_snapshot生成不被支援的SDIV指令而造成EXC_BAD_INSTRUCTION(EXC_ARM_UNDEFINED)錯誤，可通過給gen_snapshot新增引數–no-use-integer-division實現(位於build_aot.dart)。其背後的邏輯(dart編譯arm程式碼邏輯流)如下圖所示:

iPhone 4s crash logic

d.基於a和b生成的Flutter.framework,將其lipo create生成同時支援armv7和arm64的Flutter.framework。

e.修改Flutter.framework下的Info.plist，移除

  <key>UIRequiredDeviceCapabilities</key>
  <array>
    <string>arm64</string>
  </array>

同理，對於App.framework也要作此操作，以免上架後會受到App Thining的影響。

flutter_tools的除錯

如果想了解flutter如何構建debug模式下apk時，具體執行的邏輯如何，可以參考下面的思路:

a.瞭解flutter_tools的命令列引數

Flutter tools print args

b.以dart工程形式開啟packages/flutter_tools，基於獲得的引數修改flutter_tools.dart，設定命令列dart app即可開始除錯。

edit flutter_tools dart and debug it with given args

定製engine與除錯

假設我們在flutter beta v0.3.1的基礎上進行定製與業務開發，為了保證穩定，一定週期內並不升級SDK，而此時，flutter在master上修改了某個v0.3.1上就有的bug，記為fix_bug_commit。如何才能跟蹤和管理這種情形呢？

1.flutter beta v0.3.1指定了其對應的engine commit為:09d05a389，見flutter/bin/internal/engine.version。

2.獲取engine程式碼

3.因為2中拿到的是master程式碼，而我們需要的是特定commit(09d05a389)對應的程式碼庫，因而從此commit拉出新分支:custom_beta_v0.3.1。

4.基於custom_beta_v0.3.1(commit:09d05a389)，執行gclient sync，即可拿到對應flutter beta v0.3.1的所有engine程式碼。

5.使用git cherry-pick fix_bug_commit將master的修改同步到custom_beta_v0.3.1，如果修改有很多對最新修改的依賴，可能會導致編譯失敗。

6.對於iOS相關的修改執行以下程式碼:

./flutter/tools/gn --runtime-mode=debug --ios --ios-cpu=arm
ninja -C out/ios_debug_arm

./flutter/tools/gn --runtime-mode=release --ios --ios-cpu=arm
ninja -C out/ios_release_arm

./flutter/tools/gn --runtime-mode=profile --ios --ios-cpu=arm
ninja -C out/ios_profile_arm

./flutter/tools/gn --runtime-mode=debug --ios --ios-cpu=arm64
ninja -C out/ios_debug

./flutter/tools/gn --runtime-mode=release --ios --ios-cpu=arm64
ninja -C out/ios_release

./flutter/tools/gn --runtime-mode=profile --ios --ios-cpu=arm64
ninja -C out/ios_profile

即可生成針對iOS的arm/arm64&debug/release/profile的產物。可用構建產物替換flutter/bin/cache/artifacts/engine/ios*下的Flutter.framework和gen_snapshot。

如果需要除錯Flutter.framework原始碼，構建的時候命令如下:

./flutter/tools/gn --runtime-mode=debug --unoptimized --ios --ios-cpu=arm64
ninja -C out/ios_debug_unopt

用生成產物替換掉flutter中的Flutter.framework和gen_snapshot，即可除錯engine原始碼。

7.對於Android相關的修改執行以下程式碼:

./flutter/tools/gn --runtime-mode=debug --android --android-cpu=arm
ninja -C out/android_debug

./flutter/tools/gn --runtime-mode=release --android --android-cpu=arm
ninja -C out/android_release

./flutter/tools/gn --runtime-mode=profile --android --android-cpu=arm
ninja -C out/android_profile

即可生成針對Android的arm&debug/release/profile的產物。可用構建產物替換flutter/bin/cache/artifacts/engine/android*下的gen_snapshot和flutter.jar。

後續主題

後續我們將就以下主題繼續分享:

a.Flutter架構中Embedder如何處理渲染和事件(點選等)傳遞，如何管理執行緒和訊息迴圈，Channel如何工作。

b.Engine中Dart的編譯除錯如何工作，Skia內部又是如何處理渲染的。

c.Native工程如何使用Flutter實現漸進式的重構與遷移。

d.如何搭建私有倉庫，實現pub對於多倉庫的支援

…

聯絡我們

如果對文字的內容有疑問或指正，歡迎告知我們。

另閒魚技術團隊誠聘各路英才，flutter，C++，iOS/Android，Java都要，歡迎簡歷來砸。

聯絡郵箱: kylewong.wk@alibaba-inc.com

參考文件

1.Flutter`s modes

2.iOS Builds Supporting ARMv7

3.Contributing to the Flutter engine

4.Flutter System Architecture

5.The magic of flutter

6.Symbolicating production crash stacks

7.flutter.io

8.獲取本文使用的原始碼


相關文章