起源
我们知道，软件开发项目是一个综合平衡的过程，要平衡时间、成本、范围、质量四个要素，在单个项目中，这四要素是非此即彼的：时间紧迫就要压缩需求范围，添加需求就要追加成本，确保质量就不能过于压缩工期，相互之间无法调和。
但如果跳出单个项目，在日常积累上面下功夫，我们却有可能找到一种同时有利于项目四要素的途径，就是建立和使用通用的开发架构。
大部分公司不会仅研发一个App，而是会研发一系列App，形成家族化、品牌化，或互相依赖，或入场试错，这些App功能业务可能不尽相同，但一般都需要网络模块/日志模块/图像加载模块，需要一些常见的简单函数，为建立品牌形象，还需要统一的主题资源如色调/图标/提示语等。
这些低水平的重复开发，是与业务没有直接关系却必须支付的“死重”，是可以通过模块复用来提升效率的，这也是我们做Android架构分层的初衷，我们把开发中常用的模块抽象出来，分组分层，形成结构清晰，组装灵活的通用组件库，支撑起了多个App的快速实现与迭代。
价值
在实际开发过程中，我们发现通用组件库对于开发的效率和质量，都有了显著的提升：
1.节省时间，因为组件功能可以复用，能降低团队成员熟悉项目的成本，为新业务开发提供基础，加快开发迭代速度，有利于更快地发布版本。
2.降低成本，把稳定的公共模块抽象为通用组件库，提供给各个业务线协作使用，能在全公司范围内减少重复开发和升级维护的工作量
3.提升质量，频繁使用的功能/业务模块采用组件复用方式，更有利于暴露缺陷，一处修改，多处受益，提高产品质量。
具体设计
对于App来说，选用组件应该按需取用，仅选用自己需要的那些组件，这就需要把组件分离为多个，形成一个结构化的组件库，我们最终形成的组件库大概是这样的：
在上图的结构中，通用组件是与业务无关的基础功能，共享组件是与业务有紧密联系的，共享组件可能需要引用通用组件。
在具体实现中，我们处理过这样几个问题：
- 引用形式
在引用形式上，我们有aar和module代码两种方式，其中aar适合函数已经固定，不允许扩展修改的情况；module适合类型已经分开，但是函数并未固定，可以增加新函数的情况。 - 依赖倒置
在引用第三方库时，我们禁止直接引用，App可以直接引用第三方库，但是组件必须使用自己的接口，这样在第三方库升级或者更换时，不会影响顶层的app。
例如网络层必须使用网络组件自己定义的callback接口，实际上就是都要依赖于抽象，不能依赖具体。 - 接口隔离
组件库大量使用接口为App服务，这要求接口保持互相隔离，尽量把功能拆分到多个接口里，不能出现大而全的接口。 - 单一职责
每个组件仅负责一类功能，互相之间可以有调用，但不能出现一个大而全的组件。 - 开放封闭
组件中的函数是严禁修改的，可以增加新函数，但严禁修改已有函数，除非是为了消除缺陷。 - 异常抛出
底层组件有时候必须做异常捕获，无论是Exception还是Error都需要抛出，也就是说所有的Throwable都需要向上层抛出，避免应用层莫名其妙的发现流程被打断，无法查知底层组件出现的异常。 - 质量控制
底层组件的场景比较抽象也比较固定，实际上容易做单元测试和自动化测试，为组件开发专门的自动测试模块，甚至出一个自动测试demo，都是性价比很高的投入。 - 代码追溯
对于module形式共享的组件，实际上允许开发团队进行扩展和修改，但是所有的变更都隐藏着缺陷，所以在组件库的代码提交中，必须进行代码审查，并注释代码修改的时间、事由、操作人等，以便在出现缺陷时进行追溯 。 - jar包冲突
长期维护下来，必然可能引用多个版本的第三方库，这就会产生jar包冲突的问题，所以有必要在底层建立一个整合第三方库的module，各App共同引用这个库module。 - 版本分支
有些情况下，某些第三方库发生了大版本的迭代更新，更新前后的功能变化极大，导致app无法完美兼容，这就需要建立版本分支，使用特定版本的组件库，维持app的研发需求，直至app重构，或app消亡。 - 路由解耦
有些业务组件是有Activity的，这些组件之间跳转时，为了解耦合，应该避免通过包名和类名去跳转，可以参考Android的Intent思想，允许通过action和category一起过滤，找到跳转目标，实际开发中可以做一个Router，例如阿里开源的ARouter
最终，App选用组件库的结构，大概是这样的：
