组件化开发

相关资料

组件化开发

组件化开发Demo示例（来自上文）

配置gradle.properties

module相关操作

 

medule操作

新建/导入已存在medule

新建一个默认的medule（phone/tablet medule)就可以作为新的组件medule

编译的过程中会警告，库组件medule不应该有applicationId

在新建的medule中打开builde.gradle文件，删除applicationId即可通过编译

删除module

第一步，找到project structure，选中需要删除的module，点上方的红色减号即可

第二部，回到peoject目录，删除module文件夹

 

自己搭建一个组件框架

1 组件/集成模式控制

每个module目录下的build.gradle文件第一句都会定义module属性

//定义当前module为应用
apply plugin: 'com.android.application'

//定义当前module为lib库
apply plugin: 'com.android.library'

在这里可以利用项目根目录下gradle.properties文件中的属性，所有项目文件都可以获取到的特性来设置开关

# Decide whether to act as a separate medule
isModule=false

然后在需要单独模块测试的module，配置builde.gradle

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

2 AndroidManifest.xml配置

   建立不同模式下的AndroidManifest配置

每个module都会有一个AndroidManifest配置文件

组件作为模块时，配置文件中不允许出现application的名称，图标，等属性，所有模块的配置最终会合并到app包下的根配置文件

但是单独测试组件时，又需要组件能够作为独立的app运行，就需要在配置文件中提供app的信息

我们就需要在不同的模式下提供不同的配置文件

在module的build.gradle文件中配置资源文件

android {
...


sourceSets {
        main {
            if (isModule.toBoolean()) {
//                作为测试配置
                manifest.srcFile 'src/main/java/module/debug/AndroidManifest.xml'
            } else {
//                正式打包编译的配置
                manifest.srcFile 'src/main/AndroidManifest.xml'
            }
        }
    }
...
}

不同的AndroidManifest配置内容

主要针对不同模块的配置内容，这个可以根据个人规划来划分配置内容

一般情况下，主要有这些内容配置

app壳工程  由于不涉及任何组件（活动，广播，服务，内容提供器），因此只有application标签，负责整个app的风格定义

lib_common基础库    通常作为通用的第三方库的集合，配置中需要包含必要的组件。

                                    存放自定义的公共类，自定义控件，存放整个项目的资源文件

                                    application标签只有theme属性，负责整个app风格的统一

                                    在这里统一声明管理项目中需要的权限，其他module不做权限声明

功能提供组件      通常为某一模块单独提供功能支持，与common组件类似，但是不会被所有模块依赖。

                             application标签只有theme属性，负责整个app风格的统一

Main组件      负责Main页面和Splash页面。作为app整体的入口

                    需要为main页面设置Launcher属性

                     application标签只有theme属性，负责整个app风格的统一

业务组件      具体业务功能组件，添加管理具体的活动等组件

                     application标签只有theme属性，负责整个app风格的统一

 

3 全局的Application设置

这里定义application，目的就是为了提供一个基础的BaseApplication类

在common库中定义一个抽象类BaseApplication，保证第三方库的初始化，其他模块依赖common库的同时，如果需要实现application，必须要继承BaseApplication。

public abstract class BaseApplication extends Application {


 @Override
    public void onCreate() {
        super.onCreate();
//这里可以初始化一些common库依赖的第三方库
    // ARouter.init(this); 
//这里来保证子类实现自己的方法
        init();
    }



protected abstract void init();

}

对于app壳工程，实现的application文件就是正式发布时app的主进程

对于其他模块，实现的application主要用来作为模块单独测试时调用，可以在初始化的过程中，模拟登陆，传递参数等操作

对于测试文件，建议统一放到模块java文件夹下新建debug文件夹，在打包发布时排除debug文件夹

需要在设置AndroidManifest资源夹的地方，设置

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

4 项目依赖管理

排除重复依赖

项目在组件模式下，统一编译时，会把所有库文件打包进apk

因为有可能出现第三方库，重复依赖基础库文件，如果出现报错，需要排除重复依赖

implementation ("com.jude:easyrecyclerview:$rootProject.easyRecyclerVersion") {
        exclude module: 'support-v4'//根据组件名排除
        exclude group: 'android.support.v4'//根据包名排除
    }

对版本号统一管理

版本维护

应用目标版本号，也可以统一定义在根目录下的build.gradle文件中，方便其他module在模块开发时引用

第三方库，因为大部分集中在common库，在common库统一更新即可

另外，由于apt解释器需要每个module都添加依赖的问题，建议把解释器版本放在根目录下的build.gradle文件维护

版本管理

android项目需要通过本地编译器来编译，不同版本的编译器，结果会有差异。

多人协同开发时，git上传代码，有可能导致编译器版本不断的变动，因此，把规定的版本号写在gradle.properties中，在ignore文件中排除gradle.properties文件，可以保证项目编译器版本统一，gradle.properties文件直接发送给开发者即可

根目录，build.gradle文件

下面时配置文件

根目录gradle.properties

# 为自动化出包配置(因为每个开发的电脑坏境不一致)
localBuildToolsVersion=28.0.3
# 这个值一般跟你的AndroidStudio版本号一致
localGradlePluginVersion=3.3.2
# butterKnife 编译器版本
butterknifeCompiler=10.1.0

根目录build.gradle

/*
create time 2019.03.30
change time
 */
ext{
    // Sdk and tools
    //localBuildToolsVersion是gradle.properties中的数据
    buildToolsVersion = localBuildToolsVersion
    compileSdkVersion = 28
    minSdkVersion = 21
    targetSdkVersion = 28
    versionCode = 1
    versionName = "1.0"
    javaVersion = JavaVersion.VERSION_1_8

    //annotation
    butterknife_compiler=butterknifeCompiler

}

然后是引用这些定义的地方

根目录build.gradle

 dependencies {
        classpath "com.android.tools.build:gradle:$localGradlePluginVersion"
        classpath "com.jakewharton:butterknife-gradle-plugin:$butterknifeCompiler"
        // NOTE: Do not place your application dependencies here; they belong
        // in the individual module build.gradle files
    }

每个module的build.gradle

android {
    compileSdkVersion rootProject.ext.compileSdkVersion
    buildToolsVersion localBuildToolsVersion
    defaultConfig {
        applicationId "（APPID）"
        minSdkVersion rootProject.ext.minSdkVersion
        targetSdkVersion rootProject.ext.targetSdkVersion
        versionCode rootProject.ext.versionCode
        versionName rootProject.ext.versionName
        testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
    }
}

dependencies {
    implementation fileTree(dir: 'libs', include: ['*.jar'])
    implementation project (':lib_common')
//    这是除了common模块都需要引用的butterKnife编译器
    annotationProcessor "com.jakewharton:butterknife-compiler:$butterknife_compiler"
}

最后，别忘了在根目录的gitignore文件中，排除gradle.properties文件

/gradle.properties

5 模块之间通信

这个有比较成熟的方案，阿里的ARouter

配置资料

GitHub Arouter源码及教程

个人学习记录

 

6混淆配置

统一在app壳工程中启动混淆功能，配置混淆规则

主要针对第三方库文件

buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
        }
    }

其他module模块的build.gradle文件中

buildType就不是很必须，可以考虑精简掉