CN107423097A - 一种应用程序的管理方法和装置 - Google Patents

Abstract

本发明提供了一种应用程序的管理方法和装置，该方法包括：采集运行的目标应用程序的第一性能数据并发送；接收目标应用程序的补丁包并存储，补丁包为针对性能问题而生成的补丁包，性能问题为通过对第一性能数据进行分析而得到的；若目标应用程序再次启动，则根据补丁包对目标应用程序进行性能修复。本发明通过采集运行的应用程序的第一性能数据并发送，进而接收针对该第一性能数据而生成的补丁包，从而可以利用该补丁包来对该应用程序的性能问题进行修复，实现了对已发布应用程序的性能的快速修复，使得不论应用程序的运行环境存在多大差异，本发明都可以灵活的生成对应的补丁包来对其性能修复。

Description

一种应用程序的管理方法和装置

技术领域

本发明涉及应用程序管理技术领域，特别是涉及一种应用程序的管理方法和装置。

背景技术

随着移动互联网的迅速发展，移动应用也随之在人们的日常成活中扮演着越来越重要的角色，人们对移动应用各方面的要求也越来越高。比较突出的方面就是性能方面，一款应用程序(APP，application)的性能问题用户体验度起着关键性影响。

当前，如图1所示，现有的应用程序的管理系统在进行性能优化时，一般是仅仅停留在软件设计、软件开发和软件测试阶段。即软件设计阶段采用相对成熟的考虑性能的系统架构，为性能优化方面打好基础；软件开发阶段则针对网络操作的性能，数据库操作的性能，事件、消息机制的性能，以及工具类、全局设置类性能进行软件开发，从而避免出现非常严重的性能问题；软件测试阶段主要从多方面、多角度来对开发完成的软件进行性能测试，从而发现问题，进行优化。

但是，当将经过上述图1流程的管理后的软件应用发布到生产环境(即应用到移动终端)后，由于设备差异、网络差异等诸多环境的复杂性和不可预测性，很可能会出现软件设计、开发和测试过程中没有发现的性能问题。而且，开发的移动应用要求产品能够快速迭代，开发者需要不断因推出新服务而加快移动应用的迭代速度，而在移动应用迭代更新的过程中，软件测试的流程往往容易被忽略，从而进一步影响了移动应用的质量，使得用户在使用移动应用过程中经常发生崩溃、闪退、卡顿等异常现象，严重影响用户体验。

由此可见，现有技术中的应用程序的管理方案针对已发布的应用程序无法进行有效性能优化的问题。

发明内容

本发明提供了一种应用程序的管理方法和装置，以解决现有技术中的应用程序的管理方案针对已发布的应用程序无法进行有效性能优化的问题。

为了解决上述问题，根据本发明的一个方面，本发明公开了一种应用程序的管理方法，应用于移动终端，包括：

采集运行的目标应用程序的第一性能数据并发送；

接收所述目标应用程序的补丁包并存储，所述补丁包为针对性能问题而生成的补丁包，所述性能问题为通过对所述第一性能数据进行分析而得到的；

若所述目标应用程序再次启动，则根据所述补丁包对所述目标应用程序进行性能修复。

根据本发明的另一方面，本发明还公开了一种应用程序的管理装置，应用于移动终端，包括：

第一采集模块，用于采集运行的目标应用程序的第一性能数据并发送；

第一接收模块，用于接收所述目标应用程序的补丁包并存储，所述补丁包为针对性能问题而生成的补丁包，所述性能问题为通过对所述第一性能数据进行分析而得到的；

修复模块，用于若所述目标应用程序再次启动，则根据所述补丁包对所述目标应用程序进行性能修复。

与现有技术相比，本发明包括以下优点：

本发明通过采集运行的应用程序的第一性能数据并发送，进而接收针对该第一性能数据而生成的补丁包，从而可以利用该补丁包来对该应用程序的性能问题进行修复，避免了针对已发布的应用程序无法进行有效性能优化的问题，实现了对已发布应用程序的性能的快速修复，使得不论应用程序的运行环境存在多大差异，本发明都可以灵活的生成对应的补丁包来对其性能修复。

附图说明

图1是现有技术的一种应用程序管理系统实施例的结构框图；

图2是本发明的一种应用程序管理方法实施例的步骤流程图；

图3是本发明的另一种应用程序管理方法实施例的步骤流程图；

