组件化：
链接：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掉，然后就可以正常运行