CN115543334B - 编译优化方法及电子设备 - Google Patents

Abstract

本申请实施例提供了一种编译优化方法及电子设备。在该方法中，对应用进行编译优化时，在java层PMS中，线程需要持的互斥锁仅用于锁定保护Installd守护进程执行编译优化操作，在native层Installd守护进程中，线程需要持的互斥锁仅用于锁定保护所述Installd守护进程执行编译优化操作涉及的文件。这样，在应用进行编译优化时，线程无需持有全局锁，其他线程就无需等待应用编译完成后才可执行，减少了应用优化时的锁竞争问题。

Description

编译优化方法及电子设备

技术领域

本申请涉及智能终端技术领域，尤其涉及一种编译优化方法及电子设备。

背景技术

Dex2oat(dalvik excutable file to optimized art file)，是一个对dex(二进制字节码)文件进行编译优化的程序。Dex2oat编译工具是安卓运行时(Android Runtime，ART)中一个重要的模块。通过编译优化，可以提升用户对安卓(Android)手机的日常使用体验，例如应用安装速度、启动速度、应用使用过程中的流畅度等。

然而，在Dex2oat编译过程中，包管理服务(Package Manager Service，PMS)中的相关方法会一直持锁(mInstallLock)，从而使PMS中需要持锁的其他方法或操作由于等锁而无法执行，甚至可能出现由于长时间等锁而导致的***阻塞、***响应缓慢、ANR(Application Not Response，应用程序无响应)等问题。

发明内容

为了解决上述技术问题，本申请实施例提供一种编译优化方法及电子设备。在该方法中，在应用进行编译优化时，线程无需持有全局锁，而且持有独立的仅与编译优化相关的互斥锁，这样其他线程就无需等待应用编译完成后才可执行，减少了应用优化时的锁竞争问题。

第一方面，本申请实施例提供一种编译优化方法，应用于电子设备中，电子设备的***为安卓***，包括：

软件包管理服务PMS中第一线程申请持有PMS中的第一互斥锁，并在持有第一互斥锁之后，将编译优化任务提交至软件包安装器Installer；其中，第一互斥锁仅用于锁定保护Installd守护进程执行编译优化操作；

Installer中第二线程申请持有Installed守护进程中的第二互斥锁，并在持有第二互斥锁之后，请求Installed守护进程执行编译优化操作；其中，第二互斥锁仅用于锁定保护Installd守护进程执行编译优化操作涉及的文件。

示例性的，第一互斥锁为下文图6中java层PMS中的NewjavaLock锁，第二互斥锁为图7中native层Installd守护进程中的mDexOptLock锁。

这样，在java层PMS中，线程需要持的互斥锁仅用于锁定保护Installd守护进程执行编译优化操作，在native层Installd守护进程中，线程需要持的互斥锁仅用于锁定保护所述Installd守护进程执行编译优化操作涉及的文件。进而，在应用进行编译优化时，线程无需持有全局锁，其他线程就无需等待应用编译完成后才可执行，减少了应用优化时的锁竞争问题。

根据第一方面，PMS中还包括第三互斥锁，第三互斥锁用于锁定保护对Installd守护进程的访问，对Installd守护进程的访问不包括请求Installd守护进程执行编译优化操作；

Installed守护进程中还包括第四互斥锁，第四互斥锁用于锁定保护用于锁定保护Installd守护进程访问的文件，Installd守护进程访问的文件不包括Installd守护进程执行编译优化操作涉及的文件。

示例性的，第三互斥锁为下文图6中java层PMS中的mInstallLock锁，第四互斥锁为图7中native层Installd守护进程中的mLock锁。

这样，在java层PMS中第一互斥锁和第三互斥锁之间相互独立，在native层Installd守护进程中第二互斥锁和第四互斥锁之间相互独立，有效减少了应用优化时的锁竞争问题。

根据第一方面，或者以上第一方面的任意一种实现方式，在第一线程持有第一互斥锁之后，该方法还包括：PMS中第三线程申请持有第三互斥锁，并在持有第三互斥锁之后，执行相应的操作；其中，第三线程用于执行非编译优化操作。

这样，在java层，由于第一互斥锁和第三互斥锁是相互独立的，执行dexopt任务的线程长时间持锁也不会对其它执行非dexopt任务的线程产生影响，避免了其它执行非dexopt任务的线程由于长时间等锁而导致的线程阻塞问题。

根据第一方面，或者以上第一方面的任意一种实现方式，在第一线程持有第一互斥锁之后，该方法还包括：PMS中第四线程申请持有第一互斥锁，等待第一互斥锁；

在第四线程持有第一互斥锁之后，将编译优化任务提交至Installer；其中，第四线程用于执行编译优化任务。

根据第一方面，或者以上第一方面的任意一种实现方式，在第二线程持有第二互斥锁之后，该方法还包括：Installer中第五线程申请持有第四互斥锁，并在持有第四互斥锁之后，请求Installed守护进程执行相应的操作；其中，第五线程用于请求Installed守护进程执行非编译优化操作，且非编译优化操作涉及的文件与编译优化操作涉及的文件不存在冲突。

这样，在native层，由于第二互斥锁和第四互斥锁是相互独立的，执行dex2oat操作的线程长时间持锁也不会对其它执行非dex2oat操作(其操作的文件与dex2oat文件无关)的线程产生影响，避免了其它执行非dex2oat操作的线程由于长时间等锁而导致的线程阻塞问题。

根据第一方面，或者以上第一方面的任意一种实现方式，在第二线程持有第二互斥锁之后，该方法还包括：

Installer中第六线程申请持有第四互斥锁，并在持有第四互斥锁之后，申请持有第二互斥锁，等待第二互斥锁；在第六线程持有第二互斥锁之后，请求Installed守护进程执行相应的操作；其中，第六线程用于请求Installed守护进程执行非编译优化操作，且非编译优化操作涉及的文件与编译优化操作涉及的文件存在冲突。

这样，在native层，由于第二互斥锁和第四互斥锁是相互独立的，如果线程执行非dex2oat操作涉及的文件与线程执行dex2oat操作涉及的文件存在冲突，则执行非dex2oat操作的线程除了需要持有第四互斥锁，也需要持有第二互斥锁，能够确保dex2oat操作涉及的文件的同步性。而且，由于请求dex2oat操作的线程无需持有全局的第四互斥锁，不会出现长时间占用全局锁的现象。