图4是本发明的一种图片处理软件的管理方法实施例的步骤流程图；

图5是本发明的又一种应用程序管理方法的具体步骤流程图；

图6是本发明的一种系统加速软件的应用程序管理方法的具体步骤流程图；

图7是本发明的一种应用程序管理装置实施例的结构框图。

具体实施方式

为使本发明的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本发明作进一步详细的说明。

实施例一，参照图2，示出了本发明的一种应用程序的管理方法实施例的步骤流程图，应用于移动终端，具体可以包括如下步骤：

步骤101，采集运行的目标应用程序的第一性能数据并发送；

其中，当应用程序已经发布，移动终端上安装着各种各样的应用程序，那么为了避免这些应用程序发生与环境有关系的在软件设计、开发和测试过程中无法发现的性能问题时，则会影响应用程序的使用。因此，针对已经发布的某一款应用程序(这里以目标应用程序为例进行说明)，本发明实施例可以采集该运行的目标应用程序的第一性能数据，并可以将该第一性能数据发送至与该目标应用程序对应的服务器，以便服务器对该第一性能数据进行分析，从而发现该目标应用程序所存在的性能问题，进而生成补丁包，并将补丁包发回至移动终端侧。

步骤102，接收所述目标应用程序的补丁包并存储；

其中，本发明实施例的移动终端侧可以接收针对该目标应用程序的补丁包，这里的补丁包为服务器侧针对该目标应用程序的性能问题而生成的补丁包，所述性能问题为服务器侧通过对所述第一性能数据进行分析而得到的；

步骤103，若所述目标应用程序再次启动，则根据所述补丁包对所述目标应用程序进行性能修复。

那么，当该目标应用程序重启后，本发明实施例就可以根据该补丁包而对该目标应用程序进行性能修复，以解决其所存在的性能问题。

但是，需要注意的是，本发明实施例是以服务器与移动终端进行交互来说明的，但是，对性能数据进行分析，从而生成补丁包的过程并不限于服务器来完成，也可以是其他模块、芯片和分析装置等来完成。

借助于本发明上述实施例的技术方案，本发明通过采集运行的应用程序的第一性能数据并发送，进而接收针对该第一性能数据而生成的补丁包，从而可以利用该补丁包来对该应用程序的性能问题进行修复，避免了针对已发布的应用程序无法进行有效性能优化的问题，实现了对已发布应用程序的性能的快速修复，使得不论应用程序的运行环境存在多大差异，本发明都可以灵活的生成对应的补丁包来对其性能修复。

可选地，在一个实施例中，所述第一性能数据至少包括以下至少之一：

CPU占用量、内存占用量、上下行流量、移动终端温度、电流强度、电量消耗量、界面操作的响应时间、异常日志、错误日志、存储空间占用量。

上述数据可以任意组合来构成第一性能数据，它们反映了目标应用程序的各种性能问题。当然，本发明的第一性能数据并不限于上述举例，还可以包括其他未列举的性能数据。

可选地，在一个实施例中，在执行步骤101时，可以通过按照预设周期采集运行的目标应用程序的第一性能数据并发送来实现；和/或，通过在检测到所述目标应用程序作业务处理时，采集关联于所述业务处理的第一性能数据并发送。

也就是说，第一性能数据的采集时机可以是第一种：按照预设周期进行周期性采集，也可以是第二种：在程序作业务处理时(例如图片处理软件在进行图片处理时)采集，当然，也可以是第一种和第二种组合的方式来采集。

其中，第一种采集方式可以更稳定的获取第一性能数据，而第二种采集方式则可以使得采集到的性能数据更符合应用程序的实际使用情况。

在实际应用中，可以灵活设置第一性能数据的采集时机。

参照图3，示出了本发明另一种应用程序的管理方法实施例的步骤流程图。

针对一款APP，首先本发明实施例的方法可以启动该APP的自身应用性能优化管理服务，那么在开启了该服务后，就可以对该APP的上述第一性能数据进行监控采集；

在本例中，第一性能数据的采集时机采用的是上述第二种采集时机，具体而言，本发明实施例可以记录APP的页面切换时每一个页面加载的时间，该页面加载时间反映了界面操作的反映时间，该信息可以上报至服务器；

进一步地，本发明实施例还可以实时分析并记录该APP的内存使用信息(即内存占用量)，并将该内存使用信息上报至服务器；

