Android 热修复技术

介绍

2015年以来，Android开发领域里对热修复技术的讨论和分享越来越多，同时也出现了一些不同的解决方案，如QQ空间超级补丁方案、阿里AndFix以及微信Tinker，它们在原理上各有不同，适用场合也各有差异。

QQ空间超级补丁技术和微信Tinker是通过增加或替换整个DEX的方案，可参考QQ空间团队的 安卓App热补丁动态修复技术介绍 。而阿里AndFix提供了一种运行时在Native修改Filed指针的方式，实现方法的替换。

下面是对热修复技术三大流派的一个对比：Android热修复技术选型——三大流派解析。

Sophix 集成

阿里AndFix是Android HotFix的简称，目前已经更新到3.0版本，3.0有了一个新的名字—Sophix。很遗憾Sophix是收费的，但是每个账号，每月有5万台设备免费。Sophix产品文档见帮助与文档。下面我把Sophix的集成过程总结一下。

（1）创建应用
登录移动热修复控制台：https://hotfix.console.aliyun.com/，创建需要热修复的应用，创建成功后，会获取应用的基本信息，其中有三个非常重要，后面会使用到：AppId、AppSecret、RSASecret。

（2）gradle远程仓库依赖, 打开项目找到app的build.gradle文件，添加如下配置：
添加maven仓库地址：

repositories {
   maven {
       url "http://maven.aliyun.com/nexus/content/repositories/releases"
   }
}

添加gradle坐标版本依赖：

compile 'com.aliyun.ams:alicloud-android-hotfix:3.1.0'

权限说明：

    <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以上的运行时权限获取。

配置AndroidManifest文件：
在AndroidManifest.xml中间的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密钥" />

将上述value中的值分别改为通过平台HotFix服务申请得到的App Secret和RSA密钥，出于安全考虑，建议使用setSecretMetaData这个方法进行设置。

混淆配置：

/**#基线包使用，生成mapping.txt
-printmapping mapping.txt
/**#生成的mapping.txt在app/buidl/outputs/mapping/release路径下，移动到/app路径下

/**#修复后的项目使用，保证混淆结果一致
#-applymapping mapping.txt

/**#hotfix
-keep class com.taobao.sophix.**{*;}
-keep class com.ta.utdid2.device.**{*;}
/**#防止inline
-dontoptimize

SDK接入：

public class MyApp extends Application {

    @Override
    public void onCreate() {
        super.onCreate();
        initHotfix();
        SophixManager.getInstance().queryAndLoadNewPatch();
    }

    private void initHotfix() {
        String appVersion;
        try {
            appVersion = this.getPackageManager().getPackageInfo(this.getPackageName(), 0).versionName;
        } catch (Exception e) {
            appVersion = "1.0";
        }

        SophixManager.getInstance().setContext(this)
                .setAppVersion(appVersion)
                .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) {
                            // 表明新补丁生效需要重启. 开发者可提示用户或者强制重启;
                            // 建议: 用户可以监听进入后台事件, 然后调用killProcessSafely自杀，以此加快应用补丁，详见1.3.2.3
                        } else {
                            // 其它错误信息, 查看PatchStatus类说明
                        }
                    }
                }).initialize();
    }
}

更多接口说明请参考Sophix说明文档。

（3）修改代码，生成补丁包
我们这里修改的内容很简单，点击Button弹出Toast，之前弹出的内容为“I am the previous version!”，我们修改为“I am the modified version!”。

Windows版本打包工具地址：http://ams-hotfix-repo.oss-cn-shanghai.aliyuncs.com/SophixPatchTool_windows.zip
图形化操作工具，输入新旧APK的路径和目标路径即可，不多说了。

（4）上传补丁包到控制台
说明一：patch是针对客户端具体某个版本的，patch和具体版本绑定。
eg. 应用当前版本号是1.1.0, 那么只能在后台查询到1.1.0版本对应发布的补丁, 而查询不到之前1.0.0旧版本发布的补丁。所以一定要将patch发布到基线包版本。

说明二：针对某个具体版本发布的新补丁, 必须包含所有的bugfix, 而不能依赖补丁递增修复的方式, 因为应用仅可能加载一个补丁。
eg. 针对1.0.0版本在后台发布了一个补丁版本号为1的补丁修复了bug1, 然后发现此时针对这个版本补丁1修复的不完全, 代码还有bug2, 在后台重新发布一个补丁版本号为2的补丁, 那么此时补丁2就必须同时包含bug1和bug2的修复才行, 而不是只包含bug2的修复(bug1就没被修复了)。所以一定要将最新版本和基线包版本做差分包。

好了，待patch发布再过一段时间，我们再打开应用，发现bug已经被修复了。

Demo下载地址

Tinker 集成

上面也提到了，Sophix目前已经进入收费阶段。如果要使用开源方案呢？QZone方案对性能会有一定的影响，且在ART模式下会出现内存错乱的问题，美团提出的思想方案主要是基于Instant Run的原理，目前尚未开源。如果选择开源方案，tinker目前是最佳的选择，tinker的介绍有这么一句：

Tinker已运行在微信的数亿Android设备上，那么为什么你不使用Tinker呢？