安卓studiosetup怎么运行

Android studio怎么用手机运行？

准备工具：

Android studio

手机

具体步骤：

1、要想把Android studio的开发的Android的项目部署到手机进行调式的话，就需要使用数据把电脑与手机进行连接。

2、然后进行打开Android studio的开发软件，进入到当前的项目中，选中一个项目。

3、进行点击运行菜单中一个运行按钮，如果没有选中项目，运行图标左侧位置，可以再次选择项目需要部署项目。

4、d出choose device选项框中，可以看到choose a running device的真机列表，选中一个已连接真机，然后点击“OK”。

5、选择底部位置中的Android的按钮，就d出一个为logcat的信息，和devices中真机和虚拟机的列表。

6、通过安装完成之后会直接在手机中打开应用的界面中，就可以通过Android studio进行调式项目app。

android studio怎么覆盖安装？

如果没有Android studio的安装程序可以到网上进行下载安装程序，这里直接双击安装应用程序，进入到Android studio的欢迎界面中。

进入到一步之后，需要进行安装相关的插件程序，如果电脑中已有sdk，可以把勾去掉，如果第一次开发Android项目，可以直接默认安装。点击“next”。

对安装的存放路径的选择，默认是在c盘中，如果c盘空间不够大，可以选择其它盘路径中。

虚拟机启动的内存的大小默认512MB，可以根据电脑配置，更改内存的大小。

这样开始进行安装，剩下步骤可以直接下一步即可。

等待安装完成，完成之后可以看到一个界面为completing the Android studio setup的界面，如果要启动默认即可，点击“finish”。

进入complete installation界面中，如果是第一次使用，进行选择最后一项即可。开始Android studio软件开发之旅吧。

sky studio怎么使用？

需要的工具是ES文件浏览器

首先点开文件浏览器

再点击倒的三角形展开

点击文档到Android文件夹→再点击data文件夹→找到MapleSkyStudio→再点击files文件夹→再点击Sheet文件夹

把乐谱放在这里就可以进入Sky studio使用了

Android Studio如何配置SDK环境？

1、首先我们在本地需要安装好SDK的环境，如下图所示



2、接下来点击File菜单下面的Settings选项，如下图所示



3、然后找到Android SDK选项，如下图所示



4、接着点击右侧的Edit选项，如下图所示



5、然后点击路径输入框后面的三个点按钮，选择你SDK的目录，如下图所示



6、最后一路Next进行配置即可，如下图所示



androidstudio如何连接鸿蒙手机？

打开android studio的设置，找到plugins这一项点进去，然后搜索ADB Wi-Fi这个插件下载下来，这个插件的作用是当你的手机和电脑处于同一个网段时，可以通过Wi-Fi进行连接，这个连接可以查看你手机的IP以及系统版本

下载完成后点击右下角的ADB Wi-Fi使用Wi-Fi连接上android studio，这样就显示了鸿蒙系统对应的安卓版本

还有左边如果是在调试查看log也是会显示鸿蒙系统对应的安卓版本

然后把这个安卓系统的版本作为参数写到appium的客户端就可以连接到鸿蒙系统的手机了

在 android 的API中有提供 SystemClocksetCurrentTimeMillis()函数来修改系统时间，可惜无论你怎么调用这个函数都是没用的，无论模拟器还是真机，在logcat中总会得到"Unable to open alarm driver: Permission denied "这个函数需要root权限或者运行与系统进程中才可以用。

本来以为就没有办法在应用程序这一层改系统时间了，后来在网上搜了好久，知道这个目的还是可以达到的。

第一个方法简单点，不过需要在Android系统源码的环境下用make来编译：

1 在应用程序的AndroidManifestxml中的manifest节点中加入

"android:sharedUserId="androiduidsystem"这个属性。

2 修改Androidmk文件，加入LOCAL_CERTIFICATE := platform这一行

3 使用mm命令来编译，生成的apk就有修改系统时间的权限了。

第二个方法麻烦点，不过不用开虚拟机跑到源码环境下用make来编译：

1 同上，加入"android:sharedUserId="androiduidsystem"这个属性。

2 使用eclipse编译出apk文件，但是这个apk文件是不能用的。

3 用压缩软件打开apk文件，删掉META-INF目录下的CERTSF和CERTRSA两个文件。

4 使用目标系统的platform密钥来重新给apk文件签名。这步比较麻烦，

首先找到密钥文件，在我的Android源码目录中的位置是"build argetproductsecurity"，下面的platformpk8和platformx509pem两个文件。

