CN109791497B - 一种执行热补丁的方法、装置及终端 - Google Patents

Abstract

本发明实施例提供一种执行热补丁的方法、装置及终端，能够解决因编译时间过长而导致的终端黑屏、应用卡顿等现象，降低用户体验的问题。该执行热补丁的方法包括：终端下载应用的热补丁；终端加载、编译并运行热补丁，编译为采用第一编译模式完成热补丁的格式转换；若应用未在前台运行，且终端按照第一编译模式运行完热补丁，则终端再次编译热补丁，再次编译为采用第二编译模式完成热补丁的格式转换。本发明实施例适用于终端。

Description

一种执行热补丁的方法、装置及终端

本申请要求于2017年5月17日提交中国专利局、申请号为201710349599.3、申请名称为“一种加载热补丁的方法和设备”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。

技术领域

本发明实施例涉及通信技术领域，尤其涉及一种执行热补丁的方法、装置及终端。

背景技术

应用开发者为了给用户提供更加优质的应用使用效果，往往会对应用进行修复或是针对用户需求增加、改善相应功能。以安卓系统为例，传统的应用更新是指应用开发者发布一个完整的安卓安装包(Android Package，APK)程序，即一个包括了可执行的dex代码程序、各类资源、so库、布局(layout)等文件的zip格式的压缩包，用户可以使用终端从各种应用市场或官网下载该APK，由终端系统通过重新安装该应用以实现达到应用更新的目的。

对于压缩包较大的应用而言，上述方式会造成更新过慢影响用户使用的问题，因此，业界提出了热补丁更新这种相较于传统更新方式更加快速的更新技术。热补丁更新技术的特别之处在于无需单独发布一个独立的应用版本，用户无感知更新，适用于修复应用的紧急问题。热补丁(patch)，指能够修复软件漏洞的一些代码，是一种快速、低成本修复产品软件版本缺陷的方式。例如，在安卓(android)系统中，此种修复方式对用户来说是无感的，通常就是指一段从服务器或者其他方式获取到的可在android系统中运行的可执行代码(或可转为代码)的文件。在应用执行需要修复的代码逻辑和业务时，优先执行热补丁中的代码，从而达到修复问题的目的。

发明内容

本发明实施例提供一种执行热补丁的方法、装置及终端，能够解决编译过程中因采用固定编译模式所带来的编译时间过长而引发的终端黑屏、应用卡顿等问题。

第一方面，本发明实施例提供一种执行热补丁的方法，该方法包括：终端下载应用的热补丁，之后加载、编译并运行热补丁，若应用未在前台运行，且终端按照第一编译模式运行完热补丁，则终端再次编译热补丁。其中，编译为采用第一编译模式完成热补丁的格式转换；再次编译为采用第二编译模式完成热补丁的格式转换。相比较于现有技术中采用单一编译模式执行热补丁过程中，因编译时间过长而导致的终端黑屏、应用卡顿等现象，降低用户体验的情况，本发明实施例结合应用的运行情况调整编译模式，使应用在不同运行状态下采用不同的编译模式编译热补丁，即最初按照第一编译模式加载、编译并运行热补丁，待应用从前台运行的状态切换至非前台运行的状态后，采用第二编译模式编译已采用第一编译模式加载、编译并运行完的热补丁。这样在实际编译过程中，可以结合用户当前的需求，更有效利用不同编译模式的优点，从而解决编译过程中因采用固定编译模式所带来的编译时间过长而引发的终端黑屏、应用卡顿等问题。

在一种可能的设计中，按照第一编译模式编译热补丁的时间小于按照第二编译模式编译热补丁的时间，且按照第一编译模式运行热补丁的时间大于按照第二编译模式运行热补丁的时间。这样在热补丁在前台处于编译过程中，由于采用第一编译模式编译热补丁的时间小于采用第二编译模式编译热补丁的时间，因此，可以有效节省热补丁的编译时间；在热补丁运行过程中，由于采用第二编译模式运行热补丁的速度大于采用第一编译模式运行热补丁的速度，因此，当应用切换至非前台运行的状态后，在用户无感知的情况下使用运行速度较快的编译方式来优化运行程序的时间。由此可见，采用多种编译模式完成热补丁的执行，不仅可以缩短热补丁在前台编译所占用的时间，同样可以保证运行程序的时间，从而减少因编译时间过长而导致的终端黑屏、应用卡顿等现象，且不会影响到后续程序的运行，进而提升用户体验。

在一种可能的设计中，在终端加载、编译并运行热补丁之前，终端在配置文件中查找是否存在应用的标识，配置文件至少包括需要采用快速编译模式加载、编译并运行热补丁的应用的标识，其中，第一编译模式属于快速编译模式。之后终端加载、编译并运行热补丁，可以实现为：若配置文件中存在应用的标识，则终端按照配置文件中与应用的标识对应的编译模式加载、编译并运行热补丁，或者，终端按照默认的编译模式加载、编译并运行热补丁。考虑到采用编译模式切换的方式执行热补丁，会出现采用不同编译模式重复对同一热补丁进行编译的情况，而有的热补丁本身很小，即便采用现有技术的编译模式来编译并运行，也不会浪费太多时间完成热补丁的编译和运行，因此，可以仅针对部分应用的热补丁、或是某个或某些热补丁，采用编译模式切换的方式执行，而并非针对所有热补丁。

在一种可能的设计中，在终端在配置文件中查找是否存在应用的标识之后，若配置文件中不存在应用的标识，则终端按照第二编译模式加载、编译并运行热补丁，并记录用于反映热补丁执行情况的参数。为了给用户提供更好的体验，配置文件一旦确定并不会一成不变，后续可以结合热补丁的执行情况对配置文件进行调整，因此，对于当前不需要采用编译模式切换的方式执行的热补丁而言，在执行热补丁过程中或是在完成热补丁执行过程之后，需要记录用于反映热补丁执行情况的参数，而所记录的这些参数后续可以用于对热补丁执行情况进行分析，以便后续更新配置文件。

在一种可能的设计中，参数包括热补丁的大小和加载时间中的至少一项。由于热补丁的大小会直接影响编译时间，而编译时间和加载时间都会直接影响执行热补丁过程所耗费的时间，因此，可以将热补丁的大小和/或加载时间作为掌握热补丁执行情况的参数，供后续生成或是更新配置文件所用。

