模块化，组件化傻傻分不清？附带组件化福利

前几篇文章中，分析了狭义上的架构概念，如《关于移动架构的思考与总结》, 《关于移动架构，有这一篇就够了》。从狭义上来讲，Android的架构概念就在这儿，无论怎么变，都是加加减减一些边边角角的东西，不足在意。

从本篇开始，打算从广义上探究一下移动架构的思想；包括现在仍然比较火热的模块化，组件化， 插件化等架构思想。话说在前面，本篇旨在说明当前主流架构的设计概念，让大家了解当前的架构形式，以及主要用了什么设计思想，什么设计思路，算是引导篇...

模块化，组件化，插件化

上述概念已经好久了，或许还是有一些同胞对这些概念不是很清楚，大体知道是什么，但是详细也不知道是什么。现在来解析一下。

单工程模式

移动开发诞生，我们开发移动项目，我相信大多用的是单工程单任务的开发模式，二话不说，直接就开始写起，是不是这样呢？ new Project -> 分包 -> 写起。我相信都经历过，也写的比较爽，为什么呢？ 这种模式不涉及乱七八糟的处理方式， 上手快，开发快，足够敏捷。那么原因是什么呢？Mobile Project 刚起步，项目都偏小，一些附加业务还没绑到App上。

模块化

Android Studio出来了，多出来了一个新的概念， Project, Module... 模块；当时以包的形式分离的公共包common,现在成了AS中的Module。大家都知道，Module包含两种格式: application， library。也就是说，一个Module就是一个小的项目，也是AS概念中的模块。因此我们开始设计common模块， common_business模块，甚至db模块。模块的好处是什么？ 相比于包来讲，模块更灵活，耦合更低，随意插拔，想引入哪个就引入哪个。根据不同的关注点，将一个项目的可以共享的部分抽取出来，形成独立的Module，就是模块化。模块化不只包含公共部分，当然也可以是业务模块。

组件化

平时看看论坛，好多人都在问： 模块化和组件化有什么区别？ 到底有什么区别呢，其实很小；但并不是完全相同的概念。 通过以上模块化的概念讲述，应该对模块化有了一个了解，那么区别是什么呢？

组件化是建立在模块化思想上的一次演进，一个变种。组件化本来就是模块化的概念。但是组件化的核心是
什么？ 是模块角色的可转换性。是的，就是可转换性。

组件化的核心是角色的转换。 在打包时， 是library; 在调试时， 是application。

怎么理解组件化的概念 ？

Module的模式分两种， application和library。 library就是引用库，如你抽取的common。 application就是一个apk， 是一个完整的项目。

在调试时，我只关心我负责的模块，我希望我的模块是一个单独的app,因为这样更小，业务更专一，相对来讲修改与调试就会越省时省心，编译就会越快。试想当你需要改一段代码，既要关注自己的，也要关注别人的，是一种什么体验 ？ 或者， 编译一个项目10M的代码和一个工程全部1G的代码，哪个比较舒服一些？

插件化

又有人问了： 插件化和组件化又有什么区别呢？插件化严格意义来讲，其实也算是模块化的观念。将一个完整的工程，按业务划分为不同的插件，都是分治法的一种体现。化整为零，相互配合。，越小的模块越容易维护。 插件化按理也算是模块化的一种体现，和组件化就不一个概念了。那么，到底有什么区别呢？

组件化的单位是组件（module）。
插件化的单位是apk(一个完整的应用)。

组件化实现的是解耦与加快编译， 隔离不需要关注的部分。
插件化实现的也是解耦与加快编译，同时实现热插拔也就是热更新。

组件化的灵活性在于按加载时机切换，分离出独立的业务组件，比如微信的朋友圈
插件化的灵活性在于是加载apk, 完全可以动态下载，动态更新，比组件化更灵活。

组件化能做的只是， 朋友圈已经有了，我想单独调试，维护，和别人不耦合。但是和整个项目还是有关联的。
插件化可以说朋友圈就是一个app, 我需要整合了，把它整合进微信这个大的app里面

