Android组件化基础

最新推荐文章于 2023-10-27 18:44:54 发布

爱吃水蜜桃的奥特曼

最新推荐文章于 2023-10-27 18:44:54 发布

阅读量462

点赞数

分类专栏： android技术总结文章标签： android gradle

本文链接：https://blog.csdn.net/u012950099/article/details/121786260

版权

android技术总结专栏收录该内容

30 篇文章 0 订阅

订阅专栏

注：该文章也同步发布到稀土掘金：链接

前言

公司包含三大业务线，每条业务线都有独立的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可以不去掉吗？

合并.png

看到合并后的文件，里边包含了两个包含启动信息的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组件化的一些基础以及如何发布组件的一些流程。当然，组件化的内容不止这些内容，包括：

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

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

gitee：Demo地址

爱吃水蜜桃的奥特曼

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
Android组件化基础

注：该文章也同步发布到稀土掘金：链接前言公司包含三大业务线，每条业务线都有独立的app。功能模块难免会有重合~举个栗子，直播功能本来只在业务线A使用，但是由于业务拓展，现在业务线B和C也需要使用直播功能。这时候就有必要将直播功能做成一个独立的直播组件供三条业务线使用。构思既然要将直播做成组件，需要考虑哪些方面呢？既可独立运行，单独测试该组件功能；也可作为sdk，被其他项目使用统一管理：部署到私有化仓库，其他项目可配置引用基础实践全局控制配置在gradle.properties中的配置可
复制链接

扫一扫