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

本发明涉及智能终端技术领域，尤其涉及一种应用程序管理方法和装置。

背景技术：

随着通讯技术的发展，移动终端被越来越广泛的使用，用户可以在移动终端上安装各类应用程序，并通过安装的应用程序执行对应的操作。目前，应用程序的类型涉及生活的方方面面，一台移动终端中往往安装有十几个或数十个应用程序。移动终端在使用过程中，后台运行着大量的应用程序，占用了移动终端的大量内存，使得移动终端运行不流畅以及增加了电量消耗。

目前，针对后台应用的清理，现有技术是在一定时间内清理一次后台应用，清理时保留位于常用应用列表中的后台应用，而关闭其它不位于常用应用列表中的后台应用。

然而，随着用户对不同应用程序的需求变化，用户所需的常用应用也在不断变化。但由于常用应用列表中的应用程序需要用户手动添加或删除，在用户所需的常用应用更换后，容易出现用户忘记手动修改常用应用列表而导致自动清理时将用户所需的常用应用关闭，而非用户所需的应用程序仍保留在后台运行的情况，既浪费了内存又不利于用户的使用体验。

技术实现要素：

本发明实施例提供了一种应用程序管理方法和装置，能够实现常用应用的自动设置，无需用户手动修改常用应用列表，避免因用户的疏忽而导致自动清理时将用户所需的常用应用关闭，而非用户所需的应用程序仍保留在后台运行的情况。

本发明实施例提供的一种应用程序管理方法，包括：

获取预设第一时间长度内终端上已安装的各个应用程序的历史使用数据；

根据所述历史使用数据和预设排序策略对所述各个应用程序进行排序；

将排序后的前N个应用程序确定为常用应用，N为预设的正整数。

可选地，所述历史使用数据包括启动次数和使用时长；

所述根据所述历史使用数据和预设排序策略对所述各个应用程序进行排序具体包括：

获取使用时长阈值；

将使用时长大于或等于所述使用时长阈值的应用程序确定为待排序应用；

判断所述待排序应用的个数是否大于或等于N，若是，则根据所述启动次数和所述使用时长对所述待排序应用进行排序，若否，则将所述使用时长阈值减小一个预设数值，再返回执行所述将使用时长大于或等于所述使用时长阈值的应用程序确定为待排序应用的步骤以及后续步骤。

可选地，所述获取使用时长阈值具体包括：

根据在所述预设第一时间长度内所述各个应用程序的使用时长和启动过的应用个数计算得到各个应用程序的第一使用时长，所述启动过的应用个数为启动次数非零的应用程序的个数；

判断所述第一使用时长是否大于第一时长阈值且小于第二时长阈值，若是，则确定所述第一使用时长为所述使用时长阈值，若否，则执行如下步骤：

若所述第一使用时长大于或等于所述第二时长阈值，则确定所述第二时长阈值为所述使用时长阈值；

若所述第一使用时长小于或等于所述第一时长阈值，则确定所述第一时长阈值为所述使用时长阈值。

可选地，所述根据所述各个应用程序的使用时长和启动过的应用个数计算得到各个应用程序的第一使用时长具体包括：

计算使用时长超过预设的策略时长阈值的应用程序的使用时长之和，得到策略使用时长；

计算总使用时长与所述策略使用时长之差，得到比值计算时长，所述总使用时长为所述各个应用程序的使用时长之和；

计算所述比值计算时长与所述启动过的应用个数的比值，得到所述第一使用时长。

可选地，所述获取预设第一时间长度内终端上已安装的各个应用程序的历史使用数据具体包括：

获取当前系统时间；

若当前系统时间属于工作日，则在工作日时间段内获取所述当前系统时间以前第一时间长度的所述各个应用程序的历史使用数据，所述工作日时间段为排除节假日的时间段；

若当前系统时间属于节假日，则在节假日时间段内获取所述当前系统时间以前第一时间长度的所述各个应用程序的历史使用数据，所述节假日时间段为排除工作日的时间段。

本发明实施例提供的一种应用程序管理装置，包括：

历史使用数据获取模块，用于获取预设第一时间长度内终端上已安装的各个应用程序的历史使用数据；

