详细可以查看这篇博客： https://blog.csdn.net/itachi85/article/details/78088701
重点内容
双亲委托模式
类加载器查找Class所采用的是双亲委托模式，所谓双亲委托模式就是首先判断该Class是否已经加载，如果没有则不是自身去查找而是委托给父加载器进行查找，这样依次的进行递归，直到委托到最顶层的Bootstrap ClassLoader，如果Bootstrap ClassLoader找到了该Class，就会直接返回，如果没找到，则继续依次向下查找，如果还没找到则最后会交由自身去查找。
这样讲可能会有些抽象，来看下面的图。
我们知道类加载子系统用来查找和加载Class文件到 Java 虚拟机中，假设我们要加载一个位于D盘的Class文件，这时系统所提供的类加载器不能满足条件，这时就需要我们自定义类加载器继承自java.lang.ClassLoader，并复写它的findClass方法。加载D盘的Class文件步骤如下：
- 自定义类加载器首先从缓存中要查找Class文件是否已经加载，如果已经加载就返回该Class，如果没加载则委托给父加载器也就是App ClassLoader。
- 按照上图中红色虚线的方向递归步骤1。
- 一直委托到Bootstrap ClassLoader，如果Bootstrap ClassLoader在缓存中还没有查找到Class文件，则在自己的规定路径$JAVA_HOME/jre/libr中或者-Xbootclasspath选项指定路径的jar包中进行查找，如果找到则返回该Class，如果没有则交给子加载器Extensions ClassLoader。
- Extensions ClassLoader查找$JAVA_HOME/jre/lib/ext目录下或者-Djava.ext.dirs选项指定目录下的jar包，如果找到就返回，找不到则交给App ClassLoader。
- App ClassLoade查找Classpath目录下或者-Djava.ext.dirs选项所指定的目录下的jar包和Class文件，如果找到就返回，找不到交给我们自定义的类加载器，如果还找不到则抛出异常。
总的来说就是Class文件加载到类加载子系统后，先沿着图中红色虚线的方向自下而上进行委托，再沿着黑色虚线的方向自上而下进行查找，整个过程就是先上后下。
类加载的步骤在JDK8的源码中也得到了体现，来查看抽象类的ClassLoader方法，如下所示。
源码
protected Class More ...loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
synchronized (getClassLoadingLock(name)) {
Class c = findLoadedClass(name);//1
if (c == null) {
long t0 = System.nanoTime();
try {
if (parent != null) {
c = parent.loadClass(name, false);//2
} else {
c = findBootstrapClassOrNull(name);//3
}
} catch (ClassNotFoundException e) {
}
if (c == null) {
// If still not found, then invoke findClass in order
// to find the class.
long t1 = System.nanoTime();
c = findClass(name);//4
// this is the defining class loader; record the stats
sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
sun.misc.PerfCounter.getFindClasses().increment();
}
}
if (resolve) {
resolveClass(c);
}
return c;
}
}
双亲委托模式的好处
采取双亲委托模式主要有两点好处：
- 避免重复加载，如果已经加载过一次Class，就不需要再次加载，而是先从缓存中直接读取。
- 更加安全，如果不使用双亲委托模式，就可以自定义一个String类来替代系统的String类，这显然会造成安全隐患，采用双亲委托模式会使得系统的String类在Java虚拟机启动时就被加载，也就无法自定义String类来替代系统的String类，除非我们修改类加载器搜索类的默认算法。还有一点， 只有两个类名一致并且被同一个类加载器加载的类，Java虚拟机才会认为它们是同一个类，想要骗过Java虚拟机显然不会那么容易。
replugin 框架classloader的简单理解
replugin 简介
replugin-host-gradle
replugin-host-gradle 负责在主程序的编译期中生产各类文件，例如：生成HostBuildConfig类，方便插件框架读取并自定义其属性，如：进程数、各类型占位坑的数量、是否使用AppCompat库、Host版本、pulgins-builtin.json文件名、内置插件文件名等。
自动生成带 RePlugin 插件坑位的 AndroidManifest.xml文件，文件中带有如：
replugin-host-library
对应com.qihoo360.replugin:replugin-host-lib:xxx依赖，是一个Java工程，由主程序负责引入，是RePlugin的核心工程，负责初始化、加载、启动、管理插件等
replugin-plugin-gradle
对应com.qihoo360.replugin:replugin-plugin-gradle:xxx ，是一个Gradle插件，由插件负责引入，主要负责在插件的编译期中：配置插件打包相关信息；动态替换插件工程中的继承基类，如下，修改Activity的继承、Provider的重定向等。
/* LoaderActivity 替换规则 */
def private static loaderActivityRules = [
'android.app.Activity' : 'com.qihoo360.replugin.loader.a.PluginActivity',
'android.app.TabActivity' : 'com.qihoo360.replugin.loader.a.PluginTabActivity',
'android.app.ListActivity' : 'com.qihoo360.replugin.loader.a.PluginListActivity',
'android.app.ActivityGroup' : 'com.qihoo360.replugin.loader.a.PluginActivityGroup',
'android.support.v4.app.FragmentActivity' : 'com.qihoo360.replugin.loader.a.PluginFragmentActivity',
'android.support.v7.app.AppCompatActivity': 'com.qihoo360.replugin.loader.a.PluginAppCompatActivity',
'android.preference.PreferenceActivity' : 'com.qihoo360.replugin.loader.a.PluginPreferenceActivity',
'android.app.ExpandableListActivity' : 'com.qihoo360.replugin.loader.a.PluginExpandableListActivity'
]
replugin-plugin-library
对应com.qihoo360.replugin:replugin-plugin-lib:xxx依赖，是一个Java工程，由插件端负责引入，主要提供通过“Java反射”来调用主程序中RePlugin Host Library的相关接口，并提供“双向通信”的能力，以及各种基类Activity等
其中的RePlugin、RePluginInternal、PluginServiceClient都是反射宿主App ：replugin-host-library 中的 RePlugin 、 RePluginInternal 、PluginServiceClient 类方法。
Replugin的ClassLoader
这里主要介绍，宿主和插件使用的ClassLoader，以及它们的创建和Hook住时机。这是RePlugin唯一的Hook点，而其中插件ClassLoader和宿主ClassLoader是相互关系的，如下图
-
宿主的ClassLoader
RePluginClassLoader，宿主的ClassLoader，继承 PathClassLoader，构造方法使用原ClassLoader，和原ClassLoader的Parent生成。其中ParentLoader是因为双亲代理模型，创建ClassLoader所需，而原Loader用于保留在后期使用，如下图
image
如下两图，RePluginClassLoader 在创建时，浅拷贝原Loader的资源到 RePluginClassLoader 中，用于欺骗系统还处于原Loader，并且从原Loader中反射出常用方法，用于重载方法中使用
image
宿主Loader中，主要是重载了 loadClass，其中从 PMF（RePlugin中公开接口类）中查找class，如果存在即返回插件class，如果不存在就从原Loader中加载。从而实现了对加载类的拦截。
这里的 PMF 在加载class时，其实用的是下面【2、插件的ClassLoader 】：PluginDexClassLoader，这个后面流程会讲到。
-
插件的ClassLoader
PluginDexClassLoader，继承DexClassLoader，构造时持有了宿主的ClassLoader，从宿主ClassLoader中反射获取loadClass方法，当自己的loadClass方法找不到类时，从宿主Loader中加载。
image
其它内容详细查看 ： https://www.jianshu.com/p/18530be5dcdd