1为什么需要热更新？
正常开发流程：
新版本上线，发现问题或用户反馈bug，紧急修复，上线版本，用户重新安装。
存着如下问题：
l 周期长
l 用户下载成本高，app推广成本高昂
l 修复不及时，用户体验差，用户遇到奔溃时失去耐心后直接卸载。
热修复流程：
新版本上线，发现问题或用户反馈，紧急修复，上线补丁，自动修复
存着如下优点：
l 无需重新发版，及时修复问题
l 用户无感知修复，无需下载新应用，代价小
l 修复成功率高，把损失降到最低
但热修复因为大量涉及android底层知识，又因为android本身开源，华为vivo小米几大厂商都可能修改底层相关代码，兼容性困难，所以热修复技术开发维护难度巨大，人力和时间投入不菲。目前主要有腾讯，阿里等几家互联网大厂因自身刚性需求，实现此功能。
目前热修复技术主要有以下几家：
腾讯系：
QQ超级补丁
**tinker **
阿里系：
Xposed (不支持Art虚拟机，已废弃)
Andfix (native hook兼容差，适配机型少)
Sophix 新一代
饿了吗：
amigo
美团：
robust 每个函数插入额外逻辑
以上几家热修复技术都各有优缺点，也各说各的好。因此我们在引入时需要从代码侵入性，修复实时性，兼容，支持力度等几个维度综合评估。
虽然热修复在android生态圈目前呈现百花齐放的态势，但追根溯源热更新实现的基本原理，可以划分为以tinker为代表的multidex类加载法和以阿里andfix为代表的底层替换法，而阿里sophix为了提高热修复的成功率同时采用了上述两种方案，并在兼容性上进行了一定的优化。
2底层替换方案：
2.1我们首先以andfix为例，简答介绍底层替换方案。
底层替换是在已经加载了的类中直接在native层替换掉原有方法，见下图。
Andfix核心函数replaceMehtod，它的参数是在java层通过反射机制得到的method对象对应的jobject。Src对应的是需要被替换的原有方法，dest对应的是新方法。
具体替换以art虚拟机为例，通过替换java对象的数据结构ArtMehtod的所有成员。
Andfix逐个替换方式
Sophix整体替换方式
2.2
由于底层替换原理只支持方法替换，不支持方法的增加和减少，成员字段的增加和减少，所以我们需要知道哪些修改会导致方法，字段的改变，从而底层替换热部署失效。
a 非静态内部类
非静态内部类编译后实际和外部类一样都是顶级类。外部类为了访问内部类的private field method，内部类额外会添加access方法。
b 匿名内部类
匿名内部类编译后名字命名规则为外部类&number ,number根据匿名内部类在外部类出现的先后次序依次累加。如果将匿名内部类的次序调整，我们无法区分修改前后的差异的。
c 静态field 静态代码块
这2块是被编译器翻译在clinit方法中，clinit方法是在类加载阶段调用，导致热部署方案失效。
d final static 域
代码中变量i2, s2这两个静态域没有被初始化在clinit中，而是在dvmInitClass的initSFields方法中，这个方法在clinit之前执行。
此外泛型，lambda函数的修改都有可能导致热部署失效，这些都需要我们对android虚拟机的编译有一定了解，在此我们不再赘述。
所以底层替换方法限制较多，但优点是实现热部署，修改及时生效。
3 Multidex类加载法：
接着我们以tinker为例，简单介绍multidex类加载方案。
3.1 64K事件
在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重启。
3.2 Multidex.install()流程
我们分析下android的Multidex.install()的流程
MultiDex.install()在app最初启动时被调用。
Install() 实现获取DexClassLoader 解压缩dex文件，根据不同的平台版本加载补丁。
我们以V19.install为例，根据注释我们可以知道它通过反射将多余的dex file 添加到DexPathList的pathList数组字段里。
我们查看DexPathList类确实如此。
那为什么通过添加就能够实现多dex文件的合并呢？
重点我们需要看下makeDexElements这个函数做了什么处理。
这个函数通过反射调用了DexPathList的makeDexElements, 我们继续跟踪makeDexElements具体实现，发现它调用了loadDexFile.
我们继续跟踪loadDexFile, 发现最终它调用DexFile.loadDex(); 我们重点看下该函数的注释如下。
我们继续跟踪发现已经到DexFile的C++ 部分，内部是对dexfile处理的具体实现，在此我们不再叙述。
通过对MultiDex.install()流程的跟踪，我们基本可以了解腾讯tinker的热更新原理。Tinker基于基版本利用自研的DexDiff算法生成差分包，放在后台。App启动时下载差分包，与原dex重新合并，解压缩，并参考MultiDex.install()流程，重新安装app。
我们查看Tinker的核心源码确认基本按照这个思路实现，如下为tinker加载的核心函数。
由于类加载实现原理涉及dex文件的重新解压缩合并等处理，消耗内存大，耗时长，在系统低内存时容易导致热更新失败，腾讯测试成功率大概为95%。实际热部署时，差分包应文件大小最小。
综上没有完美的热更新方案，没有100%的热更新成功率。目前，腾讯tinker基本可以满足app的热更新需求，但随着app用户规模不断增大，业务需求日益复杂，可考虑阿里的sophix商业方案，sophix同时应用类加载和底层替换两种方案，具有底层替换的修改及时性，和类加载方案的兼容性等优点。
注：此文主要介绍底层替换和类加载技术两种方案，但对于热更新我们还需要了解dalvik, art虚拟机下app优化，安装的原理和差异，android类加载PathClassLoader,DexClassLoader原理, android文件校验机制等，在此我们不再赘述。
引用：
《深入探索android热修复技术原理》手淘技术团队
<u>http://blog.csdn.net/jason0539/article/details/50440669</u>
<u>https://jaeger.itscoder.com/android/2016/08/27/android-classloader.html</u>
<u>http://blog.csdn.net/nanzhiwen666/article/details/50515895</u>
<u>https://github.com/Tencent/tinker</u>
Android 5.1 source code