应用排序模块，用于根据所述历史使用数据和预设排序策略对所述各个应用程序进行排序；

常用应用确定模块，用于将排序后的前N个应用程序确定为常用应用，N为预设的正整数。

可选地，所述历史使用数据包括启动次数和使用时长；

所述应用排序模块具体包括：

时长阈值单元，用于获取使用时长阈值；

待排序应用确定单元，用于将使用时长大于或等于所述使用时长阈值的应用程序确定为待排序应用；

待排序应用判断单元，用于判断所述待排序应用确定单元确定的待排序应用的个数是否大于或等于N；

待排序应用排序单元，用于当所述待排序应用判断单元的判断结果为是时，根据所述启动次数和所述使用时长对所述待排序应用进行排序；

返回触发单元，用于当所述待排序应用判断单元的判断结果为否时，将所述使用时长阈值减小一个预设数值，再返回触发所述待排序应用确定单元。

可选地，所述时长阈值单元具体包括：

第一使用时长计算子单元，用于根据在所述预设第一时间长度内所述各个应用程序的使用时长和启动过的应用个数计算得到各个应用程序的第一使用时长，所述启动过的应用个数为启动次数非零的应用程序的个数；

范围判断子单元，用于判断所述第一使用时长是否大于第一时长阈值且小于第二时长阈值；

第一确定子单元，用于当所述范围判断子单元的判断结果为是时，确定所述第一使用时长为所述使用时长阈值；

第二确定子单元，用于当所述范围判断子单元的判断结果为否时，若所述第一使用时长大于或等于所述第二时长阈值，确定所述第二时长阈值为所述使用时长阈值；

第三确定子单元，用于当所述范围判断子单元的判断结果为否时，若所述第一使用时长小于或等于所述第一时长阈值，则确定所述第一时长阈值为所述使用时长阈值。

可选地，所述第一使用时长计算子单元具体包括：

策略使用时长计算次单元，用于计算使用时长超过预设的策略时长阈值的应用程序的使用时长之和，得到策略使用时长；

比值计算时长计算次单元，用于计算总使用时长与所述策略使用时长之差，得到比值计算时长，所述总使用时长为所述各个应用程序的使用时长之和；

第二比值计算次单元，用于计算所述比值计算时长与所述启动过的应用个数的比值，得到所述第一使用时长。

可选地，所述历史使用数据获取模块具体包括：

系统时间获取单元，用于获取当前系统时间；

工作日历史数据获取单元，用于若当前系统时间属于工作日，则在工作日时间段内获取所述当前系统时间以前第一时间长度的所述各个应用程序的历史使用数据，所述工作日时间段为排除节假日的时间段；

节假日历史数据获取单元，用于若当前系统时间属于节假日，则在节假日时间段内获取所述当前系统时间以前第一时间长度的所述各个应用程序的历史使用数据，所述节假日时间段为排除工作日的时间段。

从以上技术方案可以看出，本发明实施例具有以下优点：

本发明实施例中，首先，获取预设第一时间长度内终端上已安装的各个应用程序的历史使用数据；然后，根据所述历史使用数据和预设排序策略对所述各个应用程序进行排序；最后，将排序后的前N个应用程序确定为常用应用，N为预设的正整数，从而可以实现常用应用的自动设置，无需用户手动修改常用应用列表，避免因用户的疏忽而导致自动清理时将用户所需的常用应用关闭，而非用户所需的应用仍保留在后台运行的情况，提高了后台应用自动清理的准确率，节省内存并提升用户的使用体验。

附图说明

图1为本发明实施例中一种应用程序管理方法一个实施例流程图；

图2为本发明实施例中一种应用程序管理方法在一个应用场景下的流程示意图；

图3为本发明实施例中一种应用程序管理装置一个实施例结构图。

具体实施方式

本发明实施例提供了一种应用程序管理方法和装置，用于解决常用应用列表中的应用需要用户手动添加或删除的问题。

为使得本发明的发明目的、特征、优点能够更加的明显和易懂，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，下面所描述的实施例仅仅是本发明一部分实施例，而非全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。

