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

• 可以针对单个模块测试， 开发调试时不需要对整个项目进行编译。

• 多人合作时可以只关注自己的业务模块，把某一业务当成单一项目来开发。

• 可以灵活的对业务模块进行组装和拆分。

4、组件化开发的主要思路

就是将一个Module拆分成若干个Module，由主App提供统一的入口，每个拆分后的Module都依赖共享的Common依赖库，通过相关配置，各个Module可以独立运行调试，也可以供主App依赖使用。

5、组件化开发的步骤：

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

2. 新建一个lib组件，New → Module → Andorid Library，取名BaseReslLib，我们将所有的公共资源、drawable、String等类放在其中。

3. 将app按照需求划分成多个模块，比如按业务按地区等都可以，然后分别创建Module模块。

4. 逐一开发某个模块，每个组件都可以引用[1][2]步骤的BaseUtilLib、BaseReslLib里的公共类和公共资源，组件可以单独开发、单独测试。

5. 将工程中的开发好的组件模块，引入到工程的app中，然后就可以发布了。

6、举一个更简单的图例：

app：壳工程

module1：组件1

module2：组件2

common：第三库，公用工具、自定义 View、主题等

二、插件化

---

1、为什么需要插件化？

我们在项目的开发过程中，难免会遇到产品需求的变更或者出现bug。在传统的模式中，我们首先需要修改代码，然后重新打包Apk，再交给公司的运营去官网或者应用商店上线，用户在打开应用的时候就会进行更新了。但是这种模式有几个缺点：

• 上线周期长，从修改代码到用户更新需要较长的时间；

• 用户更新代价较大，每次用户更新都需要下载整个Apk包，整个Apk包括了一个应用的所有代码，要消耗用户较多的流量。

• 如果是一些重要的更新，为了确保用户都能更新到，还需要强制更新，即用户打开App后如果不更新则退出应用，这种对用户来说是极其不友好的。

• 还有另外一种情况，某些较大的App功能很多，比如支付宝、微信等，如果将这些功能全部塞到一个Apk中，那将会是一个巨型Apk，用户在安装或者更新Apk时将会经过漫长的等待时间。

基于以上几点，Android的插件化技术应运而生**，**插件化技术可以将整个巨型Apk按照功能模块划分，不同的功能打包成不同的Apk，然后应用的主Apk按需加载对应功能的Apk，用户只需要安装应用的主Apk即可。主Apk相当于一个壳，它会按需加载其他功能模块的Apk。通过这种模式，不仅解决了巨型Apk的问题，而且当某个功能模块需要变化时，也只需要修改对应功能的代码，打包功能Apk并更新即可，这样不仅可以让用户及时更新，而且更新的代价也很小。但是，我们知道，在Android中，没有安装的apk是不能直接运行的，那么要想实现插件化，我们就必须让宿主Apk能够加载功能Apk并运行。

2、插件化的好处：

• 宿主和插件分开编译

• 并发开发，宿主和插件都是apk，开发是互不影响的，只需要宿主给插件一个上下文

• 动态更新插件，不需要安装，下载之后就可以直接打开

• 按需下载模块

• 可以解决方法数或变量数爆棚问题

3、插件化的标准：

是不是每个app都能运行在我们的宿主app里面呢？答案肯定不是。我们必须在宿主app里面设计一套标准，让插件app满足我们这个标准才能够运行。最主要的是插件app因为没有安装，所以是没有上下文的，就需要我们的宿主将上下文传过去。插件化的activity也没有生命周期，所以我们的宿主也要对插件的生命周期进行管理，以及资源、layout等。

4、插件化技术的发展

大概从2012年开始，前前后后出现了很多插件化/组件化的框架，各种框架都有自己的特色。

AndroidDynamicLoader：2012年7月，基于Fragement实现，通过动态加载不同的Fragement来替换界面，首次使用addAssetPath来读取插件中的资源。

Altas技术沙龙分享：2014年初，阿里的一次技术沙龙分享，主要讲淘宝Alta这项技术的概念，并没有涉及详细实现，当时已经应用于淘宝客户端，未开源。

android-pluginmgr：2014年7月，主要通过操作java虚拟机字节码，通过动态生成一个插件类的子类如四大组件（需要在manifest中提前声明），达到插件化的功能（最新的已经改成hook系统的一些对象如Instrumentation、ActivityThread等）

dynamic-load-apk：2014年底，该框架使用代理的方式实现，并没有hook系统的底层对象、方法。比较有代表性，后文中会详细分析。

OpenAltas：2015年4月，后来改名为ACDD。该框架参考了淘宝App的很多经验，主要就是Hook的思想（据说是反编译代码），同时，还首次提出来通过扩展AAPT（android assert packaging tool）来解决插件与宿主的资源id冲突的问题。

Android-Plugin-Framework：2015年5月，采用hook系统底层很多方法，感觉是把能hook的对象基本都hook住了，功能相对完整，但不支持so插件，兼容性不好，目前在实际应用的实践比较少。

DroidPlugin：2015年8月，它也hook了很多Android系统的底层代码，包括本地的PMS、AMS、ActivityThread、Instrumentation、H等对象，能把任意的App都加载到宿主里运行。比较有代表性，后文也会详细分析。

DynamicAPK：2015年10月，参考了之前提到的ACDD的设计方案，并通过扩展aapt解决资源问题。

Small：2015年底，是一个比较轻巧的跨平台插件化框架，比DroidPlugin更加轻量一点，基本原理也是对底层的对象进行hook，并使用gradle脚本来解决资源冲突的问题，可以通过配置url来支持插件跳转。

TwsPluginFramework，2017年初，同样hook系统底层对象方法，并通过appt解决资源冲突的问题。

Atlas：2017年3月，它是一个动态组件化的方案，也hook了很多底层对象方法，支持so，支持增量补丁和热修复，是个单进程的框架。

最后附上：我们之前因为秋招收集的二十套一二线互联网公司Android面试真题 （含BAT、小米、华为、美团、滴滴）和我自己整理Android复习笔记（包含Android基础知识点、Android扩展知识点、Android源码解析、设计模式汇总、Gradle知识点、常见算法题汇总）

面试成功其实是必然的，因为我做足了充分的准备工作，包括刷题啊，看一些Android核心的知识点，看一些面试的博客吸取大家面试的一些经验，下面这份PDF是我翻阅了差不多1个月左右一些Android大博主的博客从他们那里取其精华去其糟泊所整理出来的一些Android的核心知识点， 全部都是精华中的精华，我能面试到现在资深开发人员跟我整理的这本Android核心知识点有密不可分的关系，在这里本着共赢的心态分享给各位朋友。

这份PDF囊括了JVM，Java集合，Java多线程并发，Java基础，生命周期，微服务， 进程,Parcelable 接口，IPC，屏幕适配,线程异步,ART，架构，Jetpack，NDK开发，计算机网络基础，类加载器，Android 开源库源码分析，设计模式汇总，Gradle 知识点汇总…

由于篇幅有限，就不做过多的介绍，大家请自行脑补

囊括了JVM，Java集合，Java多线程并发，Java基础，生命周期，微服务， 进程,Parcelable 接口，IPC，屏幕适配,线程异步,ART，架构，Jetpack，NDK开发，计算机网络基础，类加载器，Android 开源库源码分析，设计模式汇总，Gradle 知识点汇总…

由于篇幅有限，就不做过多的介绍，大家请自行脑补

本文已被CODING开源项目：《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》收录