组件化开发笔记

原文：https://blog.youkuaiyun.com/guiying712/article/details/55213884#1为什么要项目组件化

=====================================================================

以下是我方便查找做的笔记.

一、Android Studio中的Module主要有两种属性，分别为：

1、application属性，可以独立运行的Android程序，也就是我们的APP；

apply plugin: ‘com.android.application’1

2、library属性，不可以独立运行，一般是Android程序依赖的库文件；

apply plugin: ‘com.android.library’

 Module的属性是在每个组件的 build.gradle 文件中配置的，当我们在组件模式开发时，业务组件应处于application属性，这时的业务组件就是一个 Android App，可以独立开发和调试；而当我们转换到集成模式开发时，业务组件应该处于 library 属性，这样才能被我们的“app壳工程”所依赖，组成一个具有完整功能的APP；

Gradle自动构建工具有一个重要属性，可以帮助我们完成这个事情。每当我们用AndroidStudio创建一个Android项目后，就会在项目的根目录中生成一个文件 gradle.properties，我们将使用这个文件的一个重要属性：在Android项目中的任何一个build.gradle文件中都可以把gradle.properties中的常量读取出来；那么我们在上面提到解决办法就有了实际行动的方法，首先我们在gradle.properties中定义一个常量值 isModule（是否是组件开发模式，true为是，false为否）：

每次改变isModule的值后，都要同步项目才能生效；

二 、组件之间AndroidManifest合并问题

在 AndroidStudio 中每一个组件都会有对应的  AndroidManifest.xml，用于声明需要的权限、Application、Activity、Service、Broadcast等，当项目处于组件模式时，业务组件的  AndroidManifest.xml 应该具有一个 Android APP 所具有的的所有属性，尤其是声明 Application 和要  launch的Activity，但是当项目处于集成模式的时候，每一个业务组件的  AndroidManifest.xml  都要合并到“app壳工程”中，要是每一个业务组件都有自己的  Application 和  launch的Activity，那么合并的时候肯定会冲突，试想一个APP怎么可能会有多个 Application 和  launch 的Activity呢？
为组件开发模式下的业务组件再创建一个 AndroidManifest.xml，然后根据isModule指定AndroidManifest.xml的文件路径，让业务组件在集成模式和组件模式下使用不同的AndroidManifest.xml，这样表单冲突的问题就可以规避了。

集成模式下，业务组件的表单是绝对不能拥有自己的 Application 和 launch 的 Activity的，也不能声明APP名称、图标等属性，总之app壳工程有的属性，业务组件都不能有；组件模式下的业务组件表单就是一个Android项目普通的AndroidManifest.xml

标准的集成开发模式下业务组件的 AndroidManifest.xml：

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    package="com.zhy.asa">

    <application
        android:theme="@style/Base.Theme.AppCompat.Light"
        tools:replace="android:theme">
        <activity
            android:name=".ZhyMudoleActivity"
            android:screenOrientation="portrait" />
        <activity android:name=".ZhyFirstActivity"/>
    </application>
</manifest>

三、全局Context的获取及组件数据初始化

在 组件化工程模型图中，功能组件集合中有一个 Common 组件， Common 有公共、公用、共同的意思，所以这个组件中主要封装了项目中需要的基础功能，并且每一个业务组件都要依赖Common组件，Common 组件就像是万丈高楼的地基，而业务组件就是在 Common 组件这个地基上搭建起来我们的APP的，Common 组件会专门在一个章节中讲解，这里只讲 Common组件中的一个功能，在Common组件中我们封装了项目中用到的各种Base类，这些基类中就有BaseApplication 类。
BaseApplication  主要用于各个业务组件和app壳工程中声明的  Application  类继承用的，只要各个业务组件和app壳工程中声明的Application类继承了  BaseApplication，当应用启动时  BaseApplication  就会被动实例化，这样从   BaseApplication  获取的  Context  就会生效，也就从根本上解决了我们不能直接从各个组件获取全局  Context  的问题；

