热更新热修复

热更新

热更新是一种各大手游等众多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.资源缓存策略，白屏问题