Android组件化开发

本文详细介绍了Android组件化开发的概念、原因、优势及具体实现步骤。组件化旨在解决传统单一工程架构带来的开发效率低下、维护成本高、多人协作困难等问题。通过组件模式和集成模式的转换,实现业务模块的独立开发和调试。文章还涵盖了AndroidManifest的合并、全局Context获取、组件间通信(使用ARouter)以及资源名冲突的解决策略。此外,详细阐述了组件化项目的工程类型,包括app壳工程、功能组件和业务组件的角色和配置。通过组件化,可以提高业务迭代速度,简化项目维护,提升开发效率。
摘要由CSDN通过智能技术生成

 

一.什么是组件化开发

所谓组件化,就是将整个庞大的项目以业务逻辑进行拆分成多个模块,并且各个模块之间相互独立,相互解耦,每一个模块可以单独进行开发调试,各个模块调试完,以library的形式依赖在壳App中组合成一个完整的项目。

二.为什么要采用组件化

随着APP版本不断的迭代,新功能的不断增加,业务也会变的越来越复杂,APP业务模块的数量有可能还会继续增加,而且每个模块的代码也变的越来越多,这样发展下去单一工程下的APP架构势必会影响开发效率,增加项目的维护成本,每个工程师都要熟悉如此之多的代码,将很难进行多人协作开发,而且Android项目在编译代码的时候电脑会非常卡,又因为单一工程下代码耦合严重,每修改一处代码后都要重新编译打包测试,导致非常耗时,最重要的是这样的代码想要做单元测试根本无从下手,所以必须要有更灵活的架构代替过去单一的工程架构。

单一工程:原先采用的架构

从图中我们可以看出,单一工程的话,所有的业务逻辑都整合再同一个app中,业务逻辑之间也相互依赖,所谓的你中有我,我中有你,相互依赖,无法分离。单一工程也存在以下几个问题:

1、实际业务变化非常快,但是单一工程的业务模块耦合度太高,牵一发而动全身;

2、对工程所做的任何修改都必须要编译整个工程;

3、功能测试和系统测试每次都要进行;

4、团队协同开发存在较多的冲突.不得不花费更多的时间去沟通和协调,并且在开发过程中,任何一位成员没办法专注于自己的功能点,影响开发效率;

5、不能灵活的对业务模块进行配置和组装;

因此,为了满足各个业务模块的迭代而彼此不受影响,更好的解决上面这种让人头疼的依赖关系,我们就需要整改app架构。

组件化工程:整改后的架构

几个名词解释:

集成模式:所有的业务组件被“app壳工程”依赖,组成一个完整的APP;

组件模式:可以独立开发业务组件,每一个业务组件就是一个APP;

app壳工程:负责管理各个业务组件,和打包apk,没有具体的业务功能;

业务组件:根据公司具体业务而独立形成一个的工程;

功能组件:提供开发APP的某些基础功能,例如打印日志、树状图等;

Common组件:属于功能组件,支撑业务组件的基础,提供多数业务组件需要的功能,例如提供网络请求功能;

Android APP组件化架构的目标是告别结构臃肿,让各个业务变得相对独立,业务组件在组件模式下可以独立开发,而在集成模式下又可以变为arr包集成到“app壳工程”中,组成一个完整功能的APP;
       从组件化工程模型中可以看到,业务组件之间是独立的,没有关联的,这些业务组件在集成模式下是一个个library,被app壳工程所依赖,组成一个具有完整业务功能的APP应用,但是在组件开发模式下,业务组件又变成了一个个application,它们可以独立开发和调试,由于在组件开发模式下,业务组件们的代码量相比于完整的项目差了很远,因此在运行时可以显著减少编译时间。

这是组件化工程模型下的业务关系,业务之间将不再直接引用和依赖,而是通过“路由”这样一个中转站间接产生联系,而Android中的路由实际就是对URL Scheme的封装;

组件化开发可以带来以下优势:

1、加快业务迭代速度,各个业务模块组件更加独立,不再出现业务耦合情况;

2、稳定的公共模块采用依赖库方式,提供给各个业务线使用,减少重复开发和维护工作量;

3、迭代频繁的业务模块采用组件方式,各业务研发可以互不干扰、提升协作效率,并控制产品质量;

4、为新业务随时集成提供了基础,所有业务可上可下,灵活多变;

