CN116089096A - 负载资源调度方法及电子设备 - Google Patents

Abstract

本申请实施例提供了一种负载资源调度方法及电子设备。通过确定应用程序所属的目标丢帧场景，根据实时负载数据和与目标丢帧场景匹配的负载统计阈值，对电子设备的CPU资源进行调度。可以有效缓解界面显示过程中的滑动丢帧问题，可以有效提升负载资源调度效率，保证负载资源调度效果。

Description

负载资源调度方法及电子设备

技术领域

本申请实施例涉及终端设备领域，尤其涉及一种负载资源调度方法及电子设备。

背景技术

用户可以通过显示屏与终端设备进行交互。终端设备的界面显示通常需要经过绘制、渲染、合成和送显等过程。在进行界面显示的过程中，可能会出现滑动丢帧的现象。

在界面显示过程中进行负载资源调度，可以有效缓解滑动丢帧的现象。目前，在对各类应用、不同界面显示进行负载资源调度时，存在资源调度效果不理想、调度效率低的问题。

发明内容

为了解决上述技术问题，本申请提供一种负载资源调度方法及电子设备。该方法中，可以确定应用程序所属的目标丢帧场景，根据实时负载数据和与目标丢帧场景匹配的负载统计阈值，对电子设备的CPU资源进行调度。可以有效缓解界面显示过程中的滑动丢帧问题，可以有效提升负载资源调度效率，保证负载资源调度效果。

第一方面，本申请实施例提供一种负载资源调度方法。该方法包括：响应于应用程序的界面显示处于滑动场景，获取与所述应用程序关联的丢帧检测数据和实时负载数据；基于所述丢帧检测数据，确定所述应用程序所属的目标丢帧场景；以及根据所述实时负载数据和与所述目标丢帧场景匹配的负载统计阈值，对电子设备的CPU资源进行调度。

根据基于滑动场景的丢帧检测数据，确定应用程序所属的目标丢帧场景。根据与目标丢帧场景匹配的负载统计阈值，对电子设备的CPU资源进行调度。可以有效缓解界面显示过程中滑动丢帧的现象，能够有效增加界面显示的流畅性，提升用户体验。此外，基于丢帧场景类型进行负载资源调度，能够有效提升负载资源调度效率，改善负载资源调度效果。

根据第一方面，所述获取与应用程序关联的基于滑动场景的丢帧检测数据和实时负载数据，包括：检测基于所述应用程序被触发的触摸事件；在所述触摸事件为移动事件或移动抬起事件的情况下，确定所述应用程序处于所述滑动场景；获取与所述应用程序关联的基于所述滑动场景的所述丢帧检测数据和所述实时负载数据。

触摸事件可以在电子设备的各个模块之间进行传递，根据触摸事件类型，对电子设备中发生的丢帧事件进行针对性分析。具体地，在触摸事件为移动事件或移动抬起事件的情况下，确定丢帧事件为滑动丢帧事件。基于滑动丢帧事件进行负载资源调度，可以有效提升负载资源调度的针对性，改善应用使用的流畅性。

根据第一方面，或者以上第一方面的任意一种实现方式，所述获取与所述应用程序关联的基于所述滑动场景的所述丢帧检测数据，包括：获取与所述应用程序关联的包含丢帧时长信息的丢帧记录数据，以作为所述丢帧检测数据，所述丢帧记录数据与所述移动事件的被触发过程和/或与所述移动抬起事件被触发后的预设时间段相对应。

丢帧记录数据例如可以包括丢帧界面、丢帧次数、丢帧发生时刻、单次丢帧时长、丢帧平均耗时等信息。

根据第一方面，或者以上第一方面的任意一种实现方式，所述基于所述丢帧检测数据，确定所述应用程序所属的目标丢帧场景，包括：基于所述丢帧时长信息和预设的多个丢帧时长阈值，确定与各所述丢帧时长阈值匹配的丢帧记录数目；根据与各所述丢帧时长阈值匹配的所述丢帧记录数目，确定由所述丢帧记录数目指示的所述目标丢帧场景，其中，所述目标丢帧场景为多个候选丢帧场景中的任意丢帧场景，所述多个候选丢帧场景包括无丢帧场景、不易感知丢帧场景、明显丢帧场景和严重丢帧场景。

与各丢帧时长阈值匹配的丢帧记录数目，指示与对应丢帧时长阈值匹配的滑动丢帧频次。多个候选丢帧场景分别各自对应匹配的丢帧时长阈值和丢帧频次阈值。因此，可以基于预设的多个丢帧时长阈值和丢帧记录数据中的丢帧时长信息，确定由丢帧记录数据指示的目标丢帧场景。

通过确定由丢帧记录数据指示的目标丢帧场景，根据与目标丢帧场景匹配的负载统计阈值，对电子设备的CPU资源进行调度，一方面，可以有效解决滑动丢帧问题，提升应用显示的流畅性，优化用户使用体验，另一方面，根据针对应用程序的实际使用行为进行CPU资源调度，可以有效提升负载资源调度的针对性，有利于改善负载资源调度效果。

根据第一方面，或者以上第一方面的任意一种实现方式，获取与所述应用程序关联的基于所述滑动场景的所述实时负载数据，包括：获取与所述应用程序关联的CPU占用信息，以作为所述实时负载数据，其中，所述CPU占用信息与所述移动事件的被触发过程和/或与所述移动抬起事件被触发后的预设时间段相对应。

CPU占用信息例如可以包括CPU占用率、CPU程序占比等信息。

根据第一方面，或者以上第一方面的任意一种实现方式，根据预设的故障场景列表，确定与所述目标丢帧场景匹配的CPU占用率阈值，以作为所述负载统计阈值，其中，所述故障场景列表是基于以下操作得到的：获取目标用户针对电子设备的使用行为所对应的丢帧记录数据和CPU占用信息；根据所述丢帧记录数据中的丢帧时长信息，确定与多个候选丢帧场景中的各所述候选丢帧场景匹配的目标丢帧记录；根据与所述目标丢帧记录关联的所述CPU占用信息，将由所述CPU占用信息指示的CPU占用率阈值，作为与各所述候选丢帧场景匹配的负载统计阈值；与各所述候选丢帧场景匹配的所述负载统计阈值，构成所述故障场景列表，所述目标丢帧场景为多个候选丢帧场景中的任意丢帧场景，所述多个候选丢帧场景包括无丢帧场景、不易感知丢帧场景、明显丢帧场景和严重丢帧场景。

故障场景列表包括多个候选丢帧场景，以及包括与多个候选丢帧场景中的各候选丢帧场景匹配的CPU占用率阈值。根据故障场景列表，确定与目标丢帧场景匹配的CPU占用率阈值。以及，根据与目标丢帧场景匹配的CPU占用率阈值，对电子设备的CPU资源进行调度。可以在缓解滑动丢帧问题的基础上，有效实现提前感知滑动显示故障，提升用户使用体验。

根据第一方面，或者以上第一方面的任意一种实现方式，所述CPU占用信息指示CPU占用率，与各所述候选丢帧场景匹配的所述负载统计阈值包括第一CPU占用率阈值、第二CPU占用率阈值、第三CPU占用率阈值和第四CPU占用率阈值，

所述负载统计阈值是基于以下操作得到的：对基于所述预设时间段内的所述CPU占用率进行由小至大排序；根据由小至大排序的所述CPU占用率，将前第一预设占比的所述CPU占用率中的最大CPU占用率作为所述第一CPU占用率阈值；将前第二预设占比的所述CPU占用率中的最大CPU占用率作为所述第二CPU占用率阈值，所述第二预设占比大于所述第一预设占比；将前第三预设占比的所述CPU占用率中的最大CPU占用率作为所述第三CPU占用率阈值，所述第三预设占比大于所述第二预设占比；将所有CPU占用率中的最大CPU占用率作为所述第四CPU占用率阈值。

根据与目标丢帧场景匹配的CPU占用率阈值，对电子设备的CPU资源进行调度，可以有效提升CPU资源调度效率，保证CPU资源调度效果，可以在有效解决滑动丢帧问题的基础上，优化CPU资源分配效果，提升CPU资源利用率。

根据第一方面，或者以上第一方面的任意一种实现方式，所述CPU资源包括CPU频点、用于执行系统动作的CPU核、是否允许执行系统动作和内存剩余量；所述根据所述实时负载数据和与所述目标丢帧场景匹配的负载统计阈值，对电子设备的CPU资源进行调度，包括：根据与所述目标丢帧场景匹配的所述负载统计阈值和由所述实时负载数据指示的实时CPU占用率，对所述CPU资源进行调度。

根据第一方面，或者以上第一方面的任意一种实现方式，所述根据与所述目标丢帧场景匹配的所述负载统计阈值和由所述实时负载数据指示的实时CPU占用率，对所述CPU资源进行调度，包括：在所述实时CPU占用率大于或等于所述第四CPU占用率阈值的情况下，提高所述CPU频点。

