CN112394906A - 一种应用切换运行的方法及设备 - Google Patents

Abstract

本申请实施例提供一种应用切换运行的方法，涉及电子技术领域。具体方案为：以第一编译模式运行第一应用；当满足第一切换条件时，以第二编译模式运行所述第一应用。可以实现灵活切换应用的编译模式，为解决应用崩溃、不兼容等问题提供新的思路。

Description

一种应用切换运行的方法及设备

技术领域

本申请实施例涉及电子技术领域，尤其涉及一种应用切换运行的方法及设备。

背景技术

华为研发并发布了方舟编译器，方舟编译器采取了静态编译的方式，是首个取代了安卓虚拟机模式的静态编译器。华为方舟编译器提供了全新的系统及应用的编译和运行机制，从底层解决了安卓运行效率问题，可供开发者在开发环境一次性的将高级语言编译为机器码，带来效率上的极大提升。

使用方舟编译器编译过的应用称为方舟应用。方舟应用的打包形态具备多种形态，其中的BOTH打包形态下，APK(Android package,Android安装包)内部既包括android应用原始的classes.dex文件，又包括方舟编译后生成的maple.so文件。此种BOTH形态的方舟应用可以用方舟模式运行在系统中，也可以用android模式运行在系统中。

发明内容

本申请实施例提供一种应用切换运行的方法及设备，能够灵活切换应用的的编译模式，使用一种全新的方式来解决应用崩溃、不兼容等问题。

为达到上述目的，本申请实施例采用如下技术方案：

第一方面，本申请实施例提供一种应用切换运行的方法，包括：以第一编译模式运行第一应用；当满足第一切换条件时，以第二编译模式运行该第一应用。

在一种可能的设计中，该第一应用是以BOTH形态打包的方舟应用。

在一种可能的设计中，该第一切换条件为以下条件的至少一种：该第一应用的崩溃次数达到第一阈值；或当前系统内存占用超过第二阈值；或该第一应用的内存占用超过第三阈值；或该第一应用的页面响应速度低于第四阈值；或该第一应用以该第一编译模式运行时间超过第五阈值；或用户的位置信息发生改变；或该第二编译模式的编译器性能优于该第一编译模式的编译器性能；或当前系统时间处于预设时间段内。

在一种可能的设计中，当该第一切换条件为该第一应用的崩溃次数达到第一阈值时，该方法还包括：记录该第一应用的崩溃次数，将该第一应用设置为切换状态；在该第一应用重新启动时，检测该第一应用是否是切换状态；如果该第一应用是切换状态，则以该第二编译模式运行该第一应用。

在一种可能的设计中，当满足第二切换条件时，以该第一编译模式运行该第一应用。

在一种可能的设计中，该第二切换条件为：该第一应用以该第二编译模式运行后的崩溃次数大于该第一阈值。

在一种可能的设计中，该第二切换条件为：检测到该第一应用在该第一编译模式下的崩溃漏洞被修复。

在一种可能的设计中，该第一应用运行的进程下还包括第二应用，该方法还包括：当以该第二编译模式运行该第一应用时，切换该第二应用的编译模式为该第二编译模式。

在一种可能的设计中，该第二应用的启动时间早于该第一应用的启动时间。

在一种可能的设计中，该第二应用的启动时间晚于该第一应用的启动时间。

在一种可能的设计中，该第一应用的运行依赖于第三应用，该第一切换条件为：该第三应用的APK状态发生变化。

在一种可能的设计中，该第一应用的运行依赖于第三应用，该第一切换条件为：该第三应用切换为以该第二编译模式运行。

在一种可能的设计中，在创建该第一应用时，根据该第一应用的API信息生成第一校验值；将该第一校验值打包到该第一应用的APK中；将操作系统提供的API信息生成第二校验值，将该第二校验值打包到该操作系统中；当该第一应用的状态改变时，比对该第一校验值和该第二校验值；根据比对结果，切换该第一应用的编译模式。

在一种可能的设计中，该比对该第一校验值和该第二校验值为：检测该第一校验值是否为该第二校验值的子集；该根据比对结果，切换该第一应用的编译模式，具体为：如果该第一校验值不是该第二校验值的子集，则切换该第一应用的编译模式。

在一种可能的设计中，该第一编译模式为Android编译模式，该第二编译模式为方舟编译模式；或者，该第一编译模式为方舟编译模式，该第二编译模式为Android编译模式。

通过以上方案，可以灵活切换应用的的编译模式，使用一种全新的方式来解决应用崩溃、不兼容等问题。

第二方面，本申请实施例提供一种电子设备，包括第一编译模块，第二编译模块，切换模块，其中：该第一编译模块，用于以第一编译模式运行第一应用；该切换模块，用于确定当满足第一切换条件时，使得该第一应用从该第一编译模式切换为第二编译模式运行；该第二编译模块，用于以该第二编译模式运行该第一应用。

在一种可能的设计中，该第一应用是以BOTH形态打包的方舟应用。

在一种可能的设计中，该第一切换条件为以下条件的至少一种：该第一应用的崩溃次数达到第一阈值；或当前系统内存占用超过第二阈值；或该第一应用的内存占用超过第三阈值；或该第一应用的页面响应速度低于第四阈值；或该第一应用以该第一编译模式运行时间超过第五阈值；或用户的位置信息发生改变；或该第二编译模块的性能优于该第一编译模块的性能；或当前系统时间处于预设时间段内。

在一种可能的设计中，该电子设备还包括崩溃记录模块，重启检测模块，其中，该第一切换条件为该第一应用的崩溃次数达到第一阈值，其中：该崩溃记录模块，用于记录该第一应用的崩溃次数，将该第一应用设置为切换状态；该重启检测模块，用于在该第一应用重新启动时，检测该第一应用是否是切换状态；该第二编译模块，用于确定当该第一应用是切换状态，则以该第二编译模式运行该第一应用。

在一种可能的设计中，该第一编译模块还用于：当满足第二切换条件时，以该第一编译模式运行该第一应用。

在一种可能的设计中，该第二切换条件为：该第一应用以该第二编译模式运行后的崩溃次数大于该第一阈值。

在一种可能的设计中，该第二切换条件为：检测到该第一应用在该第一编译模式下的崩溃漏洞被修复。

在一种可能的设计中，该第一应用运行的进程下还包括第二应用，其中：该切换模块，用于当以该第二编译模式运行该第一应用时，切换该第二应用的编译模式为该第二编译模式。

在一种可能的设计中，该第二应用的启动时间早于该第一应用的启动时间。

在一种可能的设计中，该第二应用的启动时间晚于该第一应用的启动时间。

在一种可能的设计中，该第一应用的运行依赖于第三应用，该第一切换条件为：该第三应用的APK状态发生变化。

在一种可能的设计中，该第一应用的运行依赖于第三应用，该第一切换条件为：该第三应用切换为以该第二编译模式运行。

在一种可能的设计中，该电子设备还包括第一校验码生成模块，第二校验码生成模块，比对模块，其中：该第一校验码生成模块，用于在创建该第一应用时，根据该第一应用的API信息生成第一校验值，该将该第一校验值打包到该第一应用的APK中；该第二校验码生成模块，用于将操作系统提供的API信息生成第二校验值，将该第二校验值打包到该操作系统中；该比对模块，用于当该第一应用的状态改变时，比对该第一校验值和该第二校验值；该切换模块，用于根据比对结果，切换该第一应用的编译模式

在一种可能的设计中，该比对该第一校验值和该第二校验值为：检测该第一校验值是否为该第二校验值的子集；该根据比对结果，切换该第一应用的编译模式，具体为：如果该第一校验值不是该第二校验值的子集，则切换该第一应用的编译模式。

在一种可能的设计中，该第一编译模块为Android编译模块，该第二编译模块为方舟编译模块；或者，该第一编译模块为方舟编译模块，该第二编译模块为Android编译模块。

通过以上方案，可以灵活切换应用的的编译模式，使用一种全新的方式来解决应用崩溃、不兼容等问题。

第三方面，本申请实施例提供一种电子设备，包括第一编译器，第二编译器，处理器，其中：该第一编译器被配置为，以第一编译模式运行第一应用；该处理器被配置为，确定当满足第一切换条件时，使得该第一应用从该第一编译模式切换为第二编译模式运行；该第二编译器被配置为，以该第二编译模式运行该第一应用。

第四方面，本申请实施例提供一种电子设备，该电子设备包括：一个或多个处理器、存储器，该存储器用于存储计算机程序代码，该计算机程序代码包括指令，当该一个或多个处理器执行该指令时，该电子设备执行如第一方面及其任一种可能的设计中的方法。

第五方面，本申请实施例提供一种计算机可读存储介质，其中，包括计算机指令，当该计算机指令在电子设备上运行时，使得该电子设备执行如第一方面及其任一种可能的设计中的方法。

第六方面，本申请实施例提供一种计算机程序产品，其中，当该计算机程序产品在计算机上运行时，使得该计算机执行如第一方面及其任一种可能的设计中的方法。

