Tinker：全量替换，无须插桩
传统的热修复需要插桩实现，插桩的原因和操作：
原因：
- 通过将补丁dex文件插入到类加载器的dexElement列表最前面，完成热修复
- 调用bug类的时候就会先搜索到补丁dex里的类，从而fix bug
- bug类和它引用的类都在一个dex中，这个类就被打上了CLASS_ISPREVERIFIED标识，如果这个类调用了插在dexElement队列前面的补丁dex文件中的同名方法，就会报错，所以需要阻止bug类打上该标识
- 通过“插桩”的方法避免需要被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段不同类型的地址进行索引。
以String数据为例，首先读取Dex Header部分String IDs offset和String IDs Size的内容，如0X70和0X14，代表String数据在Table段的偏移量是0X70，共20个。在Table段读取这20个数据，每个数据4个字节，根据这4个字节代表的地址，去DataSection找这个地址存储的内容，解析成String数据。
接下来计算新旧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
- 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));
- 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
