android组件化思考

android发展到今天，虽然说很多的业务逻辑都会放在服务端处理，但是随着功能的增加，app的体积还是会越来越大，虽然统一采用了规定的MVP模式，有时候还是连自己都觉得各个模块间的相互依赖太多，比如说我们有订单模块，购物车模块，门店模块，个人中心模块等等，相互之间都会有依赖。
以前我们的模块是这样的：

上面这个图是做过androd的程序员最熟悉不过的工程了，所有的java文件都写在同一个app模块下。
那么下面我们再来看下现在的工程（只是一个列子）

上面划掉的也是一个模块，只是由于公司的名称的原因，所以不方便展示（以下模块划分只是一个参考）。

那当初为什么这个划分呢？
1：首先由于功能模块很多，一下子划分为很多的模块，任务量会比较大， 所以我们的原则是当要在模块模块中修改需求时，根据模块的归属，我们会把它抽取成一个module，这样就可以在增加业务的同时进行组件化工作，同时减少测试同学的工作量。
2：每一个模块，只需要能够实现一个功能，比如门店模块，里面所有的实现都是有关门店有关的代码。
3：跳转，当改动其他模块的时候，跳转的逻辑能够不需要修改。虽然现在分的模块不是很细，但如果到时侯某个模块需要分解成更小的不同的模块的时候，跳转也不需要变化。
4：每个模块由于存在于不同的git仓库中，所以打包apk的时候，我们只要通过依赖响应的aar，就能够实现。
5：修改底层库，比如网络层，图库层，因为我们提供了接口，所以底层的修改不会引起业务逻辑层的修改。
在组件化的工程中遇到的问题：
1：通用对象在各个模块间的使用
公共的对象，由于在不同的模块中需要使用中，所以我们暂时先把他放在了基础组件的地方。
2：跨 module 的 Activity 或 Fragment 跳转问题
跳转，通过统一的接口的跳转逻辑实现。
3：AAR 或 library project 重复依赖

通过这种方式，排除重复引用。
4：资源名冲突

5：aar包依赖的问题

排除多次引用。

以上的组件化过程还有很长的路要走，仅记下，为以后更好的组件化。