作者:潘辰星
来源:Android那些事
一、背景
Android 开发,从最初的一个人团队,我的地盘我做主,随着团队和业务逐渐变大,单App开发慢慢跟不上业务发展步伐。
代码复用性:再牛X的代码,不能给其他团队使用,其他团队无法使用,也不牛X。
业务稳定性:代码改动不可控,测试回归不可控,业务不稳定。
快速发射小卫星:业务要发布新App,一切从头开始,没有现成组件或模块可共用,刘欢唱起:大不了从头再来?
所以就走上Android 模块化之路。
二、小App向模块化App演变过程
模块化架构改造:
初期架构到后期架构
把原App中的网络、图片、UIKIT都放到MAVEN仓库。
抽离BaseActivity 和 公共资源到Common中
逐渐下沉业务Module,做到业务隔离。
做到第3步时,就面临着模块间跳转和路由的选型了。所以路由的选型, 传送门 : Android路由选型
搞定路由后,可以达到如下图的基础架构
模块化通用架构
然后新的问题也跟着来了!模块间通信和模块调用。
在前期抽业务模块过程中,如产品模块用到:获取购物车数量,或添加到购物车,就把这两个功能也下沉到Common中,慢慢就有形成一个万能的Common。
所以面临着模块间的通信和调用的选型,问题如下:三个飘着的气球,要把这几个气球给落地。
要落地的气球
Big Common :随着模块拆解越来越多,下沉的业务逻辑也会越来越多,大 Common 吾不想要!
Muti Module Call: 多模块间调用,不让下沉到Common,那就面临多模块间调用,就要寻找模块间调用的方案。
Be On Cloud: 在云端,上云,App上云的概念,第一步是让仓库代码可以被大家依赖调用到。而不是说:哥,你把我这代码拷走吧!把我的BigCommon拷走!(人家才不拷,你在依赖别人库时,多一个功能你都不想要呢)
三、模块间调用思路与方案
模块间调用思路
如果是WEB开发,对外声明接口,自己业务去实现接口,再暴露接口去调用具体业务的实现。
如上图所示,购物车模块对外提供两个服务:getCartCount 和 addToCart ,产品页面需要展示当前用户购物车的数量,以及把产品添加到购物车,那产品模块因为依赖了 ServiceCart,可以得到CartService的接口声明定义。
但怎么获取CartService的实例呢?
我相信CartService的实例一定存在世界某个地方,等我去发现。
现在模块化架构就变成如下图:
增加Service层
如上图,我们增加了一个Service层,这个Service层虽然画在了Common层上面,但并不依赖Common。
此时,我们要解决的就是 CartService 之我要找到你了!
四、CartService 之我要找到你
如果是服务端开发的话,会把CartService的实现集中注册到 Dubbo 或者 Spring中,通过某个Key得到一个Service的实例。
通过一个Key获得一个实例
前面路由的方案是:通过一个Key获取到一个路径。有点意思。经过比较,ARouter 和 自己通过AIDL来实现两套方案,对比如下:
选型标准
ARouter 使用运行时注解强大的功能,自建Map把 path
和 Service具体实例建立关联,跨模块可以轻轻松松地按照自定义路径取出实例调用。一项项来说明:
稳定性:大厂出品,稳定性都OK。
通用技术:第三方注解自建维护Map 和 Android AIDL服务调用,AIDL更通用。
跨进程:ARouter 不支持,而AIDL专为跨进程为生。
易适配:第三方App接入学习成本而言,ARouter还要学习下下,AIDL是Android开发必备技能,不用二次学习。
第三方App调用:系统其他App调用服务定义,ARouter不支持,AIDL 通过Service export= true 的情况下,还是可以支持的。
所以,我们考虑用AIDL Service的方式来实现。
这个时候,你怒了,哥,我裤子都脱了,你就给我看这个?
快 Show Me The Fucking Code!
五、代码秀
有请24位漂亮的女生登场!
漂亮女生登场
模块结构如下图:
示例代码结构截图
app: 客户端启动入口
module_product : 产品模块
module_shopcart: 购物车模块
service_shopcart: 购物车对外开放服务,通过上面截图可以看到已通过AIDL 声明了 IShopcartService
接口,并声明了 getCartCount
和 addToCart(String productId)
的能力。
看接口的实现如下:
AIDL的实现
上面的是不是最AIDL经典实现?还是原来的配方!还是原来的味道!红茶,我只要王老吉?
并在 AndroidManifest.xml
中声明Service如下:
同时,注明<intent-filter>
为:com.ssevening.www.service.shopcart.IShopcartService
,这个就是查找这个Service的Key,也是IShopcartService
的类路径。在 module_product
中的 ProductActivity
中如下方法调用:
跨模块调用服务
bindService
和 serviceConnection
还是熟悉的味道,但最上面的Intent 本应该 intent = new Intent(this,ShopcartService.class)
, 但ShopcartService
类定义在 module_shopcart
里面,所以我们新增了:getServiceIntent()
并把类名传递进去,然后通过getPackageManager().queryIntentServices(intent, 0);
查询出action=com.ssevening.www.service.shopcart.IShopcartService
的Service
,取第一个封装Intent对象,就可以正常调用AIDL服务了,还是原来的配方,还是原来的味道!
运行截图如下:
购物车数量和添加到购物车的结果都已显示出来,同时通过网络调用把 www.baidu.com
源码也成功返回。
至此,模块间调用基本方案敲定,余下的就是getServiceIntent()
方法的增强优化和下沉抽到Maven仓库的工作了。
最后,上次路由被坑了一次,详见:Android M queryIntentActivities return null list 蹲坑记 ,用户在App管理界面,可以关掉AppLinks的事,我还记得,所以这次特别去看一下context.getPackageManager().queryIntentServices(intent, 0);
代码截图如下:
queryIntentServices,通过看源码,我们发现并没有用户关掉相关的过滤选项,这样我们就放心了。
我们接着说模块间事件传递。比如 登陆状态的变化;在金币频道点击签到按钮,跳转到签到模块签到,签到完成后,回到金币模块签到成功的事情传递。
六、模块间事件传递
事件嘛,那肯定要对比 EventBus 和 广播,对比如下:
EventBus 和 广播对比
这样一对比,不用接第三方库就能实现,并且是Android通用方案,后期第三方接入和使用都方便,所以模块间事件传递就用:BroadcastReceiver
,这个连例子都不用写了。大家都懂的。
更多学习和讨论,欢迎加入我们的知识星球,这里有1000+小伙伴,让你的学习不寂寞~·
喜欢 就关注吧,欢迎投稿!