早期架构的弊端
1、进程膨胀,容易被杀,导致推送不及时
2、65535、LinearAlloc
3、功能增多,原有架构上开发难以维护
组件化重构
image.png拆分出了简单的组件化
但是之前交互都是通过事件总线进行交互,基类就定义了大量的Event
而且每次模块交互,比如数据结构的互相访问,都会进行下沉
久而久之,模块边界模糊
因此需要再次重构
组件间通信
曾考虑通过协议来通信,比如restful规范
但是双方都需要获知这个协议,维护不便
最终还是采用了最简单的方式
下沉接口
但是这里的实现非常巧妙
把希望暴露的接口,后缀修改成.api,再通过Gradle插件,自动新建一个工程,并拷贝这些.api类
这个思路令人赞叹
明确公共业务库职责
image.png分别提供了核心账号状态(初始化、注销)、网络状态回调(链接建立)、存储状态生命周期(db创建、销毁、用户存储路径切换、sdcard挂起)
不可随便下沉代码于此
完善模块生命周期
image.png image.png1、dependency阶段,主要解决一个模块依赖于另一个模块执行完成的前提下,这里指的是运行期的依赖,区别于编译期的依赖
2、configure阶段,通常用于初始化数据配置
3、execute,根据一个启动流程执行
模块内的代码边界
模块内部以页面维度隔离页面,通过设置project.properties指定依赖关系
通过这样的手段保证了代码边界
收获
- 修改.java成.api即可暴露接口,这个思路可以说是最完美地暴露接口
- 但是如何方便地实现接口呢?这点文中没提。建议采用Gradle插件的方式,给接口的实现类标注某注解,比如叫@Exposed,便可绑定联系
- 给模块指定完善的生命周期,可以避免大量代码下沉到主流程
- 代码边界的约束可以通过2个手段,第一,模块代码责任制,第二,用编译手段强制隔离
后记
学习自
https://mp.weixin.qq.com/s/6Q818XA5FaHd7jJMFBG60w
有什么写得错误、让人费解或遗漏的地方,希望可以不吝赐教,我会马上更改
网友评论