进一步地，本发明实施例还可以对当前APP的耗电量、存储空间占用量和CPU使用量(即上述CPU占用量)进行记录，并都上报至服务器侧；

而服务器侧在接收到移动终端发送的该APP自身的性能数据后，就可以根据该性能数据来分析该APP的性能问题，并针对该性能问题生成性能优化的补丁包并下发给移动终端；

移动终端侧接收到该补丁包后，在该APP重启后，就可以根据该补丁包来对该APP进行性能优化。

具体实例：图片处理软件是一种要考虑性能的典型APP，且要考虑的性能主要是内存方面。软件设计和开发时，要特别注意实例的创建、存储、引用、释放，以及代码的逐步测试和优化，最后在经过完善的系统测试，再进行性能方面的优化。此时发布的APP的性能已经基本达标，但是现在随着Android移动设备系统版本的升级、系统型号的多样化，系统测试已经无法覆盖基本的用户使用场景，一些隐含的性能问题还需要通过真实环境的真实用户操作得以体现，并及时反馈给服务器，进一步及时解决问题，优化性能。

参照图4，示出了本发明的一种图片处理软件的管理方法的步骤流程图。

首先，图片处理软件(以APP示例)通过系统测试，能够基本保证产品质量后，厂商发布APP，用户安装并启动该APP运行。

程序启动后，本发明实施例的方法可以立即启动该APP的性能优化管理服务，并按照一定周期来周期性获取当前APP的内存、耗电量、CPU等值，上报至服务器。

此外，当进入APP的功能页面后，每当用户切换APP的每一个功能页面(即，一种业务处理的过程)时，本发明实施例的方法都可以记录每一个页面的从启动到加载完成的时间；并判断页面加载所用时间是否超出正常值，如果未超出，继续加载图片并处理(例如加载图片并进行图标压缩、显示、编辑等处理)；如果超出，则将该页面的页面加载时间上报至服务器。

而在APP加载图片并进行图标压缩、显示、编辑等处理时(即另一种业务处理的过程)，本发明实施例可以读取图片处理过程中堆内存的使用情况(即内存占用量)，并抓取大图加载、压缩等处理时内存相关的异常日志信息；从而将上述内存占用量和异常日志上报至服务器。

服务器接收移动终端发送的APP自身的性能分析数据(这里可以包括周期性获取当前APP的内存、耗电量、CPU等值；页面加载时间；图片处理过程中堆内存的使用情况；异常日志等)，分析当前APP存在的性能问题，针对性能问题生成性能优化的补丁包并下发给移动终端；

移动终端的APP接收性能优化补丁包并存储，在下次应用程序启动时进行性能优化的问题修复。

实施例二，可选地，在上述实施例一的基础上，根据本发明实施例的方法还可以包括：

S11，获取预先配置的受控应用程序名单；

其中，也可以预先设置移动终端上安装的所有应用程序中哪些应用程序需要进行性能的整体监控，将需要监控的应用程序设置在受控应用程序名单中。

S12，按照预设周期采集所述受控应用程序名单内运行的受控应用程序的第二性能数据；

其中，并不一定受控应用程序名单中的每个APP都在运行，本发明只需要对名单中运行的APP来采集第二性能数据，该第二性能数据可以包括：启动频率、异常崩溃频率，和/或，进一步包括：上述第一性能数据。

S13，针对所述受控应用程序名单内的每个受控应用程序的多次采集的多组第二性能数据进行分析，得到每个受控应用程序的第二性能数据的分析结果；

其中，由于第二性能数据是按周期获取的，因此移动终端可以存储着多次获取到的每个受控APP的多组第二性能数据，因此，在执行S13时，可以通过以下方式来实现：

针对所述受控应用程序名单内某个受控应用程序的多组第二性能数据，按照第二性能的类别，对每类第二性能数据的数据值分别作预设计算(例如取平均值、取出现频率高的等等计算方式)，得到所述某个受控应用程序的第二性能数据的分析结果，所述分析结果包括每类第二性能的性能值。

具体而言，针对名单中APP1的多组第二性能数据(例如第二性能包括电量消耗量、异常崩溃频率)可以以表1示出：

APP1第二性能数据记录	电量消耗量	异常崩溃频率
			1	80％	0.8
2	70％	0.7
			3	75％	0.8

表1

