热修复

【关于tinker的详细接入请看我的这篇文章】https://blog.csdn.net/Checkiming/article/details/85223118

Why use thermal fixes?
我们平时遇到刚上线不久的项目APP的bug崩溃或者影响用户体验的话，如果按照通常做法,那就是程序猿加班搞定bug,然后测试,重新打包并发布。这样带来的问题就是成本高,效率低。于是,热修复就应运而生.

What is HotFix?
HotFix（热修复）是针对某一个具体的系统漏洞或安全问题而发布的专门解决该漏洞或安全问题的小程序，通常称为修补程序

传统
这时候我们通常的处理流程是：解决bug、重新打包App、测试、向各个应用市场和渠道换包、提示用户升级、用户下载、覆盖安装。有时候仅仅是为了修改了一行代码，也要付出巨大的成本进行换包和重新发布，而且你难道不站在用户的角度看看这件事？这件事对于用户体验难道不糟糕吗？￣へ￣

初级解决方式:
在移动 App 开发里，可以动态部署达到热修复。例如某页面出现了 Bug ，后台服务器修改配置为采用 React Native 显示此页面，而有 Bug 的 Native 页面就隐藏了。等到下一次版本更新发到线上渠道，再采用 Native 展示此页面。

热修复的驳论:

• 运行时修复不用等待App重新启动,要是需要重启的话,就是冷修复了
• 发到线上的客户端，是没法及时修改的，但是服务器可以随时控制
• Deposed 和 Fix 都不能全部适配，各自的方案都有自己的优缺点，classloader 可以发挥更好用途，局部的更新倒是采用 andfix 这样类型的方案，感觉比较方便。

###Android虚拟机原理初读 **
一、ClassLoader
Android中的虚拟机 Dalvik/ART VM 不同于Java的JVM,二者之间的区别 当然这不是今天所要谈及的重点,我们只需辨别Dalvik/ART VM 虚拟机加载类和资源也是要用到ClassLoader，不过Jvm通过ClassLoader加载的class字节码，而Dalvik/ART VM通过ClassLoader加载则是dex就够了。
Android中的类加载器ClassLoader**分为两种,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文件进行加载。）

**二、热修复机制 **