CPU为时钟驱动系统，其负载能力受限于时钟频率。CPU频率越高，单位时间内所能处理的指令数量越多，CPU负载能力越强。在CPU实际占用率超过最高CPU占用率阈值的情况下，提高CPU频点，可以有效提升CPU单位时间内所能处理的指令数量，可以有效解决滑动场景中的显示丢帧问题，有利于提升应用使用的流畅性，改善用户使用体验。

根据第一方面，或者以上第一方面的任意一种实现方式，所述根据与所述目标丢帧场景匹配的所述负载统计阈值和由所述实时负载数据指示的实时CPU占用率，对所述CPU资源进行调度，包括：在所述实时CPU占用率小于所述第四CPU占用率阈值，且大于或等于所述第三CPU占用率阈值的情况下，将所述系统动作置于CPU小核中执行。

安卓系统中的系统动作（system actions）可以是预先定义的操作或事件，可以由应用程序或系统本身触发，以用于启动、停止或执行应用程序之间的交互，系统动作例如可以包括垃圾内存回收、odex（一种从安卓系统的应用程序apk中提取出来的可运行文件）优化编译等。在CPU实际占用率超过次最大CPU占用率阈值的情况下，说明基于滑动场景的界面显示需要占用较多的CPU资源，强制将系统动作置于CPU小核中执行，及时规避易抢占CPU资源的系统行为，以空出计算能力更强的CPU大核，可以有效保证滑动场景中界面显示的流畅性，有利于提前规避滑动丢帧问题，保证用户使用体验。

根据第一方面，或者以上第一方面的任意一种实现方式，所述根据与所述目标丢帧场景匹配的所述负载统计阈值和由所述实时负载数据指示的实时CPU占用率，对所述CPU资源进行调度，包括：在所述实时CPU占用率小于所述第三CPU占用率阈值，且大于或等于所述第二CPU占用率阈值的情况下，允许执行所述系统动作。

在CPU实际占用率小于次最大CPU占用率阈值的情况下，说明基于滑动场景的界面显示无需占用较多的CPU资源，通过使用常规CPU资源调度方案，允许执行系统动作，可以在有效保证界面显示的流畅性的基础上，保证终端设备的其他功能运转的性能体验。

根据第一方面，或者以上第一方面的任意一种实现方式，所述根据与所述目标丢帧场景匹配的所述负载统计阈值和由所述实时负载数据指示的实时CPU占用率，对所述CPU资源进行调度，包括：在所述实时CPU占用率小于所述第二CPU占用率阈值，且大于或等于所述第一CPU占用率阈值的情况下，降低所述CPU频点。

在CPU实际占用率小于次最小CPU占用率阈值的情况下，说明基于滑动场景的界面显示占用较少的CPU资源。通过降低CPU频点，可以在有效保证界面显示的流畅性的基础上，节约系统资源与功耗。

根据第一方面，或者以上第一方面的任意一种实现方式，所述根据与所述目标丢帧场景匹配的所述负载统计阈值和由所述实时负载数据指示的CPU占用率，对所述CPU资源进行调度，包括：在所述CPU占用率小于所述第一CPU占用率阈值、且所述内存剩余量小于预设内存水线级的情况下，禁止执行所述系统动作。

在内存剩余量小于预设内存水线级的情况下，说明系统性能崩溃，界面显示可能出现极其卡顿的现象，禁止执行系统动作，以空出更多的CPU资源，可以有效缓解滑动过程中的界面丢帧现象，有效保证应用使用的流畅性。

根据第一方面，或者以上第一方面的任意一种实现方式，所述应用程序包括使用频次高于预设频次阈值的目标应用。对用户高频使用的目标应用进行CPU资源调度，可以有效保证CPU资源调度效果，有效提升CPU资源调度效率。

根据第一方面，或者以上第一方面的任意一种实现方式，获取与所述应用程序关联的基于所述滑动场景的所述实时负载数据，包括：获取与所述应用程序关联的以下数据中的至少之一，以作为所述实时负载数据：GPU负载信息、内存使用信息、函数调用信息和堆栈信息。

基于多元化的实时负载数据进行负载资源调度，可以有效解决滑动场景中界面显示掉帧的问题，有利于保证应用使用的动态流畅性，提升用户使用体验。

根据第一方面，或者以上第一方面的任意一种实现方式，根据所述实时负载数据和与所述目标丢帧场景匹配的所述负载统计阈值，对电子设备的以下资源中的至少之一进行调度：GPU频点、线程运行核心、应用显示帧率和屏幕刷新率。

进行针对滑动场景的多样化的负载资源调度，有利于保证滑动场景中界面显示的稳定流畅性。

第二方面，本申请实施例提供一种电子设备。该电子设备包括存储器和处理器，存储器和处理器耦合，存储器存储有程序指令，程序指令由处理器执行时，使得电子设备执行如下步骤：响应于应用程序的界面显示处于滑动场景，获取与所述应用程序关联的丢帧检测数据和实时负载数据；基于所述丢帧检测数据，确定所述应用程序所属的目标丢帧场景；以及根据所述实时负载数据和与所述目标丢帧场景匹配的负载统计阈值，对电子设备的CPU资源进行调度。

根据第二方面，所述获取与应用程序关联的基于滑动场景的丢帧检测数据和实时负载数据，包括：检测基于所述应用程序被触发的触摸事件；在所述触摸事件为移动事件或移动抬起事件的情况下，确定所述应用程序处于所述滑动场景；获取与所述应用程序关联的基于所述滑动场景的所述丢帧检测数据和所述实时负载数据。

根据第二方面，或者以上第二方面的任意一种实现方式，所述获取与所述应用程序关联的基于所述滑动场景的所述丢帧检测数据，包括：获取与所述应用程序关联的包含丢帧时长信息的丢帧记录数据，以作为所述丢帧检测数据，所述丢帧记录数据与所述移动事件的被触发过程和/或与所述移动抬起事件被触发后的预设时间段相对应。

根据第二方面，或者以上第二方面的任意一种实现方式，所述基于所述丢帧检测数据，确定所述应用程序所属的目标丢帧场景，包括：基于所述丢帧时长信息和预设的多个丢帧时长阈值，确定与各所述丢帧时长阈值匹配的丢帧记录数目；根据与各所述丢帧时长阈值匹配的所述丢帧记录数目，确定由所述丢帧记录数目指示的所述目标丢帧场景，其中，所述目标丢帧场景为多个候选丢帧场景中的任意丢帧场景，所述多个候选丢帧场景包括无丢帧场景、不易感知丢帧场景、明显丢帧场景和严重丢帧场景。

根据第二方面，或者以上第二方面的任意一种实现方式，获取与所述应用程序关联的基于所述滑动场景的所述实时负载数据，包括：获取与所述应用程序关联的CPU占用信息，以作为所述实时负载数据，其中，所述CPU占用信息与所述移动事件的被触发过程和/或与所述移动抬起事件被触发后的预设时间段相对应。

根据第二方面，或者以上第二方面的任意一种实现方式，根据预设的故障场景列表，确定与所述目标丢帧场景匹配的CPU占用率阈值，以作为所述负载统计阈值。所述电子设备还用于构建所述故障场景列表，所述故障场景列表是基于以下操作得到的：获取目标用户针对电子设备的使用行为所对应的丢帧记录数据和CPU占用信息；根据所述丢帧记录数据中的丢帧时长信息，确定与多个候选丢帧场景中的各所述候选丢帧场景匹配的目标丢帧记录；根据与所述目标丢帧记录关联的所述CPU占用信息，将由所述CPU占用信息指示的CPU占用率阈值，作为与各所述候选丢帧场景匹配的负载统计阈值；与各所述候选丢帧场景匹配的所述负载统计阈值，构成所述故障场景列表，所述目标丢帧场景为多个候选丢帧场景中的任意丢帧场景，所述多个候选丢帧场景包括无丢帧场景、不易感知丢帧场景、明显丢帧场景和严重丢帧场景。

根据第二方面，或者以上第二方面的任意一种实现方式，所述CPU占用信息指示CPU占用率，与各所述候选丢帧场景匹配的所述负载统计阈值包括第一CPU占用率阈值、第二CPU占用率阈值、第三CPU占用率阈值和第四CPU占用率阈值，

所述负载统计阈值是基于以下操作得到的：对基于所述预设时间段内的所述CPU占用率进行由小至大排序；根据由小至大排序的所述CPU占用率，将前第一预设占比的所述CPU占用率中的最大CPU占用率作为所述第一CPU占用率阈值；将前第二预设占比的所述CPU占用率中的最大CPU占用率作为所述第二CPU占用率阈值，所述第二预设占比大于所述第一预设占比；将前第三预设占比的所述CPU占用率中的最大CPU占用率作为所述第三CPU占用率阈值，所述第三预设占比大于所述第二预设占比；将所有CPU占用率中的最大CPU占用率作为所述第四CPU占用率阈值。

根据第二方面，或者以上第二方面的任意一种实现方式，由所述实时负载数据指示的所述CPU资源包括CPU频点、用于执行系统动作的CPU核、是否允许执行系统动作和内存剩余量；所述根据所述实时负载数据和与所述目标丢帧场景匹配的负载统计阈值，对电子设备的CPU资源进行调度，包括：根据与所述目标丢帧场景匹配的所述负载统计阈值和由所述实时负载数据指示的实时CPU占用率，对所述CPU资源进行调度。

