CN111190721A - 移动终端中处理应用程序的方法及移动终端 - Google Patents

Abstract

本申请提供一种移动终端中处理应用程序的方法及移动终端，所述方法包括：若检测到应用程序的运行状态发生变化，则确定所述应用程序的相关进程；按照预设的调整规则设置所述相关进程的CPU亲和力掩码，以将所述相关进程绑定到指定的CPU核心上运行。应用该方法，可以实现根据应用程序的运行状态自动调整为应用程序分配的***资源，有效避免用户在使用应用程序过程中，出现启动慢、卡顿、无反应等情况的发生，提升用户体验。

Description

移动终端中处理应用程序的方法及移动终端

技术领域

本申请涉及移动终端技术领域，尤其涉及一种移动终端中处理应用程序的方法及移动终端。

背景技术

随着移动终端，例如智能手机、平板等设备的发展，涌现出各式各样的应用程序，用户可根据自身需求在移动终端上安装多个应用程序，其中，一些应用程序具有可后台运行的特性。

目前，受移动终端硬件配置的限制，以及移动终端总使用时长的影响，用户在使用应用程序过程中，通常会出现启动慢、卡顿、无反应等情况，从而影响用户体验。现有技术中，当出现上述情况时，用户可通过清理内存的方式清理应用缓存，以及处于后台的应用程序，从而提高处于前台的应用程序的运行效率。

然而，上述方式仅仅是一种在处于前台的应用程序已经出现启动慢、卡顿、无反应等情况下，由用户手动对该情况进行改善的手段，并无法有效避免出现上述情况，也无法从根本上提升用户体验。

发明内容

有鉴于此，本申请提供一种移动终端中处理应用程序的方法及移动终端，以实现根据应用程序的运行状态自动调整为应用程序分配的***资源，有效避免用户在使用应用程序过程中，出现启动慢、卡顿、无反应等情况的发生，提升用户体验。

具体地，本申请是通过如下技术方案实现的：

根据本申请实施例的第一方面，提供一种移动终端中处理应用程序的方法，所述方法包括：

若检测到应用程序的运行状态发生变化，则确定所述应用程序的相关进程；

按照预设的调整规则设置所述相关进程的CPU亲和力掩码，以将所述相关进程绑定到指定的CPU核心上运行。

可选的，所述应用程序的运行状态发生变化包括：应用程序的运行状态由前台切换为后台；

所述指定的CPU核心为主频最小的CPU核心。

可选的，所述应用程序的运行状态发生变化包括：应用程序的运行状态由后台切换为前台；

所述指定的CPU核心为主频最大的CPU核心。

可选的，所述方法还包括：

若所述应用程序为预设的常用应用程序，则按照预设的重要性级别调整规则调整所述相关进程的oom_adj值。

可选的，所述方法还包括：

若所述应用程序为预设的常用应用程序，则根据预设的提频规则提升所述主频最大的CPU核心的运行频率。

可选的，通过以下步骤确定常用应用程序：

根据应用程序的用户使用参数，计算出所述应用程序的用户相关度；

将所述应用程序按照用户相关度从大到小的顺序进行排序；

根据排序结果，将排在前预设数量位的应用程序确定为常用应用程序。

可选的，所述用户使用参数包括下述至少一种：

应用程序的启动次数、使用应用程序的总时长、最近一次使用应用程序的时长、最近一次退出应用程序的时间点。

根据本申请实施例的第二方面，提供一种移动终端中处理应用程序的装置所述装置包括：

确定模块，用于若检测到应用程序的运行状态发生变化，则确定所述应用程序的相关进程；

设置模块，用于按照预设的调整规则设置所述相关进程的CPU亲和力掩码，以将所述相关进程绑定到指定的CPU核心上运行。

可选的，所述应用程序的运行状态发生变化包括：应用程序的运行状态由前台切换为后台；

所述指定的CPU核心为主频最小的CPU核心。

可选的，所述应用程序的运行状态发生变化包括：应用程序的运行状态由后台切换为前台；

所述指定的CPU核心为主频最大的CPU核心。

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

重要级调整模块，用于若所述应用程序为预设的常用应用程序，则按照预设的重要性级别调整规则调整所述相关进程的oom_adj值。

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

提频模块，用于若所述应用程序为预设的常用应用程序，则根据预设的提频规则提升所述主频最大的CPU核心的运行频率。

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

相关度计算模块，用于根据应用程序的用户使用参数，计算出所述应用程序的用户相关度；

