优秀框架源码分析系列（一）让解耦更轻松！多进程组件化框架-ModularizationArchitecture

写在前面

今天开始，我将陆续推出一系列的Android相关的优秀开源项目源码分析系列文章，每一期选取一个框架来进行分析解构。帮助你们更好的了解优秀框架的设计思想。分析的方式会选择从源码自己进行讨论，学习其设计思想，取长补短，每个设计都有它值得学习的地方，你们各取所需，我相信，不管是成功的经验，仍是失败的教训，都是同样有价值的。

ModularizationArchitecture概述

ModularizationArchitecture是一套Android完全组件化框架。它主要提供了如下几个功能：

• 进程间，进程内组件间的路由通讯机制
• 进程间，进程内组件行为功能的封装机制
• 组件的加载（初始化）、卸载机制
• 提供组件化核心基类

工程结构

• macore：组件化核心库
• maindemo：主程序（Host）
• musicdemo：播放器组件
• picdemo：图片组件
• webdemo：网页组件

组件的框架

每一个独立进程的组件，均需包含以下几个部分：

• Logic：组件的生命周期抽象模板，至关于组件的Application类
• Provider：一组组件行为的抽象，其内部包含一组Action。
• Action：组件行为，即对外提供的服务项（或称为最小粒度的功能点）
• RouterConnectService：多进程时，组件的守护服务

若是是非独立进程的组件，则只需包含以下几个部分：

• Logic：同上
• Provider：同上
• Action：同上

组件化内核之macore

macore提供了框架基础，为组件化提供基础功能。

组件间通讯机制

组件间通讯采用了C/S架构，跨进程通讯采用了Binder调用。其核心是经过LocalRouter和WideRouter两个类来实现。

路由器（LocalRouter、WideRouter）

本地组件间通讯经过LocalRouter来完成，进程间组件通讯是经过WideRouter来完成。若是是跨进程模式，WideRouter则独自运行在一个路由进程中。查看macore中的MaApplication.java中的startWideRouter()方法和AndroidManifest.xml不难发现，macore运行后会建立一个com.spiny.ma.widerouter的进程。

这里分别给出LocalRouter和WideRouter中route方法的逻辑图，以便更好的理解。

LocalRouter.route()

WideRouter.route()

路由器守护服务（LocalRouterConnectService、WideRouterConnectService）

路由器守护服务用来实现LocalRouter和WideRouter的双向互联。

LocalRouter做为组件的路由，既负责向WideRouter发送组件内部的跨进程调用，又负责接收来自WideRouter的跨进程调用。当其负责接收外部调用时，是做为C/S架构中的Service存在的，因此这个服务经过LocalRouterConnectService来提供。WideRouter经过LocalRouterConnectService向该组件发送请求，它是组件向外界提供能力的桥梁。

正如刚才说到的，WideRouter自己提供的对外功能就是为各个组件中转请求，实际上，它提供的就是一种路由服务，从这个层面上来说，它也是一个组件。因此它也须要一个Service向外提供服务，即WideRouterConnectService，其它的LocalRouter经过链接到这个服务，与WideRouter创建通讯通道。

在多应用多产品开发场景日益广泛的今天，在多个应用内同时引入ma框架，由多个WideRouter组成更大的组件化网络，也不失为一种策略。尤为是当咱们要对产品进行平台化演进时，将众多的基础功能服务以一个App的形式提供出去，暴露多种服务供其余应用调用的时候，组件化思想会为多模块，多应用并行开发提供可能。

组件生命周期

组件生命周期管理器（BaseApplicationLogic）

设计了一个包含相似Application同样的生命周期管理类，每个组件都实现一个这样的生命周期管理类，负责处理组件自己的初始化和去初始化动做。使用组件时，将这个生命周期类与应用的Application类进行绑定，这样组件的生命周期就和应用的生命周期绑定了。

组件其余辅助类

Wrapper

