CN109960572A - 设备资源管理方法和装置以及智能终端 - Google Patents

Abstract

本公开是关于一种设备资源管理方法，应用于安装有多个应用程序APP的设备中，所述方法包括：基于所述多个APP的历史使用情况，按照时间窗对所述多个APP进行优先级排序；以及根据所述设备的资源占用数值和所述多个APP的当前状态，在当前时间窗中基于相应的优先级排序结果对所述多个APP进行后台应用控制。根据本公开的实施例，实现基于应用场景的系统性能优化，提升了用户体验。

Description

设备资源管理方法和装置以及智能终端

技术领域

本公开涉及互联网技术领域，尤其涉及一种设备资源管理方法和装置以及智能终端。

背景技术

随着互联网特别是移动网络的普及，越来越多的产品和服务提供商都选择使用应用程序(APP)作为与消费者交互的渠道之一，甚至越来越多的商业用户也选择第三方提供的APP来向普通消费者提供推广、结算、支付等服务。随着终端设备上安装的APP越来越多，其在运行时以及在后台占用的设备资源也日益严重，逐渐将造成设备的系统卡顿变得严重。

以不断拓展的智能支付业务为例，根据某智能POS(Point of Sale，销售终端)机的使用情况以及商户反馈，无论是在独立收银还是混合使用(例如设备兼顾收银、排队和外卖等多种功能)的业务场景下，都会出现系统卡顿的现象，随着使用时间越长甚至会越严重，不仅影响收银相关业务，对其他第三方的应用也会造成影响。

综上所述，对于上述终端设备，需要提供一种能够优化系统性能、提升用户体验的设备资源管理方案。

发明内容

本公开的目的是提供一种设备资源管理方法和装置以及智能终端，进而至少在一定程度上克服由于相关技术的限制和缺陷而导致的一个或者多个问题。

本公开的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本公开的实践而习得。

根据本公开实施例的第一方面，提供一种设备资源管理方法，应用于安装有多个应用程序APP的设备中，所述方法包括：基于所述多个APP的历史使用情况，按照时间窗对所述多个APP进行优先级排序；以及根据所述设备的资源占用数值和所述多个APP的当前状态，在当前时间窗中基于相应的优先级排序结果对所述多个APP进行后台应用控制。

根据本公开实施例的第二方面，提供一种设备资源管理装置，应用于安装有多个应用程序APP的设备中，所述装置包括：优先级模块，设置为基于所述多个APP的历史使用情况，按照时间窗对所述多个APP进行优先级排序；以及应用控制模块，设置为根据所述设备的资源占用数值和所述多个APP的当前状态，在当前时间窗中基于相应的优先级排序结果对所述多个APP进行后台应用控制。

根据本公开实施例的第三方面，提供一种存储有计算机程序的存储介质，所述计算机程序在由安装有多个应用程序APP的设备的处理器运行时，使所述设备执行如以上任一实施例所述的方法。

根据本公开实施例的第四方面，提供一种智能终端，包括：处理器；存储器，存储有可由所述处理器执行的指令；其中所述处理器被配置为执行如以上任一实施例所述的方法。

根据本公开的实施例中，可以基于应用的设备类型适配不同的初始化配置，并且根据用户行为导致的应用数据变化进行优先级的动态调整，从而实现基于应用场景的系统性能优化，提升了用户体验。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

图1为根据本公开一实施例的设备资源管理方法流程图。

图2为根据本公开一实施例的优先级排序流程图。

图3为根据本公开一实施例的后台应用控制流程图。

图4为根据本公开另一实施例的设备资源管理方法流程图。

图5为根据本公开另一实施例的后台应用控制流程图。

图6为根据本公开一实施例的设备资源管理装置示意框图。

图7为根据本公开一实施例的智能终端示意框图。

具体实施方式

下面将参考若干示例性实施方式来描述本发明的原理和精神。应当理解，给出这些实施方式仅仅是为了使本领域技术人员能够更好地理解进而实现本发明，而并非以任何方式限制本发明的范围。相反，提供这些实施方式是为了使本公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。

