安卓编译机器码

① 鸿蒙系统当时在编译的时候用的是什么编程语言

根据华为公布的方舟编译器资料 可以推测鸿蒙系统是用C、C++语言编写

如何看待华为鸿蒙系统的开发？

可以预见的鸿蒙系统。

1、除华为外其他国产手机公司不会安装或重视。由于google禁售的是华为，对于小米等其他国产手机公司不禁售，因此小米等其他国产公司不会安装鸿蒙系统，即便出于公共形象的压力而安装，也不会真正重视，最多就是做个样子。

反正，内斗内行吧——除非华为让渡鸿蒙系统的控制权！

2、鸿蒙系统即便能够兼容安卓应用，在过了新鲜期之后，如何提升用户体验度是关键。如果像阿里OS一样可以远程删除用户的app，就直接死翘翘吧。

保持软件开发商的利益和用户体验度的平衡，是鸿蒙系统能否生存的关键。开发商没有得到利益，不会开发鸿蒙系统的app；用户体验度差，用户就不会用鸿蒙系统。

② 方舟编译器怎么使用

方舟编译器怎么用？方舟编译器是可以对安卓底层有优化作用的，这种优化是镶嵌在系统中，能将所有的java代码都编译成机器码，那具体我们要怎么使用到手机上呢？下面是小编整理的方舟编译器怎么用教程，一起去陆旦看看吧！
方舟编译器怎么用
1、方舟编译器是可以对安卓底层有优化作用的，像这样的优化是镶嵌在系统中的，能将所有的Java代码都编译成机器码，从而是程序运行的速度更快换句话说就是方舟编译器并不是一个单独的app，当软件运行时，其就在运行。
2、方舟编译器提供了更高效的内存回收机制，回收时无需暂停应用，随时用随时回收，大大提高运行速度。举一个链凳例子：EMUI9.1仅棚悉旅仅对系统组件SystemServer应用了华为方舟编译器后，就带来了系统操作流畅度提升24%，系统响应性能提升44%的收益。
3、代码优化是编译器最为核心的功能，也是评判一个编译器优劣最重要的标准。
方舟编译器|

③ 为什么android不将java代码编译成本地代码

1、Java所谓的跨平台主要是指cpu架构（x86\ARM\IBM的cpu等等），而不仅仅是OS。
2、Android手机硬件不标准，编译成机器码到一些手机上无法运行。
3、ART是在app安装时，将app的代码编译成本地机器码，这样就可以因地制宜地将二进制码编译成对应的本地机器码了，解决了问题2。但也不是在app发布时编译为本地机器码的。

④ 为什么Android不可以绕开虚拟机直接运行

安卓是谷歌将它从开源linux上改造而来，依旧保持开源特性。为了应用开发者更多地开发安卓程序，自然也就保留了linux上的虚拟机机制。同时，安卓的目标是手机等移动终端，这些设备的处理器五花百门，而且开源安卓也会被各种深入定制，这同样导致了安卓依然沿用了虚拟机机制来保持高兼容性。当然，这些华为研发了方舟编译器，让系统直接运行机器码，以此来消除虚拟机带来的弊端。

安卓系统最早并不是谷歌研发出来的，而是一家名叫Android的初创公司研发的。这家公司成立22个月后，就把原始Android雏形系统以4千万美元的价格卖给了谷歌。 这个雏形原本就基于linux系统研发而来，自然里面也还是沿用了linux的虚拟机机制。

谷歌拿到系统后，自己继续研发Android系统，在2007年还集合了84家当时一流的硬件厂商组成研发联盟。整个研发依然还是基于linux开源系统，但它解决了商业化的一个大难题。那就是，linux是开源系统，是有GPL开源协议的。很多硬件厂家为了适配该系统，必须将在上面研发的驱动程序公开，一旦公开驱动程序代码就相当于公开了自己的硬件设计。而谷歌研发的Android系统解决了这个问题，它将驱动程序放置到了userspace里面，并让它可以通过l内核访问硬件。同时，公开接口就可以让硬件厂商编写驱动程序。硬件厂商只需要提供驱动程序即可，不需要公开源代码了。

这么多硬件厂商一起研发，自然就会 面临一个问题就是每个厂商的硬件都不同。这对Android生态发展来说是个必须解决的兼容性问题。最好的办法依然是沿用linux的虚拟机机制 ，这样Android的软件作者就无需针对不同硬件重新开发软件。只需要一次开发就可以在安卓系统上的虚拟机中运行。

