Android 热修复实现原理

1、热修复背景

• 当发布的版本出现小 Bug 需要及时修复的时候，如果按照传统的方式，这就需要去解决 Bug、测试打包重新发布，而用户也需要重新安装你发布的新版本才能解决这个 Bug，使用这个时候可以使用热修复去进行及时修复，而且不需要发布新的版本，只需要发布补丁包，在客户不知不觉间修复掉 Bug。
• 个人认为现在市面上比较成熟稳定的热修复技术方案只有两种：

对比	Bugly	Sophix
前世今生	腾讯在 Tinker 基础上开发的商业级框架 Bugly	阿里的 AndFix 基础上开发的商业级框架 Sophix
及时生效	否，仅支持冷启动修复	是，支持实时修复和冷启动修复
方法替换	是	是
类替换	是	是
类结构修改	是	否
资源替换/更新	替换	更新
so 替换/更新	替换	更新
支持 gradle	支持	不支持
支持 ART	支持	支持
支持 Android 7.0	支持	支持
地址	Tinker-GitHub 、Bugly 接入文档	Sophix 接入文档

2、Instant Run 概述

• Instant Run 是 Android studio 2.0 以后新增的一个运行机制，能够显著减少开发人员第二次及以后的构建和部署时间。
  
• 通过上图可以看出传统的编辑部署需要重新安装和重启 App，这显然会很耗时，而 Instant Run 的构建和部署都是基于更改的部分的，且无需重新安装 App。
• Instant Run 部署有三种方式：
• （1）Hot swap（热插拔）：效率最高的部署，代码的增量改变不需要重启 App，甚至不需要重启当前的 Activity。修改一个现有方法的代码时会采用该方式。
• （2）Warm swap（热交换）：App 不需要重启，但是 Activity 需要重启。修改或删除一个现有的资源文件可采用该方式。
• （3）Cold swap（冷交换）：App 需要重启，但是不需要重新安装。采用该方式的情况很多，例如添加、删除和修改一个字段和方法，添加一个类等。

3、类加载

• 双亲委派模型的工作流程：当某个类加载器在加载类时，首先将加载任务委托给父类加载器，依次递归，如果父类加载器可以完成类加载任务，就成功返回，只有父类加载器无法完成此加载任务或者没有父类加载器时，才自己去加载。（启动类加载器 > 扩展类加载器 > 应用程序类加载器 > 自定义类加载器）
• 注意：之所以说双亲委派模式是因为它的一个机制对咱们热修复很重要，那就是避免重复加载，父类已经加载了，则子 ClassLoader 没有必要再次加载。
• Android 平台上虚拟机运行的是Dex字节码，一种对 class 文件优化的产物，Java 源文件可以通过 javac xxx.java 编译生成一个 .class文件，而 Android 是把所有 Class 文件进行合并和优化，然后生成一个最终的 class.dex，目的是把不同 class 文件重复的东西只需保留一份。如果我们的 Android 应用不进行分 dex 处理，这样一个应用的 apk 只会