flutter|flutter build做了什么事情(iOS 打包编译流程)
1、展示JIT模式 下编译文件列表,并解释每个文件的内容
1、展示文件:
文章图片
屏幕快照 2019-10-16 下午3.20.03.png 2、单个文件说明:
- app.dill : 这就是dart代码通过build的产物,为二进制的字节码,可以通过
strings app.dill
看到里面的内容,其实就是我们dart代码的源码。 - Frontend_server.d : 这里面放的是frontend_server.dart.snapshot的绝对路径,这个.snapshot可执行文件其实就是真正把我们dart代码编程app.dill的真正工具,下面详细讲解。
- snapshot_blob.bin.d : 这个文件里面是所有参与编译的dart文件的集合,包括我们自己的业务代码、
pubspec.yaml
中定义的三方库的代码、以及我们业务代码中import进来的所有flutter或者dart原生package
的代码。 - snapshot_blob.bin.d.fingerprint : 这里面放的是snapshot_blob.bin.d中的所有文件的绝对路径以及每个文件内容对应的md5值。使用这个md5来判断该文件是否有修改。在每次编译的时候会判断,如果没有文件修改,则直接跳过编译。
FlutterSDK/bin/flutter
其核心代码为最下面的"$DART" $FLUTTER_TOOL_ARGS "$SNAPSHOT_PATH" "$@"
。我们可以分别打印出相关参数,如下图修改flutter可执行文件:文章图片
WechatIMG2.jpeg
然后我们随便执行一条flutter命令,我执行的是flutter -h,结果如下:
文章图片
WechatIMG3.jpeg
所以最终
flutter -h
的命令实际上为:
【flutter|flutter build做了什么事情(iOS 打包编译流程)】
/Users/zhuyaning/.flutter_sdk/bin/cache/dart-sdk/bin/dart /Users/zhuyaning/.flutter_sdk/bin/cache/flutter_tools.snapshot -h
解释一下的话:就是启动dart虚拟机,在dart虚拟机上运行:因此,我们需要知道flutter_tools.snapshot是什么。
/Users/zhuyaning/.flutter_sdk/bin/cache/flutter_tools.snapshot,给这个
.snapshot的参数为-h
流程二:flutter_tools.snapshot是什么?我们怎么调试它呢? 其实flutter_tools.snapshot也是个可执行文件,生成它的工程为
FlutterSDK/packages/flutter_tools
这个工程是可以debug的,下面这个是flutter官方的调试方法:flutter官方介绍
总结一下调试方法为:
1、使用Android Studio打开
FlutterSDK/packages/flutter_tools
2、自己设置一下flutter sdk的路径,入下图: 屏幕快照 2019-10-16 下午4.00.23.png 3、配置dart command line如下图所示: 文章图片
WechatIMG4.jpeg
文章图片
WechatIMG5.jpeg 4、断点调试结果展示:这里我就不多BB了,直接告诉大家,在
mac.dart
文件里的buildXcodeProject
方法中执行了runAsync方法
打断点,然后看一下给到runAsync
的参数,如下图: image.png 说明,最终执行的是我们iOS工程的5、探究xcrun xcodebuild + 上图红框按顺序罗列
这条命令。
说白了:就等于,我们用xcode打开iOS工程,然后点击run
按钮是一个道理的。
flutter create
出来的iOS工程,发现如下图,有个run Script
image.png 此脚本为:
/bin/sh "$FLUTTER_ROOT/packages/flutter_tools/bin/xcode_backend.sh" build
1、/bin/sh 表示环境为shell6、xcode_backend.sh是什么? 在
2、在shell环境下执行xcode_backend.sh build命令。
FlutterSDK/packages/flutter_tools/bin/xcode_backend.sh
目录下,打开xcode_backend.sh。这里我也找到了关键的地方,发现最终又执行
flutter build bundle
命令,然后我打印出了这个命令的参数,如何打印和打印结果如下:文章图片
image.png
文章图片
屏幕快照 2019-10-16 下午4.46.09.png
所以这个xcode_backend.sh执行的真正命令为:
FlutterSDK/bin/flutter --suppress-analytics build bundle --target-platform=ios --target=lib/main.dart --debug --depfile=build/snapshot_blob.bin.d --asset-dir=/Users/zhuyaning/Desktop/test/abc/ios/Flutter/App.framework/flutter_assets
仔细一看其实就是 flutter build bundle + 参数所以,我们需要调试一下
1、--target-platform=ios 表示iOS的工程
2、--target=lib/main.dart 入口文件是谁
3、--debug 编译模式是啥
4、--depfile=build/snapshot_blob.bin.d目标文件有哪些,开头也说过snapshot_blob.bin.d这个文件里面是啥
5、--asset dir=/Users/zhuyaning/Desktop/test/abc/ios/Flutter/App.framework/flutter_assets 编译出来的东西放在那里
flutter build bundle
这个命令7、
flutter build bundle
做了什么
我们把--suppress-analytics build bundle --target-platform=ios --target=lib/main.dart --debug --depfile=build/snapshot_blob.bin.d --asset-dir=/Users/zhuyaning/Desktop/test/abc/ios/Flutter/App.framework/flutter_assets
这一大串复制到我们刚刚用Android Studio打开的dart command line里面,如图:文章图片
image.png
8、调试
flutter build bundle
的结论
我不多啰嗦了:直接在compile.dart
中有一个classKernelCompiler
,在这个class的compile
方法中processManager .start
的地方打断点,看看传入的commands:如图:文章图片
image.png
通过看上图红框里的command,得到结论:因此需要看看这个frontend_server.dart.snapshot是个什么东西。
1、开启dart虚拟机
2、利用dart虚拟机运行一个叫FlutterSDK/bin/cache/artifacts/engine/darwin-x64/frontend_server.dart.snapshot
的脚本
3、后面还是参数,包括需要传入的文件路径、需要编译的模式、编译好了的东西输出到哪里。
9、
frontend_server.dart.snapshot
是什么?
直接说结论:frontend_server.dart.snapshot
和其他可执行文件一样,都是一个工程的产物,这个工程没有像flutter tools
在flutterSDK
中,而是在engine
中,所以需要自己下载flutter engine
flutter engine的下载地址
下载完成之后,同样用Android Studio打开
你下载的engine/src/flutter/frontend_server
。按刚刚调试flutter tools
的方式自己配置dart command line
,如图:文章图片
image.png
我把中间那一大串贴出来,大家可以参考:
--sdk-root /Users/zhuyaning/.flutter_sdk/bin/cache/artifacts/engine/common/flutter_patched_sdk/ --strong --target=flutter --no-link-platform --incremental --packages /Users/zhuyaning/Desktop/test/abc/.packages --output-dill build/app.dill --depfile build/snapshot_blob.bin.d --filesystem-scheme org-dartlang-root package:abc/main.dart10、到这里,当你看到这里的时候,才真正到如何生成dill的时候。 3、调试
frontend_server
经过一系列的方法调用,最终走到:@override
Future compile(
String entryPoint,
ArgResults options, {
IncrementalCompiler generator,
}) async {
....
....
....
Component component;
if (options['incremental']) {
_compilerOptions = compilerOptions;
setVMEnvironmentDefines(environmentDefines, _compilerOptions);
_compilerOptions.omitPlatform = false;
_generator =
generator ?? _createGenerator(new Uri.file(_initializeFromDill));
await invalidateIfInitializingFromDill();
component = await _runWithPrintRedirection(() => _generator.compile());
} else {
if (options['link-platform']) {
// TODO(aam): Remove linkedDependencies once platform is directly embedded
// into VM snapshot and http://dartbug.com/30111 is fixed.
compilerOptions.linkedDependencies = [
sdkRoot.resolve(platformKernelDill)
];
}
component = await _runWithPrintRedirection(() => compileToKernel(
_mainSource, compilerOptions,
aot: options['aot'],
useGlobalTypeFlowAnalysis: options['tfa'],
environmentDefines: environmentDefines,
useProtobufTreeShaker: options['protobuf-tree-shaker']));
}
....
....
....
}
到此上面我省去的代码,是做一些校验工作,重点在
if (options['incremental'])
后面,这里判断是否为增量编译
,由于我们在编译参数中携带了--incremental,所以最终会进入if
中。无论if
还是else
都为下面省去的代码提供一个component
。这个component是什么?
/// A way to bundle up libraries in a component.
class Component extends TreeNode {
final CanonicalName root;
/// Problems in this [Component] encoded as json objects.
///
/// Note that this field can be null, and by convention should be null if the
/// list is empty.
List problemsAsJson;
final List libraries;
/// Map from a source file URI to a line-starts table and source code.
/// Given a source file URI and a offset in that file one can translate
/// it to a line:column position in that file.
final Map uriToSource;
/// Mapping between string tags and [MetadataRepository] corresponding to
/// those tags.
final Map> metadata =https://www.it610.com/article/>{};
/// Reference to the main method in one of the libraries.
Reference mainMethodName;
...这里同样省略了一些代码
}
通过对源码component 这个class的查看,它主要包含:
1、
List libraries
2、
Map uriToSource;
我们看一下Libraries和uriToSource是什么
Libriaries
文章图片
image.png
每一个Library代表一个参与编译的文件,而且Library中包含文件的绝对路径、引用关系、定义的class、method、文件偏移量等等等等,所有和该文件相关的信息都定于于此,有点像ios中
clang
生成的抽象语法树 AST。
uriToSource
文章图片
屏幕快照 2019-10-16 下午7.36.28.png
uriToSource是uri为key source为value的map,作为一个工具,通过uri来找寻对应的文件。
结论: component其实就是所有参与编译的文件生成的抽象语法树的包装类,就像我们
MVC
架构中的model
一样。值得一提的是,在生成component的过程中,执行了一个方法:
文章图片
image.png
这个方法遍历了每一个Libriary,并对其中每一个类、方法等解析成了Token(Token中定义的都是class、method的偏移量),并且通过
parser.parseUnit(tokens);
经过词法及语法分析,生成刚才我们看到的抽象语法树。
component 得到之后,我们回到
Future compile(
下面省略的代码:
if (component != null) {
if (transformer != null) {
transformer.transform(component);
}await writeDillFile(component, _kernelBinaryFilename,
filterExternal: importDill != null);
_outputStream.writeln(boundaryKey);
await _outputDependenciesDelta(component);
_outputStream
.writeln('$boundaryKey $_kernelBinaryFilename ${errors.length}');
final String depfile = options['depfile'];
if (depfile != null) {
await writeDepfile(compilerOptions.fileSystem, component,
_kernelBinaryFilename, depfile);
}_kernelBinaryFilename = _kernelBinaryFilenameIncremental;
}
调用
await writeDillFile(component, _kernelBinaryFilename, filterExternal: importDill != null);
方法,把刚才生成的component
,通过BinaryFile
输出到定义的产物文件夹。到此,dill文件的生成过程就结束了,其实debug模式下app.framework中的
kernel_blob.bin
和刚才讲解的app.dill
是同一个文件,都可以直接被dartVM
直接执行。
推荐阅读
- 我从来不做坏事
- Flutter的ListView
- 异性同事关系再好,一旦做了这5件事,就是想0距离接触
- 运用flutter|运用flutter 构建一个发布版(release)APK
- 暑假小儿日记二今天我做了什么
- Flutter自定义view|Flutter自定义view —— 闯关进度条
- 跑步锻炼却伤了膝盖(10|跑步锻炼却伤了膝盖?10 个容易犯的错误,别再做了!)
- 助教有感
- Flutter|Flutter SwiftUI React 对比
- flutter设置沉浸式状态栏