表1中第二性能的类别包括：电量消耗量和异常崩溃频率，针对电量消耗量性能的3组数据值可以取平均值得到75％，那么APP1的电量消耗量的性能值就是75％；同理，可以对APP1的异常崩溃频率进行分析计算，则APP1的异常崩溃频率的性能值就是0.77。

同理，针对受控应用程序名单中其他应用程序也可以计算得到各个第二性能的性能值。

例如经分析和计算，APP2的电量消耗量的性能值为25％，异常崩溃频率的性能值为0.5；APP3的电量消耗量的性能值为35％，异常崩溃频率的性能值为0.6。

S14，根据所述分析结果对所述受控应用程序名单内的受控应用程序分类。

其中，在执行S14时，可以通过以下方式来实现：

针对多类第二性能中的目标类别第二性能，对所述受控应用程序名单内的受控应用程序按照所述目标类别第二性能的性能值从高到低进行排序，得到所述目标类别第二性能的受控应用程序的排序结果，其中，所述多类第二性能中的每类第二性能轮流作为所述目标类别第二性能；

根据受控应用程序的所述多类第二性能的排序结果，对所述受控应用程序名单内的受控应用程序分类。

具体而言，继续以上述具体实例为例进行说明，按照电量消耗量的性能值从高到低排序，依次为APP1、APP3、APP2；按照异常崩溃频率的性能值从高到低排序，依次为APP1、APP3、APP2。

那么在分类时，可以将APP1分类在高耗电量、异常次数多的应用程序类型中，使用体验差；而将APP2分类在低耗电量且异常次数最少的应用程序类型中，使用体验好；将APP3分类在中等耗电量且异常次数一般的应用程序中，使用体验一般。

另外，在分类时，可以针对不同类别的第二性能设置相应阈值，以便于分类，例如耗电量超过70％算是高耗电，低于30％算是低耗电。

这样，本发明实施例就可以根据受控应用程序名单中的各个受控应用程序在不同类别性能数据的排序上，划分为各个类型的应用程序，这里可以分为高耗、中耗和低耗，依次为APP1、APP3、APP2。本发明实施例还可以将分类结果提供给用户，这样用户就可以对一些性能较差的应用程序进行清理或卸载等操作。

实施例三，可选地，在上述实施例一的基础上，根据本发明实施例的方法还可以包括：

获取预先配置的受控应用程序名单；

其中，也可以预先设置移动终端上安装的所有应用程序中哪些应用程序需要进行性能的整体监控，将需要监控的应用程序设置在受控应用程序名单中。

采集所述受控应用程序名单内运行的受控应用程序的第二性能数据并发送；

其中，并不一定受控应用程序名单中的每个APP都在运行，本发明只需要对名单中运行的APP来采集第二性能数据，该第二性能数据可以包括：启动频率、异常崩溃频率，和/或，进一步包括：上述第一性能数据。

这里，第二性能数据的分析步骤即上述S13由服务器来完成，即，可以将该第二性能数据发送至进行整体性能分析的服务器，此服务器不同于实施例一中的服务器，实施例一中的服务器是针对某款应用程序而专门服务的服务器，而实施例三中的服务器则是对受控应用程序名单中的所有应用程序进行性能分析的服务器。

其中，本例中的服务器对接收到各个APP的第二性能数据后，可以依据这些APP的多次采集的第二性能数据进行分析，从而得到分析结果。具体分析过程可以参照实施例二中的S13以及其具体实现过程，在此不再赘述。

接收对所述受控应用程序名单内受控应用程序的第二性能数据的分析结果，所述分析结果为根据多次采集的多组第二性能数据而分析得到的；

根据所述分析结果对所述受控应用程序名单内的受控应用程序分类。

其中，具体分类过程可以参照上述实施例二的S14以及其具体实现，在此不再赘述。

参照图5，示出了本发明实施例三的附加可选步骤的具体实现过程的步骤流程图。

针对移动终端安装的多个应用程序，首先本发明实施例的方法可以启动对受控应用的性能管理服务，那么在开启了该服务后，就可以对受控应用的上述第二性能数据进行监控采集；

然后，获取移动终端的系统中已安装的应用程序的信息列表；

在信息列表中选择需要监控的应用程序以进行受控应用名单的配置；

在对受控应用名单配置完成后，就可以记录受控应用名单中受控应用的启动次数、异常崩溃次数、内存使用情况、网络流量、存储空间使用情况的信息，并上报至服务器；

服务器接收移动终端的受控应用的性能数据并存储；