排序模块，用于将所述应用程序按照用户相关度从大到小的顺序进行排序；

常用应用确定模块，用于根据排序结果，将排在前预设数量位的应用程序确定为常用应用程序。

可选的，所述用户使用参数包括下述至少一种：

应用程序的启动次数、使用应用程序的总时长、最近一次使用应用程序的时长、最近一次退出应用程序的时间点。

根据本申请实施例的第三方面，提供一种移动终端，包括存储器、处理器、通信接口，以及通信总线；

其中，所述存储器、处理器、通信接口通过所述通信总线进行相互间的通信；

所述存储器，用于存放计算机程序；

所述处理器，用于执行所述存储器上所存放的计算机程序，所述处理器执行所述计算机程序时实现本申请实施例提供的一种移动终端中处理应用程序的方法的步骤。

根据本申请实施例的第四方面，提供一种计算机可读存储介质，所述存储介质内存储有计算机程序，所述计算机程序被处理器执行时实现本申请实施例提供的一种移动终端中处理应用程序的方法的步骤。

由上述实施例可见，通过检测到应用程序的运行状态发生变化，则确定应用程序的相关进程；按照预设的调整规则设置该相关进程的CPU亲和力掩码，以将该相关进程绑定到指定的CPU核心上运行，可以实现根据应用程序的运行状态为应用程序分配***资源，从而提高处于前台运行状态的应用程序的运行效率，有效避免启动慢、卡顿、无反应等情况的发生，提升用户体验。

附图说明

图1为本申请一示例性实施例提供的一种移动终端中处理应用程序的方法的实施例流程图；

图2为本申请一示例性实施例提供的另一种移动终端中处理应用程序的方法的实施例流程图；

图3为应用程序的运行状态变化序列的一种示例；

图4为本申请一示例性实施例提供的一种移动终端中处理应用程序的装置的实施例框图；

图5为本申请移动终端中处理应用程序的装置所在移动终端的一种硬件结构图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

为了解决现有技术中仅仅提供一种在处于前台的应用程序已经出现启动慢、卡顿、无反应等情况下，由用户手动通过清理内存的方式对该情况进行改善，以提高处于前台的应用程序的反应速度的手段，通过该手段，并无法有效避免出现上述情况，也无法从根本上提升用户体验的问题，本申请实施例提供一种移动终端中处理应用程序的方法，通过该方法，可以实现根据应用程序的运行状态自动调整为应用分配的***资源，提升用户体验。

如下，示出下述实施例，对该移动终端中处理应用程序的方法进行说明：

实施例一：

请参见图1，为本申请一示例性实施例提供的一种一种移动终端中处理应用程序的方法的实施例流程图，包括以下步骤：

步骤101：若检测到应用程序的运行状态发生变化，则确定该应用程序的相关进程。

在本申请实施例中，以移动终端执行该方法为例，移动终端上可安装有多个应用程序，例如微信、支付宝等。其中，对于具有后台运行特性的应用程序而言，应用程序的运行状态发生变化可以指：应用程序的运行状态由前台切换为后台，或者，应用程序的运行状态由后台切换为前台。

在本申请实施例中，若检测到应用程序的运行状态发生变化，则可以确定该应用程序的相关进程，例如，可以通过调用“ps|grep PackageName”这一指令，确定该应用程序的相关进程，其中，“PackageName”为该应用程序的包名。

步骤102：按照预设的调整规则设置相关进程的CPU亲和力掩码，以将相关进程绑定到指定的CPU核心上运行。

在确定应用程序的相关进程之后，可以按照预设的调整规则设置该些相关进程的CPU亲和力掩码，本领域技术人员可以理解的是，CPU亲和力是指将一个多个进程绑定到一个或多个CPU核心上运行，而进程的CPU亲和力掩码则决定该进程将在哪个或哪几个CPU核心上运行，从而，设置相关进程的CPU亲和力掩码，可以实现设置相关进程所绑定的CPU核心。

其中，CPU核心又称内核，是CPU最重要的组成部分，一块CPU上可具有多个CPU核心。以移动终端的CPU上具有8个CPU核心为例，假设该8个CPU核心的编号分别为0～7，其中，编号为0～3的CPU核心为一组，编号为4～7的CPU核心为另一组(每一组中各个CPU核心的规格相同，不同组中CPU核心的规格不同)，假设编号为0～3的CPU核心的可运行频率为0.63GHz～1.6GHz，编号为4～7的CPU核心的可运行频率为1.1GHz～1.8GHz，那么，则可以将编号为0～3的CPU核心称为主频最小的CPU核心，将编号为4～7的CPU核心称为主频最大的CPU核心。