第七方面，本申请实施例提供一种芯片，其中，包括：处理器和接口，用于从存储器中调用并运行该存储器中存储的计算机程序，执行如第一方面及其任一种可能的设计中的方法。

附图说明

图1为本申请实施例提供的一种移动终端的硬件结构示意图。

图2为本申请实施例提供的一种Android操作系统的架构示意图。

图3为本申请实施例提供的一种应用切换运行的方法流程图。

图4为本申请实施例提供的一种切换编译模式的方法流程图。

图5为本申请实施例提供的第一应用崩溃后切换编译模式的方法流程图。

图6A、6B、6C、6D、6E为本申请实施例提供的关联应用的示意图。

图7为本申请实施例提供的多个同进程应用切换编译模式的方法流程图。

图8为本申请实施例提供的一种同进程应用切换编译模式的示意图。

图9为本申请实施例提供的另一种同进程应用切换编译模式的示意图。

图10为本申请实施例提供的一种具有依赖关系的多个应用切换编译模式的示意图。

图11为本申请实施例提供的一种为解决兼容问题而切换编译模式的方法流程图

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。其中，在本申请实施例的描述中，除非另有说明，“/”表示或的意思，例如，A/B可以表示A或B；本文中的“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，在本申请实施例的描述中，“多个”是指两个或多于两个。

移动终端可以包括诸如手机、平板电脑、可穿戴设备(例如，手表、手环、智能头盔等)、车载设备、智能家居设备、增强现实(augmented reality，AR)/虚拟现实(virtualreality，VR)设备、笔记本电脑、超级移动个人计算机(ultra-mobile personal computer，UMPC)、上网本、个人数字助理(personal digital assistant，PDA)等。本申请一些实施例以手机为例，可以理解的是，这些实施例也可应用于其他类型的移动终端。

本申请实施例涉及的应用程序(application，app)，可以简称应用，为能够实现某项或多项特定功能的软件程序。通常，电子设备中可以安装多个应用，例如，即时通讯类应用、视频类应用、音频类应用、图像拍摄类应用等等。本申请实施例中提到的应用，可以是电子设备出厂时已安装的应用，也可以是用户在使用电子设备的过程中从网络下载或其他电子设备获取的应用。

如图1所示，本申请实施例中的移动终端可以为手机100。下面以手机100为例对实施例进行具体说明。应该理解的是，图示手机100仅是移动终端的一个范例，并且手机100可以具有比图中所示出的更多的或者更少的部件，可以组合两个或更多的部件，或者可以具有不同的部件配置。

如图1所示，手机100具体可以包括：处理器101、射频(RF)电路102、存储器103、触摸屏104、蓝牙装置105、一个或多个传感器106、Wi-Fi装置107、定位装置108、音频电路109、外设接口110以及电源系统111等部件。这些部件可通过一根或多根通信总线或信号线(图1中未示出)进行通信。本领域技术人员可以理解，图1中示出的硬件结构并不构成对手机的限定，手机100可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

下面结合图1对手机100的各个部件进行具体的介绍：

处理器101是手机100的控制中心，利用各种接口和线路连接手机100的各个部分，通过运行或执行存储在存储器103内的应用程序，以及调用存储在存储器103内的数据，执行手机100的各种功能和处理数据。在一些实施例中，处理器101可包括一个或多个处理单元；举例来说，处理器101可以是华为技术有限公司制造的麒麟芯片。在本申请一些实施例中，上述处理器101还可以包括指纹验证芯片，用于对采集到的指纹进行验证。

射频电路102可用于在收发信息或通话过程中，无线信号的接收和发送。特别地，射频电路102可以将基站的下行数据接收后，给处理器101处理；另外，将涉及上行的数据发送给基站。通常，射频电路包括但不限于天线、至少一个放大器、收发信机、耦合器、低噪声放大器、双工器等。此外，射频电路102还可以通过无线通信和其他设备通信。所述无线通信可以使用任一通信标准或协议，包括但不限于全球移动通讯系统、通用分组无线服务、码分多址、宽带码分多址、长期演进、电子邮件、短消息服务等。

存储器103用于存储应用程序以及数据，处理器101通过运行存储在存储器103的应用程序以及数据，执行手机100的各种功能以及数据处理。存储器103主要包括存储程序区以及存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)；存储数据区可以存储根据使用手机100时所创建的数据(比如音频数据、电话本等)。此外，存储器103可以包括高速随机存取存储器，还可以包括非易失存储器，例如磁盘存储器件、闪存器件或其他易失性固态存储器件等。存储器103可以存储各种操作系统，例如，苹果公司所开发的

操作系统，谷歌公司所开发的

操作系统等。上述存储器103可以是独立的，通过上述通信总线与处理器101相连接；存储器103也可以和处理器101集成在一起。

触摸屏104可以包括触控板104-1和显示器104-2。其中，触控板104-1可采集手机100的用户在其上或附近的触摸事件(比如用户使用手指、触控笔等任何适合的物体在触控板104-1上或在触控板104-1附近的操作)，并将采集到的触摸信息发送给其他器件例如处理器101。其中，用户在触控板104-1附近的触摸事件可以称之为悬浮触控；悬浮触控可以是指，用户无需为了选择、移动或拖动目标(例如图标等)而直接接触触控板，而只需用户位于电子设备附近以便执行所想要的功能。在悬浮触控的应用场景下，术语“触摸”、“接触”等不会暗示用于直接接触触摸屏，而是附近或接近的接触。能够进行悬浮触控的触控板104-1可以采用电容式、红外光感以及超声波等实现。此外，可以采用电阻式、电容式、红外线以及表面声波等多种类型来实现触控板104-1。显示器(也称为显示屏)104-2可用于显示由用户输入的信息或提供给用户的信息以及手机100的各种菜单。可以采用液晶显示器、有机发光二极管等形式来配置显示器104-2。触控板104-1可以覆盖在显示器104-2之上，当触控板104-1检测到在其上或附近的触摸事件后，传送给处理器101以确定触摸事件的类型，随后处理器101可以根据触摸事件的类型在显示器104-2上提供相应的视觉输出。虽然在图1中，触控板104-1与显示屏104-2是作为两个独立的部件来实现手机100的输入和输出功能，但是在某些实施例中，可以将触控板104-1与显示屏104-2集成而实现手机100的输入和输出功能。可以理解的是，触摸屏104是由多层的材料堆叠而成，本申请实施例中只展示出了触控板(层)和显示屏(层)，其他层在本申请实施例中不予记载。另外，在本申请其他一些实施例中，触控板104-1可以覆盖在显示器104-2之上，并且触控板104-1的尺寸大于显示屏104-2的尺寸，使得显示屏104-2全部覆盖在触控板104-1下面，或者，上述触控板104-1可以以全面板的形式配置在手机100的正面，也即用户在手机100正面的触摸均能被手机感知，这样就可以实现手机正面的全触控体验。在其他一些实施例中，触控板104-1以全面板的形式配置在手机100的正面，显示屏104-2也可以以全面板的形式配置在手机100的正面，这样在手机的正面就能够实现无边框的结构。

在本申请实施例中，手机100还可以具有指纹识别功能。例如，可以在触摸屏104中配置指纹采集器件112来实现指纹识别功能，即指纹采集器件112可以与触摸屏104集成在一起来实现手机100的指纹识别功能。在这种情况下，该指纹采集器件112配置在触摸屏104中，可以是触摸屏104的一部分，也可以以其他方式配置在触摸屏104中。另外，该指纹采集器件112还可以被实现为全面板指纹采集器件。因此，可以把触摸屏104看成是任何位置都可以进行指纹识别的一个面板。该指纹采集器件112可以将采集到的指纹发送给处理器101，以便处理器101对该指纹进行处理(例如指纹验证等)。本申请实施例中的指纹采集器件112的主要部件是指纹传感器，该指纹传感器可以采用任何类型的感测技术，包括但不限于光学式、电容式、压电式或超声波传感技术等。

手机100还可以包括蓝牙装置105，用于实现手机100与其他短距离的电子设备(例如手机、智能手表等)之间的数据交换。本申请实施例中的蓝牙装置可以是集成电路或者蓝牙芯片等。

手机100还可以包括至少一种传感器106，比如光传感器、运动传感器以及其他传感器。具体地，光传感器可包括环境光传感器及接近传感器，其中，环境光传感器可根据环境光线的明暗来调节触摸屏104的显示器的亮度，接近传感器可在手机100移动到耳边时，关闭显示器的电源。作为运动传感器的一种，加速计传感器可检测各个方向上(一般为三轴)加速度的大小，静止时可检测出重力的大小及方向，可用于识别手机姿态的应用(比如横竖屏切换、相关游戏、磁力计姿态校准)、振动识别相关功能(比如计步器、敲击)等；至于手机100还可配置的陀螺仪、气压计、湿度计、温度计、红外线传感器等其他传感器，在此不再赘述。