根据第二方面，或者以上第二方面的任意一种实现方式，所述根据与所述目标丢帧场景匹配的所述负载统计阈值和由所述实时负载数据指示的实时CPU占用率，对所述CPU资源进行调度，包括：在所述实时CPU占用率大于或等于所述第四CPU占用率阈值的情况下，提高所述CPU频点。

根据第二方面，或者以上第二方面的任意一种实现方式，所述根据与所述目标丢帧场景匹配的所述负载统计阈值和由所述实时负载数据指示的实时CPU占用率，对所述CPU资源进行调度，包括：在所述实时CPU占用率小于所述第四CPU占用率阈值，且大于或等于所述第三CPU占用率阈值的情况下，将所述系统动作置于CPU小核中执行。

根据第二方面，或者以上第二方面的任意一种实现方式，所述根据与所述目标丢帧场景匹配的所述负载统计阈值和由所述实时负载数据指示的实时CPU占用率，对所述CPU资源进行调度，包括：在所述实时CPU占用率小于所述第三CPU占用率阈值，且大于或等于所述第二CPU占用率阈值的情况下，允许执行所述系统动作。

根据第二方面，或者以上第二方面的任意一种实现方式，所述根据与所述目标丢帧场景匹配的所述负载统计阈值和由所述实时负载数据指示的实时CPU占用率，对所述CPU资源进行调度，包括：在所述实时CPU占用率小于所述第二CPU占用率阈值，且大于或等于所述第一CPU占用率阈值的情况下，降低所述CPU频点。

根据第二方面，或者以上第二方面的任意一种实现方式，所述根据与所述目标丢帧场景匹配的所述负载统计阈值和由所述实时负载数据指示的实时CPU占用率，对所述CPU资源进行调度，包括：在所述实时CPU占用率小于所述第一CPU占用率阈值、且所述内存剩余量小于预设内存水线级的情况下，禁止执行所述系统动作。

根据第二方面，或者以上第二方面的任意一种实现方式，所述应用程序包括使用频次高于预设频次阈值的目标应用。

根据第二方面，或者以上第二方面的任意一种实现方式，获取与所述应用程序关联的基于所述滑动场景的所述实时负载数据，包括：获取与所述应用程序关联的以下数据中的至少之一，以作为所述实时负载数据：GPU负载信息、内存使用信息、函数调用信息和堆栈信息。

根据第二方面，或者以上第二方面的任意一种实现方式，所述电子设备还用于执行如下步骤：根据所述实时负载数据和与所述目标丢帧场景匹配的所述负载统计阈值，对电子设备的以下资源中的至少之一进行调度：GPU频点、线程运行核心、应用显示帧率和屏幕刷新率。

第二方面以及第二方面的任意一种实现方式分别与第一方面以及第一方面的任意一种实现方式相对应。第二方面以及第二方面的任意一种实现方式所对应的技术效果可参见上述第一方面以及第一方面的任意一种实现方式所对应的技术效果，此处不再赘述。

第三方面，本申请实施例提供了一种计算机可读介质，用于存储计算机程序，该计算机程序包括用于执行第一方面或第一方面的任意可能的实现方式中的方法的指令。

第四方面，本申请实施例提供了一种计算机程序，该计算机程序包括用于执行第一方面或第一方面的任意可能的实现方式中的方法的指令。

第五方面，本申请实施例提供了一种芯片，该芯片包括处理电路、收发管脚。其中，该收发管脚、和该处理电路通过内部连接通路互相通信，该处理电路执行第一方面或第一方面的任一种可能的实现方式中的方法，以控制接收管脚接收信号，以控制发送管脚发送信号。

附图说明

图1为示例性示出一种应用场景示意图；

图2为示例性示出的电子设备的结构示意图；

图3为示例性示出的电子设备的软件结构框图；

图4为本申请实施例提供的滑动丢帧检测过程的各模块的交互示意图；

图5为本申请实施例提供的故障场景库文件的示意图；

图6A为本申请实施例提供的丢帧记录数据的示意图；

图6B为本申请实施例提供的CPU占用率阈值的示意图；

图7为本申请实施例提供的CPU资源调度过程的各模块的交互示意图；

图8为本申请实施例提供的一种CPU资源调度过程的流程图；

图9为本申请实施例提供的另一CPU资源调度过程的流程图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。

本申请实施例的说明书和权利要求书中的术语“第一”和“第二”等是用于区别不同的对象，而不是用于描述对象的特定顺序。例如，第一目标对象和第二目标对象等是用于区别不同的目标对象，而不是用于描述目标对象的特定顺序。

在本申请实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。

在本申请实施例的描述中，除非另有说明，“多个”的含义是指两个或两个以上。例如，多个处理单元是指两个或两个以上的处理单元；多个系统是指两个或两个以上的系统。

如图1为示例性示出的一种应用场景的示意图，示例性的，如图1中的（1）所示，响应于用户对微信应用图标101的点击操作，微信应用显示包括“朋友圈”功能的页面，如图1中的（2）所示。响应于用户对“朋友圈”功能的点击操作，微信应用显示“朋友圈”界面，如图1中的（3）所示。响应于用户在“朋友圈”界面中的滑动操作， “朋友圈”界面内容发生更新，如图1中的（4）所示。滑动操作例如可以包括单向滑动、拖动滑动、多向滑动、双指滑动等操作。

以微信应用中的界面显示为例，响应于用户在应用界面中的滑动操作，APP（Application，应用程序）通过应用程序框架层的视图系统，调用系统库中的图像渲染库对图像进行绘制渲染。APP将绘制渲染后的图像发送至图像合成系统的缓存队列，通过系统库中的图像合成库将绘制渲染后的图像合成为UI（Userlnterface，用户界面）。图像合成系统通过内核层的显示驱动，使得电子设备的屏幕显示UI，UI例如包括APP图标、APP功能页面、动效、人机交互等。

需要说明的是，电子设备通常基于同一时间基准（例如，硬件垂直同步信号，HW-Vsync）对图像的绘制、渲染、合成和屏幕刷新等操作进行同步，以此保证显示的流畅性，减少出现显示掉帧等现象。HW-Vsync为周期性信号，HW-Vsync可以根据屏幕刷新率进行设置。

以屏幕刷新率为120Hz为例，为确保显卡输出帧率与屏幕刷新率同步，保持画面显示的连续性和稳定性，HW-Vsync周期可以是1000/120=8.3ms或其倍数。假设按照时间顺序，电子设备显示的内容依次对应于帧1、帧2、帧3、帧4和帧5。以帧3为例，假设因系统负载过大，图像渲染库无法在8.3ms内完成帧3的绘制渲染。电子设备在进行内容显示时，帧2显示时长增加，从而导致电子设备出现卡顿，用户体验下降。

图像的绘制渲染时长与电子设备的系统负载状态有关，当系统负载较大时，图像的绘制渲染时长增加；当系统负载较小时，图像的绘制渲染时长缩短。系统负载状态的波动，可能引发UI显示出现掉帧的现象，降低用户体验。另外，在电子设备的CPU性能不足或者显卡显存不足的场景下，可能出现电子设备不足以负荷画面动态显示的刷新频率的情况，帧率过低可能造成画面停滞的现象，进而出现UI显示的掉帧问题，降低应用使用的流畅性，用户体验劣化。

如图2为示例性示出的电子设备100的结构示意图。可选地，电子设备100可以称为终端，也可以称为终端设备，具体产品形态可以是智能终端，如手机、平板、DV、智能手表、智能穿戴设备、便携电脑、笔记本电脑、智能音箱等产品。具体地，本申请涉及的功能模块可以部署于相关设备的DSP芯片上，具体可以是其中的应用程序或软件。可以通过软件安装或升级，以及通过硬件的调用配合，提供一种任务处理功能。

应该理解的是，图2所示的电子设备100仅是电子设备的一个范例，并且电子设备100可以具有比图中所示的更多的或者更少的部件，可以组合两个或多个的部件，或者可以具有不同的部件配置。图2中所示出的各种部件可以在包括一个或多个信号处理和/或专用集成电路在内的硬件、软件、或硬件和软件的组合中实现。

电子设备100可以包括：处理器110、外部存储器接口120、内部存储器121、通用串行总线（universal serial bus，USB）接口130、充电管理模块140、电源管理模块141、电池142、天线1、天线2、移动通信模块150、无线通信模块160、音频模块170、传感器模块180、按键190、马达191、指示器192、摄像头193、显示屏194以及用户标识模块（subscriberidentification module，SIM）卡接口195等。其中传感器模块180可以包括压力传感器、陀螺仪传感器、加速度传感器、温度传感器、运动传感器、气压传感器、磁传感器、距离传感器、接近光传感器、指纹传感器、触摸传感器、环境光传感器、骨传导传感器等。