基于上述举例，进程的CPU亲和力掩码则可以包括8位，每一位对应一个CPU核心，例如，按照从右往左的顺序，各个位依次对应编号为0～7的CPU核心，其中，位上的取值可以为0或1，当取值为1时，则表示进程绑定该位对应的CPU核心。由此可见，通过设置相关进程的CPU亲和力掩码，可以实现设置相关进程所绑定的CPU核心。

在应用程序的运行状态由前台切换为后台的情况下，上述指定的CPU核心为主频最小的CPU核心。举例来说，上述调整规则可以为：将相关进程的CPU亲和力掩码设置为“00001100”(表示将相关进程绑定到编号为2和3的主频最小的CPU核心上运行)，或“00000011”(表示将相关进程绑定到编号为0和1的主频最小的CPU核心上运行)，或“00000110”(表示将相关进程绑定到编号为1和2的主频最小的CPU核心上运行)，等等，从而实现将相关进程绑定到指定的主频最小的CPU核心上运行。

在应用程序的运行状态由后台切换为前台的情况下，上述指定的CPU核心为主频最大的CPU核心，举例来说，上述调整规则可以为：将相关进程的CPU亲和力掩码设置为“00110000”(表示将相关进程绑定到编号为4和5的主频最大的CPU核心上运行)，或“11000000”表示将相关进程绑定到编号为6和7的主频最的大CPU核心上运行)，或“01100000”表示将相关进程绑定到编号为5和6的主频最大的CPU核心上运行)，等等，从而实现将相关进程绑定到指定的主频最大的CPU核心上运行。

此外，在本申请实施例中，在应用程序的运行状态由前台切换为后台的情况下，还可以进一步判断该应用程序是否为常用应用，通俗来说，常用应用程序即为用户使用频次较多的应用程序，若该应用程序为常用应用程序，还可以按照预设的重要性级别调整规则调整上述相关进程的oom_adj值，具体地，可以将相关进程的oom_adj值调小，以实现提高该些相关进程的重要性级别。通过提高常用应用程序的相关进程的重要性级别，可以降低常用应用程序切换至后台后，其相关进程被杀死的概率，并且，在之后将该常用应用程序重新切换至前台时，可以提高其启动速度。

此外，在本申请实施例中，在应用程序的运行状态由后台切换为前台的情况下，也可以进一步判断该应用程序是否为常用应用程序，若该应用程序为常用应用程序，则可以按照预设的提频规则提升上述指定的CPU核心的运行频率，例如，将指定的主频最大的CPU核心的运行频率提升至其允许的最大运行频率。通过提高上述指定的CPU核心的运行频率，可以提高应用程序的运行效率。

在此说明，上述常用应用程序可以为预先设置的，至于预先设置常用应用程序的方式，可以参见下述实施例二中的描述，在此先不作详述。

由上述实施例可见，通过检测到应用程序的运行状态发生变化，则确定应用程序的相关进程；按照预设的调整规则设置该相关进程的CPU亲和力掩码，以将该相关进程绑定到指定的CPU核心上运行，可以实现根据应用程序的运行状态为应用程序分配***资源，从而提高处于前台运行状态的应用程序的运行效率，有效避免启动慢、卡顿、无反应等情况的发生，提升用户体验。

至此，完成实施例一的相关描述。

其次，示出下述实施例二，对常用应用程序的设置过程进行说明：

实施例二：

请参见图2，为本申请一示例性实施例提供的另一种移动终端中处理应用程序的方法的实施例流程图，该方法在上述图1所示方法的基础上，包括以下步骤：

步骤201：根据应用程序的用户使用参数，计算出应用程序的用户相关度。

首先说明，用户使用参数可以包括下述一项或几项：应用程序的启动次数、使用应用程序的总时长、最近一次使用应用程序的时长、最近一次退出应用程序的时间点。其中，应用程序的启动次数可以指，在预设时长内，应用程序被启动，以及由后台切换为前台的次数；使用应用程序的总时长可以指，在预设时长内，应用程序处于前台的总时长；最近一次使用应用程序的时长可以指，在预设时长内，应用程序最后一次处于前台的时长。

基于上述描述，在本申请实施例中，可以设定一个预设时长，在该预设时长内，针对任一应用程序，记录下应用程序启动的时间点、运行状态发生变化的时间点，以及退出的时间点，其中，运行状态发生变化可以包括：由前台切换为后台，由后台切换为前台。