Wi-Fi装置107，用于为手机100提供遵循Wi-Fi相关标准协议的网络接入，手机100可以通过Wi-Fi装置107接入到Wi-Fi接入点，进而帮助用户收发电子邮件、浏览网页和访问流媒体等，它为用户提供了无线的宽带互联网访问。在其他一些实施例中，该Wi-Fi装置107也可以作为Wi-Fi无线接入点，可以为其他电子设备提供Wi-Fi网络接入。

定位装置108，用于为手机100提供地理位置。可以理解的是，该定位装置108具体可以是全球定位系统(GPS)或北斗卫星导航系统、俄罗斯GLONASS等定位系统的接收器。定位装置108在接收到上述定位系统发送的地理位置后，将该信息发送给处理器101进行处理，或者发送给存储器103进行保存。在另外的一些实施例中，该定位装置108还可以是辅助全球卫星定位系统(AGPS)的接收器，AGPS系统通过作为辅助服务器来协助定位装置108完成测距和定位服务，在这种情况下，辅助定位服务器通过无线通信网络与电子设备例如手机100的定位装置108(即GPS接收器)通信而提供定位协助。在另外的一些实施例中，该定位装置108也可以是基于Wi-Fi接入点的定位技术。由于每一个Wi-Fi接入点都有一个全球唯一的MAC地址，电子设备在开启Wi-Fi的情况下即可扫描并收集周围的Wi-Fi接入点的广播信号，因此可以获取到Wi-Fi接入点广播出来的MAC地址；电子设备将这些能够标示Wi-Fi接入点的数据(例如MAC地址)通过无线通信网络发送给位置服务器，由位置服务器检索出每一个Wi-Fi接入点的地理位置，并结合Wi-Fi广播信号的强弱程度，计算出该电子设备的地理位置并发送到该电子设备的定位装置108中。

音频电路109、扬声器113、麦克风114可提供用户与手机100之间的音频接口。音频电路109可将接收到的音频数据转换后的电信号，传输到扬声器113，由扬声器113转换为声音信号输出；另一方面，麦克风114将收集的声音信号转换为电信号，由音频电路109接收后转换为音频数据，再将音频数据输出至RF电路102以发送给比如另一手机，或者将音频数据输出至存储器103以便进一步处理。

外设接口110，用于为外部的输入/输出设备(例如键盘、鼠标、外接显示器、外部存储器、用户识别模块卡等)提供各种接口。例如通过通用串行总线(USB)接口与鼠标连接，通过用户识别模块卡卡槽上的金属触点与电信运营商提供的用户识别模块卡(SIM)卡进行连接。外设接口110可以被用来将上述外部的输入/输出外围设备耦接到处理器101和存储器103。

手机100还可以包括给各个部件供电的电源装置111(比如电池和电源管理芯片)，电池可以通过电源管理芯片与处理器101逻辑相连，从而通过电源装置111实现管理充电、放电、以及功耗管理等功能。

尽管图1未示出，手机100还可以包括摄像头(前置摄像头和/或后置摄像头)、闪光灯、微型投影装置、近场通信(NFC)装置等，在此不再赘述。

图2是一种运行Android操作系统的手机100的操作系统结构示意图。Android操作系统架构分为四层，从高层到底层分为应用程序层，应用程序框架层，函数库层和Linux内核层。

1、应用程序层：

应用程序层(Applications)是Android操作系统架构的最上一层，包括Android操作系统装配的核心应用软件，例如电子邮件客户端、短信、通话、日历、地图、浏览器、联系人等。当然，对于开发者来说，开发者可以编写应用软件并安装到该层。一般而言，应用程序都是使用Java语言开发，通过调用应用程序框架层所提供的API(Application ProgrammingInterface)来完成。

2、应用程序框架层：

应用程序框架层(Application Framework)，主要是为开发者提供了可以访问应用程序所使用的各种API，应用程序框架层包括一些预先定义的函数。开发者通过应用程序框架层来与Android底层(例如函数库层、Linux内核层等)进行交互，开发自己的应用。该应用程序框架层主要是Android操作系统的一系列的服务和管理系统。应用程序框架层主要包括如下关键服务：

活动管理器(Activity Manager)用来管理应用程序生命周期并提供常用的导航回退功能；

内容提供器(Content Providers)，用来存放和获取数据，并使这些数据可以被应用程序访问。所述数据可以包括视频，图像，音频，拨打和接听的电话，浏览历史和书签，电话簿等。从而实现不同应用程序间的数据共享和访问；

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

资源管理器(Resource Manager)：为应用程序提供各种资源，比如本地化字符串，图标，图片，布局文件，视频文件等等。可以提供非代码资源(如字符串、图形和布局文件(Layoutfile)等)供应用程序使用；

包管理器(Package Manager)主要用于对Android操作系统的应用程序进行管理；

视图(View)，具有丰富的、可扩展的视图集合，可用于构建一个应用程序，它具体包括列表(List)、网格(Grid)、文本框(TextBox)、按钮(Button)，以及可嵌入的网页浏览器。显示界面可以由一个或多个视图组成的。例如，包括短信通知图标的显示界面，可以包括显示文字的视图以及显示图片的视图；

位置管理器(Location Manager)，主要是让应用程序可以访问到手机当前的地理位置。

3、函数库层：

函数库层(Libraries)是应用程序框架的支撑，是连接应用程序框架层与Linux内核层的重要纽带。函数库层包括一些由计算机程序C语言或C++语言编译的函数库，这些函数库能被Android操作系统中的不同的组件使用，它们通过Android应用程序框架为开发者提供服务。具体地，函数库包括libc函数库，它是专门为基于embedded linux的设备定制的；函数库还包括Android操作系统多媒体库(Media Framework)，该库支持多种编码格式的音频/视频的回放和录制，同时支持静态图像文件，以及常见的音频/视频编码格式。函数库还包括界面管理库(Surface Manager)，主要负责管理针对显示系统的访问，具体用于在执行多个应用程序时候，负责管理显示与存取操作间的互动，另外也负责2D绘图与3D绘图进行显示合成。

函数库层中还包括其他的用于实现Android操作系统手机各个功能的函数库，例如：SGL(Scalable Graphics Library)：基于XML(Extensible Markup Language)文件的2D图形图像处理引擎；SSL(Secure Sockets Layer)：位于TVP/IP协议(TransmissionControlProtocol/InternetProtocol，传输控制协议/互联网络协议)与各种应用层协议之间，为数据通讯提供支持；OpenGL/ES：3D效果的支持；SQLite：关系型数据库引擎；Webkit：Web浏览器引擎；FreeType：位图(Bitmap)及矢量(Vector)字体支持；等等。

Android Runtime是一种在Android操作系统上的运行环境，是Android操作系统所使用的一种新的虚拟机。在Android Runtime中，采用AOT(Ahead-Of-Time)技术，应用程序在第一次安装的时候，该应用程序的字节码就会被预先编译成机器码，让程序成为真正的本地应用，之后再次运行，就省去了编译这一步骤，启动和执行都会变得更加快速。应用程序层和应用程序框架层运行在虚拟机中。虚拟机将应用程序层和应用程序框架层的java文件执行为二进制文件。虚拟机用于执行对象生命周期的管理，堆栈管理，线程管理，安全和异常的管理，以及垃圾回收等功能。

在早期的Android系统中，Android Runtime也可以由核心函数库(CoreLibraries)和Dalvik虚拟机(Dalvik Virtual Machine)代替。核心函数库提供了Java语言API(Application Programming Interface)中的大多数功能，主要通过JNI(Java NativeInterface)的方式向应用程序框架层提供调用底层程序库的接口。同时也包含了Android的一些核心API,如android.os、android.net、android.media等等。Dalvik虚拟机使用一种JIT(Just-in-Time)的运行时编译的机制，每次启动一个进程都需要虚拟机在后台重新编译字节码，会对启动速度有一定的影响。每一个Android应用程序都运行在是一个Dalvik虚拟机中的实例中，每一个Dalvik虚拟机实例都是一个独立的进程空间。Dalvik虚拟机设计成在一个设备可以高效地运行多个虚拟机。Dalvik虚拟机可执行文件格式是.dex，dex格式是专为Dalvik设计的一种压缩格式，适合内存和处理器速度有限的系统。需要提出的是Dalvik虚拟机依赖于Linux内核提供基本功能(线程、底层内存管理)。可以理解的是，Android Runtime、Dalvik属于不同类型的虚拟机，本领域技术人员可以在不同情况下选用不同形式的虚拟机。

4、Linux内核层：

Android的核心系统服务，如安全性、内存管理、进程管理、网络协议栈和驱动模型等都基于Linux内核。Linux内核同时也作为硬件和软件栈之间的抽象层。该层有许多与移动设备相关的驱动程序，主要的驱动有：显示驱动(Display Driver)：基于Linux的帧缓冲(Frame Buffer)驱动。键盘驱动(KeyBoard Driver)：作为输入设备的键盘驱动。Flash驱动(Flash Memory Driver)：基于MTD(memory technology device内存技术设备)的Flash驱动程序。照相机驱动(Camera Driver)：常用的基于Linux的v4l2(Video for Linux)驱动。音频驱动(Audio Driver)：常用的基于ALSA(Advanced Linux Sound Architecture)的高级Linux声音体系驱动。蓝牙驱动(Bluetooth Driver)：基于IEEE 802.15.1标准的无线传输技术。WiFi驱动(WiFi Drive)：基于IEEE 802.11标准的驱动程序。Binder(IPC)驱动：Android的一个特殊的驱动程序，具有单独的设备节点，提供进程间通讯的功能。电源管理(Power Management)：比如电池电量等。

