带你不到80行代码搞定Flutter热更新
- 2019 年 11 月 1 日
- 笔记
一、需要热更新的背景
Flutter作为跨平台方案,相信最近很多小伙伴都已经开始接入了,我们的接入参考官方wiki,在成功接入之后,我们为了在CI构建中不依赖fluter环境,采用了调试模式使用源码的方式,打包的时候使用aar的方式,这样做的好处是,既能够保留开发期间的可调试行,也能保障构建环境不依赖Flutter环境。为此,我们团队双端各写了一个脚本,来切换接入模式,且自动将Flutter产物提提取并推送到原生工程以便打包。成功上线几个业务之后,我们遇到flutter的线上问题,大家可能和我当时的感受一样,没有一个比较好的开源工具来对Flutter进行热修复,在网上搜一下,如这篇,大多数表示只讲解原理,看原理理论上是行得通的,但是遗憾的是并没有具体实现过程,于是我们决定立足原理,来探索在Android上怎么实现Flutter页面的热更新,以下是热更新实现后的效果:
![](https://ask.qcloudimg.com/http-save/1203298/x9vo75mee8.gif)
![](https://ask.qcloudimg.com/draft/1203298/urpk2xbho1.png)
我们的第三个tab是一个Flutter实现的页面,可以看到这个页面中,banner的 福利券兑好礼 文案被替换了,那么我们是如何做到的呢?
二,实现热更新之路的探索
要热更新flutter页面,我们首先要搞明白我们到底需要动态替换一些什么?因此这里需要对flutter构建的产物有一定的了解了,怕有些小伙伴不太明白,这里也简单的带一下。
![](https://ask.qcloudimg.com/draft/1203298/pyyzltm490.png)
如上图所示,实际上,我们只需要copy一些aar文件,so文件到native工程lib目录,就可以已aar的方式来跑Flutter的页面了,这也是典型的已aar方式接入Flutter的模式。其中,libapp.so,注意在armeabi中没有,如果你的gralde配置这么写的,abiFilters "armeabi" 那么,copy armeabi-v7a下面的so到armeabi中,也是没有任何问题的,关于构建产物提取到原生工程就介绍到这里。
那么,问题来了,如果我们的Flutter页面出来bug,比如,某个文案写错了,而且是写死的,某个控件在小屏机型上溢出了,没动态计算宽高等等等,我们怎么办?
当然是进行热修复了,那么热修复,我们要提供那些文件出来呢,都需要提供吗?
答案是,并不需要都提供,如果是逻辑问题,而且这是我们大概率会遇到的问题,切发生的最多的线上问题,并不涉及到资源的话,我们只需要替换libapp.so即可实现热更新。
说到这里,有人说,tinker好像具备修复so的功能吧,可已不可以直接使用tinker呢?
答案是,并不能直接使用tinker,因为Flutter有自己的一套so加载流程,如下图,换句话说,tinker使用热修复后的so替换之前的so,Flutter不感知,因为它自己的环境会依然去读哪个没有修复的so。
![](https://ask.qcloudimg.com/draft/1203298/9bhyn9b4ri.png)
所以,我们该怎么办呢?
1、既然我们知道只要替换so既可以实现Flutter逻辑错误的修复,那么我们自己写一个管理端,下发需要替换的so即可呀,好像行得通,嗯,但是,这样会涉及到补丁版本的管理,客户端补丁下载管理,而且因为libapp.so会比较大,我们目前就一两个页面,就8M多了,因此我们也需要做差分,然后下发到客户端之后在合并出功能修复的so,好像理论上完全是OK的,不过等下,还有更好的吗的方案吗?
2、我了解到tinker,貌似是可以修复so的,而且王者人生Android端目前原生就是使用tinker来做热修复的,那么,我们是否可以对tinker这个进行利用呢,我们在前面就知道,tinker虽然具备修复Android原生so的问题,但是不能直接用来修复flutter,但是,如果我们利用tinker的热修复,将我们需要修复的libapp.so送达客户端,然后,我们想办法找到这个so,在想办法hook 以上Flutter加载 libapp.so,换句话说,就是想办法让flutter加载tinker为我们准备好的热修复后的so。
很幸运,这个猜想最终被成功实施出来了。
三,具体实现的细节
实现起来非常简单:
首先,我们在原生Android工程接入tinker,具体接入流程参考bugly文档即可。
其次,我们怎么去拿到tinker为我们生成的那个修复后的libapp.so,并且偷梁换柱呢,答案是:
package com.xxx.xxx.common.utils; import android.content.Context; import android.util.Log; import com.xxx.xxx.MyApplication; import com.tencent.tinker.lib.tinker.Tinker; import com.tencent.tinker.lib.tinker.TinkerLoadResult; import com.tencent.tinker.lib.util.TinkerLog; import com.tencent.tinker.loader.shareutil.ShareConstants; import com.tencent.tinker.loader.shareutil.SharePatchFileUtil; import java.io.File; import java.lang.reflect.Field; import io.flutter.view.FlutterMain; /** * flutter 热更新 * create by brzhang * date 2019.10.24 */ public class FlutterPatch { private static final String TAG = "FlutterPatch"; private FlutterPatch() { } public static void flutterPatchInit() { try { String libPath = findLibraryFromTinker(MyApplication.getIGameApplicationContext(), "lib/armeabi", "libapp.so"); Log.e("FlutterPatch", "flutterPatchInit() called " + libPath); Field field = FlutterMain.class.getDeclaredField("sAotSharedLibraryName"); field.setAccessible(true); field.set(null, libPath); } catch (Exception e) { e.printStackTrace(); } } public static String findLibraryFromTinker(Context context, String relativePath, String libName) throws UnsatisfiedLinkError { final Tinker tinker = Tinker.with(context); libName = libName.startsWith("lib") ? libName : "lib" + libName; libName = libName.endsWith(".so") ? libName : libName + ".so"; String relativeLibPath = relativePath + "/" + libName; if (tinker.isEnabledForNativeLib() && tinker.isTinkerLoaded()) { TinkerLoadResult loadResult = tinker.getTinkerLoadResultIfPresent(); if (loadResult.libs == null) { return libName; } for (String name : loadResult.libs.keySet()) { if (!name.equals(relativeLibPath)) { continue; } String patchLibraryPath = loadResult.libraryDirectory + "/" + name; File library = new File(patchLibraryPath); if (!library.exists()) { continue; } //whether we check md5 when load boolean verifyMd5 = tinker.isTinkerLoadVerify(); if (verifyMd5 && !SharePatchFileUtil.verifyFileMd5(library, loadResult.libs.get(name))) { tinker.getLoadReporter().onLoadFileMd5Mismatch(library, ShareConstants.TYPE_LIBRARY); } else { // System.load(patchLibraryPath); TinkerLog.i(TAG, "findLibraryFromTinker success:" + patchLibraryPath); return patchLibraryPath; } } } return libName; } } //然后在你的application 的 onCreate中调用 Flutter.startInitialization(this); FlutterPatch.flutterPatchInit();
嗯,不到80行代码就搞定了Flutter热更新了,当然我这里只写了armeabi架构的,这是因为我们项目只需要这个架构,如果你的项目有多种,这里需针对性修改一下,最后可以看一下
![](https://ask.qcloudimg.com/draft/1203298/t200mdoprv.png)
当tinker下发补丁成功之后,我们的应用data/data目录会有这个生成这个libapp.so的补丁了。然后使用上面的代码去偷梁换柱即可实现修复了。而且可以看一下,补丁的大小因为tinker做了查分包的缘故,会远远小于8M
![](https://ask.qcloudimg.com/draft/1203298/w93v57k77.png)
那么,对比下两种方案
方案对比 |
自己开发 |
基于tinker |
---|---|---|
需要自己写补丁下载逻辑 |
是 |
否 |
补丁大小 |
比较大 |
小 |
需要自己开发管理端 |
需要 |
不需要 |
是要自己写补丁合成逻辑 |
需要 |
不需要 |
稳定性 |
需要验证 |
很稳定 |
成本 |
很高 |
低 |
写在最后,我们的Android端Flutter环境目前是
Flutter 1.9.1+hotfix.6 • channel stable •
如果想了解flutter打包脚本的小伙伴,可以翻看我之前的文章,或者留言。