正常开发流程：

新版本上线，发现问题或用户反馈bug，紧急修复，上线版本，用户重新安装。

热修复流程：

新版本上线，发现问题或用户反馈，紧急修复，上线补丁，自动修复

Thinker解决思路？

在android5.0之前，每个android应用只含有一个dex文件，dex的方法数量被限制在了65535之内，导致apk引入大量第三方sdk后方法数量超过限制无法编译通过。为了解决这个问题，Google推出多dex文件的解决方案multidex，一个apk可以包含多个dex文件。通过Multidex.install(this)完成dex文件的加载。

Tinker方案参考multidex实现原理，在编译时通过新旧两个Dex生成差异patch.dex。在运行时，将差异patch.dex重新和原始安装包的旧Dex合并还原为新的Dex。这个过程可能比较耗费时间与内存，所以tinker单独放在一个后台进程:patch中处理。为了补丁包尽量的小，微信自研了DexDiff算法，它深度利用Dex的格式来减少差异的大小。由于采用ClassLoader机制，所以需要app重启。

Tinker基于基版本利用自研的DexDiff算法生成差分包，放在后台。App启动时下载差分包，与原dex重新合并，解压缩，并参考MultiDex.install()流程，重新安装app。

由于类加载实现原理涉及dex文件的重新解压缩合并等处理，消耗内存大，耗时长，在系统低内存时容易导致热更新失败，腾讯测试成功率大概为95%。实际热部署时，差分包应文件大小最小。

综上没有完美的热更新方案，没有100%的热更新成功率。目前，腾讯tinker基本可以满足app的热更新需求，但随着app用户规模不断增大，业务需求日益复杂，可考虑阿里的sophix商业方案，sophix同时应用类加载和底层替换两种方案，具有底层替换的修改及时性，和类加载方案的兼容性等优点。而且sophix采用非侵入打包，图形化的生成补丁，用阿里的原话说就是“傻瓜式接入”，点一点鼠标就能生成补丁文件，而且阿里提供了后台补丁管理系统，帮助开发者在生成补丁后直接上传至阿里的后台，无需开发者在自己的app和服务端做任何的操作。

“热部署” – 方法内的简单修改，无需重启app和Activity。 “暖部署” – app无需重启，但是activity需要重启，比如资源的修改。 “冷部署” – app需要重启，比如继承关系的改变或方法的签名变化等。 

热更新究竟是什么？

有一些这样的情况， 当一个App发布之后，突然发现了一个严重bug需要进行紧急修复，这时候公司各方就会忙得焦头烂额：重新打包App、测试、向各个应用市场和渠道换包、提示用户升级、用户下载、覆盖安装。有时候仅仅是为了修改了一行代码，也要付出巨大的成本进行换包和重新发布。

这种需要替换运行时新的类和资源文件的加载，就可以认为是热操作了。而在热更新出现之前，通过反射注解、反射调用和反射注入等方式已经可以实现类的动态加载了。而热更新框架的出现就是为了解决这样一个问题的。从某种意义上来说，热更新就是要做一件事，替换。当替换的东西属于大块内容的时候，就是模块化了，当你去替换方法的时候，叫热更新，当你替换类的时候，加热插件，而且重某种意义上讲，所有的热更新方案，都是一种热插件，因为热更新方案就是在app之外去干这个事。就这么简单的理解。无论是替换一个类，还是一个方法，都是在干替换这件事请。。这里的替换，也算是几种hook操作，无论在什么代码等级上，都是一种侵入性的操作。

所以总结一句话简单理解热更新 HotFix 就是改变app运行行为的技术！(或者说就是对已发布app进行bug修复的技术)

目前存在的主流框架？

先后出现了Dexposed、AndFix,Qzone超级补丁的类Nuwa方式，微信的Tinker, 大众点评的nuwa、百度金融的rocooFix, 饿了么的amigo以及美团的robust.以及阿里的Sophix.腾讯的内部方案KKFix.

框架横向对比？

 

 

 

实现套路？

 

 

 

 

对比点评？

AndFix作为native解决方案，首先面临的是稳定性与兼容性问题，更重要的是它无法实现类替换，它是需要大量额外的开发成本的；

Robust兼容性与成功率较高，但是它与AndFix一样，无法新增变量与类只能用做的bugFix方案；

Qzone方案可以做到发布产品功能，但是它主要问题是插桩带来Dalvik的性能问题，以及为了解决Art下内存地址问题而导致补丁包急速增大的。

特别是在Android N之后，由于混合编译的inline策略修改，对于市面上的各种方案都不太容易解决。而Tinker热补丁方案不仅支持类、So以及资源的替换，它还是2.X－8.X(1.9.0以上支持8.X)的全平台支持。利用Tinker我们不仅可以用做bugfix,甚至可以替代功能的发布

类加载机制？

我们知道Android系统也是仿照java搞了一个虚拟机，不过它不叫JVM，它叫Dalvik/ART VM他们还是有很大区别的（这是不是我们的重点, 点开是个拓展阅读)。我们只需要知道，Dalvik/ART VM 虚拟机加载类和资源也是要用到ClassLoader，不过Jvm通过ClassLoader加载的class字节码，而Dalvik/ART VM通过ClassLoader加载则是dex。

