前言
公司包含三大业务线，每条业务线都有独立的app。功能模块难免会有重合~举个栗子，直播功能本来只在业务线A使用，但是由于业务拓展，现在业务线B和C也需要使用直播功能。这时候就有必要将直播功能做成一个独立的直播组件供三条业务线使用。
构思
既然要将直播做成组件，需要考虑哪些方面呢？
- 既可独立运行，单独测试该组件功能；也可作为sdk，被其他项目使用
- 统一管理：部署到私有化仓库，其他项目可配置引用
基础实践
全局控制配置
在gradle.properties中的配置可以在项目中直接使用
# 是否作为module使用
isModule=true
build.gradle的配置
- 配置android构建插件
if(isModule.toBoolean()){
// lib
apply plugin: 'com.android.library'
}else{
// 独立运行的app
apply plugin: 'com.android.application'
}
- 禁用applicationId配置 作为library不能带有配置，否则编译会报错：
Library projects cannot set applicationId. applicationId is set to 'com.example.live' in default config.
android {
...
defaultConfig {
if(!isModule.toBoolean()){
applicationId "com.example.live"
}
...
}
AndroidManifest.xml的配置
1. 独立运行
为了可独立运行，需要配置application和启动Activity
// 正常模板
<application
android:allowBackup="true"
android:icon="@mipmap/ic_launcher"
android:label="@string/app_name"
android:roundIcon="@mipmap/ic_launcher_round"
android:supportsRtl="true"
android:theme="@style/Theme.TestAndroidManifest">
<activity
android:name=".MainActivity"
android:exported="true">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
</application>
2. module形式使用
假如被其他项目作为组件使用，则需要修改application和启动入口配置
// 去除application不必要的属性配置
<application>
// 去除intent-filter
<activity
android:name=".MainActivity"
android:exported="true">
</activity>
</application>
这里有两个问题：
- application里边的属性配置可以不去掉吗？
其实在编译后，所有module的AndroidManifest会被合并到一起，假如相同属性配置不同会报错
Manifest merger failed : Attribute application@name value=(com.example.moduledemo.MainApplication) from AndroidManifest.xml:7:9-40
is also present at [:live] AndroidManifest.xml:11:9-56 value=(com.example.live.LiveApplication).
Suggestion: add 'tools:replace="android:name"' to <application> element at AndroidManifest.xml:6:5-23:19 to override.
这里我分别给和app-module和live-module指定了自定义appliation，提示合并失败了，解决方案需要通过在app-module配置tools:replace="android:name"。这里通过不同配置然后rebuild查看下输出的AndroidManifest.xml文件可以总结以下规律：
- 假如只有一个module配置了自定义application，则直接使用该application
- 假如每个module都配置了自定义application，则需要解决冲突。解决后会使用最后编译的那个module的application（举个例子：demo中，app-module依赖于live-module，假如都配置了自定义application，因为app后编译，所以最后会使用app-module里边定义的）
- activity里边的intent-filter可以不去掉吗？
看到合并后的文件，里边包含了两个包含启动信息的activity。安装app时你会发现在桌面会有两个启动图标，并且点击他们的行为是一致的：打开第一个配置了MAIN和LAUNCHER的activity。因此是没有必要保留该配置的。
3. 动态配置AndroidManifest
根据上述的分析发现，作为module使用和独立app运行，相应的AndroidManifest.xml也需要相应的进行调整。那我们就有必要根据配置来配置使用不同的AndroidManifest文件了
- 在live-module增加用于sdk的AndroidManifest.xml
- 在live-module的build.gradle配置动态引用不同的AndroidManifest.xml
android {
...
sourceSets {
main {
if(isModule){
manifest.srcFile 'src/main/module/AndroidManifest.xml'
}else{
manifest.srcFile 'src/main/AndroidManifest.xml'
}
}
}
}
总结
至此，你已经可以通过修改gradle.properties里边的liModule来控制是否以library的形式使用live组件了。这里可以思考个问题，假如我们项目中有好几个类似于live这样的组件，是否每个组件都需要做这么繁琐的配置呢？能否将这些配置抽出来，统一管理？
优化
1. 抽取独立app构建脚本
在项目根目录创建一个common_app_build.gradle
apply plugin: 'com.android.application'
android {
compileSdk 31
defaultConfig {
minSdk 21
targetSdk 31
versionCode 1
versionName "1.0"
testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
}
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'),'proguard-rules.pro'
}
}
compileOptions {
sourceCompatibility JavaVersion.VERSION_1_8
targetCompatibility JavaVersion.VERSION_1_8
}
sourceSets {
main {
manifest.srcFile 'src/main/AndroidManifest.xml'
}
}
}
2. 抽取构建library脚本
在项目根目录创建一个common_library_build.gradle
apply plugin: 'com.android.library'
android {
compileSdk 31
defaultConfig {
minSdk 21
targetSdk 31
versionCode 1
versionName "1.0"
testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
}
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'),'proguard-rules.pro'
}
}
compileOptions {
sourceCompatibility JavaVersion.VERSION_1_8
targetCompatibility JavaVersion.VERSION_1_8
}
sourceSets {
main {
manifest.srcFile 'src/main/module/AndroidManifest.xml'
}
}
}
3. 在创建一个的course module（用于验证）
4. 修改live和course两个module的build.gradle
下边以live module为例
// 直接通过配置引用不同的gradle文件，前边涉及的配置都可以去掉
if (isModule.toBoolean()) {
apply from: '../common_library_build.gradle'
} else {
apply from: '../common_app_build.gradle'
}
android {
defaultConfig {
if(!isModule.toBoolean()){
applicationId "com.example.live"
}
}
}
后续类似的组件只需要进行简单的配置，即可实现第一点的构思
module发布
这里以live module为例进行实践，# google文档：使用 Maven Publish 插件
发布live module到本地仓库
再live module的build.gradle增加以下配置
afterEvaluate {
publishing {
repositories {
maven {
url uri("../repo")
}
}
publications {
maven(MavenPublication) {
from components.release
groupId "com.example.live"
artifactId "modulelive"
version "1.0.0"
}
}
}
}
上述配置，指定将live发布到 项目/repo/ 目录下。sync完成后，会在live出现publish task
双击publish，即会在repo生成相应的aar文件
配置根build.gradle
为了可以使用repo里边的aar，需要增加配置
buildscript {
repositories {
...
maven {
url('repo')
}
}
...
}
app中使用：配置build.gradle
dependencies {
...
// 不直接引用project
// api project(':live')
// 改为该配置
implementation 'com.example.live:modulelive:1.0.0'
...
}
重新rebuild就可以正常使用到live组件。
发布到远程仓库
因为不同业务线项目环境不同，发布到本地项目目录下，使用比较不方便吗。所以可以考虑将组件发布到公司内部的私有仓库，供所有项目组使用:
publishing {
...
repositories {
maven {
// 仓库地址
url = "http://...."
// 仓库用户名及密码
credentials {
username ''
password ''
}
}
}
}
这里有点需要注意，gradle6.x版本以及gradle7.x版本关于发布内容到maven仓库做了调整，有兴趣可以看另外一篇文章的介绍：android不同版本的gradle发布内容到Maven仓库
总结
上述主要是讲述了Android组件化的一些基础以及如何发布组件的一些流程。当然，组件化的内容不止这些内容，包括：
- 组件间通信
- 组件间跳转
- 组件化混淆
- 组件资源冲突
- …
参考视频：
组件化开发以及路由框架实现
Android应用的进阶宿命，组件化架构与阿里组件化路由解析与实现
超大型项目的终极架构，窥探阿里ARouter组件化路由框架的原理
项目越做越复杂？组件化开发替你解决所有问题
为了能让大家刚好的了解Android 组件化相关方面的知识点，小编为大家进行整理了一份Android组件化强化实战的学习文档，里面不仅记录了各大厂的技术实战，还有一些知识点解析，有需要参考的小伙伴可以点击这里查看获取方式 传送门直达 ！！！
原文地址：https://blog.csdn.net/weixin_61845324
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。