组件化之总结

组件化：

链接：http://note.youdao.com/noteshare?id=2eab8aa620df7b30b9747aedbfea3d9b&sub=D34FD81DFCFD40E1817F42EFC7817E47

Demo地址：https://github.com/Quyunshuo/ComponentDemo
 

组件化的简介

将apk拆分为多个模块（组件）进行开发，开发阶段组件可单独测试，通用组件可进行依赖复用，开发完毕阶段，将所有模块（组件）进行合并为真正的apk

组件化的好处

• 业务组件可以单独分配并行开发
• 单个组件业务可以由开发者自行决定采取MVC/MVP/MVVM架构而不影响整体大局
• 新同学接手项目分配任务可单独分配某一个模块任务,不必关心整个项目
• 开发效率提升,开发过程仅仅需要维护开发自己的组件内容
• 若公司有多个团队,优秀代码组件可快速移植复用
• 积累个人的组件仓库,摆脱粘贴复制的“搬砖工”身份
• 测试可单独测试某个模块

组件化构建流程

• 组件以及第三方SDK的版本控制

组件化开发中存在多个组件与模块，必须考虑每个模块的统一性，所以需要对每一个module进行support包和第三方SDK配置的统一管理。统一配置以后供其它组件模块使用。

1.组件化架构需要一个版本控制文件来控制整个项目的各种版本，需要在项目下新建config.gradle文件并添加需要控制的版本信息

2.在各组件的build.gradle文件中进行修改版本信息，将项目版本控制的内容加入

3.为了让整个项目都能正常使用版本控制文件，在项目的build.gradle文件中添加对版本控制文件的支持

• 动态切换Application和Library模式

在组件化中是由各组件和一个主的App构成，组件就是一个Library，它是最下层的东西供App使用，它既可以作为一个Library，又可以作为一个App，这就需要动态的去切换这两种模式

1.在config.gradle文件中添加一个属性用来控制各组件的模式

2.新建的组件进行更改build.gradle文件，进行版本控制。isApplication为true时是Application，反之则为Library。

 

3.怎么使用config.gradle文件中的属性进行控制各组件的模式呢？

在各组件的build.gradle文件添加if判断即可

在Application模式下是需要一个applicationId的，因此再添加一个判断，注意他的id是不能够重复的，现在他就是App，只不过现在他还没有Activity

当isApplication为false的时候它就是Library模式

• Library组件与主App的AndroidManifest清单合并

在每一个组件中都会有AndroidManifest清单文件，它们也是需要进行分模式处理的，不同的模式下需要不同的AndroidManifest。

1.在组件中新建debug和release文件夹，把清单放入两个文件夹中，其中debug 文件夹内的清单代表Application模式下需要的清单内容，release文件夹的清单代表Library模式下需要的清单内容。

当组件是Application模式的时候需要的清单格式如下，把相关资源复制到该组件中

当组件是Library模式的时候需要的清单格式如下

在组件build.gradle文件中添加if判断来控制不同模式下对清单的调用

当组件是Library模式的时候还需要移除Application模式下debug中无用的包

下面来测试一下，把组件的模式调为Application模式，并在组件中新建一个Activity，在debug下的AndroidManifest清单文件中注册此Activity作为启动Activity

 

在模拟器中运行这个组件，可以看到该组件是可以正常运行的

• 组件与主app的application冲突与初始化

我们做Android开发的时候通常会写一个全局的application来引用，那么在组件化架构下如何进行使用application呢？

1.再新建一个组件ModuleB并把所有的配置都按ModuleA设置好，新建一个Activity-RegisterActivity作为主Activity

2.现在整个项目有一个主app，两个Module

当module作为单独的APP存在时（也就是Application模式）各个组件都要引用自己的application，可以在各组件的src/main/java/下新建一个包debug来存放自己的application类（为了测试只添加打印的功能即可）

 

 

并在各组件自己的debug下的AndroidManifest清单文件下引用application

 

运行两个Module，可以看到Log打印

 

当各组件为Library模式为主app服务的时候，它们就需要整合application，具体操作如下：

在主app中新建application类，添加两行Log，在主app的AndroidManifest清单文件中引用此application

 

完成这一步之后还需要在主app的build.gradle文件中进行引用这两个Module

运行主app此时可能会出现资源命名冲突和项目清单合并失败的问题，抛去这个问题，程序是可以正常执行的。

项目清单合并失败解决方案：

在app的项目清单中的<application>标签内添加tools属性

解决了这些问题运行主app，可以看到正常打印两行Log

如果后续还会报错R文件不属于任何资源，就重新构建项目

• 组件与组件之间的资源命名冲突

各组件之间会出现相同资源名的情况，在组件为Application模式的时候不会出现冲突，当作为主app的依赖时就会出现资源命名冲突的问题

解决办法也较为简单：

在各组件的build.gradle文件中添加一行代码，作用是为该module的资源名添加前缀用以区分个组件之间的资源命名

然后手动更改各项资源名，例如：values下的资源id，activity，layout，把所有id更改为带前缀的，下次再新建此类资源的时候我们在build.gradle所规范的命名前缀就会自动补全

• 组件与组件之间的跳转通信

这里主要使用Intent进行跳转通信

在app的activity布局文件中新建两个按钮用来跳转

在MouduleA和ModuleB中也是创建两个按钮用来跳转测试

 

由于三者是分离的，可以用具体的包名来做Intent跳转。当组件作为主app的依赖时，它们所使用的AndroidManifest清单文件是release文件夹下的，因此需要对此文件进行相应配置

 

然后添加具体的逻辑代码（对跳转代码进行了封装）

运行后可以正常跳转，ModuleA、ModuleB不再演示

那么怎么进行通信呢？其实也很简单，以主app跳转到ModuleA为例：

 

运行程序可以看到跳转后接收到了传的值

 

组件单独运行时需要在主app的build.gradle文件中添加一个判断

运行ModuleA的时候要把接收intent值部分try/catch掉，然后就可以正常运行