安卓的虚拟机机制在很大程度上解决了兼容性的问题，但是这种边解释边执行的方式，也降低了软件的运行效率。这些年，华为在这方面的研发上花了大功夫，成功研制出了“方舟”编译器。该编译器就是为了解决这个问题而诞生的。如果软件作者采用方舟编译器重新编译自己的程序。它的软件就可以以机器码的形式在安卓系统上高效运行，并且方舟编译器还会对程序进行优化。按照华为方面的数据显示， 使用华为方舟编译器编译后的程序，操作流畅度提升24%，系统响应速度提升44%，第三方应用操作流畅度提升60%！

Android没有绕开虚拟机直接运行，是因为从它研发之初为了保持高兼容性，不得不沿用了虚拟机的机制。但在这些年，华为研发了“方舟”编译器，就是为了解决这个问题。通过方舟编译器编译后的程序可以直接以机器码的形式在安卓系统上运行，效率大大提高。

为了多点儿面试题[机智]

当初设计android的时候，设计人员只是软件工程师，无法针对某个CPU(目前有的CPU框架intel，arm，mips，rsicv等)去开发。最好的是，我针对所有CPU都支持。

跨平台，是指java语言编写的程序，一次编译后，可以在多个系统平台上运行。

因为机器针对不同机器语言，有不同执行逻辑。

就好比二进制000100，在arm里面是调用加法器，而riscv是调用乘法器一样。所以，需要给这些不同平台请个翻译。而虚拟机就是起到翻译作用。

这样虽然增加了消耗(例如执行同样代码，时间消耗上，c明显由于java)，但是可以某种意义上，把软件，物理硬件分开了。软件重点设计自己app，而硬件不断增加CPU性能。

因为上层应用是 建立在 java 库的基础上，运行 java 库 需要 java 虚拟机，调试模式，可以登录到系统里，直接运行linux 命令，也可以下载运行 c程序。

啥叫Android不可以绕开虚拟机直接运行？Android本质上是Linux的变种，它本身就是应用APP的虚拟机容器，Android源码针对硬件平台编译之后，就是直接在CPU上运行的机器码了，它的运行并不依赖于其他的虚拟机。

APP是JAVA打包的，倒是需要在Android的JVM里运行，毕竟要考虑跨平台嘛。

ActivityThread.java就是一个应用程序，有main方法，是一个进程，就是靠虚拟机，没有这个就没有app。咋绕开，绕开就得不用这个，得从内部更换成别的，都更换了那就不是简单的事情了

因为java代码必须编译成机器语言才行，这时候就要接助虚拟机

在问为什么前，先问下是什么？Android是可以不依赖虚拟机运行的，只需要改一下重新编译就好了。

系统就是这么设计的

⑤ 安卓art虚拟机在什么位置

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

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

Dilvik 虚拟机：Android 5.0 版本之前。
ART虚拟机：Android 5.0 版本全面使用。
1.2 虚拟机的演变及优化：
Android 1.0，使用Dalvik作为Android虚拟机运行环境，此时的虚拟机是一个解释执行器。
Android 2.2，Android 虚拟机中加入了JIT编译器（Just-In-Time Compiler）。
Android 4.4，全新的ART虚拟机运行环境诞生，此时ART和Dalvik是共存的，用户可以在两者之间进行选择。
Android 5.0，ART全面取代了Dalvik成为了Android虚拟机运行环境，并使用AOT预编译技术在安装Apk时全量预编译 。
Android 7.0，ART虚拟机采用 JIT/AOT混合编译模式。
二、Dalvik
Dalvik是Google公司自己设计用于Android平台的虚拟机，它是Android平台的重要组成部分，支持dex格式（Dalvik Executable）的Java应用程序的运行。dex格式是专门为Dalvik设计的一种压缩格式，适合内存和处理器速度有限的系统。Google对其进行了特定的优化，经过优化的Dalvik，具有高效、简洁、节省资源的特点，同时还允许在有限的内存中同时运行多个虚拟机的实例，并且每一个Dalvik 应用作为一个独立的Linux进程执行。独立的进程可以防止在虚拟机崩溃的时候所有程序都被关闭。
2.1 Dalvik和JVM的区别
Dalvik 基于寄存器，而 JVM 基于栈。
指令数量：基于寄存器的操作指令，会增加操作数的大小(劣势)，但是会大大减少操作指令的数量(优势)
操作效率：基于寄存器(CPU上)的指令操作速度比基于操作数栈(主存)的速度快。
移植性：基于寄存器执行效率好，但是可移植性差，难跨平台。
Dalvik虚拟机有共享机制，不同应用之间在运行时可以共享相同的类，拥有更高的效率。
2.2 JIT（Just-In-Time Compile）
Android 2.2之前，Dalvik虚拟机是通过解释器 (解释器逐条读入字节码 -> 逐条翻译成机器码 -> 执行机器码)来执行程序的，效率低。针对这个问题，引进了JIT（即时编译器）技术。它是一种优化手段。

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

