CN117130771B - 一种资源调度方法、电子设备及存储介质 - Google Patents

一种资源调度方法、电子设备及存储介质 Download PDF

Info

Publication number
CN117130771B
CN117130771B CN202310371732.0A CN202310371732A CN117130771B CN 117130771 B CN117130771 B CN 117130771B CN 202310371732 A CN202310371732 A CN 202310371732A CN 117130771 B CN117130771 B CN 117130771B
Authority
CN
China
Prior art keywords
application
thread
frame loss
core
electronic device
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.)
Active
Application number
CN202310371732.0A
Other languages
English (en)
Other versions
CN117130771A (zh
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 CN202310371732.0A priority Critical patent/CN117130771B/zh
Publication of CN117130771A publication Critical patent/CN117130771A/zh
Application granted granted Critical
Publication of CN117130771B publication Critical patent/CN117130771B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

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
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/50—Controlling the output signals based on the game progress
    • A63F13/52—Controlling the output signals based on the game progress involving aspects of the displayed game scene
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T1/00—General purpose image data processing
    • G06T1/20—Processor architectures; Processor configuration, e.g. pipelining

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Multimedia (AREA)
  • General Engineering & Computer Science (AREA)
  • Stored Programmes (AREA)

Abstract

本申请提供一种资源调度方法、电子设备及存储介质，涉及资源调度技术领域，该方法可以应用在游戏应用和另一应用以多窗口模式运行的场景中，在游戏应用的主逻辑线程的运行时长占比较大时，将游戏应用中的核心线程和工作线程进行绑核；通过该方法可以将概率性唤醒游戏应用的主逻辑线程的核心线程和工作线程绑定到中央处理器的某各较为空闲的核上，从而将系统资源优先供给核心线程和工作线程，这样就可以降低由于核心线程和工作线程得不到系统资源导致游戏应用的主逻辑线程长期处于runnable状态的时长，从而降低游戏应用的丢帧现象。

Description

一种资源调度方法、电子设备及存储介质
技术领域
本申请实施例涉及资源调度技术领域，尤其涉及一种资源调度方法、电子设备及存储介质。
背景技术
随着电子设备的功能越来越强大，电子设备可以支持一些大型应用的安装和运行。例如，一些联网的大型游戏应用。这些大型游戏应用(例如，王者荣耀)在运行过程中比较消耗系统资源，可能会导致电子设备处于高负载场景下。
在一些高负载场景下，例如，游戏应用和另一应用在前台以多窗口模式运行时，游戏应用的优先级通常较低，导致得不到系统资源，从而比较容易出现丢帧的现象。
发明内容
本申请实施例提供一种资源调度方法、电子设备及存储介质，可以游戏应用丢帧的现象。
为达到上述目的，本申请采用如下技术方案：
第一方面，本申请实施例提供一种资源调度方法，包括：
电子设备显示第一应用的界面和第二应用的界面；
在所述第一应用为游戏应用、所述第一应用的主逻辑线程的运行时长占比大于第一值时，所述电子设备将所述第一应用的核心线程和工作线程进行绑核，所述核心线程和所述工作线程用于概率性的唤醒所述主逻辑线程。
本申请实施例中，可以通过在游戏应用和其他应用以多窗口模式在前台运行时，将第一应用的核心线程和工作线程进行绑核，由于核心线程和工作线程会概率性的唤醒第一应用的主逻辑线程，所以，能够避免主逻辑线程长时间处于runnable状态，从而降低第一应用丢帧的现象；另外，当第一应用的主逻辑线程的运行时长占比大于第一值说明了中央处理器的性能确实不太好，而丢帧现象更多的出现在中央处理器的性能不太好的电子设备(负载会较高)中，所以，可以将第一应用的丢帧现象。
在第一方面的一种实现方式中，所述在所述第一应用为游戏应用、所述第一应用的主逻辑线程的运行时长占比大于第一值时，所述电子设备将所述第一应用的核心线程和工作线程进行绑核，包括：
在所述第一应用为游戏应用、所述电子设备的帧率为第一帧率、所述第一应用的主逻辑线程的运行时长占比大于第一值时，所述电子设备将所述第一应用的核心线程和工作线程进行绑核，所述第一帧率大于30帧每秒。
本申请实施例中，通常，使用性能不太好的中央处理器的电子设备在采用较高的帧率时(例如，大于30帧每秒)较常出现负载过高的情况，而采用小于或等于30帧每秒时不太容易出现负载过高的情况，所以，可以设置条件包括所述电子设备的帧率大于30帧每秒。
在第一方面的一种实现方式中，所述在所述第一应用为游戏应用、所述电子设备的帧率为第一帧率、所述第一应用的主逻辑线程的运行时长占比大于第一值时，所述电子设备将所述第一应用的核心线程和工作线程进行绑核，包括：
在所述第一应用为游戏应用、所述第二应用不为视频通话类应用、所述电子设备的帧率为第一帧率、所述第一应用的主逻辑线程的运行时长占比大于第一值时，所述电子设备将所述第一应用的核心线程和工作线程进行绑核。
本申请实施例中，当多窗口运行的另一应用不为视频通话类应用时，另一应用对系统资源的需求不太高，但是游戏应用对系统资源需求较高，所以需要将游戏应用中的相关线程迁移到小核。
在第一方面的一种实现方式中，所述在所述第一应用为游戏应用、所述第二应用不为视频通话类应用、所述电子设备的帧率为第一帧率、所述第一应用的主逻辑线程的运行时长占比大于第一值时，所述电子设备将所述第一应用的核心线程和工作线程进行绑核，包括：
在所述第一应用为游戏应用、所述第二应用不为视频通话类应用、所述电子设备的中央处理器包括两个大核和N个小核、所述电子设备的帧率为第一帧率、所述第一应用的主逻辑线程的运行时长占比大于第一值时，所述电子设备将所述第一应用的核心线程和工作线程进行绑核，N为大于或等于4的自然数。
本申请实施例中，电子设备的中央处理器包括两个大核和N个小核时，通常为性能较差的中央处理器，所以，在所述电子设备的中央处理器包括两个大核和N个小核时，对游戏应用的两个线程进行绑核，以将有限的系统资源尽量多供给第一应用的核心线程和工作线程。
在第一方面的一种实现方式中，在所述第一应用为游戏应用、所述第二应用不为视频通话类应用、所述电子设备的中央处理器包括两个大核和N个小核，所述电子设备的帧率为第一帧率、所述第一应用的主逻辑线程的运行时长占比大于第一值时，所述方法还包括：
所述第一应用的主逻辑线程的运行时长占比小于第二值时，将所述第一应用的核心线程绑定到大核运行，所述电子设备将所述第一应用的工作线程绑定到小核运行；
所述第一应用的主逻辑线程的运行时长占比大于或等于所述第二值时，所述电子设备将所述第一应用的核心线程和工作线程绑定到小核运行。
本申请实施例中，还可以根据第一应用的主逻辑线程的运行时长占比不同值选择不同的绑核策略，以最大限度的利用系统资源，又不会对系统资源造成过度消耗。
在第一方面的一种实现方式中，在所述电子设备显示第一应用的界面和第二应用的界面时，所述方法还包括：
在所述第一应用为游戏应用、所述第二应用为视频通话类应用时，所述电子设备对所述第一应用的核心线程和工作线程自由调度；
在所述第一应用为游戏应用、所述第二应用不为视频通话类应用、所述电子设备的中央处理器的性能优于采用两个大核和N个小核的中央处理器时，所述电子设备对所述第一应用的核心线程和工作线程自由调度；
在所述第一应用为游戏应用、所述第二应用不为视频通话类应用、所述电子设备的中央处理器包括两个大核和N个小核、所述电子设备的帧率为第二帧率时，所述电子设备对所述第一应用的核心线程和工作线程自由调度，所述第二帧率小于所述第一帧率；
在所述第一应用为游戏应用、所述第二应用不为视频通话类应用、所述电子设备的中央处理器包括两个大核和N个小核、所述电子设备的帧率为第一帧率、所述第一应用的主逻辑线程时长占比小于或等于第一值时，所述电子设备提高所述第一应用的核心线程和工作线程的优先级，对所述第一应用的核心线程和工作线程自由调度。
本申请实施例中，当另一应用为视频通话类应用时，两个应用对系统资源的需求均较高，这种情况下，为了避免对另一应用造成影响，可以设置两个应用的线程自由调度；
当中央处理器的性能较好时，负载不会过大，可以设置两个应用的线程自由调度；
当电子设备的帧率较小是，系统负载不会过大，可以设置两个应用的线程自由调度；
当第一应用在前台运行，且所述第一应用的主逻辑线程时长占比小于或等于第一值时，表示系统负载较小，这种情况下，可以设置两个应用的线程自由调度。
在第一方面的一种实现方式中，所述方法还包括：
在所述电子设备显示的界面不包括所述第一应用的界面时，所述电子设备解除所述第一应用的核心线程和工作线程的绑核。
本申请实施例中，在游戏应用退回到后台后，为了避免造成系统资源浪费，可以解除游戏应用的绑核。
在第一方面的一种实现方式中，所述方法还包括：
所述电子设备显示的界面包括所述第一应用的界面时，所述电子设备监测所述第一应用是否丢帧；
在所述第一应用的丢帧数量或丢帧频率满足丢帧诊断条件、在丢帧期间有后台应用被唤醒时，所述电子设备将被唤醒的后台应用的线程绑定到小核。
在实际应用中，在游戏应用在前台运行时，无论多窗口模式还是单窗口模式下，均可能出现丢帧情况，即已经实施过的一些策略已经无法满足游戏应用在前台流畅运行，所以，可以针对丢帧情况下，执行相应的策略；若丢帧期间后台应用被唤醒，说明可能为被唤醒的后台应用抢夺了系统资源，所以，可以将被唤醒的后台应用的线程绑定到小核，以避免两个应用之间抢夺系统资源。当然，将被唤醒的后台应用的线程绑定到小核运行时，可以和游戏应用的线程所在的小核在一个小核也可以不再一个小核。
在第一方面的一种实现方式中，所述在所述第一应用的丢帧数量或丢帧频率满足丢帧诊断条件、在丢帧期间有后台应用被唤醒时，所述电子设备将被唤醒的后台应用的线程绑定到小核，包括：
在所述第一应用的丢帧数量或丢帧频率满足丢帧诊断条件、所述电子设备的中央处理器的频率为可设置的最高值、在丢帧期间有后台应用被唤醒时，所述电子设备将被唤醒的后台应用的线程绑定到小核。
本申请实施例中，处于某种考虑，电子设备可能会限频(CPU频率)，例如，用户为了节约电量，自己设置为限频场景。在限频场景下丢帧与系统资源调度关系不大，在未限频场景下丢帧，说明负载确实可能较大，所以，需要设置频率是否为最高排除掉一些限频方案的干扰。
在第一方面的一种实现方式中，在所述第一应用的丢帧数量或丢帧频率满足丢帧诊断条件、所述电子设备的中央处理器的频率为可设置的最高值、在丢帧期间有后台应用被唤醒时，所述电子设备将被唤醒的后台应用的线程绑定到小核，包括：
在所述第一应用的丢帧数量或丢帧频率满足丢帧诊断条件、所述电子设备的中央处理器的频率为可设置的最高值、在丢帧期间有后台应用被唤醒且接收到消息时，所述电子设备将被唤醒的后台应用的线程绑定到小核。
通常后台应用被唤醒且接收到消息的情况，后台应用还会较快的切换为非活跃状态，所以，可以暂时将被唤醒的后台应用的线程绑定到小核。
在第一方面的一种实现方式中，所述方法还包括：
在所述第一应用的丢帧数量或丢帧频率满足丢帧诊断条件、所述电子设备的中央处理器的频率为可设置的最高值、在丢帧期间有后台应用被唤醒且未接收到消息、所述第一应用的主逻辑线程的运行时长占比大于第一值(0.5)时，所述电子设备将所述第一应用的核心线程和工作线程进行绑核。
若有后台应用被唤醒且未收到消息，说明是其他原因唤醒了该后台应用，该被唤醒的后台应用将消耗较多的系统资源，这种情况下，相当于该后台应用和游戏应用要争夺系统资源，类似于游戏应用和该后台应用在前台以多窗口模式运行，这种情况，可以参照游戏应用和另一应用在前台以多窗口模式运行时，对游戏应用的绑核策略。
在第一方面的一种实现方式中，在监测所述第一应用是否丢帧期间，所述方法还包括：
在所述第一应用的丢帧数量或丢帧频率满足丢帧诊断条件、在丢帧期间无后台应用被唤醒、在丢帧期间所述第一应用的其他线程占用大核资源时，所述电子设备将所述第一应用的其他线程绑定到小核，所述第一应用的其他线程为所述第一应用的线程中所述主逻辑线程、所述核心线程和所述工作线程以外的线程。
在第一方面的一种实现方式中，所述方法还包括：
在所述第一应用的丢帧数量或丢帧频率满足丢帧诊断条件、在丢帧期间无后台应用被唤醒、在丢帧期间所述第一应用的其他线程未占用大核资源、在丢帧期间系统进程占用大核资源、且至少一个小核中的线程运行总时长占比小于第二值时，所述电子设备将系统进程绑定到小核；
在所述第一应用的丢帧数量或丢帧频率满足丢帧诊断条件、在丢帧期间无后台应用被唤醒、在丢帧期间所述第一应用的其他线程未占用大核资源、在丢帧期间系统进程占用大核资源、且每个小核中的线程运行总时长占比大于或等于第二值时，所述电子设备将系统进程绑定到小核，将所述第一应用的核心线程和工作线程的优先级提高，取消所述第一应用的核心线程和工作线程的绑核。
本申请实施例中，无论是第一应用的其他线程，还是系统进程，谁抢夺了系统资源，就将谁绑定到小核。
在第一方面的一种实现方式中，所述方法还包括：
在所述电子设备显示的界面不包括所述第一应用的界面时，所述电子设备解除在所述第一应用的丢帧数量或丢帧频率满足丢帧诊断条件时执行的绑核。
第二方面，提供一种电子设备，包括处理器，处理器用于运行存储器中存储的计算机程序，实现本申请第一方面任一项的方法。
第三方面，提供一种芯片系统，包括处理器，处理器与存储器耦合，处理器执行存储器中存储的计算机程序，以实现本申请第一方面任一项的方法。
第四方面，提供一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，计算机程序被一个或多个处理器执行时实现本申请第一方面任一项的方法。
第五方面，本申请实施例提供了一种计算机程序产品，当计算机程序产品在设备上运行时，使得设备执行本申请第一方面任一项的方法。
可以理解的是，上述第二方面至第五方面的有益效果可以参见上述第一方面中的相关描述，在此不再赘述。
附图说明
图1为本申请实施例提供的资源调度方法所应用的电子设备的一种硬件结构示意图；
图2为本申请实施例提供的一种游戏应用发生丢帧时CoreThread的状态示意图；
图3为本申请实施例提供的一种游戏应用发生丢帧时WorkerThread的状态示意图；
图4为本申请实施例提供的一种游戏应用以多窗口模式运行时判断是否执行动态绑核策略的流程示意图；
图5为本申请实施例提供的一种游戏应用的动态绑核策略对应的流程示意图；
图6为本申请实施例提供的一种游戏应用的静态绑核策略对应的流程示意图；
图7为本申请实施例提供的另一游戏应用以多窗口模式运行时判断是否执行动态绑核策略的流程示意图；
图8为本申请实施例提供的游戏应用在前台运行时发生丢帧后的流程示意图；
图9为本申请实施例提供的另一游戏应用在前台运行时发生丢帧后的流程示意图；
图10为本申请实施例提供的另一游戏应用在前台运行时发生丢帧后的流程示意图。
具体实施方式
以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本申请实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本申请。
应当理解，当在本申请说明书和所附权利要求书中使用时，术语“包括”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。
还应当理解，在本申请实施例中，“一个或多个”是指一个、两个或两个以上；“和/或”，描述关联对象的关联关系，表示可以存在三种关系；例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B的情况，其中A、B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。
另外，在本申请说明书和所附权利要求书的描述中，术语“第一”、“第二”、“第三”、“第四”等仅用于区分描述，而不能理解为指示或暗示相对重要性。
在本申请说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本申请的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。
本申请实施例提供的一种资源调度方法，可以适用于以下电子设备中。该电子设备可以为平板电脑、手机、可穿戴设备、笔记本电脑、超级移动个人计算机(ultra-mobilepersonal computer，UMPC)、上网本、个人数字助理(personal digital assistant，PDA)等电子设备。本申请实施例对电子设备的具体类型不作限定。
图1示出了一种电子设备的结构示意图。电子设备100可以包括处理器110，外部存储器接口120，内部存储器121，通用串行总线(universal serial bus，USB)接口130，充电管理模块140，电源管理模块141，电池142，天线1，天线2，移动通信模块150，无线通信模块160，音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，传感器模块180，按键190，马达191，摄像头193，显示屏194，以及用户标识模块(subscriberidentification module，SIM)卡接口195等。其中，传感器模块180可以包括压力传感器180A，触摸传感器180K，环境光传感器180L等。
可以理解的是，本申请实施例示意的结构并不构成对电子设备100的具体限定。在本申请另一些实施例中，电子设备100可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。
处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processingunit，GPU)，图像信号处理器(image signal processor，ISP)，控制器，存储器，视频编解码器，数字信号处理器(digital signal processor，DSP)，协处理器(sensor coprocessor，SCP)，基带处理器，和/或神经网络处理器(neural-network processing unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。例如，处理器110用于执行本申请实施例中的资源调度方法。
其中，控制器可以是电子设备100的神经中枢和指挥中心。控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。
处理器110中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110刚用过或循环使用的指令或数据。如果处理器110需要再次使用该指令或数据，可从存储器中直接调用。避免了重复存取，减少了处理器110的等待时间，因而提高了系统的效率。
USB接口130是符合USB标准规范的接口，具体可以是Mini USB接口，Micro USB接口，USB Type C接口等。USB接口130可以用于连接充电器为电子设备100充电，也可以用于电子设备100与外围设备之间传输数据。
可以理解的是，本申请实施例示意的各模块间的接口连接关系，只是示意性说明，并不构成对电子设备100的结构限定。在本申请另一些实施例中，电子设备100也可以采用上述实施例中不同的接口连接方式，或多种接口连接方式的组合。
外部存储器接口120可以用于连接外部存储卡，例如Micro SD卡，实现扩展电子设备100的存储能力。外部存储卡通过外部存储器接口120与处理器110通信，实现数据存储功能。例如将音乐，视频等文件保存在外部存储卡中。
内部存储器121可以用于存储计算机可执行程序代码，可执行程序代码包括指令。处理器110通过运行存储在内部存储器121的指令，从而执行电子设备100的各种功能应用以及数据处理。内部存储器121可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统，至少一个功能所需的应用程序(比如声音播放功能，图像播放功能等)。
此外，内部存储器121可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件，闪存器件，通用闪存存储器(universal flash storage，UFS)等。
充电管理模块140用于从充电器接收充电输入。其中，充电器可以是无线充电器，也可以是有线充电器。在一些有线充电的实施例中，充电管理模块140可以通过USB接口130接收有线充电器的充电输入。
电源管理模块141用于连接电池142，充电管理模块140与处理器110。电源管理模块141接收电池142和/或充电管理模块140的输入，为处理器110，内部存储器121，外部存储器，显示屏194，摄像头193，和无线通信模块160等供电。
在其他一些实施例中，电源管理模块141也可以设置于处理器110中。在另一些实施例中，电源管理模块141和充电管理模块140也可以设置于同一个器件中。
电子设备100的无线通信功能可以通过天线1，天线2，移动通信模块150，无线通信模块160，调制解调处理器以及基带处理器等实现。
天线1和天线2用于发射和接收电磁波信号。电子设备100中的每个天线可用于覆盖单个或多个通信频带。不同的天线还可以复用，以提高天线的利用率。例如：可以将天线1复用为无线局域网的分集天线。在另外一些实施例中，天线可以和调谐开关结合使用。
移动通信模块150可以提供应用在电子设备100上的包括2G/3G/4G/5G等无线通信的解决方案。移动通信模块150可以包括至少一个滤波器，开关，功率放大器，低噪声放大器(low noise amplifier，LNA)等。移动通信模块150可以由天线1接收电磁波，并对接收的电磁波进行滤波，放大等处理，传送至调制解调处理器进行解调。移动通信模块150还可以对经调制解调处理器调制后的信号放大，经天线1转为电磁波辐射出去。
无线通信模块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)等无线通信的解决方案。无线通信模块160可以是集成至少一个通信处理模块的一个或多个器件。无线通信模块160经由天线2接收电磁波，将电磁波信号调频以及滤波处理，将处理后的信号发送到处理器110。无线通信模块160还可以从处理器110接收待发送的信号，对其进行调频，放大，经天线2转为电磁波辐射出去。
在一些实施例中，电子设备100的天线1和移动通信模块150耦合，天线2和无线通信模块160耦合，使得电子设备100可以通过无线通信技术与网络以及其他设备通信。
电子设备100可以通过音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，以及应用处理器等实现音频功能。例如音乐播放，录音等。
音频模块170用于将数字音频信号转换成模拟音频信号输出，也用于将模拟音频输入转换为数字音频信号。音频模块170还可以用于对音频信号编码和解码。在一些实施例中，音频模块170可以设置于处理器110中，或将音频模块170的部分功能模块设置于处理器110中。
扬声器170A，也称“喇叭”，用于将音频电信号转换为声音信号。电子设备100可以通过扬声器170A收听音乐，或收听免提通话。
受话器170B，也称“听筒”，用于将音频电信号转换成声音信号。当电子设备100接听电话或语音信息时，可以通过将受话器170B靠近人耳接听语音。
麦克风170C，也称“话筒”，“传声器”，用于将声音信号转换为电信号。当拨打电话或发送语音信息时，用户可以通过人嘴靠近麦克风170C发声，将声音信号输入到麦克风170C。电子设备100可以设置至少一个麦克风170C。在另一些实施例中，电子设备100可以设置两个麦克风170C，除了监听语音信息，还可以实现降噪功能。在另一些实施例中，电子设备100还可以设置三个，四个或更多麦克风170C，实现采集声音信号，降噪，还可以识别声音来源，实现定向录音功能等。耳机接口170D用于连接有线耳机。耳机接口170D可以是USB接口130，也可以是3.5mm的开放电子设备平台(open mobile terminal platform，OMTP)标准接口，美国蜂窝电信工业协会(cellular telecommunications industry association ofthe USA，CTIA)标准接口。
压力传感器180A用于感受压力信号，可以将压力信号转换成电信号。在一些实施例中，压力传感器180A可以设置于显示屏194。压力传感器180A的种类很多，如电阻式压力传感器，电感式压力传感器，电容式压力传感器等。电容式压力传感器可以是包括至少两个具有导电材料的平行板。当有力作用于压力传感器180A，电极之间的电容改变。电子设备100根据电容的变化确定压力的强度。当有触摸操作作用于显示屏194，电子设备100根据压力传感器180A检测触摸操作强度。电子设备100也可以根据压力传感器180A的检测信号计算触摸的位置。
触摸传感器180K，也称“触控面板”。触摸传感器180K可以设置于显示屏194，由触摸传感器180K与显示屏194组成触摸屏，也称“触控屏”。触摸传感器180K用于检测作用于其上或附近的触摸操作。触摸传感器可以将检测到的触摸操作传递给应用处理器，以确定触摸事件类型。可以通过显示屏194提供与触摸操作相关的视觉输出。在另一些实施例中，触摸传感器180K也可以设置于电子设备100的表面，与显示屏194所处的位置不同。
环境光传感器180L用于感知环境光亮度。电子设备100可以根据感知的环境光亮度自适应调节显示屏194亮度。环境光传感器180L也可用于拍照时自动调节白平衡。环境光传感器180L还可以与接近光传感器180G配合，检测电子设备100是否在口袋里，以防误触。
按键190包括开机键，音量键等。按键190可以是机械按键。也可以是触摸式按键。电子设备100可以接收按键输入，产生与电子设备100的用户设置以及功能控制有关的键信号输入。
马达191可以产生振动提示。马达191可以用于来电振动提示，也可以用于触摸振动反馈。
电子设备100通过GPU，显示屏194，以及应用处理器等实现显示功能。GPU为图像处理的微处理器，连接显示屏194和应用处理器。GPU用于执行数学和几何计算，用于图形渲染。处理器110可包括一个或多个GPU，其执行程序指令以生成或改变显示信息。
显示屏194用于显示图像，视频等。显示屏194包括显示面板。显示面板可以采用液晶显示屏(liquid crystal display，LCD)，有机发光二极管(organic light-emittingdiode，OLED)，有源矩阵有机发光二极体或主动矩阵有机发光二极体(active-matrixorganic light emitting diode的，AMOLED)，柔性发光二极管(flex light-emittingdiode，FLED)，Miniled，MicroLed，Micro-OLED，量子点发光二极管(quantum dot lightemitting diodes，QLED)等。在一些实施例中，电子设备100可以包括1个或N个显示屏194，N为大于1的正整数。
摄像头193用于捕获静态图像或视频。物体通过镜头生成光学图像投射到感光元件。感光元件可以是电荷耦合器件(charge coupled device，CCD)或互补金属氧化物半导体(complementary metal-oxide-semiconductor，CMOS)光电晶体管。感光元件把光信号转换成电信号，之后将电信号传递给ISP转换成数字图像信号。ISP将数字图像信号输出到DSP加工处理。DSP将数字图像信号转换成标准的RGB，YUV等格式的图像信号。在一些实施例中，电子设备100可以包括1个或N个摄像头193，N为大于1的正整数。
SIM卡接口195用于连接SIM卡。SIM卡可以通过插入SIM卡接口195，或从SIM卡接口195拔出，实现和电子设备100的接触和分离。电子设备100可以支持1个或N个SIM卡接口，N为大于1的正整数。SIM卡接口195可以支持Nano SIM卡，Micro SIM卡，SIM卡等。同一个SIM卡接口195可以同时插入多张卡。多张卡的类型可以相同，也可以不同。SIM卡接口195也可以兼容不同类型的SIM卡。SIM卡接口195也可以兼容外部存储卡。电子设备100通过SIM卡和网络交互，实现通话以及数据通信等功能。在一些实施例中，电子设备100采用eSIM，即：嵌入式SIM卡。eSIM卡可以嵌在电子设备100中，不能和电子设备100分离。
本申请实施例并未特别限定一种资源调度方法的执行主体的具体结构，只要可以通过运行记录有本申请实施例的一种资源调度方法的代码，以根据本申请实施例提供的一种资源调度方法进行通信即可。例如，本申请实施例提供的一种资源调度方法的执行主体可以是电子设备中能够调用程序并执行程序的功能模块，或者为应用于电子设备中的通信装置，例如，芯片。
随着电子设备的功能越来越强大，电子设备可以支持一些大型应用的安装和运行。例如，一些联网的大型游戏应用。这些大型游戏应用(例如，王者荣耀)在运行过程中比较消耗系统资源，可能会导致电子设备处于高负载场景下，当电子设备处于高负载场景下时，大型游戏应用比较容易出现丢帧的现象。
作为高负载场景下游戏应用丢帧的一个示例，电子设备支持多窗口模式，即两个应用同时在前台运行；这种情况下，当在前台运行的两个应用中其中一个应用为游戏应用(例如，王者荣耀等)时，通常游戏应用中非主要线程的优先级比较低导致非主要线程得不到系统资源调度，从而阻塞游戏主逻辑线程的运行，从而使得游戏应用出现丢帧的现象。
作为高负载场景下游戏应用丢帧的另一个示例，电子设备在前台运行游戏应用(可以为多窗口模式也可以为单窗口模式)时，由于电子设备后台保活应用存在被唤醒的概率，当后台保活应用被唤醒后，后台保活应用和前台游戏应用同时消耗系统资源；这种情况下，也会由于游戏应用中非主要线程的优先级比较低导致非主要线程得不到系统资源调度，从而阻塞游戏主逻辑线程的运行，从而使得游戏应用出现丢帧的现象。
当然，实际应用中还可以存在其他高负载场景导致游戏应用丢帧的示例，本申请不再一一举例。
为了降低游戏应用丢帧的现象，本申请实施例提供了一种资源调度方法，可以在游戏应用在前台运行时，对游戏应用中的部分线程进行动态调度干预，例如，提高部分线程的优先级，将部分线程进行绑核处理等，使得游戏应用中的部分线程比较容易得到系统资源。另外，在游戏应用出现丢帧现象时，若存在后台应用的线程抢夺系统资源的情况，还可以将非前台应用的线程迁移到其他小核上运行，避免后台应用的线程抢夺系统资源。
下面将详细描述本申请实施例提供的资源调度方法。
参见图2，为本申请实施例提供的对游戏应用丢帧时游戏应用的CoreThread(核心线程)的分析示意图，其中，黑色线条部分表示run状态，非黑色线条部分表示runnable状态，线条粗细表示处于对应的状态期间的时长。
通过图2可以理解，在丢帧期间，游戏应用中的CoreThread长时间处于runnable状态，由于得不到系统资源，所以，一直无法进入run状态，导致无法唤醒游戏应用的主逻辑线程。
参见图3，为本申请实施例提供的对游戏应用丢帧时应用的WorkerThread(工作线程)的分析示意图，其中，黑色线条部分表示run状态，非黑色线条部分表示runnable状态，线条粗细表示处于对应的状态期间的时长。
通过图3可以理解，在丢帧期间，游戏应用中的WorkerThread长时间处于runnable状态，由于得不到系统资源，所以，一直无法进入run状态，导致无法唤醒游戏应用的主逻辑线程。
经过分析发现游戏应用丢帧的直接原因为CoreThread和WorkerThread在高负载场景下由于nice值比较高或者系统资源有限，一直得不到系统资源而长时间处于runnable状态。通常，线程的nice值越高，优先级越低。
游戏应用的主逻辑线程UnityMain概率性的被CoreThread和WorkerThread唤醒，最终导致主逻辑线程UnityMain长时间处于sleep状态而导致游戏应用丢帧，出现游戏应用画面卡顿的现象。
所以，在解决游戏应用丢帧时，首先需要解决的是CoreThread和WorkerThread得不到系统资源调度的问题。
在实际应用中，可以通过在监测到高负载场景时，降低这两个线程(CoreThread和WorkerThread)的nice值以提高这两个线程被系统资源调度的优先级；当然，即使两个线程被系统资源调度的优先级提高，也需要有足够的系统资源，所以，为了进一步降低游戏应用丢帧的概率，还可以将一些后台运行的应用的线程迁移到其他核上运行，以保证更多的系统资源供给游戏应用。
如前所述，高负载场景可能为多窗口模式下出现的场景，还可能为后台应用被唤醒时出现的场景，下面首先描述一种高负载场景的判断过程。
参照图4，为本申请实施例提供的一种高负载场景的判断逻辑示意图，该示意图以游戏应用在前台运行为基础。
步骤S401，判断当前是否为多窗口模式。
本申请实施例中，电子设备中的多窗口模式表示两个应用在前台运行，且两个应用的界面以并排的方式或者上下的方式同时显示。
以并排的方式显示为例，可以为上半部分显示一个应用的窗口，下半部分显示另一个应用的窗口；还可以为左半部分显示一个应用的窗口，右半部分显示另一个应用的窗口。
以上下的方式显示为例，可以为下方全屏显示一个应用的窗口，在全屏显示的应用的窗口上方以悬浮窗的方式显示另一应用的窗口。
在当前为多窗口模式的情况下，执行步骤S402。
步骤S402，判断前台运行的游戏应用(可以记为第一应用)之外的另一应用(可以记为第二应用)是否为高负载应用。
本申请实施例中，多窗口模式下通常有两个应用在前台运行显示，其中一个应用为游戏应用，另一个应用可以为任何可以以多窗口模式运行的应用。
在实际应用中，可以对应用进行划分，一类为高负载应用，一类为低负载应用。高负载应用和低负载应用的划分可以以应用运行时消耗的系统资源的大小作为判断条件。
作为高负载应用的示例，视频通话类应用(例如，支持进行视频通话的应用程序)为高负载应用；作为低负载应用的示例，计算器应用为低负载应用。当然，哪个应用属于高负载应用，哪个应用属于低负载应用可以由开发人员根据各个应用运行时消耗的系统资源大小进行划分。本申请实施例对高负载应用和低负载应用具有为哪些应用不做限制。
若另一应用为高负载应用，则执行步骤S405：游戏应用的线程自由调度。本申请实施例中，由于另一应用也为高负载应用，所以，相当于两个应用均需要较多的系统资源调度，这种情况下，若将更多的系统资源供给游戏应用，则会导致另一应用出现异常，所以，游戏应用的两个线程可以自由调度，同时，另一应用的线程也可以自由调度。若另一应用不为高负载应用，则执行步骤S403。
步骤S403，判断当前芯片是否为2+6架构芯片。
本申请实施例中，2+6架构芯片表示大小核架构，即该款芯片有2个大核，6个小核。这种架构的芯片相比于目前比较流行的高性能芯片(例如，1个超大核，3个大核和4个小核)的性能稍微差一些，所以，在采用这种架构的芯片的电子设备中更容易出现高负载场景。当然，本申请实施例中，2+6架构芯片仅为低性能芯片的一个示例，在实际应用中，还可能为其他低性能芯片，例如，2个大核和4个小核。本申请实施例对小核的数量不做限制本申请实施例对此不做限制。
若当前芯片不为2+6架构芯片，则执行步骤S405：游戏应用的线程自由调度。
本申请实施例中，若不为2+6架构芯片，则默认采用性能较好的芯片，这种情况下，相当于芯片的性能较高，同时另一应用为低负载应用，所以，可以控制游戏应用的线程自由调度。
若当前芯片为2+6架构芯片，则执行步骤S404。
步骤S404，执行游戏应用的动态绑核策略。
本申请实施例中，由于采用2+6架构这种相对性能较差的芯片时，即使另一应用为低负载应用(本身对系统资源的占用较少)，也比较容易出现高负载场景，所以，需要执行一些优化策略，以将系统资源更多的供给游戏应用的两个线程。而游戏应用的动态绑核策略用于将系统资源更多的向游戏应用的两个线程供给。
作为示例，可以降低游戏应用中两个线程的nice值以提高系统资源调度的优先级或者进行绑核操作(例如，绑定到某个比较空闲的核上)，具体可参照后续实施例的描述。
步骤S405，游戏应用的线程自由调度。
本申请实施例中，若步骤S402的判断结果为另一应用为高负载应用，则两个应用均需要较多的系统资源，不能为了降低游戏应用的丢帧而导致另一应用的异常(例如，丢帧卡顿等)。因此，执行步骤S405游戏应用的线程(包括主逻辑线程和渲染线程)自由调度。
若另一应用为低负载应用，但是芯片不为2+6架构的芯片，则目前为高性能芯片，兵器而另一应用对系统资源的需求本身较少，这种情况下，较少出现高负载场景，所以，执行步骤S405游戏应用的线程(包括主逻辑线程和渲染线程)自由调度。
图4所示实施例的流程，可以在检测到游戏应用切换到前台运行时开始执行。另外，游戏应用在前台运行时，还可以持续监测游戏应用的丢帧情况，以根据丢帧情况执行出现丢帧时对应的策略。所以，对游戏应用的丢帧情况的监测也可以在游戏应用切换到前台运行时开始执行。
基于上述描述可以理解，无论是步骤S404还是步骤S405之后，均会持续监测游戏应用的丢帧情况，以执行丢帧时对应的策略，在出现丢帧时采取何种策略可以参照后续实施例的描述。
当然，在游戏应用切换到后台运行时，上述执行过的动态绑核策略或根据丢帧情况执行过的策略需要恢复为系统默认策略(例如，自由调度等)。
为了更清楚的理解在多窗口模式下执行的游戏应用的动态绑核策略，下面首先详细描述步骤S404的详细内容。
参照图5，为本申请实施例提供的一种动态绑核策略对应的流程示意图。
步骤S501，判断游戏应用的帧率是否为60帧。
本申请实施例中，王者荣耀作为游戏应用的一个示例，自身的帧率包括30、60、90和120四个档位。当然，随着电子设备的不断升级，电子设备中安装的应用还可能出现更高的帧率，或者其他档位的帧率，本申请对此不做限制。通常，从30帧升到60帧，从用户的角度，画面的质感、清晰度等会有明显提升。但是从60帧升到90帧甚至更高的帧率，从用户的角度，用户主观判断的质感、清晰度已经没有明显提升，所以，目前主流的电子设备均支持王者荣耀60帧的设置。当然，60帧仅作为第一帧率的一个示例，在实际应用中，第一帧率还可以为大于30帧每秒的另一帧率。
通常在王者荣耀设置为30帧每秒的帧率时，电子设备的CPU资源还会有剩余，所以，在30帧时，游戏应用和另一应用均可以自由调度，当然，也可以设置游戏应用绑核，另一应用自由调度等，本申请实施例对游戏应用帧率为30帧时的策略不做限制。
一些高端设备可以支持90帧、120帧甚至更高的帧率，在相对较高的帧率时，对系统资源的消耗会增加。另外在多窗口模式下两个应用也会抢夺CPU资源可能并不稳定，所以，在多窗口模式下(游戏应用和另一应用以多窗口模式运行)，对于90帧和120帧(更高的也可以)均限制为60帧的帧率，高端设备基本可以保证60帧的帧率时画面稳定和流畅，所以，王者荣耀和另一应用均可以自由调度。
鉴于上述原因，本申请实施例将主要针对中低端芯片(例如2+6芯片)上王者荣耀的60帧的帧率的场景。
步骤S502，若游戏应用的帧率不为60帧，则在王者荣耀的线程存在绑核时，将绑核的线程解除绑核，设置游戏应用的线程自由调度。
通过前面的分析可以理解，在王者荣耀的帧率不为60帧时，则为30帧的帧率。即若游戏应用的帧率不为60帧，若王者荣耀的线程存在绑核的情况，还可以将已经绑核的线程解除绑核，并设置王者荣耀的线程自由调度。
步骤S503，若游戏应用的帧率为60帧，则判断游戏应用的主逻辑线程单位时长的耗时占比是否小于0.7。
在一些中低端芯片(以2+6架构芯片为例)上，由于性能跨度比较大、热限频、交互场景限频等因素，可以针对王者荣耀的两个线程进行动态管控。
由于王者荣耀的那两个线程会概率性的唤醒游戏主逻辑线程，所以，在进行动态管控时，既需要将系统资源优先供应给这两个线程，又需要避免这两个线程阻塞主逻辑线程和渲染线程(即UnityGfx)的运行或者抢夺主逻辑线程及渲染线程的资源。所以，王者荣耀的帧率为60帧时，可以根据单位时长的主逻辑线程的耗时占比确定如何绑核。其中，单位时长主逻辑线程的耗时占比可以评估芯片的性能，以根据芯片的性能确定如何绑核。
步骤S504，若主逻辑线程单位时长的耗时占比不小于0.7，降低CoreThread及WorkerThread的nice值，将CoreThread及WorkerThread绑定到小核运行。
本申请实施例中，若单位时间内UnityMain总的耗时占比高于0.7，则说明当前芯片属于中低端芯片中性能较差的产品，此时CoreThread及WorkerThread应调整至小核,以保证大核中主逻辑线程(UnityMain)及渲染线程(UnityGfx)的资源供给，为了使得CoreThread及WorkerThread在小核运行时有限得到系统资源，可以降低CoreThread及WorkerThread的nice值，以提高被系统资源调度的优先级。
步骤S505，若主逻辑线程单位时长的耗时占比不小于0.7，则继续判断主逻辑线程单位时长的耗时占比是否小于0.5。
步骤S506，若主逻辑线程单位时长的耗时占比不小于0.5，则将CoreThread绑至大核,将WorkerThread绑至小核。
本申请实施例中，如果单位时间内UnityMain线程总的耗时占比介于0.5-0.7之间,则为中低端芯片中性能一般的产品，此时CPU资源会略有余量，在实际监测中发现，CoreThread比WorkerThread唤醒UnityMain的概率要高，所以，将CoreThread绑至大核，将WorkerThread绑至小核，从而降低CoreThread唤醒UnityMain的场景下的主逻辑线程的等待时间。
步骤S507，若主逻辑线程单位时长的耗时占比小于0.5，降低CoreThread和WorkerThread的nice，设置CoreThread和WorkerThread自由调度。
本申请实施例中，若单位时间内UnityMain线程总的耗时占比小于0.5,则为中低端芯片中性能较好的产品，此时可以降低CoreThread及WorkerThread的nice值，设置CoreThread及WorkerThread自由调度。
上述实施例中，单位时间内主逻辑线程的总耗时占比可以根据一段时间之内的主逻辑线程的平均总耗时占这段时间的比例确定。通常，芯片和应用确定的情况下，主逻辑线程的耗时占比的差异比较小。所以，该段时间主逻辑线程的耗时占比可以为任意一段时间内的主逻辑线程的耗时占比。当然，也存在一些例外的情况，例如，在同一芯片平台上，限频场景和未限频场景也可能出现主逻辑线程耗时占比差异比较大的现象。作为示例，未限频之前单位时间内UnityMain线程耗时占比小于0.5，属于性能较好的一类；限频之后主逻辑线程耗时占比介于0.5-0.7之间，此时属于性能一般的一类。其中，数值0.5作为第一值的一个示例，数值0.7作为第二值的一个示例，在实际应用中，第一值和第二值还可以选择其他数值，第二值大于第一值。
所以，本申请实施例不仅可以应用在不同芯片平台上，也可以应用在同一芯片平台上。
通过上述示例可以理解，上述实施例在第一应用和第二应用以多窗口模式运行时，根据多个条件确定具体的资源调度策略，具体可以包括如下情况：
在第一应用为预设应用(例如，王者荣耀)、第二应用为高负载应用时，对第一应用的线程自由调度。
在第一应用为预设应用、第二应用为低负载应用、电子设备的中央处理器为预设的高性能芯片(非2+6)时，对所述第一应用的线程自由调度。
在第一应用为预设应用、第二应用为低负载应用、电子设备的中央处理器为预设的低性能芯片(2+6)、电子设备的帧率为第一帧率(例如，30帧)时，对第一应用的线程自由调度(存在绑核的线程解除绑核)。
在第一应用为预设应用、第二应用为低负载应用、电子设备的中央处理器为预设的低性能芯片、电子设备的帧率为第二帧率(例如，60帧)、第一应用的主逻辑线程耗时占比大于第二值(0.7)时，降低CoreThread和WorkerThread的nice值，将CoreThread和WorkerThread绑到小核。
在第一应用为预设应用、第二应用为低负载应用、电子设备的中央处理器为预设的低性能芯片、电子设备的帧率为第二帧率、第一应用的主逻辑线程耗时占比大于第一值(0.5)、小于第二值(0.7)时，将CoreThread绑到大核、将WorkerThread绑到小核。
在第一应用为预设应用、第二应用为低负载应用、电子设备的中央处理器为预设的低性能芯片、电子设备的帧率为第二帧率、第一应用的主逻辑线程时长占比小于第一值(0.5)时，降低CoreThread和WorkerThread的nice值，对第一应用的线程自由调度。
需要说明，在实际应用中，还可以将上述进行两个线程绑核时的一些限制条件去掉，或者增加一些其他的限制条件，作为将游戏应用中的两个线程绑核的条件，本申请实施例不再一一举例。
当然，在游戏应用切换到后台时，需要将执行的绑核策略恢复为系统默认状态，即取消对应的绑核限制。
目前，可以将焦点应用进行绑核以降低焦点应用丢帧的情况发生，具体可以参照图6所示实施例。
步骤S601，检测到焦点应用的切换。
焦点应用是在前台运行的应用中，用户当前正在进行交互的应用。若当前为一个应用的单窗口模式，则该应用为焦点应用；若当前为两个应用在前台以多窗口模式运行，用户点击其中一个应用的界面或者界面上的控件之后，该应用则为焦点应用；若用户点击另一个应用的界面或者界面上的控件之后，则该另一应用为焦点应用。
步骤S602，判断切换后的焦点应用是否为游戏应用。
步骤S603，若焦点应用为游戏应用，则将游戏应用进行绑核。
步骤S604，若焦点应用不为游戏应用，则将游戏应用取消绑核。
这种方式使得焦点应用在另一应用时，系统资源将倾向于另一应用，对于多窗口模式下的游戏应用很可能得到不到系统资源，导致丢帧情况的发生。
本申请实施例相比于通过将系统资源向焦点应用更多的供应的技术方案具有更大的灵活性，也更能够根据实际复杂情况确定合适的策略，从而使得游戏应用丢帧的情况降低。
上述列举的绑核策略对应的限制条件以游戏应用在前台运行、且游戏应用和另一应用以多窗口模式运行为主，在实际应用中，若在游戏应用在前台以多窗口模式运行时，对游戏应用的线程做过了绑核，那么即使从多窗口模式下切换到游戏应用单窗口模式下，对游戏应用的线程的绑核策略可以继续生效；当然，在从游戏应用单窗口模式下切换到游戏应用多窗口模式下时，游戏应用已经生效的绑核策略继续生效，在游戏应用退到后台的情况下，再取消游戏应用的绑核限制。
所以，上述多窗口模式下的实施例也适用于游戏应用的单窗口模式(在前台运行显示一个应用的界面，该应用为游戏应用)。基于上述描述，本申请还提供另一资源调度方法的流程示意图。
参照图7，为本申请实施例提供的另一资源调度方法。
步骤S701，检测到窗口切换。
步骤S702，判断窗口切换后在前台运行的应用中是否包含游戏应用。
本申请实施例中，上述举例的多窗口模式下的策略均适用于单窗口模式下的游戏应用。所以，无论当前为单窗口模式还是多窗口模式，前台运行的应用中存在游戏应用时，均适用于上述列举的策略。
步骤S703，若前台运行的应用中不包含游戏应用，则将游戏应用取消绑核，将游戏应用在前台运行时绑定的其他应用的线程也取消绑核。
本申请实施例中，若游戏应用中的部分线程进行了绑核，则需要将绑定核的线程和所绑定的核之间的绑定关系解除，恢复为系统默认的状态，例如，系统默认的状态为自由调度时，则设置游戏应用的线程为自由调度。当然，取消绑核仅适用于在游戏应用在前台运行期间绑定核的线程，若系统默认的某些线程一直绑定在某个核上，则这种情况下，不需要取消该线程的绑核。
同理，若游戏应用在前台运行期间，通过本申请实施例提供的资源调度方法，其他应用绑定了核的线程也需要取消绑核。这是由于，其他应用若绑核，也是由于游戏应用在前台运行才会出现的绑核策略，所以，在游戏应用退回到后台运行时，将游戏应用在前台运行期间，为了将系统资源更多的向游戏应用供给进行的其他应用的绑核也取消。
步骤S704，若窗口切换后在前台运行的应用中是否包含游戏应用，则确定游戏应用是否已经绑核。
本申请实施例的场景可能由多窗口模式下的游戏应用切换到单窗口模式下的游戏应用，这种情况，游戏应用中的线程可能已经进行了绑核，当然，也可能未绑核；也可能为单窗口模式下的游戏应用切换到多窗口模式下的游戏应用，这种情况，游戏应用中的线程可能已经进行了绑核(多窗口模式下绑核切换到单窗口模式下，再切换到多窗口模式下时可能已经进行绑核)，当然，也可能未绑核。
在实际应用中，若已经进行了绑核，则无需再次判断是否需要进行绑核；若还未进行绑核，则可以判断是否需要进行绑核。
步骤S705，若游戏应用还未绑核，则判断游戏应用是否需要绑核，并在需要绑核时进行绑核。
该动态绑核策略可以参照图4和图5所示实施例中的描述，当然，也可以参照上述实施例在第一应用和第二应用以多窗口模式运行时，根据多个条件确定具体的资源调度策略。
步骤S706，在步骤S704确定游戏应用已经绑核或者步骤S705之后，继续监测游戏应用的丢帧情况。
如前所述，游戏应用在前台运行时，可以持续监测游戏应用的丢帧情况，以根据丢帧情况确定需要执行的策略。
步骤S707，若有丢帧情况，则判断另一应用的线程是否绑定在小核。
本申请实施例可以在游戏应用丢帧后，将影响游戏应用丢帧的线程或进程限制在小核运行。
在实际应用中，在多窗口模式下，通常另一应用的线程会和游戏应用的线程抢夺资源，所以，这种情况下，可以限制另一应用的线程到小核运行。
当然，在实际应用中，可以首先确定该另一应用的线程是否已经限制到小核运行。
若已经限制在小核运行，则无需再限制另一应用的线程到小核运行，若还未限制在小核运行，则需要将另一应用的线程绑定到小核运行。
步骤S708，若另一应用的线程还未绑定在小核，则将另一应用的线程绑定在小核运行。
当然，在实际应用中，另一应用的线程绑定的小核和游戏应用的线程绑定的小核可以相同也可以不同，通常可以根据小核中的剩余资源确定绑定到哪个小核运行。
游戏交互场景下的另一应用多为短视频/微信消息类应用,正常情况下另一应用自身负载相比游戏应用较低，即使将另一应用的线程迁移小核也不会对另一应用性能及主观体验造成明显影响。
通过上述示例可以理解，在监测到游戏应用丢帧时，也需要执行相应的策略，以将系统资源更多的供给游戏应用，从而降低游戏应用丢帧的情况发生。
上述将另一应用的线程迁移到小核运行仅作为出现丢帧时的策略的一个示例，并且上述示例需要在游戏应用的多窗口模式下，才会存在另一应用。所以，本申请实施还提供了另一种监测到游戏应用丢帧时执行的策略，该策略可以适用于游戏应用的多窗口模式，也可以适用于游戏应用的单窗口模式。
参照图8，为本申请实施例提供的另一种资源调度方法的流程示意图，该示意图以游戏应用在前台运行为基础，游戏应用可以为单窗口模式，也可以多窗口模式。
步骤S801，监测游戏应用的丢帧情况。
本申请实施例中，游戏应用丢帧情况用于判断系统的负载情况，在系统负载较高时，可以诊断丢帧的原因，从而执行相应的策略，以降低游戏应用丢帧的情况。所以，可以设置具体的丢帧诊断条件。
作为一个示例，在监测到游戏应用有丢帧的情况下，就认为满足丢帧诊断条件。
作为另一示例，在单位时长内监测到丢帧的数量大于预设数量，才认为满足丢帧诊断条件。这种情况可以避免偶发的丢帧导致的误判。
作为另一示例，还可以设置多个周期内有丢帧现象的周期是否占比大于一定比例时，满足丢帧诊断条件。例如，最近的5个时间周期内，有3个时间周围均监测到有丢帧，就认为满足丢帧诊断条件。
步骤S802，判断是否满足丢帧诊断条件。
步骤S803，若满足丢帧诊断条件，则判断CPU芯片的频率是否设置为最高。
本申请实施例中，CPU芯片的频率为CPU芯片的时钟频率，可以反映CPU运行速度的快慢。通常，CPU芯片的频率可以在某个区间内设置，或者可以设置为多个不同的值。本申请实施例中的最高表示允许设置的最高值。
本申请实施例中，通过CPU频率的判断将丢帧原因进行归类，需要确定是限频的干扰，还是其他线程抢夺资源导致。
若丢帧时CPU芯片的频率不是最高，这种情况下，可能是由于芯片发热(或者其他原因)导致对芯片的频率进行限频了，这种情况下，可能是芯片本身性能的原因。
若丢帧时CPU芯片的频率已经最高，则可能是其他线程抢夺资源导致，所以，可以确定是否有后台应用被唤醒。
步骤S804，在步骤S803的判断结果为CPU芯片频率未最高的情况下，判断系统是否进行热限频或调度限频等。
若未进行热限频或调度限频的情况下，说明可能是由于其他原因设置为限频，例如，用户为了省电，不考虑丢帧情况，将CPU频率设置较低，这种情况，无需进行资源调度。
若系统进行了热限频或调度限频的情况下，可能还是由于后台负载太高导致，所以，需要确定是否有后台应用被唤醒。
步骤S805，查看是否有后台应用被唤醒。
本申请实施例中，若CPU芯片频率设置为最高，则可能是其他线程抢夺资源，这种情况下，可能是后台应用被唤醒后后台应用抢夺系统资源导致丢帧，若后台应用未被唤醒，则不为后台应用抢夺系统资源导致，这种情况下，需要执行其他策略，例如，查看是否有其他应用的线程抢夺了系统资源或者是否有系统的进程抢夺了系统资源等，具体可参照后续实施例的描述。
步骤S806，若后台应用被唤醒，则将后台被唤醒应用的线程绑定到小核运行。
在本申请实施例中，若后台应用被唤醒，可能是由于后台应用接收到消息被唤醒的情况，但是，大部分应用由于接收到消息被唤醒并弹窗显示的情况还会快速进入冷冻状态(该状态与唤醒状态相对，即非唤醒状态)，这种情况通常不会抢夺前台运行的游戏应用的系统资源，所以无需针对该情况进行特殊的资源调度；也会偶尔在接收到消息被唤醒并弹窗显示后启动该后台应用的其他线程从而保持唤醒状态，这种情况就会抢夺前台运行的游戏应用的系统资源；一般而言，后台应用对性能或时效的要求并不高，所以，这种情况下可以尽量使得系统资源优先供应给前台游戏应用，所以，可以将后台被唤醒的应用绑定到小核，等到该后台应用处于非唤醒状态后，再取消该后台应用的绑核，当然，实际应用中，由于该后台应用还可能再次被唤醒，所以，也可以在该后台应用处于非唤醒状态后，继续执行该后台应用的绑核，当游戏应用不在前台运行时，再取消该后台应用的绑核。
步骤S807，若无后台应用被唤醒，则确定是否有其他线程抢夺系统资源。
若无后台应用被唤醒，还可能是其他线程或进程抢夺了系统资源，具体可以参照后续实施例的描述。
在本申请实施例中，还有一种情况，后台应用被其他方式唤醒(非接收到消息弹窗显示的情况)并未弹窗，这种情况持续会相对较长，所以，为了保证前台游戏应用的资源供给，可以参照图5所示实施例中，多窗口模式下游戏应用的绑核策略执行。
在本申请实施例中，后台应用未被唤醒的情况下，还需要确定是否有其他线程抢夺系统资源。
下面将通过图9所示实施例描述该两种情况。
步骤S804，判断后台应用是否被唤醒。
步骤S901，若后台应用被唤醒，则确定后台被唤醒的应用是否由于接受到消息被唤醒。
本申请实施例中，在确定是由于接收到消息被唤醒的情况下，可以将后台被唤醒的应用绑到小核运行，并在后台被唤醒的应用由唤醒状态进入冷冻状态后，解除绑核。
在确定不是由于接收到消息被唤醒的情况下，该后台被唤醒的应用可能保持唤醒状态的时间较长，会抢夺系统资源，这种情况下，相当于另一应用和前台运行的游戏应用同时在争夺系统资源，所以，可以参照步骤S404，即图5所示实施例的资源调度方法，根据负载情况，将游戏应用的线程进行绑核处理。
步骤S902，若无后台应用被唤醒，则判断游戏其他线程是否抢占大核资源。
本申请实施例中，可以判断丢帧期间游戏其他线程是否在大核上运行，确定游戏其他线程是否抢占大核资源。
步骤S903，若游戏其他线程抢占大核资源，则将游戏其他线程绑到小核。
步骤S904，若游戏其他线程未抢占大核资源，则判断系统进程是否抢占系统资源。
本申请实施例中，可以判断丢帧期间系统进程是否在大核上运行，确定系统进程是否抢占大核资源。
若系统进程未抢占大核资源，则表示芯片本身能力原因，可以维持当前的资源调度策略，或者降低游戏应用中在大核运行的线程的nice值。
步骤S905，若系统进程抢占大核资源，则判断小核是否具有空闲资源。
如果是系统进程抢占资源，如dex2oat应用优化之类的线程，可监测丢帧时间段内小核是否具有空闲资源(即小核的负载情况)。
步骤S906，若小核有空闲资源，则将系统进程迁移到小核。
本申请实施例中，若小核中各线程总计耗时占比小于0.8(仅作为第三值的一个示例，在实际应用中，还可以为其他值)，则小核仍有余量资源，可将大核上的抢核线程迁移小核，游戏CoreThread及WorkerThread参照WMS多窗口策略下UnityMain耗时占比进行绑核调整，即图5所示实施例中CoreThread及WorkerThread的绑核策略。
步骤S907，若小核无空闲资源，则将游戏线程的nice值降低，取消游戏绑核。
本申请实施例中，若小核中各线程总计耗时占比大于或等于0.8，此时大小核负载均极高，可认为CPU并无余量资源，此时降低游戏CoreThread及WorkerThread的nice后取消绑核限制，以尽可能高效得到各CPU资源调度,降低线程Runnable时长。
在实际应用中，只要有一个小核中的每个线程的运行时长的和占比(统计总时长之内各个线程运行时长之和占统计总时长)小于0.8，就表示该小核有空闲资源。
若6个小核中，没有一个小核中的每个线程的运行时长的和占比(统计总时长之内各个线程运行时长之和占统计总时长)小于0.8，则说明没有小核有空闲资源，即各个小核负载均较高。
参照图10，为本申请实施例提供的另一种资源调度方法。该方法中和前面实施例重复的步骤将不再详细描述，具体可参照前面所示实施例的详细描述。
本申请实施例中，通过AGP帧率模块监测帧率，通过DynamicWinFrame滑动帧窗口模块提供实时丢帧信息。由Iaware模块汇总这些信息。
步骤S101，是否监测到游戏应用间隔性丢帧。
间隔性丢帧可以作为丢帧诊断条件，该条件的设置用于避免偶发的丢帧造成误判，所以，可以设置间隔性丢帧为在单位时长内监测到丢帧的数量大于预设数量或者多个周期内有丢帧现象的周期是否占比大于一定比例时，满足丢帧诊断条件。当然，还可以设置间隔性丢帧的其他判断规则。本申请实施例对此不做限制。
步骤S102，在监测到游戏应用间隔性丢帧的情况下，确定非限频场景下频率是否最高。
步骤S103，在确定非限频场景下频点最高时，判断大核资源是否被后台应用的线程抢占。
步骤S104，若大核线程被后台应用的线程抢占，则将后台应用线程迁移到小核。
步骤S105，判断绑到小核的后台应用是否处于唤醒状态。
步骤S106，若绑到小核的后台应用处于唤醒状态，则等待预设的时间，并在等待预设时间后继续判断该后台应用是否处于唤醒状态。
步骤S107，若绑到小核的后台应用未处于唤醒状态，则将该后台应用取消绑核。
通过上述实施例的描述，基于监测到丢帧(满足丢帧诊断条件)这一场景后对应的实施例可以得到如下几种资源调度策略：
CPU芯片的频率最高(或者不是最高，但是原因为热限频或调度限频)、后台应用被唤醒、被唤醒原因为接收到消息，则后台应用线程迁到小核。
CPU芯片的频率最高(或者不是最高，但是原因为热限频或调度限频)、后台应用被唤醒，被唤醒原因不是因为接收到消息，则执行多窗口模式下游戏应用的线程的绑核策略。
CPU芯片的频率最高(或者不是最高，但是原因为热限频或调度限频)、后台应用未被唤醒、游戏其他线程抢占大核资源，则抢占大核资源的游戏其他线程迁移到小核。
CPU芯片的频率最高(或者不是最高，但是原因为热限频或调度限频)、后台应用未被唤醒、系统进程抢占大核资源、小核有资源，则系统进程迁移到小核。
CPU芯片的频率最高(或者不是最高，但是原因为热限频或调度限频)、后台应用未被唤醒、系统进程抢占大核资源、小核无资源，则系统进程迁移到小核、游戏主要线程取消绑核、调低nice值。
当然，在后台应用从唤醒状态(也可以理解为活动状态)切换为非唤醒状态(非活动状态)后，将后台应用绑核的线程解除绑核。
在游戏应用切换到后台运行后，解除在游戏应用的丢帧数量或丢帧频率满足丢帧诊断条件时执行的绑核。
应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。
本申请实施例还提供了一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，计算机程序被处理器执行时可实现上述各个方法实施例中的步骤。
本申请实施例还提供了一种计算机程序产品，当计算机程序产品在第一设备上运行时，使得第一设备可实现上述各个方法实施例中的步骤。
集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实现上述实施例方法中的全部或部分流程，可以通过计算机程序来指令相关的硬件来完成，的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，计算机程序包括计算机程序代码，计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。计算机可读介质至少可以包括：能够将计算机程序代码携带到第一设备的任何实体或装置、记录介质、计算机存储器、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、电载波信号、电信信号以及软件分发介质。例如U盘、移动硬盘、磁碟或者光盘等。在某些司法管辖区，根据立法和专利实践，计算机可读介质不可以是电载波信号和电信信号。
本申请实施例还提供了一种芯片系统，芯片系统包括处理器，处理器与存储器耦合，处理器执行存储器中存储的计算机程序，以实现本申请任一方法实施例的步骤。芯片系统可以为单个芯片，或者多个芯片组成的芯片模组。
在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及方法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围，均应包含在本申请的保护范围之内。

