CN117130773A - 资源分配方法、装置和设备 - Google Patents

资源分配方法、装置和设备 Download PDF

Info

Publication number
CN117130773A
CN117130773A CN202310488894.2A CN202310488894A CN117130773A CN 117130773 A CN117130773 A CN 117130773A CN 202310488894 A CN202310488894 A CN 202310488894A CN 117130773 A CN117130773 A CN 117130773A
Authority
CN
China
Prior art keywords
cpus
cpu
resource allocation
preset
foreground
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202310488894.2A
Other languages
English (en)
Inventor
梁绪庆
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Honor Device Co Ltd
Original Assignee
Honor Device Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Honor Device Co Ltd filed Critical Honor Device Co Ltd
Priority to CN202310488894.2A priority Critical patent/CN117130773A/zh
Publication of CN117130773A publication Critical patent/CN117130773A/zh
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5038—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the execution order of a plurality of tasks, e.g. taking priority or time dependency constraints into consideration
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5066—Algorithms for mapping a plurality of inter-dependent sub-tasks onto a plurality of physical CPUs

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

本申请公开了一种资源分配方法、装置和设备。该方法包括：应用于包括M个中央处理器CPU的设备中，所述M个CPU被优先分配给前台焦点分组，M为大于1的整数，所述方法包括：获取第一负载信息，所述第一负载信息用于指示在预设时段内每个CPU执行所述前台焦点分组中的待运行进程的平均数量；根据所述第一负载信息，确定资源分配策略；根据所述资源分配策略，为非前台焦点分组分配CPU资源，所述非前台焦点分组的优先级低于所述前台焦点分组的优先级。该方法可以避免系统前台发生卡顿，提高系统的吞吐率，从而实现系统性能的整体提升。

Description