注意： 并不是所有执行过的代码对应的机器码都会被缓存起来。而是只有被认定为热点代码（Hot Spot Code） 的代码才会。这里所指的热点代码主要有两类，包括：
被多次调用的方法
被多次执行的循环体（虽然只是循环体被多次执行，但仍是将整个方法的机器码缓存起来）。

缺点： JIT技术的缺点：
每次重新启动引用都需要重新编译。
运行时比较耗电。
三、ART 虚拟机
ART虚拟机在Android 5.0开始替换Dalvik虚拟机，其处理应用程序执行的方式不同于Dalvik虚拟机，它不使用JIT而是使用了AOT（Ahead-Of-Time），也就是提前编译技术。并对垃圾收集器也进行了改进和优化。

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

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

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

混合编译的特点：

应用在安装的时候，不进行AOT预编译。
应用运行时直接通过解释器翻译字节码为机器码然后执行。（在应用运行期间使用了JIT技术）并同时记录热点代码信息到profile文件中。
手机进入空闲或充电状态的时候，系统会扫描APP目录下的profile文件，并通过AOT对热点代码进行编译。
下一次启动时，会根据profile文件来运行已编译好的机器码，避免在运行时对已经转换为机器码的方法又进行了JIT编译。
应用运行期间会持续对热点代码进行记录，以方便在空闲或充电时进行AOT，以此循环。
使用JIT编译器来对AOT编译器进行补充，降低了Apk安装的时间，提升了运行时性能，节省了存储空间，加快应用运行速度。

小结：
Android 7.0以前，采用AOT全量预编译，Apk安装时预编译dex生成对应的机器码文件。但预编译量大导致Apk安装时间长。
Android 7.0及之后，采用JIT/AOT混合编译模式，根据对应的profile在空闲时进行AOT预编译。

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

3.2 Dalvik与ART虚拟机的区别
Dalvik每次都要编译再运行，Art只会安装时启动编译(7.0之前全量预编译)。
Art占用空间比Dalvik大（原生代码占用的存储空间更大），就是用“空间换时间”。
Art减少编译，减少了CPU使用频率，使用明显改善电池续航。
Art应用启动更快、运行更快、体验更流畅、触感反馈更及时。
3.3 Interpreter解释器、JIT、AOT的在ART上的使用
解释器： 逐条读入字节码 -> 逐条翻译成机器码 -> 执行机器码，重复执行同一代码时需要重新翻译执行。
JIT编译器： 对运行时的热点代码(热点代码)进行编译，且缓存在内存中，当下次继续执行时，直接从内存中获取，减少重复编译。
AOT编译器： 在运行前将字节码转换为机器码，在运行时直接运行转换后的机器码。

在这里插入图片描述

3.4 垃圾回收方面的优化
Android虚拟机（Dalvik && ART）学习

四、Android中的几种文件
4.1 Apk文件
APK 文件其实是 zip 格式，在Window平台上可以直接将后缀格式改为zip进行解压。解压后的目录如下图所示：
在这里插入图片描述

文件名 说明
META-INF/ 信息描述，签名等用途。编译生成一个apk包时，会对所有要打包的文件做一个校验计算，并把计算结果放在META-INF目录下。而在Android手机上安装apk包时，应用管理器会按照同样的算法对包里的文件做校验，如果校验结果与META-INF下的内容不一致，系统就不会安装这个apk。这就保证了apk包里的文件不能被随意替换
res/ 存放资源文件
libs/ 存放的是 ndk 编出来的 so 库
AndroidManifest.xml 程序全局清单文件
classes.dex dalvik 字节码
resources.ars 编译后的二进制资源文件，主要是对应的索引
assets/ 保留工程中assets目录，其他工程下的、jar包中的assets也会合并到该assets目录下。
4.2 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 文件结构：
在这里插入图片描述

4.3 引起dex文件65535问题的原因
当Android系统启动一个Apk时，会通过 dexopt 工具对dex进行优化。dexopt 的执行过程是在第一次加载dex文件的时候执行的。这个过程会生成一个odex文件，即Optimised Dex (执行odex的效率会比直接执行Dex文件的效率要高很多)。但早期Android系统中， dexopt 有一个问题(即65535问题)。dexopt会把每一个类的方法id检索起来，存在一个链表结构里面。但是这个链表的长度是用一个 short类型(2^16=65536)来保存的，导致了方法id的数目不能够超过65536个。
4.4 odex文件 (Optimized DEX)
背景： 对Android dex文件进行优化来说，需要注意的一点是dex文件的结构是紧凑的，但是我们还是要想方设法进行运行速度的提高，因此我们仍然需要对dex文件进一步优化。
odex文件的使用场景：