Claims (13)

1.一种资源调度方法，其特征在于，包括：
电子设备显示第一应用的界面和第二应用的界面；
在所述第一应用为游戏应用、所述第二应用不为视频通话类应用、所述电子设备的中央处理器包括两个大核和N个小核、所述电子设备的帧率为第一帧率、所述第一应用的主逻辑线程的运行时长占比大于第一值时，所述电子设备将所述第一应用的核心线程和工作线程进行绑核，所述电子设备提高所述核心线程和所述工作线程被系统资源调度的优先级，所述核心线程和所述工作线程用于概率性的唤醒所述主逻辑线程，所述第一帧率大于30帧每秒，N为大于或等于4的自然数。
2.如权利要求1所述的方法，其特征在于，在所述第一应用为游戏应用、所述第二应用不为视频通话类应用、所述电子设备的中央处理器包括两个大核和N个小核，所述电子设备的帧率为第一帧率、所述第一应用的主逻辑线程的运行时长占比大于第一值时，所述方法还包括：
所述第一应用的主逻辑线程的运行时长占比小于第二值时，将所述第一应用的核心线程绑定到大核运行，所述电子设备将所述第一应用的工作线程绑定到小核运行；
所述第一应用的主逻辑线程的运行时长占比大于或等于所述第二值时，所述电子设备将所述第一应用的核心线程和工作线程绑定到小核运行。
3.如权利要求1所述的方法，其特征在于，在所述电子设备显示第一应用的界面和第二应用的界面时，所述方法还包括：
在所述第一应用为游戏应用、所述第二应用为视频通话类应用时，所述电子设备对所述第一应用的核心线程和工作线程自由调度；
在所述第一应用为游戏应用、所述第二应用不为视频通话类应用、所述电子设备的中央处理器的性能优于采用两个大核和N个小核的中央处理器时，所述电子设备对所述第一应用的核心线程和工作线程自由调度；
在所述第一应用为游戏应用、所述第二应用不为视频通话类应用、所述电子设备的中央处理器包括两个大核和N个小核、所述电子设备的帧率为第二帧率时，所述电子设备对所述第一应用的核心线程和工作线程自由调度，所述第二帧率小于所述第一帧率；
在所述第一应用为游戏应用、所述第二应用不为视频通话类应用、所述电子设备的中央处理器包括两个大核和N个小核、所述电子设备的帧率为第一帧率、所述第一应用的主逻辑线程时长占比小于或等于第一值时，所述电子设备提高所述第一应用的核心线程和工作线程的优先级，对所述第一应用的核心线程和工作线程自由调度。
4.如权利要求1所述的方法，其特征在于，所述方法还包括：
在所述电子设备显示的界面不包括所述第一应用的界面时，所述电子设备解除所述第一应用的核心线程和工作线程的绑核。
5.如权利要求1至4任一项所述的方法，其特征在于，所述方法还包括：
所述电子设备显示的界面包括所述第一应用的界面时，所述电子设备监测所述第一应用是否丢帧；
在所述第一应用的丢帧数量或丢帧频率满足丢帧诊断条件、在丢帧期间有后台应用被唤醒时，所述电子设备将被唤醒的后台应用的线程绑定到小核。
6.如权利要求5所述的方法，其特征在于，所述在所述第一应用的丢帧数量或丢帧频率满足丢帧诊断条件、在丢帧期间有后台应用被唤醒时，所述电子设备将被唤醒的后台应用的线程绑定到小核，包括：
在所述第一应用的丢帧数量或丢帧频率满足丢帧诊断条件、所述电子设备的中央处理器的频率为可设置的最高值、在丢帧期间有后台应用被唤醒时，所述电子设备将被唤醒的后台应用的线程绑定到小核。
7.如权利要求6所述的方法，其特征在于，在所述第一应用的丢帧数量或丢帧频率满足丢帧诊断条件、所述电子设备的中央处理器的频率为可设置的最高值、在丢帧期间有后台应用被唤醒时，所述电子设备将被唤醒的后台应用的线程绑定到小核，包括：
在所述第一应用的丢帧数量或丢帧频率满足丢帧诊断条件、所述电子设备的中央处理器的频率为可设置的最高值、在丢帧期间有后台应用被唤醒且接收到消息时，所述电子设备将被唤醒的后台应用的线程绑定到小核。
8.如权利要求7所述的方法，其特征在于，所述方法还包括：
在所述第一应用的丢帧数量或丢帧频率满足丢帧诊断条件、所述电子设备的中央处理器的频率为可设置的最高值、在丢帧期间有后台应用被唤醒且未接收到消息、所述第一应用的主逻辑线程的运行时长占比大于第一值时，所述电子设备将所述第一应用的核心线程和工作线程进行绑核。
9.如权利要求5所述的方法，其特征在于，在监测所述第一应用是否丢帧期间，所述方法还包括：
在所述第一应用的丢帧数量或丢帧频率满足丢帧诊断条件、在丢帧期间无后台应用被唤醒、在丢帧期间所述第一应用的其他线程占用大核资源时，所述电子设备将所述第一应用的其他线程绑定到小核，所述第一应用的其他线程为所述第一应用的线程中所述主逻辑线程、所述核心线程和所述工作线程以外的线程。
10.如权利要求9所述的方法，其特征在于，所述方法还包括：
在所述第一应用的丢帧数量或丢帧频率满足丢帧诊断条件、在丢帧期间无后台应用被唤醒、在丢帧期间所述第一应用的其他线程未占用大核资源、在丢帧期间系统进程占用大核资源、且至少一个小核中的线程运行总时长占比小于第三值时，所述电子设备将系统进程绑定到小核；
在所述第一应用的丢帧数量或丢帧频率满足丢帧诊断条件、在丢帧期间无后台应用被唤醒、在丢帧期间所述第一应用的其他线程未占用大核资源、在丢帧期间系统进程占用大核资源、且每个小核中的线程运行总时长占比大于或等于第三值时，所述电子设备将系统进程绑定到小核，将所述第一应用的核心线程和工作线程的优先级提高，取消所述第一应用的核心线程和工作线程的绑核。
11.如权利要求5所述的方法，其特征在于，所述方法还包括：
在所述电子设备显示的界面不包括所述第一应用的界面时，所述电子设备解除在所述第一应用的丢帧数量或丢帧频率满足丢帧诊断条件时执行的绑核。
12.一种电子设备，其特征在于，所述电子设备包括处理器，所述处理器用于运行存储器中存储的计算机程序，以使得所述电子设备实现如权利要求1至11任一项所述的方法。
13.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，所述计算机程序被一个或多个处理器执行时实现如权利要求1至11任一项所述的方法。
CN202310371732.0A 2023-03-30 2023-03-30 一种资源调度方法、电子设备及存储介质 Active CN117130771B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310371732.0A CN117130771B (zh) 2023-03-30 2023-03-30 一种资源调度方法、电子设备及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310371732.0A CN117130771B (zh) 2023-03-30 2023-03-30 一种资源调度方法、电子设备及存储介质

