热更新
热更新是一种各大手游等众多APP常用的更新方式。简单来说，就是在用户下载安装APP之后，打开App时遇到的即时更新。
工作原理
热更新就是动态下发代码，它可以使开发者新版本的情况下，修复BUG和发布功能和发布功能，让开发者得以绕开苹果的审核机制，避免长时间的审核等待以及多次被拒造成的成本
一．热更新流程
1.线上检测到严重的crash
2.拉出不过fix分支并在分支上修复问题
3.Jenkins构建补丁生成
4.app通过推送或主动拉布丁文件
5.将bugfix代码合到master上
二．主流热更新框架介绍
1. Dexposed（用posed形式运作的）
2. AndFix（唯一的功能就是热修，性能好，提供完善的工具）
3. Nuwa
三．热更新原理
1. Android类加载机制
（1） .PatchClassLoader
（2） DexClassLoader
2. 热修复机制
（1） dexElements
（2） ClassLoader会遍历这个数组
1、什么是热更新、热修复？
打个比方，在一个App上线之后难免会出现BUG，发现BUG之后进行紧急修复，然后重新发布新版本。让用户重新下载。
这样太耗时间了，并且用户体验极差。如果是我，我肯定给它卸载了。
如果采用热更新、热修复技术，它会怎么做呢？开发者会把BUG紧急修复，然后打包成补丁，并且发布到服务器上，
然后用户开启App之后，应用程序会检测服务器上是否有补丁，如果有补丁，就先下载补丁，然后再通过类加载器和
反射机制和原始App进行融合。
2、它的替换方案和原理？
热修复和热更新的技术牵扯到安卓底层代码，由于安卓又是开源的，所以各大公司都有可能会修复它的底层代码，
导致兼容性难、维护费用巨大。各公司有各公司的热修复技术
有两家做的不错，一个是Tinker为代表的multidex类加载法，和阿里的andfix的底层替换法。
后来阿里综合了以上两种方式，并进行兼容。研究出了sophix方案，又提高了修复的成功率。
andfix底层替换：是在已加载了的类在native层替换掉原有方法，内部类、静态修饰都可能会对它有限制，但它能实现热部署，
修改即时生效。
multidex类加载：它是操控Dex文件，在编译时针对新旧两个Dex文件的差异生成一个patch.dex文件，然后在运行时，将
patch.dex文件和旧的dex文件合并成新的dex文件。它是比较耗内存和时间。
热更新的几种实现方式
一．动态库
使用OC/Swift原生实现
把需要集成的功能模块。打包成framework，通过网络下发到已经上架的APP中。
技术上是可以实现，可以做demo用。真实使用的时候会被苹果禁止。
因为打包发到AppStore的ipa安装包里的每个动态库都有唯一的编码，iOS系统会进行验证，所以动态通过网络获取新的动态库也用不了。
二．Hybrid
随着移动浪潮的兴起，各种APP层出不穷，极速的业务扩展提升了团队对开发效率的要求，这个时候使用IOS&Android 开发一个App似乎成本有点过高了，而H5的低成本，高效率，跨平台等特性马上被利用起来形成了一种新的开发模式：Hybrid APP
1. Hybrid的优点
Hybrid开发效率高，跨平台，低成本
Hybrid从业务开发上讲，没有版本问题，有BUG能及时修复
2. Hybrid的缺点
Hybrid体验就肯定比不上Native，所以使用有其场景，但是对于需要快速试错，快速占领市场团队来说，Hybrid一定是不二的选择，团队生存下来后还是需要做体验更好的原生APP
Hybrid APP底层依赖于Native提供的容器，上层使用Html&Css&JS做业务开发
3. 使用Hybrid要处理的问题
1. Hybrid中的Native与前端各自的工作是什么
2. Hybrid的交互接口如何设计
3. Hybrid的Header如何设计
4.Hybrid的如何设计目录结构以及增量机制如何实现
5.资源缓存策略，白屏问题
