本文介绍了如何将热修技术应用于SDK，以解决SDK迭代过程中的问题，如用户体验延迟、更新周期长等。文章详细描述了在没有热修前SDK的工程结构，并展示了在热修实现后，如何调整工程架构，包括新增宿主模块、插件模块和公共模块，以确保内部迭代不受影响，同时保持对外接口的一致性。
背景
前面我们了解了热修相关理论：安卓热修篇-Shadow思想篇-插桩式插件化
同时也针对理论做了个实战Demo巩固相关知识：安卓热修篇-插桩式插件化方案-Demo篇
现在我们结合前面所学的知识，怎么把热修技术应用在SDK，投入生产；
没有热修前，SDK迭代模式（业务侧）
（1）业务提需求，修改SDK，以支持业务功能
（2）技术接到需求，进行开发/测试/发版本等
（3）业务上线，把带有新SDK内容的安卓包上架，用户下载使用
从上面的流程可以看出，当下模式有几个短板：
- 正常情况下，新功能老用户体验不到
- 如果为了老用户体验，强制更新，那么用户损害较大
- 周期比较长，从内部开发到上线用户覆盖需要比较长的时间，影响业务营收速率
- 做A/B测试不方便
没有热修前，SDK的工程是怎么样的？
这里是一个虚拟出来的demo工程，和实际项目类同，不影响讲解思想
假设我们的SDK项目工程如下：
对应的依赖关系如下：
app模块：模
最低0.47元/天 解锁文章
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