Publications (2)

Publication Number Publication Date
CN117130771A CN117130771A (zh) 2023-11-28
CN117130771B true CN117130771B (zh) 2024-06-04

Family

ID=88857039

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310371732.0A Active CN117130771B (zh) 2023-03-30 2023-03-30 一种资源调度方法、电子设备及存储介质

Country Status (1)

Country Link
CN (1) CN117130771B (zh)

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106296566A (zh) * 2016-08-12 2017-01-04 南京睿悦信息技术有限公司 一种虚拟现实移动端动态时间帧补偿渲染系统及方法
CN109947569A (zh) * 2019-03-15 2019-06-28 Oppo广东移动通信有限公司 绑定核心的方法、装置、终端及存储介质
CN111831438A (zh) * 2020-07-01 2020-10-27 Oppo广东移动通信有限公司 资源分配方法、装置、存储介质及电子设备
CN113204425A (zh) * 2021-04-21 2021-08-03 深圳市腾讯网络信息技术有限公司 供进程管理内部线程的方法、装置、电子设备及存储介质
CN113842642A (zh) * 2021-09-29 2021-12-28 联想(北京)有限公司 一种为游戏应用分配资源的方法及电子设备
CN113975796A (zh) * 2021-10-26 2022-01-28 努比亚技术有限公司 游戏控制方法、移动终端及计算机可读存储介质
WO2022252986A1 (zh) * 2021-06-02 2022-12-08 华为技术有限公司 中断调度方法、电子设备及存储介质

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11922220B2 (en) * 2018-11-08 2024-03-05 Intel Corporation Function as a service (FaaS) system enhancements

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106296566A (zh) * 2016-08-12 2017-01-04 南京睿悦信息技术有限公司 一种虚拟现实移动端动态时间帧补偿渲染系统及方法
CN109947569A (zh) * 2019-03-15 2019-06-28 Oppo广东移动通信有限公司 绑定核心的方法、装置、终端及存储介质
CN111831438A (zh) * 2020-07-01 2020-10-27 Oppo广东移动通信有限公司 资源分配方法、装置、存储介质及电子设备
CN113204425A (zh) * 2021-04-21 2021-08-03 深圳市腾讯网络信息技术有限公司 供进程管理内部线程的方法、装置、电子设备及存储介质
WO2022252986A1 (zh) * 2021-06-02 2022-12-08 华为技术有限公司 中断调度方法、电子设备及存储介质
CN113842642A (zh) * 2021-09-29 2021-12-28 联想(北京)有限公司 一种为游戏应用分配资源的方法及电子设备
CN113975796A (zh) * 2021-10-26 2022-01-28 努比亚技术有限公司 游戏控制方法、移动终端及计算机可读存储介质

