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

·  阅读 1639

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

image.png 执行命令 通过引擎 选择合适的目标架构,生成目标文件,然后同步到相应的目录中

二、通过符号调试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(信使)其实是个协议

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

分类:
前端
标签:
分类:
前端
标签:
收藏成功!
已添加到「」, 点击更改