Android的类加载器分为两种,PathClassLoader和DexClassLoader，两者都继承自BaseDexClassLoader

PathClassLoader代码位于libcore\dalvik\src\main\Java\dalvik\system\PathClassLoader.java 

DexClassLoader代码位于libcore\dalvik\src\main\java\dalvik\system\DexClassLoader.java 

BaseDexClassLoader代码位于libcore\dalvik\src\main\java\dalvik\system\BaseDexClassLoader.java

PathClassLoader

用来加载系统类和应用类

DexClassLoader

用来加载jar、apk、dex文件.加载jar、apk也是最终抽取里面的Dex文件进行加载.

 

 

 

归纳一下就是:ClassLoader会遍历这个数组,然后加载这个数组中的dex文件. 

而ClassLoader在加载到正确的类之后,就不会再去加载有Bug的那个类了,我们把这个正确的类放在Dex文件中,让这个Dex文件排在dexElements数组前面即可.

 

 

 

为什么推荐Sophix?

为了提升产品在敏捷开发下的最佳发布体验，分别尝试了备受关注的阿里和微信两大派系的热更新方案（支付宝的Andfix和微信的Tinker），但在探索的过程中，发现两种方案都存在弊端，如使用场景有限，修复成功率低，存在兼容问题。加之各方案还在内部快速迭代，均未能达到商业化的标准，所以热修复在项目中的应用被暂时搁置了。

       直到最近，看到阿里推出了非侵入式热修复框架Sophix。Sophix对其前辈Andfix，阿里百川Hotfix等方案进行了升级改造，打破了旧方案诸多限制，涵盖了代码修复，资源修复，So库修复。加上阿里云平台的支持，经过简单的配置就可接入使用，目之所及，Sophix已经成为目前成熟度最高的热修复框架。这也让我重新燃起了对热更新及底层技术探索的热情。所以我想以此为契机，用系列文章的形式，围绕热点技术所涉猎的知识进行由浅入深的持续挖掘。

 

 

 

修复立即生效，是热修复所追求的，底层替换方案通过在运行时利用hook操作native指针实现“热”的特性。但这里有一个关键点，底层替换所操作的指针，实际上是ArtMethod，在类被加载，类中的每个方法都会有对应的ArtMethod，它记录了方法包括所属类和内存地址信息，Andfix正是通过篡改ArtMethod，将补丁方法ArtMethod的成员值逐一赋给旧方法，实现替换。问题就出现在这个逐一上。因为Andfix的ArtMethod方法结构是根据Android开源代码写死的，面对国内厂商的定制，经常会导致两者ArtMethod方法结构不一致，这也是兼容问题产生的根本原因。

       为了解决这个问题，Sophix采用了对旧ArtMethod进行完整替换，通过动态测量ArtMethod的size（通过c层的mempy(dest ,src ,size)方法），进行全量拷贝。这样做无论ArtMethod被修改成什么样，只需要统一执行拷贝，就可以完成替换，完全无视修改虚拟机导致的ArtMethod结构差异.

 底层替换虽能使修复即时生效，但由于类加载后，方法结构已固定，这就造成使用上会有诸多限制。相反类加载方案的使用场景更为广泛。Sophix使用类加载作为兜底方案。在热部署无法使用的情况下，自动降级为冷部署方案。

       无论是冷部署还是热部署，都需要通过同一套补丁兼顾，在Art虚拟机下，默认支持多dex加载，虚拟机会优先加载命名为classes.dex的文件。Sophix利用了这一点，将补丁文件命名为classes.dex，并对原有dex文件进行排序。这样一来，art虚拟机就会先加载补丁文件，后续加载的同类名的类会被忽略，最后将加载得到的dexFile把dexElements整体替换。

 

 

 

 

      Dalvik虚拟机下情况则有些不同，Dalvik默认只加载classes.dex，其他dex则被忽略。那么，Sophix就需要一个全量dex，前面提到tinker采用自主研发的dexDiff技术，从方法和指令的维度进行dex合成，但Dex合成过程发生在虚拟机堆内存上，修复的成功率极大的受到性能问题的影响。为了解决这个问题，Sophix换了一种思路，从类的维度，对照补丁包中出现的类，在原有包中做删除操作，如图。

 

 

 

   为了避免删除整个类信息而导致dex结构发生偏移，所以只对旧包中类的入口进行删除，实际上类的信息还在dex包中。这样一来，冷启动后，原有的类就不会被加载，相比Tinker的合成方案，Sophix的思路更为轻量化。

       至此，对Sophix对类文件修复的基本原理描述完毕。可以说Sophix吸取了百家之长，对问题的解决之法堪称巧妙。但在惊叹阿里技术底蕴的同时，也展现出底层技术的重要性，若没有对虚拟机等底层技术的深耕探索，在系统框架的纷繁规则面前，也只能至于庭前止步。