因为都是开发一些不大的项目，团队成员最多也就10来个Android，分配到一个项目上的Android 也就3到6个，我的理解可能不是太对，肯定有偏颇之嫌。
我们先来说常见的为什么要用组件化开发的APP的一种思路。
组件化解决了什么
我们去理解组件化，首先就得知道组件化解决了什么，目前国内支持组件化的方案特别多，阿里系的ARouter,滴滴的DRouter,反正各个大厂基于自己的业务基本上都整了一个自己的组件化方案，然后开源了出来，那么组件化解决了什么呢？
导航与拦截器
导航的使用场景更多的是配合APP的运营管理后台去使用，比如说广告图片的点击跳转到哪里？比如说APP 首页上面配置到功能区块，首先Android 和ios 打开一个界面的方式肯定是不一样的，为了适应这种功能，我们最终的方案可能都会落地到将一个界面定义成一个常量，然后通过统一的入口根据这个常量去跳转到对应的activity 或者fragment， 甚至还有获取view的，既然是这样，那么就一定存在一些界面需要一些前置逻辑，这个就是拦截器要处理的事情，比如说这个功能只能VVVVVip 可以使用，但是APP为了卖这个东西，每个人都可以看到，你需要让用户到购买界面去，这个也可以用拦截器去做，比如说一些活动已经过期了，比如说必须登录、必须实名认证啥的。
当然还有一个情况，那就是现在纯原生开发的比较少了，都是嵌入H5或者小程序、要不就是flutter的maven，而嵌入的东西也有打开原生界面或者获取到原生view的情况，所以会发现上面这一套也很合适。
这一套代码自己写下来，会发现，几乎都是差不多的，只是具体的实现上有差别，因为业务逻辑就这样，基本上可以看做模板代码，所以手写是不可能手写到，我只需要定义接口，通过编译时计算去生成对应的class即可。
当我们的界面或者view的实例可以通过一个常量就可以打开的时候，就会发现一个问题，代码完全不需要写到一个module里面嘛，甚至完全不需要写到一个project里面嘛，我只需要保证打包的APP 里面有这个常量对应的class即可，既然分开了，就涉及到了一个定义常量的怎么汇总啊，这个总不能手写了吧，所以注解和注解处理器就派上了用场，分了module和project，那么喜闻乐见的代码合并问题就几乎没有了，因为你永远只会在对应的功能模块上开发，现在一个多个人处理一个module的情况可太少了，能处理就说明module 还可以细分。
所以说，组件化其实是一种常见的为了配合运营后台处理的解决方案衍生出来的一个东西，这个肯定是必然的结果。
服务
结合上面的东西，既然分module了，必然不可能存在module的嵌套引用，这么编译速度也会加快，当然加上编译时技术导致的耗时，到底谁快还不一定。但是这都是基于现有的诉求决定的，不以个人意志所转移，当然也可以写到一个module里面，只要喜欢即可。
我们还是说会服务，这个概念和Android 的服务还是有一些区别，因为他实现上根本就不是Android Service那一套，Android Service其实可以理解成客户端，会被注册到系统服务管理器里面去，但是我们这里提供的Service只是用于APP内部的业务通信，完全没有必要走到系统里面去。
我们activity、fragment、view都有一个自己的父类或者接口，我们实际上使用的时候也是子类实例指向父类引用，所以我们Service 也需要定义一个接口，我们使用的时候也是直接通过定义的接口去查找到他的实现类，那么就出现一个情况，因为我们是分module 的，所以接口的class 访问不到，所以这就涉及到git 的一个子模块的概念，导入一个公共的module，每个业务module都导入这个这个公共的module，当然没有分project的就不用git 子模块了。
其他
不同的组件化解决方案，其实提供的内容还是有些差别的，可以看到我们使用组件化解决方案还是很有必要的，这是业务场景。我们从个人学习到方式上来看，组件化这种思路可以非常锻炼我们的编码概念的抽离能力，这就是面向接口编程是思想的落地了，我们定义一个输入输出的接口，我们就需要知道整个板块什么是可以输出输出的。
现在大家都在用Kotlin，Kotlin的特性是面向函数编程，但是我们强调面向接口编程，我觉得这个是不冲突的，接口是大的业务框架，而函数是具体的实现，所以完全没有必要因为Kotlin的函数式编程思维就放弃了面向接口编程。
新工程到底怎么做呢？
上面我们简单的水了一下组件化解决方案的由来，现在我们对于工程进行拆解。
common
这个就是上面的公共module。这个提供定义的东西很简单，那就是功能接口和一些公共的工具类。 比如说，现在每个APP基本上都有登录，登录存在登录、注册、退出登录、注销或者第三方登录，那么定义的接口就可以写到这个里面。
baseUI
为什么要拆出来一个baseUI,因为有些module 就是没有任何界面的，比如说网络请求、数据缓存、分享、图片加载等，至于为什么将他们拆分出来，因为练技术嘛，多写几个实现总是好的，要不然面试的时候一问为什么用这个，不用其他的，脑壳都是麻的。
我们baseUi 里面封装一些基础的UI风格及其base层，或者一些公共的动画、图片啥的，或者屏幕适配方案就可以写到这个里面来。反正什么可以就写一次的算UI的都写进来。
bridge
这个玩意，其实现在分3种，所以强烈推荐把实现定义成Service。功能的定义也需要做成Service。现在一般就是H5，小程序、flutter，同样的事情做3遍，这个不好说，现在环境如此，和前几年不一样了，现在能做事是权利，但是一直做事就没法学习，需要自己掌握好这个度，闷头写代码，不去沟通也不好，也没办法。
总结
写到这里，APP的大的框架范围就写完了，剩下的都可以按照自己的实际情况去填充东西。只能说组件化其实是一种解决方案，需要有，要不然后期运营起来的时候，则麻烦，通常是晚上发版，没有这个玩意，产线bug 扛不住，也背不了这个锅。
这里只是简单的讲了下逻辑，是吧，具体的还是看具体的解决方案提供了什么，比如说上的产线bug,如果是崩溃可以使用路由降级的方案，如果是不上了，总不能回退代码，重新打包吧，如果同时上几个功能呢？那不是测试得拖刀砍人了。