文章目录
1 热修复原理
1.1 AndFix
1.2 Robus
1.3 Tinker
1.4 Qzone
2 ClassLoader
2.1 双亲委托机制
2.2 类查找流程
3 热修复流程
生成补丁包
自动化生成补丁
Android热修复原理分析
什么是热修复
ClassLoader介绍
双亲委托机制
* findClass
热修复
总结
1 热修复原理
热补丁方案有很多,其中比较出名的有腾讯Tinker、阿里的AndFix、美团的Robust以及QZone的超级补丁方案。
1.1 AndFix
在native动态替换java层的方法,通过native层hook java层的代码。
即时生效、注解、NDK
1.2 Robus
对每个函数都在编译打包阶段自动的插入了一段代码。类似于代理,将方法执行的代码重定向到其他方法中。
即时生效、注解、插桩、代理
1.3 Tinker
Tinker通过计算对比指定的Base Apk中的dex与修改后的Apk中的dex的区别,补丁包中的内容即为两者差分的描述。
运行时将Base Apk中的dex与补丁包进行合成,重启后加载全新的合成后的dex文件。
重启生效、反射、类加载、DexDiff
Tinker对比BsDiff、DexMerge。最终自己实现了一套DexDiff算法。
BsDiff: 与格式无关的差分算法,在增量更新实现中经常使用。
DexMerge:Android的dex合并实现,如在打包APK时会有 :app:transformDexArchiveWithDexMergerForDebug 任务
1.4 Qzone
QQ空间基于的是dex分包方案。把BUG方法修复以后,放到一个单独的dex补丁文件,让程序运行期间加载dex补丁,执行修复后的方法。如何做到这一点?
在Android中所有我们运行期间需要的类都是由ClassLoader(类加载器)进行加载。
因此让ClassLoader加载全新的类替换掉出现Bug的类即可完成热修复。
重启生效、反射、类加载
2 ClassLoader
在线源码阅读:
https://www.androidos.net.cn/
或
http://androidxref.com/
2.1 双亲委托机制
某个类加载器在加载类时,首先将加载任务委托给父类加载器,依次递归,如果父类加载器可以完成类加载任务,就成功返回;只有父类加载器无法完成此加载任务或者没有父类加载器时,才自己去加载。
1、避免重复加载,当父加载器已经加载了该类的时候,就没有必要子ClassLoader再加载一次。
2、安全性考虑,防止核心API库被随意篡改。
2.2 类查找流程
3 热修复流程
获取到当前应用的PathClassloader;
反射获取到DexPathList属性对象pathList;
反射修改pathList的dexElements:
把补丁包patch.dex转化为Element[] (patch)
获得pathList的dexElements属性(old)
patch+old合并,并反射赋值给pathList的dexElements
生成补丁包
dx --dex --output=output.dex
input.jar
java -jar dx.jar --dex --output=output.dex input.jar
自动化生成补丁
每次编译生成一份缓存文件,里面记录了所有class文件的md5。
再次编译对比md5缓存文件,发生修改或者不存在的class制作为补丁包。
知识点:
Gradle插件开发
ASM插桩
Android热修复原理分析
什么是热修复
热修复:让应用能够在无需重新安装的情况实现更新,帮助应用快速建立动态修复能力。
早期遇到Bug我们一般会紧急发布了一个版本。然而这个Bug可能就是简简单单的一行代码,为了这一行代码,进行全量或者增量更新迭代一个版本,未免有点大材小用了。而且新版本的普及需要时间,以Android用户的升级习惯,即使是相对活跃的微信也需要10天以上的时间去覆盖50%的用户。使用热修复技术,能做到1天覆盖70%以上。这也是基于补丁体积较小,可以直接使用移动网络下载更新。
热修复开发流程
目前Android业内,热修复技术百花齐放,各大厂都推出了自己的热修复方案,使用的技术方案也各有所异。其中QZone超级补丁基于的是dex分包方案,而dex分包是基于Java的类加载机制ClassLoader。
ClassLoader介绍
任何一个 Java 程序都是由一个或多个 class 文件组成,在程序运行时,需要将 class 文件加载到虚拟机 中才可以使用,负责加载这些 class 文件的就是 Java 的类加载机制。ClassLoader 的作用简单来说就是加载 class 文件,提供给程序运行时使用。每个 Class 对象的内部都有一个classLoader字段来标识自己是由哪个 ClassLoader 加载的。
classLoader
ClassLoader是一个抽象类,而它的主要实现类主要有:
BootClassLoader
用于加载Android Framework层class文件。
PathClassLoader
用于Android应用程序类加载器。可以加载指定的dex,以及jar、zip、apk中的classes.dex
DexClassLoader
用于加载指定的dex,以及jar、zip、apk中的classes.dex
很多博客里说PathClassLoader只能加载已安装的apk的dex,但是实际上PathClassLoader和DexClassLoader一样都能够加载sdcard中的dex。
TAG TAG
由: 加载
由:zip file nativeLibraryDirectoriesdataappcomenjoyenjoyfixlibx86 systemlib vendorlib 加载
它们之间的关系如下:
PathClassLoader与DexClassLoader的共同父类是BaseDexClassLoader。
dexPath optimizedDirectory
librarySearchPath parent
dexPath optimizedDirectory librarySearchPath parent
dexPath parent
dexPath parent
dexPath librarySearchPath parent
dexPath librarySearchPath parent
可以看到两者唯一的区别在于:创建DexClassLoader需要传递一个optimizedDirectory参数,并且会将其创建为File对象传给super,而PathClassLoader则直接给到null。因此两者都可以加载指定的dex,以及jar、zip、apk中的classes.dex
pathClassLoader dexOutputDir context
dexClassLoader dexOutputDir
optimizedDirectory参数为odex的目录。实际上Android中的ClassLoader在加载dex时,会首先经过dexopt对dex执行优化,产生odex文件。optimizedDirectory为null时的默认路径为:***/data/dalvik-cache***。并且处于安全考虑,此目录需要使用app私有目录,如:getCodeCacheDir()
在API 26源码中,将DexClassLoader的optimizedDirectory标记为了 deprecated 弃用,实现也变为了:
dexPath optimizedDirectory
librarySearchPath parent
dexPath librarySearchPath parent
和PathClassLoader一摸一样了!
双亲委托机制
创建ClassLoader需要接收一个ClassLoader parent参数。这个parent为父类加载。即:某个类加载器在接到加载类的请求时,首先将加载任务委托给父类加载器,依次递归,如果父类加载器可以完成类加载任务,就成功返回;只有父类加载器无法完成此加载任务时,才自己去加载。这就是双亲委托机制!
name resolve c name
c
t0
parent
c parentname
c name
e
c
t1
c name
c
因此我们自己创建的ClassLoader: new PathClassLoader("/sdcard/xx.dex", getClassLoader());并不仅仅只能获得 xx.dex中的Class,还能够获得其父ClassLoader中加载的Class。
findClass
在所有父ClassLoader无法加载Class时,则会调用自己的findClass方法。findClass在ClassLoader中的定义为:
name name
其实任何ClassLoader子类,都可以重写loadClass与findClass。一般如果你不想使用双亲委托,则重写loadClass修改其实现。而重写findClass则表示在双亲委托下,父ClassLoader都找不到Class的情况下,定义自己如何去查找一个Class。而我们的PathClassLoader会自己负责加载MainActivity这样的程序中自己编写的类,利用双亲委托父ClassLoader加载Framework中的Activity。说明PathClassLoader并没有重写loadClass,因此我们可以来看看PathClassLoader中的 findClass 是如何实现的。
dexPath optimizedDirectory librarySearchPath parent
parent
pathList dexPath librarySearchPath
optimizedDirectory
name
suppressedExceptions
c pathListname suppressedExceptions
c
cnfe name pathList
t suppressedExceptions
cnfet
cnfe
c
实现非常简单,从pathList中查找class。继续查看DexPathList
definingContext dexPath librarySearchPath optimizedDirectory
dexElements dexPath optimizedDirectory
suppressedExceptions definingContext
name suppressed
element dexElements
dex elementdexFile
dex
clazz dexname definingContext suppressed
clazz
clazz
dexElementsSuppressedExceptions
suppresseddexElementsSuppressedExceptions
热修复
PathClassLoader中存在一个Element数组,Element类中存在一个dexFile成员表示dex文件,即:APK中有X个dex,则Element数组就有X个元素。
而对于类的查找,由代码for (Element element : dexElements)得知,会由数组从前往后进行查找。
在PathClassLoader中的Element数组为:[patch.dex , classes.dex , classes2.dex]。如果存在Key.class位于patch.dex与classes2.dex中都存在一份,当进行类查找时,循环获得dexElements中的DexFile,查找到了Key.class则立即返回,不会再管后续的element中的DexFile是否能加载到Key.class了。
因此,可以将出现Bug的class单独的制作一份patch.dex文件(补丁包),然后在程序启动时,从服务器下载patch.dex保存到某个路径,再通过patch.dex的文件路径,用其创建Element对象,然后将这个Element对象插入到我们程序的类加载器PathClassLoader的pathList中的dexElements数组头部。这样在加载出现Bug的class时会优先加载patch.dex中的修复类,从而解决Bug。QQ空间热修复的原理就是这样,利用反射Hook了PathClassLoader中pathList的dexElements数组。
总结
在实现热修复的过程中,必须掌握的技术包括了反射、类加载机制并且掌握Framewrok层源码中关于ClassLoader部分的内容。同时如果需要继续自动化补丁生成还需要掌握gradle编程等内容。
还没有评论,来说两句吧...