业务组件不能在集成模式下拥有自己的  Application，但是这不代表业务组件也不能在组件开发模式下拥有自己的Application，其实业务组件在组件开发模式下必须要有自己的  Application  类，一方面是为了让  BaseApplication  被实例化从而获取  Context，还有一个作用是，业务组件自己的   Application  可以在组件开发模式下初始化一些数据，例如在组件开发模式下，A组件没有登录页面也没法登录，因此就无法获取到 Token，这样请求网络就无法成功，因此我们需要在A组件这个  APP  启动后就应该已经登录了，这时候组件自己的  Application  类就有了用武之地，我们在组件的 Application的  onCreate   方法中模拟一个登陆接口，在登陆成功后将数据保存到本地，这样就可以处理A组件中的数据业务了；另外我们也可以在组件Application中初始化一些第三方库。

但是，实际上业务组件中的Application在最终的集成项目中是没有什么实际作用的，组件自己的  Application  仅限于在组件模式下发挥功能，因此我们需要在将项目从组件模式转换到集成模式后将组件自己的Application剔除出我们的项目；在  AndroidManifest  合并问题小节中介绍了如何在不同开发模式下让  Gradle  识别组件表单的路径，这个方法也同样适用于Java代码；
我们在Java文件夹下创建一个  debug  文件夹，用于存放不会在业务组件中引用的类ZhyApplication  ，你甚至可以在  debug  文件夹中创建一个Activity，然后组件表单中声明启动这个Activity，在这个Activity中不用setContentView，只需要在启动你的目标Activity的时候传递参数就行，这样就就可以解决组件模式下某些Activity需要getIntent数据而没有办法拿到的情况，代码如下:

public class LauncherActivity extends AppCompatActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        request();
        Intent intent = new Intent(this, TargetActivity.class);
        intent.putExtra("name", "avcd");
        intent.putExtra("syscode", "023e2e12ed");
        startActivity(intent);
        finish();
    }

    //申请读写权限
    private void request() {
        AndPermission.with(this)
                .requestCode(110)
                .permission(Manifest.permission.WRITE_EXTERNAL_STORAGE,
                        Manifest.permission.CAMERA, Manifest.permission.READ_PHONE_STATE)
                .callback(this)
                .start();
    }

}
接下来在业务组件的 build.gradle 中，根据 isModule 是否是集成模式将 debug 这个 Java代码文件夹排除：

sourceSets {
    main {
        if(isLib.toBoolean()) {
            manifest.srcFile 'src/main/AndroidManifest.xml'
            //集成开发模式下排除debug文件夹中的所有Java文件
            java {
                exclude 'debug/**'
            }
        } else {
            manifest.srcFile 'src/main/module/AndroidManifest.xml'
        }
    }
}

四、library依赖问题

为了方便我们统一管理第三方库，我们将给给整个工程提供统一的依赖第三方库的入口，前面介绍的Common库的作用之一就是统一依赖开源库，因为其他业务组件都依赖了Common库，所以这些业务组件也就间接依赖了Common所依赖的开源库。

五、组件之间调用和通信

这里我将介绍开源库的“ActivityRouter” ，有兴趣的同学情直接去ActivityRouter的Github主页学习：ActivityRouter，ActivityRouter支持给Activity定义 URL，这样就可以通过 URL 跳转到Activity，并且支持从浏览器以及 APP 中跳入我们的Activity，而且还支持通过 url 调用方法。下面将介绍如何将ActivityRouter集成到组件化项目中以实现组件之间的调用；
1、首先我们需要在 Common 组件中的 build.gradle 将ActivityRouter 依赖进来，方便我们在业务组件中调用：

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])
    //router
    compile "com.github.mzule.activityrouter:activityrouter:$rootProject.routerVersion"
}