资源分配方法、装置和设备
技术领域
本申请涉及计算机技术领域，更具体地，涉及一种资源分配方法、装置和设备。
背景技术
支持中央处理器(Central Processing Unit，CPU)并行处理的设备(例如，智能手机)的使用已经日益广泛，并行处理能够有效地提升设备的数据处理能力。实际应用中，移动终端支持多任务并行处理的场景如下：用户可以同时打开移动终端中安装的多个应用，当前需要使用的应用的进程在系统前台运行，暂时无需使用的应用的进程在系统后台运行。但在应用的进程在后台进行运行的情况下，有时需要执行一些耗时或占用大量CPU的任务，抢占CPU资源，导致前台运行的应用的进程由于资源被抢占而发生前台卡顿的现象。
因此，亟需提供一种方法，该方法可以避免系统前台发生卡顿，提高系统的吞吐率，从而实现系统性能的整体提升。
发明内容
本申请提供了一种资源分配方法、装置和设备，该方法可以避免系统前台发生卡顿，提高系统的吞吐率，从而实现系统性能的整体提升。
第一方面，提供一种资源分配方法，应用于包括M个中央处理器CPU的设备中，所述M个CPU被优先分配给前台焦点分组，M为大于1的整数，所述方法包括：获取第一负载信息，所述第一负载信息用于指示在预设时段内每个CPU执行所述前台焦点分组中的待运行进程的平均数量；根据所述第一负载信息，确定资源分配策略；根据所述资源分配策略，为非前台焦点分组分配CPU资源，所述非前台焦点分组的优先级低于所述前台焦点分组的优先级。
在本申请实施例中，将设备包括的所有CPU(即M个CPU，M为大于1的整数)优先分配给前台焦点分组，使得前台焦点分组能够根据自身需求从M个CPU中选取前台焦点分组所需要的CPU资源，这样，可以避免前台焦点分组由于CPU资源不充足导致前台发生卡顿现象。进一步，根据用于描述前台焦点分组的负载状态的第一负载信息确定为非前台焦点分组分配CPU资源的资源分配策略。此后，根据资源分配策略为非前台焦点分组分配CPU资源，这样，可以将设备中前台焦点分组未占用的CPU资源分配给非前台焦点分组，可以提高系统的吞吐率，从而实现系统性能的整体提升。
在一种可能的实现方式中，所述根据所述第一负载信息，确定资源分配策略，包括：在所述平均数量不超过第一预设进程数量的情况下，确定所述资源分配策略为将所述M个CPU中的N个CPU分配给所述非前台焦点分组，N是预设的最多能够分配给所述非前台焦点分组的CPU的数量，N为小于或等于M的整数。
在上述技术方案中，在前台焦点分组处于低负载状态的情况下，基本不会存在前台卡顿的现象。这种场景下，为了提升系统的吞吐率，可以放松对非前台焦点分组的CPU资源的限制，即可以将M个CPU中的较多数量(即N个)CPU分配给非前台焦点分组。
可选的，在另一种可能得实现方式中，所述根据所述第一负载信息，确定资源分配策略，包括：在所述平均数量大于第一预设进程数量且小于或等于第二预设进程数量的情况下，根据第二负载信息，确定所述资源分配策略，所述第二负载信息用于指示在所述预设时段内所述M个CPU中的至少一个CPU执行所述非前台焦点分组中的待运行进程的平均数量。
可以理解的是，在上述实现方式中，根据第二负载信息，确定所述资源分配策略，包括：根据所述第二负载信息，确定所述非前台焦点分组需要的CPU数量；根据所述非前台焦点分组需要的CPU数量、第一预设CPU数量和第二预设CPU数量，确定所述资源分配策略，所述第一预设CPU数量是预设的最少能够分配给所述非前台焦点分组的CPU的数量，所述第二预设CPU数量是预设的最多能够分配给所述非前台焦点分组的CPU的数量。
也就是说，在前台焦点分组处于中负载状态的情况下，通过根据非前台焦点分组需求的CPU数量、第一预设数量和第二预设数量，根据非前台焦点分组自身的需求为非前台焦点分组分配CPU资源。其中，在非前台焦点分组自身的需求的CPU数量小于第一预设数量且大于第二预设数量的情况下，为避免前台发生卡顿，这种情况下分配给非前台焦点分组的CPU数量为预设CPU数量(即第一预设CPU数量或第二预设CPU数量)。
可选的，在另一种可能得实现方式中，所述根据所述第一负载信息，确定资源分配策略，包括：在所述平均数量超过第二预设进程数量的情况下，根据资源利用率信息，确定所述资源分配策略，所述资源利用率信息用于指示在所述预设时段内所述M个CPU中的每个CPU实际处理数据的时间占实际运行时间的比例。
在上述技术方案中，在前台焦点分组处于高负载状态的情况下，通过确定M个CPU是否处于高负载状态，以确定接下来的确定资源分配策略的流程，这样，尽可能避免前台发生卡顿现象，同时，还有利于提高系统的吞吐率。
可选的，在另一种可能得实现方式中，所述根据资源利用率信息，确定所述资源分配策略，包括：根据所述资源利用率信息，确定所述M个CPU的利用率；在所述M个CPU的利用率超过预设比例的情况下，确定所述资源分配策略为将所述M个CPU中的K个CPU分配给所述非前台焦点分组，K是预设的最少能够分配给所述非前台焦点分组的CPU的数量，K为小于或等于N的整数；或者，
在所述M个CPU的利用率不超过所述预设比例的情况下，根据第二负载信息，确定所述资源分配策略，所述第二负载信息用于指示在所述预设时段内所述M个CPU中的至少一个CPU执行所述非前台焦点分组中的待运行进程的平均数量。
在上述技术方案中，若M个CPU处于高负载状态，则将预设的最少能够分配给非前台焦点分组的CPU的数量。也就是说，在在前台焦点分组处于高负载状态，且设备包括的M个CPU也处于高负载状态的情况下，为了避免前台发生卡顿现象需要严格限制分配给非前台焦点分组的CPU数量。若M个CPU处于低负载状态，则根据第二负载信息，确定资源分配策略。也就是说，在前台焦点分组处于高负载状态，且设备包括的M个CPU也处于低负载状态的情况下，M个CPU还有较多的资源未被前台焦点分组占用，这种情况下，可以根据非前台焦点分组自身的需求为非前台焦点分组分配CPU资源，这样，有利于提高系统的吞吐率。
可选的，在另一种可能得实现方式中，所述根据第二负载信息，确定所述资源分配策略，包括：根据所述第二负载信息，确定所述非前台焦点分组需要的CPU数量；根据所述非前台焦点分组需要的CPU数量、第一预设CPU数量和第二预设CPU数量，确定所述资源分配策略，所述第一预设CPU数量是预设的最少能够分配给所述非前台焦点分组的CPU的数量，所述第二预设CPU数量是预设的最多能够分配给所述非前台焦点分组的CPU的数量。
可选的，在另一种可能得实现方式中，所述第一预设CPU数量为K，所述第二预设CPU数量为N，N为小于或等于M的整数，K为小于或等于N的整数，所述根据非前台焦点分组需要的CPU数量、第一预设CPU数量和第二预设CPU数量，确定资源分配策略，包括：在所述非前台焦点分组需要的CPU数量小于或等于K的情况下，确定所述资源分配策略为将所述M个CPU中的K个CPU分配给所述非前台焦点分组；在所述非前台焦点分组需要的CPU数量大于或等于N的情况下，确定所述资源分配策略为将所述M个CPU中的N个CPU分配给所述非前台焦点分组；在所述非前台焦点分组需要的CPU数量大于K且小于N的情况下，确定所述资源分配策略为将所述M个CPU中的所述需要的CPU数量个CPU分配给所述非前台焦点分组。
可选的，在另一种可能得实现方式中，所述预设时段内包括P个时间窗口，P为正整数；以及，在所述根据资源利用率信息，确定所述资源分配策略之前，所述方法还包括：获取所述每个CPU在每个时间窗口的利用率，所述每个CPU在所述每个时间窗口的利用率表示在所述每个时间窗口内所述每个CPU实际处理数据的时间占实际运行时间的比例；对所述每个CPU在所述P个时间窗口的利用率执行求和处理，获得所述每个CPU在所述P个时间窗口的总利用率；利用所述总利用率除以所述预设时段，获得在所述预设时段内所述每个CPU处理数据的时间占实际运行时间的比例，以得到所述资源利用率信息。
上述确定资源利用率信息的过程，可以理解为是基于窗口平均算法的求解过程。基于于窗口平均算法确定资源利用率信息，获得的资源利用率信息结果更加准确。这样，有利于提高为非前台焦点分组分配CPU资源的准确性。
可选的，在另一种可能得实现方式中，所述获取第一负载信息，包括：获取所述M个CPU中每个CPU的进程数量，所述每个CPU的进程数量表示在所述预设时段内所述每个CPU的运行队列上属于所述前台焦点分组的进程的数量；对所述M个CPU的进程数量执行求和处理，获得求和处理结果；对所述求和处理结果除以M个预设时段，获得在所述预设时段内所述每个CPU执行所述前台焦点分组中的待运行进程的平均数量，所述M个预设时段和所述M个CPU一一对应。
可选的，在另一种可能得实现方式中，所述根据所述资源分配策略，为所述非前台焦点分组分配CPU资源，包括：根据所述资源分配策略，在所述非前台焦点分组包括多个进程的情况下，根据所述多个进程中的每个进程的优先级为所述非前台焦点分组中的进程分配CPU资源，优先级高的进程所分配到的CPU资源大于优先级低的进程所分配到的CPU资源。
上述技术方案中，根据非前台焦点分组中的进程的优先级为非前台焦点分组中的进程分组CPU资源，这样，可以保证非前台焦点分组中的具有较高优先级的进程分配更多的CPU资源。
可选的，在另一种可能得实现方式中，所述非前台焦点分组为前台分组或后台分组。
第二方面，提供一种资源分配装置，应用于包括M个中央处理器CPU的设备中，所述M个CPU被优先分配给前台焦点分组，M为大于1的整数，用于执行上述第一方面提供的资源分配方法。具体地，所述资源分配装置可以包括用于执行上述第一方面中任一种可能实现方式的模块。
第三方面，提供了一种资源分配设备，包括用于执行第一方面中任一种方法的单元。该设备可以是终端设备，也可以是终端设备内的芯片。该设备可以包括输入单元和处理单元。
当该设备是终端设备时，该处理单元可以是处理器，该输入单元可以是通信接口；该终端设备还可以包括存储器，该存储器用于存储计算机程序代码，当该处理器执行该存储器所存储的计算机程序代码时，使得该终端设备执行第一方面中的任一种方法。
当该设备是终端设备内的芯片时，该处理单元可以是芯片内部的处理单元，该输入单元可以是输出接口、管脚或电路等；该芯片还可以包括存储器，该存储器可以是该芯片内的存储器(例如，寄存器、缓存等)，也可以是位于该芯片外部的存储器(例如，只读存储器、随机存取存储器等)；该存储器用于存储计算机程序代码，当该处理器执行该存储器所存储的计算机程序代码时，使得该芯片执行第一方面中的任一种方法。
在一种可能的实现方式中，存储器用于存储计算机程序代码；处理器，处理器执行该存储器所存储的计算机程序代码，当该存储器存储的计算机程序代码被执行时，该处理器用于执行第一方面中的任一种方法。
第四方面，提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序代码，当所述计算机程序代码被资源分配装置运行时，使得该资源分配装置执行第一方面或第二方面中的任一种资源分配方法。
第五方面，提供了一种计算机程序产品，所述计算机程序产品包括：计算机程序代码，当所述计算机程序代码被资源分配装置运行时，使得该资源分配装置执行第一方面或第二方面中的任一种资源分配方法。
附图说明
图1是本申请实施例提供的电子设备100的硬件系统的示意图。
图2是本申请实施例的电子设备100的软件结构框图。
图3是本申请实施例提供的一种用户使用场景的示意图。
图4A是本申请实施例提供的另一种用户使用场景的示意图。
图4B是本申请实施例提供的又一种用户使用场景的示意图。
图5是本申请实施例提供的电子设备100为分组中的进程分配CPU资源的示意图。
图6是本申请实施例提供的图5示出的cgroup和cgroup所管理的进程的示意图。
图7是本申请实施例提供的一种资源分配方法的示意图。
图8是本申请实施例提供的另一种资源分配方法的示意图。
图9是图8提供的资源分配方法中涉及的N个时间窗口的示意图。
图10是图8提供的资源分配方法中涉及的对ta分组的平均进程数量进行更新的示意图。
图11是图8适用的手机A包括的CPU资源的示意图。
图12是本申请实施例提供的资源分配装置的示意图。
图13是本申请提供的一种资源分配设备的结构的示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
为了便于理解，首先对本申请实施例涉及的专业术语进行介绍。
(1)控制组(control group，cgroup)
cgroup以分组的形式对进程使用系统资源的行为进行管理和控制。也就是说，电子设备可通过cgroup对所有进程进行分组，再对分组整体进行资源的分配和控制。在cgroup中，任务就是系统的一个进程。
具体的，每个cgroup中可以包括一个或多个进程，也可以不包括任何进程。层次等级(hierarchy)可以理解为一颗具有层次等级关系的cgroup树，树的每个节点就是一个cgroup。示例性的，该进程树可以包括前台焦点(top-app,ta)组、前台(foreground,fg)组、系统后台(system-background)组和后台(background,bg)组。示例性的，该进程树可以包括top-app组、foreground组和background组。需要说明的是，本申请中所示的各cgroup的数量和名称仅为示例性举例，本申请对此不作限定。
在Android系统中，基于应用(也可称为任务或进程)的前后台状态，可将应用划分到不同的cgroup中，从而对应用执行与其所属的cgroup对应的调度策略。举例说明，top-app组中可包括用户当前操作所作用的应用，用户当前操作所作用的应用也可以称为焦点应用。foreground分组中可包括导航栏、状态栏等应用。system-backgroud组包括系统运行的应用，例如，电池电量统计等应用。background组包括置于后台的应用，例如桌面应用，或其它切换到后台的应用。以上划分方式仅为示意性举例，本申请对此不作限定。可以理解的是，本申请中一个分组中包括某个应用，即该一个分组包括该某个应用包括的进程。例如，top-app组中包括用户当前操作所作用的应用，即top-app组中包括用户当前操作所作用的应用包括的一个或多个进程。
每个cgroup可与一个或多个子系统(subsystem)关联，subsystem是一个通过cgroup提供的工具和接口来管理进程集合的模块。一个subsystem就是一个典型的“资源控制器”，用来调度资源或者控制资源使用的上限。可以更通俗地理解为，一个subsystem提供一种调度策略，各cgroup绑定一个或多个subsystem，即单一cgroup对应一个或多个subsystem所提供的调度策略，cgroup绑定的一个或多个subsystem，即对应的一个或多个调度策略，构成cgroup的机制(mechanism)。
示例性的，subsystem如表1所示：
表1
子系统 作用
cpuset 绑定cgroup到指定CPU
cpu 限制cgroup的CPU使用率
cpuacct 统计cgroup的CPU使用率
schedtune 选择CPU以及boost触发
参照上述表1，CPU设置(cpuset)用于指示cgroup绑定的CPU。下面，举例描述cpuset的作用。终端包括8个CPU核，分别为核0～核7(包括核0、核1、核2、核3、核4、核5、核6、核7)，其中，核0～核3为小核、核4～核6为中核、核7为大核，需要说明的是，大核、中核与小核可选地是按照核的处理能力划分的，处理能力从大到小依次为：大核＞中核＞小核，下文中不再重复说明。示例性的，若cgroup绑定的subsystem为cpuset，且指示绑定核1和核2，即为将cgroup与核1和核2绑定，也就是说，核1和核2可用于对cgroup的进程进行调度。调度调节(schedtune)用于选择CPU，可以理解为对绑定的CPU核的选择，如上文所述，CPU可分为大核、中核和小核，可通过schedtune指示cgroup与大核、中核和/或小核绑定，以通过具有不同的处理能力的核对不同的cgroup进行调度。subsystem还包括但不限于上述表1中的cpu统计器(CPU AccountingController，cpuacct)和cpu等，可参照已有标准中的描述，此处不再详细赘述。
(2)子系统(subsystem)。
一个子系统就是一个资源控制器，比如cpu子系统就是控制cpu时间分配的一个控制器。子系统必须附加(attach)到一个层级上才能起作用，一个子系统附加到某个层级以后，这个层级上的所有控制族群都受到这个子系统的控制。
(3)进程组
进程组，每个进程组有一个领头进程。进程组是一个或多个进程的集合，通常它们与一组作业相关联，可以接受来自同一终端的各种信号。每个进程组都有唯一的进程组ID(整数，也可以存放在pid_t类型中)。进程组由进程组ID来唯一标识。除了进程号(PID)之外，进程组ID也是一个进程的必备属性之一。
(4)进程(Process)
进程是计算机中的程序关于某数据集合上的一次运行活动，是系统进行资源分配的基本单位，是操作系统结构的基础。进程(process)是一块包含了某些资源的内存区域。操作系统利用进程把它的工作划分为一些功能单元。进程中所包含的一个或多个执行单元称为线程(thread)。进程还拥有一个私有的虚拟地址空间，该空间仅能被它所包含的线程访问。
(5)线程(thread)
线程只能归属于一个进程并且它只能访问该进程所拥有的资源。当操作系统创建一个进程后，该进程会自动申请一个名为主线程或首要线程的线程。
(6)应用程序(application)
应用程序又称为应用，应用程序是由一个或多个相互协作的进程组成的。
(7)运行队列(run queue,rq)
每个CPU都拥有自己的运行队列，用于描述在此CPU上所运行的所有进程。
本申请实施例提供的资源分配方法可以应用于电子设备中。下面，结合附图对电子设备的硬件结构和软件结构进行详细介绍。
图1是本申请实施例提供的电子设备100的硬件系统的示意图。
电子设备100可以是手机、智慧屏、平板电脑、可穿戴电子设备、车载电子设备、增强现实(augmented reality，AR)设备、虚拟现实(virtual reality，VR)设备、笔记本电脑、超级移动个人计算机(ultra-mobile personal computer，UMPC)、上网本、个人数字助理(personal digital assistant，PDA)、投影仪、车载设备等等，本申请实施例对电子设备100的具体类型不作任何限制。
电子设备100可以包括处理器110，外部存储器接口120，内部存储器121，通用串行总线(universal serial bus，USB)接口130，充电管理模块140，电源管理模块141，电池142，天线1，天线2，移动通信模块150，无线通信模块160，音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，传感器模块180，按键190，马达191，指示器192，摄像头193，显示屏194，以及用户标识模块(subscriber identification module，SIM)卡接口195等。其中传感器模块180可以包括压力传感器180A，陀螺仪传感器180B，气压传感器180C，磁传感器180D，加速度传感器180E，距离传感器180F，接近光传感器180G，指纹传感器180H，温度传感器180J，触摸传感器180K，环境光传感器180L，骨传导传感器180M等。
需要说明的是，图1所示的结构并不构成对电子设备100的具体限定。在本申请另一些实施例中，电子设备100可以包括比图1所示的部件更多或更少的部件，或者，电子设备100可以包括图1所示的部件中某些部件的组合，或者，电子设备100可以包括图1所示的部件中某些部件的子部件。图1示的部件可以以硬件、软件、或软件和硬件的组合实现。
处理器110可以包括一个或多个处理单元。例如，处理器110可以包括以下处理单元中的至少一个：应用处理器(application processor，AP)、调制解调处理器、图形处理器(graphics processing unit，GPU)、图像信号处理器(image signal processor，ISP)、控制器、视频编解码器、数字信号处理器(digital signal processor，DSP)、基带处理器、神经网络处理器(neural-network processing unit，NPU)。其中，不同的处理单元可以是独立的器件，也可以是集成的器件。
控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。
处理器110中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110刚用过或循环使用的指令或数据。如果处理器110需要再次使用该指令或数据，可从所述存储器中直接调用。避免了重复存取，减少了处理器110的等待时间，因而提高了系统的效率。
在一些实施例中，处理器110可以包括一个或多个接口。例如，处理器110可以包括以下接口中的至少一个：内部集成电路(inter-integrated circuit，I2C)接口、内部集成电路音频(inter-integrated circuit sound，I2S)接口、脉冲编码调制(pulse codemodulation，PCM)接口、通用异步接收传输器(universal asynchronous receiver/transmitter，UART)接口、移动产业处理器接口(mobile industry processor interface，MIPI)、通用输入输出(general-purpose input/output，GPIO)接口、SIM接口、USB接口。
I2C接口是一种双向同步串行总线，包括一根串行数据线(serial data line，SDA)和一根串行时钟线(derail clock line，SCL)。在一些实施例中，处理器110可以包含多组I2C总线。处理器110可以通过不同的I2C总线接口分别耦合触摸传感器180K、充电器、闪光灯、摄像头193等。例如：处理器110可以通过I2C接口耦合触摸传感器180K，使处理器110与触摸传感器180K通过I2C总线接口通信，实现电子设备100的触摸功能。
I2S接口可以用于音频通信。在一些实施例中，处理器110可以包含多组I2S总线。处理器110可以通过I2S总线与音频模块170耦合，实现处理器110与音频模块170之间的通信。在一些实施例中，音频模块170可以通过I2S接口向无线通信模块160传递音频信号，实现通过蓝牙耳机接听电话的功能。
PCM接口也可以用于音频通信，将模拟信号抽样，量化和编码。在一些实施例中，音频模块170与无线通信模块160可以通过PCM接口耦合。
在一些实施例中，音频模块170也可以通过PCM接口向无线通信模块160传递音频信号，实现通过蓝牙耳机接听电话的功能。所述I2S接口和所述PCM接口都可以用于音频通信。
UART接口是一种通用串行数据总线，用于异步通信。该总线可以为双向通信总线。它将要传输的数据在串行通信与并行通信之间转换。在一些实施例中，UART接口通常被用于连接处理器110与无线通信模块160。例如：处理器110通过UART接口与无线通信模块160中的蓝牙模块通信，实现蓝牙功能。
在一些实施例中，音频模块170可以通过UART接口向无线通信模块160传递音频信号，实现通过蓝牙耳机播放音乐的功能。
MIPI接口可以被用于连接处理器110与显示屏194和摄像头193等外围器件。MIPI接口包括摄像头串行接口(camera serial interface，CSI)、显示屏串行接口(displayserial interface，DSI)等。在一些实施例中，处理器110和摄像头193通过CSI接口通信，实现电子设备100的拍摄功能。处理器110和显示屏194通过DSI接口通信，实现电子设备100的显示功能。
GPIO接口可以通过软件配置。GPIO接口可以被配置为控制信号接口，也可被配置为数据信号接口。
在一些实施例中，GPIO接口可以用于连接处理器110与摄像头193，显示屏194、无线通信模块160、音频模块170和传感器模块180。GPIO接口还可以被配置为I2C接口、I2S接口、UART接口或MIPI接口。
USB接口130是符合USB标准规范的接口，例如可以是迷你(Mini)USB接口、微型(Micro)USB接口或C型USB(USB Type C)接口。USB接口130可以用于连接充电器为电子设备100充电，也可以用于电子设备100与外围设备之间传输数据，还可以用于连接耳机以通过耳机播放音频。USB接口130还可以用于连接其他电子设备100，例如AR设备。
图1所示的各模块间的连接关系只是示意性说明，并不构成对电子设备100的各模块间的连接关系的限定。可选地，电子设备100的各模块也可以采用上述实施例中多种连接方式的组合。
充电管理模块140用于从充电器接收电力。其中，充电器可以是无线充电器，也可以是有线充电器。在一些有线充电的实施例中，充电管理模块140可以通过USB接口130接收有线充电器的电流。在一些无线充电的实施例中，充电管理模块140可以通过电子设备100的无线充电线圈接收电磁波(电流路径如虚线所示)。充电管理模块140为电池142充电的同时，还可以通过电源管理模块141为电子设备100供电。
电源管理模块141用于连接电池142，充电管理模块140与处理器110。电源管理模块141接收电池142和/或充电管理模块140的输入，为处理器110，内部存储器121，显示屏194，摄像头193，和无线通信模块160等供电。电源管理模块141还可以用于监测电池容量、电池循环次数和电池健康状态(例如，漏电、阻抗)等参数。可选地，电源管理模块141可以设置于处理器110中，或者，电源管理模块141和充电管理模块140可以设置于同一个器件中。
电子设备100的无线通信功能可以通过天线1、天线2、移动通信模块150、无线通信模块160、调制解调处理器以及基带处理器等器件实现。
天线1和天线2用于发射和接收电磁波信号。电子设备100中的每个天线可用于覆盖单个或多个通信频带。不同的天线还可以复用，以提高天线的利用率。例如：可以将天线1复用为无线局域网的分集天线。在另外一些实施例中，天线可以和调谐开关结合使用。
移动通信模块150可以提供应用在电子设备100上的无线通信的解决方案，例如下列方案中的至少一个：第二代(2th generation，2G)移动通信解决方案、第三代(3thgeneration，3G)移动通信解决方案、第四代(4th generation，5G)移动通信解决方案、第五代(5th generation，5G)移动通信解决方案。移动通信模块150可以包括至少一个滤波器，开关，功率放大器，低噪声放大器(low noise amplifier，LNA)等。移动通信模块150可以由天线1接收电磁波，并对接收的电磁波进行滤波和放大等处理，随后传送至调制解调处理器进行解调。移动通信模块150还可以放大经调制解调处理器调制后的信号，放大后的该信号经天线1转变为电磁波辐射出去。在一些实施例中，移动通信模块150的至少部分功能模块可以被设置于处理器110中。在一些实施例中，移动通信模块150的至少部分功能模块可以与处理器110的至少部分模块被设置在同一个器件中。
调制解调处理器可以包括调制器和解调器。其中，调制器用于将待发送的低频基带信号调制成中高频信号。解调器用于将接收的电磁波信号解调为低频基带信号。随后解调器将解调得到的低频基带信号传送至基带处理器处理。低频基带信号经基带处理器处理后，被传递给应用处理器。应用处理器通过音频设备(例如，扬声器170A、受话器170B)输出声音信号，或通过显示屏194显示图像或视频。在一些实施例中，调制解调处理器可以是独立的器件。在另一些实施例中，调制解调处理器可以独立于处理器110，与移动通信模块150或其他功能模块设置在同一个器件中。
与移动通信模块150类似，无线通信模块160也可以提供应用在电子设备100上的无线通信解决方案，例如下列方案中的至少一个：无线局域网(wireless local areanetworks，WLAN)、蓝牙(bluetooth，BT)、蓝牙低功耗(bluetooth low energy，BLE)、超宽带(ultra wide band，UWB)、全球导航卫星系统(global navigation satellite system，GNSS)、调频(frequency modulation，FM)、近场通信(near field communication，NFC)、红外(infrared，IR)技术。无线通信模块160可以是集成至少一个通信处理模块的一个或多个器件。无线通信模块160经由天线2接收电磁波，将电磁波信号调频以及滤波处理，并将处理后的信号发送到处理器110。无线通信模块160还可以从处理器110接收待发送的信号，对其进行调频和放大，该信号经天线2转变为电磁波辐射出去。
在一些实施例中，电子设备100的天线1和移动通信模块150耦合，电子设备100的天线2和无线通信模块160耦合，使得电子设备100可以通过无线通信技术与网络和其他电子设备通信。该无线通信技术可以包括以下通信技术中的至少一个：全球移动通讯系统(global system for mobile communications，GSM)，通用分组无线服务(general packetradio service，GPRS)，码分多址接入(code division multiple access，CDMA)，宽带码分多址(wideband code division multiple access，WCDMA)，时分码分多址(time-divisioncode division multiple access，TD-SCDMA)，长期演进(long term evolution，LTE)，BT，GNSS，WLAN，NFC，FM，IR技术。该GNSS可以包括以下定位技术中的至少一个：全球卫星定位系统(global positioning system，GPS)，全球导航卫星系统(global navigationsatellite system，GLONASS)，北斗卫星导航系统(beidou navigation satellitesystem，BDS)，准天顶卫星系统(quasi-zenith satellite system，QZSS)，星基增强系统(satellite based augmentation systems，SBAS)。
电子设备100可以通过GPU、显示屏194以及应用处理器实现显示功能。GPU为图像处理的微处理器，连接显示屏194和应用处理器。GPU用于执行数学和几何计算，用于图形渲染。处理器110可包括一个或多个GPU，其执行程序指令以生成或改变显示信息。
显示屏194可以用于显示图像或视频。显示屏194包括显示面板。显示面板可以采用液晶显示屏(liquid crystal display，LCD)、有机发光二极管(organic light-emitting diode，OLED)、有源矩阵有机发光二极体(active-matrix organic light-emitting diode，AMOLED)、柔性发光二极管(flex light-emitting diode，FLED)、迷你发光二极管(mini light-emitting diode，Mini LED)、微型发光二极管(micro light-emitting diode，Micro LED)、微型OLED(Micro OLED)或量子点发光二极管(quantum dotlight emitting diodes，QLED)。在一些实施例中，电子设备100可以包括1个或N个显示屏194，N为大于1的正整数。
电子设备100可以通过ISP、摄像头193、视频编解码器、GPU、显示屏194以及应用处理器等实现拍摄功能。
ISP用于处理摄像头193反馈的数据。例如，拍照时，打开快门，光线通过镜头被传递到摄像头感光元件上，光信号转换为电信号，摄像头感光元件将所述电信号传递给ISP处理，转化为肉眼可见的图像。ISP可以对图像的噪点、亮度和色彩进行算法优化，ISP还可以优化拍摄场景的曝光和色温等参数。在一些实施例中，ISP可以设置在摄像头193中。
摄像头193用于捕获静态图像或视频。物体通过镜头生成光学图像投射到感光元件。感光元件可以是电荷耦合器件(charge coupled device，CCD)或互补金属氧化物半导体(complementary metal-oxide-semiconductor，CMOS)光电晶体管。感光元件把光信号转换成电信号，之后将电信号传递给ISP转换成数字图像信号。ISP将数字图像信号输出到DSP加工处理。DSP将数字图像信号转换成标准的红绿蓝(red green blue，RGB)，YUV等格式的图像信号。在一些实施例中，电子设备100可以包括1个或N个摄像头193，N为大于1的正整数。
数字信号处理器用于处理数字信号，除了可以处理数字图像信号，还可以处理其他数字信号。例如，当电子设备100在频点选择时，数字信号处理器用于对频点能量进行傅里叶变换等。
视频编解码器用于对数字视频压缩或解压缩。电子设备100可以支持一种或多种视频编解码器。这样，电子设备100可以播放或录制多种编码格式的视频，例如：动态图像专家组(moving picture experts group，MPEG)1、MPEG2、MPEG3和MPEG4。
NPU是一种借鉴生物神经网络结构的处理器，例如借鉴人脑神经元之间传递模式对输入信息快速处理，还可以不断地自学习。通过NPU可以实现电子设备100的智能认知等功能，例如：图像识别、人脸识别、语音识别和文本理解。
外部存储器接口120可以用于连接外部存储卡，例如安全数码(secure digital，SD)卡，实现扩展电子设备100的存储能力。外部存储卡通过外部存储器接口120与处理器110通信，实现数据存储功能。例如将音乐，视频等文件保存在外部存储卡中。
内部存储器121可以用于存储计算机可执行程序代码，所述可执行程序代码包括指令。内部存储器121可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统，至少一个功能(例如，声音播放功能和图像播放功能)所需的应用程序。存储数据区可存储电子设备100使用过程中所创建的数据(例如，音频数据和电话本)。此外，内部存储器121可以包括高速随机存取存储器，还可以包括非易失性存储器，例如：至少一个磁盘存储器件、闪存器件和通用闪存存储器(universal flash storage，UFS)等。处理器110通过运行存储在内部存储器121的指令和/或存储在设置于处理器中的存储器的指令，执行电子设备100的各种处理方法。
电子设备100可以通过音频模块170、扬声器170A、受话器170B、麦克风170C、耳机接口170D以及应用处理器等实现音频功能，例如，音乐播放和录音。
音频模块170用于将数字音频信息转换成模拟音频信号输出，也可以用于将模拟音频输入转换为数字音频信号。音频模块170还可以用于对音频信号编码和解码。在一些实施例中，音频模块170或者音频模块170的部分功能模块可以设置于处理器110中。
扬声器170A，也称为喇叭，用于将音频电信号转换为声音信号。电子设备100可以通过扬声器170A收听音乐或免提通话。
受话器170B，也称为听筒，用于将音频电信号转换成声音信号。当用户使用电子设备100接听电话或语音信息时，可以通过将受话器170B靠近耳朵接听语音。
麦克风170C，也称为话筒或传声器，用于将声音信号转换为电信号。当用户拨打电话或发送语音信息时，可以通过靠近麦克风170C发声将声音信号输入麦克风170C。电子设备100可以设置至少一个麦克风170C。在另一些实施例中，电子设备100可以设置两个麦克风170C，以实现降噪功能。在另一些实施例中，电子设备100还可以设置三个、四个或更多麦克风170C，以实现识别声音来源和定向录音等功能。处理器110可以对麦克风170C输出的电信号进行处理，例如，音频模块170与无线通信模块160可以通过PCM接口耦合，麦克风170C将环境声音转换为电信号(如PCM信号)后，通过PCM接口将该电信号传输至处理器110；从处理器110对该电信号进行音量分析和频率分析，确定环境声音的音量和频率。
耳机接口170D用于连接有线耳机。耳机接口170D可以是USB接口130，也可以是3.5mm的开放移动电子设备100平台(open mobile terminal platform，OMTP)标准接口，美国蜂窝电信工业协会(cellular telecommunications industry association of theUSA，CTIA)标准接口。
压力传感器180A用于感受压力信号，可以将压力信号转换成电信号。在一些实施例中，压力传感器180A可以设置于显示屏194。压力传感器180A的种类很多，例如可以是电阻式压力传感器、电感式压力传感器或电容式压力传感器。电容式压力传感器可以是包括至少两个具有导电材料的平行板，当力作用于压力传感器180A，电极之间的电容改变，电子设备100根据电容的变化确定压力的强度。当触摸操作作用于显示屏194时，电子设备100根据压力传感器180A检测所述触摸操作。电子设备100也可以根据压力传感器180A的检测信号计算触摸的位置。在一些实施例中，作用于相同触摸位置，但不同触摸操作强度的触摸操作，可以对应不同的操作指令。例如：当触摸操作强度小于第一压力阈值的触摸操作作用于短消息应用图标时，执行查看短消息的指令；当触摸操作强度大于或等于第一压力阈值的触摸操作作用于短消息应用图标时，执行新建短消息的指令。
陀螺仪传感器180B可以用于确定电子设备100的运动姿态。在一些实施例中，可以通过陀螺仪传感器180B确定电子设备100围绕三个轴(即，x轴、y轴和z轴)的角速度。陀螺仪传感器180B可以用于拍摄防抖。例如，当快门被按下时，陀螺仪传感器180B检测电子设备100抖动的角度，根据角度计算出镜头模组需要补偿的距离，让镜头通过反向运动抵消电子设备100的抖动，实现防抖。陀螺仪传感器180B还可以用于导航和体感游戏等场景。
气压传感器180C用于测量气压。在一些实施例中，电子设备100通过气压传感器180C测得的气压值计算海拔高度，辅助定位和导航。
磁传感器180D包括霍尔传感器。电子设备100可以利用磁传感器180D检测翻盖皮套的开合。在一些实施例中，当电子设备100是翻盖机时，电子设备100可以根据磁传感器180D检测翻盖的开合。电子设备100可以根据检测到的皮套的开合状态或翻盖的开合状态，设置翻盖自动解锁等特性。
加速度传感器180E可检测电子设备100在各个方向上(一般为x轴、y轴和z轴)加速度的大小。当电子设备100静止时可检测出重力的大小及方向。加速度传感器180E还可以用于识别电子设备100的姿态，作为横竖屏切换和计步器等应用程序的输入参数。
距离传感器180F用于测量距离。电子设备100可以通过红外或激光测量距离。在一些实施例中，例如在拍摄场景中，电子设备100可以利用距离传感器180F测距以实现快速对焦。
接近光传感器180G可以包括例如发光二极管(light-emitting diode，LED)和光检测器，例如，光电二极管。LED可以是红外LED。电子设备100通过LED向外发射红外光。电子设备100使用光电二极管检测来自附近物体的红外反射光。当检测到反射光时，电子设备100可以确定附近存在物体。当检测不到反射光时，电子设备100可以确定附近没有物体。电子设备100可以利用接近光传感器180G检测用户是否手持电子设备100贴近耳朵通话，以便自动熄灭屏幕达到省电的目的。接近光传感器180G也可用于皮套模式或口袋模式的自动解锁与自动锁屏。
环境光传感器180L用于感知环境光亮度。电子设备100可以根据感知的环境光亮度自适应调节显示屏194亮度。环境光传感器180L也可用于拍照时自动调节白平衡。环境光传感器180L还可以与接近光传感器180G配合，检测电子设备100是否在口袋里，以防误触。
指纹传感器180H用于采集指纹。电子设备100可以利用采集的指纹特性实现解锁、访问应用锁、拍照和接听来电等功能。
温度传感器180J用于检测温度。在一些实施例中，电子设备100利用温度传感器180J检测的温度，执行温度处理策略。例如，当温度传感器180J上报的温度超过阈值，电子设备100执行降低位于温度传感器180J附近的处理器的性能，以便降低功耗实施热保护。在另一些实施例中，当温度低于另一阈值时，电子设备100对电池142加热，以避免低温导致电子设备100异常关机。在其他一些实施例中，当温度低于又一阈值时，电子设备100对电池142的输出电压执行升压，以避免低温导致的异常关机。
触摸传感器180K，也称为触控器件。触摸传感器180K可以设置于显示屏194，由触摸传感器180K与显示屏194组成触摸屏，触摸屏也称为触控屏。触摸传感器180K用于检测作用于其上或其附近的触摸操作。触摸传感器180K可以将检测到的触摸操作传递给应用处理器，以确定触摸事件类型。可以通过显示屏194提供与触摸操作相关的视觉输出。在另一些实施例中，触摸传感器180K也可以设置于电子设备100的表面，并且与显示屏194设置于不同的位置。
骨传导传感器180M可以获取振动信号。在一些实施例中，骨传导传感器180M可以获取人体声部振动骨块的振动信号。骨传导传感器180M也可以接触人体脉搏，接收血压跳动信号。在一些实施例中，骨传导传感器180M也可以设置于耳机中，结合成骨传导耳机。音频模块170可以基于所述骨传导传感器180M获取的声部振动骨块的振动信号，解析出语音信号，实现语音功能。应用处理器可以基于所述骨传导传感器180M获取的血压跳动信号解析心率信息，实现心率检测功能。
按键190包括开机键和音量键。按键190可以是机械按键，也可以是触摸式按键。电子设备100可以接收按键输入信号，实现于案件输入信号相关的功能。
马达191可以产生振动。马达191可以用于来电提示，也可以用于触摸反馈。马达191可以对作用于不同应用程序的触摸操作产生不同的振动反馈效果。对于作用于显示屏194的不同区域的触摸操作，马达191也可产生不同的振动反馈效果。不同的应用场景(例如，时间提醒、接收信息、闹钟和游戏)可以对应不同的振动反馈效果。触摸振动反馈效果还可以支持自定义。
指示器192可以是指示灯，可以用于指示充电状态和电量变化，也可以用于指示消息、未接来电和通知。
SIM卡接口195用于连接SIM卡。SIM卡可以插入SIM卡接口195实现与电子设备100的接触，也可以从SIM卡接口195拔出实现与电子设备100的分离。电子设备100可以支持1个或N个SIM卡接口，N为大于1的正整数。同一个SIM卡接口195可以同时插入多张卡，所述多张卡的类型可以相同，也可以不同。SIM卡接口195也可以兼容外部存储卡。电子设备100通过SIM卡和网络交互，实现通话以及数据通信等功能。在一些实施例中，电子设备100采用嵌入式SIM(embedded-SIM，eSIM)卡，eSIM卡可以嵌在电子设备100中，不能和电子设备100分离。
上文详细描述了电子设备100的硬件系统，下面介绍电子设备100的软件系统。软件系统可以采用分层架构、事件驱动架构、微核架构、微服务架构或云架构，本申请实施例以分层架构为例，示例性地描述电子设备100的软件系统。
示例性的，图2是本申请实施例的电子设备100的软件结构框图。分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实现方式中，电子设备100的软件架构可分为两层：应用层210和操作系统层250，其中，操作系统层250可以为Android操作系统。
应用层210可以包括一系列应用程序包，应用程序包可以包括相机，图库，聊天，地图，日历，音乐，图库，通话，导航，蓝牙，视频等应用程序。在本申请另一些实施例中，相较于图2所示应用层包含的应用，电子设备100可包括更多或更少的应用，电子设备100也可包括完全不同的应用。
操作系统层250从上至下分别为框架(Framework)层220、核心库层230和内核层240。
框架层220为应用程序层的应用程序提供应用编程接口(ApplicationProgramming Interface，API)和编程框架，包括各种组件和服务来支持开发者的安卓开发。系统框架层包括一些预先定义的函数。如图2所示，系统框架层可包括活动管理服务(ActivityManagerService)、显示管理服务(DisplayManagerService)和输入管理服务(InputManagerService)等。活动管理服务为Android提供了管理Activity运行状态的系统服务，以及用于管理安卓中的其他组件运行状态，具体的，在本申请中，活动管理服务可用于对任务堆栈(以下简称堆栈)进行管理。显示管理服务用来管理显示的生命周期，它决定如何根据当前连接的物理显示设备和/或虚拟显示设备控制其逻辑显示，并且在状态更改时，向系统和应用程序发送通知等。输入管理服务用于管理整个系统的输入部分，包括键盘、鼠标、触摸屏等。
核心库层230是操作系统的核心部分，核心库包含两部分：一部分是java语言需要调用的功能函数，另一部分是安卓的核心库。核心库层230包括调度增强模块、输入/输出服务、核心服务、图形设备接口以及实现CPU或GPU图形处理的图形引擎(Graphics Engine)等。其中，调度增强模块用于基于从活动管理服务、显示管理服务以及输入管理服务获取到的信息，识别各应用的状态，以进一步确定对应于各应用的调度方式。具体执行方式将在下面的实施例中进行详细说明。
内核层240包括核调度执行模块、CPU驱动、GPU驱动以及显示控制器驱动等。各驱动用于将硬件抽象化，以隐藏硬件的特定通道，使应用可访问(或调用)硬件。在本申请中，内部调度执行模块基于调度增强模块的输入，对应用进行调度，具体执行方式将在下面的实施例中进行详细说明。
应理解的是，上述图2示出的软件结构框图仅仅是一个示例，还可选地为其他软件结构，例如相对于图2的软件结构具有不同的层数、功能模块相对于图2具有不同的命名和/或放置位置，本申请对此不做限定。
下面，结合附图介绍本申请提供的资源分配方法的用户使用场景。应理解的是，下文中描述的用户使用场景仅为示意，并不对本申请提供的资源分配方法的用户使用场景构成任何限定。
场景一：
场景一描述的是投屏场景。投屏场景可以理解为，电子设备100可以通过投屏的方式，将电子设备100上运行的应用在其他电子设备上进行播放和/或显示，被投屏的应用可以但不限于为聊天应用、地图应用、音乐应用或者视频应用。
示例性的，图3是本申请实施例提供的一种用户使用场景的示意图。参见图3，手机(即电子设备100)运行聊天应用，可选地能够在聊天应用界面接收用户输入文字，同时，手机将短视频应用镜像投屏至大屏(即电子设备101)，其中，短视频应用运行在手机后台，在手机侧对用户不可见。在一些实现方式中，手机可以通过AndroidDisplay机制和Miracast投屏协议实现上面的场景。手机定义Display1和Display2，其中Display1用于生成在手机上显示的图像，Display2用于生成在大屏上显示的图像。其中，Display1对应的应用渲染后在手机上显示，Display2对应的应用渲染后经H.264编码后，通过Wi-Fi Direct技术将视频流发送至大屏，大屏经过H.264解码后将视频流显示在大屏的显示屏上。可以理解的是，手机的后台还在运行着天气应用、音乐应用、桌面应用等应用。需要说明的是，在本申请中，投屏到大屏的应用是运行在手机上并显示在大屏上的，下文不再重复说明。
继续参见图3，目前的Android系统采用单一焦点机制，即只能存在一个前台焦点应用。前台焦点应用是用户当前正在执行的操作所作用的应用，前台焦点应用在手机侧针对用户是可见的。其中，“可见”的应用是指用户可以在手机的屏幕上看到的应用。其中，前台焦点应用的进程被划分至前台焦点分组中。在一些实现方式中，Display2通过Miracast协议中的用户输入反向通道(User Input Back Channel，UIBC)功能实现焦点感知和焦点抢占。在该应用场景下，当手机接收的用户操作为作用于聊天应用的操作时，前台焦点应用(即聊天应用)将会被划分到高优先级的前台焦点分组(例如，top-app分组)，短视频应用将会被划分到低优先级的非前台焦点分组(例如，foreground分组)。可选的，在一些实现方式中，非前台焦点分组还可以为：background分组，background分组中可以包括浏览器应用、音乐应用、桌面应用等。非前台焦点应用在手机侧针对用户是不可见的应用，其中，“不可见”的应用是指用户无法在手机的屏幕上看到的应用。可以理解的是，被划分到高优先级分组(即top-app分组)的聊天应用可优先分配资源，这种资源分配方式中，存在被划分到低优先级分组的短视频应用争抢高优先分组所分配到的资源的现象，该种情况下，可能会使得聊天应用的数据失帧，即帧率降低，导致聊天应用卡顿。反之，若用户对大屏上的短视频应用进行操作，则短视屏应用获得焦点，即为前台焦点应用，并被划分到高优先级分组(即top-app分组)，聊天应用则被划分到低优先级分组，则聊天应用将会与短视频应用应用争抢资源，使得短视频应用的数据失帧，即帧率降低，造成短视频应用卡顿。还可以理解的是，一个应用包括一个或多个进程，在本申请实施例中，当一个应用(例如，聊天应用)被划分到top-app分组时，即该一个应用包括的所有进程被划分到top-app分组。
场景二：
场景二描述的是分屏场景。分屏场景可以理解为，电子设备100的屏幕上至少包括两个应用对应的两个显示窗口。
示例性的，参见图4A，电子设备100可基于用户的操作，执行分屏操作，即，在屏幕上存在至少两个显示窗口，每个显示窗口可显示至少一个应用。
可选的，在分屏场景下，每个显示窗口可记为一个Display，其具体实现方式与异源投屏场景相同或相似，可参照上文场景一中的相关描述，此处不再详细赘述。
场景三：
场景三描述的是画中画场景。画中画场景可以理解为，电子设备100在运行一个应用的同时，电子设备100提供的显示窗口上还可以包括一个子显示窗口，用于显示另外一个应用。
示例性的，参见图4B，电子设备100在运行一个网页应用的同时，电子设备100的显示窗口上还可以包括一个子显示窗口，用于显示另外一个视频应用。
在画中画场景下，活动管理服务可向调度增强模块输入感知信息，用于指示应用是否可以感知。其中，可感知即为该应用的画面当前对用户可见，则对于该类应用，调度增强模块将该类应用划分至top-app分组，也就是说，该类应用虽然为非栈顶应用，且未对应操作事件，但是，仍可属于top-app分组，从而使画中画应用能够优先获取资源，以缩短应用响应时间，提升应用流畅度，防止卡顿现象发生。
需要说明的是，上文中以投屏场景、分屏场景以及画中画场景等多前台并发场景为例进行说明，在其他实施例中，用户可感知到系统卡顿的交互场景(例如，存在多前台并发的场景)或某些场景下对任务有较强的性能要求的场景均可适用本申请中的技术方案，本申请对此不做限定。示例性的，上述场景还可以但不限于是以下场景：滑动列表场景，或者多屏协同场景。
下面，结合图5描述电子设备100为分组中的进程分配CPU资源的实现方式。
示例性的，参见图5，电子设备100的CPU资源包括：CPU 1、CPU 2,…,CPU i，i为大于1的整数。也就是说，电子设备100是一个具有多个CPU的电子设备。电子设备100包括的每个CPU可以为以下任意一种类型的核：小核、中核、或大核。其中，大核、中核和小核的性能是逐渐降低的。
实际应用中，控制群cgroup用于对前台焦点分组和/或非前台焦点分组中的进程分配CPU资源。对控制群所管理的进程所属的分组不作具体限定，可以根据实际场景进行设置。
在一些实现方式中，电子设备100中运行有进程A、进程B和进程C，cgroup 1根据资源分配策略为进程A、进程B和进程C分配电子设备100包括的CPU资源。其中，资源分配策略是电子设备100根据电子设备100在一段时间内的运行情况确定的。对cgroup 1所管理的进程所属分组的优先级不作具体限定。换句话说，一个cgroup可以为高优先级分组(即前台焦点分组)或低优先级分组(即非前台焦点分组)中的应用的进程分配CPU资源。示例性，参见图6中的(1)示出了图5中的cgroup 1所管理的进程对应分组情况。参见图6中的(1)，进程A、进程B和进程C可以为高优先级分组(例如，top-app分组)中的进程。对进程A、进程B和进程C对应的应用不作具体限定，可以根据实际使用需求进行设置。例如，进程A可以为聊天应用，进程B可以为音乐应用、进程C可以为网页浏览应用。
在另一些实现方式中，电子设备100的系统中设置有cgroup 1和cgroup 2，其中，cgroup1根据资源分配策略为进程A、进程B和进程C分配电子设备100包括的CPU资源，cgroup2根据资源分配策略为进程D分配电子设备100包括的CPU资源。对cgroup 1和cgroup2所管理的进程所属分组的优先级不作具体限定。示例性，参见图6中的(2)示出了图5中的cgroup1和cgroup 2所管理的进程对应分组情况。参见图6中的(1)，进程A、进程B和进程C可以为高优先级分组(例如，top-app分组)中的进程，进程D可以为低优先级分组(例如，foreground前台分组，background后台分组)中的进程。
需说明的是，图5和图6仅为示意，对本申请实施例并不构成任何限定。例如，图5示出的电子设备100的系统中还可以设置更多数目的cgroup，更多数目的cgroup用于为电子设备中运行的至少一个进程分配CPU资源。例如，图6中的(2)中示出的高优先级分组还可以仅包括进程A，图6中的(2)中的低优先级分组还可以包括：进程A、进程B和进程C。
接下来，结合图7至图11对本申请实施例提供的资源分配方法进行详细介绍。
图7是本申请实施例提供的一种资源分配方法的示意图。本申请实施例提供的资源分配方法可以由电子设备来执行。可以理解的是，该电子设备可以实现为软件、或者软件和硬件的组合。示例性的，本申请实施例中的电子设备可以但不限于是图3示出的电子设备100。如图7所示，本申请实施例提供的资源分配方法包括S710至S730。
在介绍S710至S730之前，先对执行本申请实施例提供的资源分配方法的电子设备进行介绍。
本申请实施例提供的资源分配方法可以应用于包括M个中央处理器CPU的设备中，M个CPU被优先分配给前台焦点分组，M为大于1的整数。
M个CPU被优先分配给前台焦点分组，即前台焦点分组可以根据自身实际需要的CPU数量获取电子设备包括的CPU资源，以及，电子设备包括的M个CPU中未被前台焦点分组占用的CPU资源可以考虑分配给非前台焦点分组。例如，在电子设备包括8个CPU的情况下，若前台焦点分组自身实际需要的CPU资源为8个CPU，则前台焦点分组可用获得电子设备包括的这8个CPU资源。又如，在电子设备包括8个CPU的情况下，若前台焦点分组自身实际需要的CPU资源为6个CPU，则前台焦点分组可用获得电子设备包括的8个CPU中的6个CPU的资源。对M的取值不作具体限定，即M的取值可以根据实际应用场景进行设置。例如，M可以但不限于为8个或4个等。对M个CPU的类型不作具体限定，即M个CPU中的每个CPU的类型可以根据实际需求进行设置。其中，M个CPU中的任意一个CPU可以为以下类型的CPU：小核、中核或者大核。需要说明的是，大核、中核与小核是按照核的处理能力划分的，处理能力从大到小依次为：大核＞中核＞小核。需说明的是，对前台焦点分组的相关描述请参见下文S710中的相关描述，此处不再详细赘述。
下面，对S710至S730进行详细介绍。
S710，获取第一负载信息，第一负载信息表示在预设时段内每个CPU执行前台焦点分组中的待运行进程的平均数量。
第一负载信息表示在预设时段内每个CPU执行前台焦点分组中的待运行进程的平均数量，也就是说，第一负载信息是用于描述在预设时段内前台焦点分组的负载情况的信息。对预设时段的时间长度不作具体限定，可以根据实际需求进行设置。例如，预设时段可以但不限于为60秒或120秒。
对获取第一负载信息的获取方法不作具体限定。接下来，介绍本申请实施例提供的获取第一负载信息的获取方法。应理解的是，下文所描述的获取第一负载信息的获取方法仅为示意，并不对获取第一负载信息的方法构成任何限定。
在一些实现方式中，获取第一负载信息，包括：获取M个CPU中每个CPU的进程数量，每个CPU的进程数量表示在预设时段内每个CPU的运行队列上属于前台焦点分组的进程的数量；对M个CPU的进程数量执行求和处理，获得求和处理结果；对求和处理结果除以M个预设时段，获得在预设时段内每个CPU执行前台焦点分组中的待运行进程的平均数量，M个预设时段和M个CPU一一对应。可以理解的是，上述实现方式中描述的获取第一负载信息的方法是一种基于时间加权平均算法的方法。例如，电子设备包括CPU A和CPU B，其中，在2秒内CPU A中属于前台焦点分组中的待运行进程数量为4个，在2秒内CPU A中属于前台焦点分组中的待运行进程数量为6个，则在2秒内电子设备包括的每个CPU执行前台焦点分组中的待运行进程数量为：个。
在另一些实现方式中，获取第一负载信息，包括：获取M个CPU中每个CPU的进程数量，每个CPU的进程数量表示在预设时段内每个CPU的运行队列上属于前台焦点分组的进程的数量；对M个CPU的进程数量执行求平均处理，获得在预设时段内每个CPU执行前台焦点分组中的待运行进程的平均数量。可以理解的是，上述实现方式描述的获取第一负载信息的方法是一种基于平均算法的方法。例如，电子设备包括CPU A和CPU B，其中，在2秒内CPU A中属于前台焦点分组中的待运行进程数量为4个，在2秒内CPU A中属于前台焦点分组中的待运行进程数量为6个，则在2秒内电子设备包括的每个CPU执行前台焦点分组中的待运行进程数量为：个。
接下来，对本申请实施例中涉及的前台焦点分组的相关概念进行介绍。
前台焦点分组中的进程对应的应用，是当前用户执行的操作所作用的应用。前台焦点分组针对用户是可见的。在电子设备执行本申请实施例提供的资源分配方法的情况下，“可见”的应用可以理解为，用户在电子设备的屏幕中可以看到该应用。例如，当前用户在电子设备中安装的聊天应用中输入一段话，则该聊天应用的进程会被划分为前台焦点分组中的进程。
与前台焦点分组相对应的，本申请实施例中还涉及非前台焦点分组的概念。非前台焦点分组中的进程对应的应用针对用户是不可见的。在电子设备执行本申请实施例提供的资源分配方法的情况下，“不可见”的应用可以理解为，用户无法在电子设备的屏幕中看到该应用。
前台焦点分组的优先级高于非前台焦点分组的优先级。可以理解的是，前台焦点分组的优先级高于非前台焦点分组的优先级，即电子设备包括的CPU资源会优先分配给前台焦点分组。
需说明的是，一个应用包括一个或多个进程。本申请实施例中，以一个应用包括一个进程为例进行描述。也就是说，前台焦点分组或非前台焦点分组中包括的一个进程为一个应用。还可以理解的是，若一个应用包括多个进程，该一个应用的多个进程要么属于前台焦点分组要么属于非前台焦点分组。例如，一个聊天应用包括3个进程，则这3个进程均可以为前台焦点分组中的进程。又如，桌面应用包括5个进程，则这5个进程均可以为background分组中的进程。
上文，介绍了前台焦点分组的概念和非前台焦点分组的概念，以及这两个分组之间的区别。下面，举例描述前台焦点分组的示例和非前台焦点分组的示例。
在一些实现方式中，电子设备的系统中设置有：root分组、top-app分组、foreground分组和background分组。其中，root分组中的资源是预先配置后不会更改的，除去root分组之外的分组的资源是可以进行调整的。这种实现方式中，top-app分组可称为前台焦点分组，非前台焦点分组为前台分组或后台分组。
在另一些实现方式中，电子设备的系统中设置有：root分组、top-app分组、foreground分组、background分组和system-backgroud分组。其中，system-backgroud分组包括系统运行的应用，例如，电池电量统计等应用。这种实现方式中，top-app分组可称为前台焦点分组，非前台焦点分组为foreground分组、background分组或者system-backgroud分组。
下面，举例描述前台焦点分组中的进程对应的应用和非前台焦点分组中的进程对应的应用的示例。
例如，以电子设备中设置的前台焦点分组为top-app分组，且非前台焦点分组为foreground分组为例进行描述。在一些场景中，当用户当前针对电子设备中安装的聊天应用执行操作时，聊天应用的进程为top-app分组中的进程，与此同时，电子设备的桌面应用的进程为foreground分组中的进程。此后，当用户从聊天应用切换至桌面应用时，桌面应用的进程便更新为top-app分组中的进程，聊天应用的进程变更新为foreground分组中的进程。
又如，以电子设备中设置的前台焦点分组为top-app分组，且非前台焦点分组包括foreground分组和background分组为例进行描述。在一些场景中，首先用户针对电子设备中的购物应用执行操作，然后用户从针对购物应用执行操作的状态切换为针对电子设备中的聊天应用执行操作(例如，在聊天应用提供的GUI界面中输入文字)的状态，这时候购物应用还在电子设备的后台运行。这种场景中，当前用户针对聊天应用执行操作时，聊天应用的进程为top-app分组中的进程，购物应用的进程为background分组中的进程，桌面应用的进程为foreground分组中的进程。
S720，根据第一负载信息，确定资源分配策略。
在本申请实施例中，提供了三种实现方式中，以实现根据第一负载信息确定资源分配策略的目的。为便于描述，下文中将这三种实现方式分别记为：实现方式一、实现方式二和实现方式三。接下来，分别对实现方式一、实现方式二和实现方式三进行介绍。
首先，对实现方式一进行详细介绍。
实现方式一：
在实现方式一中，执行上述S720，即根据第一负载信息，确定资源分配策略，包括：在平均数量不超过第一预设进程数量的情况下，确定资源分配策略为将M个CPU中的N个CPU分配给非前台焦点分组，N是预设的最多能够分配给非前台焦点分组的CPU的数量，N为小于或等于M的整数。
应理解，平均数量表示在预设时段内每个CPU执行前台焦点分组中的待运行进程的平均数量。
第一预设进程数量是根据应用场景设置的，对第一预设进程数量的取值不作具体限定。平均数量不超过第一预设进程数量可以理解为，平均数量小于或等于第一预设进程数量。可以理解的是，在平均数量不超过第一预设进程数量的情况下，前台焦点分组处于低负载状态，即前台焦点分组中的待运行进程的数量较少。
N是根据实际应用场景设置的，且N是小于M的整数。可以理解的是，预设的最多能够分配给非前台焦点分组的CPU的数量(即N)，小于优先分配给前台焦点分组的CPU的数量(即M)。
在实现方式一中，在前台焦点分组处于低负载状态的情况下，基本不会存在前台卡顿的现象。这种场景下，为了提升系统的吞吐率，可以放松对非前台焦点分组的CPU资源的限制，即可以将M个CPU中的较多数量(即N个)CPU分配给非前台焦点分组。
接下来，对实现方式二进行详细介绍。
实现方式二：
在实现方式二中，执行上述S720，即根据第一负载信息，确定资源分配策略，包括：在平均数量大于第一预设进程数量且小于或等于第二预设进程数量的情况下，根据第二负载信息，确定资源分配策略，第二负载信息用于指示在预设时段内M个CPU中的至少一个CPU执行非前台焦点分组中的待运行进程的平均数量。
第一预设进程数量小于第二预设进程数量。第一预设进程数量和第二预设进程数量是根据应用场景设置的，对第一预设进程数量和第二预设进程数量的取值不作具体限定。
第二负载信息用于指示在预设时段内M个CPU中的至少一个CPU执行非前台焦点分组中的待运行进程的平均数量，也就是说，第二负载信息是用于描述在预设时段内非前台焦点分组的负载情况的信息。具体来说，若设备包括的M个CPU中的一个CPU执行非前台焦点分组中的进程，则第二负载信息具体用于指示在预设时段内该一个CPU执行非前台焦点分组中的待运行进程的平均数量；若设备包括的M个CPU中的多个CPU执行非前台焦点分组中的进程，则第二负载信息具体用于指示在预设时段内该多个CPU执行非前台焦点分组中的待运行进程的平均数量，其中，该多个CPU可以为M个CPU中的部分CPU，或者该多个CPU还可以为M个CPU。
在一些实现方式中，根据第二负载信息，确定资源分配策略，包括：根据第二负载信息，确定非前台焦点分组需要的CPU数量；根据非前台焦点分组需要的CPU数量、第一预设CPU数量和第二预设CPU数量，确定资源分配策略，第一预设CPU数量是预设的最少能够分配给非前台焦点分组的CPU的数量，第二预设CPU数量是预设的最多能够分配给非前台焦点分组的CPU的数量。
上述实现方式中，非前台焦点分组需要的CPU数量是指在预设时段内非前台焦点分组实际所需要的CPU数量。其中，非前台焦点分组需要的CPU数量是根据第二负载信息确定的。
下面，介绍根据第二负载信息确定非前台焦点分组需要的CPU数量的方法。应理解的是，下文中描述的“根据第二负载信息确定非前台焦点分组需要的CPU数量”的方法仅为示意，并不构成任何限定。也就是说，还可以采用其他方法根据第二负载信息确定非前台焦点分组需要的CPU数量。
在一些实现方式中，根据第二负载信息，确定非前台焦点分组需要的CPU数量，包括：计算预设系数和第二负载信息所指示的非前台焦点分组中的待运行进程的平均数量的乘积结果；将乘积结果确定为非前台焦点分组需要的CPU数量。
预设系数可以根据应用场景和用户需求进行设置。在一些实现方式中，预设系数可以根据非ta分组的总进程数量、一个CPU用于执行非ta分组中的进程数量确定。例如，在非ta分组为bg分组，bg分组包括10个进程，且设置一个CPU用于执行bg分组包括的2个进程的情况下，可以设置预设系数为0.1。又如，在非ta分组为bg分组，bg分组包括2个进程，且设置一个CPU用于执行bg分组包括的2个进程的情况下，可以设置预设系数为0.5。
在另一些实现方式中，非前台焦点分组需要的CPU数量还可以是根据第二负载信息第二负载信息所指示的非前台焦点分组中的待运行进程的平均数量和映射关系确定的，其中，映射关系表示第二负载信息所指示的非前台焦点分组中的待运行进程的平均数量与非前台焦点分组需要的CPU数量之间的映射关系。
下面，介绍实现方式二中描述的“根据非前台焦点分组需要的CPU数量、第一预设CPU数量和第二预设CPU数量，确定资源分配策略”的方法。
示例性的，在一些实现方式中，第一预设CPU数量为K，第二预设CPU数量为N，N为小于或等于M的整数，K为小于或等于N的整数，根据非前台焦点分组需要的CPU数量、第一预设CPU数量和第二预设CPU数量，确定资源分配策略，包括：在非前台焦点分组需要的CPU数量小于或等于K的情况下，确定资源分配策略为将M个CPU中的K个CPU分配给非前台焦点分组；在非前台焦点分组需要的CPU数量大于或等于N的情况下，确定资源分配策略为将M个CPU中的N个CPU分配给非前台焦点分组；在非前台焦点分组需要的CPU数量大于K且小于N的情况下，确定资源分配策略为将M个CPU中的需要的CPU数量个CPU分配给非前台焦点分组。
上述实现方式中，在非前台焦点分组需要的CPU数量在预设CPU数量范围内的情况下，将非前台焦点分组需要的CPU数量分配给非前台焦点分组，这样，可用保证将非前台焦点分组需要的CPU资源分配给非前台焦点分组；在非前台焦点分组需要的CPU数量不在预设CPU数量范围内的情况下，将预设CPU数量分配给非前台焦点分组，这样，可以避免非前台焦点分组抢占前台焦点分组的CPU资源，从而可以避免前台发生卡顿的现象。
在实现方式二中，在前台焦点分组处于中负载状态的情况下，通过根据非前台焦点分组需求的CPU数量、第一预设数量和第二预设数量，根据非前台焦点分组自身的需求为非前台焦点分组分配CPU资源。其中，在非前台焦点分组自身的需求的CPU数量小于第一预设数量且大于第二预设数量的情况下，为避免前台发生卡顿，这种情况下分配给非前台焦点分组的CPU数量为预设CPU数量(即第一预设CPU数量或第二预设CPU数量)。
下面，对实现方式三进行详细介绍。
实现方式三：
在实现方式三中，执行上述S720，即根据第一负载信息，确定资源分配策略，包括：
在平均数量超过第二预设进程数量的情况下，根据资源利用率信息，确定资源分配策略，资源利用率信息用于指示在预设时段内M个CPU中的每个CPU实际处理数据的时间占实际运行时间的比例。
可以理解的是，实现方式三中描述的第二预设进程数量，与上述实现方式二中描述的第二预设进程数量是同一个预设进程数量。也就是说，实现方式三中的第二预设进程数量大于上述实现方式二中描述的第一预设进程数量。
在一些实现方式中，根据资源利用率信息，确定资源分配策略，包括：根据资源利用率信息，确定M个CPU的利用率；在M个CPU的利用率超过预设比例的情况下，确定资源分配策略为将M个CPU中的K个CPU分配给非前台焦点分组，K是预设的最少能够分配给非前台焦点分组的CPU的数量，K为小于或等于N的整数；或者，在M个CPU的利用率不超过预设比例的情况下，根据第二负载信息，确定资源分配策略，第二负载信息用于指示在预设时段内M个CPU中的至少一个CPU执行非前台焦点分组中的待运行进程的平均数量。
其中，M个CPU的利用率用于表示M个CPU在预设时段的负载情况。
M个CPU的利用率超过预设比例表示M个CPU在预设时段内处于高负载状态，因此，确定的资源分配策略为将M个CPU中的K个CPU分配给非前台焦点分组。M个CPU的利用率不超过预设比例表示M个CPU在预设时段内处于低负载状态，因此，根据第二负载信息，进一步确定资源分配策略。
本申请对预设比例的取值不作具体限定，预设比例的取值可以用根据实际应用场景进行设置。例如，预设比例可以但不限于为0.7、0.75或0.8等。
下面，介绍根据资源利用率信息确定M个CPU的利用率的方法。应理解，下文中示出的方法仅为示意，并不对本申请实施例构成任何限定。
在一些实现方式中，资源利用率信息用于指示M个CPU中的每个CPU实际处理数据的时间占实际运行时间的比例，根据资源利用率信息，确定M个CPU的利用率，包括：对M个CPU中的M个CPU实际处理数据的时间占实际运行时间的比例执行求和处理，获得M个CPU的利用率。
在另一些实现方式中，资源利用率信息用于指示M个CPU中的每个CPU实际处理数据的时间占实际运行时间的比例，根据资源利用率信息，确定M个CPU的利用率，包括：对M个CPU中的部分CPU实际处理数据的时间占实际运行时间的比例执行求和处理，获得M个CPU的利用率。
下面，介绍根据第二负载信息确定资源分配策略的方法。
在一些实现方式中，实现方式三中描述的根据第二负载信息，确定资源分配策略，包括：根据第二负载信息，确定非前台焦点分组需要的CPU数量；根据非前台焦点分组需要的CPU数量、第一预设CPU数量和第二预设CPU数量，确定资源分配策略，第一预设CPU数量是预设的最少能够分配给非前台焦点分组的CPU的数量，第二预设CPU数量是预设的最多能够分配给非前台焦点分组的CPU的数量。
需说明的是，实现方式三中描述的“根据第二负载信息，确定资源分配策略”的具体实现方式，以及上述实现方式二中描述的“根据第二负载信息，确定资源分配策略”的具体实现方式相同，此处未详细赘述的内容可以参见上述实现方式二中描述的内容。区别在于，实现方式三中执行“根据第二负载信息，确定资源分配策略”的执行条件，与上述实现方式二中执行“根据第二负载信息，确定资源分配策略”的执行条件不同。
下面，介绍实现方式三中描述的“根据非前台焦点分组需要的CPU数量、第一预设CPU数量和第二预设CPU数量，确定资源分配策略”。示例性的，在一些实现方式中，第一预设CPU数量为K，第二预设CPU数量为N，N为小于或等于M的整数，K为小于或等于N的整数，在非前台焦点分组需要的CPU数量小于或等于K的情况下，确定资源分配策略为将M个CPU中的K个CPU分配给非前台焦点分组；在非前台焦点分组需要的CPU数量大于或等于N的情况下，确定资源分配策略为将M个CPU中的N个CPU分配给非前台焦点分组；在非前台焦点分组需要的CPU数量大于K且小于N的情况下，确定资源分配策略为将M个CPU中的需要的CPU数量个CPU分配给非前台焦点分组。
上述实现方式中，在非前台焦点分组需要的CPU数量在预设CPU数量范围内的情况下，将非前台焦点分组需要的CPU数量分配给非前台焦点分组，这样，可用保证将非前台焦点分组需要的CPU资源分配给非前台焦点分组；在非前台焦点分组需要的CPU数量不在预设CPU数量范围内的情况下，将预设CPU数量分配给非前台焦点分组，这样，可以避免非前台焦点分组抢占前台焦点分组的CPU资源，从而可以避免前台发生卡顿的现象。
实现方式三中描述的方案还涉及资源利用率信息，基于此，本申请实施例还涉及获取资源利用率信息的步骤。其中，对获取资源利用率信息的获取方法不作具体限定。在一些实现方式中，预设时段内包括P个时间窗口，P为正整数；以及，在根据资源利用率信息，确定资源分配策略之前，方法还包括：获取每个CPU在每个时间窗口的利用率，每个CPU在每个时间窗口的利用率表示在每个时间窗口内每个CPU实际处理数据的时间占实际运行时间的比例；对每个CPU在P个时间窗口的利用率执行求和处理，获得每个CPU在P个时间窗口的总利用率；利用总利用率除以预设时段，获得在预设时段内每个CPU处理数据的时间占实际运行时间的比例，以得到资源利用率信息。
上述确定资源利用率信息的过程，可以理解为是基于窗口平均算法的求解过程。基于于窗口平均算法确定资源利用率信息，获得的资源利用率信息结果更加准确。这样，有利于提高为非前台焦点分组分配CPU资源的准确性。
在实现方式三中，在前台焦点分组处于高负载状态的情况下，通过确定M个CPU是否处于高负载状态，确定接下来的确定资源分配策略的流程。具体来说，若M个CPU处于高负载状态，则将预设的最少能够分配给非前台焦点分组的CPU的数量。也就是说，在在前台焦点分组处于高负载状态，且设备包括的M个CPU也处于高负载状态的情况下，为了避免前台发生卡顿现象需要严格限制分配给非前台焦点分组的CPU数量。若M个CPU处于低负载状态，则根据第二负载信息，确定资源分配策略。也就是说，在前台焦点分组处于高负载状态，且设备包括的M个CPU也处于低负载状态的情况下，M个CPU还有较多的资源未被前台焦点分组占用，这种情况下，可以根据非前台焦点分组自身的需求为非前台焦点分组分配CPU资源。其中，在非前台焦点分组自身的需求的CPU数量小于第一预设数量且大于第二预设数量的情况下，为避免前台发生卡顿，这种情况下分配给非前台焦点分组的CPU数量为预设CPU数量(即第一预设CPU数量或第二预设CPU数量)。
S730，根据资源分配策略，为非前台焦点分组分配CPU资源，非前台焦点分组的优先级低于前台焦点分组的优先级。
在实际应用中，设备中的控制群可以用于为前台焦点分组和非前台焦点分组中的进程分配CPU资源。在本申请实施例中，对管理前台焦点分组的控制群和管理非前台焦点的控制群不作具体限定。例如，管理前台焦点分组的控制群和管理非前台焦点的控制群可以是设备中设置的两个不同的控制群。又如，管理前台焦点分组的控制群和管理非前台焦点的控制群可以是设备中设置的同一个控制群。
基于上述为非前台焦点分组分配CPU资源的实现过程，执行上述S730，即根据资源分配策略，为非前台焦点分组分配CPU资源，包括：通过目标控制群，根据资源分配策略，为非前台焦点分组分配CPU资源。其中，目标控制群是用于为非前台焦点中的进程分配CPU资源的控制群。
对非前台焦点分组中的进程数目不作具体限定，也就是说，非前台焦点分组中可以包括一个或多个进程，不同进程对应不同优先级。基于此，在一些实现方式中，根据资源分配策略，为非前台焦点分组分配CPU资源，包括：根据资源分配策略，在非前台焦点分组包括多个进程的情况下，根据多个进程中的每个进程的优先级为非前台焦点分组中的进程分配CPU资源，优先级高的进程所分配到的CPU资源大于优先级低的进程所分配到的CPU资源。
上述实现方式中，根据非前台焦点分组中的进程的优先级为非前台焦点分组中的进程分组CPU资源，这样，可以保证非前台焦点分组中的具有较高优先级的进程分配更多的CPU资源。
应理解的是，上述图7示出的资源分配方法仅为示意，并不对本申请提供的资源分配方法构成任何限定。
在本申请实施例中，将设备包括的所有CPU(即M个CPU，M为大于1的整数)优先分配给前台焦点分组，使得前台焦点分组能够根据自身需求从M个CPU中选取前台焦点分组所需要的CPU资源，这样，可以避免前台焦点分组由于CPU资源不充足导致前台发生卡顿现象。进一步，根据用于描述前台焦点分组的负载状态的第一负载信息确定为非前台焦点分组分配CPU资源的资源分配策略。此后，根据资源分配策略，为非前台焦点分组分配CPU资源，这样，可以将设备中前台焦点分组未占用的CPU资源分配给非前台焦点分组，可以提高系统的吞吐率，从而实现系统性能的整体提升。
下面，结合图8介绍本申请实施例提供的另一种资源分配方法。可以理解的是，图8所述描述的资源分配方法为上述图7所描述的资源分配方法的一个具体示例，图8所描述的方法仅为示意，并不对本申请提供的资源分配方法构成任何限定。
图8是本申请实施例提供的另一种资源分配方法的示意图。本申请实施例提供的资源分配法可以由图3示出的电子设备100来执行，其中，电子设备100可以但不限于是手机。可以理解的是，电子设备100可以实现为软件、或者软件和硬件的组合。示例性的，如图8所示，该方法包括步骤S801至步骤S811。下面，对步骤S801至步骤S811进行详细介绍。
S801，确定ta分组(即前台焦点分组的一例)的平均进程数量(即第一负载信息的一例)，其中，ta分组的平均进程数量表示：在预设时间段(即预设时段的一例)内，手机A包括的多个CPU中的每个CPU执行ta分组中的待运行进程的平均进程数量。
手机A是包括多个CPU的设备，对手机A包括的CPU的数目不作具体限定，可以根据实际使用场景设置手机A包括的CPU的数量。例如，手机A可以但不限于包括：8个、6个、4个或2个CPU。
将手机A包括的多个CPU均分配给ta分组，即ta分组中的进程可以运行在手机A包括的多个CPU中。也就是说，ta分组是具有高优先级的分组，即手机A包括的CPU会优先执行ta分组包括的进程。需说明的是，将手机A包括的所有CPU资源(即多个CPU)分配给了ta分组，在ta分组无需占用手机A包括的所有CPU资源的情况下，ta分组可以根据自身的需求占用手机A包括的多个CPU资源中的部分CPU资源。
对ta分组中包括的手机A中待运行的进程的数目不作具体限定。例如，ta分组中可以包括一个或多个待运行的进程。可选的，在ta分组包括多个待运行的进程的情况下，ta分组包括的多个待运行的进程可以和多个优先级一一对应。实际应用中，一个CPU在同一时刻仅可以运行一个进程，若将ta分组中的多个进程分配给手机A包括的同一个CPU的情况下，可以根据该多个进程对应的多个优先级确定执行该多个进程的执行顺序。具体来说，最先优先执行具有最高优先级的进程；其次，执行具有次高优先级的进程；以此类推，最后执行具有最低优先级的进程。
对确定ta分组的平均进程数量的实现方式不作具体限定。下面，介绍基于时间加权平均的方法确定ta分组的平均进程数量的流程。其中，时间加权平均就是以各项的值乘以各自的时间权重后求和，除以各项时间权重的和，权重表示重要程度。
基于时间加权平均的方法，执行上述S801，即确定ta分组的平均进程数量，包括：获取多个CPU中的每个CPU的进程数量，其中，每个CPU的进程数量表示：在预设时间段内，每个CPU的运行队列上属于ta分组的进程的数量；对所述每个CPU的进程数量执行求和处理，并对所述求和处理获得的结果除以多个预设时间段，其中，所述多个预设时间段和所述多个CPU一一对应。
预设时间段为基于时间加权平均算法的权重。对预设时间段的长度不作具体限定，可以根据实际需要进行设置。例如，预设时间段可以但不限于为60秒。
对每个CPU的运行队列上的属于ta分组的进程的状态不作具体限定。在一些实现方式中，每个CPU的运行队列上的属于ta分组的进程包括：每个CPU的运行队列上处于排队状态的ta分组的进程；或者，在另一些实现方式中，每个CPU的运行队列上的属于ta分组的进程包括：每个CPU的运行队列上处于排队状态的ta分组的进程、以及该每个CPU的运行队列上处于运行状态的ta分组的进程。
示例性的，ta分组的平均进程数量nravggroup可以通过以下数学公式表示：
在上述公式中，rqcpu表示CPU的运行队列，一个CPU对应一个运行队列。rqcpu→cgroup_nr_runningi表示i时刻一个CPU的运行队列中包括的属于ta分组的进程的数量。Periodi表示i-1时刻和i时刻之间的时间间隔，Periodi为权重。其中，i-1时刻和i时刻之间的时间间隔为预设时间段。cgroup表示ta分组所在的控制群。∑irqcpu→cgroup_nr_runningi×Periodi表示在i-1时刻至i时刻这段时间内，一个CPU的运行队列上属于ta分组的进程的数量。
表示在i-1时刻至i时刻这段时间内，手机A包括的多个CPU的多个运行队列上属于ta分组的进程的数量。
在本申请实施例中，ta分组的平均进程数量会随着属于ta分组的进程出CPU的运行队列或有更多的属于ta分组的进程进CPU的运行队列进行更新。示例性的，参见图10示出的更新流程。在图10中，在进程进CPU的运行队列；或者，进程出CPU的运行队列的情况下，确定进程是属于ta分组的进程。此后，对ta分组的平均进程数量进行更新，即将上述(公式8.1)中的Periodi更新为i时刻至i+1时刻这段时间段；以及，将∑irqcpu→cgroup_nr_runningi×Periodi进行更新为：在i时刻至i+1时刻这段时间内，一个CPU的运行队列上属于ta分组的进程的数量。其中，i+1时刻与i时刻的差值为最小采样时间间隔。
S802，检查ta分组的平均进程数量。
在执行上述S801之后执行上述S802，可以确定上述S801所计算出来的ta分组的平均进程数量是否为预设时间段内手机A包括的所有CPU中的真实ta分组的平均进程数量。
S803，确定ta分组的平均进程数目是否位于低负载阈值(即第一预设进程数量的一例)和高负载阈值(即第二预设进程数量的一例)之间。
低负载阈值和高负载阈值用于衡量ta分组的任务负载的轻重。具体来说，低负载阈值表示ta分组的任务负载较轻，高负载阈值表示ta分组的任务负载较重。在ta分组的任务负载位于低负载阈值和高负载阈值之间的情况下，ta分组的任务负载为中等程度的负载。低负载阈值和高负载阈值均是预设阈值，可以根据实际应用场景进行设置，对此不作具体限定。
执行上述S803，即确定ta分组的平均进程数目是否位于低负载阈值和高负载阈值之间。包括：确定ta分组的平均进程数目位于低负载阈值和高负载阈值之间，在执行上述S803之后继续执行S804；确定ta分组的平均进程数目没有位于低负载阈值和高负载阈值之间，在执行上述S803之后继续执行S806。
S804，将非ta分组(即非前台焦点分组的一例)的平均进程数目(即第二负载信息的一例)乘以预设系数(即预设系数的一例)，确定为非ta分组的需求的CPU数量(即非前台焦点分组需要的CPU数量的一例)。
在本申请实施例中，ta分组中的进程的优先级高于非ta分组中的进程的优先级。非ta分组可以但不限于是：foreground分组(简称为fg分组)或background分组(简称为bg分组)。对ta分组中的进程的任务类型，以及非ta分组中的进程的任务类型不作具体限定。也就是说，ta分组中的进程的任务类型和非ta分组中的进程的任务类型，可以根据实际应用场景进行设置。例如，ta分组中的进程的任务可以是投屏任务，其中，投屏任务是将手机A中运行的ta分组中的进程的图形用户界面(Graphical User Interface，GUI)投屏至除手机A以外的电子设备的显示屏上；非ta分组中的进程的任务可以是听音乐的任务。
执行上述S804，即为fg分组或bg分组确定需求CPU。其中，预设系数可以根据应用场景和用户需求进行设置。在一些实现方式中，预设系数可以根据非ta分组的总进程数量、一个CPU用于执行非ta分组中的进程数量确定。例如，在非ta分组为bg分组，bg分组包括10个进程，且设置一个CPU用于执行bg分组包括的2个进程的情况下，可以设置预设系数为0.1。又如，在非ta分组为bg分组，bg分组包括2个进程，且设置一个CPU用于执行bg分组包括的2个进程的情况下，可以设置预设系数为0.5。
可以理解的是，执行上述S804后可以确定非ta分组自身需求的CPU数量，但执行S804后确定的非ta分组的需求的CPU数量并不一定是最终分配给非ta分组的CPU的数量，接下来，还需要结合非ta分组的需求的CPU数据执行进一步判断。
S805，在需求的CPU数量位于非ta分组下可用的最少cpu数量(即第一预设CPU数量的一例)和非ta分组下可用的最多cpu数量(即第二预设CPU数量的一例)之间，将需求的CPU数量作为分配给非ta分组的可用CPU；在需求的CPU数量小于或等于非ta分组下可用的最少cpu数量的情况下，将非ta分组下可用的最少cpu数量作为分配给非ta分组的可用CPU；在需求的CPU数量大于或等于非ta分组下可用的最多cpu数量的情况下，将非ta分组下可用的最多cpu数量作为分配给非ta分组的可用CPU。
执行上述S803至S805的原理如下：在ta分组的平均进程数量处于低负载阈值和高负载阈值之间时，通过计算非ta分组的CPU需求来动态地为非ta分组分配CPU资源，且分配给非ta分组的CPU的数量应位于分组下可用的最少cpu数量和分组下可用的最多cpu数量之间。
在本申请实施例中，非ta分组下可用的最少cpu数量和非ta分组下可用的最多cpu数量是预设的。其中，非ta分组下可用的最多cpu数量小于或等于手机A包括的所有CPU的数量；非ta分组下可用的最多cpu数量大于非ta分组下可用的最小cpu数量。例如，在手机A可以包括8个CPU，且非ta分组为bg分组的场景中，bg分组下可用的最少CPU数量可以为2个CPU，bg分组下可用的最多CPU数量可以为6个CPU。又如，在手机A可以包括8个CPU，且非ta分组为fg分组的场景中，fg分组下可用的最少CPU数量可以为3个CPU，fg分组下可用的最多CPU数量可以为7个CPU。
S806，确定ta分组的平均进程数目是否大于高负载阈值。
执行上述S806，确定ta分组的平均进程数目是否大于高负载阈值，包括：在确定ta分组的平均进程数目大于高负载阈值的情况下，在执行上述S806之后继续执行807；在确定ta分组的平均进程数目没有大于高负载阈值的情况下，在执行上述S806之后继续执行809。其中，没有大于高负载阈值包括：小于或等于高负载阈值。
S807，确定手机A包括的每个CPU的利用率是否大于系统负载阈值(即预设比例的一例)。
执行上述S807，即确定手机A包括的每个CPU的利用率是否大于系统负载阈值，包括：在确定手机A包括的每个CPU的利用率大于系统负载阈值的情况下，执行上述S807之后继续执行S808；在确定手机A包括的每个CPU的利用率没有大于系统负载阈值的情况下，执行上述S807之后继续执行S804。可以理解的是，当手机A包括的每个CPU的利用率大于系统负载阈值，即手机A的系统处于高负载状态。
可选的，在执行上述S807之前，在本申请实施例中，还可以执行获取手机A包括的每个CPU的利用率。可以理解的是，手机A是包括多核CPU的电子设备，每个CPU的利用率的确定方式可以相同。下面，介绍本申请实施例提供的确定每个CPU的利用率的方法。
loadcpu＝AVG[load(W0)+load(W1)+...+load(WN-1)] (公式8.2)
在上述公式中，Wj(j＝0,1,...,N-1)表示第j个窗口，每个时间窗口的大小可以为默认值20ms。N表示窗口数量，例如N的默认取值可以为5。AVG[]表示聚合函数，用于计算某一时间段内的数据的平均值。
其中，一个窗口的负载Wj可以通过以下公式表示：
在上述公式中，busy_time表示每个CPU处于工作状态所占用的时间。total_time表示每个CPU的总时间。其中，total_time等于每个CPU处于工作状态所占用的时间与每个CPU处于空闲状态所占用的时间的总和。其中，对获取每个CPU的busy_time和每个CPU的total_time不作具体限定。
下面，举例描述获取每个CPU的busy_time和每个CPU的total_time的实现方法。示例性的，一个窗口的负载(load)可以通过使用系统中kcpustat_cpu[i]中记录的时间获取。示例性的，busy_time可以包括：user、nice、system。total_time可以包括：user、nice、system、idle、iowait+、irq、softirq、steal、guest、guest_nice。其中，user表示：CPU一共花了多少比例的时间运行在用户态空间或者说是用户进程(running user spaceprocesses)。nice表示用户空间进程的CPU的调度优先级。system表示：内核态CPU时间。idle表示：除I/O等待时间以外的其它等待时间；iowait+表示：等待I/O的CPU时间。irq表示：处理硬中断的CPU时间；softirq表示：处理软中断的CPU时间；steal表示：虚拟机进程在物理CPU上等待其CPU时间的时间百分比；guest表示代表通过虚拟化运行其他操作系统的时间，也就是运行虚拟机的CPU时间；guest_nice表示代表以低优先级运行虚拟机的时间。
需说明的是，在本申请实施例中，每个CPU的利用率采用窗口平均算法，保存N个窗口的负载，第N+1个窗口到来时清除第1个窗口的数据。示例性的，参见图9中的(1)示出的N个窗口，其中，N个窗口包括：第1个窗口，第2个窗口，第3个窗口，…,第N个窗口，N为正整数。示例性的，参见图9中的(2)示出的N个窗口，其中，N个窗口包括：第2个窗口，第3个窗口，第4个窗口，…，第N+1个窗口，N为正整数。也就是说，在图9中的(2)示出的第N+1个窗口到来时，会清除图9中的(1)示出的第1个窗口。
还需说明的是，上述以窗口平均算法为例描述了确定手机A包括的每个CPU的利用率的情况。可选的，还可以以其他方式确定手机A包括的每个CPU的利用率，本申请实施例对此不作具体限定。
S808，将预设的非ta分组下可用的最少cpu数量作为分配给非ta分组的可用CPU。
在本申请实施中，依次执行S806、S807和S808即：在确定ta分组的平均进程数目大于高负载阈值的情况下，进一步，根据手机A包括的每个CPU的利用率确定手机A的系统的CPU为高负载状态，这种情况下，即当前前台任务负载重且系统负载也重。因此，为了避免系统出现卡顿的问题需要严格显示分配给非ta分组的CPU的数量，即将预设的非ta分组下可用的最少cpu数量作为分配给非ta分组的可用CPU，其中，预设的非ta分组下可用的最少cpu数量小于手机A包括的所有CPU的数量。
S809，确定ta分组的平均进程数目是否小于低负载阈值。
执行上述S809，即确定ta分组的平均进程数目是否小于低负载阈值，包括：在确定ta分组的平均进程数目小于低负载阈值的情况下，在执行上述S809之后继续执行S810。
S810，将预设的非ta分组下可用的最多cpu数量作为分配给非ta分组的可用CPU。
在本申请实施中，依次执行S806、S809和S810即：在确定ta分组的平均进程数目小于低负载阈值的情况下(即，ta分组处于低负载状态)，为了提升系统的吞吐率，对非ta分组可以完全放开限制，即可以将预设的非ta分组下可用的最多cpu数量作为分配给非ta分组的可用CPU。
S811，将分配给非ta分组的可用CPU分配给非ta分组。
在本申请实施例中，cgroup用于对分组分配CPU资源。cgroup和分组之间存在对应关系，其中，一个cgroup和一个分组(例如，前台焦点分组或非前台焦点分组)对应，即一个cgroup用于为对应的一个分组分配CPU资源。
基于此，执行上述S810，即将分配给非ta分组的可用CPU分配给非ta分组，可以包括以下步骤：控制管理非ta分组的控制组cgroup，将分配给非ta分组的可用CPU分配给非ta分组。在实际应用中，“控制管理非ta分组的控制组cgroup，将分配给非ta分组的可用CPU分配给非ta分组”具体可以通过手机A中的native服务实现。其中，native服务是具有对节点目录中的内容进行改写的权限，节点目录中的内容用于表示分配给非ta分组的CPU的情况。例如，节点目录中的内容为CPU0和CPU1，即将CPU0和CPU1分配给非ta分组。
下面，结合具体的应用场景对执行上述S801至S811之前手机A的CPU资源分配情况，以及执行上述S801至S811之后手机A的CPU资源分配情况进行举例描述。
示例性的，参见图11中的(1)示出的手机A的CPU资源分配情况为执行上述S801至S811之前的情况。在图11中的(1)中，手机A一共包括4个CPU，其中，CPU1、CPU2和CPU4用于运行非ta分组中的进程和ta分组中的进程，CPU3仅用于运行ta分组中的进程。也就是说，图11中的(1)中示出的3个CPU均用于运行非ta分组中的进程。
示例性的，参见图11中的(2)示出的手机A的CPU资源分配情况为执行上述S801至S811之后的一种情况。在图11中的(2)中，其中，CPU1、CPU2、CPU3和CPU4均用于运行ta分组中的进程；CPU4用于同时运行非ta分组中的进程和ta分组中的进程。也就是说，图11中的(1)中示出的1个CPU用于运行非ta分组中的进程。
示例性的，参见图11中的(3)示出的手机A的CPU资源分配情况为执行上述S801至S811之后的另一种情况。在图11中的(3)中，其中，CPU3和CPU4均用于运行ta分组中的进程；CPU3用于同时运行非ta分组中的进程和ta分组中的进程；CPU1和CPU2仅用于运行ta分组中的进程。也就是说，图11中的(3)中示出的2个CPU用于运行非ta分组中的进程。
由图11中的(1)更新为图11中的(2)的场景中，可以理解为是，将非ta分组的最少可用cpu数量分配给非ta分组，其中，非ta分组的最少可用cpu数量等于1个。
由图11中的(1)更新为图11中的(3)的场景中，可以理解为是，即将非ta分组的最多可用cpu数量分配给非ta分组，其中，非ta分组的最少可用cpu数量等于2个。或者，由图11中的(1)更新为图11中的(3)的场景中，可以理解为是，即将非ta分组的需求cpu分配给非ta分组，其中，非ta分组的需求cpu的数量位于非ta分组的最少可用cpu数量与非ta分组的最多可用cpu数量之间。
应理解的是，上述图8示出的资源分配方法仅为示意，并不对本申请实施例提供的资源分配方法构成任何限定。在另一些实现方式中，上述采用窗口平均算法确定CPU的利用率的计算方法还可以替换为其他计算方法，对其他计算方法不作具体限定。例如，其他计算方法可以为传统技术中确定CPU的利用率的方法。在另一些实现方式中，上述采用时间平均加权的方式确定分组的平均进程数目的方法，还可以替换为其他传统技术中确定手机A的操作系统中分组的平均进程数目的方法。
在本申请实施例中，为ta分组分配手机A包括的所有CPU资源，以避免存在前台卡顿的现象，从而可以更好的满足用户的使用需求。在ta分组的负载较轻的情况下，或者，ta分组的负载为中等负载程度且手机A包括的所有CPU的资源利用率较小的情况下，为非ta分组分配较多的CPU资源，这样，在避免存在前台卡顿的情况下，同时还可以提高系统的吞吐率。在ta分组的负载为重度负载程度的情况下，严格限制分配给非ta分组的CPU资源，即仅将手机A包括的少部分CPU资源分配给非ta分组，这样，可以尽可能避免前台发生卡顿现象。综上，本申请实施例提供的资源分配方法，该方法可以避免系统前台发生卡顿，提高系统的吞吐率，从而实现系统性能的整体提升。
上文结合图1至图11，详细描述了本申请实施例的资源分配方法，下面将结合图12和图13，详细描述本申请的装置实施例。应理解，本申请实施例中的资源分配装置可以执行前述本申请实施例的各种资源分配方法，即以下各种产品的具体工作过程，可以参考前述方法实施例中的对应过程。
图12是本申请实施例提供的资源分配装置的示意图。
示例性的，图12示出的资源分配装置1200包括：处理单元1210。其中，资源分配装置应用于包括M个中央处理器CPU的设备中，所述M个CPU被优先分配给前台焦点分组，M为大于1的整数。
下面，介绍处理单元1210的作用。
在一些实现方式中，处理单元1210用于：获取第一负载信息，所述第一负载信息用于指示在预设时段内每个CPU执行所述前台焦点分组中的待运行进程的平均数量；所述处理单元1210还用于：根据所述第一负载信息，确定资源分配策略；所述处理单元1210还用于：根据所述资源分配策略，为非前台焦点分组分配CPU资源，所述非前台焦点分组的优先级低于所述前台焦点分组的优先级。
可选的，在一些实现方式中，所述处理单元1210还用于：在所述平均数量不超过第一预设进程数量的情况下，确定所述资源分配策略为将所述M个CPU中的N个CPU分配给所述非前台焦点分组，N是预设的最多能够分配给所述非前台焦点分组的CPU的数量，N为小于或等于M的整数。
可选的，在一些实现方式中，所述处理单元1210还用于：在所述平均数量大于第一预设进程数量且小于或等于第二预设进程数量的情况下，根据第二负载信息，确定所述资源分配策略，所述第二负载信息用于指示在所述预设时段内所述M个CPU中的至少一个CPU执行所述非前台焦点分组中的待运行进程的平均数量。
可选的，在一些实现方式中，所述处理单元1210还用于：在所述平均数量超过第二预设进程数量的情况下，根据资源利用率信息，确定所述资源分配策略，所述资源利用率信息用于指示在所述预设时段内所述M个CPU中的每个CPU实际处理数据的时间占实际运行时间的比例。
可选的，在一些实现方式中，所述处理单元1210还用于：根据所述资源利用率信息，确定所述M个CPU的利用率；在所述M个CPU的利用率超过预设比例的情况下，确定所述资源分配策略为将所述M个CPU中的K个CPU分配给所述非前台焦点分组，K是预设的最少能够分配给所述非前台焦点分组的CPU的数量，K为小于或等于N的整数；或者，在所述M个CPU的利用率不超过所述预设比例的情况下，根据第二负载信息，确定所述资源分配策略，所述第二负载信息用于指示在所述预设时段内所述M个CPU中的至少一个CPU执行所述非前台焦点分组中的待运行进程的平均数量。
可选的，在一些实现方式中，所述处理单元1210还用于：根据所述第二负载信息，确定所述非前台焦点分组需要的CPU数量；根据所述非前台焦点分组需要的CPU数量、第一预设CPU数量和第二预设CPU数量，确定所述资源分配策略，所述第一预设CPU数量是预设的最少能够分配给所述非前台焦点分组的CPU的数量，所述第二预设CPU数量是预设的最多能够分配给所述非前台焦点分组的CPU的数量。
可选的，在一些实现方式中，所述第一预设CPU数量为K，所述第二预设CPU数量为N，N为小于或等于M的整数，K为小于或等于N的整数，所述处理单元1210还用于：在所述非前台焦点分组需要的CPU数量小于或等于K的情况下，确定所述资源分配策略为将所述M个CPU中的K个CPU分配给所述非前台焦点分组；在所述非前台焦点分组需要的CPU数量大于或等于N的情况下，确定所述资源分配策略为将所述M个CPU中的N个CPU分配给所述非前台焦点分组；在所述非前台焦点分组需要的CPU数量大于K且小于N的情况下，确定所述资源分配策略为将所述M个CPU中的所述需要的CPU数量个CPU分配给所述非前台焦点分组。
可选的，在一些实现方式中，所述预设时段内包括P个时间窗口，P为正整数；以及，所述处理单元1210还用于：在所述根据资源利用率信息，确定所述资源分配策略之前，执行以下操作：获取所述每个CPU在每个时间窗口的利用率，所述每个CPU在所述每个时间窗口的利用率表示在所述每个时间窗口内所述每个CPU实际处理数据的时间占实际运行时间的比例；对所述每个CPU在所述P个时间窗口的利用率执行求和处理，获得所述每个CPU在所述P个时间窗口的总利用率；利用所述总利用率除以所述预设时段，获得在所述预设时段内所述每个CPU处理数据的时间占实际运行时间的比例，以得到所述资源利用率信息。
可选的，在一些实现方式中，所述处理单元1210还用于：获取所述M个CPU中每个CPU的进程数量，所述每个CPU的进程数量表示在所述预设时段内所述每个CPU的运行队列上属于所述前台焦点分组的进程的数量；对所述M个CPU的进程数量执行求和处理，获得求和处理结果；对所述求和处理结果除以M个预设时段，获得在所述预设时段内所述每个CPU执行所述前台焦点分组中的待运行进程的平均数量，所述M个预设时段和所述M个CPU一一对应。
可选的，在一些实现方式中，所述处理单元1210还用于：根据所述资源分配策略，在所述非前台焦点分组包括多个进程的情况下，根据所述多个进程中的每个进程的优先级为所述非前台焦点分组中的进程分配CPU资源，优先级高的进程所分配到的CPU资源大于优先级低的进程所分配到的CPU资源。
可选的，在一些实现方式中，所述非前台焦点分组为前台分组或后台分组。
需要说明的是，上述资源分配装置1200以功能单元的形式体现。这里的术语“单元”可以通过软件和/或硬件形式实现，对此不作具体限定。
例如，“单元”可以是实现上述功能的软件程序、硬件电路或二者结合。所述硬件电路可能包括应用特有集成电路(application specific integrated circuit，ASIC)、电子电路、用于执行一个或多个软件或固件程序的处理器(例如共享处理器、专有处理器或组处理器等)和存储器、合并逻辑电路和/或其它支持所描述的功能的合适组件。
因此，在本申请的实施例中描述的各示例的单元，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
图13是本申请提供的一种资源分配设备的结构的示意图。图13中的虚线表示该单元或该模块为可选的。资源分配设备1300可用于实现上述方法实施例中描述的资源分配方法。
资源分配设备1300包括一个或多个处理器1301，该一个或多个处理器1301可支持资源分配设备1300实现方法实施例中的资源分配方法。处理器1301可以是通用处理器或者专用处理器。例如，处理器1301可以是中央处理器(central processing unit，CPU)、数字信号处理器(digital signal processor，DSP)、专用集成电路(application specificintegrated circuit，ASIC)、现场可编程门阵列(field programmable gate array，FPGA)或者其它可编程逻辑器件，如分立门、晶体管逻辑器件或分立硬件组件。
处理器1301可以用于对资源分配设备1300进行控制，执行软件程序，处理软件程序的数据。资源分配设备1300还可以包括通信单元1305，用以实现信号的输入(接收)和输出(发送)。
例如，资源分配设备1300可以是芯片，通信单元1305可以是该芯片的输入和/或输出电路，或者，通信单元1305可以是该芯片的通信接口，该芯片可以作为终端设备或其它电子设备的组成部分。
又例如，资源分配设备1300可以是终端设备，通信单元1305可以是该终端设备的收发器，或者，通信单元1305可以是该终端设备的收发电路。
资源分配设备1300中可以包括一个或多个存储器1302，其上存有程序1304，程序1304可被处理器1301运行，生成指令1303，使得处理器1301根据指令1303执行上述方法实施例中描述的资源分配方法。
可选地，存储器1302中还可以存储有数据。可选地，处理器1301还可以读取存储器1302中存储的数据，该数据可以与程序1304存储在相同的存储地址，该数据也可以与程序1304存储在不同的存储地址。
处理器1301和存储器1302可以单独设置，也可以集成在一起；例如，集成在终端设备的系统级芯片(system on chip，SOC)上。
示例性的，存储器1302可以用于存储本申请实施例中提供的资源分配方法的相关程序1304，处理器1301可以用于调用存储器1302中存储的资源分配方法的相关程序1304，执行本申请实施例的资源分配方法。
本申请还提供了一种计算机程序产品，该计算机程序产品被处理器1301执行时实现本申请中任一方法实施例所述的资源分配方法。
该计算机程序产品可以存储在存储器1302中，例如是程序1304，程序1304经过预处理、编译、汇编和链接等处理过程最终被转换为能够被处理器1301执行的可执行目标文件。
本申请还提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被计算机执行时实现本申请中任一方法实施例所述的资源分配方法。该计算机程序可以是高级语言程序，也可以是可执行目标程序。
该计算机可读存储介质例如是存储器1302。存储器1302可以是易失性存储器或非易失性存储器，或者，存储器1302可以同时包括易失性存储器和非易失性存储器。其中，非易失性存储器可以是只读存储器(read-only memory，ROM)、可编程只读存储器(programmable ROM，PROM)、可擦除可编程只读存储器(erasable PROM，EPROM)、电可擦除可编程只读存储器(electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(random access memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(static RAM，SRAM)、动态随机存取存储器(dynamic RAM，DRAM)、同步动态随机存取存储器(synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(double data rate SDRAM，DDR SDRAM)、增强型同步动态随机存取存储器(enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器(synchlinkDRAM，SLDRAM)和直接内存总线随机存取存储器(direct rambus RAM，DR RAM)。
本申请中，“至少一个”是指一个或者多个，“多个”是指两个或两个以上。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a,b,或c中的至少一项(个)，可以表示：a,b,c,a-b,a-c,b-c,或a-b-c，其中a,b,c可以是单个，也可以是多个。
应理解，在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本申请所提供的几个实施例中，应该理解到所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的；例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式；例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (14)

1.一种资源分配方法，其特征在于，应用于包括M个中央处理器CPU的设备中，所述M个CPU被优先分配给前台焦点分组，M为大于1的整数，所述方法包括：
获取第一负载信息，所述第一负载信息用于指示在预设时段内每个CPU执行所述前台焦点分组中的待运行进程的平均数量；
根据所述第一负载信息，确定资源分配策略；
根据所述资源分配策略，为非前台焦点分组分配CPU资源，所述非前台焦点分组的优先级低于所述前台焦点分组的优先级。
2.根据权利要求1所述的方法，其特征在于，所述根据所述第一负载信息，确定资源分配策略，包括：
在所述平均数量不超过第一预设进程数量的情况下，确定所述资源分配策略为将所述M个CPU中的N个CPU分配给所述非前台焦点分组，N是预设的最多能够分配给所述非前台焦点分组的CPU的数量，N为小于或等于M的整数。
3.根据权利要求1所述的方法，其特征在于，所述根据所述第一负载信息，确定资源分配策略，包括：
在所述平均数量大于第一预设进程数量且小于或等于第二预设进程数量的情况下，根据第二负载信息，确定所述资源分配策略，所述第二负载信息用于指示在所述预设时段内所述M个CPU中的至少一个CPU执行所述非前台焦点分组中的待运行进程的平均数量。
4.根据权利要求1所述的方法，其特征在于，所述根据所述第一负载信息，确定资源分配策略，包括：
在所述平均数量超过第二预设进程数量的情况下，根据资源利用率信息，确定所述资源分配策略，所述资源利用率信息用于指示在所述预设时段内所述M个CPU中的每个CPU实际处理数据的时间占实际运行时间的比例。
5.根据权利要求4所述的方法，其特征在于，所述根据资源利用率信息，确定所述资源分配策略，包括：
根据所述资源利用率信息，确定所述M个CPU的利用率；
在所述M个CPU的利用率超过预设比例的情况下，确定所述资源分配策略为将所述M个CPU中的K个CPU分配给所述非前台焦点分组，K是预设的最少能够分配给所述非前台焦点分组的CPU的数量，K为小于或等于N的整数；或者，
在所述M个CPU的利用率不超过所述预设比例的情况下，根据第二负载信息，确定所述资源分配策略，所述第二负载信息用于指示在所述预设时段内所述M个CPU中的至少一个CPU执行所述非前台焦点分组中的待运行进程的平均数量。
6.根据权利要求3或5所述的方法，其特征在于，所述根据第二负载信息，确定所述资源分配策略，包括：
根据所述第二负载信息，确定所述非前台焦点分组需要的CPU数量；
根据所述非前台焦点分组需要的CPU数量、第一预设CPU数量和第二预设CPU数量，确定所述资源分配策略，所述第一预设CPU数量是预设的最少能够分配给所述非前台焦点分组的CPU的数量，所述第二预设CPU数量是预设的最多能够分配给所述非前台焦点分组的CPU的数量。
7.根据权利要求6所述的方法，其特征在于，所述第一预设CPU数量为K，所述第二预设CPU数量为N，N为小于或等于M的整数，K为小于或等于N的整数，
所述根据非前台焦点分组需要的CPU数量、第一预设CPU数量和第二预设CPU数量，确定资源分配策略，包括：
在所述非前台焦点分组需要的CPU数量小于或等于K的情况下，确定所述资源分配策略为将所述M个CPU中的K个CPU分配给所述非前台焦点分组；
在所述非前台焦点分组需要的CPU数量大于或等于N的情况下，确定所述资源分配策略为将所述M个CPU中的N个CPU分配给所述非前台焦点分组；
在所述非前台焦点分组需要的CPU数量大于K且小于N的情况下，确定所述资源分配策略为将所述M个CPU中的所述需要的CPU数量个CPU分配给所述非前台焦点分组。
8.根据权利要求4至7任一项所述的方法，其特征在于，所述预设时段内包括P个时间窗口，P为正整数；以及，
在所述根据资源利用率信息，确定所述资源分配策略之前，所述方法还包括：
获取所述每个CPU在每个时间窗口的利用率，所述每个CPU在所述每个时间窗口的利用率表示在所述每个时间窗口内所述每个CPU实际处理数据的时间占实际运行时间的比例；
对所述每个CPU在所述P个时间窗口的利用率执行求和处理，获得所述每个CPU在所述P个时间窗口的总利用率；
利用所述总利用率除以所述预设时段，获得在所述预设时段内所述每个CPU处理数据的时间占实际运行时间的比例，以得到所述资源利用率信息。
9.根据权利要求1至8任一项所述的方法，其特征在于，所述获取第一负载信息，包括：
获取所述M个CPU中每个CPU的进程数量，所述每个CPU的进程数量表示在所述预设时段内所述每个CPU的运行队列上属于所述前台焦点分组的进程的数量；
对所述M个CPU的进程数量执行求和处理，获得求和处理结果；
对所述求和处理结果除以M个预设时段，获得在所述预设时段内所述每个CPU执行所述前台焦点分组中的待运行进程的平均数量，所述M个预设时段和所述M个CPU一一对应。
10.根据权利要求1至9任一项所述的方法，其特征在于，所述非前台焦点分组为前台分组或后台分组。
11.一种资源分配装置，其特征在于，应用于包括M个中央处理器CPU的设备中，所述M个CPU被优先分配给前台焦点分组，M为大于1的整数，
所述装置包括：
处理单元用于：获取第一负载信息，所述第一负载信息表示在预设时段内每个CPU执行所述前台焦点分组中的待运行进程的平均数量；
所述处理单元还用于：根据所述第一负载信息，确定资源分配策略；
所述处理单元还用于：根据所述资源分配策略，为非前台焦点分组分配CPU资源，所述非前台焦点分组的优先级低于所述前台焦点分组的优先级。
12.一种资源分配设备，其特征在于，所述资源分配设备包括处理器和存储器，所述存储器用于存储计算机程序，所述处理器用于从所述存储器中调用并运行所述计算机程序，使得所述设备执行权利要求1至10中任一项所述的资源分配方法。
13.一种芯片，其特征在于，包括处理器，当所述处理器执行指令时，所述处理器执行如权利要求1至10中任一项所述的资源分配方法。
14.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储了计算机程序，当所述计算机程序被处理器执行时，使得处理器执行权利要求1至10中任一项所述的资源分配方法。
CN202310488894.2A 2023-04-28 2023-04-28 资源分配方法、装置和设备 Pending CN117130773A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310488894.2A CN117130773A (zh) 2023-04-28 2023-04-28 资源分配方法、装置和设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310488894.2A CN117130773A (zh) 2023-04-28 2023-04-28 资源分配方法、装置和设备

Publications (1)

Publication Number Publication Date
CN117130773A true CN117130773A (zh) 2023-11-28

Family

ID=88860621

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310488894.2A Pending CN117130773A (zh) 2023-04-28 2023-04-28 资源分配方法、装置和设备

Country Status (1)

Country Link
CN (1) CN117130773A (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117389711A (zh) * 2023-12-11 2024-01-12 腾讯科技（深圳）有限公司 终端资源的调度方法、装置、终端及计算机可读存储介质
CN117858262A (zh) * 2024-03-07 2024-04-09 成都爱瑞无线科技有限公司 基站资源调度优化方法、装置、基站、设备、介质及产品
CN117858262B (zh) * 2024-03-07 2024-05-14 成都爱瑞无线科技有限公司 基站资源调度优化方法、装置、基站、设备、介质及产品

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103577267A (zh) * 2012-08-03 2014-02-12 上海博泰悦臻电子设备制造有限公司 车载设备的资源分配方法及装置
CN107168803A (zh) * 2017-05-19 2017-09-15 努比亚技术有限公司 一种cpu资源分配方法和终端
CN107526640A (zh) * 2017-08-17 2017-12-29 广东欧珀移动通信有限公司 资源管理方法、装置、移动终端及计算机可读存储介质
CN109684090A (zh) * 2018-12-19 2019-04-26 三星电子（中国）研发中心 一种资源分配方法和装置
US20190188030A1 (en) * 2016-08-25 2019-06-20 Huawei Technologies Co., Ltd. Terminal background application management method and apparatus
CN109992400A (zh) * 2017-12-29 2019-07-09 广东欧珀移动通信有限公司 资源分配方法、装置、移动终端及计算机可读存储介质
CN114065090A (zh) * 2021-11-02 2022-02-18 北京安云世纪科技有限公司 分类数据库的更新方法、系统、存储介质及计算机设备

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103577267A (zh) * 2012-08-03 2014-02-12 上海博泰悦臻电子设备制造有限公司 车载设备的资源分配方法及装置
US20190188030A1 (en) * 2016-08-25 2019-06-20 Huawei Technologies Co., Ltd. Terminal background application management method and apparatus
CN107168803A (zh) * 2017-05-19 2017-09-15 努比亚技术有限公司 一种cpu资源分配方法和终端
CN107526640A (zh) * 2017-08-17 2017-12-29 广东欧珀移动通信有限公司 资源管理方法、装置、移动终端及计算机可读存储介质
CN109992400A (zh) * 2017-12-29 2019-07-09 广东欧珀移动通信有限公司 资源分配方法、装置、移动终端及计算机可读存储介质
CN109684090A (zh) * 2018-12-19 2019-04-26 三星电子（中国）研发中心 一种资源分配方法和装置
CN114065090A (zh) * 2021-11-02 2022-02-18 北京安云世纪科技有限公司 分类数据库的更新方法、系统、存储介质及计算机设备

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117389711A (zh) * 2023-12-11 2024-01-12 腾讯科技（深圳）有限公司 终端资源的调度方法、装置、终端及计算机可读存储介质
CN117389711B (zh) * 2023-12-11 2024-04-09 腾讯科技（深圳）有限公司 终端资源的调度方法、装置、终端及计算机可读存储介质
CN117858262A (zh) * 2024-03-07 2024-04-09 成都爱瑞无线科技有限公司 基站资源调度优化方法、装置、基站、设备、介质及产品
CN117858262B (zh) * 2024-03-07 2024-05-14 成都爱瑞无线科技有限公司 基站资源调度优化方法、装置、基站、设备、介质及产品

Similar Documents

Publication Publication Date Title
WO2020108356A1 (zh) 一种应用显示方法及电子设备
US11573829B2 (en) Task processing method and apparatus, terminal, and computer readable storage medium
WO2021036770A1 (zh) 一种分屏处理方法及终端设备
CN111913750B (zh) 一种应用程序管理方法、装置及设备
CN112527476B (zh) 资源调度方法及电子设备
WO2021115112A1 (zh) 安装包的下载方法、分发方法、终端设备、服务器及系统
WO2021052070A1 (zh) 一种帧率识别方法及电子设备
CN111543042A (zh) 通知消息的处理方法及电子设备
WO2022078105A1 (zh) 内存管理方法、电子设备以及计算机可读存储介质
CN115705241B (zh) 应用的调度方法及电子设备
CN113596919B (zh) 数据下载方法、装置和终端设备
CN117130773A (zh) 资源分配方法、装置和设备
CN116680153B (zh) 应用帧率平滑方法、电子设备及存储介质
CN111104209B (zh) 一种处理任务的方法及相关设备
CN114697348A (zh) 分布式实现方法、分布式系统、可读介质及电子设备
CN115119048B (zh) 一种视频流处理方法及电子设备
CN115729684B (zh) 输入输出请求处理方法和电子设备
CN114461589B (zh) 读取压缩文件的方法、文件系统及电子设备
CN116700913A (zh) 嵌入式文件系统的调度方法、设备及存储介质
CN114546511A (zh) 插件管理方法、系统及装置
CN116048772B (zh) 中央处理单元频率的调整方法、装置和终端设备
CN116703691B (zh) 图像处理方法、电子设备及计算机存储介质
CN116795604B (zh) 应用异常退出的处理方法、装置和设备
CN116048831B (zh) 一种目标信号处理方法和电子设备
CN116661984B (zh) 一种负载管控方法、电子设备及存储介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination