大家好，我叫祥子😊；

本人15年毕业于广东药科大学，于2018年8月加入37手游安卓团队，曾经就职于网易担任安卓开发工程师；

目前是37手游安卓团队负责人，除日常团队相关管理外，空闲喜欢专研安卓相关技术，因为始终坚信 “技术管理" 是一定要持续关注技术，保持对技术的热情，这样才不会是空中楼阁...

同时也针对理论做了个实战Demo巩固相关知识：安卓热修篇-插桩式插件化方案-Demo篇

现在我们结合前面所学的知识，怎么把热修技术应用在SDK，投入生产；

（1）业务提需求，修改SDK，以支持业务功能

（2）技术接到需求，进行开发/测试/发版本等

（3）业务上线，把带有新SDK内容的安卓包上架，用户下载使用

从上面的流程可以看出，当下模式有几个短板：

这里是一个虚拟出来的demo工程，和实际项目类同，不影响讲解思想

假设我们的SDK项目工程如下：

对应的依赖关系如下：

app模块：模拟客户的应用工程，使用SDK测试等

SDK相关：

在发布状态下，会把（sqsdk模块 + features1模块 + features2模块）导出aar或者jar的方式，给到客户使用（也就是app模块）

修改需要满足哪些条件？

对内，兼容没有修改前SDK的迭代流程（因为实际的项目中，是多人协作的，日常生产不断迭代，不可能因为热修版本，而让日常的迭代停滞，等热修版本好了之后再迭代日常内容）
对外，客户的交互层方面，老的接口不修改（因为很多客户都在用），同时确保最后，给客户接的SDK只有一套，而不是两套

接下来看下工程架构的变化～

sqsdk模块 + features1模块 + features2模块(插件)

pluhost 模块(宿主)

这个是一个宿主模块，主要作用如下：

commonpluhostandsqsdk 模块

这个模块是插件和宿主的公共模块，主要是一些接口兼容等内容（下面会说，这里先留个概念先）

其他模块（plugin等不展开，具体可以看下面的工程源码）

模块分类大致如上，那么现在来看看模块的依赖关系：

红色框

简介：这是一个插件模块
工程方面：以前是一个lib模块，导出aar/jar方式给客户直接使用；现在是一个app模块，导出一个插件apk的方式，给到宿主使用；
接口方面：以前是暴露《SqWanCore》给客户使用；现在不直接对外（客户），而是给宿主调用，所以里面的对外类会修改（《SqWanCore》改为《SqWanCoreImpl》作为实现者）

蓝色框

绿色框

过程中有问题或者需要交流的同学，可以扫描二维码加好友，然后进群进行问题和技术的交流等；