Android热更新详解

一 前言介绍

正好最近又看到热更新,对以前Android 热修复核心原理:ClassLoader类加载机制做了点补充。

从16年开始开始,热修复技术开始在安卓界流行,它以classloader类加载机制为核心,可以不发布新版本就修复线上 bug ,让线上版本有能力去进行全量或者增量更新。

常见的思路有两种:

  1. 类加载方案,即 dex 插桩。该方案以腾讯系为主,包括微信的 Tinker、饿了么的 Amigo;

  2. 底层替换,即修改替换 ArtMethod。方案以阿里系的 AndFix 等为主;

本文主要介绍第一种方案。

1.1 ART 和 Dalvik

  1. Dex :全称为Dalvik Executable Format,由很多 .class 文件处理压缩后的产物,最终可以在 Android 运行时环境执行。它适合于内存和处理器速度有限的系统。

  2. Dalvik:Google设计的Android平台的Java虚拟机。支持转换为.dex格式的Java程序运行。DVM默认使用CMS垃圾回收器。

  3. ART:Android Runtime,于Android 4.4 引入,在 Android 5.0 及更高版本作为默认的 Android 运行时。ART做出的具体改进可看安卓官方文档介绍:运行时:Android Runtime (ART) 和 Dalvik。ART 和 Dalvik 都是运行 Dex 字节码的兼容运行时,因此 ART 向下兼容Dalvik 开发的应用。

  4. AOT:ART在应用安装的时候预编译字节码到机器语言,这一机制叫Ahead-Of-Time(AOT)预编译。执行该操作后,应用程序安装会变慢,但是执行将更有效率,启动更快。

1.2 dexopt与dexaot

  1. dexopt:Dalvik虚拟机加载dex文件时,会对 dex 文件进行验证和优化,得到odex(Optimized dex) 文件。odex文件只是对dex文件使用了一些优化操作码。

  2. dex2oat:dex或者odex文件经过 AOT 预编译,即得到OAT(实际上是ELF文件)可执行文件(机器码)。(相比做过odex优化,未做过优化的dex转换成OAT要花费更长的时间)

Android热更新详解_第1张图片

1.3 ART 和 Dalvik 对比

  1. 在Dalvik下,应用运行需要解释执行,常用热点代码通过即时编译器(JIT)将字节码转换为机器码,运行效率低。而在ART 环境中,应用在安装时,字节码预编译(AOT)成机器码,安装慢了,但运行效率会提高。

  2. ART占用空间比Dalvik大(字节码变为机器码), “空间换时间"。

  3. 预编译也可以明显改善电池续航,因为应用程序每次运行时不用重复编译了,从而减少了 CPU 的使用频率,降低了能耗。

二 ClassLoader

2.1 Android运行流程

Android程序编译的时候,会将.java文件编译时.class文件,然后将.class文件打包为.dex文件。Android程序运行时,Android的Dalvik/ART虚拟机就会加载.dex文件从中获得.class文件到内存中来使用。

2.2 类加载工具ClassLoader

任何 Java 程序都是由一个或多个 class 文件组成,在程序运行时,需要通过 Java 的类加载机制将 class 文件加载到 JVM 中才可以使用。Java程序启动时不会一次性加载所有类,而是先把保证运行的基础类加载到jvm,其它类要用时再加载。这样的好处是节省了内存的开销,用时再加载这也是java动态性的一种体现。

这些类的加载就是通过ClassLoader来的,每个 Class 对象的内部都有一个 classLoader 字段来标识自己是由哪个 ClassLoader 加载的。安卓的ClassLoader小改了java的ClassLoader

class Class<T> {
     
  ...
  private transient ClassLoader classLoader;
  ...
}

常见的Android类加载器有如下四种:

  1. BootClassLoader :加载Android Framework层中的class字节码文件(类似java的BootstrapClassLoader)
  2. PathClassLoader :只能加载已经安装到Android系统中的Apk的 class 字节码文件,是Android默认使用的类加载器;(类似java的 AppClassLoader )
  3. DexClassLoader :可以加载加载制定目录的dex/jar/apk/zip文件文件(类似java中的 Custom ClassLoader ),比 PathClassLoader 更灵活,是实现热修复的重点;
  4. BaseDexClassLoader : PathClassLoader 和 DexClassLoader 的父类
Log.e(TAG, "Activity.class 由:" + Activity.class.getClassLoader() +" 加载");
Log.e(TAG, "MainActivity.class 由:" + getClassLoader() +" 加载");