通过这一记录过程，则可以得到应用程序的运行状态变化序列，如图3所示，为应用程序的运行状态变化序列的一种示例。如图3所示，在上午8点，应用程序被启动，并在前台运行，在上午12点，应用由前台切换至后台，在下午两点，应用再次由后台切换至前台，在下午6点，应用程序退出。

基于上述所记录的时间点，则可以得到上述用户使用参数，例如，在图3的示例中，应用程序的启动次数为2次；使用应用程序的总时长为8小时(包括上午8点～12点，下午2点～6点)；最近一次使用应用程序的时长为4小时(包括下午2点～6点)；最近一次退出应用程序的时间点为下午6点。

后续，则可以根据应用程序的用户使用参数，计算出该应用程序的用户相关度。

首先说明，在本申请实施例中，应用程序的用户相关度可以表示用户使用应用程序的频次，其中，用户使用应用程序的频次越高，即该应用程序越常用，则该应用程序的用户相关度越高。

其中，若具有多项用户使用参数，则可以针对每一项用户使用参数，分别计算出一个用户相关度，之后，将计算出的各个用户相关度相加，即可得到最终该应用程序的用户相关度。

如下，以用户使用参数为应用程序的启动次数为例，对用户相关度的计算过程进行说明：

在一个可选的实现方式中，可以预先设置一个用户相关度集合，该用户相关度集合中可包括若干个，例如m个用户相关度的值，且该m个用户相关度的值按照降序或者升序顺序排列，之后，将各应用程序，例如k个应用程序，按照其启动次数，采用同样的降序或升序方式进行排列，根据排列结果，将每

个应用程序分为一组，针对任一组，其包含的应用程序的用户相关度则为n(n为该组在所有组中的排列位置)。

举例来说，假设用户相关度集合为{13，9，5，2，1，0}，该用户相关度集合中包括6个用户相关度的值，且是降序排列的，并假设有12个应用程序，那么，按照上述描述，可以将该12个应用程序按照其启动次数进行降序排列，按照排列结果，可以将排在前2位的应用程序的用户相关度确定为13，将排在第3位和第4位的应用程序的用户相关度确定为9，将排在第5位和第6位的应用程序的用户相关度确定为5，依次类推。

在另一个可选的实现方式中，可以预先设置一个总相关度值，例如为r，并计算出各应用程序的总启动次数，例如为s，那么，针对一个应用程序，假设其启动次数为a，那么，那么，该应用程序的用户相关度则可以通过如下公式(一)计算得出：

在上述公式(一)中，q表示用户相关度。

举例来说，假设总相关度值为100，并假设各应用程序的启动次数之和为20次，其中一个应用程序的启动次数为5次，那么，按照上述公式(一)，可计算得出该应用程序的用户相关度为25。

针对上述使用应用程序的总时长、最近一次使用应用程序的时长，这两个用户使用参数，可以按照上述两种可选实现方式同样的原理，计算出用户相关度，至于对应最近一次退出应用程序的时间点这一用户使用参数而言，则可以按照上述第一种可实现方式的原理，将各应用程序按照最近一次退出应用程序的时间点从先到后，或从后到先的顺序进行排列，计算出用户相关度，本申请实施例对具体的计算过程不再详述。

步骤202：将应用程序按照用户相关度从大到小的顺序进行排序。

步骤203：根据排序结果，将排在前预设数量位的应用程序确定为常用应用程序。

在步骤202与步骤203中，则可以将应用程序按照用户相关度从大到小的顺序进行排序，根据排序结果，将排在前预设数量位，例如，前2位的应用程序确定为常用应用程序。

需要说明的是，常用应用程序并非是固定不变的，在本申请实施例中，可以随着时间的推移，每隔一预设时长，则按照上述步骤401至步骤403的过程重新设置一次常用应用程序。通过该种处理，可以使得设置的常用应用程序更符合用户的实际使用情况，提高针对常用应用程序的***资源分配的准确率。

由上述实施例可见，通过根据应用程序的用户使用参数，计算出应用程序的用户相关度；将应用程序按照用户相关度从大到小的顺序进行排序；根据排序结果，将排在前预设数量位的应用程序确定为常用应用程序，可以实现根据用户对应用程序的实际使用情况，确定出针对用户的常用应用程序。

至此，完成实施二的相关描述。