在一种可能的设计中，在终端记录用于反映热补丁执行情况的参数之后，终端向服务器发送热补丁和参数，并在终端处于空闲状态时，终端从服务器获取更新后的配置文件。配置文件的更新可以及时调整不同热补丁所采用的编译方式，即热补丁是否需要采用切换编译模式的方式进行编译并运行。这样能够尽可能降低因未及时将需要采用切换编译模式的方式进行编译的热补丁对应的应用的标识添加至配置文件中，而导致该终端继续采用单一的编译模式对热补丁进行编译的概率，从而尽可能减少终端黑屏、应用卡顿等情况的发生。当然也降低因未及时将需要采用单一编译模式进行编译的热补丁对应的应用的标识从配置文件中删除，而导致该终端仍然需要对相同的热补丁进行多次编译的概率，从而避免额外的资源浪费。

在一种可能的设计中，在终端再次编译热补丁之前，终端记录完成加载的热补丁的存储路径，并按照存储路径查找完成加载的热补丁。对于采用本发明实施例执行的热补丁而言，考虑到很可能需要执行两次编译过程，因此在完成热补丁的加载后需要记录该热补丁的存储路径，以便终端第二次对该热补丁进行编译时能够成功获取到完成加载的热补丁。

第二方面，本发明实施例提供一种执行热补丁的装置。该装置可以实现上述方法实施例中所实现的功能，所述功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。所述硬件或软件包括一个或多个上述功能相应的模块。

在一种可能的设计中，该装置应用于终端，该终端的结构中包括处理器和收发器，该处理器被配置为支持该装置执行上述方法中相应的功能。该收发器用于支持该装置与其他网元之间的通信。该装置还可以包括存储器，该存储器用于与处理器耦合，其保存该终端必要的程序指令和数据。

第三方面，本发明实施例提供一种计算机存储介质，该计算机可读介质上存储有计算机程序，该计算机程序加载到计算机上被计算机执行时，使计算机执行第一方面及第一方面的多种可能的设计中的任意一项。

第四方面，本发明实施例提供一种计算机程序产品，该计算机程序产品包含计算机程序，计算机程序被计算机执行，使计算机执行第一方面及第一方面的多种可能的设计中的任意一项。

附图说明

图1为本发明实施例提供的一种终端的结构示意图；

图2为本发明实施例提供的一种系统架构示意图；

图3为本发明实施例提供的一种特定场景下终端的显示界面跳转示意图；

图4为本发明实施例提供的一种应用的热补丁执行过程的示意图；

图5为本发明实施例提供的一种执行热补丁的方法流程图；

图6为本发明实施例提供的另一种执行热补丁的方法流程图；

图7为本发明实施例提供的另一种执行热补丁的方法流程图；

图8为本发明实施例提供的另一种执行热补丁的方法交互图；

图9为本发明实施例提供的另一种执行热补丁的方法交互图；

图10为本发明实施例提供的一种执行热补丁的装置结构示意图；

图11为本发明实施例提供的一种终端结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行描述。

本发明实施例可以用于一种终端，该终端可以包括笔记本电脑、智能手机等设备。该终端至少设置有显示屏、输入设备和处理器，以终端100为例，如图1所示，该终端100中包括处理器101、存储器102、摄像头103、RF电路104、音频电路105、扬声器106、话筒107、输入设备108、其他输入设备109、显示屏110、触控面板111、显示面板112、输出设备113、以及电源114等部件。其中，显示屏110至少由作为输入设备的触控面板111和作为输出设备的显示面板112组成。需要说明的是，图1中示出的终端结构并不构成对终端的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置，在此不做限定。

下面结合图1对终端100的各个构成部件进行具体的介绍：

射频(Radio Frequency，RF)电路104可用于收发信息或通话过程中，信号的接收和发送，比如，若该终端100为手机，那么该终端100可以通过RF电路104，将基站发送的下行信息接收后，传送给处理器101处理；另外，将涉及上行的数据发送给基站。通常，RF电路包括但不限于天线、至少一个放大器、收发信机、耦合器、低噪声放大器(Low NoiseAmplifier，LNA)、双工器等。此外，RF电路104还可以通过无线通信与网络和其他设备通信。该无线通信可以使用任一通信标准或协议，包括但不限于全球移动通讯系统(GlobalSystem of Mobile communication，GSM)、通用分组无线服务(General Packet RadioService，GPRS)、码分多址(Code Division Multiple Access，CDMA)、宽带码分多址(Wideband Code Division Multiple Access，WCDMA)、长期演进(Long Term Evolution，LTE)、电子邮件、短消息服务(Short Messaging Service，SMS)等。

存储器102可用于存储软件程序以及模块，处理器101通过运行存储在存储器101的软件程序以及模块，从而执行终端100的各种功能应用以及数据处理。存储器101可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如，声音播放功能、图象播放功能等)等；存储数据区可存储根据终端100的使用所创建的数据(比如，音频数据、视频数据等)等。此外，存储器101可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

其他输入设备109可用于接收输入的数字或字符信息，以及产生与终端100的用户设置以及功能控制有关的键信号输入。具体地，其他输入设备109可包括但不限于物理键盘、功能键(比如，音量控制按键、开关按键等)、轨迹球、鼠标、操作杆、光鼠(光鼠是不显示可视输出的触摸敏感表面，或者是由触摸屏形成的触摸敏感表面的延伸)等中的一种或多种。其他输入设备109还可以包括终端100内置的传感器，比如，重力传感器、加速度传感器等，终端100还可以将传感器所检测到的参数作为输入数据。