其实从框架名称就可以看出： 组 和 插。

组本来就是一个系统，你把微信分为朋友圈，聊天， 通讯录按意义上划为独立模块，但并不是真正意义上的独立模块。
插本来就是不同的apk， 你把微信的朋友圈，聊天，通讯录单独做一个完全独立的app, 需要微信的时候插在一起，就是一个大型的app了。

插件化的加载是动态的，这点很重要，也是灵活的根源。

以上是对三个思想的解析，相信应该能明白不同的概念的具体意义和区别在哪了。在《关于移动架构的思考与总结》中我指出，所谓架构，无非两个方面： 分层和通信方式。 其实广义的架构也可以说是这两个方面：子模块（子系统）划分和通信。

子模块划分

除了大家公认的common部分， 业务模块的划分尤为重要，相比于狭义上的架构，广义上的子系统的划分的关注点，很考验技术经验以及对业务的理解。

通信方式

模块化的通信方式，无非是相互引入；我抽取了common, 其他模块使用自然要引入这个module
组件化的通信方式，按理说可以划分为多种，主流的是隐式和路由。隐式的存在使解耦与灵活大大降低，因此路由是主流
插件化的通信方式，不同插件本身就是不同的进程了。因此通信方式偏向于Binder机制类似的进程间通信

废话说了这么多，其实本篇作为组件化的引导篇，本意是要探究一下组件化的思路的，嗯，本篇只讲思路；其实思路清晰了，结合一定的技术储备，完全可以自己来实现。好了，开始切入主题...

组件化的技术准备

反射与apt
gradle与groovy
路由机制

情报篇

做一件事，首先要明白我们要做什么， 然后划分步骤，哪一步怎么做，最后逐个解决。这也是分治法的一种思维方式，它当然不只是一种算法的解决思想。只有这样，我们才会建立信息，不会一下子被吓傻从而放弃。

组件化的思想是Module模式的切换。 上面已经说过,在打包时，业务module为library; 调试时，业务module成了application。

1.如何切换module的模式呢 ？

我相信都能想到，定义一个Boolean变量作为开关。根据开关分别设置module的模式，如下

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

2.两种模式的区别是什么？

1. applicationId (包的配置)             
   只存在于apply plugin: 'com.android.application'模式下

2. Manifest.xml（主页面的配置）
    集成模式下，使用app模块下的Manifest.xml配置； 组件模式下，使用组件自己的Manifest.xml配置

3. Application
    不同的组件肯定有自己的初始化的资源或框架，因此自定义的Application也是必要的。但是集成模式下，会造成重复的Application

3. 面临的问题

问题1：多业务模块下的统一配置

问题2：Application分发

问题3：资源的冲突

注意：不同的业务模块禁止彼此依赖

解决方案1：

不同的模块（20个业务模块）的配置，必须做到统一配置。在Java代码实现统一配置，SO Easy ~ 但是在gradle中呢 ？ 那就是定义一个配置文件，统一存放需要配置的项。如下

ext {

    isModule = false // 组件开关： true 组件 false 集成

    defaultConfig = [
            minSdkVersion            : 14,
            targetSdkVersion         : 26,
            versionCode              : 1,
            versionName              : "1.0",
            testInstrumentationRunner: "android.support.test.runner.AndroidJUnitRunner"
    ]

    android = [
            compileSdkVersion: 26
    ]

    applicationId = [
            app  : "com.archer.componentsarchitecture",
            card1: "com.archer.card1",
            card2: "com.archer.card2"
    ]

    supportLibrary = "26.1.0"
    appcompatv7a = "com.android.support:appcompat-v7:${supportLibrary}"

    resourcePrefixs =[
            card1: "card1",
            card2: "card2"
    ]

    router = [
            arouter: "com.alibaba:arouter-api:1.2.1.1",
            processor: "com.alibaba:arouter-compiler:1.1.2.1"
    ]
}

