共计 6321 个字符，预计需要花费 16 分钟才能阅读完成。
上一篇，咱们分享了 Flutter 在两轮的利用推广，本次分享的主题是 Flutter 在两轮的降级之路，次要分为两局部。一是咱们在 Flutter 落地之后，因为业务的倒退，导致咱们须要对 Flutter 进行降级。二是降级之后咱们遇到了一些问题，这里列举了一个比拟典型的案例——FlutterEngine 的自定义。
背景介绍
降级起因
两轮从 2019 年来开始应用 flutter，算是利用比拟早的团队。随后 flutter 降级了 2.x 版本，这个版本有个比拟重要的更新就是空平安（nullsafety），因为在 1.x 的版本，如果一个对象为 null 之后，再去调用它的任何办法，都会抛异样，在页面上的体现就是页面假死，也不会再刷新了。所以就须要研发人员关注下本人应用变量时是否曾经为空了，2.0 会强加这个查看，在编译阶段让咱们确定好次变量是否可空以及是否懒加载，这样在咱们应用变量时，就会有零碎揭示咱们，相当于帮咱们做了这个工作，缩小出错率。其实很多其余语言也都有这样的检测机制。再加上一些性能的提优，于是有了降级的诉求。
Flutter 版本敲定
这里比照了一下 1.x 版本和 2.x 版本的次要区别。2.x 版本优化了利用启动的提早，调用 Dart VM 的 GC 策略也做了一些改良，低端 Android 设施的初始帧出线间隔时间最多缩小了约 300ms。
此外，空对象音讯是咱们在开发中最常见的 exception，所以空平安是很有必要的。pub.dev 曾经公布了超过 1000 个空平安 package，包含来自 Dart、Flutter、Firebase 和 Material 团队公布的数百个 package。
降级施行
基础设施
基础设施降级次要波及到两方面，打包机 sdk 降级和集体研发侧版本管理工具。因为 SDK 降级在 2.8.1 版本删除了一些被弃用的 Api，会造成咱们编译报错。可参考以下批改：
- 切换本地环境为 2.8.1 版本
- 运行工程查看报错
- 批改对应报错库的 api
- 本地运行胜利后，挪动端 CI/CD 零碎发库提测
- 测试同学全量回归，灰度
降级节奏
整体的降级节奏包含：根底降级启动、各个业务线研发启动、业务线 null_safety 革新 1 - n 次、全量回归、灰度公布和异样观测。
本次 2.0 降级工作量根本都在 null_safety 语法革新上，因为工作量大波及范围广所以无奈在短期内实现语法革新。所以本次革新将按照业务性能划分，尽量收拢每次语法革新带来的影响范畴，从而引起测试侧屡次全量测试的人力节约。
Flutter 空平安
健全的空平安已在 Dart 2.12 和 Flutter 2.0 及更高版本中可用。Dart 3 及当前的版本将只反对健全的空平安。
有了空平安，上面代码中所有的变量都是非空的：
依赖项查看
应用官网工具进行类型推断，最好确保依赖的所有包都曾经降级为 null safe 版本。所以在革新时应该从底层向上逐渐降级。
在控制台执行如下命令：dart pub outdated —mode=null-safety
能够查看到以后我的项目工程依赖包是否是 null safe。
对于其中不符合要求的外部库，须要手动降级后打包，生成 null safe 版本，倡议版本号比之前最新版减少一个大版本；对于三方库能够在三方库官方站点或者中文站点查找合乎 null safe 的最新版本号，并批改我的项目工程的 yaml 文件。
全副依赖批改实现后，执行命令拉取最新依赖：
flutter pub get
flutter pub upgrade操作实现之后能够应用第一步的命令查看是否依赖都校对完了。
如果提醒所有依赖都申明反对 null safe，或者冀望跳过依赖查看，就能够进行后续操作。
执行胜利之后，会生成 url，点击可在浏览器中应用迁徙工具：
左侧是须要迁徙的文件目录，官网工具会对选中文件进行类型推断并主动增加如下标记：
- ! (类型不可为空)
- ? (类型可为空)
- late (初始化延时)
- late final (一次性初始化延时)
- required (参数标记)
面板两头能够看到具体改变，右侧能够看到以后文件改变的起因。
对于不须要迁徙或者大型文件须要分步迁徙的场景，能够只勾选须要迁徙的文件目录，官网迁徙工具会主动为不须要迁徙的文件顶层增加 null unsafe Dart 的版本正文。
引入反对 null safe 的第三方库
在更改本地代码时，个别都须要先降级依赖的第三方库，然而在官网第三方库下载地址 https://pub.flutter-io.cn 或者中文站点 https://pub.flutter-io.cn 中查问到依赖库的最新版本。
常见谬误及批改形式
- 谬误 1：The non-nullable variable ‘preferences’ must be initialized.
起因：非空的动态变量或者顶层变量在申明时没有初始化，诊断器就会报此谬误。因为 flutter 对于没有初始化的变量会主动赋值为 null，而该变量并没有申明可空。
解决办法：
- 谬误 2：The method ‘*‘ can’t be unconditionally invoked because the receiver can be ‘null’.
起因：可能为空的变量间接应用 ’.’ 调用办法，诊断器就会报此谬误。
解决办法：
- 谬误 3：Map<int, list> 简单类型批改
解决办法：
- 谬误 4：The default ‘List’ constructor isn’t available when null safety is enabled.
解决办法：
FlutterEngine 的 Crash 问题
在上线之后，安稳运行一段时间，咱们也继续察看监控数据，发现在 native 有大量新类型 crash。
[FlutterEngine destroyContext] 相干的 crash
解体起因是在用户敞开利用的时候会告诉到 flutter 引擎进行重置操作 (调用办法看【FlutterEngine destroyContext】)。重置的时候因为官网问题导致 engine 被屡次重置销毁。在第二次的重置的时候（OnPlatformViewSetSemanticsEnabled 这个办法里边获取引擎指针的时候解体了）
发现问题后，咱们去翻看了官网 issue，发现官网曾经修复该问题，不过是在后续版本上修复的，联合咱们本身状况（此 crash 产生是在后盾）咱们外部研究了几种解决方案：
- 解决方案 1
官网曾经修复了该问题，并曾经合并代码到 master。
修复的 pull request：https://github.com/flutter/engine/pull/30835/commits
bufix 的形容：
https://github.com/flutter/flutter/issues/95844
合并到引擎 commit 记录：https://github.com/flutter/engine/commit/fb3ee7f2b5e6e537a2a83c9fe2cf733cd9c6ec06
在高版本，2.10.2(2.10.3+) 以上此类问题已修复。
2.8.1Cherrypicks:
https://github.com/flutter/engine/pull/30355
但目前无奈间接降级到 flutter 版本到 2.10.2 以上，临时的解决办法是本地 cherry pick 代码，编译打包 flutter engine，替换 2.8.1 的 flutter engine。
危险最小然而须要评估改 pull request 的 cherry pick 老本，须要根底技术支持打包计划文档，须要摸索引擎打包交融到 flutter 批改打包，再到 flux 打 flutter 包流程交融。
- 解决方案 2
flutter 引擎从 2.8.1 降级到 2.10.4
- 解决方案 3
能够 hook destroyContext 在判断利用状态是否调用 destroyContext，但这个有肯定危险可能会影响其余的逻辑。
- 解决方案 4
梳理引擎切换的场景，通过业务上防止减小 crash 产生。
最终咱们抉择了激进的计划肯定制 FlutterEngine。
环境筹备
git
Python
Xcode
depot_tools 创立目录 /Users/xx/Desktop/flutter-engine
depot_tools 装置（须要全局 VPN 否则很慢）
cd /Users/xx/Desktop/flutter-engine
git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git配置环境 (~/.zshrc 或者~/.bashrc)
export PATH=/Users/xx/Desktop/flutter-engine/depot_tools:$PATH 这里有个配置文件须要留神下：
gclient
配置在 /Users/xxx/Desktop/flutter-engine 目录 engine 文件夹创立.gclient 文件
同步依赖
cd /Users/xxx/Desktop/flutter-engine/engine
gclient sync编译产物
cd /Users/xxx/Desktop/flutter-engine/engine/src
# --simulator 就是模拟器
# --ios-cpu=arm 就是 armv7，不指定默认就是 arm64
flutter/tools/gn --ios —unoptimized在 src/out/ios_debug_unopt 目录下，会生成一个 Xcode 我的项目，用于 debug 时候应用引擎源代码。
src/out/host_debug_unopt，我在 debug 引擎时候发现须要外面的 dart-sdk，所以这个也须要编译一下。如果没有批改 dart 层代码就不须要执行这一步。
执行 ninja，生成 framework 产物。
ninja -C out/ios_debug_unopt && ninja -C out/host_debug_unopt编译过程很漫长，能够在 ninja 前面加上参数 -j 2，防止编译占用过多的电脑资源，影响你开发。
编译实现之后，就要创立最初的 Flutter.xcframework。
官网也有提供 python 脚本工具，src/flutter/sky/tools 目录下的：create_ios_framework.py 和 create_macos_gen_snapshots.py
创立 Flutter.xcframework：release 版本加 –dsym 参数会生成 dysm 符号表
cd ~/Desktop/flutter-engine/engine/src/flutter/sky/tools
# debug 版本 Flutter.xcframework
python create_ios_framework.py --dst ~/Desktop/flutter-engine/engine/src/out/vd/ios --arm64-out-dir ~/Desktop/flutter-engine/engine/src/out/ios_debug --armv7-out-dir ~/Desktop/flutter-engine/engine/src/out/ios_debug_arm --simulator-out-dir ~/Desktop/flutter-engine/engine/src/out/ios_debug_sim
# profile 版本 Flutter.xcframework
python create_ios_framework.py --dst ~/Desktop/flutter-engine/engine/src/out/vd/ios-profile --arm64-out-dir ~/Desktop/flutter-engine/engine/src/out/ios_profile --armv7-out-dir ~/Desktop/flutter-engine/engine/src/out/ios_profile_arm --simulator-out-dir ~/Desktop/flutter-engine/engine/src/out/ios_debug_sim
# release 版本 Flutter.xcframework
python create_ios_framework.py --dst ~/Desktop/flutter-engine/engine/src/out/vd/ios-release --arm64-out-dir ~/Desktop/flutter-engine/engine/src/out/ios_release --armv7-out-dir ~/Desktop/flutter-engine/engine/src/out/ios_release_arm --simulator-out-dir ~/Desktop/flutter-engine/engine/src/out/ios_debug_sim --dsym
# 每个版本都加上了模拟器的局部，便于应用方模拟器调试 创立 gen_snapshots
cd ~/Desktop/flutter-engine/engine/src/flutter/sky/tools
# debug 版本 gen_snapshot_arm64 和 gen_snapshot_armv7
python create_macos_gen_snapshots.py --dst ~/Desktop/flutter-engine/engine/src/out/vd/ios --arm64-out-dir ~/Desktop/flutter-engine/engine/src/out/ios_debug --armv7-out-dir ~/Desktop/flutter-engine/engine/src/out/ios_debug_arm
# profile 版本 gen_snapshot_arm64 和 gen_snapshot_armv7
python create_macos_gen_snapshots.py --dst ~/Desktop/flutter-engine/engine/src/out/vd/ios-profile --arm64-out-dir ~/Desktop/flutter-engine/engine/src/out/ios_profile --armv7-out-dir ~/Desktop/flutter-engine/engine/src/out/ios_profile_arm
# release 版本 gen_snapshot_arm64 和 gen_snapshot_armv7
python create_macos_gen_snapshots.py --dst ~/Desktop/flutter-engine/engine/src/out/vd/ios-release --arm64-out-dir ~/Desktop/flutter-engine/engine/src/out/ios_release --armv7-out-dir ~/Desktop/flutter-engine/engine/src/out/ios_release_arm
# 模拟器是 JIT 的，不须要 gen_snapshot将来瞻望
俗话说，工欲善其事必先利其器。目前两轮 Flutter 降级后安稳运行，对业务迭代疾速倒退保驾护航。将来，两轮在大前端甚至能够持续摸索 flutter 的新特效，如 flutter-web，为大前端在小程序，taro，h5，app 的大交融夯实根底。
（本文作者：叶旸）