Android 组件化架构&Dagger.android实施过程笔记

现在的项目体积真的是越来越大了，APK 各种瘦身加上只用一套图片资源等手段编译出来的包有20多MB，当然和某些动不动就100 M 的APP 比较起来还是小的。但是IM，数据统计，CRASH 统计，语音识别，人脸识别模块，加解密，地图，极光小米华为推送一加起来每次编译调试实在慢的不能忍受特别是加了语音识别后。

等待和做重复性的工作对IT 从业者来说几乎就是慢性自杀。怎么摆脱呢？

模块化&组件化

模块化和组件化本质思想是一样的,都是”大化小”,两者的目的都是为了重用和解耦,只是叫法不一样.如果非要说区别,那么可以认为模块化粒度更小,更侧重于重用,而组件化粒度稍大于模块,更侧重于业务解耦.

image.png

为了便于理解，如上图所示我们把简化的精简模型简要介绍

• Main是一个空壳工程，打包的时候会把sub 1 2 3 包含进去
• sub 1 2 3 是我们的业务模块工程，比如IM 啊，打卡考勤啊，人脸识别水印相机，可以单独开发调试，也能被包含进Main 工程
• base 是抽象出来的公共的

这样子分割解耦各个Sub 之间完全是可以隔离的，某个Sub完全可以外包出去

也就是说：表面看起来，这是一个普通的多模块的工程，但是实际上，他们的关系是动态的：写代码时是七个葫芦娃，每个模块都是可以单独开发调试的，总编译时都被Main含括了。
由于每个业务的代码量相对整个业务线来说大大减少了，所以得到了更快的编译速度，这点非常重要，时间不能浪费在等待上，带薪编译我们也是不开心的。

为什么要组件化

随着项目业务的不断发展，开发人员的不断扩增，暴露出来的问题日益增多。

• 优化编译效率，开发新业务的时候只要编译BASE+新业务代码，同理测试和验证也是
• 多人协作管理会更加简单，还可以对不同组件进行差异化权限控制
• 灵活的对业务模块进行配置和组装
• 重用和解耦

怎样的实施组件化过程

改变总是痛苦的，前几年为了改变Http 请求处理（Retrofit），ORM DB 数据存储（Green Dao），线程控制切换处理（Rxjava）话费了大量时间。现在业务的体量又是今非昔比，改变总是要一步一步走，先易后难。

Dagger.android 与组件化实施过程

Dagger.android 应该是最难掌握的Android开发的点之一，但是对于解耦和组件化的实施真的很有帮助

跳转分发路由 Arouter

组件化后模块之间Activity 的跳转等肯定无法硬编码进行了，阿里巴巴的Arouter 是非常不错的。
炒鸡解耦

BaseModule（也可以叫CommonModule） 中需要包括的东西

BaseModule 是其他一切业务组件的基础，里面包含了基本的抽象出来的有共性的东西

• ORMDB ，图片加载，SharedPreferences,

• 公共的图片，颜色定义呢？

• 选择环境的登陆的页面要吧

• 大的

• AndroidManifest声明了我们 Android应用用到的所有使用权限 uses-permission 和 uses-feature，放到这里是因为在组件开发模式下，所有业务组件就无需在自己的 AndroidManifest.xm 声明自己要用到的权限了。

• Common组件的 build.gradle 需要统一依赖业务组件中用到的 第三方依赖库和jar包，例如我们用到的ARouter、Okhttp等等。（不要ButterKnife）

• Common组件中封装了Android应用的 Base类和网络请求工具、图片加载工具等等，公用的 widget控件也应该放在Common 组件中；业务组件中都用到的数据也应放于Common组件中，例如保存到 SharedPreferences 和 DataBase 中的登陆数据

• Common组件的资源文件中需要放置项目公用的 Drawable、layout、sting、dimen、color和style 等等，另外项目中的 Activity 主题必须定义在 Common中，方便和 BaseActivity 配合保持整个Android应用的界面风格统一。

• （实验一下，Good）测试的时候，组件apk的登录状态，其实可以通过设置共同的sharedUserId来读取壳app或者main app的shareprefrence或者db来解决，只要token等userprofile信息有持久化保存下来就行。

总结

最近几年很多公司都开始了 App 的组件化，组件化的基础思想都是相通的，但是并没有一个放之四海而皆准的通用解决方案，各个公司在组件化的过程中都会根据自身的情况不断的调整方案，适合自身发展的，才是最好的。一些组件化初期看起来不起眼的问题，可能进行到后期才会慢慢显现出来，这时候就要及时调整方案。不断的变动中逐渐完善的，并且以后肯定也会随着业务和代码的变动不断的进行优化，这会是一个持续的过程。

image.png

• Demo说明
  Demo 由于信息安全和涉及的License删除后重新迁移到 https://github.com/AnyLifeZLB/MVP-Dagger2-Rxjava2 ，还是一样的配方

image.png

实际项目的改造过程还是会遇到很多问题的，请多交流，我也是看了下面的书然后找资料然后写了一个Demo开源出来

image.png