本申请实施例涉及移动终端技术，尤其涉及一种应用程序热更新的控制方法、装置、存储介质及移动终端。
背景技术：
随着安卓(android)平台移动端业务复杂性程度的增加，传统的通过在软件商店发布版本更新的应用更新方案已经不能满足业务及开发者的需求。
为了解决上述问题，相关技术中出现了热更新技术，即一种快速、低成本修复应用程序(application，简称app)版本缺陷的方式，其不依赖于应用程序的版本更新来对应用程序的漏洞进行修复。相比于升级应用程序的版本，热更新的主要优势是不会使应用程序当前正在运行的业务中断，即可以在不重新发布迭代版本的基础上来对当前的应用程序版本的缺陷进行修复。然而，相关技术中的热更新流程缺少统一有效的管理流程及规范，由于部分第三方应用频繁滥用容易导致终端发热、卡顿等影响移动终端性能的问题出现。
技术实现要素：
本申请实施例提供一种应用程序热更新的控制方法、装置、存储介质及移动终端，可以优化相关技术中的应用程序热更新的控制方案。
第一方面，本申请实施例提供了一种应用程序热更新的控制方法，包括：
监听预设应用程序的热更新需求；
在终端处于第一状态且预设应用程序需要进行热更新编译处理时，启动预设服务，并通过所述预设服务在后台执行热更新编译操作，其中，所述第一状态包括熄屏状态；
若在执行所述热更新编译操作期间获取到所述终端的状态变为第二状态，则暂停执行所述热更新编译操作，并记录执行进度，其中，所述第二状态包括唤醒状态或使用状态。
第二方面，本申请实施例还提供了一种应用程序热更新的控制装置，该装置包括：
需求监听模块，用于监听预设应用程序的热更新需求；
应用热更新模块，用于在终端处于第一状态且预设应用程序需要进行热更新编译处理时，启动预设服务，并通过所述预设服务在后台执行热更新编译操作，其中，所述第一状态包括熄屏状态；
操作暂停模块，用于若在执行所述热更新编译操作期间获取到所述终端的状态变为第二状态，则暂停执行所述热更新编译操作，并记录执行进度，其中，所述第二状态包括唤醒状态或使用状态。
第三方面，本申请实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现如上述第一方面所述的应用程序热更新的控制方法。
第四方面，本申请实施例还提供了一种移动终端，包括存储器，处理器及存储在存储器上并可在处理器运行的计算机程序，所述处理器执行所述计算机程序时实现如上述第一方面所述的应用程序热更新的控制方法。
本申请实施例提供一种应用程序热更新的控制方案，通过监听预设应用程序的热更新需求；在终端处于第一状态且预设应用程序需要进行热更新编译处理时，通过预设服务在后台执行针对预设应用程序的热更新编译操作；若在执行热更新编译操作期间，检测到终端的状态变为第二状态，则暂停该热更新编译操作，并记录执行进度。采用上述技术方案，可以在应用程序启动之前进行热更新编译，避免在应用程序启动过程中执行热更新编译而发生卡顿问题，提升应用程序的启动速度。此外，在熄屏状态下进行热更新编译，可以避免热更新编译进程与用户正常使用的应用进程并行执行，导致处理效率降低或发热的问题。
附图说明
图1是本申请实施例提供的一种应用程序热更新的控制方法的流程图；
图2是本申请实施例提供的另一种应用程序热更新的控制方法的流程图；
图3是本申请实施例提供的又一种应用程序热更新的控制方法的流程图；
图4是本申请实施例提供的一种应用程序热更新的控制装置；
图5是本申请实施例提供的一种移动终端的结构示意图；
图6是本申请实施例提供的一种智能手机的结构框图。
具体实施方式
下面结合附图和实施例对本申请作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释本申请，而非对本申请的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本申请相关的部分而非全部结构。
在更加详细地讨论示例性实施例之前应当提到的是，一些示例性实施例被描述成作为流程图描绘的处理或方法。虽然流程图将各步骤描述成顺序的处理，但是其中的许多步骤可以被并行地、并发地或者同时实施。此外，各步骤的顺序可以被重新安排。当其操作完成时所述处理可以被终止，但是还可以具有未包括在附图中的附加步骤。所述处理可以对应于方法、函数、规程、子例程、子程序等等。
需要说明的是，热更新技术(又成为热修复技术)，是应用程序通过动态下载代码以修复应用问题或者退出新功能的技术。例如，在启动app时，询问服务器是否需要热更新，如果需要则先下载并加载热更新文件，然后再运行app。
采用热更新技术具有如下优点：
1)传统方案中，第三方应用的发布需要经过软件商店层层审核，导致发布周期较长，通过热更新技术可以解决该问题，从而快速修复软件漏洞；
2)第三方应用通过动态下载热更新代码，向用户快速推送新功能，免去安装升级环节；
3)降低发布安卓安装包(androidpackage，简称apk)的大小，减少应用下载等待时间。
然而，由于热更新流程缺少统一有效的管理流程及规范，少部分三方应用频繁滥用后，容易导致移动终端出现发热、卡顿等影响用户体验的问题。为了解决上述问题，本申请实施例提供一种应用程序热更新的控制方案，可以避免在应用程序启动过程中执行热更新编译而发生发热、卡顿问题，提升应用程序的启动速度。
需要说明的是，本申请实施例主要考虑以下场景下的第三方应用的热更新操作：
场景一、移动终端首次安装具有热更新文件(如后缀名为apk、so及jar等的文件)的应用，在该首次安装的应用启动时需要调用dex2oat编译程序进行编译转换；
场景二、第三方应用下载的热更新文件，加载前需要调用dex2oat进行编译转换；
场景三、软件商店后台更新应用程序，应用代码发生变化，需要重新进行编译转换；
场景四、系统版本升级(即ota，通过推送系统补丁，用户下载后安装，更新系统)后系统发生变化，所有第三方应用的补丁文件需要重新进行编译转换；
其中，dex2oat是谷歌提供的编译程序，用来编译应用的热更新文件，将热更新文件转换为android可高效执行的odex代码格式文件。
图1是本申请实施例提供的一种应用程序热更新的控制方法的流程图，本实施例可适用于应用热更新情况，该方法可以由应用程序热更新的控制装置来执行，其中，该装置可由软件和/或硬件实现，一般可集成在移动终端中。如图1所示，该方法包括：
步骤110、监听预设应用程序的热更新需求。
其中，预设应用程序可以根据移动终端中已安装的第三方应用程序的使用情况确定。例如，根据使用频率对已安装的第三方应用程序进行排序，假设根据使用频率进行降序排列，将排序在前的设定数量的第三方应用程序作为预设应用程序。又如，根据使用时长对已安装的第三方应用程序进行排序，假设根据使用时长进行降序排列，将排序在前的设定数量的第三方应用程序作为预设应用程序。其中，设定数量可以是系统默认，也可以是用户设定的，例如，可以设定用户使用最频繁的30个第三方应用程序为预设应用程序。
需要说明的是，热更新需求可以为是否需要进行热更新编译处理。也就是，检测终端是否处于预设场景。示例性的，若检测到发生系统版本更新，则确定终端处于预设场景，需要进行热更新编译处理。也就是，在系统版本更新完成时，检测终端状态，若终端状态为熄屏，则自动触发热更新服务启动，执行热更新编译操作。示例性的，若检测到应用更新，即软件商店后台更新应用程序，则确定终端处于预设场景，需要进行热更新编译处理。也就是，在发生应用更新时，若终端状态为熄屏，则自动触发热更新服务启动，执行热更新编译操作。需要说明的是，在系统版本更新完成时，触发启动热更新服务的条件不限于终端状态为熄屏状态，还可以是终端熄屏且充电设定时间。同样的，在发生应用更新时，触发动热更新服务的条件不限于终端状态为熄屏状态，还可以是终端熄屏且充电设定时间。在熄屏且充电状态下进行热编译处理，可以避免编译热更新文件代码的功耗影响移动终端的续航时间。
可以理解的是，还可以监听首次安装的应用程序，判断其是否具有热更新文件，若是，则确定该应用程序为预设应用程序，且需要进行热更新编译处理。可选的，还可以监听第三方应用程序，判断其是否下载热更新文件，若是，再根据该第三方应用程序的使用情况判断其是否是预设应用程序。例如，在使用频率或使用时长满足预设条件时，确定第三方应用程序为预设应用程序，且该预设应用程序需要进行热更新编译处理。其中，预设条件可以是使用频率或使用时长在所有第三方应用程序中排名在前30名。需要说明的是，若该第三方应用程序不是预设应用程序，则不提前进行热更新编译处理，并在检测到该应用程序启动时执行热更新编译操作。需要说明的是，执行监听第三方应用程序或首次安装的应用程序的服务可以由预设系统进程执行，可以为一预先编写的热更新服务对应的代码，预先在系统中对该代码进行注册，用来监听和记录第三方应用程序是否需要进行热更新编译。
步骤120、在终端处于第一状态且预设应用程序需要进行热更新编译处理时，启动预设服务，并通过所述预设服务在后台执行热更新编译操作。
需要说明的是，第一状态包括熄屏状态，即用户未使用移动终端的状态，或者熄屏播放音频文件的状态等。进一步的，为了避免编译热更新代码消耗的功率对续航时间的影响，可以将第一状态预设为熄屏且充电预设时长。其中，预设时长可以是5分钟或者其它系统默认时间，还可以向用户开放时间设置功能，由用户根据实际需要自行设置该充电预设时长。
需要说明的是，预设服务可以是jobservice服务(即谷歌新增的服务组件，用以在后台处理计算量大且耗时的繁重任务，例如，在后台执行预设应用程序的热更新编译操作)，用来批量逐个拉起预设应用程序的应用界面。其中，批量逐个的含义可以是根据预设应用程序的排序结果，将预设应用程序分为至少一批，按照批次确定热更新编译的目标对象集合，在同一批次中，还可以按照排序结果逐个对预设应用程序的热更新文件进行编译。可选的，可以多个批次并行进行编译操作。应用界面可以是预设应用程序的主界面或二级界面。需要说明的是，应用界面被启动则会自动调用dex2oat编译程序对热更新文件进行编译，编译完成后下次启动应用程序就不需要进行再编译，直至再次下载到热更新文件。可以理解的是，jobservice服务在后台对应用界面进行操作的方式并不限于批量逐个拉起的方式，还可以是顺序拉起或随机拉起的方式，本申请实施例并不作具体限定。
需要说明的是，可以通过监听dex2oat编译程序对应的编译进程的状态判断预设应用程序的热更新编译操作是否完成。例如，可以为不同的预设应用程序分配不同进程标识的编译进程执行编译操作，若对应于当前的预设应用程序的编译进程消失，则确定当前的预设应用程序的热更新编译操作已完成。
步骤130、若在执行所述热更新编译操作期间获取到所述终端的状态变为第二状态，则暂停执行所述热更新编译操作，并记录执行进度。
需要说明的是，第二状态包括唤醒状态或使用状态，例如，屏幕点亮、终端解锁、终端被移动或者终端被握持等。也就是说，若检测到终端处于下述状态中的任意一种，则确定终端的状态变为第二状态，屏幕点亮、解锁、终端被移动或握持。
需要说明的是，执行热更新编译操作期间可以指至少一个预设编译程序对应的进程存在于任务管理器，且占用处理资源的过程。在执行热更新编译操作期间，终端应处于第一状态。按照设定周期值周期性的获取终端状态。在获取到终端状态由第一状态变为第二状态时，暂停执行热更新编译操作，并记录已经执行完成热编译的预设应用程序的数量。其中，暂停执行热更新编译操作包括杀死预设编译进程，以等待下次终端重新处于第一状态时重新启动预设编译进程。
需要说明的是，根据预设编译进程的状态分别判断各个预设应用程序的热更新编译操作是否均执行完成，若是，则结束jobservice服务。
本实施例的技术方案，通过监听预设应用程序的热更新需求；在终端处于第一状态且预设应用程序需要进行热更新编译处理时，通过预设服务在后台执行针对预设应用程序的热更新编译操作；若在执行热更新编译操作期间，检测到终端的状态变为第二状态，则暂停该热更新编译操作，并记录执行进度。采用上述技术方案，可以在应用程序启动之前进行热更新编译，避免在应用程序启动过程中执行热更新编译而发生卡顿问题，提升应用程序的启动速度。此外，在终端状态变为第二状态后，暂停执行热更新编译操作，可以避免因执行编译代码而对用户正常使用终端造成卡顿。此外，在熄屏状态下进行热更新编译，可以避免热更新编译进程与用户正常使用的应用进程并行执行，而降低处理器对于应用进程的处理效率、导致终端发热等问题。
图2是本申请实施例提供的另一种应用程序热更新的控制方法的流程图。如图2所示，该方法包括：
步骤201、若所述终端状态为熄屏状态且充电预设时间长度，则确定所述终端处于第一状态。
步骤202、若所述终端处于第一状态，则启动预先注册的热更新服务。
示例性的，若终端满足熄屏且充电五分钟，则启动预先向系统注册的热更新服务，用于监听和记录应用是否需要做热更新编译。
需要说明的是，应用需要做热更新编译的场景包括但不限于终端首次安装的应用程序具有热更新文件。
步骤203、通过所述热更新服务检测首次安装的应用程序，判断该应用程序是否具有热更新文件，若是，则执行步骤204，否则执行步骤211。
通过该热更新服务获取用户首次安装的应用程序的apk，判断该apk中是否具有热更新文件，若是，则执行步骤204，否则执行步骤211。
步骤204、确定该首次安装的应用程序需要进行热更新编译处理。
需要说明的是，首次安装的应用程序的数量至少为1个。
步骤205、启动预设服务，并通过所述预设服务在后台执行热更新编译操作。
其中，预设服务是jobservice服务。
在首次安装的应用程序为1个时，启动一个jobservice服务，用来在后台启动该首次安装的应用程序的主界面或二级界面，从而，触发dex2oat编译程序对该首次安装的应用程序的热更新文件进行编译。
在首次安装的应用程序为2个或2个以上时，可以根据apk下载时间或应用安装时间对首次安装的应用程序进行排序。然后，通过jobservice服务批量逐个在后台启动首次安装的应用程序的主界面或二级界面。若检测到界面被拉起，则通过dex2oat编译程序编译该主界面或二级界面对应的应用程序的热更新文件。
可以理解的是，在首次安装的应用程序至少为2个时，对首次安装的应用程序进行排序的依据并不限于apk下载时间或应用安装时间，还可以是根据同类app的使用频率或使用时长等，本申请实施例并不作具体限定。
步骤206、判断热更新编译操作是否执行完成，若是，则执行步骤210，否则执行步骤207。
监听dex2oat编译程序对应的编译进程，根据监听结果判断预设应用程序的热更新编译操作是否完成。例如，该在任务管理器中检测到当前的预设应用程序对应的dex2oat编译进程时，确定当前的预设应用程序的热更新编译工作未完成。若在任务管理器中检测到当前的预设应用程序对应的dex2oat编译进程不存在时，则确定当前的预设应用程序的热更新编译工作已完成。
步骤207、判断终端状态是否为第二状态，若是，则执行步骤208，否则执行步骤209。
步骤208、暂停执行所述热更新编译操作，并记录执行进度。
在执行所述热更新编译操作期间，若检测到发生屏幕点亮、解锁、移动终端被移动或握持等用户重新使用移动终端的操作，则确定预设编译进程正在编译的当前热更新文件，杀死该预设编译进程。需要说明的是，在某些实施例中，在确定预设编译进程正在编译的当前热更新文件后，无论是否编译完成，都杀死正在执行的预设编译进程。可选的，还可以在确定预设编译进程正在编译的当前热更新文件后，判断编译是否完成，若未完成，则等待该当前热更新文件编译完成再杀死对该当前热更新文件执行编译的编译进程。
由于已确定预设编译进程正在编译的当前热更新文件，可以据此确定该当前热更新文件对应的预设应用程序。然后，根据该预设应用程序的排序结果确定已编译完成的应用数量，作为执行进程进行记录。例如，假设当前热更新文件对应的预设应用程序所述的批次中具有10个应用，当前热更新文件对应的预设应用程序在该批次中的排序是5。若该当前热更新文件已编译完成，则确定执行进度为5。若该当前热更新文件未编译完成，则确定执行进度为4。相似的，记录各个批次的执行进度。
另外，假设仅有一批预设应用程序，且具有30个预设应用，当前热更新文件对应的预设应用程序在该批次中的排序是15。相似的，若该当前热更新文件已编译完成，则确定执行进度为15。若该当前热更新文件未编译完成，则确定执行进度为14。
在记录执行进度后，若终端再次处于第一状态，则根据该执行进度通过预设编译进程继续执行热更新编译操作。
步骤209、继续在后台执行热更新编译操作。
步骤210、结束jobservice服务以及热更新服务，直至终端状态变为第一状态，再返回执行步骤202，以重新启动热更新服务。
步骤211、针对首次安装的应用程序执行安装操作。
本实施例的技术方案，若所述终端状态为熄屏状态且充电预设时间长度，则启动预先注册的热更新服务，通过所述热更新服务检测首次安装的应用程序，若检测到首次安装的应用程序具有热更新文件，则启动一个jobservice服务，以批量逐个拉起首次安装的应用程序的应用界面，并通过监听dex2oat编译进程是否存在，判断当前应用的热更新编译工作是否完成；若在针对各个首次安装的应用程序的热更新编译工作均执行完成，则结束jobservice服务以及热更新服务。若在热更新编译期间，移动终端状态变为用户使用状态，则暂停热更新编译操作，记录执行进度，以在移动终端恢复第一状态时，继续进行热更新编译。采用上述技术方案，可以提前进行热更新编译工作，避免应用启动过程中执行编译，提升应用的启动速度，避免发生应用卡顿问题。此外，在熄屏充电的情况下进行热更新编译工作，能够避免编译热更新文件使用的功耗影响续航时间，提升了手机续航性能。
图3是本申请实施例提供的又一种应用程序热更新的控制方法的流程图。如图3所示，该方法包括：
步骤301、若所述终端状态为熄屏状态且充电预设时间长度，则确定所述终端处于第一状态。
步骤302、若所述终端处于第一状态，则通过所述热更新服务监听已安装的目标应用程序的热更新文件下载情况。
若所述终端处于第一状态，则启动预先注册的热更新服务。在终端状态为第一状态时，通过所述热更新服务监听已安装的目标应用程序的热更新文件下载情况。
步骤303、判断该目标应用程序是否下载热更新文件，若是，则执行步骤304，否则返回执行步骤303。
步骤304、确定该目标应用程序需要进行热更新编译处理。
需要说明的是，目标应用程序可以根据用户的使用习惯确定。例如，目标应用程序可以是服务器对设定数量的用户的历史使用数据进行分析推测的应用程序集合，该应用程序集合中的应用程序被用户频繁使用。可以采用预设白名单的形式存储目标应用程序，并下发至移动终端。可选的，移动终端可以采集用户的历史使用记录，根据该历史使用记录分析出机主的使用习惯，例如，频繁使用哪些应用，以及使用时间较长的应用有哪些等等。并且根据该分析结果确定目标应用程序。例如，若按照使用频率对已安装的应用程序进行排序，选择排名前30的应用程序作为目标应用。可以理解的是，目标应用程序的数量并不限于30个，其可以由用户根据需要自行设定，也可以是系统默认，本申请实施例并不作具体限定。
步骤305、启动预设服务，并通过所述预设服务在后台执行热更新编译操作。
其中，预设服务是jobservice服务。
在目标应用程序为1个时，启动一个jobservice服务，用来在后台启动该目标应用程序的主界面或二级界面，从而，触发dex2oat编译程序对该目标应用程序的热更新文件进行编译。
在目标应用程序为2个或2个以上时，可以根据目标应用程序对应的历史使用记录对该目标应用程序进行排序。例如，根据使用时长对目标应用程序进行排序。通过jobservice服务批量逐个在后台启动目标应用程序的主界面或二级界面。若检测到界面被拉起，则通过dex2oat编译程序编译该主界面或二级界面对应的应用程序的热更新文件。
步骤306、判断热更新编译操作是否执行完成，若是，则执行步骤310，否则执行步骤307。
步骤307、判断终端状态是否为第二状态，若是，则执行步骤308，否则执行步骤309。
步骤308、暂停执行所述热更新编译操作，并记录执行进度。
需要说明的是，暂停执行热更新编译操作的具体方式与上述公开内容类似，此处不再赘述。
步骤309、继续在后台执行热更新编译操作。
步骤310、结束jobservice服务以及热更新服务，直至终端状态变为第一状态，再返回执行步骤302，以重新启动热更新服务。
本实施例的技术方案，若所述终端状态为熄屏状态且充电预设时间长度，则启动预先注册的热更新服务，通过所述热更新服务检测目标应用程序，若检测到目标应用程序具有热更新文件，则启动一个jobservice服务，以批量逐个拉起目标应用程序的应用界面，并通过监听dex2oat编译进程是否存在，判断当前应用的热更新编译工作是否完成；若在针对各个目标应用程序的热更新编译工作均执行完成，则结束jobservice服务以及热更新服务。若在热更新编译期间，移动终端状态变为用户使用状态，则暂停热更新编译操作，记录执行进度，以在移动终端恢复第一状态时，继续进行热更新编译。采用上述技术方案，可以提前进行热更新编译工作，避免应用启动过程中执行编译，提升应用的启动速度，避免发生应用卡顿问题。此外，在熄屏充电的情况下进行热更新编译工作，能够避免编译热更新文件使用的功耗影响续航时间，提升了手机续航性能。
图4是本申请实施例提供的一种应用程序热更新的控制装置。该装置可以通过软件和/或硬件实现，可被集成于移动终端内，用于执行应用程序热更新的控制方法。如图4所示，该装置包括：
需求监听模块410，用于监听预设应用程序的热更新需求；
应用热更新模块420，用于在终端处于第一状态且预设应用程序需要进行热更新编译处理时，启动预设服务，并通过所述预设服务在后台执行热更新编译操作，其中，所述第一状态包括熄屏状态；
操作暂停模块430，用于若在执行所述热更新编译操作期间获取到所述终端的状态变为第二状态，则暂停执行所述热更新编译操作，并记录执行进度，其中，所述第二状态包括唤醒状态或使用状态。
本实施例的技术方案提供一种应用程序热更新的控制装置，可以在应用程序启动之前进行热更新编译，避免在应用程序启动过程中执行热更新编译而发生卡顿问题，提升应用程序的启动速度。
可选的，需求监听模块410具体用于：
若发生系统版本更新或应用程序更新，则确定预设应用程序需要进行热更新编译处理。
可选的，还包括：
状态确定模块，用于若所述终端状态为熄屏状态且充电预设时间长度，则确定所述终端处于第一状态。
可选的，需求监听模块410进一步具体用于：
若所述终端处于第一状态，则启动预先注册的热更新服务；
通过所述热更新服务检测首次安装的应用程序，或者，通过所述热更新服务监听已安装的目标应用程序的热更新文件下载情况；
若检测到首次安装的应用程序具有热更新文件，或者检测到所述目标应用程序下载的热更新文件，则确定预设应用程序需要进行热更新编译处理，其中，预设应用程序包括首次安装的应用程序及目标应用程序。
可选的，在预设服务是jobservice服务时，应用热更新模块420具体用于：
根据使用频率或使用时间对所述预设应用程序进行排序；
基于排序结果通过jobservice服务在后台启动所述预设应用程序的应用界面，其中，所述应用界面包括应用主界面或二级界面；
若所述应用界面被启动，则通过预设编译进程编译所述应用界面对应的预设应用程序的热更新文件。
可选的，还包括：
进程监听模块，用于在通过所述预设服务在后台执行热更新编译操作之后，监听所述预设编译进程，根据监听结果判断所述预设应用程序的热更新编译操作是否完成。
可选的，操作暂停模块430包括：
进程销毁子模块，用于确定预设编译进程正在编译的当前热更新文件，杀死所述预设编译进程；
进度记录子模块，用于根据所述当前更新文件对应的预设应用程序的排序结果确定已编译完成的应用数量，作为执行进度进行记录。
可选的，进程销毁子模块具体用于：
获取预设编译进程正在编译的当前热更新文件；
判断所述当前热更新文件是否编译完成；
若是，则杀死所述预设编译进程；
否则，等待所述当前热更新文件编译完成。
可选的，若检测到终端处于下述任一种状态，则确定所述终端的状态变为第二状态：
屏幕点亮；
解锁；
终端被移动或握持。
本申请实施例还提供一种包含计算机可执行指令的存储介质，所述计算机可执行指令在由计算机处理器执行时用于执行应用程序热更新的控制方法，该方法包括：
监听预设应用程序的热更新需求；
在终端处于第一状态且预设应用程序需要进行热更新编译处理时，启动预设服务，并通过所述预设服务在后台执行热更新编译操作，其中，所述第一状态包括熄屏状态；
若在执行所述热更新编译操作期间获取到所述终端的状态变为第二状态，则暂停执行所述热更新编译操作，并记录执行进度，其中，所述第二状态包括唤醒状态或使用状态。
存储介质——任何的各种类型的存储器设备或存储设备。术语“存储介质”旨在包括：安装介质，例如cd-rom、软盘或磁带装置；计算机系统存储器或随机存取存储器，诸如dram、ddrram、sram、edoram，兰巴斯(rambus)ram等；非易失性存储器，诸如闪存、磁介质(例如硬盘或光存储)；寄存器或其它相似类型的存储器元件等。存储介质可以还包括其它类型的存储器或其组合。另外，存储介质可以位于程序在其中被执行的第一计算机系统中，或者可以位于不同的第二计算机系统中，第二计算机系统通过网络(诸如因特网)连接到第一计算机系统。第二计算机系统可以提供程序指令给第一计算机用于执行。术语“存储介质”可以包括可以驻留在不同位置中(例如在通过网络连接的不同计算机系统中)的两个或更多存储介质。存储介质可以存储可由一个或多个处理器执行的程序指令(例如具体实现为计算机程序)。
当然，本申请实施例所提供的一种包含计算机可执行指令的存储介质，其计算机可执行指令不限于如上所述的应用程序热更新的控制操作，还可以执行本申请任意实施例所提供的应用程序热更新的控制方法中的相关操作。
本申请实施例提供了一种移动终端，该移动终端内具有操作系统，该移动终端中可集成本申请实施例提供的应用程序热更新的控制装置。其中，移动终端可以为智能手机、pad(平板电脑)、掌上游戏机及智能穿戴设备等。图5是本申请实施例提供的一种移动终端的结构示意图。如图5所示，该移动终端包括存储器510及处理器520。所述存储器510，用于存储计算机程序、预设应用程序的应用标识及执行进度等；所述处理器520读取并执行所述存储器510中存储的计算机程序。所述处理器520在执行所述计算机程序时实现以下步骤：监听预设应用程序的热更新需求；在终端处于第一状态且预设应用程序需要进行热更新编译处理时，启动预设服务，并通过所述预设服务在后台执行热更新编译操作，其中，所述第一状态包括熄屏状态；若在执行所述热更新编译操作期间获取到所述终端的状态变为第二状态，则暂停执行所述热更新编译操作，并记录执行进度，其中，所述第二状态包括唤醒状态或使用状态。
上述示例中列举的存储器及处理器均为移动终端的部分元器件，所述移动终端还可以包括其它元器件。以智能手机为例，说明上述移动终端可能的结构。图6是本申请实施例提供的一种智能手机的结构框图。如图6所示，该智能手机可以包括：存储器601、中央处理器(centralprocessingunit，cpu)602(又称处理器，以下简称cpu)、外设接口603、rf(radiofrequency，射频)电路605、音频电路606、扬声器611、触摸屏612、电源管理芯片608、输入/输出(i/o)子系统609、其他输入/控制设备610以及外部端口604，这些部件通过一个或多个通信总线或信号线607来通信。
应该理解的是，图示智能手机600仅仅是移动终端的一个范例，并且智能手机600可以具有比图中所示出的更多的或者更少的部件，可以组合两个或更多的部件，或者可以具有不同的部件配置。图中所示出的各种部件可以在包括一个或多个信号处理和/或专用集成电路在内的硬件、软件、或硬件和软件的组合中实现。
下面就本实施例提供的集成有应用程序热更新的控制装置的智能手机进行详细的描述。
存储器601，所述存储器601可以被cpu602、外设接口603等访问，所述存储器601可以包括高速随机存取存储器，还可以包括非易失性存储器，例如一个或多个磁盘存储器件、闪存器件、或其他易失性固态存储器件。在存储器601中存储计算机程序，还可以存储预设应用程序的应用标识及执行进度等。
外设接口603，所述外设接口603可以将设备的输入和输出外设连接到cpu602和存储器601。
i/o子系统609，所述i/o子系统609可以将设备上的输入输出外设，例如触摸屏612和其他输入/控制设备610，连接到外设接口603。i/o子系统609可以包括显示控制器6091和用于控制其他输入/控制设备610的一个或多个输入控制器6092。其中，一个或多个输入控制器6092从其他输入/控制设备610接收电信号或者向其他输入/控制设备610发送电信号，其他输入/控制设备610可以包括物理按钮(按压按钮、摇臂按钮等)、拨号盘、滑动开关、操纵杆、点击滚轮。值得说明的是，输入控制器6092可以与以下任一个连接：键盘、红外端口、usb接口以及诸如鼠标的指示设备。
触摸屏612，所述触摸屏612是用户终端与用户之间的输入接口和输出接口，将可视输出显示给用户，可视输出可以包括图形、文本、图标、视频等。
i/o子系统609中的显示控制器6091从触摸屏612接收电信号或者向触摸屏612发送电信号。触摸屏612检测触摸屏上的接触，显示控制器6091将检测到的接触转换为与显示在触摸屏612上的用户界面对象的交互，即实现人机交互，显示在触摸屏612上的用户界面对象可以是运行游戏的图标、联网到相应网络的图标等。值得说明的是，设备还可以包括光鼠，光鼠是不显示可视输出的触摸敏感表面，或者是由触摸屏形成的触摸敏感表面的延伸。
rf电路605，主要用于建立手机与无线网络(即网络侧)的通信，实现手机与无线网络的数据接收和发送。例如收发短信息、电子邮件等。具体地，rf电路605接收并发送rf信号，rf信号也称为电磁信号，rf电路605将电信号转换为电磁信号或将电磁信号转换为电信号，并且通过该电磁信号与通信网络以及其他设备进行通信。rf电路605可以包括用于执行这些功能的已知电路，其包括但不限于天线系统、rf收发机、一个或多个放大器、调谐器、一个或多个振荡器、数字信号处理器、codec(coder-decoder，编译码器)芯片组、用户标识模块(subscriberidentitymodule，sim)等等。
音频电路606，主要用于从外设接口603接收音频数据，将该音频数据转换为电信号，并且将该电信号发送给扬声器611。
扬声器611，用于将手机通过rf电路605从无线网络接收的语音信号，还原为声音并向用户播放该声音。
电源管理芯片608，用于为cpu602、i/o子系统及外设接口所连接的硬件进行供电及电源管理。
本申请实施例提供的移动终端，可以在应用程序启动之前进行热更新编译，避免在应用程序启动过程中执行热更新编译而发生卡顿问题，提升应用程序的启动速度。此外，在终端状态变为第二状态后，暂停执行热更新编译操作，可以避免因执行编译代码而对用户正常使用终端造成卡顿。
上述实施例中提供的应用程序热更新的控制装置、存储介质及移动终端可执行本申请任意实施例所提供的应用程序热更新的控制方法，具备执行该方法相应的功能模块和有益效果。未在上述实施例中详尽描述的技术细节，可参见本申请任意实施例所提供的应用程序热更新的控制方法。
注意，上述仅为本申请的较佳实施例及所运用技术原理。本领域技术人员会理解，本申请不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本申请的保护范围。因此，虽然通过以上实施例对本申请进行了较为详细的说明，但是本申请不仅仅限于以上实施例，在不脱离本申请构思的情况下，还可以包括更多其他等效实施例，而本申请的范围由所附的权利要求范围决定。