//输出:
Activity.class 由:java.lang.BootClassLoader@b1202a1 加载
MainActivity.class 由:dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/com.enjoy.enjoyfix-1/base.apk"],nativeLibraryDirectories=[/data/app/com.enjoy.enjoyfix-1/lib/x86, /system/lib, /vendor/lib]]] 加载

它们之间的关系如下:

Android热更新详解_第2张图片

public class DexClassLoader extends BaseDexClassLoader {
     
	
    public DexClassLoader(String dexPath, String optimizedDirectory,
		String librarySearchPath, ClassLoader parent) {
     
		super(dexPath, new File(optimizedDirectory), librarySearchPath, parent);
	}
}
 
public class PathClassLoader extends BaseDexClassLoader {
     
 
    public PathClassLoader(String dexPath, ClassLoader parent) {
     
        super(dexPath, null, null, parent);
    }
 
	public PathClassLoader(String dexPath, String librarySearchPath, ClassLoader parent){
     
		 super(dexPath, null, librarySearchPath, parent);
	}
}

PathClassLoader 与 DexClassLoader 在构造函数中都调用了父类的构造函数,两者唯一的区别在于:DexClassLoader多传了一个optimizedDirectory参数,并且会将其创建为File对象传给super,而PathClassLoader则直接给到null。因此两者都可以加载指定的dex,以及jar、zip、apk中的classes.dex

PathClassLoader pathClassLoader = new PathClassLoader("/sdcard/xx.dex", getClassLoader());
 
File dexOutputDir = context.getCodeCacheDir();
DexClassLoader dexClassLoader = new DexClassLoader("/sdcard/xx.dex",dexOutputDir.getAbsolutePath(), null,getClassLoader());

其实optimizedDirectory参数就是dexopt的产出目录(odex)。DexClassLoader不仅仅可以加载 dex文件,还可以加载jar、apk、zip文件中的dex。而jar、apk、zip其实就是一些压缩格式,要拿到压缩包里面的dex文件就需要解压,所以,DexClassLoader在调用父类构造函数时会指定一个解压的目录。那PathClassLoader创建时,这个目录为null,就意味着不进行dexopt?并不是,optimizedDirectory为null时的默认路径为:/data/dalvik-cache。

在API 26源码中,将DexClassLoader的optimizedDirectory标记为了 deprecated 弃用,实现也变得和PathClassLoader一摸一样了:

public DexClassLoader(String dexPath, String optimizedDirectory,
          String librarySearchPath, ClassLoader parent) {
     
  super(dexPath, null, librarySearchPath, parent);
}

2.3 双亲委托机制

可以看到创建ClassLoader需要接收一个ClassLoader parent参数。这个parent的目的就在于实现类加载的双亲委托。即:某个类加载器在接到加载类的请求时,首先将加载任务委托给父类加载器,依次递归,如果父类加载器可以完成类加载任务,就成功返回;只有父类加载器无法完成此加载任务时,才自己去加载。

protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException{
     
	
    // 检查class是否有被加载  
	Class c = findLoadedClass(name);
	if (c == null) {
     
		long t0 = System.nanoTime();
		try {
     
			if (parent != null) {
     
                //如果parent不为null,则调用parent的loadClass进行加载  
				c = parent.loadClass(name, false);
            } else {
     
                //parent为null,则调用BootClassLoader进行加载  
                c = findBootstrapClassOrNull(name);
            }
        } catch (ClassNotFoundException e) {
     
		
        }
 
        if (c == null) {
     
            // 如果都找不到就自己查找
			long t1 = System.nanoTime();
            c = findClass(name);
        }
	}
	return c;
}

值得注意的是:c = findBootstrapClassOrNull(name);按照方法名理解,应该是当parent为null时候,也能够加载BootClassLoader加载的类。但是实际上,Android当中的实现为:(Java不同)

private Class findBootstrapClassOrNull(String name)
{
     
  return null;
}

2.4 类加载器的三个机制(约束)

Android热更新详解_第3张图片

双亲委托机制实际上是一种自上而下带缓存的加载,这种机制也决定它的一些特性:

委托:将类加载交由父类加载器加载,父不行再自己加载。

可见性:子类加载器可见所有的父类加载器加载的类,父类加载器不可见子类加载器加载的类。