安装阶段： Apk在安装时，系统会进行验证和优化，目的是为了校验代码合法性及优化代码执行速度。当验证和优化后，系统会从Apk中提取dex文件进行优化，并将优化后的产物(odex文件)保存到 data/dalvik-cache 目录下。
运行阶段： 当运行Apk的时候，会直接加载odex文件，避免重复验证和优化，加快了Apk的响应时间。
odex 文件的生成过程：

Android 5.0之前：Dalvik虚拟机

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

注意： 此时生成的odex文件后缀依然是dex ，它是一个dex文件，里面仍然是字节码，而不是本地机器码。
Android5.0 <= Version < Android 8.0 (Android O)：ART虚拟机

Android5.0之后使用ART虚拟机，ART虚拟机使用AOT预编译生成oat文件。oat文件是ART虚拟机运行的文件，是ELF格式二进制文件。oat文件包含dex和编译的本地机器指令，因此比Android5.0之前的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文件，里面仍然还是字节码，而不是本地机器码。)

注意： Android5.0及之后版本生成的 oat文件后缀还是odex，但是已经不是android5.0 及之前版本的文件格式，而是ELF格式封装的本地机器码。可以认为oat在dex上加了一层壳，可以从oat里提取出dex。
Android O及之后(>=Android 8.0)：ART虚拟机

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

文件生成过程：
App在首次安装的时候，odex 文件就会生成在 /system/app/<packagename>/oat/ 下。
在系统运行过程中，虚拟机将其 从/system/app 下 到 /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倍 (空间换时间)。
4.5 vdex文件
vdex文件是 Android O (Android 8.0) 新增的格式包，其目的是为了降低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 下 到 /data/davilk-cache/ 下。
4.6 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 文件会到 /data/dalvik-cache/ 下，于是 art 文件也变化了。
4.7 oat文件
ART虚拟机运行的是oat文件，oat文件是一种Android私有ELF文件格式，oat文件包含有从dex文件翻译而来的本地机器指令，还包含有原来的dex文件内容(如下图所示)，因此oat文件比odex文件更大。APK在安装的过程中，会通过dex2oat工具生成一个OAT文件(文件后缀还是odex)。对于apk来说，oat文件实际上就是对odex文件的包装，即oat=odex。

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

⑥ 安卓手机运行环境art什么意思

Android运行环境ART

安卓之前的版本运行机制是Dalvik，这个导致安卓卡慢，安卓4.4之后推出了ART，在5.0上完全使用了ART模式。

ART 的机制与 Dalvik 不同。在Dalvik下，应用每次运行的时候，字节码都需要通过即时编译器转换为机器码，这会拖慢应用的运行效率，而在ART 环境中，应用在第一次安装的时候，字节码就会预先编译成机器码，使其成为真正的本地应用。这个过程叫做预编译（AOT,Ahead-Of-Time）。这样的话，应用的启动(首次)和执行都会变得更加快速。

通俗一点就是，ART增加APK安装容量，实现了流畅度。

⑦ 安卓平台属于动态库操作吗

属于
静态库全称静态链接库，动态库全称动态链接库，看到全称就知道什么意思了吧？也就是说在链接的时候才会用到的库，只有C/C++、OC语言才会有链接过程，Java没有。

在Android中说到静态库和动态库，一般说的都是C/C++代码，我们知道在android中是通过jni技术访问到C代码的，我们会把C/C++打包成so文件，这个就是动态库（共享库）。如果我们想要使用的C库是.a形式的静态库时，我们要把.a包装成so库，具体网上有方法。

个人感觉在java语言中讨论静态库和动态库就是个伪概念，java是的编译结果是字节码文件，不是二进制文件，而且没有链接的过程，jvm在解释执行java代码的时候调用C++代码只能是动态的。

在C++和object C开发中，用编译链接的过程，静态库在链接过程中，会和自己写的源代码打到一块，多个程序多个静态库。动态库不会打到一块，如果有共享情况的话，系统只会加载一次。

OC的代码处理过程是很复杂的，有预处理、编译、链接过程，预处理就是处理宏什么的，编译这个过程就很复杂了，有编译前端和编译后端，编译称机器码（中间还会有汇编的过程），链接就是链接动态库或者静态库。

Android（java）代码处理过程就很简单啦，毕竟是运行在虚拟机上的。没有所谓的预处理，直接编译，这里的编译也就是把java代码转化成字节码，这个编译和OC中的编译可不是一个概念，只不过也这么叫而已。后续Aandroid还会用dex工具把.class打包成.dex，不同的VM模式（5.0以后都是ART）会对.dex进行不同的优化，具体看Android 编译到运行APK过程总结。需要提一下的是，ART采用AOT和JIT技术，在安装或者运行的时候，会把字节码转化成机器码，这个机器码也会受VM控制的，具体看Android之Dalvik 、ART

C/C++、Object C属于编译型语言，这是毋庸置疑的，因为它们都会在生成安装包之前编译成机器码。