草庐IT

Android虚拟机Dalvik和ART详解

Android开发编程 2023-03-28 原文

Android应用用Java/Kotlin编写,Android虚拟机并不使用JVM字节码,而是将Class文件通过DX编译器(现已换成D8)编译程dex文件,然后由虚拟机执行;

底层眼里无论是java还是kolin,最终都是机器码运行;

不废话,开始介绍

一、Dalvik简单介绍

1、Dalvik虚拟机介绍

Dalvik是Google公司自己设计用于Android平台的虚拟机。Dalvik虚拟机是Google等厂商合作开发的Android移动设备平台的核心组成部分之一。它可以支持已转换为 .dex(即Dalvik Executable)格式的Java应用程序的运行,.dex格式是专为Dalvik设计的一种压缩格式,适合内存和处理器速度有限的系统。Dalvik 经过优化,允许在有限的内存中同时运行多个虚拟机的实例,并且 每一个Dalvik 应用作为一个独立的Linux 进程执行。独立的进程可以防止在虚拟机崩溃的时候所有程序都被关闭。

2、Dalvik诞生消亡史

  • Android 1.0,使用Dalvik作为Android虚拟机运行环境。
  • Android 2.2,Google在Andriod虚拟机中加入了JIT编译器(Just-In-Time Compiler)。
  • Android 4.4,Google带来了全新的虚拟机运行环境ART,此时ART和Dalvik是共存的,用户可以在两者之间进行选择。
  • Android 5.0,ART全面取代了Dalvik成为了Android虚拟机运行环境,至此Dalvik退出历史舞台。

3、Dalvik 特点

  • Dalvik虚拟机运行的是Dalvik字节码,Dalvik字节码由Java字节码转换而来,并被打包到一个dex文件中。而JVM运行的是class文件或jar文件;
  • 加载速度快,dex相比于Jar文件会把所有包含的信息整合在一起,减少了冗余信息。这样就减少I/O操作,提高类的查找速度。
  • Dalvik虚拟机是基于寄存器,而JVM是基于栈(操作数栈)。虽然基于寄存器执行效率好,但是可移植性差,难跨平台。
  • Dalvik虚拟机允许在有限的内存中同时运行多个进程,每一个应用都运行在一个Dalvik虚拟机实例中,拥有独立的进程空间。
  • Dalvik虚拟机有共享机制,不同应用之间在运行时可以共享相同的类,拥有更高的效率。

二、ART虚拟机

1、ART概念介绍

  • ART虚拟机在Android 5.0开始替换Dalvik虚拟机。其处理应用程序执行的方式不同于Dalvik虚拟机,它不使用JIT而是使用了AOT(Ahead-Of-Time),也就是提前编译技术。并且对垃圾收集器也进行了改进和优化。
  • ART虚拟机由Android4.4被引入成为可选项,在Android5.0之后替换掉了Dalvik,并且在Android7.0和8.0分别进行了一系列改动。

2、基本概念和名词

  • .dex文件:App所有java源代码编译后生成众多class文件,由DX/D8,编译为一个/多个(multiDex)dex文件,由Android虚拟机编译执行。
  • .odex文件:dex文件经过验证和优化后的产物,art下的odex文件包含经过AOT编译后的代码以及dex的完整内容,但Android8.0之后odex中的dex内容移动到了.vdex文件。
  • .art文件:art下根据配置文件生成odex文件时同时生成.art文件,主要是为了提升运行时加载odex中热点代码的速度,包含了类信息和odex中热点方法的索引,运行App时会首先根据这个文件来加载odex中已经编译过的代码。
  • 解释器(Interpreter):用于程序运行时对代码进行逐行解释,翻译成对应平台的机器码执行。
  • JIT编译(Just In Time):由于解释器方式运行太慢引入,对于频繁运行的热点代码(判定标准一般是在某个时间段内执行次数达到某个阈值)进行实时编译(在ART下以方法为粒度)执行,并且缓存JIT编译后的代码在内存中用于下次执行。由于以方法为粒度(ArtMethod)进行编译,JIT编较于解释器可以生成效率更高的代码,运行更快。
  • AOT编译(Ahead-Of-Time):应用安装时全量编译所有代码为本地机器码,运行时直接执行机器码。

3、ART 如何运作

(1)4.4~7.0

最开始ART只采用AOT编译,在App安装时就编译所有代码存储在本地,打开App直接运行,这样做的优点是应用运行速度变快,缺点也很明显,App安装时间明显变长,而且占用存储空间较大

(2)7.0