根据第一方面，或者以上第一方面的任意一种实现方式，在第二线程持有第二互斥锁之后，该方法还包括：Installer中第七线程申请持有第二互斥锁，等待第二互斥锁；在第七线程持有第二互斥锁之后，请求Installed守护进程执行编译优化操作。

其中，第七线程请求Installd执行dex2oat操作，虽然该操作对应的dexoat文件与第二线程请求操作对应的dexoat文件不冲突，但是需要控制执行dex2oat的进程仅有一个，因此第七线程需要申请持有第二互斥锁。等待第二线程请求的dex2oat操作执行完成后，第二互斥锁被释放，线程6才可以在持有第二互斥锁后请求Installd继续执行dex2oat操作。

根据第一方面，或者以上第一方面的任意一种实现方式，在第二互斥锁空闲时，该方法还包括：

Installer中第八线程申请持有第四互斥锁，并在持有第四互斥锁之后，申请持有第二互斥锁；在第八线程持有第二互斥锁之后，请求Installed守护进程执行相应的操作；其中，第八线程用于请求Installed守护进程执行非编译优化操作，且非编译优化操作涉及的文件与编译优化操作涉及的文件存在冲突。

这样，针对第二互斥锁空闲的情况，如果请求Installed守护进程执行非编译优化操作的线程，其非编译优化操作涉及的文件与编译优化操作涉及的文件存在冲突，则该线程在可以申请到第四互斥锁之后直接获取到第二互斥锁，以继续执行相应的操作。

第二方面，本申请实施例提供一种电子设备。该电子设备包括：一个或多个处理器；存储器；以及一个或多个计算机程序，其中一个或多个计算机程序存储在存储器上，当计算机程序被一个或多个处理器执行时，使得电子设备执行第一方面以及第一方面中任意一项的编译优化方法。

第二方面以及第二方面的任意一种实现方式分别与第一方面以及第一方面的任意一种实现方式相对应。第二方面以及第二方面的任意一种实现方式所对应的技术效果可参见上述第一方面以及第一方面的任意一种实现方式所对应的技术效果，此处不再赘述。

第三方面，本申请实施例提供一种计算机可读存储介质。该计算机可读存储介质包括计算机程序，当计算机程序在电子设备上运行时，使得电子设备执行第一方面以及第一方面中任意一项的编译优化方法。

第三方面以及第三方面的任意一种实现方式分别与第一方面以及第一方面的任意一种实现方式相对应。第三方面以及第三方面的任意一种实现方式所对应的技术效果可参见上述第一方面以及第一方面的任意一种实现方式所对应的技术效果，此处不再赘述。

第四方面，本申请实施例提供一种计算机程序产品，包括计算机程序，当计算机程序被运行时，使得计算机执行如第一方面或第一方面中任意一项的编译优化方法。

第四方面以及第四方面的任意一种实现方式分别与第一方面以及第一方面的任意一种实现方式相对应。第四方面以及第四方面的任意一种实现方式所对应的技术效果可参见上述第一方面以及第一方面的任意一种实现方式所对应的技术效果，此处不再赘述。

第五方面，本申请提供了一种芯片，该芯片包括处理电路、收发管脚。其中，该收发管脚和该处理电路通过内部连接通路互相通信，该处理电路执行如第一方面或第一方面中任意一项的编译优化方法，以控制接收管脚接收信号，以控制发送管脚发送信号。

第五方面以及第五方面的任意一种实现方式分别与第一方面以及第一方面的任意一种实现方式相对应。第五方面以及第五方面的任意一种实现方式所对应的技术效果可参见上述第一方面以及第一方面的任意一种实现方式所对应的技术效果，此处不再赘述。

附图说明

图1为示例性示出的电子设备的硬件结构示意图；

图2为示例性示出的电子设备的软件结构示意图；

图3为示例性示出的一种安装应用的流程示意图；

图4为示例性示出的已有技术中应用编译优化时的持锁示意图；

图5为示例性示出的PMS中对java锁的竞争示意图；

图6为示例性示出的PMS中对java锁的拆锁示意图；

图7为示例性示出的Installd中对native锁的拆锁示意图；

图8为示例性示出的本申请实施例中应用编译优化时的持锁示意图；

图9为示例性示出的一种应用编译优化时的锁竞争示意图；

图10为示例性示出的一种应用编译优化时的锁竞争示意图；

图11为示例性示出的一种应用编译优化时的锁竞争示意图；

图12为示例性示出的一种应用编译优化时的锁竞争示意图；

图13为示例性示出的一种应用编译优化时的锁竞争示意图；

图14为示例性示出的一种应用编译优化时的锁竞争示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。

本申请实施例的说明书和权利要求书中的术语“第一”和“第二”等是用于区别不同的对象，而不是用于描述对象的特定顺序。例如，第一目标对象和第二目标对象等是用于区别不同的目标对象，而不是用于描述目标对象的特定顺序。

在本申请实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。

在本申请实施例的描述中，除非另有说明，“多个”的含义是指两个或两个以上。例如，多个处理单元是指两个或两个以上的处理单元；多个***是指两个或两个以上的***。

本申请实施例提供的方法可以应用于手机、平板电脑、可穿戴设备、车载设备、增强现实(augmented reality，AR)/虚拟现实(virtual reality，VR)设备、笔记本电脑、超级移动个人计算机(ultra-mobile personal computer，UMPC)、上网本、个人数字助理(personal digital assistant，PDA)等电子设备上，本申请实施例对电子设备的具体类型不作任何限制。

如图1所示为电子设备100的结构示意图。可选地，电子设备100可以为终端，也可以称为终端设备，本申请不做限定。应该理解的是，图1所示的电子设备100仅是电子设备的一个范例，并且电子设备100可以具有比图中所示的更多的或者更少的部件，可以组合两个或多个的部件，或者可以具有不同的部件配置。图1中所示出的各种部件可以在包括一个或多个信号处理和/或专用集成电路在内的硬件、软件、或硬件和软件的组合中实现。

电子设备100可以包括：处理器110，外部存储器接口120，内部存储器121，通用串行总线(universal serial bus，USB)接口130，充电管理模块140，电源管理模块141，电池142，天线1，天线2，移动通信模块150，无线通信模块160，音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，传感器模块180，按键190，马达191，指示器192，摄像头193，显示屏194，以及用户标识模块(subscriber identification module，SIM)卡接口195等。其中传感器模块180可以包括压力传感器，陀螺仪传感器，加速度传感器，温度传感器，运动传感器，气压传感器，磁传感器，距离传感器，接近光传感器，指纹传感器，触摸传感器，环境光传感器，骨传导传感器等。

