优秀框架源码分析系列(一)让解耦更轻松!多进程组件化框架-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调用。其核心是通过LocalRouterWideRouter两个类来实现。

路由器(LocalRouterWideRouter

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

这里分别给出LocalRouterWideRouter中route方法的逻辑图,以便更好的理解。

LocalRouter.route()

WideRouter.route()

路由器守护服务(LocalRouterConnectService、WideRouterConnectService)

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

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运行在一个进程中。当我们需要新开发某个组件的时候,只需要按组件的实际功能实现ActionProvider以及Logic即可。如果是跨进程组件,还需要扩展实现LocalRouterConnectService

总结

组件化提出已经很久了,它可以从很多方面解决我们实际项目开发中的问题,无论是技术上的实现问题,还是人员组织结构和项目分工上,都提供了很好的方式。换句话说,因为在架构上解决了耦合问题,使得项目开发的组织上也可以很轻松的实现解耦,不失为一举两得。在此,我们再重复一下组件化框架解决的几大问题:

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

源码地址

下面是项目的源码地址:

ModularizationArchitecture源码

我读了一遍后,做了些简单的Bug修复,下面这个是我fork后的地址:

修改后的ModularizationArchitecture

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

题目征集

大家有想了解的优秀框架,也可以私信我。我会筛选关注度高的框架进行解读。感谢大家的关注和支持!

小铭出品,必属精品

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

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值