如何重新获得机器码

打开视频获取机器码，到综合班机器码提交版块提交机器码！我们会到会计算的！>

Android手写热修复（一）--ClassLoader

我们平时编写的 java 文件不是可执行文件，需要先编译成 class 文件才可以被虚拟机执行。所谓类加载是指通过 类加载器 把class文件加载到虚拟机的内存空间，具体来说是方法区。类通常是按需加载，即第一次使用该类时才加载。

首先，Java与Android都是把类加载到虚拟机内存中，然后由虚拟机转换成设备识别的机器码。但是由于二者使用的虚拟机不同，所以在类加载方面也是有所区别的。Java的虚拟机是JVM，Android的虚拟机是dalvik／art(50以后虚拟机是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中我们自己写的类，而像 Activityclass 这种系统的类不是由它加载。注意：这里，并不像很多网上文章说的那样只能加载apk，本地的其他目录的文件也是可以的，这一点我会在后面验证说明。

也是被用来加载 jar 、apk、dex，通常用来加载未安装到应用中的文件。注意，它需要一个应用私有的可写的目录来存放优化后的dex文件。千万不要选择外部存储路径，因为这样可能会导致你的应用遭到注入攻击。

关于dex文件优化，可能很多人还是不理解，水平有限，我简单解释一下，

构造器参数解释：

关于optimizedDirectory：

1、这是dex优化后的路径，它必须是一个应用私有的可写的目录否则会存在注入攻击的风险；

2、这个参数在API 26（80）之前是有值的，之后的话，这个参数已经没有影响了，因为在调用父构造器的时候这个参数始终为null，也就是说Android 80 以后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/xxx@classesdex 。openDexFileNative这个native方法就不具体分析了，主要是对dex文件进行了优化 *** 作，将优化后得odex文件通过mmap映射到内存中。感兴趣的同学可以参考：

《DexClassLoader和PathClassLoader加载Dex流程》

现在在回头看看DexClassLoader与PathClassLoader的区别。DexClassLoader可以指定odex的路径，而PathClassLoader则采用系统默认的缓存路径，在80以后没有区别。

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 只能使用系统默认位置。但是在80 以后二者是没有区别的，只能使用系统默认的位置了。

这张图来源于：

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类加载

在Android50以后，谷歌彻底抛弃Dalvik，采用ART，那么这两种虚拟机有什么区别呢？

首先介绍一下dex文件，全名是Dalvik Executable，是一种专门为Dalvik设计的可运行的压缩格式。

区别在于：字节码的编译

在Dalvik下，应用每次运行时都会执行转换机器码 *** 作。

在ART(Android Runtime)下，应用在第一次安装的时候，字节码就会预先转换成机器码。

优点：运行快。

缺点：

1机器码占用的存储空间更大；

2应用的安装时间会变长；

一、概述

我们知道Android的程序虽然也是使用Java/Kotlin语言编码，并生成class字节码，但并不能直接运行在JVM上，而是运行在自己的VM上。而Android程序之所以不能在JVM上运行的根本原因是class字节码文件并不是Android的最终可执行文件(执行效率问题)，而是一个过渡产物，最终会生成dex文件在Android VM上执行。

11 Android虚拟机分类：

Android VM大体分为两种： Dalvik 虚拟机和 ART虚拟机。

Dilvik 虚拟机：Android 50 版本之前。

ART虚拟机：Android 50 版本全面使用。

12 虚拟机的演变及优化：

Android 10，使用Dalvik作为Android虚拟机运行环境，此时的虚拟机是一个解释执行器。

Android 22，Android 虚拟机中加入了JIT编译器（Just-In-Time Compiler）。

Android 44，全新的ART虚拟机运行环境诞生，此时ART和Dalvik是共存的，用户可以在两者之间进行选择。

Android 50，ART全面取代了Dalvik成为了Android虚拟机运行环境，并使用AOT预编译技术在安装Apk时全量预编译 。

Android 70，ART虚拟机采用 JIT/AOT混合编译模式。

二、Dalvik

Dalvik是Google公司自己设计用于Android平台的虚拟机，它是Android平台的重要组成部分，支持dex格式（Dalvik Executable）的Java应用程序的运行。dex格式是专门为Dalvik设计的一种压缩格式，适合内存和处理器速度有限的系统。Google对其进行了特定的优化，经过优化的Dalvik，具有高效、简洁、节省资源的特点，同时还允许在有限的内存中同时运行多个虚拟机的实例，并且每一个Dalvik 应用作为一个独立的Linux进程执行。独立的进程可以防止在虚拟机崩溃的时候所有程序都被关闭。

21 Dalvik和JVM的区别

Dalvik 基于寄存器，而 JVM 基于栈。

指令数量：基于寄存器的 *** 作指令，会增加 *** 作数的大小(劣势)，但是会大大减少 *** 作指令的数量(优势)

*** 作效率：基于寄存器(CPU上)的指令 *** 作速度比基于 *** 作数栈(主存)的速度快。

移植性：基于寄存器执行效率好，但是可移植性差，难跨平台。

Dalvik虚拟机有共享机制，不同应用之间在运行时可以共享相同的类，拥有更高的效率。

22 JIT（Just-In-Time Compile）

Android 22之前，Dalvik虚拟机是通过解释器 (解释器逐条读入字节码 -> 逐条翻译成机器码 -> 执行机器码)来执行程序的，效率低。针对这个问题，引进了JIT（即时编译器）技术。它是一种优化手段。

JIT技术：将解释过的机器码缓存起来，下次再执行时到这个方法的时候，则直接从缓存里面取出机器码来执行。减少了读取字节码和翻译字节码的 *** 作。以此来提高效率。JIT技术的引入使得Dalvik的性能提升了3~6倍。

注意： 并不是所有执行过的代码对应的机器码都会被缓存起来。而是只有被认定为热点代码（Hot Spot Code） 的代码才会。这里所指的热点代码主要有两类，包括：

被多次调用的方法

被多次执行的循环体（虽然只是循环体被多次执行，但仍是将整个方法的机器码缓存起来）。

缺点： JIT技术的缺点：

每次重新启动引用都需要重新编译。

运行时比较耗电。

三、ART 虚拟机

ART虚拟机在Android 50开始替换Dalvik虚拟机，其处理应用程序执行的方式不同于Dalvik虚拟机，它不使用JIT而是使用了AOT（Ahead-Of-Time），也就是提前编译技术。并对垃圾收集器也进行了改进和优化。

预先编译机制(AOT)可提高应用的性能。同时ART 还具有比 Dalvik 更严格的安装时验证。

31 AOT（Ahead-Of-Time）预先编译技术

AOT(提前编译技术)： 简单来说就是提前将字节码转换成本地机器码，然后存储在本地磁盘上，运行时可以直接执行，避免了Dalvik时期的应用运行时再来解释字节码。运行时效率大大提高。

在Android 70 之前，Android系统安装Apk时，会进行一次全量预编译，将字节码预先编译成本地机器码，生成 oat文件，并存储在本地磁盘上。这样在App每次运行时就不需要重新编译，可以直接使用编译好本地机器码，运行效率大大提升。但是这也使得安装应用的时间大大增加，于是在Android70及之后，又重新引进了JIT技术，形成JIT/AOT混合编译模式。

混合编译的特点：

应用在安装的时候，不进行AOT预编译。

应用运行时直接通过解释器翻译字节码为机器码然后执行。（在应用运行期间使用了JIT技术）并同时记录热点代码信息到profile文件中。

手机进入空闲或充电状态的时候，系统会扫描APP目录下的profile文件，并通过AOT对热点代码进行编译。

下一次启动时，会根据profile文件来运行已编译好的机器码，避免在运行时对已经转换为机器码的方法又进行了JIT编译。

应用运行期间会持续对热点代码进行记录，以方便在空闲或充电时进行AOT，以此循环。

使用JIT编译器来对AOT编译器进行补充，降低了Apk安装的时间，提升了运行时性能，节省了存储空间，加快应用运行速度。

小结：

Android 70以前，采用AOT全量预编译，Apk安装时预编译dex生成对应的机器码文件。但预编译量大导致Apk安装时间长。

Android 70及之后，采用JIT/AOT混合编译模式，根据对应的profile在空闲时进行AOT预编译。

参考： 实现 ART 即时 (JIT) 编译器

32 Dalvik与ART虚拟机的区别

Dalvik每次都要编译再运行，Art只会安装时启动编译(70之前全量预编译)。

Art占用空间比Dalvik大（原生代码占用的存储空间更大），就是用“空间换时间”。

Art减少编译，减少了CPU使用频率，使用明显改善电池续航。

Art应用启动更快、运行更快、体验更流畅、触感反馈更及时。

33 Interpreter解释器、JIT、AOT的在ART上的使用

解释器： 逐条读入字节码 -> 逐条翻译成机器码 -> 执行机器码，重复执行同一代码时需要重新翻译执行。

JIT编译器： 对运行时的热点代码(热点代码)进行编译，且缓存在内存中，当下次继续执行时，直接从内存中获取，减少重复编译。

AOT编译器： 在运行前将字节码转换为机器码，在运行时直接运行转换后的机器码。

在这里插入描述

34 垃圾回收方面的优化

Android虚拟机（Dalvik && ART）学习

四、Android中的几种文件

41 Apk文件

APK 文件其实是 zip 格式，在Window平台上可以直接将后缀格式改为zip进行解压。解压后的目录如下图所示：

在这里插入描述

文件名 说明

META-INF/ 信息描述，签名等用途。编译生成一个apk包时，会对所有要打包的文件做一个校验计算，并把计算结果放在META-INF目录下。而在Android手机上安装apk包时，应用管理器会按照同样的算法对包里的文件做校验，如果校验结果与META-INF下的内容不一致，系统就不会安装这个apk。这就保证了apk包里的文件不能被随意替换

res/ 存放资源文件

libs/ 存放的是 ndk 编出来的 so 库

AndroidManifestxml 程序全局清单文件

classesdex dalvik 字节码

resourcesars 编译后的二进制资源文件，主要是对应的索引

assets/ 保留工程中assets目录，其他工程下的、jar包中的assets也会合并到该assets目录下。

42 dex文件

dex 文件是可被Dalvik虚拟机识别并执行的文件， Dalvik 会执行 dex 文件中的 dalvik 字节码，但一般Dalvik在执行dex优化后的文件(即odex文件)。

dex文件特点：

dex文件是Android系统中的一种文件，是一种特殊的数据格式，和Apk、jar等格式文件类似。

文件更加紧凑：dex文件是能够被DVM识别，加载并执行的文件格式。相比于Jar文件，dex会把所有包含的信息整合在一起，减少冗余信息，从而降低了加载文件时的I/O耗时，提高类的查找速度。

dex文件包含应用程序的全部 *** 作指令和运行时数据。

相对于PC上的JVM能运行 class文件，Android上的Dalvik虚拟机能运行 dex 文件。

dex文件和 class文件的格式对照：

在这里插入描述

dex 文件结构：

在这里插入描述

43 引起dex文件65535问题的原因

当Android系统启动一个Apk时，会通过 dexopt 工具对dex进行优化。dexopt 的执行过程是在第一次加载dex文件的时候执行的。这个过程会生成一个odex文件，即Optimised Dex (执行odex的效率会比直接执行Dex文件的效率要高很多)。但早期Android系统中， dexopt 有一个问题(即65535问题)。dexopt会把每一个类的方法id检索起来，存在一个链表结构里面。但是这个链表的长度是用一个 short类型(2^16=65536)来保存的，导致了方法id的数目不能够超过65536个。

44 odex文件 (Optimized DEX)

背景： 对Android dex文件进行优化来说，需要注意的一点是dex文件的结构是紧凑的，但是我们还是要想方设法进行运行速度的提高，因此我们仍然需要对dex文件进一步优化。

odex文件的使用场景：

安装阶段： Apk在安装时，系统会进行验证和优化，目的是为了校验代码合法性及优化代码执行速度。当验证和优化后，系统会从Apk中提取dex文件进行优化，并将优化后的产物(odex文件)保存到 data/dalvik-cache 目录下。

运行阶段： 当运行Apk的时候，会直接加载odex文件，避免重复验证和优化，加快了Apk的响应时间。

odex 文件的生成过程：

Android 50之前：Dalvik虚拟机

Dalvik虚拟机会在执行dex文件前对dex文件做优化，生成可执行文件odex，保存到 data/dalvik-cache 目录，最后把Apk文件中的dex文件删除。

注意： 此时生成的odex文件后缀依然是dex ，它是一个dex文件，里面仍然是字节码，而不是本地机器码。

Android50 <= Version < Android 80 (Android O)：ART虚拟机

Android50之后使用ART虚拟机，ART虚拟机使用AOT预编译生成oat文件。oat文件是ART虚拟机运行的文件，是ELF格式二进制文件。oat文件包含dex和编译的本地机器指令，因此比Android50之前的odex文件更大。

oat文件生成过程：

App在首次安装的时候，dex2oat 工具默认会把 dex文件翻译成本地机器指令，生成ELF格式的OAT文件，并将其放在了 /data/dalvik-cache 或 /data/app/packagename/ 目录下，此时oat文件后缀格式为odex。

ART加载oat文件后不需要经过处理就可以直接运行，它在编译时就从字节码装换成机器码了，因此运行速度更快。

Dalvik虚拟机执行程序dex文件前，系统会对dex文件做优化，生成可执行文件odex，保存到 data/dalvik-cache 目录，最后把apk文件中的dex文件删除。 (注意：此时生成的odex文件后缀依然是dex ，它是一个dex文件，里面仍然还是字节码，而不是本地机器码。)

注意： Android50及之后版本生成的 oat文件后缀还是odex，但是已经不是android50 及之前版本的文件格式，而是ELF格式封装的本地机器码。可以认为oat在dex上加了一层壳，可以从oat里提取出dex。

Android O及之后(>=Android 80)：ART虚拟机

Android 80及之后版本，dex2oat会直接生成两个oat文件 (即vdex文件 和 odex文件)。其中 odex 文件是从vdex 文件中提取了部分模块生成的一个新的可执行二进制码文件，odex 从vdex 中提取后，vdex 的大小就减少了。

文件生成过程：

App在首次安装的时候，odex 文件就会生成在 /system/app/<packagename>/oat/ 下。

在系统运行过程中，虚拟机将其 从/system/app 下 copy 到 /data/davilk-cache/ 下。

odex + vdex = Apk 的全部源码 （vdex 并不是独立于odex 的，文件 odex + vdex 才代表一个Apk ）。

odex 的优点和缺点：

优点：

启动快： 省去了系统第一次启动应用时从Apk文件中读取dex文件，并对dex文件做优化的过程。和

对RAM的占用（Apk文件中的dex如果不删除，同一个应用就会存在两个dex文件：apk中和 data/dalvik-cache 目录下）。

安全性：防止第三方用户反编译系统的软件（odex文件是跟随系统环境变化的，改变环境会无法运行；而apk文件中又不包含dex文件，无法独立运行）

劣势：

优化后的odex文件大小通常是原dex文件的1~4倍 (空间换时间)。

45 vdex文件

vdex文件是 Android O (Android 80) 新增的格式包，其目的是为了降低dex2oat时间。

dex2oat的触发场景：

当系统OTA (系统升级) 后，用户自己安装的应用是不会发生任何变化的，但 framework 代码已经发生了变化，因此就需要重新对这些应用也做dex2oat。如果没有vdex文件，则需要重新校验Apk里dex文件合法性；如果存在vdex文件，就可以省略校验的过程，节省一部分时间。

当App的 JIT Profile 信息变化时，background dexopt会在后台重新做dex2oat，因为有了vdex，这个时候也可以直接跳过dex文件的校验流程。

dex 文件直接转化的可执行二进制码文件：

App在首次安装的时候，vdex文件就会生成在 /system/app/<packagename>/oat/下。

在系统运行过程中，虚拟机将其从 /system/app 下 copy 到 /data/davilk-cache/ 下。

46 art文件

art文件是由虚拟机执行odex文件后，记录虚拟机执行Apk启动的常用函数地址信息后生成出来的文件(记录函数地址信息方便寻址)，目的 是用于加快应用启动速度。通常会在data/dalvik-cache/ 目录中保存常用的jar包的相关地址记录。

第一次开机不会生成在 /system/app/<packagename>/oat/ 下，以后也不会。

odex 文件在运行时，虚拟机会计算函数调用频率，进行函数地址的修改。

最后在 /data/davilk-cache/ 由虚拟机生成 art文件(art文件生成)。

生成 art文件后，/system/app 下的odex 和 vdex 会无效，即使你删除，apk也会正常运行。

push 一个新的apk file 覆盖之前 /system/app 下Apk file ，会触发 PMS 扫描时下发 force_dex 的flag ，强行生成新的vdex 文件 ，覆盖之前的vdex 文件，由于某种机制，这个新vdex 文件会copy到 /data/dalvik-cache/ 下，于是 art 文件也变化了。

47 oat文件

ART虚拟机运行的是oat文件，oat文件是一种Android私有ELF文件格式，oat文件包含有从dex文件翻译而来的本地机器指令，还包含有原来的dex文件内容(如下图所示)，因此oat文件比odex文件更大。APK在安装的过程中，会通过dex2oat工具生成一个OAT文件(文件后缀还是odex)。对于apk来说，oat文件实际上就是对odex文件的包装，即oat=odex。

注意： Android50 及之后的版本，oat文件的后缀还是odex，但是已经不是android50 之前的文件格式，而是ELF格式封装的本地机器码。可以认为oat在dex上加了一层壳，可以从oat里提取出dex。

以上就是关于如何重新获得机器码全部的内容，包括:如何重新获得机器码、Android类加载（一）——DVM、ART、Dexopt、DexAot名词解析、Android类加载机制等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！