代码修复-深入热修复(一)

一、代码修复方式

   在app重新启动时，优先加载补丁中的类，从而达到热修复的目的，andfix采用的方式是：在已经加载了的类中直接在native层替换掉原来的方法，是在原来的类上做修改，从而达到即时生效。
1、native替换。
2、整体替换ArtMethod.
3、AndFix:是一种底层结构替换的方案，可以达到即时生效。

二、分析

方法替换：由于4.4虚拟机以下版本的不同，dalvik  art,所以需要根据不同的虚拟机做判断，又因为不同的android版本，底层的java数据结构不同，所以也要根据版本不同而做方法替换。

1、方法替换，就是把所有旧方法的成员字段都替换成新方法的，执行的时候就可以保持和新方法一致，这样所有执行到旧方法的地方，会取得新方法的入口，所属的类，方法索引及所属的dex信息。

2、方法替换，是根据artmethod的结构来做替换的，各个厂商有可以能修改artMethod结构，所有有很大的兼容性问题。

3、不适用与引起原来类结构发生变化的修改。

4、修复了非静态方法而被反射调用。

三、编译存在的问题
 1、同包名下，不同类的方法替换，由于ClassLoader不一样，会抛异常、通过反射，设置新类的ClassLoader为旧类的ClassLoader。
 2、反射调用热修复替换的非静态方法，抛异常。
3、内部类：当内部类访问外部类的私有方法或者字段，或者外部类访问内部的私有方法、字段时，编译器会生成一个方法，导致方法数的增加，解决办法，都修改成protected 或者public。
4、匿名内部类：如果原来的类中有一个匿名内部类，新添加一个匿名内部类，会按匿名内部类插入的先后位置生成类名，所以热修复无法确定生成的类是哪一个。
5、静态字段及静态代码块：都会被翻译到clinit方法中，导致热修复失败，只能通过冷气的生效。
6、final static 修复的原始类型不会翻译到clinit方法中，引用类型则翻译到clinit方法中。
7、方法内联：方法没有被任何地方引用，方法很简单，方法只被一个地方引用，都会造成方法的内联，导致方法数减少。方法剪切：若果方法中参数没有被使用，会导致该方法被剪切，如果补丁包中使用了该参数，导致方法增加，就只能走冷启动。
8、泛型：泛型擦除导致机制导致了和多态的冲突，虚拟机通过桥方法的方式解决了这个问题，但是会导致方法的增加，所以只能走冷启动。
9、lambda 表达式：在编译时会生成一个静态的辅助方法，逻辑即为lambda表达式的内容，如果是仅修改lambda的内容不会受影响，如果插入一个lambda表达式，则会导致方法的增加。

四、冷启动方案
 1、tinker ：打出差量的patch.dex,与应用的classes.dex合成一个完整的dex,完整的dex加载的到dexfile对象，然后得到Element对象，替换掉旧的Elements数组。
 优点：补丁包小，Dalvik下不影响加载性能，Art下也不存在必须包含父类/引用类的情况。
 缺点：dex合成在vm heap中，容易oom,导致合成失败。

2、插桩的方式：做一个辅助类，打包在单独的dex,app中的类在构造函数中都引用此类，由于在类的记载过程中会进行verify+optimize,所以有较大的性能影响。
3、spopt:由于art环境下已经支持一个压缩包下多个dex文件，首先优先加载classes.dex文件，所哟我们只需把补丁类放入到classes.dex中，把原来的dex依次命名为dex1,dex2....就好了，然后一起打包为一个压缩文件，然后DexFile.loadDex的到DexFile对象，最后把该DexFile对象整个替换就得dexElement就可以了。

由于loadDex是补丁dex和原apkdex的合成的压缩包，所以dexoat很耗时，所以优化后deodex没有生成或者不完整，那么loaddex就不能在应用启动时进行，因为会阻塞loadDex线程，解决方法：如果不存在odex文件，那么重启一个子线程loadDex,重启之后再生效。

合成：只需去掉原来dex中，补丁dex中存在的类，去掉时只需去掉原来类在dex中的类定义就可以了，然记载时找不到该类的定义就可以了。