android架构学习之组件化

背景：

新公司的项目采用了组件化，此前对组件化有过一些研究，但是相关的经验并不多，正好新的项目有实际运用，在此记录下组件化的学习与实践之路。网上组件化的文章很多，本人学习组建化的过程也借鉴了网上先辈们的文章。但大多数文章都从底层的细枝末节开始讲述，由下而上给人一种这门技术“博大精深”望而生畏的感觉。而我写这篇文章的初衷就是由上而下，希望别人在阅读的过程中能够觉得“组件化原来也就是这几个东西”的感觉。

正文：

1、本文主要内容

• 什么是组件化
• 组件化要解决的问题
• 组件的单独调试及集成
• 组件间通信
• 组件界面跳转
• 主项目获取并显示组件的Fragment
• 总结

2、什么是组件化

在编码的过程中，不管在哪个年代，模块分层一定是永恒的主题。首先，软件是由一个团队完成的，为了更好的更有效率的分工，模块分层必不可少。另外，模块分层更是为了减少耦合，易扩展同时维护时更省心省力。

例如Android的架构图，相信所有人都看过，从大的方面来讲它也是分层的，各层之间通过接口通信，比如C层和 Framework层之间，就定义了很多的JNI接口。

组件化，个人的理解就是更加精细一点的模块分层而已，它比模块来说，粒度更小而已，模块一般是指大的功能模块，比如首页模块、直播间模块。而组件它是一种功能更加单一的模块，例如支付组件等等。

模块化是业务导向，组件化是功能导向。

组件化基础架构图

上面是一个非常基础的组件化架构图，图中从上向下分别为应用层、组件层和基础层。

基础层：基础层很容易理解，其中包含的是一些基础库以及对基础库的封装，比如常用的图片加载，网络请求，数据存储操作等等，其他模块或者组件都可以引用同一套基础库，这样不但只需要开发一套代码，还解耦了基础功能和业务功能的耦合，在基础库变更时更加容易操作。

组件层：基础层往上是组件层，组件层就包含一些简单的功能组件，比如视频，支付等等

应用层：组件层往上是应用层，这里为了简单，只添加了一个 APP ，APP 就相当于我们的模块，一个具体的业务模块会按需引用不同的组件，最终实现业务功能，这里如果又多个业务模块，就可以各自按需引用组件，最后将各个模块统筹输出 APP。

一般来说，组件之间还需要互相通信，但为了解耦，组件与组件之间是不能直接调用对方的

3、组件化要解决的问题

要实现组件化，需要解决几个问题：

• 1、每个组件都是完整的单独个体，是需要有独立调试的能力的
• 2、组件之间的通信，相互调用，数据传递
• 3、组件界面之间的跳转，因为为了解耦，组件间不可以直接互相调用
• 4、主项目获取并显示组件的frament
• 5、组件间如何集成并调试

请大家一定要明白一点，组件化开发，组件就像积木一样，可以方便集成也可以方便删除，所以不能直接调用组件方法，明白了这点，就知道为什么要实现2、3、4点了。第1点和第5点只是项目集成问题，有了AndroidStudio，很好解决

4、组件的单独调试及集成

组件的常见的有两种类型，library以及正常的module，如果组件能被集成到主项目中，它此时就得是library，如果组件要单独调试，它此时就得是正常的module。为了满足此目标，可以新建 gradle.properties，在里边添加一个boolean值

isRunAlone=false

定义了 isRunAlone 值之后，更改build.gradle文件，即可以在两种类型之间自由切换：

if(isRunAlone.toBoolean()){
apply plugin: 'com.android.application'
}else{
apply plugin: 'com.android.library'
}

当然还有包名，甚至AndroidMenifest文件都需要根据类型不同重新设定

if (isRunAlone.toBoolean()){
        applicationId "com.okunu.login"
    }

sourceSets{
    main{
        if (isRunAlone.toBoolean()){
            manifest.srcFile 'src/main/manifest/AndroidManifest.xml'
        }else {
            manifest.srcFile 'src/main/AndroidManifest.xml'
        }
    }
}

组件又是如何被集成到主项目中呢？只要添加依赖即可：

implementation project (':base')
runtimeOnly project(':login')
runtimeOnly project(':share')

5、组件间通信

组件间的通信，因为不能直接调用，所以只有一条路了，面向接口编程。例如现在有两个组件，登录组件和分享组件，分享组件需要判断登录状态，只有登录成功了才能分享，所以登录组件需要向外部提供一个查询接口，登录是否成功。

面向接口编程，显示需要先定义一个接口，判断是否登录：

boolean isLogin();

同时这个接口是需要被多个组件一起使用的，比如登录和分享组件都要使用，那么这个接口只能定义在一个基础的组件当中，然后其它组件依赖基础组件即可。

接口已经定义，登录组件明显需要实现此接口。登录组件实现以后，分享组件怎么用到登录组件的实现呢？

本例中使用了注册接口的模式，依然是在基础组件当中，定义一个factory，在App启动的时候，注册组件，然后其它组件就都能调用到了。为了实现在App启动的时候就完成注册，我们特意定义了一个抽象类

public abstract class BaseApp extends Application {

/*
* application初始化
 */
public abstract void initModuleApp(Application application);

/*
* application初始化后的自定义操作
 */
public abstract void initModeleData(Application application);
}

并且在主项目的Application类中，调用各个组件的initModuleApp和initModeleData方法：

public void initModuleApp(Application application) {
    for (String app : AppConfig.modulesApp){
        try{
            Class clazz = Class.forName(app);
            BaseApp baseApp = (BaseApp) clazz.newInstance();
            baseApp.initModuleApp(this);
        }catch (Exception e){
            Log.d("okunu","", e);
        }
    }
}

有一点值得一提，为什么抽象类是一个Application 类，不是每个Application 类都会被启动吗？主项目的Application还需要调用 initModuleApp 方法吗？其实参与到主项目的组件，它们都是Library这种类型了，它们并没有单独运行在一个进程中，所以即使它们定义了 Application，也不会执行Application的oncreate方法。

注意：一个进程中只有一个Application

定义一个Application的抽象类，当组件单独运行的时候，这时组件的Application就会运行了。

所以总结一下，定义基础组件，基础组件中定义接口，组件实现接口并且注册，主项目帮助组件实现接口注册，这样组件之间的通信就能完成了。

6、组件界面跳转

还是相同的原因，为了减少耦合，不能直接调用组件的activity，所以为了界面跳转，只有一个办法了，使用aRouter开源库

7、主项目获取并显示组件的Fragment

其实这和组件间的通信类似，依然是面向接口编程的方式，组件提供实现并注册即可。

8、总结

组件化并不复杂，本质上就是将模块更细化，更加的单一化而已。

想想AS提供的这些功能，本质上也是mk脚本的变化而已。

今天提供的示例，也只涉及了同进程间的通信，跨进程通信还没有涉及，如果需要IPC，会更加的复杂。当然核心处理思想仍然是一样的，面向接口编程，定义公共组件，所有组件都依赖公共组件即可。

组件化，最深刻的一条就是面向接口编程，可扩展程度高，希望在日后的工作当中，牢牢记住这一点，一旦涉及跨模块，如何解耦，这非常非常非常重要，面向接口编程的思维一定是一种非常好的解决方式。

 

有其他问题或者技术困惑的伙伴，可以加群交流（备注技术交流）