• PriorityLogicWrapper：在多组件的生命周期管理上，组件的加载可能须要维护必定的顺序以保证逻辑的正确性。PriorityLogicWrapper对管理器进行了包装，增长了一个优先级属性，这样，程序员只须要在最开始指定好优先级，就不用担忧在后续的维护过程当中因过失而使初始化失序。

• ConnectServiceWrapper：承载继承自LocalRouterConnectService的类。全部组件中实现的LocalRouterConnectService扩展类，都将在macore组件中被ConnectServiceWrapper包装起来。可能就是为了写起来方便吧。

Action、Provider

• MaAction：全部Action的基类。组件能够经过继承它实现本身对外提供的服务。
• MaProvider：全部Provider的基类。
• MaActionResult：服务调用在组件间传递的返回的结果类。
• ErrorAction：当请求的服务不存在或不可用时，默认返回的错误。

RouterRequest、RouterResponse

• RouterRequest：由调用方建立的，服务调用的请求封装类。其内部实现了相似消息池同样的数组。以保证对象建立更高效。
• RouterResponse：对调用结果的包装类，承载了调用的返回状况。其中包含了字符串化的MaActionResult。

MaApplication

扩展自Application的类，将组件化框架的基础组件初始化框架封装在其中。这样，框架的使用者无需关心框架的初始化细节，而只须要关注组件自己的生命周期便可。

主程序（Host）实现

Host是整个应用的Application实现部分，其余组件都是以Library的方式存在的。Host负责对其余组件进行注册，并将应用的生命周期和macore进行绑定。这些都在MyApplication中实现。

@Override
public void initializeAllProcessRouter() {
     WideRouter.registerLocalRouter("com.spinytech.maindemo",MainRouterConnectService.class);
        WideRouter.registerLocalRouter("com.spinytech.maindemo:music",MusicRouterConnectService.class);
        WideRouter.registerLocalRouter("com.spinytech.maindemo:pic",PicRouterConnectService.class);
}

@Override
protected void initializeLogic() {
        registerApplicationLogic("com.spinytech.maindemo",999, MainApplicationLogic.class);
        registerApplicationLogic("com.spinytech.maindemo",998, WebApplicationLogic.class);
        registerApplicationLogic("com.spinytech.maindemo:music",999, MusicApplicationLogic.class);
        registerApplicationLogic("com.spinytech.maindemo:pic",999, PicApplicationLogic.class);
}

@Override
public boolean needMultipleProcess() {
    return true;
}
复制代码

Host同时也是一个组件，其对外也一样提供服务。因此，它也对应实现了Logic,Provider以及一系列Action。因为开启了多进程模式，因此也实现了RouterConnectService，它扩展自LocalRouterConnectService。

其余组件

工程下还包含了其余几个示例组件：musicdemo、picdemo、webdemo。

其中musicdemo和picdemo均为单独运行在一个进程中的组件，而webdemo与maindemo运行在一个进程中。当咱们须要新开发某个组件的时候，只须要按组件的实际功能实现Action、Provider以及Logic便可。若是是跨进程组件，还须要扩展实现LocalRouterConnectService。

总结

组件化提出已经好久了，它能够从不少方面解决咱们实际项目开发中的问题，不管是技术上的实现问题，仍是人员组织结构和项目分工上，都提供了很好的方式。换句话说，由于在架构上解决了耦合问题，使得项目开发的组织上也能够很轻松的实现解耦，不失为一箭双雕。在此，咱们再重复一下组件化框架解决的几大问题：

• 代码解耦
• 代码隔离（可见性）
• 组件（功能模块）单独调试
• 集成调试
• 组件（功能模块）生命周期管理
• 组件间数据通讯

源码地址

下面是项目的源码地址：

ModularizationArchitecture源码

我读了一遍后，作了些简单的Bug修复，下面这个是我fork后的地址：

修改后的ModularizationArchitecture

最后，感谢Spiny Wang的优秀开源框架

题目征集

你们有想了解的优秀框架，也能够私信我。我会筛选关注度高的框架进行解读。感谢你们的关注和支持！

小铭出品，必属精品

欢迎关注xNPE技术论坛，更多原创干货每日推送。