显示屏110可用于显示由用户输入的信息或提供给用户的信息以及终端100的各种菜单，还可以接受用户输入。此外，显示面板112可以采用液晶显示器(Liquid CrystalDisplay，LCD)、有机发光二极管(Organic Light-Emitting Diode，OLED)等形式来配置显示面板112；触控面板111，也称为触摸屏、触敏屏等，可收集用户在其上或附近的接触或者非接触操作(比如，用户使用手指、触笔等任何适合的物体或附件在触控面板111上或在触控面板111附近的操作，也可以包括体感操作；该操作包括单点控制操作、多点控制操作等操作类型)，并根据预先设定的程式驱动相应的连接装置。需要说明的是，触控面板111还可以包括触摸检测装置和触摸控制器两个部分。其中，触摸检测装置检测用户的触摸方位、姿势，并检测触摸操作带来的信号，将信号传送给触摸控制器；触摸控制器从触摸检测装置上接收触摸信息，并将它转换成处理器101能够处理的信息，再传送给处理器101，并且，还能接收处理器101发来的命令并加以执行。此外，可以采用电阻式、电容式、红外线以及表面声波等多种类型实现触控面板111，也可以采用未来发展的任何技术实现触控面板111。一般情况下，触控面板111可覆盖显示面板112，用户可以根据显示面板112显示的内容(该显示内容包括但不限于软键盘、虚拟鼠标、虚拟按键、图标等)，在显示面板112上覆盖的触控面板111上或者附近进行操作，触控面板111检测到在其上或附近的操作后，传送给处理器101以确定用户输入，随后处理器101根据用户输入，在显示面板112上提供相应的视觉输出。虽然在图1中，触控面板111与显示面板112是作为两个独立的部件来实现终端100的输入和输出功能，但是在某些实施例中，可以将触控面板111与显示面板112集成，以实现终端100的输入和输出功能。

RF电路104、扬声器106，话筒107可提供用户与终端100之间的音频接口。音频电路105可将接收到的音频数据转换后的信号，传输到扬声器106，由扬声器106转换为声音信号输出；另一方面，话筒107可以将收集的声音信号转换为信号，由音频电路105接收后转换为音频数据，再将音频数据输出至RF电路104以发送给诸如另一终端的设备，或者将音频数据输出至存储器102，以便处理器101结合存储器102中存储的内容进行进一步的处理。另外，摄像头103可以实时采集图像帧，并传送给处理器101处理，并将处理后的结果存储至存储器102和/或将处理后的结果通过显示面板112呈现给用户。

处理器101是终端100的控制中心，利用各种接口和线路连接整个终端100的各个部分，通过运行或执行存储在存储器102内的软件程序和/或模块，以及调用存储在存储器102内的数据，执行终端100的各种功能和处理数据，从而对终端100进行整体监控。需要说明的是，处理器101可以包括一个或多个处理单元；处理器101还可以集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面(User Interface，UI)和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器101中。

终端100还可以包括给各个部件供电的电源114(比如，电池)，在本发明实施例中，电源114可以通过电源管理系统与处理器101逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗等功能。

此外，图1中还存在未示出的部件，比如，终端100还可以包括蓝牙模块、近距离无线通讯技术(Near Field Communication，NFC)模块、无线保真(Wireless-Fidelity，Wi-Fi)模块、全球定位系统(global positioning system，GPS)模块、扬声器、加速计、陀螺仪等，在此不再赘述。其中，蓝牙模块，可用于手机在特定距离内(蓝牙协议规定的距离内)与其他支持蓝牙功能的设备建立蓝牙连接并互相通信；NFC模块，可用于手机与其他支持NFC通信的设备建立NFC连接并互相通信；终端100可通过Wi-Fi模块建立Wi-Fi连接并进行数据传输。

对于应用而言，在应用处于非前台运行状态时，终端可以通过联网检测该应用是否存在热补丁，若存在，则在下载热补丁后执行该热补丁，具体实现方式可以参考如图4所示的实现流程。

本发明实施例可以用于一种系统，如图2所示，该系统不仅包括如图1所示的终端，至少还包括服务器。其中，终端与服务器之间可以进行数据交互，比如，终端可以从服务器获取配置文件、热补丁等内容，服务器可以从终端获取热补丁及包括该热补丁的大小、加载时间等参数。需要说明的是，上述服务器可以为至少一个，比如，当服务器有多个时，终端可以从一个服务器获取配置文件，并从另一个服务器获取热补丁；终端与服务器之间的交互流程以及交互过程中所涉及的传输内容会在后文提出，在此不赘述。

为了便于理解本发明实施例所描述的技术方案，在此对本发明实施例中所涉及的关键术语、缩略语等进行解释，具体内容如下：

其中，热补丁的执行过程包括了热补丁的加载、编译和运行。若应用处于前台运行，则在热补丁完成编译后，直接运行编译后的oat文件，若应用处于非前台运行，则在热补丁完成编译后，可以直接运行编译后的oat文件，或是待应用再次处于前台运行后，运行编译后的oat文件。需要说明的是，对于用户可感知的热补丁的执行过程而言，如图3所示，终端的显示界面可以按照箭头指向，依次呈现显示界面a至显示界面g。终端的显示界面可以通过呈现对话框的形式来询问用户是否需要执行应用A的热补丁。若用户通过点击、滑动等操作，选中“是”，则认为用户当前需要执行应用A的热补丁，此时终端的显示界面a可以跳转至显示界面b，即呈现热补丁的加载进度，具体呈现形式可以为采用动态变化的进度条实时向用户呈现加载进度，和/或通过显示加载完成的百分比，以更加直观地将加载进度呈现给用户，当然还可以包括其他呈现形式。需要说明的是，对于显示界面b、d、f所呈现的处理进度，可以选择性地向用户呈现，比如，对于那些处理时间较长的过程，可以通过这种处理进度呈现的方式使用户实时了解处理进度，进而大大减少了因用户等待时间过程而选择退出执行热补丁过程的情况。当然，在本发明实施例中，若终端不向用户呈现上述处理进度的显示界面，终端也可以直接在某一过程完成后，通过响铃、语音提示、文字提示等方式告知用户当前这一过程已完成，即将进入下一过程。在应用A的热补丁加载完成后，终端同样可以通过弹出对话框的方式，询问用户是否需要对完成加载的热补丁进行编译，并在完成编译后询问用户是否需要运行热补丁，且在热补丁执行完后，通过弹出对话框的方式，询问用户是否需要直接跳转至应用A的访问界面。需要说明的是，上述热补丁完成加载后，也可以由终端直接进行热补丁的编译、运行过程，在这一过程中，无需再次询问用户的需求，并且可以选择性地向用户呈现当前每个过程的处理进度。当然，为了给用户带来更好的用户体验，避免多次弹出用于触发下一过程的对话框而给用户带来的不便，在本发明实施例中，终端也可以在单次询问过程中，一次性征求用户的多个操作建议，比如，终端通过弹出一个对话框来分别询问用户是否需要编译热补丁，以及若需要编译，在编译完成后是否需要直接运行等。上述实现流程，仅为一种可能的实现方案，对于用户无感知的热补丁执行过程而言，在终端的显示界面中不需要向用户呈现任何内容。此外，对于上述用户有感知的热补丁执行过程而言，终端在各个阶段所呈现的具体内容，也要参照目前热补丁执行过程所实际呈现的内容，本发明实施例中，可以不对显示界面的呈现内容做任何改变。此外，对于本发明实施例中提及的采用两种不同的编译模式编译热补丁的过程而言，若原有编译过程需要在显示界面呈现相应内容，那么此时可以认为终端在两个不同的时间节点，分别向用户呈现两种不同的编译模式编译热补丁所产生的相应数据，比如，编译进度等，在此不做限定。

