Dex格式解析及在Tinker中的应用

Difference

Tinker:全量替换,无须插桩

传统的热修复需要插桩实现,插桩的原因和操作:
原因:

  1. 通过将补丁dex文件插入到类加载器的dexElement列表最前面,完成热修复
  2. 调用bug类的时候就会先搜索到补丁dex里的类,从而fix bug
  3. bug类和它引用的类都在一个dex中,这个类就被打上了CLASS_ISPREVERIFIED标识,如果这个类调用了插在dexElement队列前面的补丁dex文件中的同名方法,就会报错,所以需要阻止bug类打上该标识
  4. 通过“插桩”的方法避免需要被fix的class打上CLASS_ISPREVERIFIED标识

如何插桩:
使可能会产生bug的class引用另外一个dex中的class,从而避免该class被打上CLASS_ISPREVERIFIED标识(Groovy语言字节码织入)。

Tinker使用的是apk全量替换的方法,使用差量包补丁包和原来的apk合成新的apk,使用全新apk,从而不会出现引用其他dex的class的情况,避免了插桩。

Part 1:怎样生成差量补丁

APK Diff包括:DexDiff,ResDiff,ManifestDiff和SoDiff

1. ManifestDiff

用来检测新的Manifest是否发送过改变,Tinker不支持Manifest修改。原因应该是apk在执行install操作的时候会向系统注册Manifest信息,tinker热修复不会经历这个过程。

2. ResDiff/SoDiff

BsDiff算法,求新版本和旧版本的二进制差异。原理来自这篇博士论文Naive Differences of Executable Code
基本步骤:
a.对old文件中所有子字符串形成一个字典;
b.对比old文件和new文件,产生diffstring和extra string;
c.将diffstring 和extra string 以及相应的控制字用zip压缩成一个patch包。

优点:通用性强,适用于所有文件的补丁包生成
缺点:没有针对特定的格式做优化,导致补丁包可能过大

3. DexDiff

对Dex文件进行差量包生成,传统的方法有两种,除了上面提到的Bsdiff算法,还有一种反编译方法,通过对dex文件反编译后的class进行比较,以确定哪些class发生了变化的方式,并对发生变化的class文件进行补丁操作。
微信团队为了使得差异包最小化,充分利用了Dex的结构,开发了专门应用于Dex文件的差量包生成算法DexDiff算法,跟Bsdiff相比,丧失了通用性,但是效率更高。
DexClassLoader文件结构如下,分为Header,Table,Data三部分。

Header:

dex文件头部,记录整个dex文件的相关属性,如都包含哪些部分(如String,Field,Method,Class等),每部分的大小和偏移量。

Table:

存放每种类型数据的地址列表,如在String Table中,连续存放若干个String的地址,根据每个地址,可以在Data段找到改地址存储的字符串。

Data:

存放具体的数据,由Table段不同类型的地址进行索引。

Dex文件结构
Dex Header格式

以String数据为例,首先读取Dex Header部分String IDs offset和String IDs Size的内容,如0X70和0X14,代表String数据在Table段的偏移量是0X70,共20个。在Table段读取这20个数据,每个数据4个字节,根据这4个字节代表的地址,去DataSection找这个地址存储的内容,解析成String数据。

String数据解析.png

接下来计算新旧Dex的String数据的Diff数据。采用最小序列生成算法,生成由旧String列表生成新列表的操作,用删除,添加,修改三种操作表示。

算法描述如下,摘抄自这篇帖子

首先我们需要将新旧内容排序,这需要针对排序的数组进行操作

新旧两个指针,在内容一样的时候 old、new 指针同时加1,在 old 内容小于 new >内容的时候 old 指针加1,标记当前 old 项为删除

在 old 内容大于 new 内容 new 指针加1, 标记当前 new 项为新增

------old-----
11 foo2
12 foo5
13 hello dodola
14 hello dodola1

------new-----
11 foo3
12 foo5
13 hello dodola1
14 hello dodola3

对比的old cursor 和 new cursor 指针的改变以及操作判定,判定过程如下
old_11 new_11 cmp <0 del
old_12 new_11 cmp >0 add
old_12 new_12 cmp =0 no
old_13 new_13 cmp <0 del
old_14 new_13 cmp =0 no
break;

进入下一步过程
可以确定的是删除的内容肯定是从 old 中的 index 进行删除的 添加的内容肯定是从 new 中的 index 中来的,按照这个逻辑我们可以整理如下内容。

old_11 del
new_11 add
old_13 del
new_14 add

到这一步我们需要找出替换的内容,很明显替换的内容就是从old中del的并且在 >new 中 add 的并且 index 相同的i tem,所以这就简单了

old_11 replace
old_13 del
new_14 add

这样就生成了两个Dex的String部分的变化。

Part 2:怎么加载新的apk

  1. Dex加载:将合成的新的dex加入到PathClassLoader的dexElements列表中
PathClassLoader classLoader = (PathClassLoader) TinkerDexLoader.class.getClassLoader();
Field pathListField = ShareReflectUtil.findField(loader, "pathList");
Object dexPathList = pathListField.get(loader);
ArrayList<IOException> suppressedExceptions = new ArrayList<IOException>();
ShareReflectUtil.expandFieldArray(dexPathList, "dexElements", 
      makePathElements(dexPathList,    new ArrayList<File>(additionalClassPathEntries), optimizedDirectory,    suppressedExceptions));
  1. Res加载
    访问应用程序资源的函数有两个:getResources和getAssets。getResources返回Resources对象,Resources对象通过资源的ID访问编译后的资源。getAssets返回AssetManager对象,AssetManager对象通过资源的文件名访问编译后或未经编译的资源文件。实际上,Resources访问资源是先通过资源ID获取文件名,然后通过AssetManager根据文件名访问资源文件。
    为了使这两个方法加载新的资源文件,执行以下操作:
    a. 新建一个AssetManager对象newAssetManager,通过反射调用其addAssetPath方法,传入新生成的apk文件路径
    b. 新建Resources对象,通过反射设置其mAssets属性的值为newAssetManager
    通过这种方式实现新的资源文件的加载。
addAssetPathMethod.invoke(newAssetManager, externalResourceFile)
assetsFiled.set(resources, newAssetManager);

参考:
https://github.com/WeMobileDev/article/blob/master/%E5%BE%AE%E4%BF%A1Android%E7%83%AD%E8%A1%A5%E4%B8%81%E5%AE%9E%E8%B7%B5%E6%BC%94%E8%BF%9B%E4%B9%8B%E8%B7%AF.md
https://www.zybuluo.com/dodola/note/554061
http://www.jianshu.com/p/f7f0a712ddfe
http://blog.csdn.net/add_ada/article/details/51232889

推荐阅读更多精彩内容