基础组件:支撑上层业务组件运行的基础业务服务。
基础 SDK:完全业务无关的基础代码。
各层次职责清晰独立,可以很方便的进行拆解和组合;由于都有自己的版本,业务线可以独立发版,随时升级、回滚。
基本解耦方案
组件化的第一步就是对要拆出去的组件进行解耦,常见解耦方式有以下几种:
(1) 公用代码处理
-
基础业务逻辑分别拆成基础组件
-
自身逻辑完整、用于完成某一特定功能、不含业务逻辑的一组代码,独立成 SDK
-
代码量很小不足以拆分成单独拆分的代码和资源,我们统一放在一个专门建立的 common 组件中,并且严格限制 common 组件的增长。随着组件化的逐渐进行,common 应该逐渐变小而不是增大。
-
碰巧被共同使用的一些代码和资源片段,通常它们被复用只是因为被开发人员搜索到而直接使用了,很多时候某个资源已经被 A 业务声明了前缀,但是由于没有隔离,仍然会不可避免的被他人在 B 业务中强行复用,这时候如果 A 业务方要进行一些修改,B 业务就会受到影响 —— 这种情况我们允许直接复制
(2) 初始化
有些组件有在应用启动时初始化服务的需求,而且很多服务还是有依赖关系的,最初我们为每个组件都添加了一个 init() 方法,但是并不能解决依赖顺序问题,需要每个组件都在 app 工程中按顺序添加初始化代码才能正常运行,这使得不熟悉整套组件业务的人很难建立起一个可以独立运行的组件 app。因
《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》
【docs.qq.com/doc/DSkNLaERkbnFoS0ZF】 完整内容开源分享
此我们开发了一套多线程初始化框架,每个组件只要新建若干个启动 Task 类,并在 Task 中声明依赖关系即可:
App 只需知道自己依赖什么组件即可,在编译 app 时 gradle 插件会自动定位到所有的 Task,并运行时生成依赖图,按依赖顺序启动 Task:
这样就解决了组件在主工程中堆积初始化代码的问题,在简化了代码的同时还有加快启动速度的功效。
(3) 路由
界面间使用 Url 进行跳转,不但实现了解耦,也统一了各端的页面打开方式。我们实现了一套灵活小巧的路由框架 ZRouter,它支持多组件、路由拦截、AB Test 、参数正则匹配、降级策略、任意参数传递以及自定义跳转等功能,可以自定义路由的各个阶段,完全满足了我们的业务需求。
(4) 接口
除了页面间的跳转,不同业务之间不可避免的会有一些调用,为了避免组件的直接通信,通常都是使用接口依赖的方式。我们实现了一个 Interface Provider 来支持接口通信,它可以通过运行时在动态注册一个接口,同时也实现了对于 ServiceLoader 的支持。只要一方组件将通信接口暴露出来,使用方就可以直接使用接口进行调用。
动态注册接口
Provider.register(AbcInterface.class,new AbcInterfaceImpl())