什么是热修复?
热修复提出于2014年,兴起于2016年,尤其是在Instant run 问世以后,各种热修复技术相继涌出。
是一种摆脱传统发版方案直接使用补丁来更新app内容,不需要重新下载安装apk等略过一系列繁琐过程的新兴技术,目前国内部分成熟App都拥有自己的热修复技术,如:手淘、QQ、微信、美团、饿了么等。
热修复有什么优势&为什么要使用热修复?
来看一个场景:公司一个项目A在上线后发现一个严重bug如果不紧急修复可能导致用户流失,这种情况下如果是传统的app更新就很麻烦了大概是这个流程:
这期间重新发版涉及到提交测试环节,这样修复一个bug很不及时,如果使用热修复方案,它将变得很简单:
其优势为:
- 无需重新发版,简单高效
- 用户无感知,无需下载新应用,代价小
- 修复成功率高,挽回用户群体
热修复是如何工作的?
- 2017年6月手淘联合阿里云正式发布了新一代非侵入式Android热修复方案 - Sophix
它能修复:代码、资源、SO库,下图为Sophix与微信和饿了么热修复技术对比表
从表中我们能知道个大概,就是Sophix似乎更值得使用一下。
分别介绍QQ空间超级不定、微信Tinker和Sophix的前身HotFix各自的工作原理。
首先了解一下apk的执行过程:代码被编译Build后生成apk文件,其实在里面生成了一个classes.dex文件。
我们解压一个apk文件如下图:
这个classes.dex就是所有代码的集合,是一个可执行文件,android运行apk实质是解压apk运行里面的这个的dex文件。
apk首次运行的时候会对这个dex文件进行优化,优化后生成一个odex文件,存在于缓存中,下次再启动就直接打开这个odex文件,达到快速打开目的。而执行apk的过程就是遍历这个dex并作出相应操作的过程,遍历后的dex方法存放在一个Elements数组中,它的长度限制是65536.即日常说的65K.
如果我们apk因为太庞大或者是引用三方库太多导致方法数超过65K,就会报错.
而谷歌已经在Android 5.0开始支持Multdex.
在知道上面信息后,我们谈谈这三家的热修复是如何实现的
1.QQ空间超级补丁:基于DEX分包方案,使用了多DEX加载的原理,大致的过程就是:把BUG方法修复以后,放到一个单独的DEX里,插入到dexElements数组的最前面,让虚拟机去加载修复完后的方法。
当patch.dex中包含Test.class时就会优先加载,在后续的DEX中遇到Test.class的话就会直接返回而不去加载,这样就达到了修复的目的.
2.微信Tinker:微信针对QQ空间超级补丁技术的不足提出了一个提供DEX差量包,整体替换DEX的方案。主要的原理是与QQ空间超级补丁技术基本相同,区别在于不再将patch.dex增加到elements数组中,而是差量的方式给出patch.dex,然后将patch.dex与应用的classes.dex合并,然后整体替换掉旧的DEX文件,以达到修复的目的。
3.AndFix:不同于QQ空间超级补丁技术和微信Tinker通过增加或替换整个DEX的方案,提供了一种运行时在Native修改Filed指针的方式,实现方法的替换,达到即时生效无需重启,对应用无性能消耗的目的。
AndFix与HotFix的关系如下:
AndFix实现原理:
AndFix实现过程:
更详细的说明戳这里:三大流派之简单对比
阿里云Sophix热修复之简单使用
Sophix集成示例:
第一步:找到Project的build.gradle文件,在allProjects节点下加上如下代码:
repositories {
maven { url"http://maven.aliyun.com/nexus/content/repositories/releases"}
}
第二步:找到Module的build.gradle文件,添加依赖:
compile'com.aliyun.ams:alicloud-android-hotfix:3.0.7'
然后同步project
第三步:添加权限,SDK使用到以下权限
<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
<uses-permission android:name="android.permission.ACCESS_WIFI_STATE" />
<!--<! -- 外部存储读权限,调试工具加载本地补丁需要 –>-->
<uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE"/>
READ_EXTERNAL_STORAGE/ACCESS_WIFI_STATE 权限属于Dangerous Permissions,自行做好android6.0以上的运行时权限获取
第四步:密钥等配置,在application节点下加入以下配置:
<meta-data
android:name="com.taobao.android.hotfix.IDSECRET"
android:value="App ID" />
<meta-data
android:name="com.taobao.android.hotfix.APPSECRET"
android:value="App Secret" />
<meta-data
android:name="com.taobao.android.hotfix.RSASECRET"
android:value="RSA密钥" />
第五步:登录阿里云热修复管理控制台,填入对应3个value
第六步:代码集成
在Application的attachBaseContext方法里加入Sophix初始化
@Override
protected void attachBaseContext(Context base) {
super.attachBaseContext(base);
SophixManager.getInstance().setContext(this)
.setAppVersion(getAppVersion())
.setAesKey(null)
.setEnableDebug(true)
.setPatchLoadStatusStub(new PatchLoadStatusListener() {
@Override
public void onLoad(final int mode, final int code, final String info, final int handlePatchVersion) {
// 补丁加载回调通知
if (code == PatchStatus.CODE_LOAD_SUCCESS) {
// 表明补丁加载成功
} else if (code == PatchStatus.CODE_LOAD_RELAUNCH) {
// 表明新补丁生效需要重启. 开发者可提示用户或者强制重启;
// 建议: 用户可以监听进入后台事件, 然后应用自杀
} else if (code == PatchStatus.CODE_LOAD_FAIL) {
// 内部引擎异常, 推荐此时清空本地补丁, 防止失败补丁重复加载
SophixManager.getInstance().cleanPatches();
} else {
// 其它错误信息, 查看PatchStatus类说明
}
}
}).initialize();
}
@Override
public void onCreate() {
super.onCreate();
......
// queryAndLoadNewPatch不可放在attachBaseContext 中,否则无网络权限,建议放在后面任意时刻,如onCreate中
SophixManager.getInstance().queryAndLoadNewPatch();
}
自此SDK的集成已经差不多完成,官方给出了很详细的集成方法,官方集成文档