APP-热修复都懂了那你会-SDK-热修复吗？最全的方案在这里！

1. 比较适合主包变动小的情况；
2. 主包和子包耦合性强；
3. 还是需要用到反射。

方案二：插件化

步骤

将SDK分包，宿主包仅提供 API 和加载核心实现的插件包，插件包就可以热更了。

优缺点

优点：

1. 灵活

缺点：

1. 对主项目工程的依赖太大，往往一些基本配置需要依赖于主工程的项目源码；
2. 使用接入成本高，配置麻烦，而 SDK 的业务接入方需要的是快速接入；
3. 插件化框架可能会对系统原生代码的运行造成不可预估的影响；
4. 不得不依赖很多不需要的插件化框架功能。

方案三：业务方热更

走投无路之下，我想起，诶！很多 app 热更方案不是说支持 lib 热更吗！那先作为一个保底方案吧。

步骤

通过业务方 app 热更 lib 包。

优缺点

优点：

1. 热更权把控在业务方手中，对业务方透明

缺点：

1. lib 包太大时，下载还是很耗流量的
2. diff 算法无法计算新旧 lib 的差异，只能整个替换掉
3. 步骤相当繁琐，如下图：

方案四：改造现有 APP 热修复方案

1. 那在选择热修复方案时考虑点有哪些？

1. 热更项目的需求

• 只需要简单的方法级别 Bug 修复？
• 需要资源及 so 库的修复？
• 需要 Native 的修复？
• 对平台兼容性要求及成功率要求？