处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器（application processor，AP）、调制解调处理器、图形处理器（graphics processingunit，GPU）、图像信号处理器（image signal processor，ISP）、控制器、存储器、视频编解码器、数字信号处理器（digital signal processor，DSP）、基带处理器和/或神经网络处理器（neural-network processing unit，NPU）等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。

其中，控制器可以是电子设备100的神经中枢和指挥中心。控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。

处理器110中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器110中的存储器为高速缓冲存储器。

电子设备100的无线通信功能可以通过天线1、天线2、移动通信模块150、无线通信模块160、调制解调处理器以及基带处理器等实现。

天线1和天线2用于发射和接收电磁波信号。电子设备100中的每个天线可用于覆盖单个或多个通信频带。不同的天线还可以复用，以提高天线的利用率。

移动通信模块150可以提供应用在电子设备100上的包括2G/3G/4G/5G等无线通信的解决方案。移动通信模块150可以包括至少一个滤波器、开关、功率放大器、低噪声放大器（low noise amplifier，LNA）等。

无线通信模块160可以提供应用在电子设备100上的包括无线局域网（wirelesslocal area networks，WLAN）（如无线保真（wireless fidelity，Wi-Fi）网络）、蓝牙（bluetooth，BT）、全球导航卫星系统（global navigation satellite system，GNSS）、调频（frequency modulation，FM）、近距离无线通信技术（near field communication，NFC）、红外技术（infrared，IR）等无线通信的解决方案。

在一些实施例中，电子设备100的天线1和移动通信模块150耦合，天线2和无线通信模块160耦合，使得电子设备100可以通过无线通信技术与网络以及其他设备通信。

电子设备100通过GPU、显示屏194以及应用处理器等实现显示功能。处理器110可包括一个或多个GPU，其执行程序指令以生成或改变显示信息。

显示屏194用于显示图像、视频等。显示屏194包括显示面板。在一些实施例中，电子设备100可以包括1个或N个显示屏194，N为大于1的正整数。

电子设备100可以通过ISP、摄像头193、视频编解码器、GPU、显示屏194以及应用处理器等实现拍摄功能。

ISP 用于处理摄像头193反馈的数据。例如，拍照时，打开快门，光线通过镜头被传递到摄像头感光元件上，光信号转换为电信号，摄像头感光元件将电信号传递给ISP处理，转化为肉眼可见的图像。

摄像头193用于捕获静态图像或视频。物体通过镜头生成光学图像投射到感光元件。感光元件可以是电荷耦合器件(charge coupled device，CCD)或互补金属氧化物半导体(complementary metal-oxide-semiconductor，CMOS)光电晶体管。感光元件把光信号转换成电信号，之后将电信号传递给ISP转换成数字图像信号。ISP将数字图像信号输出到DSP加工处理。DSP将数字图像信号转换成标准的RGB、YUV等格式的图像信号。在一些实施例中，电子设备100可以包括1个或N个摄像头193，N为大于1的正整数。

其中，摄像头193可以位于电子设备的边缘区域，可以为屏下摄像头，也可以是可升降的摄像头。摄像头193可以包括后置摄像头，还可以包括后置摄像头。本申请实施例对摄像头193的具体位置和形态不予限定。电子设备100可以包括一种或多种焦段的摄像头，例如不同焦段的摄像头可以包括长焦摄像头、广角摄像头、超广角摄像头或全景摄像头等。

外部存储器接口120可以用于连接外部存储卡，例如Micro SD卡，实现扩展电子设备100的存储能力。外部存储卡通过外部存储器接口120与处理器110通信，实现数据存储功能。

内部存储器121可以用于存储计算机可执行程序代码，所述可执行程序代码包括指令。处理器110通过运行存储在内部存储器121的指令，从而执行电子设备100的各种功能应用以及数据处理，例如使得电子设备100实现本申请实施例中的负载调节方法。内部存储器121可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统，至少一个功能所需的应用程序（比如声音播放功能、图像播放功能等）等。存储数据区可存储电子设备100使用过程中所创建的数据（比如音频数据、电话本等）等。此外，内部存储器121可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、通用闪存存储器（universal flash storage，UFS）等。

电子设备100可以通过音频模块170以及应用处理器等实现音频功能。例如音乐播放、录音等。

音频模块170用于将数字音频信息转换成模拟音频信号输出，也用于将模拟音频输入转换为数字音频信号。音频模块170还可以用于对音频信号编码和解码。在一些实施例中，音频模块170可以设置于处理器110中，或将音频模块170的部分功能模块设置于处理器110中。

触摸传感器，也称“触控面板”。触摸传感器可以设置于显示屏194，由触摸传感器与显示屏194组成触摸屏，也称“触控屏”。触摸传感器用于检测作用于其上或附近的触摸操作。触摸传感器可以将检测到的触摸操作传递给应用处理器，以确定触摸事件类型。可以通过显示屏194提供与触摸操作相关的视觉输出。

压力传感器用于感受压力信号，可以将压力信号转换成电信号。在一些实施例中，压力传感器可以设置于显示屏194。电子设备100也可以根据压力传感器的检测信号计算触摸的位置。

陀螺仪传感器可以用于确定电子设备100的运动姿态。在一些实施例中，可以通过陀螺仪传感器确定电子设备100围绕三个轴（即，x、y和z轴）的角速度。

加速度传感器可检测电子设备100在各个方向上（一般为三轴）加速度的大小。当电子设备100静止时加速度传感器可检测出重力的大小及方向。加速度传感器还可以用于识别电子设备姿态，应用于横竖屏切换、计步器等应用。

按键190包括开机键（或称电源键）、音量键等。按键190可以是机械按键。也可以是触摸式按键。电子设备100可以接收按键输入，产生与电子设备100的用户设置以及功能控制有关的键信号输入。

电子设备100的软件系统可以采用分层架构、事件驱动架构、微核架构、微服务架构或云架构。本发明实施例以分层架构的Android系统为例，示例性说明电子设备100的软件结构。

如图3为示例性示出的电子设备100的软件结构框图，电子设备100的分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，将Android系统分为四层，从上至下分别为应用程序层、应用程序框架层、安卓运行时(Android runtime)、系统层和内核层。

应用程序层可以包括一系列应用程序包，如图3所示，应用程序包可以包括相机、图库、微信、短视频、新闻等应用程序。

应用程序框架层为应用程序层的应用程序提供应用编程接口(ApplicationProgramming Interface，API)和编程框架，包括各种组件和服务来支持开发者的安卓开发。应用程序框架层包括一些预先定义的函数。如图3所示，应用程序框架层可以包括视图系统、窗口管理器、资源管理器、内容提供器、通知管理器、性能雷达和CPU资源调度模块等，性能雷达例如可以包括滑动状态检测模块、滑动丢帧检测模块、滑动丢帧统计模块和CPU负载检测模块。

窗口管理器用于管理窗口程序。窗口管理器可以获取显示屏大小、判断是否有状态栏、锁定屏幕、截取屏幕等。

内容提供器用来存放和获取数据，并使这些数据可以被应用程序访问。数据可以包括视频、图像、音频、拨打和接听的电话、浏览历史和书签、电话簿等。

资源管理器可以为应用程序提供各种资源，比如本地化字符串、图标、图片、布局文件、视频文件等等。

通知管理器使应用程序可以在状态栏中显示通知信息，可以用于传达告知类型的消息，可以短暂停留后自动消失，无需用户交互。比如通知信息被用于告知下载完成、消息提醒等。通知信息还可以是以图表或者滚动条文本形式出现在系统顶部状态栏的通知，例如后台运行的应用程序的通知，还可以是以对话窗口形式出现在屏幕上的通知。例如在状态栏提示文本信息、发出提示音、电子设备振动、指示灯闪烁等。

滑动状态检测模块可用于检测电子设备中的滑动事件（MOVE），滑动事件例如可由触摸点按下、触摸点移动和触摸点释放等动作实现。滑动事件还可以派生出其他事件，例如fling事件。例如，用户在拖住UI元素快速滑动之后抬手，会派生出一个 fling事件，UI元素例如可在抬手之后基于初始速度做减速运动。以“朋友圈”界面显示为例，在用户滑动手势释放（TOUCH_UP）后，“朋友圈”界面不会马上停止滑动，而是转换为fling事件继续执行一小段时间。因此，滑动状态检测模块可用于检测滑动事件的触摸点状态（按下、松开）、触摸点移动（移动的距离大小、速度等）、触摸点数量、事件因素（长按、短按等）。

视图系统响应于电子设备中的滑动事件，确定视图布局变化内容，并将视图布局变化内容传递至绘制合成模块进行绘制、渲染、合成等处理，生成帧图像。绘制合成模块在基于视图布局变化内容合成帧图像后，将帧处理时长传递至滑动丢帧检测模块，滑动丢帧检测模块根据帧处理时长判断是否发生滑动丢帧，以及将滑动丢帧判断结果传递至滑动丢帧统计模块。

滑动丢帧统计模块用于基于滑动丢帧判断结果，统计应用程序中的丢帧界面、丢帧次数、丢帧发生时刻、单次丢帧时长、丢帧平均耗时等信息，得到滑动丢帧统计结果。