本领域技术人员知道，本发明的实施方式可以实现为一种系统、装置、设备、方法或计算机程序产品。因此，本公开可以具体实现为以下形式，即：完全的硬件、完全的软件(包括固件、驻留软件、微代码等)，或者硬件和软件结合的形式。

根据本发明的实施方式，提出了一种设备资源管理方法和装置以及介质和智能终端。

下面参考本发明的若干代表性实施方式，详细阐释本发明的原理和精神。

图1为根据本公开一实施例的设备资源管理方法流程图，如图所示，本实施例的方法包括以下步骤S101-S102。在一个实施例中，本实施例的方法可由安装有应用程序APP的设备(例如手机、平板、智能POS机)来执行。

在步骤S101中，基于多个APP的历史使用情况，按照时间窗对多个APP进行优先级排序。

为确定后续步骤S102中后台应用控制的依据，本步骤中需要对多个APP进行优先级排序。本步骤基于微积分原理来实现优先级的排序，先将单个业务周期进行拆解，然后再横向对比多个业务周期完成优先级的计算。这里，单个业务周期的拆解按时间窗来进行，例如以每天24小时为基础细分为24个时间窗，或者以营业时间和非营业时间为基础粗分为2个时间窗，本实施例可视需要采用，此处并不加以限制。

在一个实施例中，本步骤对多个APP的优先级排序按照预设周期进行更新。例如，每次优先级排序对3天内同一时间窗(例如8:00-9:00)的数据相应累加后进行排序，3天后更新一次排序结果。

如图2所示，在一个实施例中，本步骤S101可通过以下包括步骤S201-S202的流程实现。

在步骤S201中，分别统计多个APP在单个时间窗内处于前台的使用时间和切换到前台的前台切换次数。

在步骤S202中，根据所述统计的使用时间和切换次数，按照以下排序策略进行优先级排序：

使用时间越长，对应APP的优先级越高；以及

在两个或多个APP的使用时间相同时，切换次数越高，对应APP的优先级越高。

以设备本地安装的APP 1-3为例，假设经步骤S201统计得到三者在预设周期(例如3天)内同一时间窗(例如8:00-9:00)累加的使用时间和切换次数分别为：APP 1(1小时，10次)、APP 2(0.6小时，15次)和APP 3(0.6小时，12次)，则基于步骤S202的排序策略得到的优先级排序结果为APP 1＞APP 2＞APP 3。

另外，在一个实施例中，上述排序策略还包括：在两个或多个APP的使用时间和切换次数均相同时，切换到前台的时间越早，对应APP的优先级越高。

在一个实施例中，本步骤的优先级排序可仅针对前一周期相应时间窗使用过的应用(也称活跃应用)进行。另外，为了实现设备资源的优化配置，在一个实施例中针对上述优先级排序还可设置优先级限制，例如，在每个时间窗内，可以没有活跃应用，但活跃应用的数目不超过预设数目(例如3个)。

在一个实施例中，步骤S101之前还包括获取初始化配置的步骤。

当设备新投入使用时，可从本地或从服务器获取针对设备上已安装的多个APP的初始化配置。在一个实施例中，获取初始化配置的步骤包括根据设备对应的标签，在按照标签建立的同类设备使用习惯数据库中，确定匹配度最高的初始化配置。

以从服务器获取初始化配置为例，所有与服务器通信的设备都与若干个特定的标签绑定(也可以理解为使用设备的用户或商户与这些标签绑定)，不同标签可对应不同的业务属性，例如包括但不限于行业分类、门店规模、业务性质和运营方式等等。服务器侧预先基于这些设备的使用历史大数据生成不同业务场景下使用习惯模型，并同样与标签相对应的存储于使用习惯数据库。当新投入使用的设备与服务器通信时，服务器可根据其绑定的标签搜索同类设备的使用习惯数据库，匹配出最适合的使用习惯模型，以作为初始化配置发送至当前设备。

这里，所述的初始化配置包括上述多个APP中至少部分APP的优先级排序结果。例如，当前设备从服务器获取到最适配的使用习惯模型中携带指示以下优先级的信息：APP 1＞APP 2＞APP 3，则设备将该优先级排序应用于本地安装的APP 1-3以作为初始阶段后台应用控制的依据。在一个实施例中，初始化配置还包括各APP对应的业务属性、活跃状态和虚拟内存值等信息，详见后续实施例的描述。

