Flutter引擎源码分析(一) - 编译调试

一、Xcode编译干了什么

image.png

cd flutter存放路径/flutter/packages/flutter_tools/bin && vim xcode_backend.sh

image.png

vim xcode_backend.dart

image.png
image.png
其实主要就是干了一件事，编译App
image.png
image.png
image.png

根据目标架构不同，对应格各自的framework

image.png
读取bitcode配置
image.png
如果是app集成flutter module的方式，执行脚本 把引擎拷贝到app中去,也就是上一步获取到的framework 下查找引擎
image.png
flutter 命令解释器执行命令 参数
image.png

似乎遗漏了什么 .....

image.png

Bingo! 😊 源码配置 要做的就是根据环境变量配置上源码引擎路径

image.png

equivalent of RunCommand pushd "${project_path}"
执行命令 通过引擎 选择合适的目标架构，生成目标文件，然后同步到相应的目录中

二、通过符号调试flutter engine

（一）MethodChanndel

1. 首先需要少量的代码配置

flutter端

image.png

ios端

image.png
image.png

2. 通过xcode运行起来，进入调试

下符号

image.png

c过断点

image.png
可以看出 FlutterMethodChannel 初始化默认生成一个编码器
继续符号
image.png

定位到一个关键结点

image.png
三个赋值操作， name， messenger(信使，可以理解为传递消息的人)，codec(编码器) , 存储到channel中

3. channel 设置回调

继续符号 setMethodCallHandler:

image.png

此时变得有点意思，为什么如此设计 不由得发出哲学三连问

• 这段代码究竟是什么？(只知道是个set)
• 如此设置的缘由是什么？
• 解决什么问题？

3.1 推敲复杂的4个block嵌套

image.png

handler - ①

messageHandler - ②

callback - ③

^(id result){} - ④

image.png

执行序列为 ② ① ④ ③ 有点反直觉

4个callback 貌似什么也没说，没关系，知道这里这么个设计就成，后面会有映照, 编上号也为了准确地描述以下部分

继续符号 setMessageHandlerOnChannel:binaryMessageHandler:

3.2 犹抱琵琶 - 引擎engine

image.png
image.png
image.png

最终到 c++部分 - message_handlers_ 通过 字符串key存储 handler, 回调的时候通过key再取出来执行

4. 根据下符号调试，messenger通过engine设置

FlutterBinaryMessageHandler

image.png
image.png

调试期间，最终追踪到engine，会不会engine本身就是实现了信使协议的信使？ 需通过flutter端进一步验证

三、 flutter与原生之间的通信猜测+分析

原生与flutter之间通信其实就是C++层面的数据通信，两种高级语言之间的耦合部分一定是往下层走，oc/swift/flutter 底层都是c++，从ios借助flutter引擎源码调试，handler的设置也是到c++，其实就很明显了

回到上面提到的4个回调嵌套，原生与flutter能够相互通信，其实就是这4个block的嵌套设计

image.png

信使可能就是engine

Flutter引擎源码分析(一) - 编译调试