处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processingunit，GPU)，图像信号处理器(image signal processor，ISP)，控制器，存储器，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器(neural-network processing unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。

其中，控制器可以是电子设备100的神经中枢和指挥中心。控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。

处理器110中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器110中的存储器为高速缓冲存储器。

USB接口130是符合USB标准规范的接口，具体可以是Mini USB接口，Micro USB接口，USB Type C接口等。USB接口130可以用于连接充电器为电子设备100充电，也可以用于电子设备100与***设备之间传输数据。也可以用于连接耳机，通过耳机播放音频。该接口还可以用于连接其他电子设备，例如AR设备等。

充电管理模块140用于从充电器接收充电输入。其中，充电器可以是无线充电器，也可以是有线充电器。在一些有线充电的实施例中，充电管理模块140可以通过USB接口130接收有线充电器的充电输入。在一些无线充电的实施例中，充电管理模块140可以通过电子设备100的无线充电线圈接收无线充电输入。充电管理模块140为电池142充电的同时，还可以通过电源管理模块141为电子设备供电。

电源管理模块141用于连接电池142，充电管理模块140与处理器110。电源管理模块141接收电池142和/或充电管理模块140的输入，为处理器110，内部存储器121，外部存储器，显示屏194，摄像头193，和无线通信模块160等供电。

电子设备100的无线通信功能可以通过天线1，天线2，移动通信模块150，无线通信模块160，调制解调处理器以及基带处理器等实现。

天线1和天线2用于发射和接收电磁波信号。电子设备100中的每个天线可用于覆盖单个或多个通信频带。不同的天线还可以复用，以提高天线的利用率。例如：可以将天线1复用为无线局域网的分集天线。在另外一些实施例中，天线可以和调谐开关结合使用。

移动通信模块150可以提供应用在电子设备100上的包括2G/3G/4G/5G等无线通信的解决方案。移动通信模块150可以包括至少一个滤波器，开关，功率放大器，低噪声放大器(low noise amplifier，LNA)等。

无线通信模块160可以提供应用在电子设备100上的包括无线局域网(wirelesslocal area networks，WLAN)(如无线保真(wireless fidelity，Wi-Fi)网络)，蓝牙(bluetooth，BT)，全球导航卫星***(global navigation satellite system，GNSS)，调频(frequency modulation，FM)，近距离无线通信技术(near field communication，NFC)，红外技术(infrared，IR)等无线通信的解决方案。

在一些实施例中，电子设备100的天线1和移动通信模块150耦合，天线2和无线通信模块160耦合，使得电子设备100可以通过无线通信技术与网络以及其他设备通信。

电子设备100通过GPU，显示屏194，以及应用处理器等实现显示功能。GPU为图像处理的微处理器，连接显示屏194和应用处理器。GPU用于执行数学和几何计算，用于图形渲染。处理器110可包括一个或多个GPU，其执行程序指令以生成或改变显示信息。

显示屏194用于显示图像，视频等。显示屏194包括显示面板。在一些实施例中，电子设备100可以包括1个或N个显示屏194，N为大于1的正整数。

电子设备100可以通过ISP，摄像头193，视频编解码器，GPU，显示屏194以及应用处理器等实现拍摄功能。

ISP用于处理摄像头193反馈的数据。例如，拍照时，打开快门，光线通过镜头被传递到摄像头感光元件上，光信号转换为电信号，摄像头感光元件将所述电信号传递给ISP处理，转化为肉眼可见的图像。ISP还可以对图像的噪点，亮度，肤色进行算法优化。ISP还可以对拍摄场景的曝光，色温等参数优化。在一些实施例中，ISP可以设置在摄像头193中。

摄像头193用于捕获静态图像或视频。物体通过镜头生成光学图像投射到感光元件。感光元件可以是电荷耦合器件(charge coupled device，CCD)或互补金属氧化物半导体(complementary metal-oxide-semiconductor，CMOS)光电晶体管。感光元件把光信号转换成电信号，之后将电信号传递给ISP转换成数字图像信号。ISP将数字图像信号输出到DSP加工处理。DSP将数字图像信号转换成标准的RGB，YUV等格式的图像信号。在一些实施例中，电子设备100可以包括1个或N个摄像头193，N为大于1的正整数。

外部存储器接口120可以用于连接外部存储卡，例如Micro SD卡，实现扩展电子设备100的存储能力。外部存储卡通过外部存储器接口120与处理器110通信，实现数据存储功能。

内部存储器121可以用于存储计算机可执行程序代码，所述可执行程序代码包括指令。处理器110通过运行存储在内部存储器121的指令，从而执行电子设备100的各种功能应用以及数据处理，例如使得电子设备100实现本申请实施例中的编译方法。内部存储器121可以包括存储程序区和存储数据区。其中，存储程序区可存储操作***，至少一个功能所需的应用程序(比如声音播放功能，图像播放功能等)等。存储数据区可存储电子设备100使用过程中所创建的数据(比如音频数据，电话本等)等。此外，内部存储器121可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件，闪存器件，通用闪存存储器(universal flash storage，UFS)等。

电子设备100可以通过音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，以及应用处理器等实现音频功能。例如音乐播放，录音等。

音频模块170用于将数字音频信息转换成模拟音频信号输出，也用于将模拟音频输入转换为数字音频信号。音频模块170还可以用于对音频信号编码和解码。在一些实施例中，音频模块170可以设置于处理器110中，或将音频模块170的部分功能模块设置于处理器110中。

扬声器170A，也称“喇叭”，用于将音频电信号转换为声音信号。电子设备100可以通过扬声器170A收听音乐，或收听免提通话。在一些实施例中，电子设备100可以设置多个扬声器170A。

受话器170B，也称“听筒”，用于将音频电信号转换成声音信号。当电子设备100接听电话或语音信息时，可以通过将受话器170B靠近人耳接听语音。

麦克风170C，也称“话筒”，“传声器”，用于将声音信号转换为电信号。当拨打电话或发送语音信息时，用户可以通过人嘴靠近麦克风170C发声，将声音信号输入到麦克风170C。电子设备100可以设置至少一个麦克风170C。在另一些实施例中，电子设备100可以设置两个麦克风170C，除了采集声音信号，还可以实现降噪功能。在另一些实施例中，电子设备100还可以设置三个，四个或更多麦克风170C，实现采集声音信号，降噪，还可以识别声音来源，实现定向录音功能等。

耳机接口170D用于连接有线耳机。耳机接口170D可以是USB接口130，也可以是3.5mm的开放移动电子设备平台(open mobile terminal platform，OMTP)标准接口，美国蜂窝电信工业协会(cellular telecommunications industry association of the USA，CTIA)标准接口。

压力传感器用于感受压力信号，可以将压力信号转换成电信号。在一些实施例中，压力传感器可以设置于显示屏194。电子设备100也可以根据压力传感器的检测信号计算触摸的位置。

陀螺仪传感器可以用于确定电子设备100的运动姿态。在一些实施例中，可以通过陀螺仪传感器确定电子设备100围绕三个轴(即，x，y和z轴)的角速度。

加速度传感器可检测电子设备100在各个方向上(一般为三轴)加速度的大小。当电子设备100静止时加速度传感器可检测出重力的大小及方向。加速度传感器还可以用于识别电子设备姿态，应用于横竖屏切换，计步器等应用。

触摸传感器，也称“触控面板”。触摸传感器可以设置于显示屏194，由触摸传感器与显示屏194组成触摸屏，也称“触控屏”。触摸传感器用于检测作用于其上或附近的触摸操作。触摸传感器可以将检测到的触摸操作传递给应用处理器，以确定触摸事件类型。

按键190包括开机键(或称电源键)，音量键等。按键190可以是机械按键。也可以是触摸式按键。电子设备100可以接收按键输入，产生与电子设备100的用户设置以及功能控制有关的键信号输入。

马达191可以产生振动提示。马达191可以用于来电振动提示，也可以用于触摸振动反馈。例如，作用于不同应用(例如拍照，音频播放等)的触摸操作，可以对应不同的振动反馈效果。

指示器192可以是指示灯，可以用于指示充电状态，电量变化，也可以用于指示消息，未接来电，通知等。

电子设备100的软件***可以采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构。本申请实施例以分层架构的Android***为例，示例性说明电子设备100的软件结构。

图2是本申请实施例的电子设备100的软件结构框图。

电子设备100的分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，将Android***分为四层，从上至下分别为应用程序层，应用程序框架层，安卓运行时(Android Runtime)和***库，以及内核层。

应用程序层可以包括一系列应用程序包。

如图2所示，应用程序包可以包括相机，图库，日历，通话，地图，导航，WLAN，蓝牙，音乐，视频，短信息等应用程序。

应用程序框架层为应用程序层的应用程序提供应用编程接口(applicationprogramming interface，API)和编程框架。应用程序框架层包括一些预先定义的函数。

如图2所示，应用程序框架层可以包括软件包管理器(Package Manager Service，PMS)，窗口管理器，内容提供器，视图***，资源管理器，通知管理器等。

PMS主要用于管理应用的安装、卸载、更新、解析以及权限等过程。其中，PMS运行过程中会经常调用Package Installer(或称Installer)(应用安装器或者软件包安装)执行具体的操作，Installer会再次调用Native层执行安装解析等操作。

窗口管理器用于管理窗口程序。窗口管理器可以获取显示屏大小，判断是否有状态栏，锁定屏幕，截取屏幕等。

内容提供器用来存放和获取数据，并使这些数据可以被应用程序访问。所述数据可以包括视频，图像，音频，拨打和接听的电话，浏览历史和书签，电话簿等。

视图***包括可视控件，例如显示文字的控件，显示图片的控件等。视图***可用于构建应用程序。显示界面可以由一个或多个视图组成的。例如，包括短信通知图标的显示界面，可以包括显示文字的视图以及显示图片的视图。

资源管理器为应用程序提供各种资源，比如本地化字符串，图标，图片，布局文件，视频文件等等。

通知管理器使应用程序可以在状态栏中显示通知信息，可以用于传达告知类型的消息，可以短暂停留后自动消失，无需用户交互。比如通知信息被用于告知下载完成，消息提醒等。通知信息还可以是以图表或者滚动条文本形式出现在***顶部状态栏的通知，例如后台运行的应用程序的通知，还可以是以对话窗口形式出现在屏幕上的通知。通知信息还例如可以是在状态栏提示的文本信息，发出的提示音，电子设备的振动，指示灯闪烁等。

Android Runtime包括核心库和虚拟机。Android Runtime负责安卓***的调度和管理。

核心库包含两部分：一部分是java语言需要调用的功能函数，另一部分是安卓的核心库。

应用程序层和应用程序框架层运行在虚拟机中。虚拟机将应用程序层和应用程序框架层的java文件执行为二进制文件。虚拟机用于执行对象生命周期的管理，堆栈管理，线程管理，安全和异常的管理，以及垃圾回收等功能。

***库可以包括多个功能模块。例如：Installd守护进程，表面管理器(surfacemanager)，媒体库(Media Libraries)，三维图形处理库(例如：OpenGL ES)，2D图形引擎(例如：SGL)等。

其中，Installd守护进程是一个native进程，其功能为启动一个socket，处理来自Installer的命令。

表面管理器用于对显示子***进行管理，并且为多个应用程序提供了2D和3D图层的融合。

媒体库支持多种常用的音频，视频格式回放和录制，以及静态图像文件等。媒体库可以支持多种音视频编码格式，例如：MPEG4，H.264，MP3，AAC，AMR，JPG，PNG等。

三维图形处理库用于实现三维图形绘图，图像渲染，合成，和图层处理等。

2D图形引擎是2D绘图的绘图引擎。

内核层是硬件和软件之间的层。内核层至少包含显示驱动，摄像头驱动，存储驱动，传感器驱动等。其中，硬件至少包括处理器，显示屏，摄像头，传感器等。

可以理解的是，图2示出的软件结构中的层以及各层中包含的部件，并不构成对电子设备100的具体限定。在本申请另一些实施例中，电子设备100可以包括比图示更多或更少的层，以及每个层中可以包括更多或更少的部件，本申请不做限定。

可以理解的是，电子设备为了实现本申请实施例中的编译方法，其包含了执行各个功能相应的硬件和/或软件模块。结合本文中所公开的实施例描述的各示例的算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。本领域技术人员可以结合实施例对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

为了便于理解，本申请以下实施例将以具有图1和图2所示结构的电子设备为例，结合附图和应用场景，对本申请实施例提供的编译方法进行具体阐述。

在描述本申请实施例的安装应用的方法之前，首先对本申请实施例中的术语做简单的介绍。

1、Android应用程序包(Application Package，APK)：是Android操作***使用的一种应用程序包文件格式，用于分发和安装移动应用及中间件。一个Android应用程序的代码想要在Android设备上运行，必须先进行编译，然后被打包成为一个被Android***所能识别的文件才可以被运行，而这种能被Android***识别并运行的文件格式便是“APK”。APK由xml、资源文件、dex文件组合而成。

2、dexopt线程：用于执行dexopt任务，dexopt是对dex文件进行验证和优化的过程，生成可执行的odex文件。该过程可以提升应用启动和组件加载性能。

3、dex2oat线程：用于执行dex2oat工作任务，dex2oat是对APK文件进行编译优化，生成oat文件的过程。oat文件是一种Android私有(Executable and Linkable Format，可执行与可链接格式)文件格式，它不仅包含有从dex文件翻译而来的本地机器指令，还包含有原来的dex文件内容。对于APK来说，oat文件实际上是对odex文件的包装。

4、互斥锁(lock_guard)：是一种在作用域内控制可锁对象所有权的类型，是保证同一时间内只有一个线程访问某一方法或变量的一种机制。在Java等面向对象的语言中，当一个线程访问被同步的代码时，必须获取该代码所属的互斥锁，否则该线程将阻塞，直到该对象锁被释放。互斥锁，即最多只有一个线程能够获得该锁，当线程A尝试去获得线程B持有的互斥锁时，线程A必须等待或者阻塞，直到线程B释放这个锁后，线程A才能够获取该互斥锁访问相应的方法或变量。

需要指出的是，下述提及的以各种英文字符串命名的锁均指的是互斥锁。

图3是本申请实施例提供的一种安装应用的流程示意图。以基于安卓(Android)***的电子装置为例，电子装置通过Package Installer的接口来安装应用。如图3所示，安装应用的流程具体包括如下步骤：

S101，应用程序层创建应用安装的任务。

S102，应用程序层将任务提交到应用框架层中的PMS中，由PMS进行应用的安装。

S103，PMS安装应用。

PMS安装应用时会从应用的下载目录中将应用的APK文件拷贝到***目录中，并扫描该APK文件，通过扫描过程对该APK文件进行解析，以获取应用的组件、配置文件等信息。

S104，PMS向Installer提交dexopt任务。

PMS向Installer提交dexopt任务时，dexopt线程需要持有java层的mInstallLock锁。mInstallLock锁，用于保护所有对Installd接口的访问。在当前dexopt任务未完成时，mInstallLock锁阻止其他dexopt任务进行，以及阻止其他需要持mInstallLock锁的其他操作或方法进行。

S105，Installer请求Installd守护进程执行dexopt任务。

Installer提供Java API接口，与Installd守护进程进行Binder通信(android8.1.0以前是通过Socket通信)。Installer作为客户端，由位于Nativie层的Installd守护进程来完成具体的操作。

其中，Installer请求Installd守护进程执行dexopt任务时，相应的线程需要持有native层的全局锁mLock。mLock锁，用于保护Installd守护进程访问的所有文件数据。在当前dexopt任务未完成时，mLock锁阻止其他需要持mLock锁的其他操作或方法进行。

S106，Installd守护进程调用dex2oat线程执行dex2oat操作。

Installd在执行dexopt任务时，通过内部调用dex2oat线程对APK文件进行二进制优化，以提升应用启动速度和组件加载性能。

S107，Installd守护进程向Installer发送dex2oat线程执行结束的消息。

待dex2oat线程执行完dex2oat操作时，Installer释放mLock锁。

S108，Installer向PMS发送dexopt任务执行完成的消息。

dexopt任务执行完成时，dexopt线程释放mInstallLock锁。

S109，PMS向应用程序层发送应用安装完成的消息。

本流程未尽详细解释之处可以参照已有技术，在此不再赘述。

上述流程以安装新应用为例，阐述了dex2oat操作涉及的场景。除此之外，dex2oat操作涉及的场景还包括应用首次启动、应用升级更新等。其中，dex2oat操作可能是由用户的操作(如安装应用的操作)触发的，也可能是由***自动(如应用自动更新)触发的。

通过上述流程可知，为了实现dex2oat操作，如图4所示，在PMS中dexopt任务需要持有java层的mInstallLock锁，在Installd守护进程中dex2oat线程需要持有native层的mLock锁。由于dex2oat操作是计算量和输入输出(IO)量比较大的操作，则dex2oat线程的执行时间会较长，进而java层的mInstallLock锁和native层的mLock锁被持有的时间就会较长。进而，此时若其他线程需要使用java层的mInstallLock锁或native层的mLock锁时，则需要阻塞等待，但可能出现长时间无法获取到锁导致***阻塞，发生***响应慢，ANR等问题，从而影响用户的使用体验。

如图5所示，PMS中很多应用接口(API Implement)和内部方法函数(InternalMethod)对应的线程需要持有java层的mInstallLock锁才能继续执行。因此，若dexopt任务持有mInstallLock锁的时间过长，则会导致PMS中的其它线程等锁的时间过长，而影响用户使用体验。示例性的，需要持锁的API Implement可以是卸载应用的API Implement、清除应用数据的API Implement等，内部方法函数可以是在切换隐私空间时或在创建应用分身时准备数据的方法函数等。

在一种可能的应用场景中，若A应用正在执行dex2oat操作，则此时java层的mInstallLock锁和native层的mLock锁被持有。只有A应用的dex2oat操作完成之后，则java层的mInstallLock锁和native层的mLock锁才会被释放。在A应用正在执行dex2oat操作的过程中，如果用户在设置页面中执行清除B应用用户数据的操作，则只有在A应用的dex2oat操作完成之后***才会响应该数据清除操作。假设A应用的耗时为20秒，则在20秒之后***才会响应B应用的数据清除操作，用户看到B应用数据清除成功的耗时就很长，例如为21秒。

在一种可能的应用场景中，在A应用正在执行dex2oat操作的过程中，如果用户执行卸载C应用的操作，则只有在A应用的dex2oat操作完成之后***才会响应卸载C应用的操作。

在一种可能的应用场景中，在A应用正在执行dex2oat操作的过程中，如果用户执行切换隐私空间的操作，则只有在A应用的dex2oat操作完成之后***才会响应切换隐私空间的操作。

在一种可能的应用场景中，在A应用正在执行dex2oat操作的过程中，如果用户执行创建与D应用对应的分身应用的操作，则只有在A应用的dex2oat操作完成之后***才会响应创建分身应用的操作。

在一种可能的应用场景中，在A应用正在执行dex2oat操作的过程中，如果用户执行安装E应用的操作，则只有在A应用的dex2oat操作完成之后***才会响应安装E应用的操作。

需要指出的是，上述应用场景仅仅是示例性的解释说明。当任一应用执行dex2oat操作的过程中，只要其他线程需要持java层的mInstallLock锁才能继续执行时，则该线程就需要待A应用的dex2oat操作完成之后才能被响应。

这样，java层的mInstallLock锁无疑会成为PMS中的一个瓶颈，在java层中出现针对mInstallLock锁的锁竞争问题。

类似的，当任一应用执行dex2oat操作的过程中，只要其他线程需要持native层的mLock锁才能继续执行时，则该线程就需要待A应用的dex2oat操作完成之后才能被响应。这样，native层的mLock锁也会成为Installd中的一个瓶颈，在native层中出现针对mLock锁的锁竞争问题。

为了减少应用优化时的锁竞争问题，本申请实施例分别在java层和native层将用于编译优化的锁在全局锁中拆分开来，通过在java层中预先定义一个NewjavaLock锁，用于锁定保护Installd守护进程执行dex2oat，以及在native层预先定义一个mDexOptLock锁，用于锁定保护Installd守护进程执行dex2oat涉及的文件。

这样，执行dex2oat操作，只需要在java层申请新增的NewjavaLock锁，以及在native层新增的mDexOptLock锁。由此，dex2oat操作不会再长时间占用原有的java层全局锁和native层全局锁，减少了应用优化时的锁竞争问题。

需要指出的是，新增的NewjavaLock锁以及mDexOptLock锁的名称仅仅是示例性的命名，本申请实施例对此不做限定。

如图6所示，在java层，PMS中至少包括mInstallLock锁和NewjavaLock锁。mInstallLock锁和NewjavaLock锁之间是彼此独立的。

其中，mInstallLock锁用于锁定保护对Installd守护进程的访问，不再对Installd守护进程执行dex2oat业务进行锁定保护，而NewjavaLock锁仅用于对Installd守护进程执行dex2oat业务进行锁定保护。

需要指出的是，为了尽量减少对安卓***已有设计的修改，此处依旧使用“mInstallLock”来标识用于对访问Installd守护进程进行保护的锁。区别于已有技术中的mInstallLock锁，图6所示的mInstallLock锁不再用于对Installd守护进程执行dex2oat业务进行锁定保护。

其中，关于NewjavaLock锁和mInstallLock锁的定义方式，可以参照已有技术关于互斥锁的定义方式，在此不再赘述。

当PMS向Installer提交dexopt任务时，dexopt线程只需申请持有NewjavaLock锁；而其他API Implement和Internal Method在执行时只需申请持有mInstallLock锁。这样，dexopt线程长时间持有NewjavaLock锁，也不会对其它其他API Implement和InternalMethod的执行产生影响。

如图7所示，在native层，Install守护进程中至少包括mLock锁和mDexOptLock锁。mLock锁和mDexOptLock锁之间是彼此独立的。

其中，mLock锁用于锁定保护Installd守护进程访问的文件，该文件不包括Installd守护进程执行dex2oat业务涉及的文件；而mDexOptLock锁仅用于对Installd守护进程执行dex2oat业务涉及的文件进行锁定保护。

需要指出的是，为了尽量减少对安卓***已有设计的修改，此处依旧使用“mLock”来标识用于对Installd守护进程访问文件进行保护的锁。区别于已有技术中的mLock锁，图7所示的mLock锁不再用于对Installd守护进程执行dex2oat业务涉及的文件进行锁定保护。

其中，关于mLock锁和mDexOptLock锁的定义方式，可以参照已有技术中关于互斥锁的定义方式，在此不再赘述。

当线程向Installd守护进程请求的操作非dex2oat操作，且不对dex2oat涉及的文件的进行操作时，该线程只需申请持有mLock锁。在此情形下，该线程操作与dex2oat线程操作的文件不存在冲突。

例如，线程1请求Installd守护进程执行对抖音应用的dex2oat的操作，操作的文件目录为/data/apk/抖音目录；线程2请求Installd守护进程执行对淘宝应用的缓存数据清除操作，操作的文件目标为data/user_de/0/淘宝目录。此时，线程2请求的操作非dex2oat操作，且该操作的文件与dex2oat线程操作的文件不存在冲突，线程2只需申请持有mLock锁。

当线程向Installd守护进程请求的操作为dex2oat操作时，该线程只需申请持有mDexOptLock锁。

例如，线程3请求Installd守护进程执行对抖音应用的dex2oat的操作，线程3只需申请持有mDexOptLock锁。

再例如，线程3请求Installd守护进程执行对抖音应用的dex2oat的操作，线程3持有mDexOptLock锁。当线程4也请求Installd守护进程执行对淘宝应用的dex2oat的操作，线程4也申请持有mDexOptLock锁。此时由于mDexOptLock锁被线程3持有，线程4无法申请到mDexOptLock锁。待对抖音应用的dex2oat的操作完成之后，线程3释放mDexOptLock锁，线程4才可以申请到mDexOptLock锁。

当线程向Installd守护进程请求的操作非dex2oat操作，但需要对dex2oat操作涉及的文件的进行操作时，该线程首先要申请持有mLock锁然后要申请持有mDexOptLock锁。

例如，线程1请求Installd守护进程执行对抖音应用的dex2oat的操作，操作的文件目录为/data/apk/抖音目录；线程2请求Installd守护进程执行其他操作，操作的文件目录也为/data/apk/抖音目录。此时，线程2请求的操作虽然非dex2oat操作，但该操作的文件与dex2oat线程操作的文件存在冲突，则线程2除了要申请持有mLock锁，还要申请持有mDexOptLock锁。

此处，请求Installd守护进程执行其他操作的线程，仍然保持AOSP的原始逻辑，需要持有mLock的全局锁。本申请实施例是为了减少对应用优化时的锁竞争，dex2oat操作长时间持锁是问题所在。因此，当其他线程操作的文件与dex2oat操作的文件是同一组文件时，这些线程除了要申请持有mLock锁，还要额外申请持有mDexOptLock锁。

下述结合图8对电子设备执行dex2oat操作涉及的持锁情形进行解释说明。如图8所示，PMS向Installer提交dexopt任务，dexopt线程仅需要持有java层的NewjavaLock锁，以对Installd守护进程执行dex2oat业务进行锁定保护。Installer请求Installd守护进程执行dexopt任务，相应的线程仅需要持有native层中的mDexOptLock锁，以对Installd守护进程执行dex2oat涉及的文件进行锁定保护。进而，Installd守护进程即可调用dex2oat线程完成编译优化操作。待dex2oat线程执行完dex2oat操作时，Installer释放mDexOptLock锁，待dexopt任务执行完成时，dexopt线程释放NewjavaLock锁。

下面结合几种可能的使用场景，对应用编译优化时多个并行线程之间的锁竞争情况进行解释说明。

场景一

在本场景中，针对应用编译优化时java层PMS中的锁竞争问题进行解释说明。

在一种可能的情形中，如图9所示，在java层，PMS中线程1执行dexopt任务1，仅需要持有NewjavaLock锁。在线程1持有NewjavaLock锁执行dexopt任务1的过程中，线程2启动。例如，线程2用于执行dexopt任务2。在NewjavaLock锁被线程1持有的过程中，线程2处于等待NewjavaLock锁的状态，待线程1将NewjavaLock锁释放后，线程2申请持有NewjavaLock锁，并在持有NewjavaLock锁之后执行dexopt任务2。

在一种可能的情形中，如图10所示，在java层，PMS中线程1执行dexopt任务1，仅需要持有NewjavaLock锁。在线程1持有NewjavaLock锁执行dexopt任务1的过程中，线程3启动。其中，线程3用于执行非dexopt任务的其他方法任务，例如为卸载应用的任务、清除数据的任务等。线程3启动后，申请持有全局的mInstallLock锁，并在持有mInstallLock锁之后执行相应的方法任务。

这样，在java层，由于NewjavaLock锁和mInstallLock锁是相互独立的，执行dexopt任务的线程长时间持锁也不会对其它执行非dexopt任务的线程产生影响，避免了其它执行非dexopt任务的线程由于长时间等锁而导致的线程阻塞问题。

需要说明的是，某个线程是否用于执行dexopt任务是编程人员已知的，故线程在运行时是仅需要申请持有java层中mInstallLock锁，还是仅需要申请持有NewjavaLock锁，是预先定义的。线程启动后仅需根据预定义信息申请相应的锁即可。

场景二

在本场景中，针对应用编译优化时native层Installd中的锁竞争问题进行解释说明。

在一种可能的情形中，如图11所示，在native层，线程4请求Installd执行dex2oat，仅需要持有mDexOptLock锁。在线程4持有mDexOptLock锁执行dex2oat的过程中，线程5启动。其中，线程5用于执行非dex2oat的其他操作，例如为操作文件等。假设线程5操作的文件与线程4操作的文件不存在冲突，则线程5启动后，可以仅申请持有全局mLock锁，并在持有mLock锁之后执行相应的操作。

关于线程执行非dex2oat操作涉及的文件与线程执行dex2oat操作涉及的文件是否存在冲突，可以参照前文示例，在此不再赘述。

这样，在native层，由于mDexOptLock锁和mLock锁是相互独立的，执行dex2oat操作的线程长时间持锁也不会对其它执行非dex2oat操作(其操作的文件与dex2oat文件无关)的线程产生影响，避免了其它执行非dex2oat操作的线程由于长时间等锁而导致的线程阻塞问题。

在一种可能的情形中，如图12所示，在native层，线程4请求Installd执行dex2oat1操作，仅需要持有mDexOptLock锁。在线程4持有mDexOptLock锁执行dex2oat的过程中，线程6启动。其中，线程6用于请求Installd执行dex2oat2。在mDexOptLock锁被线程4持有的过程中，线程6处于等待mDexOptLock锁的状态，待线程4将mDexOptLock锁释放后，线程6申请持有mDexOptLock锁，并在持有mDexOptLock锁之后请求Installd执行dex2oat2操作。

需要指出的是，若mDexOptLock锁处于空闲状态时，用于请求Installd执行dex2oat操作的线程可以直接申请到mDexOptLock锁，此时不存在锁竞争。

线程6请求Installd执行dex2oat2操作，虽然其操作的dexoat文件与线程4操作的dexoat文件不冲突，但是需要控制执行dex2oat的进程仅有一个，因此线程6需要申请持有mDexOptLock锁。等待线程4请求的dex2oat操作执行完成后，mDexOptLock锁被释放，线程6才可以在持有mDexOptLock锁后请求Installd继续执行dex2oat2操作。

在一种可能的情形中，如图13所示，在native层，线程4请求Installd执行dex2oat1操作，仅需要持有mDexOptLock锁。在线程4持有mDexOptLock锁执行dex2oat的过程中，线程7启动。其中，线程7用于执行非dex2oat的其他操作，例如为操作文件等。假设线程7操作的文件与线程4操作的文件存在冲突，则线程7启动后，不仅需要申请持有全局mLock锁，还需要在持有mLock锁后继续申请持有mDexOptLock锁，并在持有mDexOptLock锁后执行相应的操作。

示例性的，线程7用于操作文件。此处线程7仍然保持AOSP的原始逻辑，首先需要持有mLock的全局锁。这样能够尽量避免对安卓***原有设计的破坏。但是，在线程7需要操作的文件与线程4操作的文件是同一组文件时，也即线程7执行非dex2oat操作涉及的文件与线程4执行dex2oat操作涉及的文件存在冲突时，线程7还要额外请求mDexOptLock锁，等待线程4结束释放mDexOptLock锁后才能继续执行操作文件的动作。

关于线程执行非dex2oat操作涉及的文件与线程执行dex2oat操作涉及的文件是否存在冲突，可以参照前文示例，在此不再赘述。

这样，在native层，由于mDexOptLock锁和mLock锁是相互独立的，如果线程执行非dex2oat操作涉及的文件与线程执行dex2oat操作涉及的文件存在冲突，则执行非dex2oat操作的线程除了需要持有mLock锁，也需要持有mDexOptLock锁，能够确保dex2oat操作涉及的文件的同步性。而且，由于请求dex2oat操作的线程无需持有全局的mLock锁，不会出现长时间占用mLock全局锁的现象。

除了以上场景，还有一种情形：请求非dex2oat操作的线程早于请求dex2oat操作的线程启动，此时同样要控制dex2oat操作时不能与正在操作的文件存在冲突。

如图14所示，在native层，线程8首先执行，但并不是用于请求Installd执行dex2oat，而是执行操作文件的相关函数。此时，线程8首先按照AOSP的逻辑，会首先请求并持有mLock锁。假设线程8请求的操作涉及的文件与dex2oat操作涉及的文件有关，则线程8还需要同时申请持有mDexOptLock锁。在当前***中不存在其他线程持有mDexOptLock锁时，线程8可以直接申请到mDexOptLock锁，进而可以执行相应的文件操作。

在线程8持有mDexOptLock锁的过程中，假设线程9启动。其中，线程9用于请求Installd执行dex2oat操作。在mDexOptLock锁被线程8持有的过程中，线程9处于等待mDexOptLock锁的状态，待线程8将mDexOptLock锁释放后，线程9申请持有mDexOptLock锁，并在持有mDexOptLock锁之后请求Installd执行dex2oat操作。

假设线程8请求的操作涉及的文件与dex2oat操作涉及的文件无关，则线程8在持有mLock锁后，即可继续执行相关操作。

需要说明的是，某个线程是否用于请求Installd执行dex2oat，线程涉及的操作是否与dex2oat操作涉及的文件有关是编程人员已知的，故线程在运行时是仅需要申请持有native层中mDexOptLock锁，还是仅需申请持有native层中的mLock全局锁，还是既需要申请native层中的mLock全局锁又需要申请mDexOptLock锁，是预先定义的。线程启动后仅需根据预定义信息申请相应的锁即可。

本实施例还提供一种计算机存储介质，该计算机存储介质中存储有计算机指令，当该计算机指令在电子设备上运行时，使得电子设备执行上述相关方法步骤实现上述实施例中的编译优化方法。

本实施例还提供了一种计算机程序产品，当该计算机程序产品在计算机上运行时，使得计算机执行上述相关步骤，以实现上述实施例中的编译优化方法。

另外，本申请的实施例还提供一种装置，这个装置具体可以是芯片，组件或模块，该装置可包括相连的处理器和存储器；其中，存储器用于存储计算机执行指令，当装置运行时，处理器可执行存储器存储的计算机执行指令，以使芯片执行上述各方法实施例中的编译优化方法。

其中，本实施例提供的电子设备(如手机等)、计算机存储介质、计算机程序产品或芯片均用于执行上文所提供的对应的方法，因此，其所能达到的有益效果可参考上文所提供的对应的方法中的有益效果，此处不再赘述。

通过以上实施方式的描述，所属领域的技术人员可以了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个装置，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (9)

1.一种编译优化方法，其特征在于，应用于电子设备中，所述电子设备的***为安卓***，包括：

软件包管理服务PMS中第一线程申请持有所述PMS中的第一互斥锁，并在持有所述第一互斥锁之后，将编译优化任务提交至软件包安装器Installer；其中，所述第一互斥锁仅用于锁定保护Installd守护进程执行编译优化操作；

Installer中第二线程申请持有Installed守护进程中的第二互斥锁，并在持有所述第二互斥锁之后，请求所述Installed守护进程执行编译优化操作；其中，所述第二互斥锁仅用于锁定保护所述Installd守护进程执行编译优化操作涉及的文件；

其中，所述PMS中还包括第三互斥锁，所述第三互斥锁用于锁定保护对Installd守护进程的访问，所述对Installd守护进程的访问不包括请求Installd守护进程执行编译优化操作；

所述Installed守护进程中还包括第四互斥锁，所述第四互斥锁用于锁定保护用于锁定保护所述Installd守护进程访问的文件，所述Installd守护进程访问的文件不包括所述Installd守护进程执行编译优化操作涉及的文件。

2.根据权利要求1所述的方法，其特征在于，在所述第一线程持有所述第一互斥锁之后，还包括：

所述PMS中第三线程申请持有所述第三互斥锁，并在持有所述第三互斥锁之后，执行相应的操作；其中，所述第三线程用于执行非编译优化操作。

3.根据权利要求1所述的方法，其特征在于，在所述第一线程持有所述第一互斥锁之后，还包括：

所述PMS中第四线程申请持有所述第一互斥锁，等待所述第一互斥锁；

在所述第四线程持有所述第一互斥锁之后，将编译优化任务提交至所述Installer；其中，所述第四线程用于执行编译优化任务。

4.根据权利要求1所述的方法，其特征在于，在所述第二线程持有所述第二互斥锁之后，还包括：

所述Installer中第五线程申请持有所述第四互斥锁，并在持有所述第四互斥锁之后，请求所述Installed守护进程执行相应的操作；其中，所述第五线程用于请求所述Installed守护进程执行非编译优化操作，且所述非编译优化操作涉及的文件与编译优化操作涉及的文件不存在冲突。

5.根据权利要求1所述的方法，其特征在于，在所述第二线程持有所述第二互斥锁之后，还包括：

所述Installer中第六线程申请持有所述第四互斥锁，并在持有所述第四互斥锁之后，申请持有所述第二互斥锁，等待所述第二互斥锁；

在所述第六线程持有所述第二互斥锁之后，请求所述Installed守护进程执行相应的操作；其中，所述第六线程用于请求所述Installed守护进程执行非编译优化操作，且所述非编译优化操作涉及的文件与编译优化操作涉及的文件存在冲突。

6.根据权利要求1所述的方法，其特征在于，在所述第二线程持有所述第二互斥锁之后，还包括：

所述Installer中第七线程申请持有所述第二互斥锁，等待所述第二互斥锁；

在所述第七线程持有所述第二互斥锁之后，请求所述Installed守护进程执行编译优化操作。

7.根据权利要求1所述的方法，其特征在于，在所述第二互斥锁空闲时，还包括：

所述Installer中第八线程申请持有所述第四互斥锁，并在持有所述第四互斥锁之后，申请持有所述第二互斥锁；

在所述第八线程持有所述第二互斥锁之后，请求所述Installed守护进程执行相应的操作；其中，所述第八线程用于请求所述Installed守护进程执行非编译优化操作，且所述非编译优化操作涉及的文件与编译优化操作涉及的文件存在冲突。

8.一种电子设备，其特征在于，包括：

一个或多个处理器；

存储器；

以及一个或多个计算机程序，其中所述一个或多个计算机程序存储在所述存储器上，当所述计算机程序被所述一个或多个处理器执行时，使得所述电子设备执行如权利要求1-7中任一项所述的编译优化方法。

9.一种计算机可读存储介质，包括计算机程序，其特征在于，当所述计算机程序在电子设备上运行时，使得所述电子设备执行如权利要求1-7中任一项所述的编译优化方法。