Android架构之构建模块化、多进程的APP实践

正文

请到「今天看啥」查看全文

通过上图可以看到，我们在最基础的Common库中，创建了一个路由 Router ，中间有n个模块 Module ，这个 Module 实际上就是Android Studio中的module，这些 Module 都是 Android Library Module ，最上面的Module Main是 可运行的Android Application Module 。

这几个 Module 都引用了Common库，同时Main Module还引用了A、B、N这几个 Module ，经过这样的处理之后， 所有的 Module 之间的相互调用就都消失了，耦合性降低，所有的通信统一都交给Router来处理分发，而注册工作则交由Main Module去进行初始化 。这个架构思想其实和Binder的思想很类似，采用C/S模式，模块之间隔离，数据通过共享区域进行传递。模块与模块之间只暴露对外开放的Action，所以也具备 面向接口编程思想 。

图中的红色矩形代表的是行动 Action ， Action 是具体的执行类，其内部的 invoke方法是具体执行的代码逻辑 。如果涉及到 并发操作 的话，可以在 invoke方法内加入锁，或者直接在invoke方法上加上synchronized描述 。

图中的黄色矩形代表的是供应商 Provider ，每个 Provider 中包含1个或多个 Action ，其内部的数据结构以 HashMap 来存储Action。 首先HashMap查询的时间复杂度是O(1)，符合我们对调用速度上的要求，其次，由于我们是统一进行注册，所以在写入时并不存在并发线程并发问题，在读取时，并发问题则交由Action的invoke去具体处理。 在每一个 Module 内都会有1个或多个供应商 Provider （如果不包含 Provider ，那么这个 Module 将无法为其他 Module 提供服务）。

途中蓝色矩形代表的是路由 Router ，每个 Router 中包含多个 Provider ，其内部的数据结构也是以 HashMap 来存储 Provider ，原理也和 Provider 是一样的。之所以用了两次HashMap，有两点原因，一个是因为这样做， 不容易导致 Action 的重名 ，另一个是因为在注册的时候，只注册 Provider 会 减少注册代码，更易读 。并且由于HashMap的查询时间复杂度是O(1)，所以两次查找不会浪费太多时间。当查找不到对应 Action 的时候，Router会生成一个 ErrorAction ，会告之调用者没有找到对应的 Action ，由调用者来决定接下来如何处理。

一次请求流程

通过Router调用的具体流程是这样的:

Router时序图

请到「今天看啥」查看全文