另外，与步骤S101和S102相对应，此处获取初始化配置的步骤中与多个APP相关的排序等信息也是按时间窗进行存储，例如以每天24小时为基础细分为24个时间窗，或者以营业时间和非营业时间为基础粗分为2个时间窗，本实施例可视需要采用，此处并不加以限制。

在步骤S102中，根据设备的资源占用数值和多个APP的当前状态，在当前时间窗中基于相应的优先级排序结果对多个APP进行后台应用控制。

为了实现设备资源的优化配置，本实施例通过对多个APP的后台应用控制来完成，包括针对多个APP中运行于后台的至少一个APP，结合前述步骤的优先级排序结果、当前设备资源使用情况以及预设阈值来选择性的保活或终止应用。

如图3所示，在一个实施例中，本步骤S102可通过以下包括步骤S301-S305的流程实现。

在步骤S301中，判断设备的资源占用数值是否低于等于预设值，若是则转步骤S302，否则，设备的资源占用数值高于预设值时，转步骤S303。

在步骤S302中，响应于多个APP中任意APP退到后台均进行应用保活。

预设值根据设备资源占用的正常情况进行设置，设备的资源占用数值低于等于预设值时，表示资源占用没有偏离正常情况，无需触发优化配置，任意在后台运行的APP均可以进行保活处理，从而分配相应的系统资源。

在步骤S303中，判断设备的资源占用数值是否低于等于预警值，若是则转步骤S304，否则，设备的资源占用数值高于预警值时，转步骤S305。

在步骤S304中，响应于多个APP中优先级高于等于预设级别的APP退到后台进行应用保活，响应于多个APP中优先级低于预设级别的APP退到后台进行应用终止。

预警值根据设备资源占用的正常边界进行设置，设备的资源占用数值高于预设值但低于等于预警值时，表示资源占用濒临偏离正常情况，从而需要进行优化配置，仅对优先级较高的部分APP分配系统资源。例如，对于APP1＞APP 2＞APP 3的排序结果，假设预设级别为1，则仅在APP 1退到后台运行时才进行保活处理，而对于APP 2或APP 3退到后台运行都进行终止处理，从而将设备的资源占用维持在正常状态。

在步骤S305中，对于多个APP中处于后台的APP，按照优先级从低到高进行应用终止，直至设备的资源占用数值低于等于预设值。

设备的资源占用数值高于预警值，表示设备的资源占用已偏离正常情况，从而需要终止部分后台应用，回收相应的系统资源。例如，对于APP 1＞APP 2＞APP 3的排序结果，在步骤S305中按照APP 3、APP 2、APP 1的顺序终止后台运行的APP，直至设备的资源占用数值低于等于预设值。

在一个实施例中，本步骤S102所提及的资源占用数值可以包括CPU的占用百分比和内存的实际使用数值，相应的预设值和预警值也针对CPU和内存分别进行设置。

另外，对于步骤S305的终止条件“设备的资源占用数值低于等于预设值”，在资源占用数值为内存使用数值时，为便于快速计算，设备的资源占用数值可以利用执行步骤之前的资源占用数值减去初始化配置中相应APP的虚拟内存值来确定。

根据上述实施例的设备资源管理方法，可以基于应用的设备类型适配不同的初始化配置，并且根据用户行为导致的应用数据变化进行优先级的动态调整，从而实现基于应用场景的系统性能优化，提升了用户体验。

在一个实施例中，本公开的设备资源管理方法可应用于有专门业务需求的智能终端(例如智能POS机)。实际上，相关技术方案中的系统性能优化方案都是基于ToC(ToCustomer，针对消费者)的场景，而对于具有专门业务需求的To B(To Business，针对商户)场景，相关技术并没有特别适用的重构方案。一般来说，To B和To C场景有以下几点区别。

第一，TO C不区分细化使用场景，也不区分业务，需要保证消费级别用户使用任何应用都有流畅的体验；而TO B场景有很强的业务属性，需要保证在业务应用的流畅体验下，尽可能让其他应用也有流畅的体验。