其中，热补丁的加载指的是将下载完的热补丁存储到内存中；热补丁的编译指的是将存储到内存中的dex文件转化为可运行的机器码，比如oat文件；热补丁的运行指的是运行完成编译后的oat文件。需要说明的是，在本发明实施例中以dex文件、oat文件为例进行描述，热补丁还可以为其他格式的文件，在此不做限定。

相对于前台运行而言，非前台运行包括了应用处于后台运行的状态，当然也可以包括终端处于空闲状态或是待机状态的情况，在此不一一例举。其中，在终端处于空闲状态时，可以被视为终端具有足够的空闲资源用于支持热补丁的编译。

对于用户而言，在前台运行的应用即为当前终端显示屏呈现给用户的界面所对应的应用。

热补丁为通过服务器下发的针对特定应用版本进行修复问题的形式，可以直接是dex包这类安卓系统可识别、可加载的程序格式，也可以是应用自定义的某些格式，但是在加载的过程中，应用通过各种转化，形成系统可识别、可加载运行的dex格式。其中，dex为安卓系统中可执行的程序代码打包格式。在本发明实施例中，热补丁可以被视为应用单独下载的一段可执行的代码，或是可转化为可执行代码的其他文件。在本发明实施例中，以热补丁为dex文件为例进行描述，但并不作为对热补丁实现形式的限定。

oat文件为一种安卓系统私有ELF文件格式，它不仅包含有从dex文件翻译而来的本地机器指令，还包含有原来的dex文件内容。

运行环境(android runtime，art)虚拟机和Dalvik虚拟机(Dalvik VirtualMachine，DVM)一样都是安卓中使用的虚拟机，不同的是在安装应用的过程中，将dex文件预先编译成机器码，运行时直接运行机器码。其中，对于Dalvik虚拟机而言，所有安卓程序都运行在安卓系统进程里，每个进程对应着一个Dalvik虚拟机实例，运行时对应用的dex文件进行解释执行。

如图4所示，为一种应用的热补丁执行过程的示意图。

步骤1、下载dex文件。

需要说明的是，在应用处于前台运行或是非前台运行状态时，都可以下载应用的dex文件。一般情况下，为了不影响应用的正常使用，往往在应用处于非前台运行状态时才进行dex文件的下载，以确保在该应用处于前台运行状态时能充足的资源。

步骤2、加载dex文件。

在完成dex文件的下载后，为了方便后续dex文件的编译、运行，在本发明实施例中，需要将下载完的dex文件加载到内存中。

步骤3、确定是否存在oat文件。若存在，则执行步骤4或执行步骤5；若不存在，则执行步骤6。

步骤4、若oat文件为最新版本，则运行oat文件。

步骤5、若oat文件为非最新版本，则将dex文件转化为oat文件并运行。

步骤6、将dex文件转化为oat文件并运行。

考虑到应用初次在终端上安装、终端升级、终端刚刚开机等情况，有可能已生成的oat文件不是最新版本的oat文件，这样若仍然运行已有oat文件，就无法成功执行热补丁，因此，如图4所示，在完成dex文件的加载后，不仅需要确定是否存在oat文件，还需要确定在存在oat文件的情况下，该oat文件是否为最新版本，对于不是最新版本的oat文件而言，在本发明实施例中，需要重新对完成加载的dex文件进行编译，即将该dex文件转化为最新版本的oat文件，之后运行。

其中，生成最新版本的oat文件的方式可以为dex2oat，但该方式并不作为本发明实施例的限定，还可以采用其他方式将dex文件转化为最新版本的oat文件。

需要说明的是，为了保证运行的oat文件为最新版本的oat文件，上述步骤3至步骤6是必不可少的，而目前所采用的编译模式往往会使步骤6耗费大量时间，从而因编译时间过长而导致的终端黑屏、应用卡顿等现象，降低用户体验。

以安卓系统为例，在使用运行环境(android runtime，art)虚拟机的安卓系统上加载热补丁的dex文件时，调用的接口是loadDex，这是一种叫做forced-dexopt方式的加载方式，所采用的编译模式是speed方式的编译模式。其中，speed方式的编译模式属于全量编译成机器码模式，该编译方式的特点是生成的oat文件较大，从而增加编译时间，然而在程序运行的时候所用时间较短。

由此可见，在编译过程中因采用固定编译模式所带来的编译时间过长而引发的终端黑屏、应用卡顿等问题。因此，在本发明实施例中，改变原有对热补丁采用单一编译模式的形式，在应用从前台切换至非前台运行后，采用另一种编译模式对热补丁进行编译、运行，以提高编译热补丁的速度，同时保证或是提高运行已完成编译的热补丁的速度。

本发明实施例提供一种执行热补丁的方法，如图5所示，该方法可以由图1所示的终端100执行，该方法包括：

步骤201、终端下载应用的热补丁。

应用户需求或是预先配置，终端可以从诸如应用商店等类似的平台、网站完成热补丁的下载，之后采用第一编译模式加载、编译并运行热补丁。

步骤202、终端加载、编译并运行热补丁。

其中，编译为采用第一编译模式完成热补丁的格式转换。

上述第一编译模式与现有技术中采用的编译模式不同，在本发明实施例中，可以将现有技术中采用的编译模式视为下文提到的第二编译模式，当然，第二编译模式除了可以为现有技术中采用的编译模式，还可以为其他运行速度较快的编译模式，同样的，第一编译模式可以为其他编译速度较快的编译模式，在此对于编译模式具体为哪个不限定。需要说明的是，在现有技术中，由于oat文件较大、编译时间过长，往往会导致热补丁在编译过程中出现长时间卡住的情况，从而导致终端黑屏、应用卡顿等现象，降低用户体验。为了进一步解决上述问题，在本发明实施例中，按照第一编译模式编译热补丁的时间小于按照第二编译模式编译热补丁的时间，且按照第一编译模式运行热补丁的时间大于按照第二编译模式运行热补丁的时间。由于采用第一编译模式编译热补丁的时间小于采用第二编译模式编译热补丁的时间，因此，采用第一编译模式完成格式转换得到的编译后热补丁内容简单，而采用第二编译模式完成格式转换得到的编译后热补丁内容复杂，且相比较于前一情况，内容更加详细，易于运行。由此可见，同一热补丁，不同的编译时长会影响编译后热补丁的内容详细程度，进而影响后续运行过程的难易程度。