编译器是一种将高级语言翻译为能被计算机或虚拟机新的目标代码，编译器的效率直接影响程序运行性能和效果。例如，手机里的应用程序是由高级语言开发而成的，当启动某个应用程序的时候，编译器扮演者“翻译者”的角色，把高级语言转换成机器能读懂的机器码，并按照指令运行。

Java为了能够实现跨平台操作，便借助虚拟机来调度硬件平台资源。在虚拟机里，还需要集成翻译器或者编译器，来将Java的字节码(即中间代码)解释成机器听得懂的机器语言，或者直接编译成机器直接执行的010101的机器码。Android 1.0刚发布的时候，使用的是一个叫Dalvik的虚拟机，里面集成了一个解释器，每次用户在安卓手机上运行应用时，就会叫醒这个解释器，来给安卓的硬件解释应用想执行的操作，效率非常低下。在2010年中发布了2.2版本，引入了JIT(Just in Time，即时编译)机制。JIT比较聪明，当用户在安卓手机运行APP时，会同时将用户经常使用的功能编译为机器能直接执行的010101机器码，不用每一句每一句的去翻译。当出现不常用的功能时，再把解释器叫起来翻译。

JIT每次启动APP都要先编译一次，加上Dalvik虚拟机性能比较落后，所以谷歌在2014年10月推出了Android 5.0版本，将虚拟机从Dalvik替代成ART(Android Run Time)，同时把JIT的编译器替代成AOT(Ahead of Time)。意思就是说，APP在下载后安装到手机上时同时把能编译的代码先编译成机器听得懂的101010。剩下不太好翻译的代码，就在用户使用时再叫醒解释器来翻译。AOT相比JIT的好处，就是不用每次打开APP都需要先编译一遍。但是，坏处就是用户安装APP的时间有点长。

谷歌在2017年Android 7.0又做了一点改进，安装时先不编译中间代码，而是在用户空闲时将能够编译成机器码的那部分代码，通过AOT编译器先静态编译了。如果AOT还没来得及编译或者不能编译，再唤醒JIT和解释器编译。

当前的Android系统使用Java作为编程语言，易于开发，尽管Android采用了ART(Android Runtime)模式，对调用次数多的Java代码编译为机器码(静态编译)；在设备空闲的时候进行一些预编译，解决了部分Java代码执行效率问题，但对于动态语义部分还是无法实现静态编译，仍需要虚拟机充当“翻译”边解释边运行，效率和体验提升有限。

无论是编译器还是解释器，只是在虚拟机上打补丁。手机上的虚拟机+编译器+解释器本身不仅占用硬件资源，还无法最大发挥软件运行性能。正因如此，所以绝大部分手机厂商只能通过提升安卓手机的内存和存储空间，来弥补虚拟机的弊端。安卓虚拟机的编译器受限于手机硬件和代码优化模板单一，代码优化空间有限。编译器包含三个部分。前端Front End，主要负责将源代码翻译成IR(Intermediate Representation，中间表示)；中端的Optimizer主要负责代码优化，将前端翻译过来的IR代码优化得更高效；后端Back End则将优化后的IR编译成101010的机器码。为了防止生态过于碎片化，安卓只为第三方开放了简单的编译代码优化模板，代码优化空间有限。

方舟编译器采用了全新的系统及应用的编译和运行机制，对所有的Java语义全部做到静态编译，有效解决现有Android系统中存在的“边解释边执行”的低效现象，采用方舟编译器的应用在开发阶段就已经完成了编译，也就是说，从华为应用市场下载的就是编译过的机器码了。经过华为方舟编译器的应用，再也不需要在手机上编译了，彻底告别了虚拟机，让方舟编译器能够将Java代码编译成机器能直接执行的语言。

方舟编译器采取了静态编译的方式，是首个取代了Android虚拟机模式的静态编译器，可供开发者在开发环境一次性将高级语言编译为机器码，APP厂商无需重新开发APP，只要用方舟编译器重新编译发布，即可显著提升运行速度、流畅度。根据华为官方的测试数据显示，操作系统流畅度提升24％，系统响应速度提升44％，三方应用操作流畅度提升60％。目前华为方舟编译器已面向业界开源。

使用方舟编译器编译过的应用称为方舟应用。方舟应用的打包形态具备多种形态，例如原有的Android形态，包括android应用原始的classes.dex文件，不包括方舟编译后生成的maple.so文件；方舟only形态，包括方舟编译后生成的maple.so文件，不包括android应用原始的classes.dex文件；BOTH打包形态的APK内部既包括android应用原始的classes.dex文件，又包括方舟编译后生成的maple.so文件。此种BOTH形态的方舟应用具备如下特征：既可以用方舟模式运行在系统中，也可以用android模式运行在系统中，应用的运行方式具备可切换性。

本申请利用这种可切换性，为使用方舟编译器编译后产生的方舟应用带来了运行方式上的灵活性。例如，可以为应用的稳定性(崩溃、闪退等)故障的恢复提供新的手段。针对方舟应用实际运行的场景复杂性，本申请提供了相应的切换策略。

图3提供了一种应用切换运行的方法，该方法包括以下步骤：

301、以第一编译模式运行第一应用。

编译模式可以是Android编译模式或者方舟编译模式。第一编译模式可以是这两种编译模式其中的一种。其中，在Android编译模式下，应用启动并加载到Android进程中，该Android进程里有Android的ART虚拟机；或者说，移动终端运行第一应用APK中的classes.dex文件；在方舟编译模式下(也可以称作maple编译模式)，应用启动并加载到方舟进程中，该方舟进程里有方舟的runtime；或者说，移动终端运行第一应用APK中的经方舟编译器编译后生成的maple.so文件。第一应用，可以是当前正在运行的应用，或者将要运行的应用(例如用户将要打开的应用)。

302、当满足第一切换条件时，以第二编译模式运行所述第一应用。

第二编译模式，是不同于第一编译模式的另一种编译模式。例如，当第一编译模式是Android编译模式时，第二编译模式是方舟编译模式。又例如，当第一编译模式是方舟编译模式时，第二编译模式是Android编译模式。

当满足第一切换条件时，可以是移动终端收到用户手动切换编译模式的指令，也可以是移动终端收到系统自动切换第一应用的编译模式的指令。手动切换编译模式的指令，可以是用户在第一应用运行过程中手动切换编译模式，也可以在打开第一应用之前切换编译模式。具体的，用户可以在第一应用的设置选项，或者移动终端系统的设置选项中进行切换。切换的方式不做限制，例如可以通过点击屏幕上的按钮，按下手机的按键(或者按键的组合)，使用手势指令，使用语音指令，晃动手机，翻转手机等等。自动切换编译模式的指令，可以由用户事先设置然后触发，也可以在移动终端出厂时自动设置并触发，也可以在移动终端运行过程中接受服务器侧的设置而触发，还可以是第一应用默认的设置而触发。

作为不完全举例，“当满足第一切换条件时”具体可以是：所述第一应用崩溃次数达到第一阈值；或者，当前系统内存占用超过某个阈值；或者，第一应用的内存占用超过了某个阈值；或者，第一应用页面响应速度低于某个阈值；或者，第一应用以第一编译模式运行的时间已经超过某个时间阈值；或者，用户的位置信息(如GPS信息)，和/或时区信息，和/或运营商PLMN号发生了变化；或者，第二编译模式的编译器性能优于第一编译模式的编译器性能；或者，根据移动终端的硬件能力(CPU，或存储容量，或GPU，或磁盘读写速度，或屏幕分辨率，或屏幕尺寸等)切换；或者，根据移动终端的操作系统版本切换；或者，当前移动终端的系统时间处于预设时间段内；等等。

图4示出了一个切换编译模式的例子。传统的Android应用在崩溃后，系统会弹出对话框提示用户该应用遇到了异常，没有其他有效的修复方式。利用方舟应用的可切换性，可以在应用崩溃后切换编译模式来运行，从而恢复应用正常运行，获得更好的用户体验。具体步骤如下：

401，以第一编译模式运行第一应用。

402、当满足第一切换条件时，以第二编译模式运行所述第一应用，其中，所述第一切换条件为：所述第一应用崩溃次数达到第一阈值。

当该第一应用发生连续崩溃(frequently crash)，例如在1分钟内崩溃或者闪退达到2次，就认为满足了第一切换条件。可以理解的是，这里的第一阈值表示一定时间周期内该第一应用崩溃的次数，第一阈值可以灵活设置，比如1分钟内崩溃2次，或者5分钟内崩溃3次，等等。在满足第一切换条件后，操作系统会检测并记录到该连续崩溃的状况，并将该应用设置为切换状态。然后，该应用在重新启动时，操作系统会对已设置为切换状态的该应用进行切换运行，例如从第一编译模式切换到第二编译模式运行。

