android四大组件系列,android的四大组件和作用

android四大组件系列,android的四大组件和作用

在Android开发中，随着项目的不断扩展，项目会变得越来越庞大，而随之带来的便是项目维护成本与开发成本的增加！每次调试时，不得不运行整个项目；每当有新成员加入团队时，需要更多的时间去了解庞大的项目。。。而为了解决这些问题，团队通常会将项目模块化，以此来降低项目的复杂度和耦度，让团队可以并行开发与测试，让团队成员更加专注于自己所负责的功能模块开发。。。

对于一些大厂如BAT或者美团等这些大型互联网公司，都会自己造轮子，实现项目模块化。而对于中小型公司，限于成本因素，一般都是选用这些大厂造的优秀的轮子来进行项目模块化。本文以及后面一系列文章，将向大家分享我在项目模块化中的实践经验。我的项目模块化方案主要借鉴于饿了么、微信、美团 的模块化技术文章，如有建议，欢迎提出！

首先，在开始项目模块化之前，我们必须要明确模块化需要做些什么？这就等于写书之前必须得有个总纲，否则越写到后面，越是混乱。以下是我认为在模块化时需要注意的几个问题：

如上图所示，我将项目大概划分为五层：

以上是大多数项目模块化时的拆分方式，每个人也可以根据项目的实际情况进行调整。

1. 常用的通信方式

当项目被拆分成多个模块后，模块之间的良好的通信是我们必须考虑的问题。ARouter本身也提供一套通信机制，但是一般很难满足我们所有的需求，所以我们会容易想到的常用的几种通信方式：EvenBus、协议通信、广播或者是将通信的部分下沉到公共组件库。对于这几种方式，在一些大厂的技术文章中都有提到一些他们的看法，下面我简单总结一下：

2. 改善通信方式

上面说了一些常用的通信方式，可以看到大厂并不是很满意，那么大厂都是怎么解决的呢？没错，大厂往往都会有重造一个符他们要求的通信框架！然而这不是我们想要的（中小型公司的实力和成本不允许啊）,不过没关系，我们可以根据大厂们的思路，自己建造一个精简实用的通信架构，下面一起来看!

2.1 使用接口进行通信

接口通信概念并不是什么新颖的概念，微信在技术文章中着重说明过，ARouter框架也具备这种能力。下面我们配一个小例子形象的说明一下。

eg：在一个房产项目中，有与新盘两个模块，这两个模块使用相同的接口（传入参数不同）获取楼盘数据。

针对这种状况，一般我们下沉数据接口公共组件库，然后和新盘都去调用公共组件库中的楼盘接口获取数据。而上面也说过了，这种情况的后果就是，当有数十上百个接口被下沉到公共组件库后，公共组件库已然中心化且变得很庞大，这不是我们想要的。我们需要的是去中心化，开发成员只需要专注于自己负责的模块本身，减少模块之间的耦。而接口化的通信方式给我们提供了这种可能。

对于这种接口化的通信实现，ARouter 的IProvider 就已经实现，完全可以满足我们的要求。具体如何使用IProvider，这里就不在详细介绍，大家可以网上自行搜索。

2.2 如何对外暴露接口

解决了通信手段的问题，我们就得考虑另一个问题，为其他模块提供的接口+数据结构 我们应该放在哪里？下沉到公共模块吗？或者另外新建一个module用来维护这些接口+数据结构？但是这样一来，成本就有些大了，也不方便。

在微信的模块化文章中提出了一个解决方法，将你要暴露的接口+数据结构 甚其他想要暴露的文件都.api化 ，即将你要暴露的文件的后缀名改为api，然后通过特定的方法将api后缀的文件拷贝出来，在module外部重新组成一个新的module（也可称为SDK），而想要使用的模块只需要调用这个SDK即可。当然，拷贝文件和组件SDK是完全自动化的，并非手工，这样才能节省成本。

