首页 > 代码库 > Android 热修复技术(1)---原理
Android 热修复技术(1)---原理
热修复技术分为几部分:
原理介绍
Android HotFix源码分析
自定义框架
1.Android分包MultiDex原理
首先Dex是什么东西?
Dex就是Window里面的exe文件 也就是可执行问题。
Android没有用传统的Java虚拟机,而是使用dalvik虚拟机。当APK安装到手机后,dalvik会先把de文件转化位ODEX文件,
优化结构。
在早期的android系统中,为了优化dex,所有的method会存放在一张表里面,表的大小位short,也就是65535(65K)
But现在android代码非常多,超过65K很正常,这个时候就需要一种解决方案来解决这个问题。
简单来说就是将编译好的class文件分拆成2个dex文件,绕过65k的限制。
关于分包的具体实现,可以参考dex分包方案概述与multidex包的配置使用
2.Android热补丁修复技术原理
目的:有时候需要修改几行代码,但是我们需要重发各个市场,重新release等。是不是可以只是简单的打patch就可以解决这个问题呢?
首先来看dex加载的源码:
public Class findClass(String name, List<Throwable> suppressed) { for (Element element : dexElements) { DexFile dex = element.dexFile; if (dex != null) { Class clazz = dex.loadClassBinaryName(name, definingContext, suppressed); if (clazz != null) { return clazz; } } } if (dexElementsSuppressedExceptions != null) { suppressed.addAll(Arrays.asList(dexElementsSuppressedExceptions)); } return null;}
每个element对应的就是dex文件,所以加载class就是从一个个dex文件中找到对应的code。but,可以发现,一旦找到成功了以后,就直接return。
也就是说如果2个dex含有相同的class,会先返回前面那个。
so 我们的解决方案来了,使用一个新的dex,让他在element文件表的最前面,这样我们修改的class文件就会被首先加载进来。
理论上,如果在不同的dex中有相同的类存在,那么会优先选择排在前面的dex文件的类,如下图:
在此基础上,我们构想了热补丁的方案,把有问题的类打包到一个dex(patch.dex)中去,然后把这个dex插入到Elements的最前面,如下图:
好,该方案基于第二个拆分dex的方案,方案实现如果懂拆分dex的原理的话,大家应该很快就会实现该方案,如果没有拆分dex的项目的话,可以参考一下谷歌的multidex方案实现。然后在插入数组的时候,把补丁包插入到最前面去。
But 我们发现在插入patch.dex后,会报错,原因是CLASS_ISPREVERIFIED。这是个什么东东?
在类的方法中直接引用的类,如果在同一dex中,就会被打上CLASS_ISPREVERIFIED这个标志。
我们单独给一个AntilazyLoad类打包成hack.dex 这样每个class里面都调用。我们在构造函数里面添加:
public class A{ public A() { system.println(AntilazyLoad.class); }}
So,这样A就引用了不在一个dex里面的class,从而不会被打上CLASS_ISPREVERIFIED的代码。进而不会出现问题。
参考:
安卓App热补丁动态修复技术介绍
http://my.oschina.net/853294317/blog/308583
http://blog.csdn.net/lmj623565791/article/details/49883661
Android 热修复技术(1)---原理