单一性:一个类仅加载一次,子类加载器不会再次加载父类加载器加载过的类。

2.5 findClass

可以看到在所有父ClassLoader无法加载Class时,则会调用自己的findClass方法。findClass在ClassLoader中的定义为:

protected Class<?> findClass(String name) throws ClassNotFoundException {
     
	throw new ClassNotFoundException(name);
}

其实任何ClassLoader子类,都可以重写loadClass与findClass。一般如果你不想使用双亲委托,则重写loadClass修改其实现。而重写findClass则表示在双亲委托下,父ClassLoader都找不到Class的情况下,定义自己如何去查找一个Class。而我们的PathClassLoader会自己负责加载MainActivity这样的程序中自己编写的类,利用双亲委托父ClassLoader加载Framework中的Activity。说明PathClassLoader并没有重写loadClass,因此我们可以来看看PathClassLoader中的 findClass 是如何实现的。

public BaseDexClassLoader(String dexPath, File optimizedDirectory,String 	
						librarySearchPath, ClassLoader parent) {
     
	super(parent);
	this.pathList = new DexPathList(this, dexPath, librarySearchPath, 		
                                    optimizedDirectory);
}
 
@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
     
	List<Throwable> suppressedExceptions = new ArrayList<Throwable>();
    //查找指定的class
    Class c = pathList.findClass(name, suppressedExceptions);
    if (c == null) {
     
		ClassNotFoundException cnfe = new ClassNotFoundException("Didn't find class \"" + 														name + "\" on path: " + pathList);
        for (Throwable t : suppressedExceptions) {
     
			cnfe.addSuppressed(t);
        }
            throw cnfe;
	}
	return c;
}

实现非常简单,从pathList中查找class。继续查看DexPathList:

public DexPathList(ClassLoader definingContext, String dexPath,
            String librarySearchPath, File optimizedDirectory) {
     
	//.........
    // splitDexPath 实现为返回 List.add(dexPath)
    // makeDexElements 会去 List.add(dexPath) 中使用DexFile加载dex文件返回 Element数组
    this.dexElements = makeDexElements(splitDexPath(dexPath), optimizedDirectory,
                                           suppressedExceptions, definingContext);
	//.........
    
}
 
public Class findClass(String name, List<Throwable> suppressed) {
     
     //从element中获得代表Dex的 DexFile
	for (Element element : dexElements) {
     
		DexFile dex = element.dexFile;
		if (dex != null) {
     
            //查找class
        	Class clazz = dex.loadClassBinaryName(name, definingContext, suppressed);
            if (clazz != null) {
     
            	return clazz;
        	}
    	}
    }
    if (dexElementsSuppressedExceptions != null) {
     
    	suppressed.addAll(Arrays.asList(dexElementsSuppressedExceptions));
    }
	return null;
}

可以看到, BaseDexClassLoader 的 findClass() 方法实际上是通过 DexPathList 的 findClass() 方法来获取class的,而这个 DexPathList 对象恰好在之前的 BaseDexClassLoader 构造函数中就已经被创建好了,里面解析了dex文件的路径,并将解析的dex文件都存在this.dexElements里面。DexPathList 类通过构造函数调用了 makeDexElements() 得到 Element

makeDexElements()

 //解析dex文件
private static Element[] makeDexElements(ArrayList<File> files, File optimizedDirectory, ArrayList<I
 // 1.创建Element集合
 ArrayList<Element> elements = new ArrayList<Element>();
 // 2.遍历所有dex文件(也可能是jar、apk或zip文件)
 for (File file : files) {
     
 ZipFile zip = null;
 DexFile dex = null;
 String name = file.getName();
 ...
 // 如果是dex文件
 if (name.endsWith(DEX_SUFFIX)) {
     
 dex = loadDexFile(file, optimizedDirectory);
 // 如果是apk、jar、zip文件(这部分在不同的Android版本中,处理方式有细微差别)
 } else {
     
 zip = file;
 dex = loadDexFile(file, optimizedDirectory);
 }
 ...
 // 3.将dex文件或压缩文件包装成Element对象,并添加到Element集合中
 if ((zip != null) || (dex != null)) {
     
 elements.add(new Element(file, false, zip, dex));
 }
 }
 // 4.将Element集合转成Element数组返回
 return elements.toArray(new Element[elements.size()]);
}