然后，服务器根据存储的n组性能数据来分析各个受控应用所存在的性能问题(以分析结果的方式)发送至移动终端；

移动终端接收各个受控应用程序的性能分析结果并以折线图等直观方式展示给用户，并对受控应用进行例如高耗电、中耗电、低耗电等级分类；

最后，用户就可以选择对例如高耗电的应用程序进行清理或者卸载等操作。

参照图6，在一个具体实例中，实施例三中附加的可选步骤可以以加速软件的形式来体现，该加速软件是对系统整体性能优化的软件，一般要考虑的因素有：系统当前内存占用与可用情况、系统缓存数据大小、耗电量、流量等、应用的使用频率、异常崩溃频率、流畅程度等，结合用户的使用习惯综合分析系统中各个应用的性能，进而进行优先级划分和清理优化等操作。

具体而言，本发明实施例的系统加速软件的工作流程以及与服务器之间的交互如图6所示：

首先，启动该加速软件，并启动该加速软件的性能优化管理服务。

然后，判断移动终端系统是否已配置受控应用能名单，如果没有配置，则获取系统已安装应用程序，并配置受控应用名单；如果已经配置，则记录受控应用的使用频率、异常崩溃次数、内存使用情况、网络流量、存储空间使用情况的信息，并上报至服务器。

接着，服务器接收移动终端的加速软件发送的各受控应用的性能数据并存储，然后，根据数据库中存储的各个受控应用的n组性能数据进行分析，确定各个受控应用的各个性能的基本值(即上述预设计算后得到的性能值)，并将各个受控应用的各个性能的基本值返回至移动终端。

移动终端接收到各个受控应用的性能的分析结果(即上述各个性能的基本值)，可以按照各个性能值对各个受控应用排序，并以折线图等直观方式展示给用户，直观的展示出符合用户使用习惯的不同应用的性能情况，并对受控应用进行高耗、中耗、低耗等级分类；

最后，用户可以选择对高耗应用清理或者卸载等操作，从而优化系统性能。

其中，上述移动终端的操作系统可以是安卓系统。

借助于本发明实施例的方法，本发明实施例通过对系统已安装的所有应用进行整体的性能使用情况的分析，在加速APP启动后获取系统已安装的所有应用的列表，用户可以在此进行选择配置受控应用的名单。加速APP会周期性的监测受控名单中应用的一些信息，包括：使用频率、崩溃次数、内存使用量、网络流量、存储空间使用量等。并将这些信息上报至服务器，服务器经过分析处理将受控应用的性能结果返回给移动终端，用户可以根据该结果得知受控应用的性能消耗情况，从而可以进行其他处理(清理、卸载等)。

综上，本发明实施例的方法实施在保证软件设计、软件开发、软件测试都通过的基础之上，对安装运行后的APP进行性能优化管理。对APP从启动到运行再到退出，整个流程的每一个操作和动作，其产生的内存消耗、用电量消耗、响应时间消耗等，全部记录下来并上报至服务器分析处理；运行期间所产生的异常崩溃日志，也会上报至服务器；从而服务器侧可以获得APP上报的数据并进行性能等问题的分析，及时处理解决并通过热修复技术下发补丁包至移动终端的APP，以达到性能优化的目的。

那么通过本发明实施例的上述技术方案可以及时解决在软件测试过程中发现不到的实际问题，在真实的用户使用场景下，加上广泛的系统版本型号的真实使用，最终能够使得产品更加全面的适配不同机型，产品质量也大大提升，用户体验也更加良好。

需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明实施例并不受所描述的动作顺序的限制，因为依据本发明实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本发明实施例所必须的。

与上述本发明实施例所提供的方法相对应，参照图7，示出了本发明一种应用程序的管理装置实施例的结构框图，应用于移动终端，具体可以包括如下模块：

第一采集模块71，用于采集运行的目标应用程序的第一性能数据并发送；

第一接收模块72，用于接收所述目标应用程序的补丁包并存储，所述补丁包为针对性能问题而生成的补丁包，所述性能问题为通过对所述第一性能数据进行分析而得到的；

修复模块73，用于若所述目标应用程序再次启动，则根据所述补丁包对所述目标应用程序进行性能修复。

可选地，所述第一性能数据至少包括以下至少之一：

CPU占用量、内存占用量、上下行流量、移动终端温度、电流强度、电量消耗量、界面操作的响应时间、异常日志、错误日志、存储空间占用量。