第二，TO C场景无法预期，终端设备可能会有几百个应用，用户没有非常明确的使用规律；TO B场景很垂直，业务使用有周期性，用户行为可预期。

第三，TO C场景对电量敏感，需要控制功耗，TO B场景可以随时充电，对电量消耗不敏感。

基于以上区别，以下实施例的设备资源管理方法对TO B场景进行方案重构。图4为该实施例的设备资源管理方法流程图，如图所示，本实施例的方法包括以下步骤S401-S403。在一个实施例中，本实施例的方法可由安装有至少一个业务APP和多个非业务APP的设备来执行。以智能POS机为例，业务APP例如是专用于实现结算收银的APP，而非业务APP例如包括用于实现排队、外卖接单等功能的各种APP。

在步骤S401中，获取并应用针对多个非业务APP的初始化配置。

当设备新投入使用时，可从本地或从服务器获取针对设备上已安装的多个APP的初始化配置。在一个实施例中，本步骤包括根据设备对应的标签，在按照标签建立的同类设备使用习惯数据库中，确定匹配度最高的初始化配置。例如，匹配的具体标签可以包括：商户的行业分类(例如餐饮、酒店、电影等)、商户的门店规模(大中小三个规模可选)、商户的业务性质(快餐、烧烤、正餐等)和商户的运营方式(单店、连锁店)等等。

以从服务器获取初始化配置为例，当商户在第三方提供的智能POS机上第一次登陆时，第三方服务器可获取商户新绑定的标签内容，从而在使用习惯数据库中匹配出最适合的非业务APP初始化配置。初始化配置的内容可参见图1实施例的描述，此处不再赘述。

在步骤S402中，基于多个非业务APP的历史使用情况，按照时间窗对多个非业务APP进行优先级排序。

本步骤的实施可参见图1实施例步骤S101的描述，此处不再重复。

在步骤S403中，根据设备的资源占用数值和所有APP的当前状态，在当前时间窗中基于相应的优先级排序结果对所有APP进行后台应用控制。

为了实现设备资源的优化配置，本实施例通过对所有APP的后台应用控制来完成，包括针对上述的至少一个业务APP和多个非业务APP，结合前述步骤的优先级排序结果、当前设备资源使用情况以及预设阈值来选择性的保活或终止应用。

与图1实施例步骤S102不同的是，由于此处适用的To B场景，本步骤S403中同时要考虑业务APP的状态。如图5所示，在一个实施例中，本步骤S403可通过以下包括步骤S501-S505的流程实现。

在步骤S501中，判断设备的资源占用数值是否低于等于预设值，若是则转步骤S502，否则，设备的资源占用数值高于预设值时，转步骤S503。

在步骤S502中，响应于所有APP中任意APP退到后台均进行应用保活。

预设值根据设备资源占用的正常情况进行设置，设备的资源占用数值低于等于预设值时，表示资源占用没有偏离正常情况，无需触发优化配置，任意在后台运行的APP均可以进行保活处理，从而分配相应的系统资源。

在步骤S503中，判断设备的资源占用数值是否低于等于预警值，若是则转步骤S504，否则，设备的资源占用数值高于预警值时，转步骤S505。

在步骤S504中，响应于任意业务APP退到后台均进行应用保活，响应于多个非业务APP中优先级高于等于预设级别的APP退到后台进行应用保活，响应于多个非业务APP中优先级低于预设级别的APP退到后台进行应用终止。

预警值根据设备资源占用的正常边界进行设置，设备的资源占用数值高于预设值但低于等于预警值时，表示资源占用濒临偏离正常情况，从而需要进行优化配置，仅对业务APP以及优先级较高的部分非业务APP分配系统资源。例如，对于非业务APP的排序结果APP1＞APP 2＞APP 3，假设预设级别为1，则仅在APP 1退到后台运行时才进行保活处理，而对于APP 2或APP 3退到后台运行都进行终止处理，从而在保证为业务APP分配足够资源的条件下将设备的资源占用维持在正常状态。

在步骤S505中，对于多个非业务APP中处于后台的非业务APP，按照优先级从低到高进行应用终止，直至设备的资源占用数值低于等于预设值。