编译模式是指执行dex文件的模式，比如interpret-only模式、speed模式、speed-profile模式等，在此不一一例举。其中，interpret-only模式的编译速度较快，但在完成编译后运行程序时速度较慢；speed模式属于全量编译成机器码模式，该编译模式的编译时间长、生成的oat文件较大，但在运行程序时所用时间较短；speed-profile模式属于部分热点方法编译成机器码模式。需要说明的是，编译速度较快的模式除了interpret-only模式，还包括verify-none模式、verify-at-runtime模式等。

步骤203、若应用未在前台运行，且终端按照第一编译模式运行完热补丁，则终端再次编译热补丁。

其中，再次编译为采用第二编译模式完成热补丁的格式转换。

需要说明的是，应用未在前台运行可以被视为应用处于上述非前台的运行状态。也就意味着，在应用从未在前台运行的状态重新切换回在前台运行的状态后，热补丁仍继续采用第二编译模式进行编译，或是在采用第二编译模式完成编译后，直接在前台运行时运行完成编译的热补丁。当然，根据用户需求或是其他指令指示，也可以在后台完成第二编译模式的编译后直接运行。

对于采用第一编译模式执行的热补丁而言，若在前台运行该应用时采用第一编译模式完成了热补丁的编译以及部分热补丁的运行，那么在该应用切换至未在前台运行的状态后，需要将未运行完的热补丁运行完之后，再采用第二编译模式重新实现热补丁的编译。若在前台运行该应用时仅采用第一编译模式完成了热补丁的编译，而并未运行编译完的热补丁，且该应用切换至未在前台运行的状态，那么此时虽然完成编译的热补丁未运行，但在本发明实施例中，需要运行完该热补丁后再采用第二编译模式实现热补丁的编译。上述示例仅作为一种可能的实现方式提出，并不作为对本发明实施例的过多限定，当然在本发明实施例中可能出现的情况也不仅仅包括上述两种情况。

结合上述示例可以得知，无论采用哪种实现方式，最终在应用的运行状态切换回前台运行的状态后，若采用第二编译模式还未完成热补丁的编译，则重新回到前台运行的应用会继续沿用第二编译模式完成热补丁的编译。

相比较于现有技术中采用单一编译模式执行热补丁过程中，因编译时间过长而导致的终端黑屏、应用卡顿等现象，降低用户体验的情况，本发明实施例结合应用的运行情况调整编译模式，使应用在不同运行状态下采用不同的编译模式编译热补丁，即最初按照第一编译模式加载、编译并运行热补丁，待应用从前台运行的状态切换至非前台运行的状态后，采用第二编译模式编译已采用第一编译模式加载、编译并运行完的热补丁。这样在热补丁在前台处于编译过程中，由于采用第一编译模式编译热补丁的时间小于采用第二编译模式编译热补丁的时间，因此，可以有效节省热补丁的编译时间；在热补丁运行过程中，由于采用第二编译模式运行热补丁的速度大于采用第一编译模式运行热补丁的速度，因此，当应用切换至非前台运行的状态后，在用户无感知的情况下使用运行速度较快的编译方式来优化运行程序的时间。由此可见，采用多种编译模式完成热补丁的执行，不仅可以缩短热补丁在前台编译所占用的时间，同样可以保证运行程序的时间，从而减少因编译时间过长而导致的终端黑屏、应用卡顿等现象，且不会影响到后续程序的运行，进而提升用户体验。

考虑到采用编译模式切换的方式执行热补丁，会出现采用不同编译模式重复对同一热补丁进行编译的情况，而有的热补丁本身很小，即便采用现有技术的编译模式来编译并运行，也不会浪费太多时间完成热补丁的编译和运行，因此，在本发明实施例一种可能的实现方式中，可以仅针对部分应用的热补丁、或是某个或某些热补丁，采用编译模式切换的方式执行，而并非针对所有热补丁。因此，在如图5所示的实现方式的基础上，还可以实现为如图6所示的实现方式。其中，在执行步骤202终端加载、编译并运行热补丁之前，还可以执行步骤301；步骤202可以实现为步骤302；此外，在执行完步骤301之后还可以根据判定结果来选择执行步骤302或是步骤303：

步骤301、终端在配置文件中查找是否存在应用的标识。若配置文件中存在应用的标识，则执行步骤302；否则，执行步骤303。

其中，配置文件至少包括需要采用快速编译模式编译并运行热补丁的应用的标识，第一编译模式属于快速编译模式。需要说明的是，上述快速编译模式指的是加载、编译速度较快的编译模式。

配置文件可以为预存在终端本地的文件，或是终端在需要该配置文件时，通过网络、蓝牙等通讯方式从其他诸如服务器、终端的设备上直接获取到的文件，也可以是终端从云端获取的文件，在此对配置文件的来源不做限定。此外，配置文件中的内容可以由工作人员根据历史经验值进行设置，比如，设置某类或是某个应用的热补丁需要采用本发明实施例所提供的实现方式执行，或是以热补丁的类别作为区分编译方式的依据等；或者，配置文件中的内容可以结合用户的反馈信息来确定，比如，用户对于某个应用的使用评价等，在此对于配置文件的内容的确定方式不做限定。

应用标识用于区分不同的应用，可以为特定的字符或是字符串，在此不做限定。需要说明的是，应用标识可以占有多位，终端可以按照预置的规定，依据应用标识中的部分位或是全部位对应用的种类进行区分，之后针对某一类应用采用本发明实施例所提供的实现方式执行热补丁，当然也可以单独针对某个应用采用本发明实施例所提供的实现方式执行热补丁，在此不做限定。

步骤302、终端按照配置文件中与应用的标识对应的编译模式加载、编译并运行热补丁，或者，终端按照默认的编译模式加载、编译并运行热补丁。