可选地，所述第一采集模块71包括：

第一采集子模块，用于按照预设周期采集运行的目标应用程序的第一性能数据并发送；和/或，

第二采集子模块，用于若检测到所述目标应用程序作业务处理，则采集关联于所述业务处理的第一性能数据并发送。

可选地，所述装置还包括：

第一获取模块，用于获取预先配置的受控应用程序名单；

第二采集模块，用于采集所述受控应用程序名单内运行的受控应用程序的第二性能数据并发送；

第二接收模块，用于接收对所述受控应用程序名单内受控应用程序的第二性能数据的分析结果，所述分析结果为根据多次采集的多组第二性能数据而分析得到的；

第一分类模块，用于根据所述分析结果对所述受控应用程序名单内的受控应用程序分类。

可选地，所述装置还包括：

第二获取模块，用于获取预先配置的受控应用程序名单；

第三采集模块，用于按照预设周期采集所述受控应用程序名单内运行的受控应用程序的第二性能数据；

分析模块，用于针对所述受控应用程序名单内的每个受控应用程序的多次采集的多组第二性能数据进行分析，得到每个受控应用程序的第二性能数据的分析结果；

第二分类模块，用于根据所述分析结果对所述受控应用程序名单内的受控应用程序分类。

可选地，所述分析模块包括：

计算子模块，用于针对所述受控应用程序名单内某个受控应用程序的多组第二性能数据，按照第二性能的类别，对每类第二性能数据的数据值分别作预设计算，得到所述某个受控应用程序的第二性能数据的分析结果，所述分析结果包括每类第二性能的性能值。

可选地，所述第二分类模块包括：

排序子模块，用于针对多类第二性能中的目标类别第二性能，对所述受控应用程序名单内的受控应用程序按照所述目标类别第二性能的性能值从高到低进行排序，得到所述目标类别第二性能的受控应用程序的排序结果，其中，所述多类第二性能中的每类第二性能轮流作为所述目标类别第二性能；

分类子模块，用于根据受控应用程序的所述多类第二性能的排序结果，对所述受控应用程序名单内的受控应用程序分类。

可选地，所述第二性能数据包括：启动频率、异常崩溃频率，和/或，进一步包括：所述第一性能数据。

对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

本领域内的技术人员应明白，本发明实施例的实施例可提供为方法、装置、或计算机程序产品。因此，本发明实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明实施例是参照根据本发明实施例的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本发明实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明实施例范围的所有变更和修改。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。

以上对本发明所提供的一种应用程序管理方法和一种应用程序管理装置，进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims (16)

1.一种应用程序的管理方法，其特征在于，应用于移动终端，包括：

采集运行的目标应用程序的第一性能数据并发送；

接收所述目标应用程序的补丁包并存储，所述补丁包为针对性能问题而生成的补丁包，所述性能问题为通过对所述第一性能数据进行分析而得到的；

若所述目标应用程序再次启动，则根据所述补丁包对所述目标应用程序进行性能修复。

2.根据权利要求1所述的方法，其特征在于，所述第一性能数据至少包括以下至少之一：

CPU占用量、内存占用量、上下行流量、移动终端温度、电流强度、电量消耗量、界面操作的响应时间、异常日志、错误日志、存储空间占用量。

3.根据权利要求1所述的方法，其特征在于，所述采集运行的目标应用程序的第一性能数据并发送，包括：

按照预设周期采集运行的目标应用程序的第一性能数据并发送；和/或，

若检测到所述目标应用程序作业务处理，则采集关联于所述业务处理的第一性能数据并发送。

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

获取预先配置的受控应用程序名单；

采集所述受控应用程序名单内运行的受控应用程序的第二性能数据并发送；

接收对所述受控应用程序名单内受控应用程序的第二性能数据的分析结果，所述分析结果为根据多次采集的多组第二性能数据而分析得到的；

根据所述分析结果对所述受控应用程序名单内的受控应用程序分类。

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

获取预先配置的受控应用程序名单；

按照预设周期采集所述受控应用程序名单内运行的受控应用程序的第二性能数据；

针对所述受控应用程序名单内的每个受控应用程序的多次采集的多组第二性能数据进行分析，得到每个受控应用程序的第二性能数据的分析结果；

根据所述分析结果对所述受控应用程序名单内的受控应用程序分类。