Android N之后对于ART进行改动,重新引入了JIT编译,结合使用AOT/JIT混合编译,主要机制如下:

  • 安装时不进行任何编译,前几次运行仅通过解释器解释运行,同时对热点代码进行JIT编译,并将这些代码的相关信息记录在一个配置文件里
  • 设备处于空闲和充电状态时,编译守护进程读取配置文件对热点代码进行AOT编译并写入到app对应的odex文件中
  • 再次启动应用后优先使用AOT编译过的代码,否则使用解释器+JIT编译,重复这个过程
  • 对于一些庞大的APP,比如某宝,有些功能可能你一辈子都不会用到,根据上述策略这部分代码就不会被编译保存,从而减少了存储空间的占用。另外,在系统升级时也避免了全量编译所有现存应用造成的时间空间消耗。

(3)8.0

Android 8.0引入了.vdex文件,它里面包含 APK 的未压缩 DEX 代码,以及一些用于加快验证速度的元数据.

4、ART垃圾收集器优化

  • 只有一次GC暂停(Dalvik需要两次)。
  • 并发复制,可减少后台内存使用和碎片。
  • GC暂停的时间不受堆大小影响。
  • 在清理最近分配的短时对象这种特殊情况中,回收器的总GC时间更短。
  • 优化了垃圾回收的工效,能够更加及时地进行并行垃圾回收,这使得GC_FOR_ALLOC事件在典型用例中极为罕见。

5、ART时间线

  • Android 4.4 ,ART和Dalvik是共存的,用户可以在两者之间进行选择。
  • Android 5.0,正式取代Dalvik虚拟机成为Android虚拟机运行环境,Dalvik退出历史舞台,AOT取代JIT。
  • Android 7.0,JIT回归,采用JIT和AOP混合编译模式。
  • ART持续更新优化

6、Dalvik VM 和 ART VM 有什么区别

  • ART早期使用AOT技术,后期使用AOT+JIT混合,而Dalvik使用JIT。
  • ART支持64位CPU并兼容32位CPU,而Dalvik只支持32位CPU。
  • ART对垃圾收集器进行了改进优化,提高了吞吐量。

总结

核心内容就一句话:App安装时不编译代码只校验合法性,运行时通过解释器执行,将运行频繁的代码进行编译放到内存缓存并且记录在本地配置文件,后台线程编译配置文件记录的方法存放到.odex文件,再次运行App时优先读.odex文件中编译后的代码,然后重复这个过程。

