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包依赖的问题 排除多次引用。

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