在Project下创建一个config.gradle(什么？创建不了？那就把Project自带的build.gradle复制一份rename & clear)。 ext是groovy提供的扩展参数，不可修改的。 以下可以随意定义自己的配置，如代码。这里说下两个概念：

1. 占位符 ${supportLibrary} 占据一个位置，然后用｛｝里面的变量补充，达到一致配置的目的
2. android = [
   compileSdkVersion: 26
   ]
   以上相当于定义了一个Map, 存放键值对，以Key: Value的形式，以，分隔。这是groovy的写法。android 为Map的名称，你可以用你自己的命名，但是注意不要和系统变量冲突

以上是统一变量的定义，配置文件config.gradle。 配置文件定义好了，那么如何引入呢？

1. 在[Project]下的build.gradle引入配置文件

   
   image.png
   

   2.在Module中引用是通过rootProject.ext.你定义的名称。但是每次这么用比较繁琐，推荐定义变量实现，如下

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

def cfg = rootProject.ext.defaultConfig
def drd = rootProject.ext.android
def app = rootProject.ext.applicationId

android {
    compileSdkVersion drd.compileSdkVersion
    defaultConfig {
        if (isModule) {
            applicationId app['card2']
        }
        minSdkVersion cfg.minSdkVersion
        targetSdkVersion cfg.targetSdkVersion
        versionCode cfg.versionCode
        versionName cfg.versionName

        testInstrumentationRunner cfg.testInstrumentationRunner

        resourcePrefix rootProject.ext.resourcePrefixs['card2']

        javaCompileOptions {
            annotationProcessorOptions {
                arguments = [ moduleName : project.getName() ]
            }
        }
    }

调用Groovy map中的字段的两种方式： rootProject.ext.android.key和 rootProject.ext.android['key']

解决方案2：

application的分发，错误的做法是不同的组件下初始化自己的框架，工具等。正确的做法是在BaseApplication或统一实现公共模块如网络， 缓存， 数据库等的初始化，在各Module实现自己需要的初始化，来避免重复的初始化与冲突。

解决方案3：

资源的冲突解决办法有两个：
1） 公共资源建议由公共模块管理
2） 模块私有资源，添加前缀限制 （只能解决xml冲突）
3）资源谨慎命名

资源命名只能在开发中加以注意， 通过以上共有资源和前缀极大可能的保证资源不会冲突，且不会重复浪费。至于万一的冲突，只能交给开发规范了。

解决方案4：

这个是新加的，也就是前面说的，怎么控制application和library的转换，全部配置如下：

// 自由控制模式转换
if (isModule) {
    apply plugin: 'com.android.application'
} else {
    apply plugin: 'com.android.library'
}

// 包名配置
 defaultConfig {
        if (isModule) {
            applicationId app['card2']
        }
｝

// Manifest.xml  application配置
 sourceSets {
        main {
            if (isModule) {
                // src/main下新建文件夹，存放组件模式下的Manifest.xml与Application
                manifest.srcFile 'src/main/component/AndroidManifest.xml'
                java.srcDirs = ['src/main/java', 'src/main/component/java']
            } else {
                // library模式下不需要Application
                manifest.srcFile 'src/main/AndroidManifest.xml'
                java.srcDirs 'src/main/java'
            }
        }
    }

以上配置在相应Module中的build.gradle的android下

本来打算出这篇为Router原理思想的，结果为了引导从模块化的概念直到组件化的核心概念以及初步实现。因为真的不少人可能对这些概念了解不是很清楚，包括以前的我，比如模块化和组件化。从整篇来看，组件化无非就是实现了一次转换，解决的一些转换过程中涉及的问题。没那么难， 也存在一些坑，只有在开发过程中随着遇到进一步填平。组件化的配置核心就是library和application的toggle。 真正实现的功能核心却是通信部分的路由实现部分，下一篇讲一下，如何手写Rooter通信框架。