然后用Android提供的Signapk工具来签名，signapk的源代码是在"build oolssignapk"下，用法为"signapk platformx509pem platformpk8 inputapk outputapk"，文件名最好使用绝对路径防止找不到，也可以修改源代码直接使用。这样最后得到的apk和第一个方法是一样的。

最后解释一下原理，首先加入android:sharedUserId="androiduidsystem"这个属性。通过Shared User id,拥有同一个User id的多个APK可以配置成运行在同一个进程中。那么把程序的UID配成androiduidsystem，也就是要让程序运行在系统进程中，这样就有权限来修改系统时间了。

只是加入UID还不够，如果这时候安装APK的话发现无法安装，提示签名不符，原因是程序想要运行在系统进程中还要有目标系统的platform key，就是上面第二个方法提到的platformpk8和platformx509pem两个文件。用这两个key签名后apk才真正可以放入系统进程中。第一个方法中加入LOCAL_CERTIFICATE := platform其实就是用这两个key来签名。

这也有一个问题，就是这样生成的程序只有在原始的Android系统或者是自己编译的系统中才可以用，因为这样的系统才可以拿到 platformpk8和platformx509pem两个文件。要是别家公司做的Android上连安装都安装不了。试试原始的Android 中的key来签名，程序在模拟器上运行OK，不过放到G3上安装直接提示"Package has no signatures that match those in shared user androiduidsystem"，这样也是保护了系统的安全。

一、概述

我们知道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 Runtime

申国骏

2022-08-08 12:31·字数:2599·阅读:2340

imagepng

上图是Android整体的架构，Android Runtime之于Android而言相当于心脏之于人体，是Android程序加载和运行的环境。这篇文章主要针对Android Runtime部分进行展开，探讨Android Runtime的发展以及目前现状，并介绍应用Profile-Guided Optimization(PGO)技术对应用启动速度进行优化的可行性。转载请注明来源「申国骏」

App运行时演进

JVM

Android原生代码使用Java或者Kotlin编写，这些代码会通过javac或者kotlinc编译成class文件，在Android之前，这些class文件会被输入到JVM中执行。JVM可以简单分为三个子系统，分别是Class Loader、Runtime Data Area以及Execution Engine。其中Class Loader主要负责加载类、校验字节码、符号引用链接及对静态变量和静态方法分配内存并初始化。Runtime Data负责存储数据，分为方法区、堆区、栈区、程序计数器以及本地方法栈。Execution Engine负责二进制代码的执行以及垃圾回收。

imagepng

Execution Engine中，会采用Interpreter或者JIT执行。其中Interpreter表示在运行的过程中对二进制代码进行解释，每次执行相同的二进制代码都进行解释比较浪费资源，因此对于热区的二进制代码会进行JIT即时编译，对二进制代码编译成机器码，这样相同的二进制代码执行时，就不用再次进行解释。

imagepng

DVM(Android 21/22)

JVM是stack-based的运行环境，在移动设备中对性能和存储空间要求较高，因此Android使用了register-based的Dalvik VM。从JVM转换到DVM我们需要将class文件转换为dex文件，从class转换到dex的过程需要经过 desugar -> proguard -> dex compiler三个过程，这三个过程后来逐步变成 proguard -> D8(Desugar) 直到演变到今天只需要一步R8(D8(Desugar))。

imagepng

我们主要关注Android中Runtime Engine与JVM的区别。在Android早期的版本里面，只存在Interpreter解释器，到了Android22版本将JIT引入，这个版本Dalvik与JVM的Runtime Engine区别不大。

imagepng

ART-AOT(Android 44/50)

为了加快应用的启动速度和体验，到了Android44，Google提供了一个新的运行时环境ART(Android Runtime)，到了Android50，ART替换Dalvik成为唯一的运行时环境。

imagepng

ART运行时环境中，采用了AOT(Ahead-of-time)编译方式，即在应用安装的时候就将dex提前编译成机器码，经过AOT编译之后dex文件会生成oat文件。这样在应用启动执行的时候，因为不需要进行解释编译，大大加快了启动速度。

imagepng

然而AOT带来了以下两个问题：

应用安装时间大幅增加，由于在安装的过程中同时需要编译成机器码，应用安装时间会比较长，特别在系统升级的时候，需要对所有应用进行重新编译，出现了经典的升级等待噩梦。

imagepng

