What is HotFix?

以补丁的方式动态修复紧急Bug,不再需要重新发布App,不再需要用户重新下载,覆盖安装(来自:安卓App热补丁动态修复技术介绍)
HotFix原理
首先HotFix原理是基于Android Dex分包方案的,而Dex分包方案的关键就是Android的ClassLoader体系。ClassLoader的继承关系如下:

ClassLoader继承关系

这里我们可以用的是PathClassLoader和DexClassLoader,接下来看看这两个类的注释:

PatchClassLoader/*** Provides a simple {@link ClassLoader} implementation that operates on a list* of files and directories in the local file system, but does not attempt to* load classes from the network. Android uses this class for its system class* loader and for its application class loader(s).*/

这个类被用作系统类加载器和应用类(已安装的应用)加载器。

DexClassLoader/*** A class loader that loads classes from {@code .jar} and {@code .apk} files* containing a {@code classes.dex} entry. This can be used to execute code not* installed as part of an application.*/

注释可以看出,这个类是可以用来从.jar文件和.apk文件中加载classed.dex,可以用来执行没有安装的程序代码。
通过上面的两个注释可以清楚这两个类的作用了,很显然我们要用的是DexClassLoader,对插件化了解的小伙伴们对这个类肯定不会陌生的,对插件化不了解的也没关系。下面会更详细的介绍。
我们知道了PathClassLoader和DexClassLoader的应用场景,接下来看一下是如何加载类的,看上面的继承关系这里两个类都是继承自BaseDexClassLoader,所以查找类的方法也在BaseDexClassLoader中,下面是部分源码:

/** * Base class for common functionality between various dex-based * {@link ClassLoader} implementations. */public class BaseDexClassLoader extends ClassLoader {     /** structured lists of path elements */     private final DexPathList pathList;     //...some code     @Override     protected Class<?> findClass(String name) throws ClassNotFoundException {         Class clazz = pathList.findClass(name);         if (clazz == null) {             throw new ClassNotFoundException(name);         }         return clazz;     }    //...some code}

可以看到在findClass()方法中用到了pathList.findClass(name),而pathList的类型是DexPathList,下面看一下DexPathList的findClass()方法源码:

/** * A pair of lists of entries, associated with a {@code ClassLoader}. * One of the lists is a dex/resource path — typically referred * to as a "class path"list, and the other names directories * containing native code libraries. Class path entries may be any of: * a {@code .jar} or {@code .zip} file containing an optional * top-level {@code classes.dex} file as well as arbitrary resources, * or a plain {@code .dex} file (with no possibility of associated * resources). * * 

This class also contains methods to use these lists to look up * classes and resources.

*//*package*/ final class DexPathList { /** list of dex/resource (class path) elements */ private final Element[] dexElements; /** * Finds the named class in one of the dex files pointed at by * this instance. This will find the one in the earliest listed * path element. If the class is found but has not yet been * defined, then this method will define it in the defining * context that this instance was constructed with. * * @return the named class or {@code null} if the class is not * found in any of the dex files */ public Class findClass(String name) { for (Element element : dexElements) { DexFile dex = element.dexFile; if (dex != null) { Class clazz = dex.loadClassBinaryName(name, definingContext); if (clazz != null) { return clazz; } } } return null; }}

这个方法里面有调用了dex.loadClassBinaryName(name, definingContext),然后我们来看一下DexFile的这个方法:

/** * Manipulates DEX files. The class is similar in principle to * {@link java.util.zip.ZipFile}. It is used primarily by class loaders. * 

* Note we don't directly open and read the DEX file here. They're memory-mapped * read-only by the VM. */public final class DexFile { /** * See {@link #loadClass(String, ClassLoader)}. * * This takes a "binary" class name to better match ClassLoader semantics. * * @hide */ public Class loadClassBinaryName(String name, ClassLoader loader){ return defineClass(name, loader, mCookie); } private native static Class defineClass(String name, ClassLoader loader, int cookie);}

好了,关联的代码全部贴上了,理解起来并不难,总结一下流程:BaseDexClassLoader中有一个DexPathList对象pathList,pathList中有个Element数组dexElements(Element是DexPathList的静态内部类,在Element中会保存DexFile的对象),然后遍历Element数组,通过DexFile对象去查找类。
更通俗的说:

一个ClassLoader可以包含多个dex文件,每个dex文件是一个Element,多个dex文件排列成一个有序的数组dexElements,当找类的时候,会按顺序遍历dex文件,然后从当前遍历的dex文件中找类,如果找类则返回,如果找不到从下一个dex文件继续查找。(出自安卓App热补丁动态修复技术介绍)
so,通过上面介绍,我们可以将patch.jar(补丁包),放在dexElements数组的第一个元素,这样优先找到我们patch.jar中的新类去替换之前存在bug的类。
方案有了,但是我们还差一个步骤,就是防止类被打上CLASS_ISPREVERIFIED的标记
解释一下:在apk安装的时候,虚拟机会将dex优化成odex后才拿去执行。在这个过程中会对所有class一个校验。校验方式:假设A该类在它的static方法,private方法,构造函数,override方法中直接引用到B类。如果A类和B类在同一个dex中,那么A类就会被打上CLASS_ISPREVERIFIED标记。A类如果还引用了一个C类,而C类在其他dex中,那么A类并不会被打上标记。换句话说,只要在static方法,构造方法,private方法,override方法中直接引用了其他dex中的类,那么这个类就不会被打上CLASS_ISPREVERIFIED标记。(引用自Android热补丁动态修复技术(二):实战!CLASS_ISPREVERIFIED问题!)
O..O..OK,现在很清楚了,实现热修复,我们需要完成两个任务:
改变BaseDexClassLoader中的dexElements数组,将我们的patch.jar插入到dexElements数组的第一个位置。
在打包的时候,我们要阻止类被打上CLASS_ISPREVERIFIED标记

HotFix框架汇总
RocooFix(推荐)
Nuwa
HotFix
AndFix
Tinker_imitator(微信热更新方案实践)

RoccoFix使用问题
RocooFix的正确教程,不生成patch.jar请按这个步骤来执行
待更新

参考
安卓App热补丁动态修复技术介绍
Android dex分包方案
Android 热补丁动态修复框架小结
Android热补丁动态修复技术(一):从Dex分包原理到热补丁
Android热补丁动态修复技术(二):实战!CLASS_ISPREVERIFIED问题!
Android热补丁动态修复技术(三)—— 使用Javassist注入字节码,完成热补丁框架雏形(可使用)
Android热补丁动态修复技术(四):自动化生成补丁——解决混淆问题

文/zyyoona7(简书作者)
原文链接:http://www.jianshu.com/p/6f0ae1e364d9
著作权归作者所有,转载请联系作者获得授权,并标注“简书作者”。

更多相关文章

  1. Android实现动态自动匹配输入内容功能
  2. 【Android】Android中Button的OnClickListener实现方法
  3. Android webview中定制js的alert,confirm和prompt对话框的方法 (
  4. Android 性能优化的一些方法(转)
  5. 消除“Unfortunately, System UI has stopped”的方法
  6. Live Wallpaper动态壁纸开发

随机推荐

  1. 接口 登录、注册、信息
  2. android自定义一圆角ImageView
  3. 调用摄像头拍照并显示
  4. android 读中文文本文件
  5. Android抽屉(SlidingDrawer)的实现
  6. Android中的数据存储方式
  7. Android中获取全局Context
  8. 单条-多条 折线图
  9. ViewPager无限轮播图
  10. 使用ComponentName启动Activity