2、这一步我们需要先了解 APT这个概念，APT(Annotation Processing Tool)是一种处理注解的工具，它对源代码文件进行检测找出其中的Annotation，使用Annotation进行额外的处理。 Annotation处理器在处理Annotation时可以根据源文件中的Annotation生成额外的源文件和其它的文件(文件具体内容由Annotation处理器的编写者决定)，APT还会编译生成的源文件和原来的源文件，将它们一起生成class文件。在这里我们将在每一个业务组件的  build.gradle  都引入ActivityRouter 的 Annotation处理器，我们将会在声明组件和Url的时候使用，annotationProcessor是Android官方提供的Annotation处理器插件，代码如下：
dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])
    annotationProcessor "com.github.mzule.activityrouter:compiler:$rootProject.annotationProcessor"
}
3、接下来需要在 app壳工程的 AndroidManifest.xml 配置，到这里ActivityRouter配置就算完成了：

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    package="com.zhy.as">

    <application
        android:name=".app.AsApplication"
        android:allowBackup="true"
        android:icon="@mipmap/ic_launcher"
        android:label="zhyAs"
        android:roundIcon="@mipmap/ic_launcher_round"
        android:supportsRtl="true"
        tools:replace="android:label"
        android:theme="@style/Base.Theme.AppCompat.Light">
        <activity android:name=".MainActivity">
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>
        <activity
            android:name="com.github.mzule.activityrouter.router.RouterActivity"
            android:theme="@android:style/Theme.NoDisplay">
            <intent-filter>
                <action android:name="android.intent.action.VIEW" />
                <category android:name="android.intent.category.DEFAULT" />
                <category android:name="android.intent.category.BROWSABLE" />
                <data android:scheme="zhyrouter" /> <!-- 改成自己的scheme -->
            </intent-filter>
        </activity>
    </application>

</manifest>

4、接下来我们将声明项目中的业务组件，声明方法如下：

在每一个业务组件的java文件的根目录下创建一个类，用 注解@Module 声明这个业务组件；
@Module("zhyAsa")
public class FirstMoudle {
}

然后在“app壳工程”的 应用Application 中使用 注解@Modules 管理我们声明的所有业务组件，方法如下：

@Modules({"zhyAsa"})
public class AsApplication extends BaseApplication {
}

到这里组件化项目中的所有业务组件就被声明和管理起来了，组件之间的也就可以互相调用了，当然前提是要给业务组件中的Activity定义 URL。

然后我们就可以在项目中的任何一个地方通过 URL地址 ： module://first, 调用 ZhyFirstActivity，方法如下：

Routers.open(MainActivity.this, "zhyrouter://first");

组件之间的调用解决后，另外需要解决的就是组件之间的通信，例如A业务组件中有消息列表，而用户在B组件中操作某个事件后会产生一条新消息，需要通知A组件刷新消息列表，这样业务场景需求可以使用Android广播来解决，也可以使用第三方的事件总线来实现，比如EventBus。

六、组件之间资源名冲突

因为我们拆分出了很多业务组件和功能组件，在把这些组件合并到“app壳工程”时候就有可能会出现资源名冲突问题，例如A组件和B组件都有一张叫做“ic_back”的图标，这时候在集成模式下打包APP就会编译出错，解决这个问题最简单的办法就是在项目中约定资源文件命名规约，比如强制使每个资源文件的名称以组件名开始，这个可以根据实际情况和开发人员制定规则。当然了万能的Gradle构建工具也提供了解决方法，通过在在组件的build.gradle中添加如下的代码：
 //设置了resourcePrefix值后，所有的资源名必须以指定的字符串做前缀，否则会报错。
    //但是resourcePrefix这个值只能限定xml里面的资源，并不能限定图片资源，所有图片资源仍然需要手动去修改资源名。
    resourcePrefix "zhy_"
但是设置了这个属性后有个问题，所有的资源名必须以指定的字符串做前缀，否则会报错，而且resourcePrefix这个值只能限定xml里面的资源，并不能限定图片资源，所有图片资源仍然需要手动去修改资源名；所以我并不推荐使用这种方法来解决资源名冲突。