组件化与插件化的学习（一）

随着业务越来越多，参与人员越来越多，相互之间任务不明确，开发耦合，代码重叠修改，协调效率低下，动一发牵全身。

**问题：**上述情景在APP的迭代开发，人员变更是必然存在的~，~这就给了我们理由去重构我们的代码了，毕竟一个好的程序猿是为了解决问题而生，而不是单纯码代码。

**解决方案：**面前主流的做法解决思路一般都是：组件化和插件化 ####1. 组件化开发就是将一个app分成多个模块，每个模块都是一个组件（Module），开发的过程中我们可以让这些组件相互依赖或者单独调试部分组件等，但是最终发布的时候是将这些组件合并统一成一个apk，这就是组件化开发。 ####2. 插件化开发和组件化开发略有不用，插件化开发时将整个app拆分成很多模块，这些模块包括一个宿主和多个插件，每个模块都是一个apk（组件化的每个模块是个lib），最终打包的时候将宿主apk和插件apk分开或者联合打包。 一图看懂组件化和插件化

---

###组件化###

---

首先先来了解组件化 定义：组件化就是基于可重用的目的，将一个大的软件系统按照分离关注点的形式，拆分成多个独立的组件。 简单点：不同功能做成一个组件，达到可重用目的。再不懂看上面的图。 讲道理~

1. 首先看看年轻时候写的代码
   这种代码相信很多猿年少轻狂都会写过吧，复制粘贴。但是作为一个会进化的猿，是谁给你的勇气再写这样的代码的？梁静茹吗？
2. 那好，我们再来看看可重用的做法
   这种应该很常见，层级分明。但是转身一想，还记得我们文章的开头吗？ 随着业务越来越多，参与人员越来越多，相互之间任务不明确，开发耦合，代码重叠修改，协调效率低下，动一发牵全身。
3. 行，产品是爸爸，你说加就加。你有张良计我有过墙梯。你不逼我我都不进步。 回看组件化的思想，不同功能做成一个组件，可重用
   APP有一个壳工程（主工程），然后有着各种功能的基础组件（网络、数据库、图片加载等）。然后负责登录组件的开发童鞋只需要在主工程和基础组件的基础上开发登录组件即可，达到了代码重用、解耦。可开发可测试。其他业务组件同理。 但是现实是这样吗？想多了吧。 举个栗子：用户操作组件需要什么？用户。用户哪里来？登录来的。那好，登录组件和用户组件就存在了一定的耦合，用户组件必须依赖登录组件。 或许你会说：“这还不简单，一个壳工程和基础组件加上登录组件、用户操作组件一起开发就行。” 想法是好，那假如业务组件需要依赖多个业务组件呢？这个业务组件也需要依赖另一个业务组件呢？不同模块下跳转？隐式跳转？

4. 接下啦要掏出我们的大宝剑。要解决上面的耦合，隆重介绍主角——路由（Router）。对路由的了解可以看这篇文章Android架构思考(模块化、多进程)