在配置文件中，除了会记载应用的标识以外，还可能记载了该应用的热补丁在执行过程中需要采用的编译模式。对于配置文件中只记载了应用的标识的情况，可以采用默认的编译模式执行热补丁，其中，默认的编译模式属于快速编译模式的一种，默认的编译模式可以预先在终端内部配置，也可以预先设置相应的规则，从而使终端需要执行热补丁时调用相应的规则，在此不做限定。对于配置文件中记载了应用的标识以及该标识对应的编译模式的情况，执行热补丁时可以直接采用配置文件中记载的编译模式。需要说明的是，不同标识对应的编译模式可以相同或是不同，在此不做限定。

另外，无论应用当前处于前台还是非前台运行状态，对于需要初次执行的热补丁而言，均需要采用第一编译模式(即上述默认的编译模式，或配置文件中记载的编译模式)加载、编译并运行。

步骤303、终端按照第二编译模式加载、编译并运行热补丁，并记录用于反映热补丁执行情况的参数。

其中，参数包括热补丁的大小和加载时间中的至少一项。

在本发明实施例中，为了给用户提供更好的体验，配置文件一旦确定并不会一成不变，后续可以结合热补丁的执行情况对配置文件进行调整，因此，对于当前不需要采用编译模式切换的方式执行的热补丁而言，在执行热补丁过程中或是在完成热补丁执行过程之后，需要记录用于反映热补丁执行情况的参数，而所记录的这些参数后续可以用于对热补丁执行情况进行分析，以便后续更新配置文件。

需要说明的是，对于采用编译模式切换的方式执行的热补丁而言，若资源充足，也可以同样记录用于反映热补丁执行情况的参数，而这里的参数还可以包括热补丁采用不同编译模式进行编译所耗费的时间等，在此不做限定。另外，上述资源指的可以是终端的存储空间或是会影响到负载情况的资源等，在此不做限定。

为了实现配置文件的更新，在本发明实施例一种可能的实现方式中，终端需要将记载的参数及热补丁向服务器发送，并在终端处于空闲状态时从服务器获取更新后的配置文件。因此，在如图6所示的实现方式的基础上，还可以实现为如图7所示的实现方式。其中，在执行完步骤303终端按照第二编译模式加载、编译并运行热补丁，并记录用于反映热补丁执行情况的参数之后，还可以执行步骤401和步骤402：

步骤401、终端向服务器发送热补丁和参数。

终端可以周期性或是非周期性向服务器发送热补丁和参数，并且在发送热补丁和参数时，终端可以将多个热补丁及参数分多次或是一次性向服务器发送。在本发明实施例中，对于发送热补丁和参数的时机、方式等不做限定。

步骤402、在终端处于空闲状态时，终端从服务器获取更新后的配置文件。

空闲状态指的是终端具有充足的资源完成配置文件的更新，或是说在更新配置文件时不会影响终端中其他程序的运行等。由此可见，终端的空闲状态可以包括终端中空闲资源高于资源阈值时的运行状态，还可以包括终端的系统处于待机时的状态等，在此不做限定。

需要说明的是，若服务器中不存在更新后的配置文件，或是已经预先配置好在一段时间内不需要获取更新后的配置文件等，则终端即便处于空闲状态也无需实现配置文件的更新。另外，配置文件更新的时机、方式等不仅限于本发明实施例所提供的实现方式，也可以根据用户的需求或是预先配置的条件，选择合适的更新时机。

对于服务器而言，服务器在接收到终端发送的热补丁和参数之后，可以将热补丁与参数之间的对应关系存储在本地，并针对单个应用在一定时间内产生的热补丁对应的参数，来确定是否需要将该应用的标识添加至配置文件中。比如，对于加载时间大于时间阈值，和/或热补丁大小大于预设阈值的热补丁，则可以将该热补丁对应的应用的标识添加至配置文件中。需要说明的时，对于已经在配置文件中的标识对应的应用而言，也可以结合产生的参数，将该应用的标识从配置文件中删除。

当然，服务器可以仅完成热补丁、参数的存储，后续分析、处理过程可以由工作人员进行，或是配置相应的执行规则，由其他第三方设备或是该服务器按照执行规则对配置文件中标识的增减进行判断，在此不赘述。

配置文件的更新可以及时调整不同热补丁所采用的编译方式，即热补丁是否需要采用切换编译模式的方式进行编译并运行。这样能够尽可能降低因未及时将需要采用切换编译模式的方式进行编译的热补丁对应的应用的标识添加至配置文件中，而导致该终端继续采用单一的编译模式对热补丁进行编译的概率，从而尽可能减少终端黑屏、应用卡顿等情况的发生。当然也降低因未及时将需要采用单一编译模式进行编译的热补丁对应的应用的标识从配置文件中删除，而导致该终端仍然需要对相同的热补丁进行多次编译的概率，从而避免额外的资源浪费。

对于采用本发明实施例执行的热补丁而言，考虑到很可能需要执行两次编译过程，因此在完成热补丁的加载后需要记录该热补丁的存储路径，以便终端第二次对该热补丁进行编译时能够成功获取到完成加载的热补丁。因此，在如图5至图7所示的实现方式的基础上，以图5为例，还可以实现为如图8所示的实现方式。其中，在执行步骤203若应用未在前台运行，且终端按照第一编译模式加载、编译并运行完热补丁，则终端再次编译热补丁之前，还可以执行步骤501；步骤203可以实现为步骤502和步骤503：

步骤501、终端记录完成加载的热补丁的存储路径。

步骤502、若应用未在前台运行，且终端按照第一编译模式加载、编译并运行完热补丁，则终端按照存储路径查找完成加载的热补丁。

由此可见，若应用未在前台运行，但终端按照第一编译模式还未完成整个加载、编译并运行热补丁的操作，则需要在完成上述操作后，再按照存储路径查找完成加载的热补丁。针对这种情况而言，则会对完成加载的热补丁进行两次编译。

步骤503、终端按照第二编译模式编译热补丁。

需要说明的是，在采用第二编译模式完成热补丁的编译后，终端可以直接运行完成编译的热补丁，也可以待应用切换至前台运行的状态后再运行。

如图9所示，为一种如图2所示的终端和服务器之间可能的执行热补丁的实现过程。

步骤601、初始化热补丁配置文件。

初始化的过程可以被视为终端从本地、服务器等设备或是云端获取配置文件的过程。

步骤602、运行应用，并下载热补丁。

步骤603、查询配置文件，并获取不同热补丁所对应的不同处理方法。