CPU负载检测模块用于检测电子设备的CPU负载信息，CPU负载信息例如可以包括CPU核心频点数量、当前CPU最大运行频率、当前CPU最小运行频率、CPU占用率等信息。CPU负载信息用于指示CPU的负载情况，CPU负载信息可以从内核调度模块读取。

CPU资源调度模块用于根据滑动丢帧统计结果和CPU负载信息，进行CPU负载调度，CPU负载调度例如包括CPU调频、CPU核切换等操作。

系统层包括系统库和安卓运行时（Android Runtime）。系统库可以包括多个功能模块，例如图像渲染库、图像合成库、函数库和媒体库等。安卓运行时包括核心库和虚拟机，安卓运行时负责安卓系统的调度和管理。核心库包含两部分：一部分是java语言需要调用的功能函数，另一部分是安卓的核心库。应用程序层和应用程序框架层运行在虚拟机中，虚拟机将应用程序层和应用程序框架层的java文件执行为二进制文件。虚拟机用于执行对象生命周期的管理、堆栈管理、线程管理、安全和异常的管理以及垃圾回收等功能。

可以理解的是，图3示出的系统框架层、系统库与运行时层包含的部件，并不构成对电子设备100的具体限定。在本申请另一些实施例中，电子设备100可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。

内核层是硬件和上述软件层之间的层，内核层中可以包括故障场景库文件。

下面结合图4所示的各模块的交互示意图，对滑动丢帧检测过程进行示意说明。

如图4所示，用户可以通过触摸屏与电子设备进行交互。响应于用户的手指接触触摸屏，触摸屏将包含电容值的touch事件（触摸事件）信息传递至内核层中的触摸屏驱动，由触摸屏驱动根据电容值，确定touch事件的触摸点状态（按下、松开）、触摸点移动（移动的距离大小、速度等）、触摸点数量、事件因素（长按、短按等）等信息，进而确定touch事件类型。

touch事件类型例如可以包括按压事件、移动事件、移动抬起事件、取消事件等。例如，当用户将手指按压在触摸屏的控件区域时，触摸屏驱动确定touch事件类型为按压事件。当用户将手指在触摸屏的控件区域中滑动时，触摸屏驱动确定touch事件类型为移动事件。当用户将手指在触摸屏的控件区域中滑动后抬起时，触摸屏驱动确定touch事件类型为移动抬起事件。当用户将手指移出触摸屏的控件区域时，触摸屏驱动确定touch事件类型为取消事件。

触摸屏驱动将touch事件类型传递给滑动状态检测模块，滑动状态检测模块根据touch事件类型确定APP（应用程序）是否处于滑动场景，得到滑动检测结果。例如，响应于touch事件类型为移动事件或移动抬起事件，滑动状态检测模块确定APP处于滑动场景。滑动状态检测模块将touch事件类型和滑动检测结果传递给APP，由APP确定与touch事件对应的应用控件，由应用控件基于touch事件确定视图布局变化内容。APP将视图布局变化内容传递给绘制合成模块，由绘制合成模块进行图像的绘制、渲染、合成等处理，生成帧图像。

绘制合成模块将生成帧图像过程中的帧处理时长传递给滑动丢帧检测模块，由滑动丢帧检测模块根据帧处理时长，确定与APP关联的基于滑动场景的丢帧检测结果。丢帧检测结果例如可以包括丢帧界面、丢帧次数、丢帧发生时刻、单次丢帧时长、丢帧平均耗时等信息。

滑动丢帧检测模块将丢帧检测结果发送给滑动丢帧统计模块，由滑动丢帧统计模块对接收到的丢帧检测结果进行统计，得到丢帧统计结果。CPU负载检测模块可以检测帧图像生成过程中的CPU占用信息，CPU占用信息可以与移动事件的被触发过程或者与移动抬起事件被触发后的预设时间段相对应。故障场景库文件生成模块根据丢帧统计结果和CPU占用信息，生成故障场景库文件。

示例性地，滑动状态检测模块、滑动丢帧检测模块和滑动丢帧统计模块可设置于应用程序框架层的性能雷达中，性能雷达可以提供系统监视器功能，可用于监测应用程序的CPU占用率、内存使用率、网络活动和存储使用情况等信息。

作为一种可选的实施例，在通过滑动丢帧检测模块确定是否存在滑动丢帧的过程中，可以利用滑动丢帧检测模块，在应用程序的预设位置埋点，利用监控线程获取帧图像绘制过程中的帧处理时长，以及监控帧处理时长是否超过预设时长阈值。在帧处理时长超过预设时长阈值的情况下，利用滑动丢帧检测模块，通过所埋的点获取应用程序预设位置的页面信息。此外，可以利用采集线程采集应用程序及终端的运行记录，运行记录例如包括应用使用率、应用显示帧率、屏幕刷新率等信息。由滑动丢帧检测模块对页面信息、帧处理时长、运行记录进行聚合分析，得到与应用程序关联的基于滑动场景的丢帧检测数据。

例如，可以利用滑动丢帧检测模块，在应用程序的列表滑动、核心页面、动画切换、Fragment（片段）栈等位置进行埋点。针对动态页面，可以利用滑动丢帧检测模块，获取每帧动态页面的开始绘制时间和结束绘制时间，根据开始绘制时间和结束绘制时间，得到帧图像绘制过程中的帧处理时长。针对静态页面，可以利用滑动丢帧检测模块，获取前后两帧的静态页面的绘制时间间隔，根据绘制时间间隔得到帧图像绘制过程中的帧处理时长。

作为另一种可选的实施例，可以通过滑动丢帧检测模块监听应用程序主线程的开始运行时间，以及确定当前时间与开始运行时间之间的时间差值是否超过预设时间阈值。在时间差值超过预设时间阈值的情况下，确定应用程序发生滑动丢帧。或者，可以通过与应用程序匹配的屏幕刷新定时器，监听帧图像的渲染帧开始时间。在当前时间与渲染帧开始时间之间的时间差值超过预设时间阈值的情况下，确定应用程序发生滑动丢帧。

另外，可以通过滑动丢帧检测模块监听应用程序主线程的运行状态，在应用程序主线程的运行状态为等待事件阶段的情况下，确定应用程序发生滑动丢帧。

如图5所示为故障场景库文件的示意图，如图5所示，故障场景库文件可以包括无丢帧场景列表、不易感知丢帧场景列表、明显丢帧场景列表和严重丢帧场景列表。

无丢帧场景列表包括[无丢帧界面1、无丢帧界面2、…] [CPU占用率1a、CPU占用率2a、CPU占用率3a、CPU占用率4a]，不易感知丢帧场景列表包括[不易感知丢帧界面1、不易感知丢帧界面2、…] [CPU占用率1b、CPU占用率2b、CPU占用率3b、CPU占用率4 b]，明显丢帧场景列表包括[明显丢帧界面1、明显丢帧界面2、…] [CPU占用率1c、CPU占用率2c、CPU占用率3c、CPU占用率4c]，严重丢帧场景列表包括[严重丢帧界面1、严重丢帧界面2、…] [CPU占用率1d、CPU占用率2d、CPU占用率3d、CPU占用率4d]。

故障场景库文件中的丢帧界面信息指示高频使用应用的滑动丢帧界面。在进行CPU资源调度时，可以根据故障场景库文件中的丢帧界面信息，确定应用程序的丢帧界面是否属于高频使用应用的滑动丢帧界面。当然，也可以根据针对应用程序的启动次数，确定应用程序的丢帧界面是否属于高频使用应用的滑动丢帧界面。一般来说，在高频使用应用的界面显示出现滑动丢帧的情况下，对电子设备的CPU资源进行调度。

基于目标用户在预设时间段内针对电子设备的使用行为，可以通过滑动丢帧检测模块获取使用行为所对应的丢帧记录数据，使用行为例如包括针对应用界面的滑动操作。通过滑动丢帧统计模块，对基于预设时间段内的丢帧记录数据进行统计，得到丢帧统计结果。丢帧统计结果例如包括对丢帧界面、丢帧次数、丢帧发生时刻、单次丢帧时长、丢帧平均耗时等信息的统计结果。此外，通过CPU负载检测模块获取使用行为所对应的CPU占用信息，CPU占用信息例如可以包括CPU占用率、CPU程序占比等信息。预设时间段例如可以是最近N天，N例如可以是7。基于预设时间段内的丢帧记录数据和CPU占用信息为非实时数据，非实时数据可用于构建故障场景库文件。

示例性地，通过滑动丢帧统计模块，根据丢帧记录数据中的丢帧时长信息和预设的多个丢帧时长阈值，确定与各丢帧时长阈值匹配的目标丢帧记录。目标丢帧记录的数量构成了丢帧记录数目，丢帧记录数目指示了与对应丢帧时长阈值匹配的丢帧频次。根据各候选丢帧场景与丢帧时长阈值之间的预设映射关系，确定由丢帧记录数目指示的目标丢帧场景，目标丢帧场景可以是多个候选丢帧场景中的任意丢帧场景。

