15年开始，时至今日、各家热更新热修复如雨后春笋般纷纷绽放，百花齐放、最后到阿里的sophix时；为之前种种算是做了总结吧；我学习热修复技术原理已有些时日了，总害怕自己会忘记、所以还是写篇总结进行记录吧。
先说热修复技术的演变史，从pc到移动互联网、从原生开发到混合开发，所有在pc时代演变的技术、丝毫不差的照搬到了移动互联网上；热修复的演变过程中：手淘从针对androiddalvik虚拟机运行时的java method hook技术---Dexposed(由于方案对底层的Davilk虚拟机结构过于依赖，最终无法兼容android 5.0以后的ART虚拟机)；然后到支付宝的Andfix(同样是底层结构替换方案，兼容ART)；然后阿里百川将业务逻辑解藕推出了Hotfix(只提供代码层面的修复，对于资源和so的修复还不支持);最后到Sophix；腾讯系QQ空间的超级补丁、微信的Tinker、饿了么的Amigo、美团的Robust等，有各自的局限性、或者不稳定，或者补丁过大，或者效率低下，或者使用过于繁琐，所以体验不是很好。在android热修复的三大领域：代码修复、资源修复、so修复中，sophix在业界是领先的。
sophix唯一不支持的地方就是四大组件的修复，因为要修复四大组件，必须在AndroidManifest里面预先插入代理组件，并且尽可能的声明所有的权限，这么做就导致原APP添加了很多臃肿代码，对运行流程侵入性很强。
Sophix设计理念：非侵入性，不需要侵入apk的build流程，只要生产新旧apk就好；唯一需要的就是初始化和请求补丁两行代码。
1、 代码修复：
代码修复两大主要方案：阿里系的底层替换方案、腾讯系的类加载方案
优劣：
底层替换方案限制颇多，但时效性最好、加载轻快，立即见效
类加载方案时效性差，需要重新冷启动才能见效，但修复范围广，限制少。
底层替换方案：在已经加载了的类中直接替换掉原有方法，是在原来类的基础上进行修改的；因为无法实现对原有类进行方法和字段的增减；因为这样会破坏原有类结构(一旦补丁类中出现方法的增加或减少，就会导致这个类以及整个Dex的方法数变化，方法数变化导致方法索引变化，这样访问方法时就无法正常索引到正确方法；字段的增加和减少、也一样会导致索引变化)。
像Dexposed、Andfix或者其他Hook方案，都是依赖修改虚拟机方法实体的具体字段，如改Dalvik方法的jni函数指针、改类或方法的访问权限等，由于各厂商可以对源代码改造，替换机制就很可能出问题。Sophix采取了无视底层具体结构的替换方式，只要保证ArtMethod数组仍是线性结构排列就行。
类加载方案：原理是在app重启动后让Classloader去加载新的类
sophix采用全量合成dex技术，利用android原先的类查找和合成机制，快速合成新的全量dex，重新编排包中dex顺序，虚拟机查找类时会优先找到classes.dex中的类，然后才是classes2.dex、classes3.dex；这样它对旧包与补丁包中的classes.dex的顺序进行的打破和重组而实现类覆盖。
双剑合璧，将两种方案融合在一起，根据代码变动情况进行选择，针对小修改、在底层替换方案限制范围内的就直接采用底层替换修复、其他的为类加载替换。