与前述移动终端中处理应用程序的方法的实施例相对应，本申请还提供了移动终端中处理应用程序的装置的实施例。

请参考图4，为本申请一示例性实施例提供的一种移动终端中处理应用程序的装置的实施例框图，该装置包括：确定模块41、设置模块42。

其中，确定模块41，可以用于若检测到应用程序的运行状态发生变化，则确定所述应用程序的相关进程；

设置模块42，可以用于按照预设的调整规则设置所述相关进程的CPU亲和力掩码，以将所述相关进程绑定到指定的CPU核心上运行。

在一实施例中，所述应用程序的运行状态发生变化包括：应用程序的运行状态由前台切换为后台；

所述指定的CPU核心为主频最小的CPU核心。

在一实施例中，所述应用程序的运行状态发生变化包括：应用程序的运行状态由后台切换为前台；

所述指定的CPU核心为主频最大的CPU核心。

在一实施例中，所述装置还可以包括(图4中未示出)：

重要级调整模块，用于若所述应用程序为预设的常用应用程序，则按照预设的重要性级别调整规则调整所述相关进程的oom_adj值。

在一实施例中，所述装置还可以包括(图4中未示出)：

提频模块，用于若所述应用程序为预设的常用应用程序，则根据预设的提频规则提升所述主频最大的CPU核心的运行频率。

在一实施例中，所述装置还可以包括(图4中未示出)：

相关度计算模块，用于根据应用程序的用户使用参数，计算出所述应用程序的用户相关度；

排序模块，用于将所述应用程序按照用户相关度从大到小的顺序进行排序；

常用应用确定模块，用于根据排序结果，将排在前预设数量位的应用程序确定为常用应用程序。

在一实施例中，所述用户使用参数包括下述至少一种：

应用程序的启动次数、使用应用程序的总时长、最近一次使用应用程序的时长、最近一次退出应用程序的时间点。

本申请移动终端中处理应用程序的装置的实施例可以应用在移动终端上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在移动终端的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图5所示，为本申请移动终端中处理应用程序的装置所在移动终端的一种硬件结构图，除了图5所示的处理器51、内存52、网络接口53、非易失性存储器54，以及内部总线55之外，实施例中装置所在的移动终端通常根据该移动终端的实际功能，还可以包括其他硬件，对此不再赘述。

本申请还提供一种计算机可读存储介质，所述存储介质内存储有计算机程序，所述计算机程序被处理器执行时本申请实施例提供的移动终端中处理应用程序的方法的步骤。

上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

Claims (9)

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

若检测到应用程序的运行状态发生变化，则确定所述应用程序的相关进程；

按照预设的调整规则设置所述相关进程的CPU亲和力掩码，以将所述相关进程绑定到指定的CPU核心上运行。

2.根据权利要求1所述的方法，其特征在于，所述应用程序的运行状态发生变化包括：应用程序的运行状态由前台切换为后台；

所述指定的CPU核心为主频最小的CPU核心。

3.根据权利要求1所述的方法，其特征在于，所述应用程序的运行状态发生变化包括：应用程序的运行状态由后台切换为前台；

所述指定的CPU核心为主频最大的CPU核心。

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

若所述应用程序为预设的常用应用程序，则按照预设的重要性级别调整规则调整所述相关进程的oom_adj值。

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

若所述应用程序为预设的常用应用程序，则根据预设的提频规则提升所述主频最大的CPU核心的运行频率。

6.根据权利要求4或5所述的方法，其特征在于，通过以下步骤确定常用应用程序：

根据应用程序的用户使用参数，计算出所述应用程序的用户相关度；

将所述应用程序按照用户相关度从大到小的顺序进行排序；

根据排序结果，将排在前预设数量位的应用程序确定为常用应用程序。

7.根据权利要求6所述的方法，其特征在于，所述用户使用参数包括下述至少一种：

应用程序的启动次数、使用应用程序的总时长、最近一次使用应用程序的时长、最近一次退出应用程序的时间点。

8.一种移动终端，其特征在于，包括存储器、处理器、通信接口，以及通信总线；

其中，所述存储器、处理器、通信接口通过所述通信总线进行相互间的通信；

所述存储器，用于存放计算机程序；

所述处理器，用于执行所述存储器上所存放的计算机程序，所述处理器执行所述计算机程序时实现权利要求1-7任一所述方法的步骤。

9.一种计算机可读存储介质，其特征在于，所述存储介质内存储有计算机程序，所述计算机程序被处理器执行时实现权利要求1-7任一所述方法的步骤。

Images