Android组件化 & 模块化 & 插件化演进

从事Adroid开发几年来，逐渐对Android应用架构和发展趋势有一点点认识，总结为三个词：“组件化，模块化，插件化”。下面以一张图为基础，分别从这个三个方面进行阐述。

组件化

为什么需要组件化？

Android的原生控件，基本上都没法直接拿来用，太丑了。另外一方面，原生控件在不同的Android版本上可能有不同风格，Holo，Material Design等。而从应用开发者角度来讲，他们需要一个拿来可用的，统一并且可延续的风格。在这种背景下，他们开始自定义系统控件，逐渐形成了自己的风格。比如，微信，支付宝，高德地图等。这样之后，我们就需要将这种风格应用于TextView，Button，ImageView等标准化控件。组件化后，我们开发新功能，只需要直接引用带有自己风格的标准化控件，再稍微调整宽度，高度，字体大小等，就可以应付大多数情况了。

不组件化会怎么样？

如果没有形成自己的风格，又或者是形成固定风格后，不去进行组件化，会有什么后果呢？那大概的情况可能是这样，整个应用风格不统一。给你的整体印象可能是，你一会是在用苹果应用，一会是在用Android应用。打个不恰当的比方，一个男人，上身西装笔挺，下身大裤衩，脚上又是厚厚的棉鞋。

模块化

为什么需要模块化？

起初，一个应用几个人搞定，并不需要模块化这些事情。

但随着业务的发展，应用的迭代，可能出现人员越来越多，业务模块越来越多，越来越复杂的情况。在产品快速迭代过程中，假设某个业务的某个需求，由于外部原因等无法按时开发完成怎么办？或者由于其他原因，导致这部分功能有严重BUG怎么办？下掉这部分功能，又进行全量测试？划不来。硬着头皮修复BUG？万一来不及，错过发布日期怎么办？

这种情况下，应该按照业务，将业务模块分成几大块，同时按照业务模块对人员进行分组。

模块化建议遵循以下原则：

1. 模块之间松耦合。 如果模块之间耦合度很高，应该考虑是不是应该将两个模块合并在一起。

2. 模块之间的约定/接口应该保持稳定。 模块化后，如果由于人员更替，导致模块之间的约定被破坏，或者接口被修改，没有及时同步，可能会造成模块之间的调用出现BUG。所以，这部分约定/接口应该保持稳定。万一要修改，确保通知到其他人，做相应调整。

3. 模块定义清晰。不要为了模块化而强行进行模块化。

怎样进行模块化？

参考上面的图片。我的建议是这样的，分层进行。

底层

包含，基础库和底层库。

*** 基础库 ***

1. Http，封装了常用的网络操作，例如： okhttp

2. Image，封装了图片相关的网络操作。（其中，如何防止内存溢出OOM问题尤其重要。） 例如： Fresco

3. SQLITE,封装了数据库相关操作，也就是我们常说的ORM。例如： greenDAO

4. 其他就不一一列举了。

*** 底层库 ***底层库，主要是使用C/C++开发的跨平台的引擎或者库，以so的形式存在。例如：游戏引擎cocos2d

中间层

每个公司根据业务不同，分成不同的业务模块。在底层的基础上，实现相应的业务功能。

上层

将所有业务模块聚合在一起，加上配置，形成主应用。一个模块化做的好的应用，主应用应该很简单，并且非常的稳定。

插件化

为什么需要插件化？

1. 方法数限制的需要 大家都知道，一个dex的最大的方法数是固定的，65536.如果方法数超过这个数目，你根本无法正常的打包了。你可以采用MultiDex方案，但是看起来插件化的方案更靠谱一点。

2. 安装包大小控制的需要 对于大部分应用来说，应用安装包越小，用户越容易安装。安装包越大，用户下载，安装，升级时，需要等待的时间越长，放弃应用的概率也就越高。通过插件化，可以将较小众的功能/模块进行插件化，用户需要时，点击下载，安装插件。

3. 灵活性的需要 插件化之前，我们发布patch包总是要针对整个应用。而现在，我们只需要发布某个插件的更新即可。

怎么进行插件化？

并没有一个官方的插件化方案。各个大的互联网公司内部通常会搞一个插件化方案。庆幸的时，有一部分插件化方案被开源出来，供大家参考，使用。具体怎么进行插件化，超出了本人的讨论范围。如果大家有兴趣的话，可以到这里了解。 awesome-android

哪些模块需要插件化？

对于核心底层模块，不建议进行插件化。即使要进行插件化，也要在最初的安装时，给全部安装完毕。

对于核心业务模块，可以进行插件化。要在最初的安装时，给全部安装完毕。

对于非核心业务模块，建议进行插件化。用户从网络下载，按需安装。

PS：facebook推出react native之后，移动应用又刮起了一阵Web风。苦于对Android平台和Windows开发环境的支持不足，暂时没法紧跟时代步伐了。