请参阅图1，本发明实施例中一种应用程序管理方法一个实施例包括：

101、获取预设第一时间长度内终端上已安装的各个应用程序的历史使用数据；

在本实施例中，可以获取预设第一时间长度内终端上已安装的各个应用程序的历史使用数据。可以理解的是，对于本实施例中的应用程序管理方法，其可以在用户需要时进行使用，例如用户手动进行常用应用的更新或更换；也可以在一定更新时间内执行一次，例如每日(即24小时)执行一次该应用程序管理方法，或者实时(即更新时间间隔极短，例如0.5秒)执行该应用程序管理方法，对常用应用进行实时更新。

上述的预设第一时间长度具体可以为12小时、24小时、36小时、48小时等。然而，由于应用程序的使用数据与用户的作息时间密切相关，因此为了使得该预设第一时间长度内获取到的历史使用数据具有有效的参考价值，该预设第一时间长度应当选取24小时的倍数，比如可以为24小时、48小时、72小时等。关于预设第一时间长度选取为24小时的倍数，还因为若选取为12小时或36小时，会获取到无效时间中的历史使用数据，例如获取到了晚上不操作时间。进一步地，为了保证本方法对常用应用的更换速度，该预设第一时间长度取24小时，而24小时正好获取了一个完整的作息时间，能够在保证获取到足够的有效时间的同时也保证了常用应用的刷新率，避免某些临时应用程序因为某一时段操作过多，所以即便其暂停使用一段时间仍可以保有常用应用的地位。

本实施例中，上述的历史使用数据可以包括应用程序的启动次数、启动时间、使用时长、操作次数等数据，其记录了用户对该应用程序的使用情况，从而这些历史使用数据可以反映出用户所需的常用应用是哪些。

另外，上述终端上已安装的各个应用程序是指系统上已安装的所有的应用程序，例如手机或平板电脑上的所有的应用APP。

进一步地，获取预设第一时间长度内终端上已安装的各个应用程序的历史使用数据具体可以包括：

1)获取当前系统时间；

2)若当前系统时间属于工作日，则在工作日时间段内获取所述当前系统时间以前第一时间长度的所述各个应用程序的历史使用数据，所述工作日时间段为排除节假日的时间段；

3)若当前系统时间属于节假日，则在节假日时间段内获取所述当前系统时间以前第一时间长度的所述各个应用程序的历史使用数据，所述节假日时间段为排除工作日的时间段。

可以理解的是，对于用户来说，工作日和节假日下所需的常用应用是不相同的，比如在工作日时，常用应用更多是关于工作和生活的，例如公交APP、导航APP或者办公类APP等；而在节假日，常用应用则更多的是关于休闲和娱乐的，例如美食类APP、旅游类APP、社交类APP或购物类APP等。因此在获取历史使用数据时，可以考虑当前系统时间是属于工作日还是节假日，如果是属于工作日，比如当前时间为星期一上午8点钟，第一时间长度为24小时，则应当获取今天凌晨0点至8点以及上星期五的8点至24点这些时间段内的终端上已安装的各个应用程序的历史使用数据。而如果当前时间是属于节假日，比如当前时间为星期六上午8点钟，第一时间长度为24小时，则应当获取今天凌晨0点至8点以及上星期日的8点至24点这些时间段内的终端上已安装的各个应用程序的历史使用数据。

上述的节假日不仅仅包括每个星期的星期六日，还包括法定节假日以及特殊节假日。用户也可以根据自己的需求对节假日的定义进行调整，例如，若该用户每星期只休息星期天一天，则可以将节假日中的每星期休息日设置为每星期的星期天。对于上述的工作日，其与节假日的定义是相对的，也可以由用户自行定义，此处不再赘述。

需要说明的是，当上述的预设第一时间长度选取为24小时时，如果不进行工作日和节假日的区分，每次节假日与工作日之间切换时可能会出现1天的混乱期，导致获取到的历史使用数据不准确而不具备有效的参考价值。

102、根据所述历史使用数据和预设排序策略对所述各个应用程序进行排序；

在获取到终端上已安装的各个应用程序的历史使用数据之后，可以根据所述历史使用数据和预设排序策略对所述各个应用程序进行排序。

