Ⅰ 【android】Android中的类加载
前文： 【java】ClassLoader与双亲委派机制
Android中的类加载器有三种， DexClassLoader 、 PathClassLoader 、 BootClassLoader 。
其中 BootClassLoader 是系统启动时预加载常用类的，一般使用不到。 DexClassLoader 、 PathClassLoader 都是继承自 BaseDexClassLoader 。
但 DexClassLoader 和 PathClassLoader 并没有重写 BaseDexClassLoader 中的任何方法，所以源码只需要看 BaseDexClassLoader 即可。
由于Android SDK并没有包含 BaseDexClassLoader ，所以需要到源码查询网站查询源码，如下：
复制这个java文件到对应源码文件夹下就可以在Android Studio中查看了。
通过调试可以看到，Android中普通类的加载器其实是 PathClassLoader 。追踪 PathClassLoader.findClass 方法，即可获取Android的类加载过程：
PathClassLoader.findClass -- 继承自 --> BaseDexClassLoader.findClass()
-> BaseDexClassLoader.pathList.findClass()
-> DexPathList.dexElements.foreach { element.findClass() }
-> Element.findClass()
-> Element.dexFile.loadClassBinaryName()
-> DexFile.defineClass()
即类加载过程通过 BaseDexClassLoader.findClass 、 DexPathList.findClass 、 Element.findClass 、 DexFile.loadClassBinaryName ，最终会落到 DexFile.defineClass 方法中，然后就交给native层了。
其中需要注意的是，在 BaseDexClassLoader.findClass 的开头有这么一段：
这段是在Android 10新加入的，据称是为了实现 shared library 功能的，在之前的版本中没首枯有这一段。
在上一节中知道了，类加载的流程如下：
BaseDexClassLoader.findClass() ->
BaseDexClassLoader.pathList.findClass() ->
DexPathList.dexElements.foreach { element.findClass() } ->
Element.findClass() -> ...
看 DexPathList.findClass 方法：
可以发现， DexPathList 加载类的方法是遍历 dexElements 数组依次加载，知道获取到值为止。所以可迅丛以通过修改这个数组，把新的dex文件放在数组的前面，使其加载修改后的类者昌洞，从而实现热修复。
根据以上原理，写下这个工具类，有效性待验证：
Ⅱ Android启动优化概述
Android启动应用, 按 官方说法 分为冷启动, 温启动和热启动.
具体的定义可以看官方文档, 简单地说
一般我们只需要关注冷启动即可.
要想启动快, 硬件性能必然有影响, 在硬件一定的前提下, 我们要尽量 降低启动应用时CPU的负载 , 让CPU有更多的算力投入到启动流程中:
在做好一些基本原则后, 接着看具体的流程优化点
在应用进程创建后, 首先必然是加载类, 此时一些静态变量就会初始化了, 因此我们应该
类加载完毕后就是创建 Application 实例了, 因此我们应该
之后会先创建 ContentProvider 和执行 ContentProvider.onCreate() , 因此我们应该
跟接着就会执行 Application.onCreate() 等方法, 因此我们应该
接着就进入 Activity 环节.
同样第一步会是创建实例, 因此我们应该
在 Activity 进程生命周期后, 第一步就是渲染(inflate)布局, 我们应该
在应用启动的瞬间, 系统服纳亏务会先展示一个空白窗口哪茄歼, 等待应用第一帧绘制完毕后, 再从该窗口切换到应用, 如果启动耗时较长, 就会明显看到白屏, 对于这一点, 常见的操作有
可以使用IdleHandler, 在主线程空闲时再执行某些不重要的操作
实际上异步初始化只是不阻塞主线程, 但是子线程一样会占用CPU资源, 让主线程的执行时间变少, 所以不应该盲目地将所有工作放到子线程.
优化做到最后, 就是在系统流程上做文章了
原理是将启动时加载的类放到主dex，提升了这些类的内聚，让更多的类满足pre-verify的条件，在安装时就做了校验和优化，以减少首次加载的耗时，从而优化冷启动耗时。
Redex 初探与 Interdex：Andorid 冷启动优化
应用启动过程中会从apk压缩包中读取文件, 该优化的原理是利用Linux中的Pagecache机制, 让启动过程会用到的文件尽可能进入缓存中, 减少磁盘IO次数
支付宝 App 构建优化解析：通过安装包重排布优化 Android 端启动性能
在Dalvik VM(Android5.0以前)加载类的时候会有一个类校验过程, 它需要校验方李冲法的每一个指令, 是一个比较耗时的过程, 可以通过Hook去掉类加载过程中的类验证过程. 不过对于ART(Android5.0之后)来说, 这个过程在安装时已经做了, 所以用处不大.
不进入冷启动, 就不用优化了~
这个Android Studio自带的工具, 可以看到启动过程中详细的方法执行流程, 但是采集数据本身会影响方法执行, 所以不能准确判断每个方法的耗时, 但是仍可以判断哪个方法相对来说耗时.
这个工具的好处是可以自定义事件, 可以指定需要采集的数据集, 可以看到线程间的状态等.
启动优化的一个关键点在于定义启动结束的点, 以及如何测量启动时间.
在Android4.4以上, 系统进程会提供一个类似 ActivityManager: Displayed ***: +3s534ms 的日志, 表示从启动进程到首次绘制完毕所用的时间.
应用可以在任何时候调用该方法, 触发系统打印类似 system_process I/ActivityManager: Fully drawn {package}/.MainActivity: +1s54ms 的日志
应用可以通过 ViewTreeObserver 来监听绘制前回调来判断第一帧的绘制时机, 或者直接在控件树的末尾加一个简单的View, 它 onDraw 调用时即表示页面(差不多)绘制完毕.
应用启动过程可以参考 Android Vitals Series' Articles 系列文章
Ⅲ Android开发 页面加载慢的问题
小图片加载理论上不会影响加载速度的，你们的项目是否在Ui线程进行了很多其他的操作导致了页面加载慢的结果。
Ⅳ Android 性能优化之启动加速
当点击app的启动图标时，安卓系统会从Zygote进程中fork创建出一个新的进程分配给该应用，之后会依次创建和初始化Application类、创建MainActivity类、加载主题样式Theme中的
windowBackground等属性设置给MainActivity以及配置Activity层级上的一些属性、再inflate布局、当onCreate/onStart/onResume方法都走完了后最后才进行contentView的measure/layout/draw显示在界面上，所以直到这里，
应用的第一次启动才算完成，这时候我们看到的界面也就是所说的第一帧。所以，总结一下，应用的启动流程如下：
Application的构造器方法——>attachBaseContext()——>onCreate()——>Activity的构造方法——>onCreate()——>配置主题中背景等属性——>onStart()——>onResume()——>测量布局绘制显示在界面上。
1、冷启动：当启动应用时，后台没有该应用的进程，这腔滑晌时系统会重新创建一个新的进程分配给该应用，这个启动方式就是冷启动。
2、热启动：当启动应用时，后台已有该应用伍锋的进程（例：按back键、在已有进程的情况下，这种启动会从已有的进程中来启动应用，这个方式叫热启动
1、冷启动：冷启动因为系统会重新创建一个新的进程分配给它，所以会先创建和初始化Application类，再创建和初始化MainActivity类（包括一系列的测量、布局、绘制），最后显示在界面上。
2、热启动：热启动因为会从已有的进程中来启动，所以热启动就不会走Application这步了，而是直接走MainActivity（包括一系列的测量、布局、绘制），所以热启动的过程只需要创建和初始化一个MainActivity就行了，而不必创建和初始化Application
黑白屏产生原因：当我们在启让清动一个应用时，系统会去检查是否已经存在这样一个进程，如果不存在，系统的服务会先检查startActivity 中的intent 的信息，然后在去创建进程，最后启动Acitivy，即冷启动。
而启动出现白黑屏的问题，就是在这段时间内产生的。系统在绘制页面加载布局之前，首先会初始化窗口（Window），而在进行这一步操作时，系统会根据我们设
置的Theme 来指定它的Theme 主题颜色，我们在Style 中的设置就决定了显示的是白屏还是黑屏。
1.Application 优化(懒加载,延时加载)
2.UI效果，背景图
3.fragment的懒加载
4.延时加载
Ⅳ 热更新是什么意思
问题一：热更新是什么意思？ 最简单的解释就是不关软件直接更新，更新期间软件直接用，现在大部分软件是山腊孝冷更新，要退出才能更新
问题二：ios热更新是什么意思 ios为什么要移除热更新 iso10的热度还没有过去,iOS10.2 Beta3就已经推出来了.那么大家肯定想要知道ios10.2更新了什么？ios10.2怎么样？下面我给大家带来的是iOS10.2 Beta3详细介绍,有兴趣的朋友快来看看吧！iOS10.2 Beta3简介iOS10.2开发者预览版Beta3固件更新,这是iOS10.2第三个开发者预览版别,此外,iOS10.2公测版Beta3也同步推送,依照常规,两个版别更新内容一致,本次更新固件编号为14C5077b.iOS10.2 Beta3功能在 iOS 10.2 beta 3 中,苹果现已删除了视频 App （由于 TV App 的呈现）.而 iOS 10.1 中呈现视频运用的告诉插件也被移除,取而代之的是 TV 运用的告诉插件.而在这一版中,苹果移除了 SOS 紧迫呼叫功用本来能够经过接连多次按下电源键呼叫紧迫效劳功用.而在苹果的发布注意事项中说到, SOS 功用现在仅在印度可用.iOS10.2 Beta3更新内容SOS紧迫救助功能移除,该功能仅在印度区域可用.视频运用移除,视频运用告诉插件移除.电视运用（国行称号）中用户能够挑选是不是运用数据播映视频,用户在采购视频资本时可挑选HD或许SD画质,现在国行版无法运用,需求切换到美区才干进行体会.iMessage新增爱心全屏特效.以上就是我给大家带来的是iOS10.2 Beta3详细介绍,没看我的文章之前还有疑问的网友们,现在看了我的文章还会不懂吗？我认为这篇文章是对大家有所帮助的,大家有任何疑问可以在下方留言哦！
问题三：苹果手机的热更新是什么意思 请解答的详细点 就是不经过APP商店，直接在应用内更新，如一些游戏，经常会更新数据包。
问题四：热更新真的那么重要吗 背景 相信使用 Node.js 过 Web 应用的同学一定苦恼过新修改的代码必须要重启 Node.js 进程后才能更新的问题。习惯使用 PHP 的同学更会非常的不适用，大呼果然还是我大PHP才是世界上最好的编程语言。手动重启进程不仅仅是非常恼人的重复劳动，当应用规模稍大以后，启动时间也逐渐开始不容忽视。 当然作为程序猿，无论使用哪种语言，都不会让这样的事情折磨自己。解决这类问题最直接和普适的手段就是监听文件修改并重启进程。这个方法也已经有很多成熟的解决方案提供了，比如已经被弃坑的 node-supervisor，以及现在比较火的 PM2 ，或者比较轻量级的 node-dev 等等均是这样的思路。 本文则提供了另外一种思路，只需要很小的改造，就可以实现真正的0重启热更新代码，解决 Node.js Web 应用时恼人的代码更新问题。 总体思路 说起代码热更新，逗稿当下最有名的当属 Erlang 语言的热更新功能，这门语言的特色在于高并发和分布式编程，主要的应用场景则是类似证券交易、游戏服务端等领域。这些场景都或多或少要求服务拥有在运行中运维的手段，而代码热更新就是其中非常重要的一环，因此我们可以先简单的了解一下 Erlang 的做法。 由于我也没有使用过 Erlang ，以下内容均为道听途说，如果希望深入和准确的了解 Erlang 的代码热更新实现，最好还是查阅官方文档。 Erlang 的代码加载由一个名为code_server的模块管理，除了启动时的一些必要代码外，大部分的代码均是由code_server加载。 当code_server发现模块代码被更新后，会重新加载模块，此后的新请求会使用新模块执行，而原有还在执行的请求则继续使用老模块执行。 老模块会在新模块加载后，被打上old标签，新模块则是current标签。当下一次热更新的时候，Erlang 会扫描还在执行老模块的进行并杀掉，再继续按照这个逻辑更新模块。 Erlang 中并非所有代码均允许热更新，如 kernel, stdlib, piler 等基础模块默认是不允许更新的 我们可以发现 Node.js 中也有与code_server类似的局扰模块，即 reuire 体系，因此 Erlang 的做法应该也可以在 Node.js 上做一些尝试。通过了解 Erlang 的做法，我们可以大概的总结出在 Node.js 中解决代码热更新的关键问题点 如何更新模块代码 如何使用新模块处理请求 如何释放老模块的资源 那么接下来我们就逐个的解析这些问题点。 如何更新模块代码 要解决模块代码更新的问题，我们就需要去阅读 Node.js 的模块管理器实现，直接上链接 mole.js。通过简单的阅读，我们可以发现核心的代码就在于 Mole._load ，稍微精简一下代码贴出来。 Check the cache for the reuested file. 1. If a mole already exists in the cache: return its exports object. 2. If the mole is native: call `NativeMole.reuire()` with the filename and return the result. 3. Otherwise, creat......>>
问题五：热更新 的是什么 热更新的时候不需要关闭服务器，直接重新部署项目就行。冷的自然就是关闭服务器后再操作
问题六：android热更新是什么意思 我们知道Java在运行时加载对应的类是通过ClassLoader来实现的，ClassLoader本身是一个抽象来，Android中使用PathClassLoader类作为Android的默认的类加载器，
PathClassLoader其实实现的就是简单的从文件系统中加载类文件。PathClassLoade本身继承自BaseDexClassLoader，BaseDexClassLoader重写了findClass方法，
该方法是ClassLoader的核心
问题七：热更新有多重要 应该是有点上火积食了，不知道宝宝多大了，可以给他煮一些白萝卜水喝一下，衣服别给他穿太多了，食物也是，尽量别吃会上火的食物
问题八：热更新什么意思 就是更新的比较热
问题九：如何实现iOS热更新 Unity没有实现iOS平台代码热更新是因为：
1 所谓热更新就是指代码可以不通过重新打包提交App Store的方式来更新客户端的执行代码。
2由于以下几个原因客户端更新希望更加轻量和快速： App Store的审核周期比较难控制； 手机网络游戏更新频繁.。
问题十：热更新真的那么重要吗 日系的不安全，韩系的还不如日系的，当然你要是能到日、韩原产而非中国产的例外，人家对中国市场是特别对待的。
ESP对于安全来说是很必要的，不怕一万只怕万一，你说呢？2010大众的GOLF为标配、大众斯柯达明锐手自一体的都是标配，手动最低端十二万多的可以选配。
Ⅵ android 怎么动态加载jar
核心类 1.1 DexClassLoader类 可以加载jar/apk/dex，可以从SD卡中加载为安装的apk。 1.2 PathClassLoader类 只能加载已经安装到Android系统中的apk文件。 一、正文 1.1 类似于eclipse的插件化实现， 首先定义好接口， 用户实现接口功能后即可通过动态加载的方式载入jar文件， 以实现具体功能。 注意 ， 这里的jar包需要经过android dx工具的处理 , 否则不能使用。
Ⅶ Android-类加载
双亲委托机制
类在进行类加载的时候，把加载任务托管给父类加载器，如能加载成功，则返回，否则依次向子类加载器递归尝试类加载。
意义：
①避免类的重复加载，父类加载已加载该类时,子ClassLoader就没有必要加载一次了。
②安全性，防止核心API被随意篡改。
ClassLoader
ClassLoader本身是一个抽象方法。它的主要实现类有BootClassLoader、PathClassLoader、DexClassLoader.
BootClassLoader：用于加载Android Framwork层（SDK）的class文件
PathClassLoader：用于Android应用程序加载器,可以加载指定的dex和jar、zip、apk中的classes.dex（系统使用）
DexClassLoader：用于加载指定的dex和jar、zip、apk中的classes.dex。(供开发者使用)
拓展：
在API26之前。
optimizedDirectory 参数就是dexopt的产出目录(odex)。那 PathClassLoader 创建时，这个目录为null，就
意味着不进行dexopt？并不是， optimizedDirectory 为null时的默认路径为：/data/dalvik-cache。
在API26之后DexClassLoader也取消了optimizedDirectory
热修复相关
LoadClass：
findClass：PathClassLoader和DexClassLoader的父类BaseDexClassLoader中实现findClass。
BaseDexClassLoader中
PathClassLoader加载过后，pathlist 中存在一个Element数组，Element类中存在一个dexFile成员表示dex文件，即：APK中有X个dex，则Element数组就扮丛有X个元素。
总结:
可能看到这里我们比较乱了，理一下。一个类的加载经历了哪些。我们以PathClassLoader为例。
①加载一个类的时候，首先通过Class缓存寻找是否已经加载过该类。参考抽象类的loadClass方法。
②若在缓存中未找到该类，则交由父加载器加载该类。参考抽象类的loadClass方法。
③调用父加载器PathClassLoader的父类BaseDexClassLoader实现的findClass方法加载该类。
④PathClassLoader在初始化的时候调用枣坦父构造方法实例化DexPathList属性，DexPathList属性初始化时构造方法内通过makePathElements（或makeDexElements 不同API可能不同）加载APK内的dex文件生成Element数组。
⑤BaseDexClassLoader实现的findClass方法中顺序循环已存在的Element数组，通过Element中的DexFile加载类。。
⑥未找到，抛出类未找厅岩樱到异常。
热修复（multide 形式（thinker、qfix））
热修复的原理。我们只需在应用启动的时候，一般是在application方法中（因为class加载首先从缓存中加载），在应用启动后，经过PathClassLoader加载过后所有的类都在 pathList的Element 数组，把生成的Elment数组插入到PathList的Element数组的最前方。在加载类的时候就只会加载到我们需要更新的类了，因为是顺序寻找，找到就返回。(先从我们补丁的dex文件生成的element寻找，找不到再从APK的dex生成的element种寻找)。
热修复基本思路总结:
①获取到当前引用的PathClassLoader
②反射获取其中DexPathList属性:DexPathList pathList.
③获取到补丁包path.dex文件的Element[]数组 pElements。参考PathClassLoader怎么把dex文件转换为Element数组的。于是我们反射执行DexPathList 中的makePathElements方法（视API而定）传入dex路径得到补丁包的element数组。
④获取pathList的dexElements数组。
⑤把补丁包的pElements数组合并到pathList的dexElements数组的前方，即newElements=pElements+dexElements
⑥反射赋值把newElements替换掉pathList的dexElements
热修复没这么简单，还需考虑混淆，API版本不同导致的使用makePathElements方法或makeDexElements方法等因素。
热修复（InstantRun 形式(Robust)）待了解。
Ⅷ android 热部署是什么意思
在 Java 开发领域，热部署一直是一个难以解决的问题，目前的 Java 虚拟机只能实现方法体的修改热部署，对于整个类的结构修改，仍然需要重启虚拟机，对类重新加载才能完成更新操作。对于某些大型的应用来说，每次的重启都需要花费大量的时间成本。虽然 osgi 架构的出现，让模块重启成为可能，但是如果模块之间有调用关系的话，这样的操作依然会让应用出现短暂的功能性休克。本文将探索如何在不破坏 Java 虚拟机现有行为的前提下，实现某个单一类的热部署，让系统无需重启就完成某个类的更新。
类加载的探索
首先谈一下何为热部署（hotswap），热部署是在不重启 Java 虚拟机的前提下，能自动侦测到 class 文件的变化，更新运行时 class 的行为。Java 类是通过 Java 虚拟机加载的，某个类的 class 文件在被 classloader 加载后，会生成对应的 Class 对象，之局差巧后就可以创建该类的实例。默认的虚拟机行为只会在启动时加载类，如果后期有一个类需要更新的话，单纯替换编译的 class 文件，Java 虚拟机是不会更新正在运行的 class。如果要实现热部署，最根本的方式是修改虚拟机的源代码，改变 classloader 的加载行为，使虚拟机能监听 class 文件的更新，重新加载 class 文件，这样的行为破坏性很大，为后续的 JVM 升级埋下了一个大坑。
另一种友好的方法是创建自己的 classloader 来加载需要监听的 class，这样就能控制类加载的时机，从而实现热部署。本文将具体探索如何实现这个方案。首先需要了解一下 Java 虚拟机现有的加载机制。目前的加载机制，称为双亲委派，系统在使用一个 classloader 来加载类时，会先询问当前 classloader 的父类是否有能力加载，如果父类无法实现加载操作，才会将任务下放到该 classloader 来加载。这种自上而下的加载方式的好处是，让每个 classloader 执行自己的加载任务，不会重复加载类。但是这种方式却使加载顺序非常难改变，让自定义 classloader 抢先加载需要监听改变的类成为了一个难题。
不过我们可以换一个思路，虽然无法抢先加载该类，但是仍然可以用自定义 classloader 创建一个功能相同的类，让每次实例化的对象都指向这个新的类。当这个类的 class 文件发生改变的时候，再次创建一个更新的类，之后如果系统再次发出实例化请求，创建的对象讲指向这个全新的类。
下面来简单列举一下需要做的工作。
创建自定义的 classloader，加载需要监听改变的类，在 class 文件发生改变的时候，重新加载该类。
改变创建对象的行为，使他们在创建时使用自定义 classloader 加载的 class。
自定义加载器的实现
自定义加载器仍然庆态需要执行类加载的功能。这里却存在一个问题，同一个类加载器无法同时加载两个相同名称的类，由于不论类的结构如何发生变化，生成的类名不会变，而 classloader 只能在虚拟机停止前销毁已经加载的类，这样 classloader 就无法加载更新后的类了。这里有一个小技巧，让每次加载的类都保存成一个带有版本信息的 class，比如加载 Test.class 时，保存在内存中的类是 Test_v1.class，当类发生改变时，重新加载的类名是 Test_v2.class。但是真正执行加载 class 文件创建 class 的 defineClass 方法是一个 native 的方法，修改起来又变得很困难。所以面前还剩一条路，那就是直接修改编译生成的 class 文件。
利用 ASM 修改 class 文件
可以修改字节码的框架有很多，比如 ASM，CGLIB。本文使用的是 ASM。先来介绍一下 class 文件的结构，class 文件包含了以下几类信息，一个是类的基本信息，包含了访问权限信息，类名信息，父类信息，接口信息。第二个是类的变量信息。第三个是方法的信息。桐键ASM 会先加载一个 class 文件，然后严格顺序读取类的各项信息，用户可以按照自己的意愿定义增强组件修改这些信息，最后输出成一个新的 class。
首先看一下如何利用 ASM 修改类信息。
清单 1. 利用 ASM 修改字节码
ClassWriter cw = new ClassWriter(ClassWriter.COMPUTE_MAXS);
ClassReader cr = null;
String enhancedClassName = classSource.getEnhancedName();
try {
cr = new ClassReader(new FileInputStream(
classSource.getFile()));
} catch (IOException e) {
e.printStackTrace();
return null;
}
ClassVisitor cv = new EnhancedModifier(cw,
className.replace(".", "/"),
enhancedClassName.replace(".", "/"));
cr.accept(cv, 0);
Ⅸ Android Studio Flutter Hot Reload热加载无效
如题，在Flutter开发中，正常情况下，修改后按保存（ctrl+s），就能自动州虚耐将更新内容热加载到设备中，但是我早上突然就遇到保存后没有热加载的情况。
试了试册春，有的页面是没问题，可以热更新的，有的页面不行，那应该就是某些页面的问题了。在热更新生效的页面，每次保存后查看Run里面输出的日志，誉悉发现最后一行是类似：
而热更新无效的页面，保存后的日志是：
也就是AS没有找到改变的东西，所以没更新。
联想到早些时候把几个dart文件的位置拖动了下，是不是那个操作引起的问题，打开来看了看，发现了问题所在。那些引用被拖动文件的地方，引用语句由
变成了
（***是我脱敏替代了）
导致AS无法加载最新修改的内容。
把引用方式由file的方式改回package的方式就行。
以上。
Ⅹ Android类加载机制
Android手写热修复（一）--ClassLoader
我们平时编写的 .java 文件不是可执行文件，需要先编译成 .class 文件才可以被虚拟机执行。所谓类加载是指通过 类加载器 把class文件加载到虚拟机的内存空间，具体来说是方法区。类通常是按需加载，即第一次使用该类时才加载。
首先，Java与Android都是把类加载到虚拟机内存中，然后由虚拟机转换成设备识别的机器码。但是由于二者使用的虚拟机不同，所以在类加载方面也是有所区别的。Java的虚拟机是JVM，Android的虚拟机是dalvik／art(5.0以后虚拟机是art，是对dalvik的一种升级)。 Java虚拟机运行的是class文件，而Android 虚拟机运行的是dex文件。 dex其实是class文件的集合，是对class文件优化的产物，是为了避免出现重复的class。
从上面的讲解中，我们已经知道我们平时写的类是被 类加载器 加载尽虚拟机内存才能运行。下面就通过Framework源码来为大家讲解Android中最主要的5个类加载器。
在Activity做个简单验证：
结果：
可以看出系统类由BootClassLoader加载，apk中的类由PathClassLoader加载，PathClassLoader的父类加载器是BootClassLoader。如果暂时不能理解父类加载器是什么，没关系，后面讲双亲委托机制的时候会理解的。
下面的源码解析基于 Android SDK API28 ，这几个类加载器（除了ClassLoader）没办法直接在AS上查看源码，AS搜索到的是反编译的class的内容，是不可信的，为大家推荐一个在线工具查看， 在线查看Android Framework源码 。
用来加载本地文件系统上的文件或目录，通常是用来加载apk中我们自己写的类，而像 Activity.class 这种系统的类不是由它加载。注意：这里，并不像很多网上文章说的那样只能加载apk，本地的其他目录的文件也是可以的，这一点我会在后面验证说明。
也是被用来加载 jar 、apk、dex，通常用来加载未安装到应用中的文件。注意，它需要一个应用私有的可写的目录来存放优化后的dex文件。千万不要选择外部存储路径，因为这样可能会导致你的应用遭到注入攻击。
关于dex文件优化，可能很多人还是不理解，水平有限，我简单解释一下，
构造器参数解释：
关于optimizedDirectory：
1、这是dex优化后的路径，它必须是一个应用私有的可写的目录否则会存在注入攻击的风险；
2、这个参数在API 26（8.0）之前是有值的，之后的话，这个参数已经没有影响了，因为在调用父构造器的时候这个参数始终为null，也就是说Android 8.0 以后DexClassLoader和PathClassLoader基本一样的来；
3、在加载app的时候，apk内部的dex已经执行过优化了，优化之后放在系统目录/data/dalvik-cache下。
这个构造器的关键是初始化了一个DexPathList对象，这个是后面加载class的关键类。
这个构造方法等关键是通过 makeDexElements() 方法来获取Element数组，这个Element数组非常关键，后面查找class就会用到它，也是热修复的关键点之一。
splitDexPath(dexPath) 方法是把dexPath目录下的所有文件转换成一个File集合，如果是多个文件的话，会用 : 作为分隔符。
makeDexElements()
小结一下，这个方法就是把指定目录下的文件apk／jar／zip／dex按不同的方式封装成Element对象，然后按顺序添加到Element[]数组中。
DexPathList#loadDexFile()
可以看到 DexFile 最终是调用了openDexFile、native方法openDexFileNative去打开Dex文件的，如果outputName为空，则自动生成一个缓存目录，具体来说是 /data/dalvik-cache/[email protected] 。openDexFileNative这个native方法就不具体分析了，主要是对dex文件进行了优化操作，将优化后得odex文件通过mmap映射到内存中。感兴趣的同学可以参考：
《DexClassLoader和PathClassLoader加载Dex流程》
现在在回头看看DexClassLoader与PathClassLoader的区别。DexClassLoader可以指定odex的路径，而PathClassLoader则采用系统默认的缓存路径，在8.0以后没有区别。
ClassLoader是一个抽象类，有3个构造方法，最终调用的还是第一个构造方法，主要功能是保存实现类传入的parent参数，也就是父类加载器。ClassLoader的实现类主要有2个，一个是前面讲过的BaseDexClassLoader，另一个是BootClassLoader。
BootClassLoader是ClassLoader的内部类，而且继承了ClassLoader。
这是加载一个类的入口，流程如下：
1、 先检查这个类是否已经被加载，有的话直接返回Class对象；
2、如果没有加载过，通过父类加载器去加载，可以看出parent是通过递归的方式去加载class的；
3、如果所有的父类加载器都没有加载过，就由当前的类加载器去加载。
通常我们自己写的类是通过当前类加载器调用 findClass 方法去加载的，但是在 ClassLoader 中这是个空方法，具体的实现在它的子类 BaseDexClassLoader 中。
BaseDexClassLoader # findClass
可以看到是通过pathList去查找class的，这个对象其实之前讲过，它是在BaseDexClassLoader 的构造方法中初始化的，它实际上是一个 DexPathList 对象。
DexPathList # findClass()
对Element数组遍历，再通过Element对象的 findClass 方法去查找class，有的话就直接返回这个class，找不到则返回null。 这里可以看出获取Class是通过DexFile来实现的，而各种类加载器操作的是Dex。Android虚拟机加载的dex文件，而不是class文件。
1、加载一个类是通过双亲委托机制来实现的。
2、如果是第一次加载class，那是通过 BaseDexClassLoader 中的findClass方法实现的；接着进入 DexPathList 中的findClass方法，内部通过遍历Element数组，从Element对象中去查找类；Element实际上是对Dex文件的包装，最终还是从dexfile去查找的class。
3、一般app运行主要用到2个类加载器，一个是PathClassLoader：主要用于加载自己写的类；另一个是BootClassLoader：用于加载Framework中的类；
4、热修复和插件化一般是利用DexClassLoader来实现。
5、PathClassLoader和DexClassLoader其实都可以加载apk／jar／dex，区别是 DexClassLoader 可以指定 optimizedDirectory ，也就是 dex2oat 的产物 .odex 存放的位置，而 PathClassLoader 只能使用系统默认位置。但是在8.0 以后二者是没有区别的，只能使用系统默认的位置了。
这张图来源于：
Android虚拟机框架：类加载机制
在类加载流程分析中，我们已经知道，查找class是通过DexPathList来完成的，实际上DexPathList最终还是遍历其Element数组，获取DexFile对象来加载Class文件。 由于数组是有序的，如果2个dex文件中存在相同类名的class，那么类加载器就只会加载数组前面的dex中的class。如果apk中出现了有bug的class，那只要把修复的class打包成dex文件并且放在 DexPathList 中Element数组`的前面，就可以实现bug修复了 。下一篇为大家带来的手写热修复。
Android类加载机制的细枝末节
从JVM到Dalivk再到ART（class,dex,odex,vdex,ELF）
类加载机制系列2——深入理解Android中的类加载器
Android 热修复核心原理，ClassLoader类加载