当一个App发布之后，若发现一个严重bug需要进行紧急修复，这时候大家就开始手忙脚乱了，需要重新打包App、测试、向各个发布市场替换新包并提示用户升级。有时候修复bug可能只改动几行代码，但造成的影响是非常恶劣的。
App热补丁方案可以实现在线修复bug,以补丁的方式动态修复紧急Bug，成功避开了上面的重新打包测试并替换市场包的繁杂过程。
本文主要简单介绍热补丁的测试过程及方法。
（一）代码工程配置
1）在项目根目录的build.gradle中添加classpath依赖。
2）如果在APP的manifest的里面注册的Application类不是继承自android.app.Application/android.support.multidex.MultiDexApplication,则还需要在build.gradle中排除所用Application的父类
如:manifest里面注册的是App类,App类继承自AbsApp1,AbsApp1继承自AbsApp2,AbsApp2继承自android.app.Application,则build.gradle添加排除代码
hotfix{
excludeClass = ['AbsApp1.class', 'AbsApp2.class']
}
（二）热补丁测试过程
1）react_native目录下执行npm run build_android，将RN代码打包进apk。（这样app中的RN页面就不再会是空白页面了。
2）修改native代码，测试热补丁首先需要的是打有bug的apk。所以首先修改代码，制造bug。
制造bug示例：
示例一：登录按钮制造crash
登录模块的Activity中
@Override
public void onClick(View v) {
......
} else if (id == R.id.login_btn_login) {//登录按钮
/*************热补丁测试代码:制造crash**************/
Object nullObject = null;
Toast.showBottom(this,"制造crash");
nullObject.toString();
/*************热补丁测试代码:制造crash***************/
……
}
}
......
}
示例二： 注册按钮制造错误跳转，跳转找回密码
登录模块的Activity中
@Override
public void onClick(View v) {
......
} else if (id == R.id.login_btn_register_account) {
/**************热补丁测试代码:跳转错误页面*******************/
boolean test = true;
if(test){
Toast.showBottom(this,"跳转错误页面");
startActivity(new Intent(this,FindMyPasswordActivity.class));
return;
}
/**************热补丁测试代码:跳转错误页面*******************/
……
}
}
3）制造完bug后，在APP根目录下首先执行./gradlew clean；然后执行./gradlew build（或执行./gradlew assembleRelease或简写版命令./gradlew aR）。能看到在运行模块的build/outputs/apk/下面生成了xxx-release-unsigned.apk。此包未签名。
4）步骤3执行完成后，能看到在运行模块的build/outputs目录下同时也生成了一个hotfix目录。拷贝此目录到另一个地方保存。如拷贝hotfix目录到/home/work/hotfixdir/下面。此目录的信息在后面的生成补丁包命令中会用到。
5）在某个目录下生成签名文件，后面需要利用此签名文件对apk及补丁包签名。注意，对apk及补丁包的签名文件必须是一致的。如在目录/home/work/signdir下生成签名文件，可以直接在此目录下执行命令：keytool -genkey -alias mykey -keyalg RSA -validity 40000 -keystore demo.keystore
6）签名apk。将步骤3生成的xx-release-unsigned.apk拷贝到/home/work/signdir目录下。在此目录下对apk签名可以直接在该目录下执行: jarsigner -verbose -keystore demo.keystore -digestalg SHA1 -sigalg MD5withRSA -signedjar signed.apk ./xx-release-unsigned.apkmykey
其中signed.apk就是签名后的apk，文件名可以随便取。这里取名为signed.apk。
7）打补丁包。首先是修改native的代码，需要的效果是应用此补丁包后能看到app发生了变化。我们真正目的是为了解决发出去的app的bug才打的补丁包。
所以，如果是参考步骤2在native中制造的bug，只需要将制造bug的代码注释掉就可以啦。注释掉后（认为bug已经通过代码修复了）就可以打补丁包了。在工程的根目录下执行：./gradlew clean hotfixReleasePatch -P HotFixDir=/home/work/hotfixdir/hotfix（HotFixDir的值要根据你第4步实际存放的hotfix目录来填写）。可以看到在运行模块的build/outputs/hotfix/release目录下生成了patch.jar。此patch.jar就是补丁包。
8）签名补丁包。将补丁包拷贝到步骤5中生成的签名文件所在的目录。如将patch.jar包放到/home/work/signdir目录下。并利用此目录下的demo.keystore对补丁包签名。签名补丁包与第6步中的签名apk方法一样，直接在该目录下执行： jarsigner -verbose -keystore demo.keystore -digestalg SHA1 -sigalg MD5withRSA -signedjar signed_patch.jar./patch.jarmykey
其中，signed_patch.jar就是签名后的补丁包，文件名可以随便取。这里取名为signed_patch.jar
9）在后台管理平台上传补丁包。切记，补丁包是针对某个app版本的。如果要修复app 2.0.0版本的bug，则补丁包上传时一定要选择app版本是2.0.0。此补丁包只对2.0.0.版本的app生效。
10）下载补丁包。补丁包下载时的临时存放目录在/storage/emulated/0/包名/download.patch_tmp。下载过程中可以看到如下日志：
………………
07-11 16:00:06.069 I/FSTANDARD-HFDownloadTask( 1855): 成功重命名临时文件/storage/emulated/0/com_xxx_xxx/download.patch_tmp->/storage/emulated/0/com_xxx_xxx/download.patch。
………………
下载过程中生成download.patch_tmp，下载完成后重命名该文件为download.patch。download.patch经过AES解密后重命名为download_decode.patch，该文件如果通过了MD5校验和APK签名校验（所用的签名文件与安装的apk用的签名文件一致）则该文件会被拷贝到 data/data/包名/files/hotfixopt/目录下，并重命名为patch.apk。同时也会删除掉临时补丁目录的download_decode.patch这个文件。若md5校验不通过或签名校验不通过（此补丁包的签名文件与apk的签名文件不一致）则直接删除download_decode.patch文件。
11）应用补丁包
通过第10步的下载补丁包及签名校验，可以看到在/data/data/包名/files/hotfixopt目录下有两个文件hfhotfix.apk和patch.apk。
root@android:/data/data/包名/files/hotfixopt # ls
hfhotfix.apk
patch.apk
hfhotfix.apk文件可以认为是一个默认的补丁包，是为了防止app里用到的所有类被优化、保证所有类在应用热补丁时可以被成功替换。app里面所有类都引用了hfhotfix.apk里的一个对应的类，而hfhotfix.apk里的这个类是个空类，没有任何代码，这样该类就会被其他dex里的类替换。真正的需要被应用的补丁包是patch.apk。如果此时破坏掉patch.apk，会发现补丁包不会被应用了。即使是应用完补丁包后再破坏掉patch.apk，会发现重启app后之前应用的补丁就失效了，app又回到了应用补丁前的状态。（当然此时又会再次检测到后台的补丁包）
当然，需要重启app才会看到补丁包应用生效。重启app后，可以看到补丁包已经生效了，此时，查看/data/data/包名/files/hotfixopt这个 目录，可以看到多了两个文件，patch.dex和hfhotfix.dex。这两个文件是应用补丁包过程中产生的。