有关Android虚拟机Dalvik和ART详解的更多相关文章

  1. 在VMware16虚拟机安装Ubuntu详细教程 - 2

    在VMware16.2.4安装Ubuntu一、安装VMware1.打开VMwareWorkstationPro官网,点击即可进入。2.进入后向下滑动找到Workstation16ProforWindows,点击立即下载。3.下载完成,文件大小615MB,如下图:4.鼠标右击,以管理员身份运行。5.点击下一步6.勾选条款,点击下一步7.先勾选,再点击下一步8.去掉勾选,点击下一步9.点击下一步10.点击安装11.点击许可证12.在百度上搜索VM16许可证,复制填入,然后点击输入即可,亲测有效。13.点击完成14.重启系统,点击是15.双击VMwareWorkstationPro图标,进入虚拟机主

  2. kvm虚拟机安装centos7基于ubuntu20.04系统 - 2

    需求:要创建虚拟机,就需要给他提供一个虚拟的磁盘,我们就在/opt目录下创建一个10G大小的raw格式的虚拟磁盘CentOS-7-x86_64.raw命令格式:qemu-imgcreate-f磁盘格式磁盘名称磁盘大小qemu-imgcreate-f磁盘格式-o?1.创建磁盘qemu-imgcreate-fraw/opt/CentOS-7-x86_64.raw10G执行效果#ls/opt/CentOS-7-x86_64.raw2.安装虚拟机使用virt-install命令,基于我们提供的系统镜像和虚拟磁盘来创建一个虚拟机,另外在创建虚拟机之前,提前打开vnc客户端,在创建虚拟机的时候,通过vnc

  3. 安卓apk修改(Android反编译apk) - 2

    最近因为项目需要,需要将Android手机系统自带的某个系统软件反编译并更改里面某个资源,并重新打包,签名生成新的自定义的apk,下面我来介绍一下我的实现过程。APK修改,分为以下几步:反编译解包,修改,重打包,修改签名等步骤。安卓apk修改准备工作1.系统配置好JavaJDK环境变量2.需要root权限的手机(针对系统自带apk,其他软件免root)3.Auto-Sign签名工具4.apktool工具安卓apk修改开始反编译本文拿Android系统里面的Settings.apk做demo,具体如何将apk获取出来在此就不过多介绍了,直接进入主题:按键win+R输入cmd,打开命令窗口,并将路

  4. 物联网MQTT协议详解 - 2

    一、什么是MQTT协议MessageQueuingTelemetryTransport:消息队列遥测传输协议。是一种基于客户端-服务端的发布/订阅模式。与HTTP一样,基于TCP/IP协议之上的通讯协议,提供有序、无损、双向连接,由IBM(蓝色巨人)发布。原理:(1)MQTT协议身份和消息格式有三种身份:发布者(Publish)、代理(Broker)(服务器)、订阅者(Subscribe)。其中,消息的发布者和订阅者都是客户端,消息代理是服务器,消息发布者可以同时是订阅者。MQTT传输的消息分为:主题(Topic)和负载(payload)两部分Topic,可以理解为消息的类型,订阅者订阅(Su

  5. Tcl脚本入门笔记详解(一) - 2

    TCL脚本语言简介•TCL(ToolCommandLanguage)是一种解释执行的脚本语言(ScriptingLanguage),它提供了通用的编程能力:支持变量、过程和控制结构;同时TCL还拥有一个功能强大的固有的核心命令集。TCL经常被用于快速原型开发,脚本编程,GUI和测试等方面。•实际上包含了两个部分:一个语言和一个库。首先,Tcl是一种简单的脚本语言,主要使用于发布命令给一些互交程序如文本编辑器、调试器和shell。由于TCL的解释器是用C\C++语言的过程库实现的,因此在某种意义上我们又可以把TCL看作C库,这个库中有丰富的用于扩展TCL命令的C\C++过程和函数,所以,Tcl是

  6. ruby-on-rails - Rails 验证虚拟属性 - 2

    我这个模型:classBunny每当我提交一个表单来创建这个模型时,我都会收到以下错误:#的未定义方法“number_before_type_cast” 最佳答案 我通过将此方法添加到我的Bunny模型中解决了这个问题:defnumber_before_type_castnumberend我不喜欢它,但我想在有人发布更好的解决方案之前它会起作用。 关于ruby-on-rails-Rails验证虚拟属性,我们在StackOverflow上找到一个类似的问题: h

  7. 【详解】Docker安装Elasticsearch7.16.1集群 - 2

    开门见山|拉取镜像dockerpullelasticsearch:7.16.1|配置存放的目录#存放配置文件的文件夹mkdir-p/opt/docker/elasticsearch/node-1/config#存放数据的文件夹mkdir-p/opt/docker/elasticsearch/node-1/data#存放运行日志的文件夹mkdir-p/opt/docker/elasticsearch/node-1/log#存放IK分词插件的文件夹mkdir-p/opt/docker/elasticsearch/node-1/plugins若你使用了moba,直接右键新建即可如上图所示依次类推创建

  8. 【Elasticsearch基础】Elasticsearch索引、文档以及映射操作详解 - 2

    文章目录概念索引相关操作创建索引更新副本查看索引删除索引索引的打开与关闭收缩索引索引别名查询索引别名文档相关操作新建文档查询文档更新文档删除文档映射相关操作查询文档映射创建静态映射创建索引并添加映射概念es中有三个概念要清楚,分别为索引、映射和文档(不用死记硬背,大概有个印象就可以)索引可理解为MySQL数据库;映射可理解为MySQL的表结构;文档可理解为MySQL表中的每行数据静态映射和动态映射上面已经介绍了,映射可理解为MySQL的表结构,在MySQL中,向表中插入数据是需要先创建表结构的;但在es中不必这样,可以直接插入文档,es可以根据插入的文档(数据),动态的创建映射(表结构),这就

  9. 【云计算】私有云在VMware下虚拟机的创建与配置(图文教程) - 2

    【适用平台】私有云   说明:完成私有云部分是需要两台虚拟机的,分别为controller、compute两个节点,但我们只需配置一台,然后克隆就方便多啦!需要用到的映射文件:关于vm的安装我就不介绍的,毕竟挺简单的,下面让我们看看基于私有云模块中,虚拟机的搭建吧。1、创建新的虚拟机,这里一般我会选择自定义,毕竟后面的配置都要根据私有云相关来进行搭建,会比较复杂。(如果是基础的可以选择典型,典型的满足一般虚拟机的配置) 2、选择稍后安装操作系统会比较方便后续的选择,这里你也可以自己选择自己的映像文件(但不建议)  3、我们是基于Linux下操作的,所以选择Linux客户机操作系统,版本选择自己

  10. 最强Http缓存策略之强缓存和协商缓存的详解与应用实例 - 2

    HTTP缓存是指浏览器或者代理服务器将已经请求过的资源保存到本地,以便下次请求时能够直接从缓存中获取资源,从而减少网络请求次数,提高网页的加载速度和用户体验。缓存分为强缓存和协商缓存两种模式。一.强缓存强缓存是指浏览器直接从本地缓存中获取资源,而不需要向web服务器发出网络请求。这是因为浏览器在第一次请求资源时,服务器会在响应头中添加相关缓存的响应头,以表明该资源的缓存策略。常见的强缓存响应头如下所述:Cache-ControlCache-Control响应头是用于控制强制缓存和协商缓存的缓存策略。该响应头中的指令如下:max-age:指定该资源在本地缓存的最长有效时间,以秒为单位。例如:Ca

随机推荐