本实施例中，该预设排序策略可以是通过对各个历史使用数据进行加权，计算最终权重来排序，比如，对同一个应用程序的启动次数、启动时间、使用时长和操作次数分别进行加权，从而计算出最终的权重值，然后比较所述各个应用程序的权重值大小，权重越大的排序越靠前。

另外，该预设排序策略还可以是在对应用程序的启动次数和使用时长进行筛选后再行排序，其中，所述历史使用数据可以包括启动次数和使用时长，具体如下：

1)获取使用时长阈值；

2)将使用时长大于或等于所述使用时长阈值的应用程序确定为待排序应用；

3)判断所述待排序应用的个数是否大于或等于N(N为预设的正整数)，若是，则根据所述启动次数和所述使用时长对所述待排序应用进行排序，若否，则将所述使用时长阈值减小一个预设数值，再返回执行所述将使用时长大于或等于所述使用时长阈值的应用确定为待排序应用的步骤以及后续步骤。

可以理解的是，用户所需的常用应用一般其在预设第一时间长度内的使用时长应当超过一定的时间，也即超过使用时长阈值。但为了保证用户所需的常用应用的个数不至于过少，比如若对某用户来说，最后得到的常用应用只有1个，则很可能影响用户的使用体验。因此，当判断发现所述待排序应用的个数小于N时，应当对使用时长阈值进行调整，比如减小一个预设的数值，可以自减10，也可以自减5，从而降低使用时长阈值的“门槛”，使得待排序应用的个数大于或等于N，从而确保最后得到的常用应用不会少于N个。具体地，考虑到使用时长阈值的自减比例应该与其本身大小相关，因此若使用时长阈值大于30分钟，则使用时长阈值自减10；若使用时长阈值小于等于30分钟，则使用时长阈值自减5。

进一步地，所述获取使用时长阈值具体可以包括：

(1)根据在所述预设第一时间长度内所述各个应用程序的使用时长和启动过的应用个数计算得到各个应用程序的第一使用时长，所述启动过的应用个数为启动次数非零的应用程序的个数；

(2)判断所述第一使用时长是否大于第一时长阈值且小于第二时长阈值，若是，则确定所述第一使用时长为所述使用时长阈值，若否，则执行如下步骤：

若所述第一使用时长大于或等于所述第二时长阈值，则确定所述第二时长阈值为所述使用时长阈值；

若所述第一使用时长小于或等于所述第一时长阈值，则确定所述第一时长阈值为所述使用时长阈值。

其中，所述启动过的应用个数可以等于所述各个应用程序的总个数与启动次数为零的应用程序的个数之差。

特别地，所述第一时长阈值可以为13分钟，所述第二时长阈值可以为105分钟。从而，当应用程序的第一使用时长大于13分钟且小于105分钟时，该使用时长阈值取值为该第一使用时长；当应用程序的第一使用时长大于或等于105分钟时，该使用时长阈值取值为105分钟；当应用程序的第一使用时长小于或等于13分钟时，该使用时长阈值取值为13分钟。其中上述13分钟和105分钟的取值是在模拟一般用户的实际情况得到的：目前，用户一天正常使用应用APP的个数在8～18个之间，而应用APP的使用时间在4～14小时之间，按照最小平均数的计算方法：4*60/18＝13分钟，按照最大平均数的计算方法：14*60/8＝105分钟。

更进一步地，所述根据所述各个应用程序的使用时长和启动过的应用个数计算得到各个应用程序的第一使用时长具体可以包括：

1)计算使用时长超过预设的策略时长阈值的应用程序的使用时长之和，得到策略使用时长；

2)计算总使用时长与所述策略使用时长之差，得到比值计算时长，所述总使用时长为所述各个应用程序的使用时长之和；

3)计算所述比值计算时长与所述启动过的应用个数的比值，得到所述第一使用时长。

