深刻理解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简介

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来渲染字体。

Embedder是一个嵌入层，即把Flutter嵌入到各个平台上去，这里作的主要工做包括渲染Surface设置,线程设置，以及插件等。从这里能够看出，Flutter的平台相关层很低，平台(如iOS)只是提供一个画布，剩余的全部渲染相关的逻辑都在Flutter内部，这就使得它具备了很好的跨端一致性。

Flutter工程结构

本文使用开发环境为flutter beta v0.3.1，对应的engine commit:09d05a389。

以hello_flutter工程为例，Flutter工程结构以下所示:

其中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代码构建链路以下所示:

其中gen_snapshot是dart编译器，采用了tree shaking(相似依赖树逻辑，可生成最小包，也于是在Flutter中禁止了dart支持的反射特性)等技术,用于生成汇编形式的机器代码，再经过xcrun等编译工具链生成最终的App.framework。换句话说，全部的dart代码，包括业务代码，三方package代码，它们所依赖的flutter框架代码，最终将会变成App.framework。

tree shaking功能位于gen_snapshot中，对应逻辑参见: engine/src/third_party/dart/runtime/vm/compiler/aot/precompiler.cc

dart代码最终对应到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_assets是相关的资源，代码则是位于Frameworks下的App.framework和Flutter.framework。

Release模式下的运行

Flutter相关的渲染，事件，通讯处理逻辑以下所示:

其中dart中的main函数调用栈以下:

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中的符号表以下所示:

对Runner.app/flutter_assets/snapshot_blob.bin执行strings命令能够看到以下内容:

Debug模式下main入口的调用堆栈以下:

Flutter代码的编译与运行(Android)

鉴于Android和iOS除了部分平台相关的特性外，其余逻辑如Release对应AOT，Debug对应JIT等均相似，此处只涉及二者不一样。

Release模式下的编译

release模式下，flutter下Android工程中dart代码整个构建链路以下所示:

其中vm/isolate_snapshot_data/instr内容均为arm指令，将会在运行时被engine载入，并标记vm/isolate_snapshot_instr为可执行。vm_中涉及runtime等服务(如gc)，用于初始化DartVM，调用入口见Dart_Initialize(dart_api.h)。isolate__则是对应了咱们的App代码，用于建立一个新的isolate,调用入口见Dart_CreateIsolate(dart_api.h)。flutter.jar相似iOS的Flutter.framework，包括了engine部分的代码(Flutter.jar中的libflutter.so)，以及一套将Flutter嵌入Android的类和接口(FlutterMain,FlutterView,FlutterNativeView等)。实际中flutter.jar位于flutter仓库的/bin/cache/artifacts/engine/android*下，默认从google仓库拉取。当须要自定义修改的时候，可经过下载engine源码，利用Ninja构建系统来生成flutter.jar。

以isolate_snapshot_data/instr为例，执行disarm命令结果以下:

)

其Apk结构以下所示:

APK新安装以后，会根据一个ts的判断(packageinfo中的versionCode结合lastUpdateTime)来决定是否拷贝APK中的assets，拷贝后内容以下所示:

isolate/vm_snapshot_data/instr均最后位于app的本地data目录下，而这部分又属于可写内容，所以能够经过下载并替换的方式，完成App的整个替换和更新。

Release模式下的运行

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的默认逻辑。以下所示:

由于gradle自己的特色，此部分修改后直接构建便可生效。

2.设定Android启动时默认使用第一个launchable-activity

此部分属于flutter_tools相关，修改以下:

这里的重点不是如何去修改，而是如何去让修改生效。原理上来讲，flutter run/build/analyze/test/upgrade等命令实际上执行的都是flutter(flutter_repo_dir/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下的flutter。此时能够构建release下的apk，也能够将flutter强制修改成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有依赖部分代码的从新编译，修改以下:

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的，但目前并未提供官方支持，须要自行修改相关逻辑，具体以下:

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=debug --ios --ios-cpu=arm
ninja -C out/ios_debug_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)。其背后的逻辑以下图所示:

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的命令行参数

b.以dart工程形式打开packages/flutter_tools，基于得到的参数修改flutter_tools.dart，设置命令行dart app便可开始调试。

>>>>阅读全文