Android组件化和插件化开发简单介绍(1)

随着APP版本不断的迭代，新功能的不断增加，业务也会变的越来越复杂，APP业务模块的数量有可能还会继续增加，而且每个模块的代码也变的越来越多，这样发展下去单一工程下的APP架构势必会影响开发效率，增加项目的维护成本，每个工程师都要熟悉如此之多的代码，将很难进行多人协作开发，而且Android项目在编译代码的时候电脑会非常卡，又因为单一工程下代码耦合严重，每修改一处代码后都要重新编译打包测试，导致非常耗时，最重要的是这样的代码想要做单元测试根本无从下手，所以必须要有更灵活的架构代替过去单一的工程架构。

组件化

---

概述

android工程的组件一般分为两种，lib组件和application组件

application组件是指该组件本身就可以运行并打包成apk

lib组件是指该组件属于app的一部分，可以供其它组件使用但是本身不能打包成apk

为什么要有组件化？

加入一个app工程只有一个组件，随着app业务的壮大模块越来越多，代码量超10万是很正常的，这个时候我们会遇到以下问题

稍微改动一个模块的一点代码都要编译整个工程，耗时耗力

公共资源、业务、模块混在一起耦合度太高

不方便测试

组件化正确的姿势

既然选择使用组件化，那么如何正确的使用它呢？这里给出一种解决方案，如果你有更好的方案，欢迎交流。

我们创建了一个app工程project，默认里面有一个app组件，这个app组件是可以直接运行的。

怎么划分组件呢？

1.新建一个lib组件，new Module—>Andorid Library，取名BaseUtilLib，我们将所有的公共的工具类、网络分装等类放在其中

2.新建

资料获取→专栏
一个lib组件，BaseReslLib，我们将所有的公共资源、drawable、String等类放在其中

3.将app按照自己
的规则划分成多个模块，比如按业务按地区等都可以

4.逐一开发某个模块，比如Test模块，新建一个TestApp组件，TestApp组件引用[1][2]步骤的BaseUtilLib和BaseReslLib，在TestApp组件里添加并引用TestLib组件。在TestLib的activity中写代码写业务逻辑，TestApp只负责跳转和测试

5.将工程中的所有类似TestLib组件（不是TestApp组件）引入到工程的app中

看着有点乱，整理出一张图

这样的好处有

每个模块可以独立开发编译运行

开发单个模块时可以共享资源和工具类

可以针对单个模块测试

demo地址：https://github.com/halibobo/ModuleBuild

插件化

---

为什么有插件化？

有了组件化，为什么还要用插件化呢？插件化开发总的来说有以下几点好处（不同插件框架不一样）：

宿主和插件分开编译

并发开发

动态更新插件

按需下载模块

方法数或变量数爆棚

处境

开放出来的插件化开发框架比较多，他们各自都有自己的优势和和不足，实现的原理也有差别下面列

开源的插件化框架

https://github.com/Qihoo360/DroidPlugin

https://github.com/CtripMobile/DynamicAPK

https://github.com/mmin18/AndroidDynamicLoader

https://github.com/singwhatiwanna/dynamic-load-apk

https://github.com/houkx/android-pluginmgr

https://github.com/bunnyblue/ACDD
https://github.com/wequick/Small
……
目前开源的这几个框架有宿主和插件分离的也有融合在一起的，每个框架的详细介绍和demo在github里都可以查看到。插件化demo运行起来比较简单

/Small](https://github.com/wequick/Small)
……
目前开源的这几个框架有宿主和插件分离的也有融合在一起的，每个框架的详细介绍和demo在github里都可以查看到。插件化demo运行起来比较简单