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

Android @ 37手游

作者

大家好,我叫祥子😊; 

本人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,进行使用

代码戳这里>>

结束语

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

分类:
Android
标签:
分类:
Android
标签:
收藏成功!
已添加到「」, 点击更改