含义：可以简单理解为将一个app分为多个小的app，其中有一个为宿主app。
解决的主要问题：代码加载、资源加载。
插件的方式：apk安装，apk不安装，dex包
插件化的优点：
1) 模块解耦，应用程序扩展性强
2) 解除单个dex函数不能超过 65535的限制
3) 动态升级，下载更新节省流量
4) 高效开发(编译速度更快)
插件化的缺点：
1) 增加了主应用程序的逻辑难度
2) 技术有难度，目前一些成熟的框架都是闭源的
插件化开发—动态加载技术加载已安装和未安装的apk
动态加载技术就是使用类加载器加载相应的apk、dex、jar(必须含有dex文件)，再通过反射获得该apk、dex、jar内部的资源（class、图片、color等等）进而供宿主app使用。
代码加载：
类的加载可以使用Java的ClassLoader机制，还需要组件生命周期管理。
资源加载：
用AssetManager的隐藏方法addAssetPath。
插件化必备基础：
ClassLoader类加载器
要想实现加载外部dex文件（即插件）来实现热部署，那么必然要把其中的class文件加载到内存中。
其中涉及到两种ClassLoader:DexClassLoader和PathClassLoader。而DexClassLoader可以加载外部的jar,dex等文件，正是我们需要的。
Java反射
因为插件apk与宿主apk不在一个apk内，那么一些类的访问必然要通过反射进行获取。所以了解反射对插件化的学习是必须的。
插件资源访问
res里的每一个资源都会在R.java里生成一个对应的Integer类型的id，APP启动时会先把R.java注册到当前的上下文环境，我们在代码里以R文件的方式使用资源时正是通过使用这些id访问res资源，然而插件的R.java并没有注册到当前的上下文环境，所以插件的res资源也就无法通过id使用了。
查看源码，通过“addAssetPath”方法重新生成一个新的Resource对象来保存插件中的资源，避免冲突。
代理模式
插件化实现的过程主要靠欺上瞒下，坑蒙拐骗来实现。想想虽然加载进来了Activity等组件，但也仅仅是最为一个对象而存在，并没有在AndroidManifest中注册，没有生命周期的回调，并不能实现我们想要的效果。因此无论是dynamic_load_apk通过代理activity来操控插件activity的方式，还是DroidPlugin通过hook activity启动过程来启动插件activity的方式，都是对代理模式的应用。