Android热更新之初探
什么是热修复？
热修复提出于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的集成已经差不多完成，官方给出了很详细的集成方法，官方集成文档
第七步：生成热修复补丁
我们直接看官方文档这里面写的很详细，细到每个设置每个参数都有说明
第八步：调试并发布补丁
首先我们需要上传补丁到阿里云管理后台，点此查看详细操作
接下来是对补丁的调试，点此查看详细操作
调试没毛病后，发布补丁，参考管理后台使用说明的step5
查看我自己的Demo数据
