Android组件化基础

前言


公司包含三大业务线,每条业务线都有独立的app。功能模块难免会有重合~举个栗子,直播功能本来只在业务线A使用,但是由于业务拓展,现在业务线B和C也需要使用直播功能。这时候就有必要将直播功能做成一个独立的直播组件供三条业务线使用。


构思


既然要将直播做成组件,需要考虑哪些方面呢?



  1. 既可独立运行,单独测试该组件功能;也可作为sdk,被其他项目使用
  2. 统一管理:部署到私有化仓库,其他项目可配置引用

基础实践


全局控制配置


在gradle.properties中的配置可以在项目中直接使用


# 是否作为module使用
isModule=true

build.gradle的配置



  1. 配置android构建插件

if(isModule.toBoolean()){
// lib
apply plugin: 'com.android.library'
}else{
// 独立运行的app
apply plugin: 'com.android.application'
}


  1. 禁用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>

这里有两个问题:



  1. 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里边定义的)


  1. activity里边的intent-filter可以不去掉吗?

合并.png


看到合并后的文件,里边包含了两个包含启动信息的activity。安装app时你会发现在桌面会有两个启动图标,并且点击他们的行为是一致的:打开第一个配置了MAIN和LAUNCHER的activity。因此是没有必要保留该配置的。


3. 动态配置AndroidManifest


根据上述的分析发现,作为module使用和独立app运行,相应的AndroidManifest.xml也需要相应的进行调整。那我们就有必要根据配置来配置使用不同的AndroidManifest文件了



  1. 在live-module增加用于sdk的AndroidManifest.xml

module.png
3. 在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


maven.png


双击publish,即会在repo生成相应的aar文件


aar.png


配置根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 ''
}
}
}
}

总结


上述主要是讲述了Android组件化的一些基础以及如何发布组件的一些流程。当然,组件化的内容不止这些内容,包括:



  • 组件间通信
  • 组件间跳转
  • 组件化混淆
  • 组件资源冲突
  • .....

这些方面都是在进行组件化设计需要思考与处理的~后续逐渐完善这块的内容


gitee:Demo地址


作者:king_nina
链接:https://juejin.cn/post/7028842367960481806
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

0 个评论

要回复文章请先登录注册