例如，如果第一编译模式是方舟编译模式，当第一应用以方舟编译模式运行时在一定时间周期内发生崩溃的次数达到了第一阈值，则认为满足了第一切换条件。操作系统可以检测并记录崩溃次数情况，并将该第一应用设置为切换状态。具体的，可以将该切换状态记录到APK文件中，例如添加到disable-maplePkgs.xml中。然后，在该第一应用重新启动时，操作系统会检测到该第一应用已被设置为切换状态，从而切换到第二编译模式运行，例如以Android编译模式启动该第一应用。以Android编译模式启动该第一应用的具体实现是公知的，例如可以通过zygote进程创建一个虚拟机实例来创建新进程，从而以Android编译模式启动该第一应用。以上切换步骤可以在用户无感知的情况下进行(例如在后台切换而不弹出提示消息)，避免应用崩溃后一直无法修复带来的糟糕的用户体验。通过以上步骤，当第一应用以方舟编译模式运行发生连续崩溃后，该第一应用可以切换成Android编译模式正常运行，从而获得了更好的用户体验。由于在步骤402中，第一应用切换编译模式前发生了连续崩溃，切换编译模式后可以正常运行，所以步骤402的“切换”有时候也可以称作“逃生”。

又例如，如果第一编译模式是Android编译模式，当该第一应用以Android编译模式运行时在一定周期内发生崩溃的次数达到了第一阈值，则认为满足了第一切换条件。操作系统可以检测并记录崩溃次数情况，并将该第一应用设置为切换状态。然后，在该第一应用重新启动时，操作系统会检测到该第一应用已被设置为切换状态，从而切换到第二编译模式运行，例如以方舟编译模式启动该第一应用。以方舟编译模式启动该第一应用时，可以通过mygote进程来创建新进程，从而以方舟编译模式启动该第一应用。以上切换步骤可以在用户无感知的情况下进行(例如在后台切换而不弹出提示消息)，避免应用崩溃后一直无法修复带来的糟糕的用户体验。

可选的，在步骤402之后，还可以包括以下步骤403：

403：当满足第二切换条件时，以第一编译模式运行所述第一应用。

在上述步骤402中，第一应用切换到第二编译模式运行。如果切换后满足第二切换条件，该第一应用还可以再次切换回第一编译模式运行。例如，第二切换条件可以是第一应用以第二编译模式运行后的崩溃次数大于第一阈值，此时意味着步骤402切换为第二编译模式后，应用崩溃情况比以第一编译模式运行时还要严重，崩溃次数超过了第一阈值。从而说明步骤402切换后应用运行情况反而恶化了，还不如切换回第一编译模式来运行。类似于步骤402，步骤403的切换也可以在用户无感知的情况下进行。可选的，第二切换条件还可以是检测到第一应用在第一编译模式下的崩溃漏洞已被修复，此时使用第一编译模式已经可以使得第一应用以较好的状况运行，则可以切换回第一编译模式。可以理解的是，第二切换条件还可以是移动终端收到用户或者系统设置的其他切换指令。

图5是一种可能的第一应用在方舟编译模式下崩溃后切换到Android编译模式的流程示意图。在上述步骤402中，如果第一编译模式是方舟编译模式，当满足了第一切换条件，则以Android编译模式启动该第一应用。在现有的应用崩溃重启时，操作系统会执行APK扫描(APK scan)，然后设备启动(device booting)，然后应用启动(App start),然后运行zygote进程创建新进程来启动该第一应用(zygote fork)。

在图5中，当第一应用发生了连续崩溃(frequently crash)(501),则操作系统会把崩溃情况记录在disable-maplePkgs.xml文件中(502)。然后在应用崩溃重启时，操作系统执行APK扫描(APK scan)会读取该disable-maplePkgs.xml文件(503)，然后设备启动(device booting)(504)，然后应用启动(App start)(505)。应用启动时会检查是否是方舟编译模式(即maple编译模式)(506)，如果是，则检查方舟编译模式是否被禁用(disabled)(507)；如果否，则以Android编译模式启动，即用zygote进程创建新进程来启动该第一应用(zygote fork)(508).在507步骤检查方舟编译模式是否被禁用，如果是(被禁用)，则仍然使用Android编译模式启动，执行步骤508；如果否(没有被禁用)，则以方舟编译模式启动该第一应用，即用mygote进程来启动该第一应用(mygote fork)(509)。

以上是单个应用切换编译模式的例子，在系统实际运行过程中，可能会遇到多个应用需要切换编译模式的情况。注意，此处所说的多个可以是两个，也可以是多于两个的情况。例如，当多个应用之间存在关联关系时(这些应用相互之间可以称为关联应用)，一个应用的编译模式切换可能会导致其他关联应用的编译模式切换。

图6A，图6B，图6C，图6D，图6E是关联应用的5个例子。这5个例子中有些是方舟应用运行在方舟进程中，可以理解的是，Android应用运行在Android进程中也可以有类似的实现，反之亦然。在图6A中，多个应用一起运行在同一个进程(process)中，例如，方舟应用A(包名：com.package.a)和方舟应用B(包名：com.package.b)共享运行在一个方舟进程1(process1)中。在图6B中，一个应用可以运行在多个进程中，例如方舟应用A(包名：com.package.a)启动了方舟进程1(process1),而方舟应用B(包名：com.package.b)同时运行在方舟进程1(process1)和方舟进程2(process2)中。图6C是图6B的一个变种，图6C中，有方舟应用A(包名：com.package.a)启动了方舟进程1(process1)，方舟应用B(包名：com.package.b)运行在方舟进程2(process2)，方舟应用C(包名：com.package.c)同时运行在方舟进程1(process1)和方舟进程2(process2)中。图6D是一个应用分别运行在Android进程和方舟进程中，例如Android应用A(包名：com.package.a)启动了Android进程(process1)，方舟应用B(包名：com.package.b)同时运行在Android进程(process1)和方舟进程(process2)中。可以理解的是，图6D中方舟应用B同时运行在Android进程process1和方舟进程process2中时，分别运行Android编译模式下的classes.dex文件和方舟编译模式下的maple.so文件。图6E是图6D的一个变种，例如在图6E中，Android应用A(包名：com.package.a)启动了Android进程(process1)，方舟应用B(包名：com.package.b)运行在方舟进程中(process2)，方舟应用C(包名：com.package.c)同时运行在Android进程(process1)和方舟进程(process2)中。

图7示出了多个应用同进程的情况下切换编译模式的步骤，包括：

701：在第一应用的进程启动时，创建第一列表记录所述进程中的所有应用。

例如，当第一应用启动并以第一编译模式运行时，可以在第一应用的进程启动时，创建第一列表记录所述进程中的所有应用。具体的，可以是在应用进程启动时(即应用的Activity组件启动时)，Android系统的ActivityManagerService会为每个进程创建ProcessRecord，用于保存进程信息。其中，可以在ProcessRecord中创建pkgList列表(第一列表)，该列表可以记录运行在该进程下的所有应用。可以理解的是，“运行在该进程下的所有应用”，可以是指当第一应用启动之后，启动的运行在该进程下的其他应用；在有些情况下，也可以是第一应用启动之前，已经运行在该进程下的其他应用。

702：当第一应用切换编译模式时，把所述第一列表中的所有应用设置为切换状态。

当第一应用切换编译模式时(从第一编译模式切换为第二编译模式，例如从Android编译模式切换为方舟编译模式，或者从方舟编译模式切换为Android编译模式)，可以遍历该进程下的pkgList列表，把其中记录的所有应用都设置为切换状态。可选的，还可以在设置为切换状态时记录切换方式(即具体是从Android编译模式切换为方舟编译模式，还是从方舟编译模式切换为Android编译模式)。可选的，切换状态和切换方式都可以存储在操作系统文件中。

可选的，步骤702也可以是第一列表记录的其他应用(例如第二应用)，当第二应用切换编译模式时，把所述第一列表中的所有应用设置为切换状态。可选的，当该进程中的任一应用切换时，可以把该进程中的所有应用设置为切换状态。可选的，当该进程个的任意几个应用切换时，可以把该进程中的所有应用设置为切换状态。

703：当启动第二应用时，以所述切换状态运行所述第二应用，所述第二应用是所述第一列表记录的所有应用中的一个应用。

当上述pkgList列表中的某个应用(即所述进程下的所有应用中的某个应用)启动时，可以按照步骤702设置的切换状态(可选的，也可以包括切换方式)来运行这个应用。可以理解的是，703所述的第二应用只是某个应用的例子，也可以是“当启动第一应用时，以所述切换状态运行所述第一应用”。以所述切换状态运行，可以是该应用启动时切换编译模式运行，例如，当步骤701是以Android编译模式运行时，步骤703可以以方舟编译模式运行第二应用。