本实施例中，上述计算策略考虑到某些用户的应用程序中会存在一个或多个并列的“异常”应用程序，比如微信APP和QQ应用程序，甚至还有系统维护相关的APP，比如360安全卫士等，对于这些使用时长较其他应用程序长出许多的APP，也可以将其使用时长从总使用时长中排除，以提高第一使用时长的参考价值，最终提高使用时长阈值的参考价值。因此该计算策略通过策略时长阈值来筛选出哪些应用的使用时长“过长”，使用时长超过策略时长阈值的，则认为这个应用程序为“异常”应用程序，将其使用时长从总使用时长中排除。

具体地，当应用程序中只存在一个“异常”应用程序时，或者该计算策略只考虑一个“异常”应用程序的情况时，上述计算策略则可以调整为：

1)计算总使用时长与最长使用时长之差，得到第一策略时长，所述总使用时长为所述各个应用程序的使用时长之和，所述最长使用时长是指使用时长最长的应用的使用时长；

2)计算所述第一策略时长与所述启动过的应用个数的比值，得到所述第一使用时长。

该第一计算策略重点考虑了使用时长最长的应用程序对第一使用时长的最终值的影响。可以理解的是，用户的应用程序中常会存在一个最常用的应用程序，比如现在社交使用的微信APP，对于一名用户来说，微信APP可能全天候处于开启状态，也即使用时长在一天内可以高达24小时。这种情况下，针对这种“异常”的应用APP的使用时长，应当将其从总使用时长中排除，以提高第一使用时长的参考价值，最终提高使用时长阈值的参考价值。

本实施例中，对于应用程序的启动次数和使用时长的获取，可以分别使用程序“com.android.internal.os.PkgUsageStats”和程序“android.app.usage API”从应用程序的相关信息中提取。

103、将排序后的前N个应用程序确定为常用应用。

在对应用进行排序后，可以将排序后的前N个应用确定为常用应用，其中，N为预设的正整数。一般来说，常用应用的个数在1～10之间，特别地，本实施例中可以选取N为5，也即将排序后的前5个应用程序确定为常用应用。

在本实施例中，在确定出常用应用之后，还可以对系统的后台应用进行自动清理。比如，每30分钟获取一次系统的后台应用，然后判断这些后台应用是否属于常用应用，最后关闭不属于常用应用的后台应用。

本实施例中，首先，获取预设第一时间长度内终端上已安装的各个应用程序的历史使用数据；然后，根据所述历史使用数据和预设排序策略对所述各个应用程序进行排序；最后，将排序后的前N个应用程序确定为常用应用，N为预设的正整数，从而可以实现常用应用的自动设置，无需用户手动修改常用应用列表，避免因用户的疏忽而导致自动清理时将用户所需的常用应用关闭，而非用户所需的应用仍保留在后台运行的情况，提高了后台应用自动清理的准确率，节省内存并提升用户的使用体验。

另外，本实施例中，使用时长阈值的计算算法简单可靠，计算量小，能实现短时间(实时)的常用应用自动更新，配合系统的自动清理，可以提高系统的后台应用的清理效率，避免了后台应用过多导致的卡顿问题，并且保留了用户最需要的应用程序，不需要用户手动设置，在工作日与节假日使用也不会出现任何影响体验的问题。

为便于理解，根据图1所描述的实施例，下面以一个实际应用场景对本发明实施例中的一种应用程序管理方法进行描述：

图2示出了本发明实施例中一种应用程序管理方法在一个应用场景下的流程示意图。

1)开始时，获取当前系统时间；

2)判断当前系统时间是否为工作日，若是，则执行步骤3)，如否，则执行步骤4)；

3)在工作日的时间范围内获取24小时内终端上已安装的各个应用程序的启动次数和使用时长，执行步骤5)；

4)在节假日的时间范围内获取24小时内终端上已安装的各个应用程序的启动次数和使用时长，执行步骤5)；

5)(总使用时长-最长使用时长)/(总应用个数-启动次数为0的应用个数)＝第一使用时长；

6)判断第一使用时长是否大于13分钟且小于105分钟，若是，则执行步骤7)，若否，则执行步骤8)；

7)确定第一使用时长为使用时长阈值，执行步骤9)；

8)若所述第一使用时长大于或等于所述第二时长阈值，则确定所述第二时长阈值为所述使用时长阈值；若所述第一使用时长小于或等于所述第一时长阈值，则确定所述第一时长阈值为所述使用时长阈值；再执行步骤9)；