5、降低团队成员熟悉项目的成本,降低项目的维护难度;

6、加快编译速度,提高开发效率;

7、控制代码权限,将代码的权限细分到更小的粒度;

三、组件化具体实现

前言:需要先确定业务模块的划分,定义一些全局的变量,来控制模块不同模式的切换。

前期准备:

1)组件模式和集成模式的转换

AndroidStudio中的Module主要有两种属性,分别为:

1、application属性,可以独立运行的应用程序,就是一个app

apply plugin: ‘com.android.application’

2.library属性,不可以单独运行,一般是依赖的库文件

apply plugin: ‘com.android.library’

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

但是我们如何让组件在这两种模式之间自动转换呢?总不能每次需要转换模式的时候去每个业务组件的 Gralde 文件中去手动把 Application 改成 library 吧?如果我们的项目只有两三个组件那么这个办法肯定是可行的,手动去改一遍也用不了多久,但是在大型项目中我们可能会有十几个业务组件,再去手动改一遍必定费时费力,这时候就需要程序员发挥下懒的本质了。

试想,我们经常在写代码的时候定义静态常量,那么定义静态常量的目的什么呢?当一个常量需要被好几处代码引用的时候,把这个常量定义为静态常量的好处是当这个常量的值需要改变时我们只需要改变静态常量的值,其他引用了这个静态常量的地方都会被改变,做到了一次改变,到处生效;根据这个思想,那么我们就可以在我们的代码中的某处定义一个决定业务组件属性的常量,然后让所有业务组件的build.gradle都引用这个常量,这样当我们改变了常量值的时候,所有引用了这个常量值的业务组件就会根据值的变化改变自己的属性;可是问题来了?静态常量是用Java代码定义的,而改变组件属性是需要在Gradle中定义的,Gradle能做到吗?

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

# 每次更改“isModule”的值后,需要点击 "Sync Project" 按钮
#不能用;结束
isModule = true

然后我们在每一个业务组件的build.gradle中读取 isModule,但是 gradle.properties 还有一个重要属性: gradle.properties 中的数据类型都是String类型,使用其他数据类型需要自行转换;也就是说我们读到 isModule 是个String类型的值,而我们需要的是Boolean值,代码如下:在模块build.gradle中

if(isModule.toBoolean()){//如果是组件模式---可以单独运行
    apply plugin: 'com.android.application'
}else {//集成模式,不能单独运行
    apply plugin: 'com.android.library'
}

这样我们第一个问题就解决了,当然了 每次改变isModule的值后,都要同步项目才能生效

2)组件之间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呢?

但是大家应该注意到这个问题是在组件开发模式和集成开发模式之间转换引起的问题,而在上一节中我们已经解决了组件模式和集成模式转换的问题,另外大家应该都经历过将 Android 项目从 Eclipse 切换到 AndroidStudio 的过程,由于 Android 项目在 Eclipse 和 AndroidStudio开发时 AndroidManifest.xml 文件的位置是不一样的,我们需要在build.gradle 中指定下 AndroidManifest.xml 的位置,AndroidStudio 才能读取到 AndroidManifest.xml,这样解决办法也就有了,我们可以为组件开发模式下的业务组件再创建一个 AndroidManifest.xml,然后根据isModule指定AndroidManifest.xml的文件路径,让业务组件在集成模式和组件模式下使用不同的AndroidManifest.xml,这样表单冲突的问题就可以规避了。

上图是组件化项目中一个标准的业务组件目录结构,首先我们在main文件夹下创建一个module文件夹用于存放组件开发模式下业务组件的 AndroidManifest.xml,而 AndroidStudio 生成的 AndroidManifest.xml 则依然保留,并用于集成开发模式下业务组件的表单;然后我们需要在业务组件的 build.gradle 中指定表单的路径,代码如下:

这样在不同的开发模式下就会读取到不同的 AndroidManifest.xml ,然后我们需要修改这两个表单的内容以为我们不同的开发模式服务。

首先是集成开发模式下的 AndroidManifest.xml,前面我们说过集成模式下,业务组件的表单是绝对不能拥有自己的 Application 和 launch 的 Activity的,也不能声明APP名称、图标等属性,总之app壳工程有的属

  • 12
    点赞
  • 35
    收藏
    觉得还不错? 一键收藏
  • 5
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 5
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值