热修复
目前国内Android热修复技术已经发展的可以说百花齐放了,从实现方式来大致分类,可以分为: ① Native层实现 ② Java层实现
之前有简单分析过阿里开源的Andfix实现原理(基于Native层),详见Android_热修复_Andfix原理分析,这里就多说了,感兴趣的可以看下
本文简单分析一下Java层实现热修复逻辑,简单实现代码热修复Demo,以Tinker为例(当然Tinker是支持代码修复,资源修复,so修复的,感兴趣的小伙伴自行移步官网~)
先梳理下思路:
Java类编译过程
就是java类通过javac编译成.class文件,再由dx.bat编译成.dex文件的过程,不做赘述,简单画张图~
ClassLoader简介
Android中的java.lang.ClassLoader这个类也不同于Java中的java.lang.ClassLoader。 Android中的ClassLoader类型也可分为系统ClassLoader和自定义ClassLoader。其中系统ClassLoader包括3种分别是：
BootClassLoader，Android系统启动时会使用BootClassLoader来预加载常用类，与Java中的Bootstrap ClassLoader不同的是，它并不是由C/C++代码实现，而是由Java实现的。BootClassLoader是ClassLoader的一个内部类。PathClassLoader，全名是dalvik/system.PathClassLoader，可以加载已经安装的Apk，也就是/data/app/package 下的apk文件，也可以加载/vendor/lib, /system/lib下的nativeLibrary。DexClassLoader，全名是dalvik/system.DexClassLoader，可以加载一个未安装的apk文件。 PathClassLoader和DexClasLoader都是继承自 dalviksystem.BaseDexClassLoader，它们的类加载逻辑全部写在BaseDexClassLoader中。 下图展示了Android中的ClassLoader中的继承体系，其中SecureClassLoader和UrlClassLoader是在Java中的类加载器，在Android中是没法办使用的。
.dex文件加载
通过源码得知,.dex文件是通过BaseDexClassLoader类(ClassLoader的子类)进行加载的,这个类里面有个成员变量DexPathList对象,而这个对象中有个有个数组存放的是DexElement对象,也就是从文件中加载的.dex文件,切入点就在这里,对于项目来说,一般项目会分包(方法数大于64k,及大于65535个时候,google提供的分包策略),如果采用Java代码实现热修复,分包是肯定要做的,因为要保证主包没有bug,分包简单说就是打包的apk一般有多个.dex文件,如 classes.dex,classes2.dex 等等...
那么比如我们的classes2.dex中某个类的某个方法出现了异常,我们就可以创建一个修复包(修复后的classes2.dex文件),然后通过自定义的类加载器将修复后的classes2.dex文件copy到私有目录,再插队到系统ClassLoader的dexPathList对象的dexElement的数组中,让系统优先加载修复后的classes2.dex文件,以做到热修复的目的,这种实现方式必须要执行修复逻辑后,重启app才能实现效果~
了解了这些信息大致思路就有了,我们需要修复后的.dex文件加载解析,然后插队旧的安装包装的.dex文件,做到插队的操作,相当于欺骗了Android系统,大致如下:
实现原理
思路大概是,我们需要一个修复bug的.dex文件,插队到BaseDexClassLoader类下的DexPathList对象的DexElement数组中,并且排序到最前面,让系统加载到我们修复后的.dex文件不会再加载有bug的dex文件,完成插队(插装),这里会有个类加载机制的知识,本文不做详细介绍,后面会单独写一篇总结~
大致实现步骤如下:
Demo实现
#####① 基础配置-主包配置
配置分包,配置分包的目的主要是打包做出来的apk会有多个.dex文件,实际项目应用中要保证主包不要有bug,demo中加载.dex文件的时候也排除了主包文件classes.dex,大致如下:
创建BaseApplication,BaseActivity,MainActivity放置在主包,其中MainActivity主要是为了分包占位,只做了点击跳转分包中SecondActivity的逻辑
app目录下的build.gradle开启分包支持,在android→defaultConfig下增加配置,其中multiDex-config.txt是配置保留在主包内类文件
//开启分包
multiDexEnabled true
//分包的配置,将配置文件中的放置在主包
multiDexKeepFile file("multiDex-config.txt")
添加分包依赖:
//multidex分包依赖
implementation 'com.android.support:multidex:1.0.3'
Application开启分包:
public class BaseApplication extends MultiDexApplication {
@Override
public void onCreate() {
super.onCreate();
}
@Override
protected void attachBaseContext(Context base) {
super.attachBaseContext(base);
//安装分包配置
MultiDex.install(this);
}
}
② 分包配置
分包就创建了一个SecondActivity类做模拟异常和修复异常的入口,和一个Calculate模拟异常,做了10/0的操作,修复后为10/1
注:获取修复后的classes2.dex文件可以通过直接buildapk直接解压获取,或者用build-tools下的dx.bat执行命令获取,这篇文章中提及: Android_热修复_Andfix原理分析
简单贴下SecondActivity,点击fix按钮后的代码,完整代码见文末~:
private void update() {
//将下载的修复包,复制到私有目录,解压从.dex文件中取到对应的.class文件
//从sd卡取修复包
File sourceFile = new File(Environment.getExternalStorageDirectory(), Constants.DEX_NAME);
//目标文件
File targetFile = new File(getDir(Constants.DEX_DIR, Context.MODE_PRIVATE).getAbsolutePath() + File.separator + Constants.DEX_NAME);
if (targetFile.exists()) {
targetFile.delete();
Log.e("update","删除原有dex文件(已使用的)");
}
//将SD卡中的修复包copy到私有目录
FileUtils.copyFile(sourceFile,targetFile);
Log.e("update","copy完成");
FixDexUtils.loadDexFile(this);
}
③FixModule
新建一个Module处理热修复的相关逻辑
只有五个文件,核心文件代码在FixDexUtils,其它是工具类,还有个定义了几个常量
看下FixDexUtils中的代码
public class FixDexUtils {
//修复文件可能有多个
private static HashSet<File> loadedDex = new HashSet<>();
//不建议这么写,demo演示用
static {
loadedDex.clear();
}
public static void loadDexFile(Context context) {
//获取私有目录
File fileDir = context.getDir(Constants.DEX_DIR, Context.MODE_PRIVATE);
//遍历筛选私有目录中的.dex文件
File[] listFiles = fileDir.listFiles();
for (int i = 0; i < listFiles.length; i++) {
//文件名以.dex结尾,且不是主包.dex文件
if (listFiles[i].getName().endsWith(Constants.DEX_SUFFIX) && !"classes.dex".equalsIgnoreCase(listFiles[i].getName())) {
loadedDex.add(listFiles[i]);
}
}
//创建自定义的类加载器
createDexClassLoader(context ,fileDir);
}
/**
* @param context
* @param fileDir
* 创建自己的类加载器,加载私有目录的.dex文件,上面已经将修复包中的dex文件copy到私有目录
*/
private static void createDexClassLoader(Context context, File fileDir) {
//解压目录
String optimizedDir = fileDir.getAbsolutePath()+File.separator+"opt_dex";
File fileOpt = new File(optimizedDir);
if (!fileOpt.exists()) {
fileOpt.mkdirs();
}
for (File dex : loadedDex) {
//创建自己的类加载器,临时的
DexClassLoader classLoader = new DexClassLoader(dex.getAbsolutePath(), optimizedDir, null, context.getClassLoader());
//有一个修复文件,就插装一次
hotFix(classLoader,context);
}
}
private static void hotFix(DexClassLoader classLoader, Context context) {
try {
//获取系统的PathClassLoader类加载器
PathClassLoader pathClassLoader = (PathClassLoader)context.getClassLoader();
//获取自己的dexElements数组
Object myElements = ReflectUtils.getDexElements(ReflectUtils.getPathList(classLoader));
//获取系统的dexElements数组
Object systemElements = ReflectUtils.getDexElements(ReflectUtils.getPathList(pathClassLoader));
//合并数组,并排序,生成一个新的数组
Object dexElements=ArrayUtils.combineArray(myElements,systemElements);
//通过反射获取系统的pathList属性
Object systemPathList = ReflectUtils.getPathList(pathClassLoader);
//通过反射,将合并后新的dexElements赋值给系统的pathList
ReflectUtils.setFieldValue(systemPathList,"dexElements",dexElements);
}catch (Exception e){
e.printStackTrace();
}
}
}
主要做的工作就是:就是上面那张流程图,就是先通过遍历,解压等操作,获取到需要执行热修复的.dex文件集合,遍历该集合,对应每次创建一个临时的DexClassLoader,然后执行修复步骤,细分就是六步:
最终实现效果如图(Demo使用手机是华为8.0的手机):
注:这里为了效果图更直观,已经重启过一次app
注: 这种方式实现的热修复必须要重启App才可以实现修复,这一点也是类加载机制决定的,如下图中修复之后再次打开加载执行修复后的classes.dex文件是在BaseApplication中调用了修复方法,详见完整代码