由于微信的模块化文章中没有涉及到.api化的具体实现，所以根据这种思路，我使用了其他方法来实现要达到的效果。具体思路如下：

1.创建一个名为_exports的文件夹，需要对外暴露的文件都放在里面

2.将_exports文件夹打包成jar

* 创建 jar 包 */task makeExportJar(type: Jar) { baseName = hpauth-exports version = 1.0.0 extension = jar // java文件编译后的所在位置 from('build/intermediates/classes/debug/') // kotlin文件编译后的所在位置 from('build/tmp/kotlin-classes/debug/') include('com/homeprint/module/auth/_exports/**') // jar包导出路径 destinationDir = file('build/_exports')}

3.将jar发布到本地maven仓库（发布到本地仅仅针对个人开发的时候；团队开发时，大家使用各自的电脑，无法访问到你本地的maven仓库，所以这时需要在局域网中建立一个maven仓库。

archives makeExportJar}uploadArchives { repositories { mavenDeployer { // 本地的maven仓库路径 repository(url: uri(../repo)) pom.project { groupId 'com.homeprint.module' artifactId 'auth-exports' version '1.0.0' } } }}

4.在需要的模块调用jar

注： 此处必须使用compileOnly 来调用，compileOnly 是provided 的替代方法，provided 将被google废弃。此处使用compileOnly 代表，jar包只在编译时有效，不参与打包。如果使用api 或者implementation，因为我们只是将文件拷贝出来成为一个单独的SDK，并未修改包名和文件名，当将多个模块集成为一个app时，会抛出异常，提示jar包中的文件已存在。

2.3 使用EventBus时，自建简单的事件索引

以上的通信手段能满足大多数的场景，但是也会遇到满足不了的情况，比如在一个模块中的线程执行任务，执行完毕后通知另一个模块做出改变，这种模块处于被动接收信息的模式下，一般我们使用的手段就是广播或者EventBus，而相比广播，EventBus更灵巧。

虽然微信不是很，但是美团却是比较看重此种EventBus这种类型的通信手段。就个人而言，我认为只要能理控制EventBus，这也是一种比较的通信手段。而EventBus目前最被诟病的一点就是无法追溯事件，所以为了能更好的控制EvenBus，我们可以自建一个事件索引。

private Object index; private T data; public Event() { } public Event(Object index, T data) { this.index = index; this.data = data; } public Object getIndex() { return index; } public void setIndex(Object index) { this.index = index; } public T getData() { return data; } public void setData(T data) { this.data = data; }}在我们每次传递Event<T>时，必须为事件添加index索引标识而我们可以在公共模块类中创建一个索引类，用于记录所有的索引标识，这样我们就可以根据这些标识，简单的做到事件追溯

companion object { // 事件从修改昵称页面发送用户信息页面 const val EVENT_FROM_MODIFYNAME_TO_USERINFO = From_ModifyName_To_UserInfo // 事件从修改邮箱页面发送用户信息页面 const val EVENT_FROM_MODIFYEMAIL_TO_USERINFO = From_ModifyEmail_To_UserInfo }}

还有值得注意的一点，在公共模块中，仅存放模块之间的通信索引标识；模块内使用EventBus通信，建立的索引放在对应模块内，给公共模块EventIndex文件降级，如下图示例：

虽然在模块化时，我们已经将业务拆分成了一个一个单独的module，但是有的业务实在是庞大，即使单独拆分成一个module，仍然有些臃肿。但是如果将业务module继续拆分成单独的子module，又会显得过重。此时我们就要开始寻求比module更小一级的粒度，这一点《微信Android模块化架构重构实践》中给我们提出了Pins工程的思路。

如上图，我们可以在module中构建粒度更小的pins工程来拆分业务，可以更加清晰直观的明确业务内的职责分工，示例代码如下：

def dirs = ['p_imageview','p_progresar'] main { dirs.each { dir -> java.srcDir(src/${dir}/main/java) res.srcDir(src/${dir}/main/res) } } }

上述代码做到的是仅仅是分割代码，pins工程之间还可以相互调用。而微信提出的是工程之间没有依赖关系存在，则不可以相互调用，类似于两个module之间，如果没有在gradle中注明依赖，则不可相互调用。所以，有些人就会提出，既然如此，为何不直接拆将Pins工程 完全拆分成module？

论坛中开发者们给出的最多的答案是编译速度！不过快手的一位资深Android工程师说，微信内部已经放弃了Pins工程，虽然不知道是真是假，不过美团在借鉴微信的Pins工程 时，也没有提出代码的完全隔离。就个人而言，我认为Pins工程 是module化的一个过渡阶段，当Pins工程 的体量达到一定程度时，必须进行完全的module化，所以也没有必要做到Pins工程之间的代码完全隔离，做到以上即可。如果有想实现代码完全隔离的，可以参考《Android Pins 工程结构》

在组件化开发时，每个组件都应该有自己独立的生周期，这个生周期类似于组件自己的application，在这个生周期中，组件可以做一些类库的初始化等工作，否则如果每个组件都将这些工作集中到壳工程的Applicaiton中实现的话，会显得壳工程的Application太过中心化，并且一旦需要修改，会很麻烦，且容易产生冲突。

基于上述原因，我们可以自己搭建一个简易的组件生周期管理器，主要分为两步：

1.构建组件的生周期模型，构建的模型持有整个app的Application引用，同时提供三个基础方法：生周期创建、生周期停止以及生周期的优先级设置。

2.有了生周期模型，我们还需要一个管理器，用于管理这些组件的生周期模型，在这个管理器中，我们同样需要实现三个基础方法：生周期模型的注册，生周期模型的反注册以及执行已存在的生周期模型。

override fun onCreate() { super.onCreate() BizLifeCycleManager.register(CommonBizLifeCycle(this)) BizLifeCycleManager.register(HttpBizLifeCycle(this)) BizLifeCycleManager.register(RouterBizLifeCycle(this)) BizLifeCycleManager.register(ThirdBizLifeCycle(this)) BizLifeCycleManager.execute() }五、模块在调试与发布模式之间的切换

项目开发时，一般提供调试环境与正式发布环境。在不同的环境中，app的有些功能是不需要用到的，或者是有所不同的。另外，在模块化开发时，有些业务模块在调试时，可以作为单独的app运行调试，不必每次都编译所有的模块，极大的加快编译速度，节省时间成本。基于，以上种种原因，我们就必须对项目的调试与正式环境做不同的部署配置，然而如果全靠每次手动修改，当模块量达到数十时，则会非常麻烦，且容易出错。所以我们需要尽可能的用代码做好配置。

首先，来看如何配置module在app与library之间的切换，实现module在调试时作为app单独运行调试。看示例代码，这也是比较常见的方式：

# true: 作为一个模块 # false: 作为一个appisAuthModule=true在auth模块 的build.gradle 文件中作如下配置：

// 获取 gradle.properties 文件中的配置字段值def isApp = !isAuthModule.toBoolean()// 判断是否为 app，选择加载不同的插件if (isApp) { apply plugin: 'com.android.application'} else { apply plugin: 'com.android.library'}......android { defaultConfig { // library 是没有 applicationId 的，只有为 app 时，才有 if (isApp) { applicationId com.homeprint.module.auth } ...... } sourceSets { main { // 作为app与模块时的AndroidManifest.xml会有所不同，在不同状态时选择不同的AndroidManifest.xml if (isApp) { manifest.srcFile 'src/main/AndroidManifest.xml' } else { // 记得在 main 文件夹下创建 module 文件夹，添加AndroidManifest.xml manifest.srcFile 'src/main/module/AndroidManifest.xml' } }}

这样只要我们更改一下，gradle.properties 文件中的配置字段，就可以自由实现module在模块与app之间的切换。下面我们再来看下，如何实现app在调试与发布环境时，加载不同的模块，看以下示例：