解耦框架 ModularizationArchitecture 学习解析

ModularizationArchitecture Demo结构分析

引导

作者对于框架结构的思考：

http://blog.spinytech.com/2016/12/28/android_modularization/

项目Github地址：https://github.com/SpinyTech/ModularizationArchitecture

项目的使用：

http://blog.spinytech.com/2017/02/01/ma_get_start_cn/

解耦和框架的原则

1.     单一职责，意味着一个模块、一个组件只做一件事，绝不多做。

2.     正交性，意思是不重复，一个模块跟另一个模块的职责是正交的，没有重叠，组件也是一样。

3.     单向依赖，模块之间最多是单向的依赖，如果出现A依赖B，B也依赖A，那么要么是A、B应该属于一个模块，要么就是整体的拆分有问题。一个完整的软件系统的模块依赖应该是一张有向无环图。（当然这是最终理想=。=）

4.     紧凑性，模块、组件对外暴露的接口、属性应该尽可能的少，接口的参数个数也要少。

5.     面向接口，模块、组件对外提供服务时最好是面向接口的，以便后期可以灵活的变更实现。

关键词

l  主App Module：Android studio中的可运行的Module，项目的主Module

l  模块Library Moudule：Android studio中的Library Module，模块化中的单一业务或功能组件

l  测试App Module：Android studio中的可运行的Module，用于测试某一个模块Library的可运行的壳子Module

l  Action：跨模块调用的具体实现

l  ActionResult：Action调用后返回的结果

l  Provider：Action簇，将一组Action放到一起，便于注册

l  RouterRequest：调用Action时的请求信息

l  RouterResponse：Action调用完成之后的响应信息

l  LocalRouter：单进程本地局域路由器

l  WideRouter：多进程广域路由器

l  LocalRouterConnectService：本地路由器Service，用于和广域路由器连接，进行AIDL跨进程通信

项目结构分析：

整体项目结构框架

项目框架：

分析：

这里我们有一个主的 moudule main，它相当于一个皮包公司，所有业务都通过一个中介router公司，将业务外包出去给对应的外包module，外包的module完成独立的功能。按照单向依赖原则，所有的外包module如果和其他外包module或者和我们的皮包公司有业务往来都不能直接去找对方公司的人，都必须依赖中介router。这就是控制反转的思想。

外包mudule：在外包module中，根据面向接口的原则，外包module暴露给中介router的都是一些接口方法，在这个项目里，通过action来对module要暴露出去的功能进行相应的封装，而内部调用就正常调用就好了。为了能把自己的外包业务功能告诉雇主，他自己要把功能项列成一个map然后提供给中介router。

中介router：在中介router那里，外包module还需要将自己的module名提供给中介router，让主module在订购功能的时候可以查询到对应的外包module。

请求流程：

分析：

在这个流程为皮包公司app在调用外包module的action业务的整体流程：

皮包公司A先去中介router那里查询能实现对应功能的皮包公司module。中介router通过查询注册到自己那里的外包公司module之后去查看外包公司给自己的业务清单provider，找到对应业务action之后。让后中介公司router就可以直接命令外包公司module去执行action动作，并获得对应的结果，然后再将结果发送给皮包公司app。整套流程调用完毕。

 

Demo分析

总览module

对于module的分析

maindemo

AsyncAction picdemo