早期架构的弊端

1、进程膨胀，容易被杀，导致推送不及时
2、65535、LinearAlloc
3、功能增多，原有架构上开发难以维护

组件化重构

image.png

拆分出了简单的组件化
但是之前交互都是通过事件总线进行交互，基类就定义了大量的Event
而且每次模块交互，比如数据结构的互相访问，都会进行下沉
久而久之，模块边界模糊
因此需要再次重构

组件间通信

曾考虑通过协议来通信，比如restful规范
但是双方都需要获知这个协议，维护不便
最终还是采用了最简单的方式
下沉接口
但是这里的实现非常巧妙
把希望暴露的接口，后缀修改成.api，再通过Gradle插件，自动新建一个工程，并拷贝这些.api类
这个思路令人赞叹

明确公共业务库职责

image.png

分别提供了核心账号状态（初始化、注销）、网络状态回调（链接建立）、存储状态生命周期（db创建、销毁、用户存储路径切换、sdcard挂起）
不可随便下沉代码于此

完善模块生命周期

image.png image.png

1、dependency阶段，主要解决一个模块依赖于另一个模块执行完成的前提下，这里指的是运行期的依赖，区别于编译期的依赖
2、configure阶段，通常用于初始化数据配置
3、execute，根据一个启动流程执行

模块内的代码边界

模块内部以页面维度隔离页面，通过设置project.properties指定依赖关系
通过这样的手段保证了代码边界

收获

1. 修改.java成.api即可暴露接口，这个思路可以说是最完美地暴露接口
2. 但是如何方便地实现接口呢？这点文中没提。建议采用Gradle插件的方式，给接口的实现类标注某注解，比如叫@Exposed，便可绑定联系
3. 给模块指定完善的生命周期，可以避免大量代码下沉到主流程
4. 代码边界的约束可以通过2个手段，第一，模块代码责任制，第二，用编译手段强制隔离

后记

学习自
https://mp.weixin.qq.com/s/6Q818XA5FaHd7jJMFBG60w

有什么写得错误、让人费解或遗漏的地方，希望可以不吝赐教，我会马上更改