多个候选丢帧场景例如包括无丢帧场景、不易感知丢帧场景、明显丢帧场景和严重丢帧场景。各候选丢帧场景可以与不同的丢帧时长阈值、丢帧频次阈值相对应。

例如，无丢帧场景所对应的丢帧时长阈值为25ms，与丢帧时长阈值匹配的丢帧频次阈值为0次。即，在单次丢帧时长位于25ms以上的丢帧次数为0次的情况下，touch事件所对应的应用界面处于无丢帧场景。

不易感知丢帧场景所对应的丢帧时长阈值为25 ms、58ms，与丢帧时长阈值匹配的丢帧频次阈值占总丢帧次数的比例为1。即，在单次丢帧时长位于25~58ms之间的丢帧次数占总丢帧次数的比例为1的情况下，touch事件所对应的应用界面处于不易感知丢帧场景。

严重丢帧场景所对应的丢帧时长阈值为133ms，与丢帧时长阈值匹配的丢帧频次阈值为3次。即，在单次丢帧时长位于133ms以上的总丢帧次数超过3次的情况下，touch事件所对应的应用界面处于严重丢帧场景。

明显丢帧场景所对应的单次丢帧时长位于58~133ms之间，除上述情况以外的其他情况属于明显丢帧场景。

如图6A所示为丢帧记录数据的示意图，如图6A所示，关于针对D应用新闻内容的滑动操作，单次丢帧时长位于25ms以上的总丢帧次数为0次，针对D应用新闻内容的滑动操作对应无丢帧场景。关于针对B应用首页界面的滑动操作，单次丢帧时长位于133ms以上的总丢帧次数为3次，针对B应用首页界面的滑动操作对应严重丢帧场景。

关于针对C应用影视界面的滑动操作，单次丢帧时长位于25~58ms之间的丢帧次数占总丢帧次数的比例为1，针对C应用影视界面的滑动操作对应不易感知丢帧场景。关于针对A应用功能界面的滑动操作、针对E应用搜索页面的滑动操作、针对F应用推荐页面的滑动操作，单次丢帧时长位于58~133ms之间的总丢帧次数大于0，并且单次丢帧时长位于133ms以上的总丢帧次数小于3，因此，针对A应用功能界面的滑动操作、针对E应用搜索页面的滑动操作、针对F应用推荐页面的滑动操作对应明显丢帧场景。

继续结合图5进行说明，通过故障场景库文件生成模块，根据与目标丢帧记录关联的CPU占用信息，确定与各候选丢帧场景匹配的CPU占用率阈值，CPU占用率阈值构成与对应候选丢帧场景匹配的负载统计阈值。例如，明显丢帧场景列表中的[CPU占用率1c、CPU占用率2c、CPU占用率3c、CPU占用率4c、]，构成与明显丢帧场景匹配的CPU占用率阈值。

与任意候选丢帧场景匹配的负载统计阈值例如包括第一CPU占用率阈值（load1）、第二CPU占用率阈值（load2）、第三CPU占用率阈值（load3）和第四CPU占用率阈值（load4）。

一种示例方式，针对多个候选丢帧场景中的各候选丢帧场景，通过故障场景库文件生成模块，将与各候选丢帧场景匹配的CPU占用率进行排序，CPU占用率与目标用户针对电子设备的使用行为相对应。如图6B所示为CPU占用率阈值的示意图，如图6B所示，基于从小至大排序的CPU占用率，将前第一预设占比的CPU占用率中的最大CPU占用率作为load1，第一预设占比例如可以是25%。将前第二预设占比的CPU占用率中的最大CPU占用率作为load2，第二预设占比例如可以是50%。将前第三预设占比的CPU占用率中的最大CPU占用率作为load3, 第三预设占比例如可以是75%。将所有使用行为所对应的最大CPU占用率作为load4。

即，基于从小至大排序的CPU占用率，前25%的CPU占用率低于load1，接下来25%的CPU占用率位于load1与load2之间，再接下来25%的CPU占用率位于load2与load3之间，最大CPU占用率构成load4。

下面结合图7所示的各模块的交互示意图，对CPU资源调度过程进行示意说明。

如图7所示，滑动丢帧检测模块根据帧处理时长，确定丢帧检测结果。示例性地，在帧处理时长超过预设时长阈值的情况下，可能导致在HW-Vsync（硬件垂直同步信号）到达时，无法绘制完成当前touch事件所对应的帧图像，从而导致滑动丢帧。例如，在单次丢帧时长大于25ms的情况下，滑动丢帧检测模块上报滑动丢帧事件。在单次丢帧时长不超过25ms的情况下，滑动丢帧检测模块判断滑动丢帧事件为不易被感知的偶然事件，进而不上报滑动丢帧事件。

滑动丢帧检测模块将丢帧检测结果传递给场景解析模块，丢帧检测结果构成与APP关联的基于滑动场景的丢帧检测数据，丢帧检测结果例如可以包括丢帧界面、丢帧次数、丢帧发生时刻、单次丢帧时长、丢帧平均耗时等信息。

由场景解析模块根据预设的多个丢帧时长阈值和丢帧检测结果中的丢帧时长信息，确定与当前touch事件匹配的目标丢帧场景。示例性地，由场景解析模块根据预设的多个丢帧时长阈值和丢帧检测结果中的丢帧时长信息，确定与各丢帧时长阈值匹配的丢帧记录数目。根据与各丢帧时长阈值匹配的丢帧记录数目，确定由丢帧记录数目指示的目标丢帧场景。目标丢帧场景可以是多个候选丢帧场景中的任意丢帧场景，多个候选丢帧场景可以包括无丢帧场景、不易感知丢帧场景、明显丢帧场景和严重丢帧场景。

场景解析模块将当前touch事件所属的目标丢帧场景信息发送给CPU资源调度模块，由CPU资源调度模块根据帧图像绘制过程中的CPU占用信息、当前touch事件所属的目标丢帧场景和故障场景库文件，对CPU资源进行调度。帧图像绘制过程中的CPU占用信息，构成与APP关联的基于滑动场景的实时负载数据。

作为一种可选的实施例，由场景解析模块根据故障场景库文件和当前touch事件所属的目标丢帧场景，确定与目标丢帧场景匹配的CPU占用率阈值。故障场景库文件指示与多个候选丢帧场景中的各候选丢帧场景匹配的CPU占用率阈值，当前touch事件所属的目标丢帧场景为多个候选丢帧场景中的任意候选丢帧场景。

由CPU资源调度模块根据CPU占用率阈值和帧图像绘制过程中的CPU占用信息，对CPU资源进行调度。例如，对分配给APP的CPU频点、用于执行系统动作的CPU核、是否允许执行系统动作和内存剩余量等资源进行调度。由CPU资源调度模块将调度后的CPU资源信息传递给绘制合成模块，以使绘制合成模块基于调度后的CPU资源进行帧图像绘制。

下面结合图8所示的流程图，对一种CPU资源调度过程进行示意说明。如图8所示，CPU资源调度过程可以包括操作S110~ S130。

在操作S110，电子设备获响应于应用程序的界面显示处于滑动场景，获取与应用程序关联的丢帧检测数据和实时负载数据。

在操作S120，电子设备基于丢帧检测数据，确定应用程序所属的目标丢帧场景。

在操作S130，电子设备根据实时负载数据和与目标丢帧场景匹配的负载统计阈值，对电子设备的CPU资源进行调度。

示例性地，通过电子设备中的滑动状态检测模块，检测基于应用程序被触发的触摸事件，在触摸事件为移动事件或移动抬起事件的情况下，确定应用程序的界面显示处于滑动场景。应用程序包括使用频次高于预设频次阈值的目标应用，使用频次例如可由针对应用程序的启动次数指示。

响应于应用程序的界面显示处于滑动场景，通过滑动丢帧检测模块，获取与应用程序关联的包含丢帧时长信息的丢帧记录数据，以作为丢帧检测数据。丢帧记录数据与移动事件的被触发过程和/或与移动抬起事件被触发后的预设时间段相对应。丢帧记录数据例如包括丢帧界面、丢帧次数、丢帧发生时刻、单次丢帧时长、丢帧平均耗时等信息。

通过CPU负载检测模块，获取与应用程序关联的CPU占用信息，以作为实时负载数据。CPU占用信息与移动事件的被触发过程和/或与移动抬起事件被触发后的预设时间段相对应。CPU占用信息例如可以包括CPU占用率、CPU程序占比等信息。

通过场景解析模块，根据丢帧检测数据中的丢帧时长信息和预设的多个丢帧时长阈值，确定与各丢帧时长阈值匹配的丢帧记录数目，丢帧记录数目指示与对应丢帧时长阈值匹配的丢帧频次。根据与各丢帧时长阈值匹配的丢帧记录数目，确定由丢帧记录数目指示的目标丢帧场景。目标丢帧场景可以是多个候选丢帧场景中的任意丢帧场景，多个候选丢帧场景例如包括无丢帧场景、不易感知丢帧场景、明显丢帧场景和严重丢帧场景，各候选丢帧场景分别对应匹配的丢帧时长阈值和丢帧频次阈值。