6.根据权利要求5所述的方法，其特征在于，所述针对所述受控应用程序名单内的每个受控应用程序的多次采集的多组第二性能数据进行分析，得到每个受控应用程序的第二性能数据的分析结果，包括：

针对所述受控应用程序名单内某个受控应用程序的多组第二性能数据，按照第二性能的类别，对每类第二性能数据的数据值分别作预设计算，得到所述某个受控应用程序的第二性能数据的分析结果，所述分析结果包括每类第二性能的性能值。

7.根据权利要求6所述的方法，其特征在于，所述根据所述分析结果对所述受控应用程序名单内的受控应用程序分类，包括：

针对多类第二性能中的目标类别第二性能，对所述受控应用程序名单内的受控应用程序按照所述目标类别第二性能的性能值从高到低进行排序，得到所述目标类别第二性能的受控应用程序的排序结果，其中，所述多类第二性能中的每类第二性能轮流作为所述目标类别第二性能；

根据受控应用程序的所述多类第二性能的排序结果，对所述受控应用程序名单内的受控应用程序分类。

8.根据权利要求4或5所述的方法，其特征在于，所述第二性能数据包括：启动频率、异常崩溃频率，和/或，进一步包括：所述第一性能数据。

9.一种应用程序的管理装置，其特征在于，应用于移动终端，包括：

第一采集模块，用于采集运行的目标应用程序的第一性能数据并发送；

第一接收模块，用于接收所述目标应用程序的补丁包并存储，所述补丁包为针对性能问题而生成的补丁包，所述性能问题为通过对所述第一性能数据进行分析而得到的；

修复模块，用于若所述目标应用程序再次启动，则根据所述补丁包对所述目标应用程序进行性能修复。

10.根据权利要求9所述的装置，其特征在于，所述第一性能数据至少包括以下至少之一：

CPU占用量、内存占用量、上下行流量、移动终端温度、电流强度、电量消耗量、界面操作的响应时间、异常日志、错误日志、存储空间占用量。

11.根据权利要求9所述的装置，其特征在于，所述第一采集模块包括：

第一采集子模块，用于按照预设周期采集运行的目标应用程序的第一性能数据并发送；和/或，

第二采集子模块，用于若检测到所述目标应用程序作业务处理，则采集关联于所述业务处理的第一性能数据并发送。

12.根据权利要求9所述的装置，其特征在于，所述装置还包括：

第一获取模块，用于获取预先配置的受控应用程序名单；

第二采集模块，用于采集所述受控应用程序名单内运行的受控应用程序的第二性能数据并发送；

第二接收模块，用于接收对所述受控应用程序名单内受控应用程序的第二性能数据的分析结果，所述分析结果为根据多次采集的多组第二性能数据而分析得到的；

第一分类模块，用于根据所述分析结果对所述受控应用程序名单内的受控应用程序分类。

13.根据权利要求9所述的装置，其特征在于，所述装置还包括：

第二获取模块，用于获取预先配置的受控应用程序名单；

第三采集模块，用于按照预设周期采集所述受控应用程序名单内运行的受控应用程序的第二性能数据；

分析模块，用于针对所述受控应用程序名单内的每个受控应用程序的多次采集的多组第二性能数据进行分析，得到每个受控应用程序的第二性能数据的分析结果；

第二分类模块，用于根据所述分析结果对所述受控应用程序名单内的受控应用程序分类。

14.根据权利要求13所述的装置，其特征在于，所述分析模块包括：

计算子模块，用于针对所述受控应用程序名单内某个受控应用程序的多组第二性能数据，按照第二性能的类别，对每类第二性能数据的数据值分别作预设计算，得到所述某个受控应用程序的第二性能数据的分析结果，所述分析结果包括每类第二性能的性能值。

15.根据权利要求14所述的装置，其特征在于，所述第二分类模块包括：

排序子模块，用于针对多类第二性能中的目标类别第二性能，对所述受控应用程序名单内的受控应用程序按照所述目标类别第二性能的性能值从高到低进行排序，得到所述目标类别第二性能的受控应用程序的排序结果，其中，所述多类第二性能中的每类第二性能轮流作为所述目标类别第二性能；

分类子模块，用于根据受控应用程序的所述多类第二性能的排序结果，对所述受控应用程序名单内的受控应用程序分类。

16.根据权利要求12或13所述的装置，其特征在于，所述第二性能数据包括：启动频率、异常崩溃频率，和/或，进一步包括：所述第一性能数据。