安卓热修系列-Shadow-SDK实战篇

做者

你们好，我叫祥子😊； 

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

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

背景

前面咱们了解了热修相关理论：安卓热修篇-Shadow思想篇-插桩式插件化

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

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

没有热修前，SDK迭代模式（业务侧）

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

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

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

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

• 正常状况下，新功能老用户体验不到

• 若是为了老用户体验，强制更新，那么用户损害较大

• 周期比较长，从内部开发到上线用户覆盖须要比较长的时间，影响业务营收速率

• 作A/B测试不方便

没有热修前，SDK的工程是怎么样的？

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

假设咱们的SDK项目工程以下：

对应的依赖关系以下：

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

SDK相关：

• sqsdk模块：SDK和客户的交互层
• features1模块：SDK内部功能1的模块
• features2模块：SDK内部功能2的模块

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

代码戳这>>

热修实现，原来工程架构应该怎么调整？

修改须要知足哪些条件？

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

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

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

• 原SDK内容，这里把它当成一个插件；
• 这样作的缘由是，平常业务迭代通常改动的内容都是在这些地方，尽可能不去改动这一块的架构等，进一步实现上面说的《对内，兼容没有修改前SDK的迭代流程》；
• 那么这里要实现上面的，就有一个问题须要处理：怎么封装成插件？（下面会说，这里先留个概念先）

pluhost 模块(宿主)

这个是一个宿主模块，主要做用以下：

• 对内方面，加载插件，而且在客户调研接口的时候，调用插件的具体实现；同时导出aar或者/jar给到客户对接
• 对外方面，提供对外接口给客户

commonpluhostandsqsdk 模块

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

其余模块（plugin等不展开，具体能够看下面的工程源码）

模块分类大体如上，那么如今来看看模块的依赖关系：

红色框

• 简介：这是一个插件模块

• 工程方面：之前是一个lib模块，导出aar/jar方式给客户直接使用；如今是一个app模块，导出一个插件apk的方式，给到宿主使用；

• 接口方面：之前是暴露《SqWanCore》给客户使用；如今不直接对外（客户），而是给宿主调用，因此里面的对外类会修改（《SqWanCore》改成《SqWanCoreImpl》做为实现者）

• 注意：这里类的修改，是有技巧的，为了兼容之前的模式，那么会用到gradle插件方式修改，具体看下面源码模块的buildSrc

蓝色框

• 简介：这是一个宿主模块
• 工程方面：这个是新增长的一个模块，会引用插件apk，而且实现插件的加载
• 接口方面：这里会保持之前对客户的接口，也就是《SqWanCore》，而后客户能够不怎么修改直接兼容到；宿主里面则转调插件里面的具体实现

绿色框

• 简介：这是一个模拟客户的app工程
• 工程方面：依赖宿主导出的jar/aar，进行使用

代码戳这里>>

结束语

过程当中有问题或者须要交流的同窗，能够扫描二维码加好友，而后进群进行问题和技术的交流等；