通过图7中的切换方法，可以实现一个进程下某个应用切换后其他同进程应用连锁切换，从而方便的实现多应用切换编译模式。例如，对于同进程的多个应用，当其中一个应用发生连续崩溃时，系统不仅会设置该应用为切换状态，同时会把同进程的其他应用也设置为切换状态，当其他同进程应用在下次启动时，会根据此切换状态来切换运行。

举例来说，如图8所示，应用A的进程启动后，该进程中还运行有同进程应用B和同进程应用C，其中，应用B和应用C晚于应用A启动(对应用B和应用C二者之间的启动顺序不做限制)。当应用A切换编译模式时，同进程的应用B和C也都会自动切换编译模式。例如，当方舟应用A因为连续崩溃而切换到以Android编译模式运行时，晚于方舟应用A启动的同进程方舟应用B和方舟应用C也会自动切换到以Android编译模式运行。又例如，当Android应用A的进程启动后，又启动Android应用B，二者在同一进程下运行；当Android应用A因为自身内存占用超过了某个阈值从而切换为以方舟编译模式运行时，Android应用B也会同步切换到以方舟编译模式运行。

在另一些例子中，如图9所示，应用A的进程启动后，该进程中还运行有同进程应用B和同进程应用C，其中，应用B晚于应用A启动，应用C晚于应用B启动。在一种情况下，当应用B切换编译模式时，早于应用B启动的应用A也会自动切换编译模式，晚于应用B启动的应用C也会自动切换编译模式；在另一种情况下，当应用C切换编译模式时，早于应用C启动应用A和应用B都会自动切换编译模式。又例如，当方舟应用A的进程启动后，该进程中还运行有同进程方舟应用B，当方舟应用B因为连续崩溃而切换到以Android编译模式运行时，早于方舟应用B启动的方舟应用A也会自动切换为以Android编译模式运行。

以上介绍了同进程的多个应用切换编译模式的例子，还存在另一种情况，即多个应用虽然不是同进程，但存在业务上的依赖关系，这种依赖关系可以在系统中注册或者记录。例如，如图10所示，A应用(也可以称为“依赖应用”)的运行依赖于应用B(也可以称为“被依赖应用”)，如果应用B被删除或者改变，可能导致应用A无法启动或者无法正常运行，尽管这两个应用不在同一进程运行。在这种情况下，如果应用B切换编译模式，则可能导致应用A无法启动或者无法正常运行；所以，如果多个应用间存在依赖和被依赖的关系，如果被依赖的应用切换了编译模式，则依赖应用也要随之切换编译模式，从而确保依赖应用能够正常启动和运行。例如，方舟应用A的运行依赖于方舟版本的webview(被依赖应用)，当该webview的APK状态发生了变化，例如被卸载、被删除、被损坏、被替换/更新为非方舟版本(例如被更新为Android版本)、切换为以其他编译模式运行等情况，都会导致方舟应用A无法正常启动或者运行。此时，如果该webview切换为Android编译模式，则方舟应用A也要自动/手动切换为以Android编译模式运行，才能正常启动和运行。

可选的，上述依赖应用切换编译模式，可以是主动切换的，也可以是被动切换的。举例来说，在依赖应用主动切换的情况下，该依赖应用会主动监听被依赖应用的状态变化(是否被卸载，是否被删除，是否被替换/更新为其他版本，或者是否以其他编译模式运行等)，如果被依赖应用状态有变化，则依赖应用会自动进行切换编译模式。例如，被依赖应用和依赖应用开始时都以方舟编译模式运行，后来依赖应用监听到被依赖应用切换为以Android编译模式运行，则该依赖应用会主动随之切换为以Android编译模式运行。又例如，被依赖应用和依赖应用开始时都以方舟编译模式运行，后来依赖应用监听到被依赖应用已被删除或卸载，则该依赖应用会主动切换为以Android编译模式运行。

在依赖应用被动切换的情况下，当被依赖应用发生状态变化，由于系统中已经注册了二者的依赖关系，则系统可以自动对依赖应用进行编译模式的切换。例如，应用A是依赖应用，应用B是被依赖应用，系统中已经注册了二者的依赖关系，当应用B发生了状态变化时(例如从方舟编译模式切换为Android编译模式)，系统会自动切换应用A的编译模式(例如从方舟编译模式切换为Android编译模式)。具体的，系统可以将应用A标记为切换状态，在应用A启动的时候以该切换状态启动；或者，系统可以通知应用A，使得应用A标记自身为切换状态，在应用A启动的时候以该切换状态启动。

方舟应用通过静态化编译直接将java字节码编译为机器码，因此分别独立编译的maple.so和方舟系统间存在版本的兼容问题。在某些特定场景下，例如开发人员错误编译，可能会出现发布的方舟应用与方舟系统间不兼容的情况。为了解决此类异常问题，图11给出了一种解决方案，包括以下步骤：

1101：创建方舟应用时，根据该方舟应用的API信息生成第一校验值，并将该第一校验值打包到APK中。

在开发人员创建方舟应用的过程中，可以根据该方舟应用的API(ApplicationProgramming Interface，应用程序编程接口)信息，例如编译中使用到的androidframework API的类、成员或方法等信息，抽象成为一组校验值(md5或者其他方式生成校验值)，形成第一校验值。该第一校验值可以打包预置到APK中。其中，API是一组定义、程序及协议的集合，是计算机软件之间为了保证互相通信所提供的一系列特殊规则和要求。通过API，应用程序和操作系统之间可以实现通信。

第一校验值会随着该方舟应用的代码变化而变化。例如，当该方舟应用升级时，会引入新的代码，此时API信息会发生变化，导致抽象出的第一校验值也发生变化。

1102：将方舟系统提供的API信息生成第二校验值，并将该第二校验值打包到方舟系统中。

将方舟系统对外提供的API信息，例如对外提供的android framework层API类、成员或方法等信息，抽象成为一组校验值(md5或者其他方式生成校验值),形成第二校验值。该第二校验值生成的方法与步骤1101中第一校验值生成的方法相同。并将该第二校验值打包预置到方舟系统中。

第二校验值会随着该方舟系统的代码变化而变化。例如，当该方舟系统版本更新时，会引入新的代码，此时API信息会发生变化，导致抽象出的第二校验值也发生变化。一般来说，方舟应用API的第一校验值是方舟系统API的第二校验值的子集。

1103：当该方舟应用状态改变时，方舟系统比对第一校验值和第二校验值。

状态改变，可以是安装、更新、OTA(over the air，空中下载)升级、打补丁等；方舟应用的状态改变可以引起第一校验值的变化。当该方舟应用发生状态改变时，方舟系统会比对上述第一校验值和第二校验值，确定第一校验值是否是第二校验值的子集。

1104：根据该比对结果，切换方舟应用的编译模式。

如果第一校验值是第二校验值的子集，则不必切换该方舟应用的编译模式，即仍然保持方舟编译模式运行。如果第一校验值不是第二校验值的子集，说明可能存在版本的兼容性问题(例如方舟应用版本和方舟系统版本不兼容)，则切换该方舟应用的编译模式，即切换为Android编译模式。

可以理解的是，生成校验值的方法可以有多种，上述使用API信息生成校验值只是其中一个例子。其他生成校验值的方法包括但不限于：使用代码生成的库文件生成校验值，使用代码生成的库文件中的某一个代码段生成校验码，使用代码中的类生成校验值，使用类中的方法生成校验值，或使用类中的接口生成校验值，等等。

使用图11中所示的方法，可以在应用不兼容的情况下切换编译模式，从而解决方舟应用和方舟系统不兼容的问题。

另外，本申请还提供一种应用切换运行的方法，包括：

1.一种应用切换运行的方法，其特征在于，所述方法包括：

以第一编译模式运行第一应用；

当满足第一切换条件时，以第二编译模式运行所述第一应用。

2.根据1所述的方法，其特征在于，所述第一应用是以BOTH形态打包的方舟应用。

3.根据1或2所述的方法，其特征在于，所述第一切换条件为以下条件的至少一种：

所述第一应用的崩溃次数达到第一阈值；或

当前系统内存占用超过第二阈值；或

所述第一应用的内存占用超过第三阈值；或

所述第一应用的页面响应速度低于第四阈值；或

所述第一应用以所述第一编译模式运行时间超过第五阈值；或

用户的位置信息发生改变；或

所述第二编译模式的编译器性能优于所述第一编译模式的编译器性能；或

当前系统时间处于预设时间段内。

4.根据1-3所述的方法，其特征在于，当所述第一切换条件为所述第一应用的崩溃次数达到第一阈值时，所述方法还包括：

记录所述第一应用的崩溃次数，将所述第一应用设置为切换状态；

在所述第一应用重新启动时，检测所述第一应用是否是切换状态；

如果所述第一应用是切换状态，则以所述第二编译模式运行所述第一应用。

5.根据1-4所述的方法，其特征在于，所述方法还包括：

当满足第二切换条件时，以所述第一编译模式运行所述第一应用。

6.根据5所述的方法，其特征在于，所述第二切换条件为：

所述第一应用以所述第二编译模式运行后的崩溃次数大于所述第一阈值。