通过CPU资源调度模块，根据应用程序所属的目标丢帧场景和预设的故障场景库文件，确定与目标丢帧场景匹配的CPU占用率阈值，以作为负载统计阈值。故障场景库文件包括多个候选丢帧场景列表，多个候选丢帧场景例如包括无丢帧场景、不易感知丢帧场景、明显丢帧场景和严重丢帧场景，各候选丢帧场景分别对应匹配的CPU占用率阈值。

通过CPU资源调度模块，根据实时负载数据和与目标丢帧场景匹配的负载统计阈值，对电子设备的CPU资源进行调度。CPU资源例如包括CPU频点、用于执行系统动作的CPU核、是否允许执行系统动作和内存剩余量等资源。示例性地，根据与目标丢帧场景匹配的CPU占用率阈值和由实时负载数据指示的实时CPU占用率，对电子设备的CPU频点、用于执行系统动作的CPU核、是否允许执行系统动作和内存剩余量等资源进行调度。

下面结合图9所示的流程图，对另一CPU资源调度过程进行示意说明。如图9所示，CPU资源调度过程可以包括操作S201~ S216。

在操作S201，由滑动状态检测模块检测用户针对应用程序的触摸操作。

针对应用程序的触摸操作例如可以包括按压事件、移动事件、移动抬起事件、取消事件等。

在操作S202，由滑动状态检测模块根据触摸事件类型，确定应用程序的界面显示是否处于滑动场景。若是，执行操作S204，以及若否，执行操作S203。

在触摸事件类型为移动事件或移动抬起事件的情况下，确定应用程序的界面显示处于滑动场景。

在操作S203，利用CPU资源调度模块，基于预设长期调控策略进行CPU资源调度。

在操作S204，由滑动丢帧检测模块获取与应用程序关联的丢帧检测数据。

示例性地，利用滑动丢帧检测模块，获取与应用程序关联的包含丢帧时长信息的丢帧记录数据，以作为丢帧检测数据。丢帧记录数据例如可以包括丢帧界面、丢帧次数、丢帧发生时刻、单次丢帧时长、丢帧平均耗时等信息。

在操作S205，由场景分析模块根据丢帧检测数据，确定应用程序所属的目标丢帧场景。

示例性地，利用场景分析模块，根据预设的多个丢帧时长阈值和丢帧记录数据中的丢帧时长信息，确定与各丢帧时长阈值匹配的丢帧记录数目。根据与各丢帧时长阈值匹配的丢帧记录数目，确定由丢帧记录数目指示的目标丢帧场景。目标丢帧场景可以是多个候选丢帧场景中的任意丢帧场景，多个候选丢帧场景包括例如无丢帧场景、不易感知丢帧场景、明显丢帧场景和严重丢帧场景。

在操作S206，由CPU负载检测模块获取与应用程序关联的实时负载数据。

示例性的，利用CPU负载检测模块，获取基于滑动场景的CPU占用信息，以作为与应用程序关联的实时负载数据。

接下来，利用CPU资源调度模块，根据应用程序所属的目标丢帧场景和预设的故障场景列表，确定与目标丢帧场景匹配的负载统计阈值。以及，根据实时负载数据和与目标丢帧场景匹配的负载统计阈值，对电子设备的CPU资源进行调度。

例如，可以利用CPU资源调度模块根据目标丢帧场景和故障场景列表，确定与目标丢帧场景匹配的CPU占用率阈值，以作为负载统计阈值。以目标丢帧场景为不易感知丢帧场景为例进行说明，明显丢帧场景列表中包括第一CPU占用率阈值（load1）、第二CPU占用率阈值（load2）、第三CPU占用率阈值（load3）和第四CPU占用率阈值（load4），load1＜load2＜load3＜load4。

具体地，在操作S207，确定由实时负载数据指示的实时CPU占用率是否小于load4，若是，执行操作S209，以及若否，执行操作S208。

在操作S208，通过CPU资源调度模块提高CPU频点。

CPU为时钟驱动系统，其负载能力受限于时钟频率。CPU频率越高，单位时间内所能处理的指令数量越多，CPU负载能力越强。

在操作S209，确定实时CPU占用率是否小于load3，若是，执行操作S211，以及若否，执行操作S210。

在操作S210，通过CPU资源调度模块强制将系统动作置于CPU小核中执行。

示例性地，CPU小核所对应的核心信息为0-3，CPU大核所对应的核心信息为4-7，

CPU小核的计算能力低于CPU大核的计算能力。

安卓系统中的系统动作（system actions）可以是预先定义的操作或事件，可以由应用程序或系统本身触发，以用于启动、停止或执行应用程序之间的交互。常见的系统动作例如包括ACTION_VIEW：打开指定的 URI，例如可以是网址、文件路径等；ACTION_SEND：发送数据给其他应用程序，例如可以是文本、图片、音频、视频等；ACTION_PICK：从系统提供的数据中选择某个条目，例如选择联系人或图片等。

在操作S211，确定实时CPU占用率是否小于load2，若是，执行操作S212，以及若否，执行操作S213。

在操作S212，通过CPU资源调度模块允许执行系统动作。

在操作S213，确定实时CPU占用率是否小于load1，若是，执行操作S215，以及若否，执行操作S214。

在操作S214，通过CPU资源调度模块降低CPU频点。

在操作S215，确定内存剩余量是否小于预设内存水线级，若是，执行操作S216，否则结束流程。内存水线级例如可以是第4级水线。

在操作S216，通过CPU资源调度模块禁止执行系统动作。

示例性地，在通过CPU资源调度模块对电子设备的CPU资源进行调度时，还可以将CPU频率调整为目标频率。或者，可以基于预设检测周期检测CPU的应用程序占比，针对应用程序占比大于预设占比阈值的其他应用，确定其他应用的优先级是否为高优先级。在其他应用为高优先级的情况下，将其他应用从主CPU切换至从CPU上运行。其他应用包括与待进行CPU资源调度的目标应用不同的应用程序。

作为一种可选的实施例，在获取基于滑动场景的实时负载数据的过程中，还可以获取与应用程序关联的以下数据中的至少之一，以作为实时负载数据：GPU负载信息、内存使用信息、函数调用信息和堆栈信息。GPU负载信息可以指示GPU的负载情况，GPU负载信息例如包括GPU核心频点信息、GPU频率档位信息、GPU当前运行频率和GPU使用率等信息。

此外，还可以根据与目标丢帧场景匹配的负载统计阈值，对电子设备的以下资源中的至少之一进行调度：GPU频点、线程运行核心、应用显示帧率和屏幕刷新率。例如，可以提高GPU频点以及内存带宽，或者将渲染合成线程调度向更高计算能力的大核心上运行等。

可以理解的是，电子设备为了实现上述功能，其包含了执行各个功能相应的硬件和/或软件模块。结合本文中所公开的实施例描述的各示例的算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。本领域技术人员可以结合实施例对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

上述方法实施例涉及的各步骤的所有相关内容均可以援引到对应功能模块的功能描述，在此不再赘述。

本实施例还提供一种计算机存储介质，该计算机存储介质中存储有计算机指令，当该计算机指令在电子设备上运行时，使得电子设备执行上述相关方法步骤实现上述实施例中的负载资源调度方法。

本实施例还提供了一种计算机程序产品，当该计算机程序产品在计算机上运行时，使得计算机执行上述相关步骤，以实现上述实施例中的负载资源调度方法。

另外，本申请的实施例还提供一种装置，这个装置具体可以是芯片，组件或模块，该装置可包括相连的处理器和存储器；其中，存储器用于存储计算机执行指令，当装置运行时，处理器可执行存储器存储的计算机执行指令，以使芯片执行上述各方法实施例中的负载资源调度方法。

其中，本实施例提供的电子设备、计算机存储介质、计算机程序产品或芯片均用于执行上文所提供的对应的方法，因此，其所能达到的有益效果可参考上文所提供的对应的方法中的有益效果，此处不再赘述。

通过以上实施方式的描述，所属领域的技术人员可以了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。

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

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

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

本申请各个实施例的任意内容，以及同一实施例的任意内容，均可以自由组合。对上述内容的任意组合均在本申请的范围之内。

集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该软件产品存储在一个存储介质中，包括若干指令用以使得一个设备（可以是单片机，芯片等）或处理器（processor）执行本申请各个实施例方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器（read only memory，ROM）、随机存取存储器（random access memory，RAM）、磁碟或者光盘等各种可以存储程序代码的介质。

上面结合附图对本申请的实施例进行了描述，但是本申请并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本申请的启示下，在不脱离本申请宗旨和权利要求所保护的范围情况下，还可做出很多形式，均属于本申请的保护之内。