在配置文件中，记载了需要特殊处理的热补丁对应的应用的标识。其中，特殊处理指的就是需要采用编译模式切换的方式执行热补丁的过程。

步骤604、处理配置文件中记录的需要特殊处理的热补丁，并按照原有流程处理配置文件中未记录的热补丁。

这里原有流程指的是背景技术中描述的热补丁执行过程，即采用单一编译模式完成热补丁的编译、运行。

步骤605、记录需要特殊处理的热补丁完成加载后的存储路径。

步骤606、选择一种快速编译的方法编译并运行热补丁。

若配置文件中已经记录了该热补丁对应的快速编译模式，则直接采用该快速编译模式对该热补丁进行编译并运行；若配置文件中未记录该热补丁对应的快速编译模式，则可以采用默认的快速编译模式对该热补丁进行编译并运行。

步骤607、待终端空闲时，编译记录了存储路径的已完成加载的热补丁。

终端空闲指的是该热补丁对应的应用处于非前台的运行状态。

步骤608、分析从客户端搜集的热补丁特征。

热补丁特征是指热补丁对应的参数，比如，热补丁的大小、热补丁的加载时间等。

步骤609、终端通过客户端搜集数据并向服务器发送。

步骤610、服务器向终端的客户端下发新的配置文件。

步骤611、在应用再次执行热补丁时，运行重新编译的热补丁。

以终端的系统未安卓系统为例，在本发明实施例中，可以通过安卓通用命令adbshell bugreport，检测到应用编译、运行热补丁时所采用的编译模式。当然，上述检测方式仅作为一种可能的实现方式，还可以采用其他能够识别出当前编译模式的方式对热补丁当前的编译模式进行检测，在此不赘述。

比如，检测到终端编译热补丁时采用的编译模式为interpret-only(如下)或是其他快速编译模式。

/data/user/0/com.xxxxxxx.mm/patch/odex/classes.dex：interpret-only

再比如，检测到终端第二次运行热补丁时采用的编译模式为speed模式(如下)。

/data/user/0/com.xxxxxxx.mm/patch/odex/classes.dex：speed

在上述终端中可以设置有执行热补丁的装置，执行热补丁的装置为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本发明能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

本发明实施例可以根据上述方法示例对执行热补丁的装置进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本发明实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

如图10所示，为上述实施例中所涉及的执行热补丁的装置的一种可能的结构示意图。执行热补丁的装置70包括：通信模块71、处理模块72和存储模块73。其中，通信模块71用于支持执行热补丁的装置70执行图5、图6、图7、图8中的步骤201，图7中的步骤401和步骤402，以及用于支持执行热补丁的装置70与终端中各个模块之间进行数据交互，和/或支持终端与诸如服务器等其他设备之间的通信；处理模块72用于支持执行热补丁的装置70执行图5中的步骤202和步骤203，图6、图7中的步骤301、步骤302以及步骤303中的按照第二编译模式加载、编译并运行热补丁的过程，图8中的步骤202、步骤502和步骤503，和/或用于本文所描述的技术的其它过程；存储模块73用于支持执行热补丁的装置70执行图6中步骤303中的记录用于反映热补丁执行情况的参数的过程，图8中的步骤501，以及用于存储终端的程序代码和数据。

其中，处理模块72可以实现为处理器或控制器，例如可以是中央处理器(CentralProcessing Unit，CPU)，通用处理器，数字信号处理器(Digital Signal Processor，DSP)，专用集成电路(Application-Specific Integrated Circuit，ASIC)，现场可编程门阵列(Field Programmable Gate Array，FPGA)或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本发明公开内容所描述的各种示例性的逻辑方框，模块和电路。所述处理器也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，DSP和微处理器的组合等等。通信模块71可以实现为收发器、收发电路或通信接口等。存储模块73可以实现为存储器。

若处理模块72实现为处理器、通信模块71实现为收发器、存储模块73实现为存储器，则如图11所示，终端80包括：处理器81、收发器82、存储器83，以及总线84。其中，处理器81、收发器82和存储器83通过总线84相互连接；总线84可以是外设部件互连标准(Peripheral Component Interconnect，PCI)总线或扩展工业标准结构(ExtendedIndustry Standard Architecture，EISA)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图11中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

结合本发明公开内容所描述的方法或者算法的步骤可以硬件的方式来实现，也可以是由处理器执行软件指令的方式来实现。软件指令可以由相应的软件模块组成，软件模块可以被存放于随机存取存储器(Random Access Memory，RAM)、闪存、只读存储器(ReadOnly Memory，ROM)、可擦除可编程只读存储器(Erasable Programmable ROM，EPROM)、电可擦可编程只读存储器(Electrically EPROM，EEPROM)、寄存器、硬盘、移动硬盘、只读光盘(Compact Disc Read-Only Memory，CD-ROM)或者本领域熟知的任何其它形式的存储介质中。一种示例性的存储介质耦合至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息。当然，存储介质也可以是处理器的组成部分。处理器和存储介质可以部署在同一设备中，或者，处理器和存储介质也可以作为分立组件部署在于不同的设备中。

本领域技术人员应该可以意识到，在上述一个或多个示例中，本发明实施例所描述的功能可以用硬件、软件、固件或它们的任意组合来实现。当使用软件实现时，可以将这些功能存储在计算机可读介质中或者作为计算机可读介质上的一个或多个指令或代码进行传输。计算机可读介质包括计算机存储介质和通信介质，其中通信介质包括便于从一个地方向另一个地方传送计算机程序的任何介质。存储介质可以是通用或专用计算机能够存取的任何可用介质。

以上所述的具体实施方式，对本发明实施例的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明实施例的技术方案的基础之上，所做的任何修改、等同替换、改进等，均应包括在本发明实施例的保护范围之内。

Claims (19)

1.一种执行热补丁的方法，其特征在于，所述方法包括：

终端下载应用的热补丁；

若所述应用在前台运行，所述终端加载、编译并运行所述热补丁，所述编译为采用第一编译模式完成所述热补丁的格式转换；

若所述应用未在前台运行，且所述终端按照所述第一编译模式运行完所述热补丁，则所述终端再次编译所述热补丁，所述再次编译为采用第二编译模式完成所述热补丁的格式转换；其中，按照所述第一编译模式编译所述热补丁的时间小于按照所述第二编译模式编译所述热补丁的时间，且按照所述第一编译模式运行所述热补丁的时间大于按照所述第二编译模式运行所述热补丁的时间。