应用占用过多的存储空间，由于所有应用都被编译成oat机器码，应用所占的存储空间大大增加，使得本来并不充裕的存储空间变得雪上加霜。

进一步思考对应用全量进行编译可能是没有必要的，因为用户可能只会用到一个应用的部分常用功能，并且全量编译之后更大的机器码加载会占用IO资源。

ART-PGO(Android 70)

从Android70开始，Google重新引入了JIT的编译方式，不再对应用进行全量编译，结合AOT、JIT、Interpreter三者的优势提出了PGO(Profile-guided optimization)的编译方式。

在应用执行的过程中，先使用Interpreter直接解释，当某些二进制代码被调用次数较多时，会生成一个Profile文件记录这些方法存储起来，当二进制代码被频繁调用时，则直接进行JIT即时编译并缓存起来。

当应用处于空闲（屏幕关闭且充电）的状态时，编译守护进程会根据Profile文件进行AOT编译。

当应用重新打开时，进行过JIT和AOT编译的代码可以直接执行。

这样就可以在应用安装速度以及应用打开速度之间取得平衡。

imagepng

imagepng

JIT 工作流程：

imagepng

ART-Cloud Profile(Android 90)

不过这里还是有一个问题，就是当用户第一次安装应用的时候并没有进行任何的AOT优化，通常会经过用户多次的使用才能使得启动速度得到优化。

imagepng

考虑到一个应用通常会有一些用户经常使用执行的代码（例如启动部分以及用户常用功能）并且大多数时候会有先行版本用于收集Profile数据，因此Google考虑将用户生成的Profile文件上传到Google Play中，并在应用安装时同时带上这个Profile文件，在安装的过程中，会根据这个Profile对应用进行部分的AOT编译。这样当用户安装完第一次打开的时候，就能达到较快的启动速度。

imagepng

imagepng

Profile in cloude 需要系统应用市场支持，在国内市场使用Google Play的占比非常低，因此cloud profile的优化在国内几乎是没有作用的，不过Profile的机制提供了一个可以做启动优化的思路。早在2019年，支付宝就在秒开技术的回应的里面提到过profile-based compile的技术，参考：如何看待今日头条自媒体发布谣言称「支付宝几乎秒开是因为采用华为方舟编译器」？，这也是我们一直研究Profile技术的原因。困扰着我们的一直有两个问题，第一个问题是如何生成Profile文件，第二个问题是怎么使用生成的Profile文件。对于第一个问题的解决相对还是有思路的，因为app运行就会生成profile文件，因此我们手动运行几次app就能在文件系统中收集到这个文件，不过如何以一种较为自动化的手段收集仍然是个问题。第二个问题我们知道Profile文件最终生成的位置，因此我们可以把生成的文件放到相应的系统目录，不过大多数手机和应用都没有权限直接放置这个文件。因此Profile优化技术一直都没有落地，直到Baseline Proflie让我们看到了希望。

Baseline Profile

Baseline Profile是一套生成和使用Profile文件的工具，在2022年一月份开始进入视野，随后在Google I/O 2022随着Jetpack新变化得到广泛关注。其背景是Google Map加快了发版速度，Cloud Profle还没完全收集好就上新版，导致Cloud Proflie失效。还有一个背景是Jetpack Compose 不是系统代码，因此没有完全编译成机器码，而且Jetpack Compose库比较大，因此在Profile生成之前使用了Jetpack Compose的应用启动会产生性能问题。最后Google为了解决这些问题，创造了收集Profile的BaselineProfileRule Macrobenchmark以及使用Profile的ProfileInstaller。

使用Baseline Profile的机制可以在Android7及以上的手机上得到应用的启动加速，因为从上述知道Android7就已经开始有PGO(Profile-guided optimization)的编译方式。生成的Profile文件会打包到apk里面，并且会结合Google Play的Cloud Profile来引导AOT编译。虽然在国内基本上用不了Cloud Profile，不过Baseline Profile是可以独立于Google Play单独使用的。

imagepng

在使用了Baseline Proflie之后，有道词典的启动速度从线上统计上看，冷启动时间有15%的提升。

这篇文章主要介绍了Android Runtime的演进以及对于应用启动的影响，下一篇文章我会详细介绍关于Profile&dex文件优化、Baseline Profile工具库原理，以及在实际 *** 作上如何使用的问题，敬请大家期待一下！

以上就是关于安卓studiosetup怎么运行全部的内容，包括:安卓studiosetup怎么运行、android 如何在应用程序中修改系统时间、安卓art虚拟机在什么位置等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！