Flutter热更新技术探索 | 京东云技术团队
一,需求背景:
APP发布到市场后,难免会遇到严重的BUG阻碍用户使用,因此有在不发布新版本APP的情况下使用热更新技术立即修复BUG需求。原生APP(例如:Android & IOS)的热更新需求已经比较成熟,但Flutter技术栈目前还缺少类似的技术方案,因此Flutter研发团队,也需要类似的热更新技术。
二,Flutter热更新技术方向分析:
经过分析目前可能有三种可行的方案: 1)类似RN框架; 2)页面动态组件框架; 3)Dart虚拟机定制方案;
方案名称 | 原理 | 优点 | 缺点 | 开源方案 |
---|---|---|---|---|
类似RN的方案 | 用JS以Flutter语法写dart,然后用JavaScript把XML DSL转为Flutter的原子widget组件,然后再让Flutter来渲染 | 由于ios系统内置支持js,ios上完全可以实现更新 | 1)由于跨语言执行,对于性能有影响;学习成本高 2)Android 端需要额外引入JS库 | 手Q的MXFlutter,58同城的Fair |
页面动态组件方案 | 编译期时插桩/预埋好DynamicWidget到代码中,然后动态下发Json 数据,通过协定好的语义匹配到JSON内的数据,动态替换Widget内容来实现更新 | 能支持Android/iOS 两端的更新 | 1)UI更新相对较容易,业务逻辑动态化较麻烦; 2)语义解析器开发成本相对较大,且不易维护 3)需要一整套前后端服务和工具 | 天猫的Tangram,淘宝的DinamicX等 |
Dart虚拟机定制方案 | 通过分析Dart虚拟机的原理,修改Flutter Engine层Java/C++代码实现热更新的目标; | 性能影响小,动态性很高,技术上可以替换所有Flutter页面(包括UI,逻辑,资源文件) | 由于使用的是定制引擎,需要维护不同版本的Flutter引擎代码; | 未开源 |
因为其他方式都有开源的示例,本案将重点以第三种“Dart虚拟机定制方案”为目标,做方案的研究讲解。
三,预备知识
在开始了解技术方案之前,需要提前了解一些相应的技术概念:
3.1 Flutter编译模式
Flutter开发语言是Dart,它的编译模式来自Dart的编译模式,主要有JIT(Just In Time)和AOT(Ahead Of Time)。
编译模式名称 | 特点 | 优点 | 缺点 |
---|---|---|---|
JIT | 即时编译,典型例子V8,它可以即时编译运行JS,只需要输入源代码字符串,就可以编译运行代码 | 可以动态下发和执行代码,不用管CPU架构,可以提供动态化内容 | 1,大量字符串代码让JIT编译器花费时间和内存; 2,性能不好; |
AOT | 预先编译,典型例子C/C++,通过GCC编译成二进制代码,然后安装取得权限后才可以加载执行 | 事先编译好的,加载和执行速度快 | 1,编译时区分CPU架构; 2,生成的二进制代码包比较大; 3,二进制代码需要取得权限才可以执行,无法在ios系统上动态更新 |
Flutter编译模式有:Debug,Release,Profile;
Flutter编译模式 | 特点 |
---|---|
Debug | 对应JIT模式,支持设备和模拟器; 打开了断言,支持快速开发,支持HotReload; 并未对包大小,执行速度做优化; |
Release | 对应AOT模式,支持真机,不支持模拟器; 禁止了所有断言调试信息; 对包大小,启动和执行速度进行了优化; |
Profile | 类似Release模式,保留了一些调试功能,帮助性能分析; |
3.2 Flutter编译产物分析
Flutter下的iOS/Android工程本质上是一个标准的iOS/Android的工程;IOS平台: Flutter通过在BuildPhase中添加shell(xcode_backend.sh)来生成和嵌入App.framework和Flutter.framework到ios; Android平台: Flutter通过gradle来添加flutter.jar和编译完的二进制文件添加到Android;
3.2.1 引擎层结构分析:
3.2.2 Android编译产物的分析
3.2.3 IOS编译产物的分析
四,热更新技术方案分析
4.1 业务代码分析
根据“3.3.1” ~“3.3.2”的分析可以确定无论是IOS还是Android APP业务代码都是由四个段组成:kDartVmSnapshotData、kDartVmSnapshotInstructions、kDartIsolateSnapshotData、kDartIsolateSnapshotInstructions;理论上只要能动态替换加载的代码段&数据段代码即可实现目标。
名称 | 注释 | 作用 | 注释 |
---|---|---|---|
kDartIsolateSnapshotData | Dart isolate数据段 | 类信息,全局变量,函数指针等 | 允许动态下发 |
kDartIsolateSnapshotInstructions | Dart isolate指令段 | 包含由Dart isolate执行的AOT代码 | IOS不允许动态下发 |
kDartVmSnapshotData | vm isolate数据段 | isolate 之间共享的 Dart 堆 (heap) 的初始状态 | 允许动态下发 |
kDartVmSnapshotInstructions | vm isolate指令段 | 包含 VM 中所有 Dart isolate 之间共享的通用程序的 AOT 指令 | IOS不允许动态下发 |
注释: isolate, snapshot, vm isolate含义解释如下:
名称 | 含义 |
---|---|
isolate | Dart是单线程,isolate跟线程差不多,可以理解为 Dart 中的线程。 isolate 与线程的区别:线程与线程之间是共享内存的,而 isolate 和 isolate 之间是内存不共享的。 不存在锁竞争问题,两个Isolate完全是两条独立的执行线,且每个Isolate都有自己的事件循环,它们之间只能通过发送消息通信,所以它的资源开销低于线程。 |
snapshot | 将类信息、全局变量、函数指令直接以序列化的方式存在磁盘中,称为 Snapshot(快照)。 |
vm isolate | 同一个进程里可以有很多isolate,但两个 isolate 的堆区是不能共享的,所以官方设计了 VM isolate,也就是 kDartVmSnapshot,用来多个 isolate 之间的交互。 |
4.2 业务代码的加载分析(运行时)
按照4.1的分析思路,我们首先需要了解Flutter运行时代码加载的完整流程,经过梳理分析流程如下:
1 )Android- APP业务代码的加载流程:
2)IOS- APP业务代码的加载流程:
4.3 业务代码的编译生成(编译时)
根据以上的分析,我们知道了Flutter业务代码的数据结构,也知道了在运行时如何加载,因此我们只需要在编译时做更改,产生自己需要的代码段,和数据段文件。在运行时加载自己的构建产物即可达到目标。
1)在此以 IOS 构建自己的业务代码流程做详细分析:
**有完成构建流程可以分析,基本流程是“Dart Code(业务代码)” -> (通过Dart编译器gen_snapshot.cc) 生成 snapshot_assemble.S 的汇编文件 -> (通过xcrun工具)生成 snapshot_assemble.o的obj文件 -> (通过xcun clang工具链) 生成了 App.Framework。
2)Android的产物构建流程和IOS类似。由于Android有其他更简单的方案, 因此省略详细的构建流程分析,大致如下:
4.4 实现热更新的方案探索
根据上面的技术分析结果,已经可以独立生成自己的代码段,数据段文件。通过需改虚拟机底层代码的方式,也可以动态的加载运行。但由于IOS系统目前底层的系统还不能动态加载可读写的代码段数据到内存中,所以还有技术难点需要突破。但Android端有更简单的路径可以解决,因此下面以Android端为例重点分析思路,大致如下图所示:
由上图可以得知,Android端 热修复核心步骤如下:
1, 修改Flutter Engine代码,加载指定路径的libapp.so和flutter_aasets,比如私有目录(data/data/files);
2, 编译APK时,利用Gradle Transform插件,根据Flutter SDK的engine version动态替换官方的Flutter engine,最终写入修改后的engine到APK;
3, 生成补丁包:利用BSdiff算法比较新旧APK文件,生成patch补丁包
4, APP启动时访问后端接口,根据参数(app的版本号,补丁包版本号,md5,flutter SDK版本号,Engine版本号)拉取补丁包;
5, 合成补丁包:校验md5,app版本号,补丁版本号,安装时间;
6, 自定义Flutter Engine加载指定路径的libapp.so和flutter_assets资源文件;
作者:京东科技 刘振中、周智
内容来源:京东云开发者社区

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
构建高可用云原生应用,如何有效进行流量管理?
摘要:对于那些希望使用华为云的云原生服务的人来说,这篇文章提供了很好的指导,让他们了解如何通过容错来保证他们的服务的可用性和稳定性。 本文分享自华为云社区《构建高可用云原生应用,如何有效进行流量管理?》,作者: breakDawn。 随着云原生的概念越来越火,服务的架构应该如何发展和演进,成为很多程序员关心的话题。大名鼎鼎的《深入理解java虚拟机》一书作者于21年推出了新作《凤凰架构》,从这本书中可以看到当前时下很多最新的技术或者理念。 因此本文以及后续都将持续沉淀发布这本书的学习笔记和思考,也欢迎购买该书进行详细学习,或者关注后续的学习笔记内容发布,了解精华内容和总结思考。 流量治理 1 服务容错 1.1 容错策略 文章中介绍了故障转移、快速失败、安全失败、沉默失败、故障恢复、并行调用、广播调用等几种容错策略,我用表格的形式直观呈现一下这几种策略的区别,方便理解和选型: 1.2 容错设计模式 1.断路器模式 即服务中发请求的地方都通过一个断路器模块来转发发送 当10秒内请求数量达到20,且失败阈值达到50%以上(这些参数都可以调整), 则认为出现问题, 于是主动进行服务熔断, 断路...
- 下一篇
Nodejs 应用编译构建提速建议 | 京东云技术团队
编译构建的整体过程 拉取编译镜像 拉取缓存镜像 拉取项目源码 挂载缓存目录 执行编译命令(用户自定义) 持久化缓存 上传编译镜像 为什么在本地构建就快, 但编译机上很慢 在编辑机上每次的构建环境都是全新的, 完成一次构建比本地需要多一些步骤: 现成的全局包缓存 VS 重新构建缓存: 咱可以先简单理解为咱使用 npm 的时候那个全局的缓存目录, 编辑机需要准备持久化的缓存的环境, 包括下载、挂载以重建缓存, 如果缓存内容过大, 时间也会相对更长, 本地构建直接使用了稳定的本地文件系统; 增量安装依赖 VS 全量安装依赖: 本地不太经常需要执行 install 的过程, 即使需要, 也因为有持久的 node_modules 目录存在, 不需要全量安装, 但编辑机环境每次需要重新安装这个项目需要的所有依赖; 增量构建 VS 全量构建: 本地构建默认会将构建缓存放到 node_modules 目录下, 第二次构建的时候这些构建就能被用起来, 使得后面的构建更快, 但这个构建的默认缓存位置在编辑机上不会被持久化, 也就是每次需要全量构建. 网络环境: 有些依赖包安装依赖外部网络甚至海外网络, 本...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2整合Redis,开启缓存,提高访问速度
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- MySQL8.0.19开启GTID主从同步CentOS8
- Mario游戏-低调大师作品
- Linux系统CentOS6、CentOS7手动修改IP地址
- Docker安装Oracle12C,快速搭建Oracle学习环境
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- CentOS7安装Docker,走上虚拟化容器引擎之路
- Docker快速安装Oracle11G,搭建oracle11g学习环境