自定义类加载器的好处和应用场景
一般情况下，使用不同的类加载器去加载不同的功能模块，会提高应用程序的安全性。但是，如果涉及 Java类型转换，则加载器反而容易产生不美好的事情。
开发人员可以通过继承抽象类java.lang.ClassLoader类的方式，实现自己的类加载器，以满足一些特殊的需求。
描述这个类的属性和作用 ： 比如你自定义一个Person类，就是人类，你可以通过属性（比如两只眼睛 两只耳朵 ）和行为（行为简单的理解就是能干什么 比如人能跑 能跳 能吃饭）把人这个类描述清楚。
加密：众所周知，java代码很容易被反编译，如果你需要把自己的代码进行加密，可以先将编译后的代码用某种加密算法加密，然后实现自己的类加载器，负责将这段加密后的代码还原。
比较典型的自定义classloader使用情况就是给类加密。
Classloader、插件化开发(结合Presto)
Java 自定义 ClassLoader 实现隔离运行不同版本jar包的方式 从上面我们得知，如果采取ServiceLoader的SPI方案，应该在 resources/META-INF/services 中存放实现类的全限定名。
hook式呢是将插件apk融入到了我们的宿主apk，那直接在里面就可以直接loadClass了，在不用这个插件的ClassLoader了，这样的话对于插件和宿主就没什么区别了，不像插桩式有一个中间者。
插件调用主工程 在ClassLoader构造时指定主工程的DexClassLoader为父加载器即可直接调用主工程中的类和方法。 主工程调用插件 如果是多DexClassLoader的情况，则需要通过插件的DexClassLoader加载对应的类并反射调用其方法。
插件化是体现在功能拆分方面的，它将某个功能独立提取出来，独立开发，独立测试，再插入到主应用中动态加载。以此来规避主应用规模超限。通过代理或Hook来实现。
PathClassLoader：用于Android应用程序加载器，可以加载指定的dex和jar、zip、apk中的classes.dex（系统使用）DexClassLoader：用于加载指定的dex和jar、zip、apk中的classes.dex。(供开发者使用)拓展：在API26之前。
自定义类加载器的代码实现
用户通过定制自己的类加载器，这样可以重新定义类的加载规则，以便实现一些自定义的处理逻辑。这两种方法本质上差不多，毕竟loadClass()也会调用findClass()，但是从逻辑上讲我们最好不要直接修改loadClass()的内部逻辑。
JVM 是通过 一个称为 ClassLoader 的东西 来加载 class 文件，每当 JVM 启动的时候，就会产生 三个 ClassLoader，它们分别是Bootstrap Loader， ExtClassLoader 和 AppClassLoader。
当程序需要的时候才加载，当你的程序完全在本机编译的话，默认的类加载器一般都工 作的很好。但是Java很容易的从网络上而不只是本地加载类。
用Java类文件的方式命名。调用外部javac命令将该文件编译。用类加载器（ClassLoad）动态加载新的class文件并用Class.forName()注册该类，然后就可以正常使用了。上面的每一步都能在baidu中找到实现方法，自己发挥吧。
jdk类加载器
Application ClassLoader，主要加载Classpath指定的库类，一般情况下这是程序中的默认类加载器，也是ClassLoader.getSystemClassLoader()的返回值。
类加载器从JDK0就出现了，最初是为了满足JavaApplet的需要而开发出来的。JavaApplet需要从远程下载Java类文件到浏览器中并执行。
删除导入的包。无法使用类加载程序jdk.internal.loader可以删除导入的包，当然这只适合这一种bug。类加载指的是将类的class文件读入内存，并为之创建一个java.lang.Class对象。类的加载过程是由类加载器来完成。