2.根据权利要求1所述的方法，其特征在于，在所述终端加载、编译并运行所述热补丁之前，所述方法还包括：

所述终端在配置文件中查找是否存在所述应用的标识，所述配置文件至少包括需要采用快速编译模式加载、编译并运行所述热补丁的应用的标识，其中，所述第一编译模式属于所述快速编译模式；

所述终端加载、编译并运行所述热补丁包括：

若所述配置文件中存在所述应用的标识，则所述终端按照所述配置文件中与所述应用的标识对应的编译模式加载、编译并运行所述热补丁，或者，所述终端按照默认的编译模式加载、编译并运行所述热补丁。

3.根据权利要求2所述的方法，其特征在于，在所述终端在配置文件中查找是否存在所述应用的标识之后，所述方法还包括：

若所述配置文件中不存在所述应用的标识，则所述终端按照所述第二编译模式加载、编译并运行所述热补丁，并记录用于反映所述热补丁执行情况的参数。

4.根据权利要求3所述的方法，其特征在于，所述参数包括所述热补丁的大小和加载时间中的至少一项。

5.根据权利要求3或4所述的方法，其特征在于，在所述终端记录用于反映所述热补丁执行情况的参数之后，所述方法还包括：

所述终端向服务器发送所述热补丁和所述参数；

在所述终端处于空闲状态时，所述终端从所述服务器获取更新后的配置文件。

6.根据权利要求1至4中任意一项所述的方法，其特征在于，在所述终端再次编译所述热补丁之前，所述方法还包括：

所述终端记录完成加载的所述热补丁的存储路径；

所述终端按照所述存储路径查找完成加载的所述热补丁。

7.一种执行热补丁的装置，其特征在于，所述装置包括：

通信模块，用于下载应用的热补丁；

处理模块，用于在所述应用在前台运行，加载、编译并运行所述通信模块下载的所述热补丁，所述编译为采用第一编译模式完成所述热补丁的格式转换；

所述处理模块，还用于在所述应用未在前台运行，且所述处理模块按照所述第一编译模式运行完所述热补丁后，再次编译所述热补丁，所述再次编译为采用第二编译模式完成所述热补丁的格式转换；其中，按照所述第一编译模式编译所述热补丁的时间小于按照所述第二编译模式编译所述热补丁的时间，且按照所述第一编译模式运行所述热补丁的时间大于按照所述第二编译模式运行所述热补丁的时间。

8.根据权利要求7所述的装置，其特征在于，所述处理模块，还用于在配置文件中查找是否存在所述应用的标识，所述配置文件至少包括需要采用快速编译模式加载、编译并运行所述热补丁的应用的标识，其中，所述第一编译模式属于所述快速编译模式；

所述处理模块，还用于若所述配置文件中存在所述应用的标识，则按照所述配置文件中与所述应用的标识对应的编译模式加载、编译并运行所述热补丁，或者，按照默认的编译模式加载、编译并运行所述热补丁。

9.根据权利要求8所述的装置，其特征在于，所述处理模块，还用于若所述配置文件中不存在所述应用的标识，则按照所述第二编译模式加载、编译并运行所述热补丁；

所述装置还包括：

存储模块，用于记录用于反映所述热补丁执行情况的参数。

10.根据权利要求9所述的装置，其特征在于，所述参数包括所述热补丁的大小和加载时间中的至少一项。

11.根据权利要求9或10所述的装置，其特征在于，所述通信模块，还用于向服务器发送所述热补丁和所述参数；

所述通信模块，还用于在终端处于空闲状态时，从所述服务器获取更新后的配置文件。

12.根据权利要求7至10中任意一项所述的装置，其特征在于，所述装置还包括：

存储模块，用于记录完成加载的所述热补丁的存储路径；

所述处理模块，还用于按照所述存储路径查找完成加载的所述热补丁。

13.一种终端，其特征在于，所述终端包括：

收发器，用于下载应用的热补丁；

处理器，用于在所述应用在前台运行，加载、编译并运行所述收发器下载的所述热补丁，所述编译为采用第一编译模式完成所述热补丁的格式转换；

所述处理器，还用于在所述应用未在前台运行，且所述处理器按照所述第一编译模式运行完所述热补丁后，再次编译所述热补丁，所述再次编译为采用第二编译模式完成所述热补丁的格式转换；其中，按照所述第一编译模式编译所述热补丁的时间小于按照所述第二编译模式编译所述热补丁的时间，且按照所述第一编译模式运行所述热补丁的时间大于按照所述第二编译模式运行所述热补丁的时间。

14.根据权利要求13所述的终端，其特征在于，在所述处理器加载、编译并运行所述热补丁之前，所述处理器，还用于在配置文件中查找是否存在所述应用的标识，所述配置文件至少包括需要采用快速编译模式加载、编译并运行所述热补丁的应用的标识，其中，所述第一编译模式属于所述快速编译模式；

所述处理器，还用于若所述配置文件中存在所述应用的标识，则按照所述配置文件中与所述应用的标识对应的编译模式加载、编译并运行所述热补丁，或者，按照默认的编译模式加载、编译并运行所述热补丁。

15.根据权利要求14所述的终端，其特征在于，在所述处理器在配置文件中查找是否存在所述应用的标识之后，所述处理器，还用于若所述配置文件中不存在所述应用的标识，则按照所述第二编译模式加载、编译并运行所述热补丁；

所述终端还包括：

存储器，用于记录用于反映所述热补丁执行情况的参数。

16.根据权利要求15所述的终端，其特征在于，所述参数包括所述热补丁的大小和加载时间中的至少一项。

17.根据权利要求15或16所述的终端，其特征在于，在所述存储器记录用于反映所述热补丁执行情况的参数之后，所述收发器，还用于向服务器发送所述热补丁和所述参数；

所述收发器，还用于在所述终端处于空闲状态时，从所述服务器获取更新后的配置文件。

18.根据权利要求13至16中任意一项所述的终端，其特征在于，在所述终端再次编译所述热补丁之前，所述终端还包括：

存储器，用于记录完成加载的所述热补丁的存储路径；

所述处理器，还用于按照所述存储路径查找完成加载的所述热补丁。

19.一种计算机可读介质，其特征在于，所述计算机可读介质上存储有计算机程序，所述计算机程序加载到计算机上被所述计算机执行时，使所述计算机执行根据权利要求1至6任意一项所述的方法。

Images