原文 阿里技術(shù) ，?傳送門
Flutter簡介
Flutter的架構(gòu)主要分成三層:Framework，Engine和Embedder。
Framework使用dart實(shí)現(xiàn)，包括Material Design風(fēng)格的Widget,Cupertino(針對iOS)風(fēng)格的Widgets，文本/圖片/按鈕等基礎(chǔ)Widgets、渲染、動畫、手勢等。此部分的核心代碼是：flutter倉庫下的flutter package，以及sky_engine倉庫下的io,async,ui(dart:ui庫提供了Flutter框架和引擎之間的接口)等package。
Engine使用C++實(shí)現(xiàn)，主要包括:Skia,Dart和Text。Skia是開源的二維圖形庫，提供了適用于多種軟硬件平臺的通用API。其已作為Google Chrome，Chrome OS，Android, Mozilla Firefox, Firefox OS等其他眾多產(chǎn)品的圖形引擎，支持平臺還包括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來渲染字體。
Embedder是一個嵌入層，即把Flutter嵌入到各個平臺上去，這里做的主要工作包括渲染Surface設(shè)置,線程設(shè)置，以及插件等。從這里可以看出，F(xiàn)lutter的平臺相關(guān)層很低，平臺(如iOS)只是提供一個畫布，剩余的所有渲染相關(guān)的邏輯都在Flutter內(nèi)部，這就使得它具有了很好的跨端一致性。
Flutter工程結(jié)構(gòu)
本文使用開發(fā)環(huán)境為flutter beta v0.3.1，對應(yīng)的engine commit:09d05a389。
以hello_flutter工程為例，F(xiàn)lutter工程結(jié)構(gòu)如下所示：
其中ios為iOS部分代碼，使用CocoaPods管理依賴，android為Android部分代碼，使用Gradle管理依賴，lib為dart代碼，使用pub管理依賴。類似iOS中Cocoapods對應(yīng)的Podfile和Podfile.lock，pub下則是pubspec.yaml和pubspec.lock。
Flutter模式
對于Flutter，它支持常見的debug,release,profile等模式，但它又有其不一樣。
Debug模式：對應(yīng)了Dart的JIT模式，又稱檢查模式或者慢速模式。支持設(shè)備，模擬器(iOS/Android)，此模式下打開了斷言，包括所有的調(diào)試信息，服務(wù)擴(kuò)展和Observatory等調(diào)試輔助。此模式為快速開發(fā)和運(yùn)行做了優(yōu)化，但并未對執(zhí)行速度，包大小和部署做優(yōu)化。Debug模式下，編譯使用JIT技術(shù)，支持廣受歡迎的亞秒級有狀態(tài)的hot reload。
Release模式：對應(yīng)了Dart的AOT模式，此模式目標(biāo)即為部署到終端用戶。只支持真機(jī)，不包括模擬器。關(guān)閉了所有斷言，盡可能多地去掉了調(diào)試信息，關(guān)閉了所有調(diào)試工具。為快速啟動，快速執(zhí)行，包大小做了優(yōu)化。禁止了所有調(diào)試輔助手段，服務(wù)擴(kuò)展。
Profile模式：類似Release模式，只是多了對于Profile模式的服務(wù)擴(kuò)展的支持，支持跟蹤，以及最小化使用跟蹤信息需要的依賴，例如，observatory可以連接上進(jìn)程。Profile并不支持模擬器的原因在于，模擬器上的診斷并不代表真實(shí)的性能。
鑒于Profile同Release在編譯原理等上無差異，本文只討論Debug和Release模式。
事實(shí)上flutter下的iOS/Android工程本質(zhì)上依然是一個標(biāo)準(zhǔn)的iOS/Android的工程，flutter只是通過在BuildPhase中添加shell來生成和嵌入App.framework和Flutter.framework(iOS),通過gradle來添加flutter.jar和vm/isolate_snapshot_data/instr(Android)來將Flutter相關(guān)代碼編譯和嵌入原生App而已。因此本文主要討論因flutter引入的構(gòu)建，運(yùn)行等原理。編譯target雖然包括arm,x64,x86,arm64，但因原理類似，本文只討論arm相關(guān)(如無特殊說明，android默認(rèn)為armv7)。
Flutter代碼的編譯與運(yùn)行(iOS)
Release模式下的編譯
release模式下，flutter下iOS工程中dart代碼構(gòu)建鏈路如下所示：
其中g(shù)en_snapshot是dart編譯器，采用了tree shaking(類似依賴樹邏輯，可生成最小包，也因而在Flutter中禁止了dart支持的反射特性)等技術(shù),用于生成匯編形式的機(jī)器代碼，再通過xcrun等編譯工具鏈生成最終的App.framework。換句話說，所有的dart代碼，包括業(yè)務(wù)代碼，三方package代碼，它們所依賴的flutter框架代碼，最終將會變成App.framework。
tree shaking功能位于gen_snapshot中，對應(yīng)邏輯參見:?
engine/src/third_party/dart/runtime/vm/compiler/aot/precompiler.cc
dart代碼最終對應(yīng)到App.framework中的符號如下所示：
事實(shí)上，類似Android Release下的產(chǎn)物(見下文)，App.framework也包含了kDartVmSnapshotData，kDartVmSnapshotInstructions，kDartIsolateSnapshotData，kDartIsolateSnapshotInstructions四個部分。為什么iOS使用App.framework這種方式，而不是Android的四個文件的方式呢？原因在于在iOS下，因?yàn)橄到y(tǒng)的限制，F(xiàn)lutter引擎不能夠在運(yùn)行時將某內(nèi)存頁標(biāo)記為可執(zhí)行，而Android是可以的。
Flutter.framework對應(yīng)了Flutter架構(gòu)中的engine部分，以及Embedder。實(shí)際中Flutter.framework位于flutter倉庫的/bin/cache/artifacts/engine/ios*下，默認(rèn)從google倉庫拉取。當(dāng)需要自定義修改的時候，可通過下載engine源碼，利用Ninja構(gòu)建系統(tǒng)來生成。
Flutter相關(guān)代碼的最終產(chǎn)物是:App.framework(dart代碼生成)和Flutter.framework(引擎)。從Xcode工程的視角看，Generated.xcconfig描述了Flutter相關(guān)環(huán)境的配置信息，然后Runner工程設(shè)置中的Build Phases新增的xcode_backend.sh實(shí)現(xiàn)了Flutter.framework的拷貝(從Flutter倉庫的引擎到Runner工程根目錄下的Flutter目錄)與嵌入和App.framework的編譯與嵌入。最終生成的Runner.app中Flutter相關(guān)內(nèi)容如下所示：
其中flutter_assets是相關(guān)的資源，代碼則是位于Frameworks下的App.framework和Flutter.framework。
Release模式下的運(yùn)行
Flutter相關(guān)的渲染，事件，通信處理邏輯如下所示：
其中dart中的main函數(shù)調(diào)用棧如下：
Debug模式下的編譯
Debug模式下flutter的編譯，結(jié)構(gòu)類似Release模式，差異主要表現(xiàn)為兩點(diǎn)：
1.Flutter.framework
因?yàn)槭荄ebug，此模式下Framework中是有JIT支持的，而在Release模式下并沒有JIT部分。
2.App.framework
不同于AOT模式下的App.framework是Dart代碼對應(yīng)的本地機(jī)器代碼，JIT模式下，App.framework只有幾個簡單的API，其Dart代碼存在于snapshot_blob.bin文件里。這部分的snapshot是腳本快照，里面是簡單的標(biāo)記化的源代碼。所有的注釋，空白字符都被移除，常量也被規(guī)范化，也沒有機(jī)器碼，tree shaking或者是混淆。
App.framework中的符號表如下所示：
對Runner.app/flutter_assets/snapshot_blob.bin執(zhí)行strings命令可以看到如下內(nèi)容：
Debug模式下main入口的調(diào)用堆棧如下：
Flutter代碼的編譯與運(yùn)行(Android)
鑒于Android和iOS除了部分平臺相關(guān)的特性外，其他邏輯如Release對應(yīng)AOT，Debug對應(yīng)JIT等均類似，此處只涉及兩者不同。
Release模式下的編譯
release模式下，flutter下Android工程中dart代碼整個構(gòu)建鏈路如下所示：
其中vm/isolate_snapshot_data/instr內(nèi)容均為arm指令，將會在運(yùn)行時被engine載入，并標(biāo)記vm/isolate_snapshot_instr為可執(zhí)行。vm_中涉及runtime等服務(wù)(如gc)，用于初始化DartVM，調(diào)用入口見Dart_Initialize(dart_api.h)。isolate__則是對應(yīng)了我們的App代碼，用于創(chuàng)建一個新isolate,調(diào)用入口見Dart_CreateIsolate(dart_api.h)。
flutter.jar類似iOS的Flutter.framework，包括了engine部分的代碼(Flutter.jar中的libflutter.so)，以及一套將Flutter嵌入Android的類和接口(FlutterMain,FlutterView,FlutterNativeView等)。實(shí)際中flutter.jar位于flutter倉庫的/bin/cache/artifacts/engine/android*下，默認(rèn)從google倉庫拉取。當(dāng)需要自定義修改的時候，可通過下載engine源碼，利用Ninja構(gòu)建系統(tǒng)來生成flutter.jar。
以isolate_snapshot_data/instr為例，執(zhí)行disarm命令結(jié)果如下：
其Apk結(jié)構(gòu)如下所示：
APK新安裝之后，會根據(jù)一個ts的判斷(packageinfo中的versionCode結(jié)合lastUpdateTime)來決定是否拷貝APK中的assets，拷貝后內(nèi)容如下所示：
isolate/vm_snapshot_data/instr均最后位于app的本地data目錄下，而這部分又屬于可寫內(nèi)容，因此可以通過下載并替換的方式，完成App的整個替換和更新。
Release模式下的運(yùn)行
Debug模式下的編譯
類似iOS的Debug/Release的差別，Android的Debug與Release的差異主要包括以下兩部分：
1.flutter.jar
區(qū)別同iOS
2.App代碼部分
位于flutter_assets下的snapshot_blob.bin，同iOS。
在介紹了iOS/Android下的Flutter編譯原理后，下面著重描述下如何定制flutter/engine以完成定制和優(yōu)化。鑒于Flutter處于敏捷的迭代中，現(xiàn)在的問題后續(xù)不一定是問題，因而此部分并不是要去解決多少問題，而是選取不同類別的問題來說明解決思路。
Flutter構(gòu)建相關(guān)的定制與優(yōu)化
Flutter是一個很復(fù)雜的系統(tǒng)，除了上述提到的三層架構(gòu)中的內(nèi)容外，還包括Flutter Android Studio(Intellij)插件，pub倉庫管理等。但我們的定制和優(yōu)化往往是在flutter的工具鏈相關(guān)，具體代碼位于flutter倉庫的flutter_tools包。接下來舉例說明下如何對這部分做定制。
Android部分
相關(guān)內(nèi)容包括flutter.jar，libflutter.so(位于flutter.jar下)，gen_snapshot，flutter.gradle，flutter(flutter_tools)。
1.限定Android中target為armeabi
此部分屬于構(gòu)建相關(guān)，邏輯位于flutter.gradle下。當(dāng)App是通過armeabi支持armv7/arm64的時候，需要修改flutter的默認(rèn)邏輯。如下所示：
因?yàn)間radle本身的特點(diǎn)，此部分修改后直接構(gòu)建即可生效。
2.設(shè)定Android啟動時默認(rèn)使用第一個launchable-activity，此部分屬于flutter_tools相關(guān)，修改如下：
這里的重點(diǎn)不是如何去修改，而是如何去讓修改生效。原理上來說，flutter run/build/analyze/test/upgrade等命令實(shí)際上執(zhí)行的都是flutter(flutter_repo_dir/bin/flutter)這一腳本，再通過腳本通過dart執(zhí)行flutter_tools.snapshot(通過packages/flutter_tools生成)。其邏輯如下：
不難看出要重新構(gòu)建flutter_tools，可以刪除flutter_repo_dir/bin/cache/flutter_tools.stamp(這樣重新生成一次)，或者屏蔽掉if/fi判斷(每一次都會重新生成)。
3.如何在Android工程Debug模式下使用release模式的flutter
當(dāng)開發(fā)者在研發(fā)中發(fā)現(xiàn)flutter有些卡頓時，猜測可能是邏輯的原因，也可能是因?yàn)槭荄ebug下的flutter。此時可以構(gòu)建release下的apk，也可以將flutter強(qiáng)制修改為release模式如下：
iOS部分
相關(guān)內(nèi)容包括:Flutter.framework，gen_snapshot，xcode_backend.sh，flutter(flutter_tools)。
1.優(yōu)化構(gòu)建過程中反復(fù)替換Flutter.framework導(dǎo)致的重新編譯
此部分邏輯屬于構(gòu)建相關(guān)，位于xcode_backend.sh中，F(xiàn)lutter為了保證每次獲取到正確的Flutter.framework,每次都會基于配置(見Generated.xcconfig配置)查找和替換Flutter.framework，但這也導(dǎo)致了工程中對此Framework有依賴部分代碼的重新編譯，修改如下：
2.如何在iOS工程Debug模式下使用release模式的flutter
只需要將Generated.xcconfig中的FLUTTER_BUILD_MODE修改為release，F(xiàn)LUTTER_FRAMEWORK_DIR修改為release對應(yīng)的路徑即可。
3.armv7的支持
原始文章請參見:
https://github.com/flutter/engine/wiki/iOS-Builds-Supporting-ARMv7
事實(shí)上flutter本身是支持iOS下的armv7的，但目前并未提供官方支持，需要自行修改相關(guān)邏輯，具體如下：
a.默認(rèn)的邏輯可以生成
Flutter.framework(arm64)
b.修改flutter以使得flutter_tools可以每次重新構(gòu)建，修改build_aot.dart和mac.dart，將相關(guān)針對iOS的arm64修改為armv7,修改gen_snapshot為i386架構(gòu)。
其中i386架構(gòu)下的gen_snapshot可通過以下命令生成：
這里有一個隱含邏輯：
構(gòu)建gen_snapshot的CPU相關(guān)預(yù)定義宏(x86_64/__i386等)，目標(biāo)gen_snapshot的arch，最終的App.framework的架構(gòu)整體上要保持一致。即x86_64->x86_64->arm64或者i386->i386->armv7。
c.在iPhone4S上，會發(fā)生因gen_snapshot生成不被支持的SDIV指令而造成EXC_BAD_INSTRUCTION(EXC_ARM_UNDEFINED)錯誤，可通過給gen_snapshot添加參數(shù)--no-use-integer-division實(shí)現(xiàn)(位于build_aot.dart)。其背后的邏輯如下圖所示：
d.基于a和b生成的Flutter.framework,將其lipo create生成同時支持armv7和arm64的Flutter.framework。
e.修改Flutter.framework下的Info.plist，移除
同理，對于App.framework也要作此操作，以免上架后會受到App Thining的影響。
flutter_tools的調(diào)試
例如我們想了解flutter在構(gòu)建debug模式下的apk的時候，具體執(zhí)行的邏輯如何，可以按照下面的思路走：
a.了解flutter_tools的命令行參數(shù)
b.以dart工程形式打開packages/flutter_tools，基于獲得的參數(shù)修改flutter_tools.dart，設(shè)置命令行dart app即可開始調(diào)試。
定制engine與調(diào)試
假設(shè)我們在flutter beta v0.3.1的基礎(chǔ)上進(jìn)行定制與業(yè)務(wù)開發(fā)，為了保證穩(wěn)定，一定周期內(nèi)并不升級SDK，而此時，flutter在master上修改了某個v0.3.1上就有的bug，記為fix_bug_commit。如何才能跟蹤和管理這種情形呢？
1.flutter beta v0.3.1指定了其對應(yīng)的engine commit為:09d05a389，見
flutter/bin/internal/engine.version。
2.獲取engine代碼
3.因?yàn)?中拿到的是master代碼，而我們需要的是特定commit(09d05a389)對應(yīng)的代碼庫，因而從此commit拉出新分支:custom_beta_v0.3.1。
4.基于custom_beta_v0.3.1(commit:09d05a389)，執(zhí)行g(shù)client sync，即可拿到對應(yīng)flutter beta v0.3.1的所有engine代碼。
5.使用git cherry-pick fix_bug_commit將master的修改同步到custom_beta_v0.3.1，如果修改有很多對最新修改的依賴，可能會導(dǎo)致編譯失敗。
6.對于iOS相關(guān)的修改執(zhí)行以下代碼：
如果需要調(diào)試Flutter.framework源代碼，構(gòu)建的時候命令如下：
用生成產(chǎn)物替換掉flutter中的Flutter.framework和gen_snapshot，即可調(diào)試engine源代碼。
7.對于Android相關(guān)的修改執(zhí)行以下代碼：
即可生成針對Android的arm&debug/release/profile
的產(chǎn)物?？捎脴?gòu)建產(chǎn)物替換
flutter/bin/cache/artifacts/engine/android*下的gen_snapshot和flutter.jar。
