热修复原理

热修复是一种在出现大bug的时候进行一种无须发版就能修复的一种技术，就能修复代码的bug，也能修复资源的问题和so库的问题，热修复的框架也有很多，主要还是阿里和腾讯的热修框架比较流行，主要介绍2种：

一：阿里的AndFix

原理：这里用到最核心的知识点就是在native层获取到指定方法的结构体，然后改变他的nativeFunc字段值，而这个值就是可以指定这个方法对应的native函数指针，所以先从Java层跳到native层，改变指定方法的nativeFunc值，然后在改变之后的函数中调用Java层的回调即可。实现了方法的拦截功能

优点：

即时生效
支持dalvik和art（AndFix supports Android version from 2.3 to 7.0, both ARM and X86 architecture, both Dalvik and ART runtime, both 32bit and 64bit.）
与Dexposed框架相比AndFix框架更加轻便好用，在进行热修复的过程中更加方便了
缺点：

面临稳定性与兼容性问题
AndFix不支持新增方法，新增类，新增field等

AndFix（Dexpsed）框架不稳定的原因（痛点）

二 腾讯的Tinker

服务端做dex差量，将差量包下发到客户端，在ART模式的机型上本地跟原apk中的classes.dex做merge，merge成为一个新的merge.dex后将merge.dex插入pathClassLoader的dexElement，原理类同Q-Zone，为了实现差量包的最小化，Tinker自研了DexDiff/DexMerge算法。Tinker还支持资源和So包的更新，So补丁包使用BsDiff来生成，资源补丁包直接使用文件md5对比来生成，针对资源比较大的（默认大于100KB属于大文件）会使用BsDiff来对文件生成差量补丁。

优点：

支持动态下发代码
支持替换So库以及资源
缺点：

不能即时生效，需要下次启动
Tinker已知问题：

Tinker不支持修改AndroidManifest.xml，Tinker不支持新增四大组件(1.9.0支持新增非export的Activity)；
由于Google Play的开发者条款限制，不建议在GP渠道动态更新代码；
在Android N上，补丁对应用启动时间有轻微的影响；
不支持部分三星android-21机型，加载补丁时会主动抛出"TinkerRuntimeException:checkDexInstall failed"；
对于资源替换，不支持修改remoteView。例如transition动画，notification icon以及桌面图标。
Tinker性能痛点：

Dex合并内存消耗在vm head上，容易OOM，最后导致合并失败。
如果本身app占用内存已经比较高，可能容易导致app本系统杀掉。