Also Published As

Publication number Publication date
CN117130771A (zh) 2023-11-28

Similar Documents

Publication Publication Date Title
KR102392465B1 (ko) 단말기 제어 방법 및 단말기
US20240021176A1 (en) Image Processing Method Based on Vertical Sychronization Signal and Electronic Device
JP7468830B2 (ja) エネルギー効率の良い表示処理方法およびデバイス
CN112988282B (zh) 应用保活方法和终端设备
CN111132234A (zh) 一种数据传输方法及对应的终端
CN113133095B (zh) 一种降低移动终端功耗的方法及移动终端
WO2022262434A1 (zh) 一种功耗优化方法和电子设备
WO2021223539A1 (zh) 射频资源分配方法及装置
CN110687998A (zh) 一种应用管理方法及装置
WO2022017474A1 (zh) 任务处理方法及相关装置
CN113535340A (zh) 一种任务调度方法、装置及电子设备
CN115278831A (zh) 一种休眠调度方法及设备
WO2023088209A1 (zh) 一种跨设备音频数据传输的方法和电子设备
CN112684969A (zh) 始终显示方法及移动设备
CN117130771B (zh) 一种资源调度方法、电子设备及存储介质
CN114430542A (zh) 一种节能方法及终端设备
CN115729346A (zh) 界面显示方法和电子设备
CN116847145A (zh) 休眠唤醒方法及电子设备
CN114375027A (zh) 降低功耗的方法和装置
US11864111B2 (en) Downlink channel monitoring method, terminal, and storage medium
CN113453327A (zh) 一种发送功率控制方法、终端、芯片系统与系统
WO2023138533A1 (zh) 业务协同方法、电子设备、可读存储介质和芯片系统
CN114258044B (zh) 待机方法、系统及终端设备
CN116700585B (zh) 熄屏控制方法、电子设备及存储介质
US20240214939A1 (en) Power consumption optimization method and electronic device

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
GR01 Patent grant
GR01 Patent grant