Flutter引擎源码分析(二) - channel原生通信

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引擎源码分析(一) - 编译调试

你可能感兴趣的:(Flutter引擎源码分析(二) - channel原生通信)