结合本申请实施例公开内容所描述的方法或者算法的步骤可以硬件的方式来实现，也可以是由处理器执行软件指令的方式来实现。软件指令可以由相应的软件模块组成，软件模块可以被存放于随机存取存储器（Random Access Memory，RAM）、闪存、只读存储器（Read Only Memory，ROM）、可擦除可编程只读存储器（Erasable Programmable ROM，EPROM）、电可擦可编程只读存储器（Electrically EPROM，EEPROM）、寄存器、硬盘、移动硬盘、只读光盘（CD-ROM）或者本领域熟知的任何其它形式的存储介质中。一种示例性的存储介质耦合至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息。当然，存储介质也可以是处理器的组成部分。处理器和存储介质可以位于ASIC中。

本领域技术人员应该可以意识到，在上述一个或多个示例中，本申请实施例所描述的功能可以用硬件、软件、固件或它们的任意组合来实现。当使用软件实现时，可以将这些功能存储在计算机可读介质中或者作为计算机可读介质上的一个或多个指令或代码进行传输。计算机可读介质包括计算机存储介质和通信介质，其中通信介质包括便于从一个地方向另一个地方传送计算机程序的任何介质。存储介质可以是通用或专用计算机能够存取的任何可用介质。

上面结合附图对本申请的实施例进行了描述，但是本申请并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本申请的启示下，在不脱离本申请宗旨和权利要求所保护的范围情况下，还可做出很多形式，均属于本申请的保护之内。

Claims (18)

1.一种负载资源调度方法，其特征在于，包括：

响应于应用程序的界面显示处于滑动场景，获取与所述应用程序关联的丢帧检测数据和实时负载数据；

基于所述丢帧检测数据，确定所述应用程序所属的目标丢帧场景；以及

根据所述实时负载数据和与所述目标丢帧场景匹配的负载统计阈值，对电子设备的CPU资源进行调度。

2.根据权利要求1所述的方法，其特征在于，所述响应于应用程序的界面显示处于滑动场景，获取与所述应用程序关联的丢帧检测数据和实时负载数据，包括：

检测基于所述应用程序被触发的触摸事件；

在所述触摸事件为移动事件或移动抬起事件的情况下，确定所述应用程序的界面显示处于滑动场景；

获取与所述应用程序关联的所述丢帧检测数据和所述实时负载数据。

3.根据权利要求2所述的方法，其特征在于，所述获取与所述应用程序关联的所述丢帧检测数据，包括：

获取与所述应用程序关联的包含丢帧时长信息的丢帧记录数据，以作为所述丢帧检测数据，

其中，所述丢帧记录数据与所述移动事件的被触发过程和/或与所述移动抬起事件被触发后的预设时间段相对应。

4.根据权利要求3所述的方法，其特征在于，所述基于所述丢帧检测数据，确定所述应用程序所属的目标丢帧场景，包括：

基于所述丢帧时长信息和预设的多个丢帧时长阈值，确定与各所述丢帧时长阈值匹配的丢帧记录数目；

根据与各所述丢帧时长阈值匹配的所述丢帧记录数目，确定由所述丢帧记录数目指示的所述目标丢帧场景，

其中，所述目标丢帧场景为多个候选丢帧场景中的任意丢帧场景，所述多个候选丢帧场景包括无丢帧场景、不易感知丢帧场景、明显丢帧场景和严重丢帧场景。

5.根据权利要求2所述的方法，其特征在于，获取与所述应用程序关联的所述实时负载数据，包括：

获取与所述应用程序关联的CPU占用信息，以作为所述实时负载数据，

其中，所述CPU占用信息与所述移动事件的被触发过程和/或与所述移动抬起事件被触发后的预设时间段相对应。

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

根据预设的故障场景列表，确定与所述目标丢帧场景匹配的CPU占用率阈值，以作为所述负载统计阈值，其中，所述故障场景列表是基于以下操作得到的：

基于目标用户在预设时间段内针对电子设备的使用行为，获取与所述使用行为关联的丢帧记录数据和CPU占用信息；

根据所述丢帧记录数据中的丢帧时长信息，确定与多个候选丢帧场景中的各所述候选丢帧场景匹配的目标丢帧记录；

根据与所述目标丢帧记录关联的所述CPU占用信息，将由所述CPU占用信息指示的CPU占用率阈值，作为与各所述候选丢帧场景匹配的负载统计阈值；

与各所述候选丢帧场景匹配的所述负载统计阈值，构成所述故障场景列表，

所述目标丢帧场景为多个候选丢帧场景中的任意丢帧场景，所述多个候选丢帧场景包括无丢帧场景、不易感知丢帧场景、明显丢帧场景和严重丢帧场景。

7.根据权利要求6所述的方法，其特征在于，所述CPU占用信息指示CPU占用率，与各所述候选丢帧场景匹配的所述负载统计阈值包括第一CPU占用率阈值、第二CPU占用率阈值、第三CPU占用率阈值和第四CPU占用率阈值，

所述负载统计阈值是基于以下操作得到的：

对基于所述预设时间段内的所述CPU占用率进行由小至大排序；

根据由小至大排序的所述CPU占用率，将前第一预设占比的所述CPU占用率中的最大CPU占用率作为所述第一CPU占用率阈值；

将前第二预设占比的所述CPU占用率中的最大CPU占用率作为所述第二CPU占用率阈值，所述第二预设占比大于所述第一预设占比；

将前第三预设占比的所述CPU占用率中的最大CPU占用率作为所述第三CPU占用率阈值，所述第三预设占比大于所述第二预设占比；

将所有CPU占用率中的最大CPU占用率作为所述第四CPU占用率阈值。

8.根据权利要求7所述的方法，其特征在于，

所述CPU资源包括CPU频点、用于执行系统动作的CPU核、是否允许执行系统动作和内存剩余量；

所述根据所述实时负载数据和与所述目标丢帧场景匹配的负载统计阈值，对电子设备的CPU资源进行调度，包括：

根据与所述目标丢帧场景匹配的所述负载统计阈值和由所述实时负载数据指示的实时CPU占用率，对所述CPU资源进行调度。

9.根据权利要求8所述的方法，其特征在于，所述根据与所述目标丢帧场景匹配的所述负载统计阈值和由所述实时负载数据指示的实时CPU占用率，对所述CPU资源进行调度，包括：

在所述实时CPU占用率大于或等于所述第四CPU占用率阈值的情况下，提高所述CPU频点。

10.根据权利要求8所述的方法，其特征在于，所述根据与所述目标丢帧场景匹配的所述负载统计阈值和由所述实时负载数据指示的实时CPU占用率，对所述CPU资源进行调度，包括：

在所述实时CPU占用率小于所述第四CPU占用率阈值，且大于或等于所述第三CPU占用率阈值的情况下，将所述系统动作置于CPU小核中执行。

11.根据权利要求8所述的方法，其特征在于，所述根据与所述目标丢帧场景匹配的所述负载统计阈值和由所述实时负载数据指示的实时CPU占用率，对所述CPU资源进行调度，包括：

在所述实时CPU占用率小于所述第三CPU占用率阈值，且大于或等于所述第二CPU占用率阈值的情况下，允许执行所述系统动作。

12.根据权利要求8所述的方法，其特征在于，所述根据与所述目标丢帧场景匹配的所述负载统计阈值和由所述实时负载数据指示的实时CPU占用率，对所述CPU资源进行调度，包括：

在所述实时CPU占用率小于所述第二CPU占用率阈值，且大于或等于所述第一CPU占用率阈值的情况下，降低所述CPU频点。

13.根据权利要求8所述的方法，其特征在于，所述根据与所述目标丢帧场景匹配的所述负载统计阈值和由所述实时负载数据指示的实时CPU占用率，对所述CPU资源进行调度，包括：

在所述实时CPU占用率小于所述第一CPU占用率阈值、且所述内存剩余量小于预设内存水线级的情况下，禁止执行所述系统动作。

14.根据权利要求1至13中任一项所述的方法，其特征在于，所述应用程序包括使用频次高于预设频次阈值的目标应用。

15.根据权利要求1所述的方法，其特征在于，获取与所述应用程序关联的所述实时负载数据，包括：

获取与所述应用程序关联的以下数据中的至少之一，以作为所述实时负载数据：

GPU负载信息、内存使用信息、函数调用信息和堆栈信息。

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

根据所述实时负载数据和与所述目标丢帧场景匹配的所述负载统计阈值，对电子设备的以下资源中的至少之一进行调度：

GPU频点、线程运行核心、应用显示帧率和屏幕刷新率。

17.一种电子设备，其特征在于，包括：一个或多个处理器、存储器以及一个或多个计算机程序，其中所述一个或多个计算机程序存储在所述存储器上，当所述计算机程序被所述一个或多个处理器执行时，使得所述电子设备执行以下步骤：

响应于应用程序的界面显示处于滑动场景，获取与所述应用程序关联的丢帧检测数据和实时负载数据；

基于所述丢帧检测数据，确定所述应用程序所属的目标丢帧场景；以及

根据所述实时负载数据和与所述目标丢帧场景匹配的负载统计阈值，对CPU资源进行调度。

18.一种计算机可读存储介质，其特征在于，包括计算机程序，当所述计算机程序在电子设备上运行时，使得所述电子设备执行如权利要求1至16中任意一项所述的负载资源调度方法。

Images