7.根据5所述的方法，其特征在于，所述第二切换条件为：

检测到所述第一应用在所述第一编译模式下的崩溃漏洞被修复。

8.根据1-7所述的方法，其特征在于，所述第一应用运行的进程下还包括第二应用，所述方法还包括：

当以所述第二编译模式运行所述第一应用时，切换所述第二应用的编译模式为所述第二编译模式。

9.根据8所述的方法，其特征在于，所述第二应用的启动时间早于所述第一应用的启动时间。

10.根据8所述的方法，其特征在于，所述第二应用的启动时间晚于所述第一应用的启动时间。

11.根据1所述的方法，其特征在于，所述第一应用的运行依赖于第三应用，所述第一切换条件为：

所述第三应用的APK状态发生变化。

12.根据1所述的方法，其特征在于，所述第一应用的运行依赖于第三应用，所述第一切换条件为：

所述第三应用切换为以所述第二编译模式运行。

13.根据1所述的方法，其特征在于，所述方法还包括：

在创建所述第一应用时，根据所述第一应用的API信息生成第一校验值；

将所述第一校验值打包到所述第一应用的APK中；

将操作系统提供的API信息生成第二校验值，将所述第二校验值打包到所述操作系统中；

当所述第一应用的状态改变时，比对所述第一校验值和所述第二校验值；

根据比对结果，切换所述第一应用的编译模式。

14.根据13所述的方法，其特征在于，所述比对所述第一校验值和所述第二校验值为：检测所述第一校验值是否为所述第二校验值的子集；

所述根据比对结果，切换所述第一应用的编译模式，具体为：如果所述第一校验值不是所述第二校验值的子集，则切换所述第一应用的编译模式。

15.根据1-14所述的方法，其特征在于：

所述第一编译模式为Android编译模式，所述第二编译模式为方舟编译模式；或者，

所述第一编译模式为方舟编译模式，所述第二编译模式为Android编译模式。

另外，本申请还提供一种电子设备，包括第一编译模块，第二编译模块，切换模块，其中：所述第一编译模块，用于以第一编译模式运行第一应用；所述切换模块，用于确定当满足第一切换条件时，使得所述第一应用从所述第一编译模式切换为第二编译模式运行；所述第二编译模块，用于以所述第二编译模式运行所述第一应用。

其中，所述第一应用是以BOTH形态打包的方舟应用。

其中，所述第一切换条件为以下条件的至少一种：

所述第一应用的崩溃次数达到第一阈值；或

当前系统内存占用超过第二阈值；或

所述第一应用的内存占用超过第三阈值；或

所述第一应用的页面响应速度低于第四阈值；或

所述第一应用以所述第一编译模式运行时间超过第五阈值；或

用户的位置信息发生改变；或

所述第二编译模块的性能优于所述第一编译模块的性能；或

当前系统时间处于预设时间段内。

其中，所述电子设备还包括崩溃记录模块，重启检测模块，其中，所述第一切换条件为所述第一应用的崩溃次数达到第一阈值，所述崩溃记录模块，用于记录所述第一应用的崩溃次数，将所述第一应用设置为切换状态；所述重启检测模块，用于在所述第一应用重新启动时，检测所述第一应用是否是切换状态；所述第二编译模块，用于确定当所述第一应用是切换状态，则以所述第二编译模式运行所述第一应用。

其中，所述第一编译模块还用于：当满足第二切换条件时，以所述第一编译模式运行所述第一应用。

其中，所述第二切换条件为：所述第一应用以所述第二编译模式运行后的崩溃次数大于所述第一阈值。

其中，所述第二切换条件还可以为：检测到所述第一应用在所述第一编译模式下的崩溃漏洞被修复。

其中，所述第一应用运行的进程下还包括第二应用，所述切换模块，用于当以所述第二编译模式运行所述第一应用时，切换所述第二应用的编译模式为所述第二编译模式。

其中，所述第二应用的启动时间早于所述第一应用的启动时间。

其中，所述第二应用的启动时间晚于所述第一应用的启动时间。

其中，所述第一应用的运行依赖于第三应用，所述第一切换条件可以为：所述第三应用的APK状态发生变化。

其中，所述第一应用的运行依赖于第三应用，所述第一切换条件也可以为：所述第三应用切换为以所述第二编译模式运行。

其中，所述电子设备还包括第一校验码生成模块，第二校验码生成模块，比对模块，所述第一校验码生成模块，用于在创建所述第一应用时，根据所述第一应用的API信息生成第一校验值，所述将所述第一校验值打包到所述第一应用的APK中；所述第二校验码生成模块，用于将操作系统提供的API信息生成第二校验值，将所述第二校验值打包到所述操作系统中；所述比对模块，用于当所述第一应用的状态改变时，比对所述第一校验值和所述第二校验值；所述切换模块，用于根据比对结果，切换所述第一应用的编译模式。

其中，所述比对所述第一校验值和所述第二校验值为：检测所述第一校验值是否为所述第二校验值的子集；所述根据比对结果，切换所述第一应用的编译模式，具体为：如果所述第一校验值不是所述第二校验值的子集，则切换所述第一应用的编译模式。

其中，所述第一编译模块为Android编译模块，所述第二编译模块为方舟编译模块；或者，所述第一编译模块为方舟编译模块，所述第二编译模块为Android编译模块。

本申请还提供一种电子设备，包括第一编译器，第二编译器，处理器，所述第一编译器被配置为，以第一编译模式运行第一应用；所述处理器被配置为，确定当满足第一切换条件时，使得所述第一应用从所述第一编译模式切换为第二编译模式运行；所述第二编译器被配置为，以所述第二编译模式运行所述第一应用。

其中，所述第一应用是以BOTH形态打包的方舟应用。

其中，所述第一切换条件为以下条件的至少一种：

所述第一应用的崩溃次数达到第一阈值；或

当前系统内存占用超过第二阈值；或

所述第一应用的内存占用超过第三阈值；或

所述第一应用的页面响应速度低于第四阈值；或

所述第一应用以所述第一编译模式运行时间超过第五阈值；或

用户的位置信息发生改变；或

所述第二编译器的性能优于所述第一编译器的性能；或

当前系统时间处于预设时间段内。

其中，当所述第一切换条件为所述第一应用的崩溃次数达到第一阈值时，所述处理器还用于：记录所述第一应用的崩溃次数，将所述第一应用设置为切换状态；

在所述第一应用重新启动时，检测所述第一应用是否是切换状态；

如果所述第一应用是切换状态，则以所述第二编译模式运行所述第一应用。

其中，所述第一编译器还用于：当满足第二切换条件时，以所述第一编译模式运行所述第一应用。

其中，所述第二切换条件为：所述第一应用以所述第二编译模式运行后的崩溃次数大于所述第一阈值。

其中，所述第二切换条件还可以为：检测到所述第一应用在所述第一编译模式下的崩溃漏洞被修复。

其中，所述第一应用运行的进程下还包括第二应用，所述处理器用于：当以所述第二编译模式运行所述第一应用时，切换所述第二应用的编译模式为所述第二编译模式。

其中，所述第二应用的启动时间早于所述第一应用的启动时间。

其中，所述第二应用的启动时间晚于所述第一应用的启动时间。

其中，所述第一应用的运行依赖于第三应用，所述第一切换条件可以为：所述第三应用的APK状态发生变化。

其中，所述第一应用的运行依赖于第三应用，所述第一切换条件也可以为：所述第三应用切换为以所述第二编译模式运行。

其中，所述处理器还用于：在创建所述第一应用时，根据所述第一应用的API信息生成第一校验值；将所述第一校验值打包到所述第一应用的APK中；将操作系统提供的API信息生成第二校验值，将所述第二校验值打包到所述操作系统中；当所述第一应用的状态改变时，比对所述第一校验值和所述第二校验值；根据比对结果，切换所述第一应用的编译模式。

其中，所述比对所述第一校验值和所述第二校验值为：检测所述第一校验值是否为所述第二校验值的子集；所述根据比对结果，切换所述第一应用的编译模式，具体为：如果所述第一校验值不是所述第二校验值的子集，则切换所述第一应用的编译模式。

其中，所述第一编译器为Android编译器，所述第二编译器为方舟编译器；或者，所述第一编译器为方舟编译器，所述第二编译器为Android编译器。

本申请还提供一种电子设备，其特征在于，所述电子设备包括：一个或多个处理器、存储器，所述存储器用于存储计算机程序代码，所述计算机程序代码包括指令，当所述一个或多个处理器执行所述指令时，所述电子设备执行上述任一实施例所述的方法。

本申请还提供一种计算机可读存储介质，其特征在于，包括计算机指令，当所述计算机指令在电子设备上运行时，使得所述电子设备执行上述任一实施例所述的方法。

本申请还提供一种计算机程序产品，其特征在于，当所述计算机程序产品在计算机上运行时，使得所述计算机执行上述任一实施例所述的方法。

本申请还提供一种芯片，其特征在于，包括：处理器和接口，用于从存储器中调用并运行所述存储器中存储的计算机程序，执行上述任一实施例所述的方法。

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

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

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是一个物理单元或多个物理单元，即可以位于一个地方，或者也可以分布到多个不同地方。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该软件产品存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(read only memory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

以上内容，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (35)

1.一种应用切换运行的方法，其特征在于，所述方法包括：

以第一编译模式运行第一应用；

当满足第一切换条件时，以第二编译模式运行所述第一应用。

2.根据权利要求1所述的方法，其特征在于，所述第一应用是以BOTH形态打包的方舟应用。

3.根据权利要求1或2所述的方法，其特征在于，所述第一切换条件为以下条件的至少一种：

所述第一应用的崩溃次数达到第一阈值；或

当前系统内存占用超过第二阈值；或

所述第一应用的内存占用超过第三阈值；或

所述第一应用的页面响应速度低于第四阈值；或

所述第一应用以所述第一编译模式运行时间超过第五阈值；或

用户的位置信息发生改变；或

所述第二编译模式的编译器性能优于所述第一编译模式的编译器性能；或

当前系统时间处于预设时间段内。

4.根据权利要求1-3所述的方法，其特征在于，当所述第一切换条件为所述第一应用的崩溃次数达到第一阈值时，所述方法还包括：

记录所述第一应用的崩溃次数，将所述第一应用设置为切换状态；

在所述第一应用重新启动时，检测所述第一应用是否是切换状态；

如果所述第一应用是切换状态，则以所述第二编译模式运行所述第一应用。

5.根据权利要求1-4所述的方法，其特征在于，所述方法还包括：

当满足第二切换条件时，以所述第一编译模式运行所述第一应用。

6.根据权利要求5所述的方法，其特征在于，所述第二切换条件为：

所述第一应用以所述第二编译模式运行后的崩溃次数大于所述第一阈值。

7.根据权利要求5所述的方法，其特征在于，所述第二切换条件为：

检测到所述第一应用在所述第一编译模式下的崩溃漏洞被修复。

8.根据权利要求1-7所述的方法，其特征在于，所述第一应用运行的进程下还包括第二应用，所述方法还包括：

当以所述第二编译模式运行所述第一应用时，切换所述第二应用的编译模式为所述第二编译模式。

9.根据权利要求8所述的方法，其特征在于，所述第二应用的启动时间早于所述第一应用的启动时间。

10.根据权利要求8所述的方法，其特征在于，所述第二应用的启动时间晚于所述第一应用的启动时间。

11.根据权利要求1所述的方法，其特征在于，所述第一应用的运行依赖于第三应用，所述第一切换条件为：

所述第三应用的APK状态发生变化。

12.根据权利要求1所述的方法，其特征在于，所述第一应用的运行依赖于第三应用，所述第一切换条件为：

所述第三应用切换为以所述第二编译模式运行。

13.根据权利要求1所述的方法，其特征在于，所述方法还包括：

在创建所述第一应用时，根据所述第一应用的API信息生成第一校验值；

将所述第一校验值打包到所述第一应用的APK中；

将操作系统提供的API信息生成第二校验值，将所述第二校验值打包到所述操作系统中；

当所述第一应用的状态改变时，比对所述第一校验值和所述第二校验值；

根据比对结果，切换所述第一应用的编译模式。

14.根据权利要求13所述的方法，其特征在于，所述比对所述第一校验值和所述第二校验值为：检测所述第一校验值是否为所述第二校验值的子集；

所述根据比对结果，切换所述第一应用的编译模式，具体为：如果所述第一校验值不是所述第二校验值的子集，则切换所述第一应用的编译模式。

15.根据权利要求1-14所述的方法，其特征在于：

所述第一编译模式为Android编译模式，所述第二编译模式为方舟编译模式；或者，

所述第一编译模式为方舟编译模式，所述第二编译模式为Android编译模式。

16.一种电子设备，包括第一编译模块，第二编译模块，切换模块，其特征在于：

所述第一编译模块，用于以第一编译模式运行第一应用；

所述切换模块，用于确定当满足第一切换条件时，使得所述第一应用从所述第一编译模式切换为第二编译模式运行；

所述第二编译模块，用于以所述第二编译模式运行所述第一应用。

17.根据权利要求16所述的电子设备，其特征在于，所述第一应用是以BOTH形态打包的方舟应用。

18.根据权利要求16或17所述的电子设备，其特征在于，所述第一切换条件为以下条件的至少一种：

所述第一应用的崩溃次数达到第一阈值；或

当前系统内存占用超过第二阈值；或

所述第一应用的内存占用超过第三阈值；或

所述第一应用的页面响应速度低于第四阈值；或

所述第一应用以所述第一编译模式运行时间超过第五阈值；或

用户的位置信息发生改变；或

所述第二编译模块的性能优于所述第一编译模块的性能；或

当前系统时间处于预设时间段内。

19.根据权利要求16-18所述的电子设备，所述电子设备还包括崩溃记录模块，重启检测模块，其中，所述第一切换条件为所述第一应用的崩溃次数达到第一阈值，其特征在于：

所述崩溃记录模块，用于记录所述第一应用的崩溃次数，将所述第一应用设置为切换状态；

所述重启检测模块，用于在所述第一应用重新启动时，检测所述第一应用是否是切换状态；

所述第二编译模块，用于确定当所述第一应用是切换状态，则以所述第二编译模式运行所述第一应用。

20.根据权利要求16-19所述的电子设备，其特征在于，所述第一编译模块还用于：

当满足第二切换条件时，以所述第一编译模式运行所述第一应用。

21.根据权利要求20所述的电子设备，其特征在于，所述第二切换条件为：

所述第一应用以所述第二编译模式运行后的崩溃次数大于所述第一阈值。

22.根据权利要求20所述的电子设备，其特征在于，所述第二切换条件为：

检测到所述第一应用在所述第一编译模式下的崩溃漏洞被修复。

23.根据权利要求1-7所述的电子设备，所述第一应用运行的进程下还包括第二应用，其特征在于：

所述切换模块，用于当以所述第二编译模式运行所述第一应用时，切换所述第二应用的编译模式为所述第二编译模式。

24.根据权利要求23所述的电子设备，其特征在于，所述第二应用的启动时间早于所述第一应用的启动时间。

25.根据权利要求23所述的电子设备，其特征在于，所述第二应用的启动时间晚于所述第一应用的启动时间。

26.根据权利要求16所述的电子设备，其特征在于，所述第一应用的运行依赖于第三应用，所述第一切换条件为：

所述第三应用的APK状态发生变化。

27.根据权利要求16所述的电子设备，其特征在于，所述第一应用的运行依赖于第三应用，所述第一切换条件为：

所述第三应用切换为以所述第二编译模式运行。

28.根据权利要求16所述的电子设备，所述电子设备还包括第一校验码生成模块，第二校验码生成模块，比对模块，其特征在于：

所述第一校验码生成模块，用于在创建所述第一应用时，根据所述第一应用的API信息生成第一校验值，所述将所述第一校验值打包到所述第一应用的APK中；

所述第二校验码生成模块，用于将操作系统提供的API信息生成第二校验值，将所述第二校验值打包到所述操作系统中；

所述比对模块，用于当所述第一应用的状态改变时，比对所述第一校验值和所述第二校验值；

所述切换模块，用于根据比对结果，切换所述第一应用的编译模式。

29.根据权利要求28所述的电子设备，其特征在于，所述比对所述第一校验值和所述第二校验值为：检测所述第一校验值是否为所述第二校验值的子集；

所述根据比对结果，切换所述第一应用的编译模式，具体为：如果所述第一校验值不是所述第二校验值的子集，则切换所述第一应用的编译模式。

30.根据权利要求16-29所述的电子设备，其特征在于：

所述第一编译模块为Android编译模块，所述第二编译模块为方舟编译模块；或者，

所述第一编译模块为方舟编译模块，所述第二编译模块为Android编译模块。

31.一种电子设备，包括第一编译器，第二编译器，处理器，其特征在于：

所述第一编译器被配置为，以第一编译模式运行第一应用；

所述处理器被配置为，确定当满足第一切换条件时，使得所述第一应用从所述第一编译模式切换为第二编译模式运行；

所述第二编译器被配置为，以所述第二编译模式运行所述第一应用。

32.一种电子设备，其特征在于，所述电子设备包括：一个或多个处理器、存储器，所述存储器用于存储计算机程序代码，所述计算机程序代码包括指令，当所述一个或多个处理器执行所述指令时，所述电子设备执行如权利要求1-15中任意一项所述的方法。

33.一种计算机可读存储介质，其特征在于，包括计算机指令，当所述计算机指令在电子设备上运行时，使得所述电子设备执行如权利要求1-15中任意一项所述的方法。

34.一种计算机程序产品，其特征在于，当所述计算机程序产品在计算机上运行时，使得所述计算机执行如权利要求1-15中任一项所述的方法。

35.一种芯片，其特征在于，包括：处理器和接口，用于从存储器中调用并运行所述存储器中存储的计算机程序，执行如权利要求1-15中任一项所述的方法。

Images