设备的资源占用数值高于预警值，表示设备的资源占用已偏离正常情况，从而需要终止部分后台应用，回收相应的系统资源。例如，对于APP 1＞APP 2＞APP 3的排序结果，在步骤S505中按照APP 3、APP 2、APP 1的顺序终止后台运行的APP，直至设备的资源占用数值低于等于预设值。

图5实施例的其他内容可参见图3实施例的描述，此处不再重复。

根据上述实施例的设备资源管理方法，针对To B场景进行了重构，可以基于设备应用的场景类型适配不同的初始化配置，并且根据用户行为导致的应用数据变化进行非业务应用优先级的动态调整，从而在保证为业务应用分配足够资源的条件下将设备的资源占用始终维持在正常状态，实现基于应用场景的系统性能优化，提升了用户体验。

需要说明的是，尽管在附图中以特定顺序描述了本公开中方法的各个步骤，但是，这并非要求或者暗示必须按照该特定顺序来执行这些步骤，或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的，可以省略某些步骤，将多个步骤合并为一个步骤执行，以及/或者将一个步骤分解为多个步骤执行等。另外，也易于理解的是，这些步骤可以是例如在多个模块/进程/线程中同步或异步执行。

本示例实施方式中进一步提供了一种设备资源管理装置。

图6为根据本公开一实施例的设备资源管理装置示意框图。如图所示，本实施例的设备资源管理装置包括优先级模块61和应用控制模块62。

在一个实施例中，优先级模块61设置为基于多个APP的历史使用情况，按照时间窗对上述多个APP进行优先级排序；应用控制模块62设置为根据设备的资源占用数值和多个APP的当前状态，在当前时间窗中基于相应的优先级排序结果对上述多个APP进行后台应用控制。

在一个实施例中，优先级模块61设置为分别统计所述多个APP在单个时间窗内处于前台的使用时间和切换到前台的前台切换次数，并根据所述统计的使用时间和切换次数，按照预设排序策略进行所述优先级排序。

在一个实施例中，上述预设排序策略包括：使用时间越长，对应APP的优先级越高；在两个或多个APP的使用时间相同时，所述切换次数越高，对应APP的优先级越高。在另一个实施例中，上述预设排序策略还包括：在两个或多个APP的使用时间和切换次数均相同时，切换到前台的时间越早，对应APP的优先级越高。

在一个实施例中，优先级模块61还设置为按照预设周期更新所述对多个APP的优先级排序。

在一个实施例中，应用控制模块62的后台应用控制包括以下至少一种：在所述设备的资源占用数值低于等于预设值时，响应于所述多个APP中任意APP退到后台均进行应用保活；在所述设备的资源占用数值高于预设值但低于等于预警值时，响应于所述多个APP中优先级高于等于预设级别的APP退到后台进行应用保活，响应于所述多个APP中优先级低于预设级别的APP退到后台进行应用终止；以及在所述设备的资源占用数值高于预警值时，对于所述多个APP中处于后台的APP，按照优先级从低到高进行应用终止，直至所述设备的资源占用数值低于等于预设值。

在一个实施例中，设备资源管理装置还包括初始化模块(图中未示出)，设置为根据设备对应的标签，从按照标签建立的同类设备使用习惯数据库中，获取匹配度最高的初始化配置。在一个实施例中，所述初始化配置包括上述多个APP中至少部分APP的优先级排序结果。

在一个实施例中，上述多个APP为非业务APP，所述设备还安装有业务APP。

关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。作为模块或单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本公开方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

通过以上实施方式的描述，本领域的技术人员易于理解，上文描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。

例如，在一个示例实施方式中，还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时可以实现上述任意一个实施例中所述方法的步骤。所述方法的具体步骤可参考前述实施例中的详细描述，此处不再赘述。所述计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