可以看到,DexPathList 的构造函数是将一个个的程序文件(可能是dex、apk、jar、zip)封装成一个个 Element 对象,最后添加到Element集合中。Android的类加载器(不管是PathClassLoader,还是DexClassLoader,它们最后在加载文件时,都只认dex文件,而loadDexFile()是加载dex文件的核心方法,他可以可以从jarapkzip中提取出dex

回头看一下PathClassLoader中的 findClass 方法:

 Class c = pathList.findClass(name, suppressedExceptions);

于是看到DexPathListfindClass()方法。如下:

public Class findClass(String name, List<Throwable> suppressed) {
     
    // 遍历从dexPath查询到的dex和资源Element
    for (Element element : dexElements) {
     
        DexFile dex = element.dexFile;
        // 如果当前的Element是dex文件元素
        if (dex != null) {
     
            // 使用DexFile.loadClassBinaryName加载类
            Class clazz = dex.loadClassBinaryName(name, definingContext, suppressed);
            if (clazz != null) {
     
                return clazz;
            }
        }
    }
    if (dexElementsSuppressedExceptions != null) {
     
        suppressed.addAll(Arrays.asList(dexElementsSuppressedExceptions));
    }
    return null;
}

对 Element 数组进行遍历,一旦找到类名与name相同的类时,就直接返回这个 class ,找不到则返回null。

通过如上分析,我们发现整个类加载流程就是:

  1. 类加载器BaseDexClassLoader先将dex文件解析放到pathListdexElements里面
  2. 加载类的时候从dexElements里面去遍历,看哪个dex里面有这个类就去加载,生成class对象

三 热修复

接刚刚个类加载流程,热修复原理就是将补丁 dex 文件放到 dexElements 数组靠前位置,这样在加载 class 时,优先找到补丁包中的 dex 文件,加载到 class 之后就不再寻找,从而原来的 apk 文件中同名的类就不会再使用,从而达到修复的目的:

PathClassLoader中的Element数组为:[patch.dex , classes.dex , classes2.dex]。如果存在Key.class位于patch.dex与classes2.dex中都存在一份,当进行类查找时,循环获得dexElements中的DexFile,查找到了Key.class则立即返回,不会再管后续的element中的DexFile是否能加载到Key.class了。因此一种热修复实现可以将出现Bug的class单独的制作一份fix.dex文件(补丁包),然后在程序启动时,从服务器下载fix.dex保存到某个路径,再通过fix.dex的文件路径,用其创建Element对象,然后将这个Element对象插入到我们程序的类加载器PathClassLoader的pathList中的dexElements数组头部。这样在加载出现Bug的class时会优先加载fix.dex中的修复类,从而解决Bug。

热修复的方式不止这一种,并且如果要完整实现此种热修复可能还需要注意一些其他的问题(如:反射兼容)。另外插件的形式常见的有apkdex文件。

dex打包工具(d8)

更新的dex文件如何生成呢?

Android SDK提供了dex打包工具d8,在在Android 构建工具 28.0.1 及更高版本中可以找到:

Android热更新详解_第4张图片

对正常的java文件,直接javac成class文件后,可直接用d8编译成dex文件:

./d8 XXX.class

如果你想更新的文件是apk格式的,可直接在Android Studio中对更新的Module/Lib直接打包成apk。

代码实现

dex替换:

//在Application中进行替换
public class MApplication extends Application {
     

    @Override
    public void onCreate() {
     
        super.onCreate();
        //dex作为插件进行加载
        dexPlugin();
    }
    ...

  /**
     * dex作为插件加载
     */
    private void dexPlugin(){
     
        //插件包文件
        File file = new File("/sdcard/hotfix.dex");
        if (!file.exists()) {
     
            Log.i("MApplication", "插件hotfix不存在");
            return;
        }
        try {
     
            //获取到 BaseDexClassLoader 的  pathList字段
            // private final DexPathList pathList;
            Field pathListField = BaseDexClassLoader.class.getDeclaredField("pathList");
            //破坏封装,设置为可以调用
            pathListField.setAccessible(true);
            //拿到当前ClassLoader的pathList对象
            Object pathListObj = pathListField.get(getClassLoader());

            //获取当前ClassLoader的pathList对象的字节码文件(DexPathList )
            Class<?> dexPathListClass = pathListObj.getClass();
            //拿到DexPathList 的 dexElements字段
            // private final Element[] dexElements;
            Field dexElementsField = dexPathListClass.getDeclaredField("dexElements");
            //破坏封装,设置为可以调用
            dexElementsField.setAccessible(true);

            //使用插件创建 ClassLoader
            DexClassLoader pathClassLoader = new DexClassLoader(file.getPath(), getCacheDir().getAbsolutePath(), null, getClassLoader());
            //拿到插件的DexClassLoader 的 pathList对象
            Object newPathListObj = pathListField.get(pathClassLoader);
            //拿到插件的pathList对象的 dexElements变量
            Object newDexElementsObj = dexElementsField.get(newPathListObj);

            //拿到当前的pathList对象的 dexElements变量
            Object dexElementsObj=dexElementsField.get(pathListObj);

            int oldLength = Array.getLength(dexElementsObj);
            int newLength = Array.getLength(newDexElementsObj);
            //创建一个dexElements对象
            Object concatDexElementsObject = Array.newInstance(dexElementsObj.getClass().getComponentType(), oldLength + newLength);
            //先添加新的dex添加到dexElement
            for (int i = 0; i < newLength; i++) {
     
                Array.set(concatDexElementsObject, i, Array.get(newDexElementsObj, i));
            }
            //再添加之前的dex添加到dexElement
            for (int i = 0; i < oldLength; i++) {
     
                Array.set(concatDexElementsObject, newLength + i, Array.get(dexElementsObj, i));
            }
            //将组建出来的对象设置给 当前ClassLoader的pathList对象
            dexElementsField.set(pathListObj, concatDexElementsObject);
        } catch (Exception e) {
     
            e.printStackTrace();
        }
    }

apk:

    // apk作为插件加载
    private void apkPlugin() {
     
        //插件包文件
        File file = new File("/sdcard/hotfix.apk");
        if (!file.exists()) {
     
            Log.i("MApplication", "插件hotfix不存在");
            return;
        }
        try {
     
            //获取到 BaseDexClassLoader 的  pathList字段
            // private final DexPathList pathList;
            Field pathListField = BaseDexClassLoader.class.getDeclaredField("pathList");
            //破坏封装,设置为可以调用
            pathListField.setAccessible(true);
            //拿到当前ClassLoader的pathList对象
            Object pathListObj = pathListField.get(getClassLoader());

            //获取当前ClassLoader的pathList对象的字节码文件(DexPathList )
            Class<?> dexPathListClass = pathListObj.getClass();
            //拿到DexPathList 的 dexElements字段
            // private final Element[] dexElements;
            Field dexElementsField = dexPathListClass.getDeclaredField("dexElements");
            //破坏封装,设置为可以调用
            dexElementsField.setAccessible(true);

            //使用插件创建 ClassLoader
            DexClassLoader pathClassLoader = new DexClassLoader(file.getPath(), getCacheDir().getAbsolutePath(), null, getClassLoader());
            //拿到插件的DexClassLoader 的 pathList对象
            Object newPathListObj = pathListField.get(pathClassLoader);
            //拿到插件的pathList对象的 dexElements变量
            Object newDexElementsObj = dexElementsField.get(newPathListObj);
            //将插件的 dexElements对象设置给 当前ClassLoader的pathList对象
            dexElementsField.set(pathListObj, newDexElementsObj);
        } catch (Exception e) {
     
            e.printStackTrace();
        }
    }

一些扩展

  1. 选择apk文件的方式一般就不对dexElements数组就行插前值操作了,而是直接替换整个dexElements数组。但是现实中,热更新可能只是更新某几个类或者资源文件,如果使用apk全量替换的方式,就很重,那么增量替换,即使用dex文件的方式,就是很好的方式;

  2. 更新的文件一般放服务器上需要客户端下载插前值;

  3. so库在Android代码中是通过调用System.loadLibrary函数实现的。动态注册的native方法调用一次JNI_OnLoad方法都会重新完成一次映射, 所以我们是否只要先加载原来的so库,,然后再加载补丁so库,就能完成Java层native方法到native层patch后的新方法映射, 这样就完成动态注册native方法的patch实时修复。

  4. 、资源文件的更新方式:加载apk,反射调用AssetManager的addAssetPath方法。

参考文章:

Android Runtime (ART) 和 Dalvik

Android 热修复核心原理, ClassLoader类加载

【小家Java】从原理层面理解Java中的类加载器

一看你就懂,超详细java中的ClassLoader详解

Android热修复实现及原理

你可能感兴趣的:(Android进阶学习,Android,android,热更新,热修复)