组件化

当下安卓的组件化方案可谓是五彩斑斓，为多人大规模并行开发带来的极大的便利，优点有以下几点：
1，最大程度实现代码复用；
2，代码层次清晰，工程结构有条理；
3，提高多人协作开发效率；
4，易扩展，降低耦合；
但是要实现组件化基本有以下要求：
1，代码解耦，将一个大工程进行合理拆分成一个个独立的组件；
2，组件的单独运行与调试，每一个组件都可以做到单独运行和调试；
3，组件通信，组件之间的数据通信，UI跳转等；
4，代码和资源的隔离，将每个组件中的逻辑功能实现代码和资源进行完全隔离开；

代码解耦

要实现代码解耦，需要对现有业务有一个完成的轮廓，现有组件化方案基本都会把结构大致分为几个大的层次：app壳，业务组件，功能组件。
app壳：该层主要对组件进行组合打包apk等逻辑；
业务组件（纵向）：该层主要是对应和应用强相关的一些业务逻辑实现和处理，比如一些登录组件，消息组件，订单组件，个人信息组件等等，是和应用具有强依赖关系的组件；
功能组件（横向）：该层次基本都是一些脱离具体业务，侧重某一向功能的组件，比如网络，日志打点，消息推送，分享，支付等等，都是一个通用的功能组件，不限于某一个app，强调的是实现某一功能；
所以，从以上可以看出，功能组件是基础，如果一个公司具备完善的功能组件，那么它就会有快速构建app的能力，业务组件基本都是依赖于需求的，脱离了需求，业务组件的价值就得不到体现，但是具体该怎样拆分，还需要对整个业务非常熟悉；app壳属于最上层，对业务组件进行选择性打包，具体是否需要某一个业务组件取决于当前的公司需求是否需要。当然功能组件基本都会有许多开源的框架可供选择，并不需要我们从零开始，但是，对于一个更成熟的公司，要高瞻远瞩，因为技术在不断更新，就拿网络库来说，从android-async-http，volley,okhttp,retrofit,同样是网络库，可能公司不同部门会选用不同的网络库，如果某一天需要将多个app打造成聚合app，进行合并，那将是非常痛苦的，所以，最好的方式是公司实现一套自己的一套网络接口功能组件，具体实现对外屏蔽，只暴露接口，这样，可以方便的进行管理，也为后期解除的后患。

组件的单独运行与调试

拆分的组件如果不能单独的运行和调试，岂不是很痛苦，所以，让每个组件可以单独运行和调试非常重要，当然现有的一些组件化方案已经给了很好的实现方案，不必多说。但是组件的调试又分为组件内部调试，和组件之间联调，内部调试更好处理一些，我们只要能够处理好组件从application到libray的转换即可，当然调试的时候我们会需要自己的启动入口Activity，application等，或者是一些调试的类，一个更好的处理方式是我们可以借助微信pins工程的思想，将我们需要调试的代码和资源单独出来，通过sourceset去动态设置是否需要将调试代码和资源进行编译；当组件作为library时我们又可以将调试的代码和资源隔离开；组件之间联调可能会显得比较麻烦一些，一个可行的办法就是借助app壳工程，将必要的组件进行打包，但是一个组件的运行可能还会涉及到登录态等一些限制，所以这些都需要提前准备好。

组件通信

为了实现组件之间的通信，现在基本都会采取路由的方式实现UI的跳转，不管哪种路由，适用自己就好，组件之间的数据通信，也有很多通用的消息通信框架，或者是接口+数据结构，但是这里有一个问题就是，比如组件A依赖组件B的服务，依赖B的某个类，通常都是将接口或数据结构下沉到基础库或者公共库里面，到后期必然会造成基础库爆炸式增长，许多类过度集中到基础库中的问题会越来越严重，那么如何才能够避免这种情况，让基础库去中心化呢？Android组件化方案及组件消息总线modular-event实战给了一个比较好的实现方案，每个业务组件都划分成了Export Module+Implement Module的模式，将接口和实现完全隔离开，感觉思路很不错，当然如果你觉得这种做法比较隔离级别比较重，那么我们也可以通过微信p工程一样去进行隔离，我们发布两个版本，一个是Export版本，对外提供接口和数据结构让别人可以依赖，在发布一个Implement 版本，进行具体的实现逻辑。当然我们也可以借助ServiceLoader的思想将所有接口和实现类进行配置，为了降低所依赖的数据结构类的数量，最好的方式是我们可以使用android特有的message，bundle或者是一些集合类等进行一些简单参数数据的传递。

代码和资源的隔离

在对基础库中去中心化的过程中，我们通过只依赖其他的接口和数据结构已经很好的隔离了代码，但是对于资源来说还有一些问题就是资源冲突，为了规避资源冲突，我们可以在命名上进行一些约定，比如所有资源文件以module名开头