在另一个示例实施方式中，还提供一种智能终端，该智能终端可以是手机、平板电脑等移动终端，也可以是台式计算机、服务器等终端设备，本示例实施方式中对此不作限制。图7示出根据本公开示例实施方式中一种智能终端70的示意图。例如，智能终端70可以被提供为一移动终端。参照图7，设备70包括处理组件71，其进一步包括一个或多个处理器，以及由存储器72所代表的存储器资源，用于存储可由处理组件71的执行的指令，例如应用程序。存储器72中存储的应用程序可以包括一个或一个以上的每一个对应于一组指令的模块。此外，处理组件71被配置为执行指令，以执行上述设备资源管理方法。该方法的步骤可参考前述方法实施例中的详细描述，此处不再赘述。

智能终端70还可以包括一个电源组件73被配置为执行智能终端70的电源管理，一个有线或无线网络接口74被配置为将智能终端70连接到网络，和一个输入输出(I/O)接口75。智能终端70可以操作基于存储在存储器72的操作系统，例如Android、IOS或类似。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由所附的权利要求指出。

虽然已参照几个典型实施例描述了本公开，但应当理解，所用的术语是说明和示例性、而非限制性的术语。由于本公开能够以多种形式具体实施而不脱离申请的精神或实质，所以应当理解，上述实施例不限于任何前述的细节，而应在随附权利要求所限定的精神和范围内广泛地解释，因此落入权利要求或其等效范围内的全部变化和改型都应为随附权利要求所涵盖。

Claims (10)

1.一种设备资源管理方法，应用于安装有多个应用程序APP的设备中，所述方法包括：

基于所述多个APP的历史使用情况，按照时间窗对所述多个APP进行优先级排序；以及

根据所述设备的资源占用数值和所述多个APP的当前状态，在当前时间窗中基于相应的优先级排序结果对所述多个APP进行后台应用控制。

2.如权利要求1所述的方法，其中，所述对多个APP进行优先级排序包括：

分别统计所述多个APP在单个时间窗内处于前台的使用时间和切换到前台的前台切换次数；以及

根据所述统计的使用时间和切换次数，按照以下排序策略进行所述优先级排序：

使用时间越长，对应APP的优先级越高；

在两个或多个APP的使用时间相同时，所述切换次数越高，对应APP的优先级越高。

3.如权利要求2所述的方法，其中，所述排序策略还包括：在两个或多个APP的使用时间和切换次数均相同时，切换到前台的时间越早，对应APP的优先级越高。

4.如权利要求2所述的方法，其中，按照预设周期更新所述对多个APP的优先级排序。

5.如权利要求1所述的方法，其中，所述对多个APP进行后台应用控制包括以下步骤的至少一个：

在所述设备的资源占用数值低于等于预设值时，响应于所述多个APP中任意APP退到后台均进行应用保活；

在所述设备的资源占用数值高于预设值但低于等于预警值时，响应于所述多个APP中优先级高于等于预设级别的APP退到后台进行应用保活，响应于所述多个APP中优先级低于预设级别的APP退到后台进行应用终止；以及

在所述设备的资源占用数值高于预警值时，对于所述多个APP中处于后台的APP，按照优先级从低到高进行应用终止，直至所述设备的资源占用数值低于等于预设值。

6.如权利要求1所述的方法，其中，在所述按照时间窗对所述多个APP进行优先级排序之前，所述方法还包括：

根据所述设备对应的标签，从按照标签建立的同类设备使用习惯数据库中，获取匹配度最高的初始化配置；所述初始化配置包括所述多个APP中至少部分APP的优先级排序结果。

7.如权利要求1至6任一项所述的方法，其中，所述多个APP为非业务APP，所述设备还安装有业务APP。

8.一种设备资源管理装置，应用于安装有多个应用程序APP的设备中，所述装置包括：

优先级模块，设置为基于所述多个APP的历史使用情况，按照时间窗对所述多个APP进行优先级排序；以及

应用控制模块，设置为根据所述设备的资源占用数值和所述多个APP的当前状态，在当前时间窗中基于相应的优先级排序结果对所述多个APP进行后台应用控制。

9.一种存储有计算机程序的存储介质，所述计算机程序在由安装有多个应用程序APP的设备的处理器运行时，使所述设备执行如权利要求1-6中任一项所述的方法。

10.一种智能终端，包括：

处理器；

存储器，存储有可由所述处理器执行的指令；

其中所述处理器被配置为执行如权利要求1-6中任一项所述的方法。