9)将使用时长大于或等于使用时长阈值的应用程序确定为待排序应用；

10)判断所述待排序应用的个数是否大于或等于5，若是，则执行步骤12)，若否，则执行步骤11)；

11)若使用时长阈值若大于30分钟，则使用时长阈值-10；若使用时长阈值若小于等于30分钟，则使用时长阈值-5；再返回执行步骤9)；

12)对待排序应用进行排序，将前5名应用程序设为常用应用。

上面主要描述了一种应用程序管理方法，下面将对一种应用程序管理装置进行详细描述。

图3示出了本发明实施例中一种应用程序管理装置一个实施例结构图。

本实施例中，所述应用程序管理装置可以装配于智能手机、平板电脑、可穿戴设备、车载导航仪、智能学习机、智能家居中控服务器等智能设备上。

本实施例中，一种应用程序管理装置包括：

历史使用数据获取模块301，用于获取预设第一时间长度内终端上已安装的各个应用程序的历史使用数据；

应用排序模块302，用于根据所述历史使用数据和预设排序策略对所述各个应用程序进行排序；

常用应用确定模块303，用于将排序后的前N个应用确定为常用应用，N为预设的正整数。

进一步地，所述历史使用数据包括启动次数和使用时长；

所述应用排序模块302具体包括：

时长阈值单元3021，用于获取使用时长阈值；

待排序应用确定单元3022，用于将使用时长大于或等于所述使用时长阈值的应用程序确定为待排序应用；

待排序应用判断单元3023，用于判断所述待排序应用确定单元确定的待排序应用的个数是否大于或等于N；

待排序应用排序单元3024，用于当所述待排序应用判断单元3023的判断结果为是时，根据所述启动次数和所述使用时长对所述待排序应用进行排序；

返回触发单元3025，用于当所述待排序应用判断单元3023的判断结果为否时，将所述使用时长阈值减小一个预设数值，再返回触发所述待排序应用确定单元3022。

进一步地，所述时长阈值单元3021具体包括：

第一使用时长计算子单元30211，用于根据在所述预设第一时间长度内所述各个应用程序的使用时长和启动过的应用个数计算得到各个应用程序的第一使用时长，所述启动过的应用个数为启动次数非零的应用程序的个数；

范围判断子单元30212，用于判断所述第一使用时长是否大于第一时长阈值且小于第二时长阈值；

第一确定子单元30213，用于当所述范围判断子单元30212的判断结果为是时，确定所述第一使用时长为所述使用时长阈值；

第二确定子单元30214，用于当所述范围判断子单元30212的判断结果为否时，若所述第一使用时长大于或等于所述第二时长阈值，确定所述第二时长阈值为所述使用时长阈值；

第三确定子单元30215，用于当所述范围判断子单元30212的判断结果为否时，若所述第一使用时长小于或等于所述第一时长阈值，则确定所述第一时长阈值为所述使用时长阈值。

进一步地，所述第一使用时长计算子单元30211具体包括：

策略使用时长计算次单元111，用于计算使用时长超过预设的策略时长阈值的应用程序的使用时长之和，得到策略使用时长；

比值计算时长计算次单元112，用于计算总使用时长与所述策略使用时长之差，得到比值计算时长，所述总使用时长为所述各个应用程序的使用时长之和；

第二比值计算次单元113，用于计算所述比值计算时长与所述启动过的应用个数的比值，得到所述第一使用时长。

进一步地，所述历史使用数据获取模块301具体包括：

系统时间获取单元3011，用于获取当前系统时间；

工作日历史数据获取单元3012，用于若当前系统时间属于工作日，则在工作日时间段内获取所述当前系统时间以前第一时间长度的所述各个应用程序的历史使用数据，所述工作日时间段为排除节假日的时间段；

节假日历史数据获取单元3013，用于若当前系统时间属于节假日，则在节假日时间段内获取所述当前系统时间以前第一时间长度的所述各个应用程序的历史使用数据，所述节假日时间段为排除工作日的时间段。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

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

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

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

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

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