CN110489228B

CN110489228B - 一种资源调度的方法和电子设备

Info

Publication number: CN110489228B
Application number: CN201910639437.2A
Authority: CN
Inventors: 曾广珠; 万承臻
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2019-07-16
Filing date: 2019-07-16
Publication date: 2022-05-17
Anticipated expiration: 2039-07-16
Also published as: CN110489228A; WO2021008543A1

Abstract

本申请提供了一种资源调度的方法和电子设备，该方法包括：电子设备接收用户的第一操作；该电子设备响应于该第一操作，获取该电子设备的前台应用；该电子设备确定该前台应用的帧绘制线程的第一过程窗口，该第一过程窗口用于指示帧绘制过程，或者，该第一过程窗口用于指示关键过程；在该第一过程窗口内，该电子设备执行步进硬件资源调度策略，该步进硬件资源调度策略为随着时间的增加，增加调度的硬件资源。本申请实施例的资源调度的方法，有助于提升资源调度的准确性。

Description

一种资源调度的方法和电子设备

技术领域

本申请涉及电子设备领域，并且更具体地，涉及一种资源调度的方法和电子设备。

背景技术

当前主流的智能终端操作系统为Android，Android系统中应用程序在前台运行时，有各种界面刷新变化的情况。尤其是，聊天会话列表中，连续多次滑动时，典型的问题是界面变化忽快忽慢，有时会有丢帧卡顿的现象，用户的体验不好。其主要原因是Android系统为了性能和功耗的平衡对中央处理器(central processing unit，CPU)资源和应用的调度上未能很好的做到按需供给、及时响应，导致后台高负载应用消耗较多功耗，而前台紧急任务无法及时获得所需的CPU资源。

传统的Android系统是基于CPU核的负载来调整CPU的工作频率，这个任务是由CPU频率的调节器来完成的。近年出现了对应用进程进行分组，前台组进程相比后台组进程具有较高的提频和用大核权重，以满足交互应用对响应及时性的要求，效能感知调度器(energy aware scheduling，EAS)就是典型的使用例子。

EAS调度器一般是基于线程粒度，将某个进程中的所有线程加入到一个调度组中，组中所有线程采用相同的调度策略。由于CPU负载变化是随机的，这可能使得EAS调度器难以应对突发的需求，从而导致其调度准确性不高。

发明内容

本申请提供一种资源调度的方法和电子设备，有助于提升资源调度的准确性。

第一方面，提供了一种资源调度的方法，该方法应用于电子设备，该方法包括：电子设备接收到用户的第一操作；该电子设备响应于该第一操作，获取该电子设备的前台应用；该电子设备确定该前台应用的帧绘制线程的第一过程窗口，该第一过程窗口用于指示帧绘制过程，或者，该第一过程窗口用于指示关键过程；在该第一过程窗口内，该电子设备执行步进硬件资源调度策略，该步进硬件资源调度策略为随着时间的增加，增加调度的硬件资源。

在一些可能的实现方式中，该步进硬件资源调度策略为对电子设备硬件资源的步进硬件资源调度策略，该调度的硬件资源包括CPU资源，该电子设备执行该步进硬件资源调度策略包括该电子设备随着时间的增加，切换CPU核(示例性的，从小核切换到中核，再切换到大核)；和/或，该电子设备调整CPU频率(示例性的，从小核的较小频率调整到大核的较大频率)。

在一些可能的实现方式中，该调度的硬件资源包括图形处理器GPU资源，该电子设备执行该步进硬件资源调度策略包括该电子设备随之时间的增加，调整GPU频率(示例性的，从较小的频率调整为较大的频率)。

在一些可能的实现方式中，该调度的硬件资源包括输入输出IO资源，该电子设备执行步进硬件资源调度策略包括该电子设备随着时间的增加，调整带宽(示例性的，总带宽为100M，该电子设备从总带宽的10％调整到总带宽的50％)。

在一些可能的实现方式中，该过程窗口可以用于指示帧绘制过程，或者，该过程窗口可以用于指示非帧绘制过程中的关键过程。

在一些可能的实现方式中，该电子设备可以根据显示缓冲器中缓存的帧的数量，确定该帧绘制过程，示例性的，显示缓冲器中缓存的帧的数量可以为0、1或2，电子设备在确定第一过程窗口时可以根据缓存的帧的数量确定当前的帧绘制过程，并且可以根据具体实施例中表2确定出对应的margin值，进而确定该过程窗口的预期最长时间deadline。

具体地，该帧绘制过程可以由前台应用识别，前台应用在确定缓存的帧的数量后，可以将该帧绘制过程指示给内核调度器，由内核调度器根据对应的帧绘制过程执行相应的硬件资源调度策略。

在一些可能的实现方式中，前台应用可以向内核调度器指示帧绘制过程或者关键过程的标识信息，例如，0为PerfmClick过程的标识，1为ActivityTrasaction过程的标识，2为FrameWindowMargin_0的标识，3为FrameWindowMargin_1的标识，4为FrameWindowMargin_2的标识。具体指示标识的先后顺序可以根据用户的操作进行。

例如，用户执行打开微信通讯录的操作时，前台应用可以按照执行PerfmClick、ActivityTrasaction和帧绘制过程的顺序向内核调度器指示对应的标识。

结合第一方面，在第一方面的某些实现方式中，该非帧绘制过程包括点击过程或者活动组件运行过程。

本申请实施例中，关键过程主要包括ActivityTrasaction(活动组件运行过程)、PerformClick(点击过程)和ViewInflate等等。关键过程的划分主要是通过性能测试模型中识别出来的对性能延时影响比较大的过程函数。所以，当发现其他对性能测试影响较大的函数，通过本申请实施例的技术方案对性能有明显提升就可以将该过程设定为关键过程。

在一些可能的实现方式中，该步进硬件资源调度策略为：该电子设备确定该第一过程窗口中每个调度周期内所需的硬件资源量；该电子设备可以根据每个周期内确定的硬件资源量，对该第一过程窗口执行相应的调度。

在一些可能的实现方式中，每个周期内所需的硬件资源量依次增大。

本申请实施例的资源调度的方法，电子设备通过识别帧绘制线程中的帧绘制过程或者关键过程的状态，从而执行相应的资源调度，调度的粒度相比于线程粒度更加精细，有助于提升电子设备对帧绘制线程的资源进行硬件资源调度时的准确度。同时，对于帧绘制过程和关键过程，在进行资源调度时，随着时间的增加，电子设备可以增加调度的硬件资源，有助于保证帧绘制过程和关键过程及时完成。

结合第一方面，在第一方面的某些实现方式中，该方法还包括：该电子设备确定该前台应用的帧绘制线程的第二过程窗口；在从该第二过程窗口开始的第一时间段内，该电子设备根据第一硬件资源量进行硬件资源调度，该第一硬件资源量由该第一过程窗口的负载情况确定。

在一些可能的实现方式中，该第一硬件资源量为该第一过程窗口内调度的硬件资源量的平均值。

在一些可能的实现方式中，该电子设备中保存有过程窗口调度的硬件资源量的下限值，该电子设备对该第二过程窗口进行硬件资源调度的初始时刻(第一时间段内)，该电子设备可以判断该下限值和该第一硬件资源量的大小，从中选择其中比较大的一个作为初始调度的硬件资源量。

结合第一方面，在第一方面的某些实现方式中，该第一过程窗口为该第二过程窗口的上一个过程窗口。

结合第一方面，在第一方面的某些实现方式中，该方法还包括：在该第二过程窗口内，若按照该步进硬件资源调度策略调度的硬件资源量大于或者等于所述第一过程窗口的负载情况时，该电子设备执行该步进硬件资源调度策略。

本申请实施例的资源调度的方法，在当前过程窗口开始时，可以采用实时负载和上一过程窗口的实际负载中较大的一个来确定初始调度的硬件资源量，从而有助于避免过程窗口开始时，将该帧绘制线程调度到较小的硬件资源量，造成过程窗口的时间过长而产生丢帧，也避免了调度的硬件资源量的大幅度波动而造成的影响。

在一些可能的实现方式中，在该预设时长内，帧绘制线程的实时负载(vload)的计算方式为：

其中，vload为帧绘制窗口的即时负载，t为当前绘制消耗的时间，d为该第二过程窗口对应的预设时长。

结合第一方面，在第一方面的某些实现方式中，该方法还包括：在该步进硬件资源调度策略所调度的硬件资源量达到第一阈值时，该电子设备停止执行该步进硬件资源调度策略；该电子设备按照第二硬件资源量对该第一过程窗口进行硬件资源调度，该第二硬件资源量大于或者等于该第一阈值。

在一些可能的实现方式中，该第二硬件资源量大于该当前过程窗口中最后一个调度周期内的硬件资源量。

本申请实施例的资源调度方法，电子设备在预设时长内，对该过程窗口的调度没有完成时，可以采用更高的硬件资源量对其进行硬件资源调度，从而保证对该过程窗口的调度尽快完成。

结合第一方面，在第一方面的某些实现方式中，该方法还包括：该第二硬件资源量为该电子设备支持的最大硬件资源量，或者，该第二硬件资源量为该第一过程窗口预设的最大可用硬件资源量。

结合第一方面，在第一方面的某些实现方式中，该方法还包括：该方法还包括：该电子设备确定该前台应用的帧绘制线程的第三过程窗口；在该第三过程窗口内，该电子设备按照第三硬件资源量进行硬件资源调度。

在一些可能的实现方式中，该第二硬件资源量和该第三硬件资源量相同。

在一些可能的实现方式中，该第三过程窗口对应于显示缓冲器中缓存的帧的数量为0，此时电子设备可以按照其支持的最大硬件资源量对该第三过程窗口进行硬件资源调度。

结合第一方面，在第一方面的某些实现方式中，在该第一过程窗口内，执行步进硬件资源调度策略，包括：在该第一过程窗口内，一次或者多次增加调度的硬件资源量。

结合第一方面，在第一方面的某些实现方式中，当该电子设备在该第一过程窗口内，多次增加调度的硬件资源量时，该电子设备可以周期性的多次增加调度的硬件资源量。

在一些可能的实现方式中，该方法还包括：在该第一过程窗口结束时，停止执行该步进硬件资源调度策略。

本申请实施例中，该步进硬件资源调度策略可以是在该第一过程窗口中执行，当该第一过程窗口结束时，电子设备停止执行该步进硬件资源调度策略。对于该第一过程窗口结束后执行什么策略本申请实施例并不作任何限定。

结合第一方面，在第一方面的某些实现方式中，该方法还包括：在该帧绘制线程发生中断时，确定与该帧绘制线程对应的关联线程；该电子设备可以按照对该帧绘制线程调度的硬件资源量，对该关联线程的资源进行硬件资源调度。

应理解，关联线程可以为参与帧绘制动作的主线程、渲染线程，以及主线程、渲染线程在帧绘制期间直接或间接依赖的其他线程。

结合第一方面，在第一方面的某些实现方式中，该帧绘制线程包括主线程、渲染线程或者其他线程中的一个或者多个线程。

本申请实施例中，当帧绘制线程中断时，电子设备可以确定造成帧绘制线程中断的关联线程，并对该关联线程进行资源的调度，这样有助于提高帧绘制线程的效率，保证帧绘制线程及时完成。

结合第一方面，在第一方面的某些实现方式中，该调度的硬件资源包括中央处理器CPU资源、图形处理器GPU资源、内存资源或者输入输出IO资源中的一种或者多种。

在一些可能的实现方式中，若该资源为CPU资源，该CPU资源可以包括帧绘制线程运行的CPU核以及帧绘制线程运行的CPU核的频率，该电子设备可以根据计算得到的vload确定当前过程窗口的CPU核以及该CPU核对应的频率。

在一些可能的实现方式中，该CPU核至少包括一个大核和一个小核，每个CPU核至少包括两个不同的CPU频率。

第二方面，本技术方案提供了一种资源调度的装置，该装置包含在电子设备中，该装置具有实现上述方面及上述方面的可能实现方式中电子设备行为的功能。功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。硬件或软件包括一个或多个与上述功能相对应的模块或单元。

第三方面，本技术方案提供了一种电子设备，包括：存储器；多个应用程序；以及一个或多个计算机程序。其中，一个或多个计算机程序被存储在存储器中，一个或多个计算机程序包括指令。当指令被电子设备执行时，使得电子设备执行以下操作：接收到用户的第一操作；响应于该第一操作，获取该电子设备的前台应用；确定该前台应用的帧绘制线程的第一过程窗口，该第一过程窗口用于指示帧绘制过程，或者，该第一过程窗口用于指示关键过程；在该第一过程窗口内，执行步进硬件资源调度策略，该步进硬件资源调度策略为随着时间的增加，增加调度的硬件资源。

结合第三方面，在第三方面的某些可能的实现方式中，当指令被电子设备执行时，使得电子设备执行以下操作：确定该前台应用的帧绘制线程的第二过程窗口；在从该第二过程窗口开始的第一时间段内，根据第一硬件资源量情况进行硬件资源调度，该第一硬件资源量由该第一过程窗口的负载情况确定。

结合第三方面，在第三方面的某些可能的实现方式中，该第一过程窗口为该第二过程窗口的上一个过程窗口。

结合第三方面，在第三方面的某些可能的实现方式中，当指令被电子设备执行时，使得电子设备执行以下操作：在该第二过程窗口内，若按照该步进硬件资源调度策略调度的硬件资源量大于或者等于该第一硬件资源量时，执行该步进硬件资源调度策略。

结合第三方面，在第三方面的某些可能的实现方式中，当指令被电子设备执行时，使得电子设备执行以下操作：在该步进硬件资源调度策略所调度的硬件资源量达到第一阈值时，停止执行该步进硬件资源调度策略；按照第二硬件资源量对该第一过程窗口进行硬件资源调度，该第二硬件资源量大于或者等于该第一阈值。

结合第三方面，在第三方面的某些可能的实现方式中，该第二硬件资源量为该电子设备支持的最大硬件资源量，或者，该第二硬件资源量为该第一过程窗口预设的最大可用硬件资源量。

结合第三方面，在第三方面的某些可能的实现方式中，当指令被电子设备执行时，使得电子设备执行以下操作：确定该前台应用的帧绘制线程的第三过程窗口；在该第三过程窗口内，按照第三硬件资源量进行硬件资源调度。

结合第三方面，在第三方面的某些可能的实现方式中，当指令被电子设备执行时，使得电子设备执行以下操作：在该第一过程窗口内，一次或者多次增加调度的硬件资源量。

结合第三方面，在第三方面的某些可能的实现方式中，当指令被电子设备执行时，使得电子设备执行以下操作：在该第一过程窗口内，周期性得多次增加调度的硬件资源量。

结合第三方面，在第三方面的某些可能的实现方式中，当指令被电子设备执行时，使得电子设备执行以下操作：当该第一过程窗口结束时，停止执行该步进硬件资源调度策略。

结合第三方面，在第三方面的某些可能的实现方式中，当指令被电子设备执行时，使得电子设备执行以下操作：在该帧绘制线程发生中断时，确定与该帧绘制线程对应的关联线程；根据对该帧绘制线程调度的硬件资源量，对该关联线程的资源进行硬件资源调度。

第四方面，本技术方案提供了一种电子设备，包括一个或多个处理器和一个或多个存储器。该一个或多个存储器与一个或多个处理器耦合，一个或多个存储器用于存储计算机程序代码，计算机程序代码包括计算机指令，当一个或多个处理器执行计算机指令时，使得电子设备执行上述任一方面任一项可能的实现中的资源调度的方法。

第五方面，本技术方案提供了一种计算机存储介质，包括计算机指令，当计算机指令在电子设备上运行时，使得电子设备执行上述任一方面任一项可能的实现中的资源调度的方法。

第六方面，本技术方案提供了一种计算机程序产品，当计算机程序产品在电子设备上运行时，使得电子设备执行上述任一方面任一项可能的设计中的资源调度的方法。

附图说明

图1是本申请实施例提供的技术方案应用的电子设备的示意性框图。

图2是本申请实施例提供的技术方案应用的系统的示意性框图。

图3是本申请实施例的资源调度方法300的示意性流程图。

图4是本申请实施例的负载变化曲线的示意图。

图5是本申请实施例的另一负载变化曲线的示意图。

图6是本申请实施例的基于上一帧负载和当前帧负载的负载曲线的示意图。

图7是Android系统中显示子系统的整体架构的示意图。

图8是本申请实施例提供的一种帧绘制场景的示意图。

图9是本申请实施例提供的另一种帧绘制场景的示意图。

图10是本申请实施例提供的另一种帧绘制场景的示意图。

图11是本申请实施例提供的另一种帧绘制场景的示意图。

图12是本申请实施例提供的帧绘制窗口的识别、指示和调度方法的示意性流程图。

图13是本申请实施例提供的帧绘制窗口的识别、指示和调度方法的另一示意性流程图。

图14是UI线程中的关键过程、非关键过程以及帧绘制过程在运行时间轴上的关系。

图15是本申请实施例提供的内核调度器的调度方法的示意性流程图。

图16是本申请实施例提供的帧绘制线程关联线程的识别和调度方法的示意性流程图。

图17是本申请实施例的技术方案应用的系统的另一示意图。

图18是本申请实施例提供的资源调度的方法的另一示意性流程图。

图19是本申请实施例提供的电子设备的示意性框图。

具体实施方式

以下实施例中所使用的术语只是为了描述特定实施例的目的，而并非旨在作为对本申请的限制。如在本申请的说明书和所附权利要求书中所使用的那样，单数表达形式“一个”、“一种”、“所述”、“上述”、“该”和“这一”旨在也包括例如“一个或多个”这种表达形式，除非其上下文中明确地有相反指示。还应当理解，在本申请以下各实施例中，“至少一个”、“一个或多个”是指一个、两个或两个以上。术语“和/或”，用于描述关联对象的关联关系，表示可以存在三种关系；例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B的情况，其中A、B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。

在本说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本申请的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。

以下介绍了本申请实施例提供设计的电子设备、用于这样的电子设备的用户界面、和用于使用这样的电子设备的实施例。在一些实施例中，电子设备可以是还包含其它功能诸如便携式电子设备，诸如手机、平板电脑、具备无线通讯功能的可穿戴电子设备(如智能手表)等。便携式电子设备的示例性实施例包括但不限于搭载

或者其它操作系统的便携式电子设备。上述便携式电子设备也可以是其它便携式电子设备，诸如膝上型计算机(Laptop)等。还应当理解的是，在其他一些实施例中，上述电子设备也可以不是便携式电子设备，而是台式计算机。在一些实施例中，电子设备可以是智能家电，诸如智能音箱、智能家居设备等等。

图1示出了本申请实施例提供的技术方案应用的电子设备100的示意性框图。该电子设备100可以包括触摸屏101、处理器102、存储器103和显示屏104，其中，触摸屏101和显示屏104可以集成在一个屏幕中。如图1所示，本申请实施例的技术方案的硬件环境为电子设备，触摸屏101接收用户的触控事件，并将该触控事件发送给处理器102，处理器102通过从存储器103调用程序和数据，对触摸事件进行处理，并最终输出给显示屏104显示输出。从处理器102(例如，中央处理器(central processing unit，CPU))接收和处理用户交互信息到输出显示的过程中，通过识别系统软件和用户软件中的关键动作，为关键动作提供有保障的CPU资源，保障了用户交互的流畅性和及时性，也避免了非关键动作过多消耗CPU资源，从而提供良好的用户体验。其中，关键动作可以为与用户交互和显示感受敏感的任务，如帧数据的准备过程(包括ActivityTrasition、PerformClick等)、帧的合成渲染、输入(input)事件处理、动画事务处理、活动组件创建和启动、活动组件中视图控件的布局和界面响应用户点击或滑动操作等等。非关键动作可以为绘制线程中，接收系统广播消息、接收立式会话消息等用户视觉不敏感的任务。

在介绍本申请实施例的技术方案之前，先介绍本申请实施例中一些相关概念。

CPU资源：进程或者线程运行的CPU大、小核，以及所在核的CPU频率。

帧绘制窗口：某应用的绘制关联线程中，绘制一帧时从开始到结束的时间窗。

绘制关联线程：绘制关联线程是指参与帧绘制动作的主线程、渲染线程，以及主线程、渲染线程在帧绘制期间直接或间接依赖的其他线程。

主线程、渲染线程为依赖线程，其他线程为被依赖线程。被依赖线程是依赖线程通过进程间通信而依赖被依赖线程，或者被依赖线程是依赖线程通过进程内锁同步调用而依赖被依赖线程。间接依赖是指依赖线程依赖了被依赖线程依赖的其他线程。

本申请实施例提供了一种资源调度方法，该资源调度方法基于前台应用的帧绘制线程中帧绘制窗口的调度和调频。即在应用的绘制关联线程中，前台应用标记每一帧绘制动作的开始点和结束点，使得内核可以在该帧的绘制窗口(从开始点到结束点)中，周期性地(即时的)根据当前帧的即时负载(vload)和上一帧的平均负载决策当前帧对CPU资源(或者，图形处理器(graphics processing unit，GPU)、内存等资源等)的需求，从而调度所有绘制线程以给定的资源运行。

帧绘制窗口的开始点和结束点一般由主线程、渲染线程共同决定。一般情况下，当应用界面首次显示，或发生变化需要重绘时，应用的主线程中调用系统提供的绘制接口进行界面的绘制，同时为了减轻主线程的负担，也会将部分高计算量的绘制任务分解到渲染线程中完成。从而通过观测系统的绘制接口可以获得帧绘制窗口的开始点和结束点。

前台应用的主线程中，除了帧绘制任务的执行效率直接影响用户体验感受外，还有很多其他关键动作和非关键动作。为了提高用户的操作体验，我们对这些重要的任务和帧绘制任务一样，识别和标记起止点，即时地决策和提供所需的CPU资源。

进一步的，帧绘制任务有简单的，有复杂的。简单的任务执行时长可能不到2ms，复杂的任务执行时长可能超过100ms。调度CPU资源时，不是一味追求快，而是希望每一帧在16ms内刚好能够完成。这样对简单的帧绘制任务，一开始提供的CPU资源很少，以便节省功耗，提高续航能力。当一个帧绘制任务进行到一定的时间，发现该任务还未完成，需要提高CPU资源供给。这个时间离16ms越近，CPU资源供给越大，接近甚至超过16ms时，CPU可以开足马力全力运行该任务。

本申请实施例的技术方案中，可以通过以下两种方式判断帧绘制任务的复杂度。

方式一

通过上一帧的负载预判断当前帧的执行时长。对同一应用(同一个activity)中的两个连续的帧，大部分情况下，执行的时长基本相同。因此可以根据上一帧中CPU资源的消耗量预测当前帧对CPU资源的需求。

对于方式一，上一帧中CPU资源的消耗量可以在内核调度器中实时获得并判断的。

方式二

根据绘制任务中，关键绘制动作(通过接口来识别)与帧绘制开始点的时长来判断。

进一步的，可以根据显示组件中，缓存的帧的数量来决策当前帧绘制任务的时间窗。

根据显示缓冲器中缓存的帧的数量来判断。应用与显示组件(Surface Flinger)间维护了一个帧的队列，应用每完成一帧的绘制任务，就将该帧加入到该队列。目前该队列中帧的数量可能为0、1、2几种可能。显然，帧数量越大，意味着应用中帧绘制任务比较简单，应用完成一帧需要的时长小。反之，帧绘制任务复杂，耗时较长。因而，帧数量大，CPU资源的供给可以低一些；帧数量小，CPU资源的供给可以高一些。

应理解，本申请实施例中，缓存的帧的数量与帧绘制任务的复杂度并不直接关联，缓存的帧的数量可以体现生产者和消费者之间的快慢关系，内核调度器可以根据这个关系来控制CPU资源的供给，从而可以更好的达到性能和功耗之间的均衡。

对于方式二，在前台应用获得后，需要通知给内核调度器的。即前台应用除了指示内核调度器每一个帧绘制任务的起止点以外，还可以指示内核调度器该帧绘制任务的紧迫程度。例如，当显示缓冲器中维护的帧的队列中帧的数量为2时，此时前台应用可以确定该帧绘制任务的紧迫程度较低；当应用与显示组件维护的帧的队列中帧的数量为0时，此时前台应用可以确定该帧绘制任务的紧迫程度较高。内核调度器根据帧绘制任务的紧迫程度，可以确定帧绘制任务对CPU资源的需求量，从而完成帧绘制窗口中对帧绘制关联线程的调度和CPU调频，以达到更好的性能体验和续航能力的均衡。

对帧绘制关联线程的调度是决定在帧绘制的时间窗口中，所有关联线程运行所采用的CPU核(大核或小核，以及所用的核的数量)。

对帧绘制关联线程的CPU调频是决定在帧绘制的时间窗口中，所有关联线程运行所采用的CPU核的频点(高还是低，从频点集合中选择合适的)。

表1示出了某芯片中CPU能力(等价于CPU上运行任务的负载vload)与CPU资源的关系。

表1负载与CPU资源的关系

本申请实施例中，内核调度器决策帧绘制窗口的CPU资源时，可以采用前一帧的负载和当前帧的即时负载(vload)相结合的方式。

前一帧的负载和当前帧的即时负载并不是同一个概念，前一帧负载是前一个帧绘制窗口中，帧绘制关联线程组实际执行的负载量，这是Linux内核已有的技术。当前帧即时负载，是本申请中根据需要定义的负载计算方式(下文中介绍了多种计算方式)计算得到。

内核调度器在进行决策时，可以取前一帧的负载和当前负帧即时负载中较大的一个，用于当前帧窗口中CPU资源的调度决策。

一个帧绘制任务中，除了主线程、渲染线程承担主要的工作外，还需要获取一些帧绘制所需的信息，这些信息需要依赖其他线程的工作才能获得。依赖关系可以为进程间通信(inter process communication，IPC)调用。本申请实施例中通过介绍Binder IPC调用产生的依赖来识别绘制关联线程。

本申请实施例的技术方案可以应用处于可显示终端的前台应用时，系统调度模块结合应用中帧绘制任务的情况，决策和调度CPU等资源，以保证应用运行的流畅性和及时性。图2示出了本申请实施例的技术方案所应用的系统200的架构图。如图2所示，该系统200中包括系统服务进程201、前台应用进程202和内核调度器203。其中，系统服务进程中可以包括活动管理服务(activity manager service，AMS)、窗口管理服务(windowmanagerservice，WMS)、主绘制线程管理模块和调度策略配置管理模块，其中，主绘制线程管理模块可以执行对主绘制线程的识别和指示功能；前台应用进程中包括帧绘制准备阶段指示模块、帧绘制窗口指示模块和空白帧指示模块；内核调度器包括帧绘制关联线程识别和设置模块、帧绘制窗口负载计算和预测模块、帧绘制窗口关联线程调度模块和基于帧绘制窗口负载的调度器。

在系统服务进程201中，AMS服务管理操作系统(例如，Android)中运行的应用进程中的活动(Activity)组件。

WMS服务管理Activity组件相关的窗口系统。

本申请实施例中，在系统服务进程201中新增了调度策略配置管理模块和主绘制线程管理模块。

主绘制线程管理模块根据AMS维护的前台应用进程的信息和WMS中维护的前台应用的窗口信息，确定在前台运行的应用进程中的绘制线程。其中，WMS提供最顶层的与用户交互的应用窗口对应的应用的进程，AMS提供所述应用的进程中负责绘制的主线程(包含渲染线程)。

调度策略配置管理模块负责本申请实施例中的调度策略的配置信息，以及控制本特性的工作状态。

前台应用进程202中实现帧绘制动作状态的采集，从而指示内核调度器完成基于帧绘制窗口的调度和调频。

在内核调度器203中，帧绘制关联线程识别和设置模块用于根据系统服务发送的主绘制线程，来识别和设置主绘制线程的关联线程；

帧绘制窗口负载计算和预测模块用于周期性计算当前帧绘制窗口的即时负载和根据上一帧预测当前帧的负载；

基于帧绘制窗口负载的调度器用于基于即时负载和预测负载决策关联线程组的CPU核资源和CPU核频率，从而调度帧绘制窗口关联线程执行。

系统服务进程和内核调度器间主要存在以下三个接口：

(1)功能使能/停止；

(2)调度策略配置参数；

(3)主绘制关联线程列表。

系统服务进程和医用进程之间的主要存在以下接口：

(1)通知前台应用进程的窗口开始显示。

前台应用收到该通知后，启动帧绘制窗口的监测，从而指示内核调度器绘制动作和非绘制动作的开始点与结束点。

(2)通知后台应用进程的窗口停止显示。

后台应用受到该通知后，停止帧绘制窗口的检测和动作指示。

前台应用进程和内核调度器之间主要存在以下三个接口：

(1)热点事件开始/结束的指示。

热点事件包括活动组件(Activity)的onStart、onStop等；视图组件(view)的点击响应过程on PerformClick、inflate、layout；广播组件的onReceive等。PerformClick、layout、inflate为Android应用程序的帧绘制线程中的过程函数。下文中ActivityTrasaction、drawFrame、doFrame均为Android应用程序的帧绘制线程中的过程函数。

(2)帧绘制窗口开始或者结束的指示。

(3)主绘制线程中的其他过程。

图3示出了本申请实施例的资源调度方法300的示意性流程图，如图3所示，该资源调度方法300主要包括初始化阶段和运行阶段，初始化阶段进行的资源调度信息下发，运行阶段进行CPU调度和控制。该方法300包括：

S301，系统服务进程从配置文件中加载资源调度信息。

S302，系统服务进程将资源调度信息发送给内核调度器。

应理解，S301和S302为该资源调度方法300的初始化阶段。在初始化阶段，系统服务进程中的调度策略配置管理模块从配置文件中加载资源调度信息，并下发给内核调度器模块。资源调度信息包括内核调度器的运行控制参数、过程窗口的最长时间(Deadline)控制参数。Deadline可以指一个过程函数或者帧绘制期望不超过的最长时间。

该过程窗口可以用于指示帧绘制过程，或者，该过程窗口可以用于指示非帧绘制过程中的关键过程。

内核调度器的运行控制参数包括但不限于：

(1)负载计算和调度的周期；

(2)帧绘制窗口的负载上限控制。

帧绘制窗口的最长时间(Deadline)控制参数为每类过程窗口定义的一个时间差额(margin)值，具体地过程窗口包括但不限于以下场景：

(1)FrameWindowMargin_0；

(2)FrameWindowMargin_1；

(3)FrameWindowMargin_2；

(4)ActivityTrasaction；

(5)PerfmClick；

(6)ViewInflate；

(7)ViewLayout。

其中，场景(1)-(3)为帧绘制动作的状态，场景(4)-(7)为非帧绘制动作的状态。非帧绘制动作的状态可以包括关键场景和非关键场景，其中场景(4)-(7)可以为关键场景。非帧绘制动作的状态还可以包括空白帧绘制场景。

应理解，本申请实施例中，帧绘制动作的状态并不限于上述(1)-(3)中的举例，非帧绘制动作的状态也不限于上述(4)-(7)中的举例。

还应理解，本申请实施例中，帧绘制动作的状态也可以称之为帧绘制场景，非帧绘制动作的状态也可以称之为非帧绘制场景。

调度资源管理配置模块中支持为每个场景配置时间差额(margin)值。margin值指对帧绘制窗口Deadline的调节量，单位可以为毫秒(ms)。默认的帧绘制窗口Deadline可以为一个常量，以1秒绘制60帧为例，可以默认Deadline为16.6ms，实际场景下的Deadline可以为16.6+场景对应的margin值。

一个实施例中，在内核调度器的帧绘制调度窗口内，内核调度器计算帧绘制窗口的CPU负载vload可以采用如下公式(1):

其中，vload为帧绘制窗口的即时负载，t为当前绘制消耗的时间，d为上述Deadline。d默认可以设置为16.6ms，即帧率为60FPS下每一帧的平均时间间隔。在不同的场景下，d通过margin值进行调节，此时d＝16.6+margin值。

示例性的，表2示出了不同过程窗口对应的margin值的对应关系。

表2不同过程窗口与margin值的对应关系

过程窗口名称	Margin值(单位ms)
		ActivityTrasaction	-16
PerfmClick	-8
		FrameWindowMargin_0	0
FrameWindowMargin_1	8
		FrameWindowMargin_2	16
…	…

其中，对于ActivityTrasaction过程窗口，该过程中内核调度器进行全程CPU资源最大供给；对于PerfmClick过程窗口，该过程在8ms内未完成时，内核调度器开始供给最大CPU资源；对于FrameWindowMargin_0过程窗口，该过程在16ms内未完成时，内核调度器开始供给最大CPU资源；对于FrameWindowMargin_1过程窗口，该过程在24ms内未完成时，内核调度器开始供给最大CPU资源；对于FrameWindowMargin_2过程窗口，该过程在32ms内未完成时，内核调度器开始供给最大CPU资源。

应理解，表2中过程窗口与margin值的对应关系仅仅是示意性的，本申请实施例中并不对实际的margin值进行限定。

还应理解，系统服务进程向内核调度器发送的资源配置信息中可以携带上述表2所示的过程窗口与margin值的对应关系；另一个实施例中，资源配置信息中还可以携带过程窗口和deadline的对应关系。

示例性的，表3示出了过程窗口与deadline的对应关系。

表3不同过程窗口与deadline的对应关系

一个实施例中，系统服务进行向内核调度器发送的资源配置信息中还可以携带过程窗口和CPU资源的对应关系。

示例性的，表4示出了不同的过程窗口与CPU资源的对应关系。

表4不同过程窗口与CPU资源的对应关系

过程窗口名称	CPU资源
		ActivityTrasaction	大核1400M
PerformClick	大核1800M
		FrameWindowMargin_0	大核2200M
FrameWindowMargin_1	大核2000M
		FrameWindowMargin_2	大核1800M
…	…

应理解，上述表2至表4中的对应关系可以以表格的形式体现，也可以由其他方式体现，例如以函数的方式体现，本申请实施例对此并不作任何限定。

还应理解，本申请实施例中，系统服务进程可以在资源调度信息中携带表2至表4中任一对应关系，也可以是，系统服务进程可以不将资源调度信息发送给内核调度器，而是由内核调度器保存有上述任一对应关系，当前台应用进程向内核调度器指示过程窗口时，内核调度器可以根据保存的上述对应关系，对帧绘制线程进行资源的调度。

vload可以是一个[0，1024]的变量，随着帧绘制窗口中时间的变长，从0逐步增加大1024。当t大于帧绘制的预期截止点d时，vload可以取最大值1024。Vload与t和magin的变化曲线可以如图4所示。

从图4可以看出，当margin值小于等于-16时，vload在帧绘制的整个窗口中都为1024。随着margin的增大，vload增长为1024的时间增长。

内核调度器可以根据vload周期性的确定帧绘制线程(组)的CPU资源。

示例性的，该调度周期如果设定为4ms，则每个4ms计算一次vload，根据vload来确定CPU资源。

vload与CPU资源的关系与CPU芯片支持的能力相关，某芯片中vload与CPU资源的关系可以如表1所示。

内核调度器估计出当前帧绘制窗口的CPU负载后，选择与当前负载最接近的CPU能力，也可以选择比该CPU负载稍大的CPU能力。假设当前帧绘制窗口的CPU负载为628，位于大核1400M和小核1300M之间，则内核调度器一般选择大核1400M运行帧绘制线程(组)。

一个实施例中，帧绘制窗口的负载计算公式可以根据不同的场景或者产品确定，从而定义负载与时间窗曲线的其他可能性，以改善性能和功耗的平衡关系。

内核调度器计算帧绘制线程(组)的CPU负载vload可以采用如下公式(2):

或者，内核调度器计算帧绘制线程(组)的CPU负载vload可以采用如下公式(3):

其中，公式(2)中负载与时间成线性正比例关系，相比于公式(1)，能够更快的供给CPU资源；公式(3)则相比于公式(2)更为激进。三个公式的变化曲线可以参考图5所示。

一个实施例中，内核调度器还可以计算出上一帧中帧绘制线程的实际负载，在当前帧绘制窗口开始时，采用上一帧的实际负载来确定初始的CPU资源，避免帧绘制窗口开始时，计算的vload为0，将帧绘制线程(组)调度到小核最低频运行，造成帧绘制窗口时间过长而丢帧，也避免了CPU频率的大幅波动造成的影响。

基于上一帧负载和当前帧负载的负载曲线可以如图6所示。从图6中的(a)中可以看出，内核调度器每次决策CPU资源时，在初始调度时，以上一帧平均负载和当前帧即时负载的较大的值。当调度时长达到t₁时，由于实时负载大于上一帧的平均负载，内核调度器可以再用该值从vload与CPU资源的关系表中，确定出CPU资源，从而按照该CPU资源对帧绘制线程进行硬件资源调度。当内核调度器调度的硬件资源的时长达到t₂时,该电子设备还没有完成对当前帧绘制窗口的调度，该电子设备可以采用该电子设备所支持的最大硬件资源量(例如，1024)进行资源调度。

示例性的，如图6中的(b)所示，从图6中的(a)中可以看出，内核调度器每次决策CPU资源时，在初始调度时，以上一帧平均负载和当前帧即时负载的较大的值。当调度时长达到t₁时，由于实时负载大于上一帧的平均负载，内核调度器可以再用该值从vload与CPU资源的关系表中，确定出CPU资源，从而按照该CPU资源对帧绘制线程进行硬件资源调度。当内核调度器调度的硬件资源的时长达到t₃时,该电子设备还没有完成对当前帧绘制窗口的调度，该电子设备可以采用当前帧绘制窗口所支持的最大硬件资源量(例如，900)进行资源调度。

应理解，以上描述时是以帧绘制窗口为例进行描述，对于关键过程的资源调度也可以参考上述对帧绘制窗口的资源调度过程，为了简洁，在此不再赘述。

S303，当电子设备检测到用户的操作，该操作为从第一前台应用切换到第二前台应用时，第一前台应用进程向系统服务进程指示应用进程的切换。

S304，系统服务进程启动前台应用。

应理解，S303和S304为可选地步骤。

S305，系统服务进程向内核调度器发送第二前台应用进程的绘制线程的ID。

S306，系统服务进程通知第一前台应用进程到后台并指示第一前台应用进程停止绘制动作的识别和指示。

S307，系统服务进程通知第二前台应用进程到前台，并指示第二前台应用进程启动绘制动作的识别和指示。

S308，第二前台应用进程向内核调度器发送绘制动作状态指示。

S309，内核调度器根据绘制动作状态指示，确定绘制线程的CPU资源，从而调度绘制线程在决策的CPU资源上运行。

应理解，S305-309为资源调度方法300的运行阶段。

一个实施例中，该方法300还包括：

内核调度器在确定帧绘制线程发生中断时，确定与该帧绘制线程对应的关联线程；

内核调度器对该关联线程进行硬件资源调度。

帧绘制线程在绘制一帧的过程中可以发生阻塞(或者，中断)。例如，UI线程调用系统服务进程中WMS，从而获取显示窗口的信息。此时，UI线程是通过进程间通信通道Binder发送指令给WMS，WMS中的Binder线程接收指令并处理后从原通道回复查询的信息。这种情况下，WMS中的Binder线程是UI线程的关联线程，内核调度器在调度时，可以感知到UI线程对该Binder线程的依赖，将该Binder线程加入到帧绘制关联线程组中，并基于帧绘制窗口的负载调度该线程。

运行阶段调度和控制主要由系统服务进程的主绘制线程管理模块和前台应用进程的帧绘制窗口识别和指示模块两个实体控制内核调度器实现基于帧绘制窗口的调度和调频。

主绘制线程管理模块检测应用的前后台切换事件，当发生前后台切换事件时，主绘制线程管理模块获得前台应用的主绘制线程UI和render。系统服务进程可以将UI和render下发给内核调度器；系统服务进程可以通知前台应用进程的帧绘制窗口识别和指示模块在前台显示；系统服务进程还可以通知上一个前台应用停止帧绘制动作的识别和指示。

帧绘制窗口识别和指示模块接收到前台显示的消息后，开始帧绘制动作的识别和指示。前台应用识别的帧绘制过程包括但不限于FrameWindowMargin_0、FrameWindowMargin_1、FrameWindowMargin_2，非帧绘制过程包括但不限于ActivityTrasaction、PerfmClick、ViewInflate和ViewLayout等等。

每个帧绘制动作中包含起始(start)和结束(end)两个节点，帧绘制窗口识别和指示模块将这些帧绘制动作信息告知内核调度器，内核调度器根据帧绘制窗口的Deadline控制参数和帧绘制动作信息确定帧绘制窗口的时间窗和Dealine，进一步周期性的确定帧绘制窗口中每个周期点上的CPU资源，并调度帧绘制关联线程以所给的CPU资源运行。

一个实施例中，内核调度器可以根据表2所示的过程窗口与margin值的对应关系确定Dealine，内核调度器可以以调度周期(例如，4ms)确定帧绘制窗口的负载，从而根据表3所示的负载与CPU资源的对应关系，确定出对应的CPU资源，从而调度绘制线程在决策的CPU资源上运行。

在Deadline结束时，如果该帧还未完成，可以调度CPU资源到最大的门限，供给帧绘制线程以该CPU资源运行，确保尽快完成该帧的绘制。

根据前台应用中UI主线程的关键流程，帧绘制窗口识别和指示模块在帧绘制动作识别和指示时包括热点事件开始或者结束指示、帧绘制窗口开始或者结束指示以及主绘制线程中的其他过程。

其中帧绘制窗口开始或者结束的指示是其中的关键部分，下面介绍帧绘制窗口的识别和指示。帧绘制窗口识别和指示时，可以结合显示缓冲器Buffer的帧的数量。应理解，显示缓冲器是应用进程和SF之间的显示缓冲器。

下面介绍基于显示缓冲区Buffer的帧绘制窗口的识别和指示过程。

以Android系统为例，应用中界面的输出显示帧率为60fps。图7示出了Android系统中显示子系统的整体架构。显示器(display processing unit，DPU)以16.6ms的固定周期从显示缓冲区(Frame Buffer0HWC output)中获取帧数据并输出给显示屏(DisplayScreen)。同时，DPU会产生垂直同步(vertical syncronization，Vsync)信号，以通知前台应用帧同步信息。前台应用可以在vsync信号后的16.6ms内产生帧数据并存放到SF的缓存队列(Fame Buffer2UI output)。SF和硬件合成器(HW Composor)负责不同层面的图层的叠加。

每个在显示的应用和SF间一个缓存队列(BufferQueue)，当前该BufferQueue中有两个FrameBuffer。应用是FrameBuffer的生产者，SF是消费者。应用中负责生产Buffer的主要有UI和render两个线程。

UI线程生成显示视图列表(displaylist)，Render线程根据displaylist结合GPU完成帧的渲染。Render线程的渲染数据，需要向SF申请FrameBuffer，才能够完成数据交换，对于当前双Buffer的机制，进程存在SF消费者消费慢，但是Render生产者生产快，导致Render线程存在长时间睡眠等待状态；针对此问题，基于消费者反压生产者的思路，在消费者来不及消费时，生产者放慢生产速度：

Render线程中获取BufferQueue有效帧数量N，当N为2帧时，表示已经没有空闲Buffer给生产者，因此上层通过设置FrameCacheBuffer_2去相应的延后每帧的deadline，最终通过相对缓和的调度和调频来实现；

当N为1帧时，此时表示只有一帧有效数据，还有一个空闲buffer给生产者，此时margin的值设置为FrameCacheBuffer_1，也延后deadline；

当N为0时，要求当前帧需要在16.6ms内完成，否则就会存在丢帧；因此通过下发FrameCacheBuffer_0来保证最高等级的调度和调频。

在配置帧绘制窗口的Deadline控制参数时，可以遵守以下原则：

FrameCacheBuffer_2>＝FrameCacheBuffer_1>＝FrameCacheBuffer_0

示例性的，如表2所示，当margin的值设置为FrameCacheBuffer_2，margin值为16ms，Deadline为32ms；当margin的值设置为FrameCacheBuffer_1，margin值为8ms，Deadline为24ms；当margin的值设置为FrameCacheBuffer_0，margin值为0，Deadline为16ms。

帧绘制窗口识别和指示模块在指示内核调度器当前的帧绘制动作时，首先判断SF的BufferQueue中FrameBuffer的数量，根据FrameBuffer的数量指示内核调度器帧绘制调度的类型。

应理解，以上介绍了帧绘制窗口中CPU资源的调度和调频方法，帧绘制线程中的render线程还可以识别中GPU资源的起止点。一般来说，render线程中使用GPU资源进行渲染时会调用opengl的接口。通过识别opengl的接口，render线程可以识别出每一帧中opengl调用的开始点和结束点，并指示内核调度器关于GPU资源的帧绘制窗口，从而调度GPU资源。一个实施例中，可以识别出帧绘制窗口中对其他资源如内存资源、IO存储资源的需求窗口和门限，即可以将帧绘制窗口中资源的调度扩展到除CPU资源以外的其他资源，如GPU、内存资源、IO存储资源等等其他资源。

Android系统中，UI和render配合完成主界面的渲染工作，往往存在UI线程开始第二帧绘帧，但Render线程还在绘制第一帧。帧绘制窗口的识别根据绘制场景需要精确的确定一帧的开始和结束。

UI线程中，doFrame过程负责一帧的绘制任务，帧绘制任务是由doFrame中的一些子过程组合完成的，这些子过程以回调函数的形式注册给doFrame过程，doFrame判断子过程回调函数是否注册，如果注册了，才调用子过程回调函数执行。这些子过程包括input、animation、traversal。其中input、animation分别处理用户输入事件和动画的准备。

traversal过程中包含测量过程measure、布局过程layout、渲染过程draw，只有draw子过程是执行绘制的。draw子过程并不自己完成每一帧的绘制，而是将绘制任务打包为显示视图列表displaylist，再将displaylist转交给render线程中的drawFrame过程，由后者最终完成一帧的绘制渲染。

在实际应用中，识别每一帧绘制的开始点和结束点并不容易，因为每一帧中包含的子过程并不总是相同，如有些doFrame过程虽然包含了input、animation、traversal所有这些子过程，但traversal中的draw只是一个空实现，没有显示区域的刷新，也不向render线程的drawFrame提交绘制事物。而另外一些情况下，doFrame一开始并不包括traversal，而是在animation的执行过程中，决定做动画的渲染，从而向doFrame注册了traversal过程。

下面介绍本申请实施例的几种帧绘制场景，本申请实施例中，帧绘制场景可以主要分为以下4个场景。

场景一

图8示出了本申请实施例提供的一种帧绘制场景的示意图，如图8所示，doFrame过程包含了input(输入事件的处理过程)、animation(动画处理过程)和traversal(遍历)，traversal的子过程draw(帧绘制准备过程)将绘制任务委托给render线程的drawFrame(帧绘制过程)。

场景二

图9示出了本申请实施例提供的另一种帧绘制场景的示意图，如图9所示，traversal的子过程draw为空，没有要刷新的界面绘制任务，所以render线程中，drawFrame过程为空。

场景三

图10示出了本申请实施例提供的另一种帧绘制场景的示意图，如图10所示，doFrame的callback(回调)列表中，一开始没有TRAVERSAL_CALLBACK，在其子过程animation运行过程中，才注册了TRAVERSAL_CALLBACK。

应理解，TRAVERSAL_CALLBACK为一类Android应用程序中，参与帧绘制过程的回调函数的名称，而traversal为TRAVERSAL_CALLBACK对应的实际过程函数。

场景四

图11示出了本申请实施例提供的另一种帧绘制场景的示意图，如图11所示，drawFrame过程中，判断当前帧是否需要重新绘制，如果需要重新绘制，则由draw子过程注册新的traversal过程。在这种情况下，第二个traversal过程中，可能会调用draw子过程重新绘制，也可能只是对界面的重新measure(测量)和layout(布局)，但不进行绘制(draw)。

为了准确的判断每一帧的开始和结束点，增加一个实体对象帧绘制调度管理器(RtgSchedManager)。RtgSchedManager接收UI线程中doFrame的开始和结束事件，并接收Traversal中的开始和结束事件，同时接收render线程中drawFrame过程的开始和结束事件，RtgSchedManager记录每一类过程的状态，判断是否处于帧绘制的过程中，确保每一帧绘制时，向内核调度器分别发送一次帧绘制动作的开始和结束事件。

下面对场景一和场景三对应的帧绘制窗口的识别、指示和调度进行详细描述。

图12示出了本申请实施例提供的帧绘制窗口的识别、指示和调度方法400的示意性流程图，如图12所示，该方法400包括：

S401，UI线程判断doFrame中的TRAVERSAL_CALLBACK是否已经注册。

如果已经注册该回调函数，说明doFrame中会调用doTraversal子过程。

S402，如果已经注册该回调函数，UI线程向RtgSchedManager发送doFrame过程开始指示。

S403，RtgSchedManager指示内核调度器帧绘制窗口开始。

由于RtgSchedManager没有在其他帧绘制的窗口中，RtgSchedManager指示内核调度器帧绘制窗口开始，以便内核调度器开始为帧绘制关联线程计算帧绘制窗口的负载，并为帧绘制关联线程调度所需的资源。同时，RtgSchedManager将第一状态标记为帧绘制状态FRAME中。

S404，UI线程确定子过程doTraversal开始时，可以向RtgSchedManager发送doTraversal过程开始事件。

子过程doTraversal开始时，UI线程也需要向RtgSchedManager通知doTraversal开始事件。这样做的目的是如果在doFrame开始时，还没有注册TRAVERSAL_CALLBACK回调函数，则此处为该帧的开始点。

S405，在doTraversal的子过程draw中，UI线程的draw过程可以向render线程发送开始draw过程指示。

在doTraversal的子过程draw中，draw过程会通知render线程开始drawFrame。一般情况下，draw过程会阻塞UI线程，直到Render线程完成drawFrame的子过程syncFrameState。此时UI线程从阻塞状态恢复的运行状态，处理其他非帧绘制过程或处理下一帧绘制过程。而render线程继续完成当前的帧绘制的渲染动作。

S406，在render线程的drawFrame开始阶段，render线程向RtgSchedManager发送drawFrame开始事件。

S407，RtgSchedManager标记第二状态标记为render线程渲染中。

S408，doTraversal的子过程draw结束后，如果当前的doFrame中只有一个TRAVERSAL_CALLBACK，则该doFrame过程会马上结束，UI线程会通知doTraversal过程结束事件和doFrame过程结束事件给RtgSchedManager。

S409，RtgSchedManager在收到这些事件时，判断第一状态标记是否为FRAME，如果为FRAME，则进一步判断第二状态标记是否为render线程渲染中。

当第二状态标记不是render线程渲染中，则说明当前帧的draw子过程为空，未进行drawFrame过程，则立马向内核调度器指示结束帧绘制窗口，以便内核调度器停止帧绘制窗口的负载计算，进一步重新确定帧绘制关联线程的CPU资源。

当第二状态标记是render线程渲染中，则说明当前帧的drawFrame过程还没有结束，则清除第一状态标记后返回。

S410，UI线程从第一帧的doFrame返回后，可以执行第二帧的doFrame过程。UI线程向向RtgSchedManager发送doFrame过程开始指示。

若第一帧的doFrame过程超过16.6ms，UI线程认为应该开始第二帧的绘制。同样，如果第二帧的doFrame过程开始时，发现已经注册了TRAVERSAL_CALLBACK，UI线程可以向RtgSchedManager发送doFrame过程开始指示。

RtgSchedManager如果判断第二状态标记为render线程渲染中，RtgSchedManager可以标记第三状态为下一帧开始(DO_NEXT_FRAME)。

S411，Render线程的drawFrame结束时，render线程向RtgSchedManager发送drawFrame结束事件。

S412，RtgSchedManager判断第三状态标记是否为DO_NEXT_FRAME，如果是则说明UI线程的下一帧已经在绘制中，下一帧的帧绘制窗口被延误，RtgSchedManager向内核调度器发送帧绘制窗口开始指示。

这种情况下，丢弃帧绘制窗口结束的指示动作。内核调度器连续收到两次帧绘制窗口的开始指示，则自动进入下一帧的帧绘制窗口的负载跟踪和帧绘制线程的调度中。

在DO_NEXT_FRAME的状态下，考虑到下一帧的帧绘制窗口已经被延误，本应该对帧绘制窗口的开始时间做补偿，从当前时间往前移到真正的开始时间点。但对SF来说，刚接收到drawFrame过程渲染的一帧数据，SF来不及消耗该帧，因此帧绘制的动作还可以考虑SF中缓存的已渲染的帧数据量。

针对此问题，基于消费者反压生产者的思路，在消费者来不及消费时，生产者放慢生产速度。

当Render线程中获取BufferQueue有效帧数量N，当N为2帧时，表示已经没有空闲Buffer给生产者，因此上层通过设置FrameCacheBuffer_2去响应的延后每帧的deadline，最终通过相对缓和的调度和调频来实现。

当N为1帧时，此时表示只有一帧有效数据，还有一个空闲buffer给生产者，此时margin的值设置为FrameCacheBuffer_1，也延后deadline。

对于RtgSchedManager，在前述的drawFrame结束时，并且第三状态标记为DO_NEXT_FRAME，RtgSchedManager可以根据前述有效帧数量N指示内核调度器帧绘制窗口的类型，所述类型与帧数量N相关。表5示出了一种帧数量、帧绘制窗口指示和绘制窗口的调节量的对应关系。

表5帧数量、帧绘制窗口指示和绘制窗口的调节量的对应关系

帧数量	帧绘制窗口指示	绘制窗口的调节量
			0	FAME_BEGIN_0	FrameWindowMargin_0
1	FAME_BEGIN_1	FrameWindowMargin_1
			2	FAME_BEGIN_2	FrameWindowMargin_2

内核调度器根据帧绘制窗口指示，选择对应的帧绘制窗口的调节量，设定当前帧绘制窗口的Deadline。内核调度器根据帧绘制窗口的预期截至点Deadline控制参数和帧绘制动作信息确定帧绘制窗口的时间窗和Dealine，进一步周期性的确定帧绘制窗口中每个周期点上的帧绘制关联线程的负载和CPU资源，并调度帧绘制关联线程以所给的CPU资源运行。

应理解，内核调度器确定帧绘制窗口和Deadline的过程可以参考上述方法300中的描述，为了简洁，在此不再赘述。

以上介绍了场景一和场景三中帧绘制窗口的识别、指示和调度的方法400，下面介绍场景二中帧绘制窗口的识别、指示和调度的方法500。

图13示出了本申请实施例的帧绘制窗口的识别、指示和调度的方法500的示意性流程图，如图13所示，该方法包括：

S501，UI线程判断doFrame中的TRAVERSAL_CALLBACK是否已经注册。

在本例中，帧绘制doFrame开始时，doFrame的回调函数列表中没有注册TRAVERSAL_CALLBACK对应的子过程，doFrame认为该帧不需要绘制，因而不通知RtgSchedManager去触发帧绘制窗口开始的指示动作。

但doFrame中包含了动画animation子过程，animation过程中判断需要进行界面的渲染刷新，因而注册了TRAVERSAL_CALLBACK对应的回调过程doTraversal1。

S502，UI线程向RtgSchedManager发送doTraversal1开始事件。

doTraversal回调在animation过程的后面执行，当前doFrame中的animation结束后，运行doTraversal过程，doTraversal开始阶段向RtgSchedManager发送doTraversal1开始事件。

S503，RtgSchedManager中发现第一状态标记非FRAME时，指示内核调度器帧绘制窗口开始。

S504，UI线程向render线程发送draw过程指示。

同场景一，在doTraversal1的子过程draw中，draw过程会通知render线程开始drawFrame。一般情况下，Draw过程会阻塞UI线程，直到Render线程完成drawFrame的子过程syncFrameState。此时UI线程从阻塞状态恢复的运行状态，处理其他非帧绘制过程或处理下一帧绘制过程。而render线程继续完成当前的帧绘制的渲染动作。

S505，在render线程的drawFrame开始阶段，render线程向RtgSchedManager发送drawFrame开始事件。RtgSchedManager标记第二状态标记为render线程渲染中。

Render线程完成drawFrame的子过程syncFrameState中，发现当前帧需要重新绘制，UI线程从draw过程的阻塞状态恢复时，收到当前帧需要重新绘制的通知。UI线程因而再次注册了TRAVERSAL_CALLBACK对应的回调过程doTraversal2。

S506，Render线程drawFrame时，UI线程运行doTraversal2。doTraversal2开始阶段，UI线程向RtgSchedManager发送doTraversal2开始事件。

S507，RtgSchedManager中发现第二状态标记为render线程渲染中，则标记第三状态为下一帧开始(DO_NEXT_FRAME)。

下来的过程与场景一类似，Render线程的drawFrame结束时，RtgSchedManager判断第三状态标记是否为DO_NEXT_FRAME，如果是则说明UI线程的下一帧(由doTraversal2触发的绘制)已经在绘制中，下一帧的帧绘制窗口被延误，则指示内核调度器帧绘制窗口开始。这种情况下，丢弃帧绘制窗口结束的指示动作。内核调度器连续收到两次帧绘制窗口的开始指示，可以自动进入下一帧的帧绘制窗口的负载跟踪和帧绘制线程的调度中。

S508，render线程向RtgSchedManager发送drawFrame结束事件。

S509，RtgSchedManager判断第三状态是否为DO_NEXT_FRAME，如果是，则指示内核调度器帧绘制窗口开始。

需要说明的是，帧模型和帧模型的组合可以是自由的，场景一中的第一帧可以与场景二的第二帧组合，场景二的第一帧可以与场景一的第二帧组合。同时，任何一个场景中，第二帧可能不存在，也可能是第一第一帧与第二第一帧的组合。所述第一第一帧与第二第一帧的组合场景是指，直到第一第一帧的drawFrame结束，第二第一帧的doFrame还没有开始。

以上结合图8至图13介绍了帧绘制场景，下面介绍非帧绘制场景。

非帧绘制场景是指UI主线程中，除了帧绘制场景之外的其他可识别的过程。这里将非帧绘制过程分为关键过程和非关键过程。本申请实施例中重点描述非帧绘制场景中的关键过程。

UI主线程中的关键过程主要包括ActivityTrasaction、PerformClick和ViewInflate等等。关键过程的划分主要是通过性能测试模型中识别出来的对性能延时影响比较大的过程函数。所以，当发现其他对性能测试影响较大的函数，通过本申请实施例的技术方案对性能有明显提升就可以将该过程设定为关键过程。

应理解，性能测试模型不是本申请实施例关注的，本申请实施例中假定关键过程的选择已经通过性能测试模型或其他方法确定好。

图14示出了UI线程中的关键过程、非关键过程以及帧绘制过程在运行时间轴上的关系。

用户点击应用，触发PerformClick过程(点击处理过程)，PerformClick中决定运行新的应用组件时，继而触发ActivityTrasaction过程(活动组件处理过程)。

ActivityTrasaction随即加载新的界面，触发多个帧绘制doFrame过程，Inflate一般会嵌入在ActivityTrasaction或doFrame过程中。特殊场景下，Inflate过程(视图构造过程)可以在二者的外面。

PerformClick、Inflate这些关键过程与doFrame过程的识别和指示动作类似，下面重点描述ActivityTrasaction过程的CPU资源调度过程。

ActivityTrasaction运行时，一般有两个ActivityTrasaction成对出现，前一个Activity运行暂停过程ActivityTrasactionPause，后一个Activity运行恢复过程ActivityTrasactionResume。这两个Activity的进程关系分：

(1)同一个进程的两个activity；

(2)同一个应用中两个进程的activity；

(3)不同应用的两个进程的activity。

由于两个Activity所属的进程存在上述情况，需要内核调度器对多个进程的帧绘制动作指示进程冲裁，确定合适的帧绘制窗口。内核调度器调度方法中详细描述。

下面介绍内核调度器的调度方法，内核调度器可能同时接受到多个应用的多个进程发送的帧绘制动作指示指令，这些进程之间互相不感知对方的存在和状态。以Android系统为例，一般由系统服务进程承担应用和进程的管理。

图15示出了本申请实施例提供的内核调度器的调度方法600的示意性流程图，帧绘制动作指示的使能和停止是由系统服务进程通过setFrameSchedThreads下发给内核调度器。该方法600包括：

S601：第一前台应用APP1_UI中的界面控件检测到用户的操作，触发控件的PerformClick过程。

有些应用的PerformClick过程比较复杂，CPU供给不及时。因而本申请实施例中将PerformClick定义为关键过程，使能关键过程窗口的资源调度。在该过程的开始点指示内核调度器开始点击调度(clickSchedBegin)，结束点指示内核调度器结束点击调度(clickSchedEnd)。PerformClick过程中如果启动了一个新的应用APP2_UI，APP1_UI会通知系统服务进程启动新的活动组件(newActivityStar)t。

S602：系统服务进程在启动新应用的过程中，识别出新进程的绘制线程UI和Render线程，通过设置帧绘制线程(setFrameSchedThreads)指示内核调度器新的绘制线程。

内核调度器则执行绘制线程的切换动作：停止对前一个应用的绘制线程的帧窗口调度，使能对新应用的绘制线程的帧窗口调度模式。

S603：系统服务进程在S602的基础上，同时向APP2_UI发送通知应用到前台(notifyAppToForegrund)指示。APP2_UI收到notifyAppToForegrund后，使能本方案的帧调度模式。

S604：系统服务进程在S602的基础上，同时向APP1_UI发送通知应用到后台(notifyAppToBackground)。APP1_UI收到notifyAppToBackground后，停止帧调度模式。

S605，APP2_UI通知内核调度器开始活动组件调度(activitySchedStart)。

当活动组件调度完成后，APP2_UI通知内核调度器结束活动组件调度(activitySchedEnd)。

应理解，Android中activity的启动流程的多样性，本例中activity启动流程是其中一种可能，不局限于此。本例主要说明Activity启动时，发生应用进程切换时，帧调度的关键控制流程。

更具体的：

如上例，APP1_UI执行activity停止过程ActivityTrasactionPause时，指示内核调度器启动非帧绘制关键过程窗口的调度。在该窗口中，系统服务进程设置setFrameSchedThreads，内核调度器修改帧绘制线程的ID列表。

随后，当APP2_UI执行activity停止过程ActivityTrasactionStart时，指示内核调度器启动该进程的非帧绘制关键过程窗口的调度。内核调度器停止APP1_UI线程的非帧绘制关键过程窗口的调度，重新启动APP2_UI线程的非帧绘制关键过程窗口的调度。

在APP2_UI线程的非帧绘制关键过程窗口过程中，APP1_UI下发的任何动作指示都被忽略，如activitySchedEnd、frameSchedStart都不会影响该窗口的起止点。

下面介绍本申请实施例提供的帧绘制线程关联线程的识别和调度方法。

帧绘制线程在绘制一帧的过程中，可能会被阻塞。典型的例子是，UI线程调用系统服务进程中的窗口管理模块，获取显示窗口的信息。此时，UI线程是通过进程间通信通道Binder发送指令给窗口管理服务WMS，WMS中的Binder线程接收指令并处理后从原通道回复查询的信息。这种情况下，WMS中的Binder线程是UI线程的依赖线程，内核调度器在调度时，可以感知到UI线程对该Binder线程的依赖，将该Binder线程加入到帧绘制关联线程组中，并基于帧绘制窗口的负载调度该线程。

同样的，WMS中的Binder线程在处理UI线程的请求时，需要先获取WMS锁，此时如果WMS锁被其他WMS的线程WMS所持有，则可以将线程WMS加入到帧绘制关联线程组中，以便内核调度器基于帧绘制窗口的负载调度该线程，加速该线程的运行。

当用户点击界面时触发performClick关键过程。如图16所示，图16示出了一种帧绘制线程关联线程的识别和调度方法700的示意性流程图，该方法700包括：

S701，UI线程中的PerformClick过程向Binder线程发送请求(request)。

S702，内核调度器接收该请求，内核调度器将该请求加入到Binder线程的接收队列中。

S703，内核调度器唤醒Binder线程执行。

S704，为了加快binder线程的执行，内核调度器将执行addThreadToRtg过程，将binder线程加入到帧绘制关联线程组中。

因为UI线程的PerformClick过程是非绘制场景中的关键过程，在其执行窗口中，Binder线程也被当作帧绘帧关联线程一起调度。

S705，Binder线程向内核调度器返回执行结果(response)。

S706，内核调度器将结果反馈给UI线程的同时，执行removeThreadFromRtg，将Binder线程从帧绘制关联线程组移除。

通过上面的方法，Binder线程参与帧绘制关联线程组的联合调度，在关键窗口期内享受基于帧绘制窗口的调度，间接提高了UI线程中PerformClick过程的执行速度。

本申请实施例中，将关键线程中的关键过程识别出来，指示调度器在关键过程执行的窗口内调度CPU资源，能够实现快上快下的按需分配，显著提升关键过程的运行；同时将关键线程中的非关键过程区别出来，在非关键过程中，不需要激进的CPU资源，以提供较高的功耗效率；显然，该方法对非关键线程能够自动排出在高功耗的范围内。

本申请实施例中，系统服务进程、前台应用进程和内核调度器之间通信可以如图2所示，一个实施例中，该系统服务进程、前台应用进程和内核调度器之间通信还可以如图17所示。

图17示出了本申请实施例的技术方案应用的系统200的另一示意图，相比于图2，图17中的系统200增加了帧窗口调度进程204，系统服务进程和前台应用进程通过帧窗口调度进程204间接与内核调度器通信。

本实施例中帧窗口调度进程204接收系统服务进程和前台应用进程的配置与指令，经过处理后发送到内核调度器。这样，部分由内核调度器执行的处理过程可以由帧窗口调度进程来完成，如多个应用进程发送帧绘制动作指示时，帧绘制窗口调度进程204决策哪个进程的指令被允许发送给内核调度器；内核调度器中缓存的配置信息、帧绘制线程等信息也可以由帧窗口调度进程204来实现。

如上述方法600中描述，帧窗口调度进程204可以检查当前线程ID与系统服务进程配置的ID是否匹配，如果不匹配，则可以拦截其他前台应用进程向内核调度器发送的指令，从而保证了内核调度器的安全性。

通过在系统服务进程、前台应用进程和内核调度器之间增加帧窗口调度进程，有助于简化内核调度器的实现复杂度，同时也可以提高内核调度器的安全性和稳定性。

图18示出了本申请实施例提供的资源调度的方法800的示意性流程图，该方法800可以由电子设备执行，也可以由电子设备中的内核调度器执行，下面以执行主体为电子设备为例进行说明，如图18所示，该方法800包括：

S801，子设备接收到用户的第一操作。

示例性的，如图2所示，电子设备中系统服务进程中主绘制线程识别模块检测应用的前后台切换事件，当发生前后台切换事件时，主绘制线程识别模块可以向内核调度器指示前台应用的帧绘制线程的标识。

S802，电子设备响应于该第一操作，获取该电子设备的前台应用。

示例性的，电子设备检测到用户在电子设备的桌面点击某个前台应用的图标后，打开该前台应用，显示该前台应用的界面，该电子设备进入前台应用。

具体的，当电子设备检测到用户在电子设备的桌面点击某个前台应用的图标(例如，淘宝)后，应用程序层的前台应用会向框架层的系统服务模块发送该前台应用对应的标号(例如，进程识别号(process identifier，PID))和该前台应用对应的进程名称，系统服务模块可以通过该标号和进程名称确定是哪个App启动了。

例如，电子设备通过确定该前台应用的进程识别号和进程名称确定该前台应用启动了。

S803，该电子设备确定该前台应用的帧绘制线程的第一过程窗口，该第一过程窗口用于指示帧绘制过程，或者，该第一过程窗口用于指示关键过程；

示例性的，当电子设备检测到用户的操作时，系统服务进程可以通知前台应用进程开启帧绘制动作的识别和指示以及非帧绘制动作的识别和指示。当前台应用进程识别出帧绘制线程的帧绘制过程或者关键过程后，前台应用进程可以向内核调度器指示该帧绘制过程或者关键过程。

应理解，该帧绘制过程可以为表2中的FrameWindowMargin_0、FrameWindowMargin_1或者FrameWindowMargin_2，该关键过程可以为非帧绘制过程中的关键过程，如表2所示，该关键过程可以为ActivityTrasaction或者PerformClick。

本申请实施例中，前台应用可以向内核调度器指示帧绘制过程或者关键过程的标识信息，例如，0为PerfmClick过程的标识，1为ActivityTrasaction过程的标识，2为FrameWindowMargin_0的标识，3为FrameWindowMargin_1的标识，4为FrameWindowMargin_2的标识。具体指示标识的先后顺序可以根据用户的操作进行。

当指示帧绘制过程时，电子设备可以根据显示缓冲器中缓存的帧的数量，确定该帧绘制过程，示例性的，显示缓冲器中缓存的帧的数量可以为0、1或2，电子设备在确定第一过程窗口时可以根据缓存的帧的数量确定当前的帧绘制过程，并且可以根据具体实施例中表2确定出对应的margin值，进而确定该过程窗口的预期最长时间deadline。

S804，在该第一过程窗口内，该电子设备执行步进硬件资源调度策略，该步进硬件资源调度策略为随着时间的增加，增加调度的硬件资源。

示例性的，当内核调度器接收到前台应用进程指示的帧绘制过程或者关键过程时，可以确定调度当前过程窗口的调度策略为随着调度时间的增加，增加调度的硬件资源，从而调度帧绘制线程在决策的资源上运行。

本申请实施例的资源调度的方法，电子设备通过识别帧绘制线程中的帧绘制过程或者关键过程，从而执行相应的资源调度，调度的粒度相比于线程粒度更加精细，有助于提升电子设备对帧绘制线程的资源进行硬件资源调度时的准确度。同时，对于帧绘制过程和关键过程，在进行资源调度时，随着时间的增加，电子设备可以增加调度的硬件资源，有助于保证帧绘制过程和关键过程及时完成。

示例性的，如图4和图5所示，当该电子设备确定前台应用的帧绘制线程的过程窗口后，可以确定过程窗口的类型对应的margin值，从而确定该过程窗口的deadline，如图4或图5所示，当该对于margin值为-8、0、8或者16的情况，其对应的调度的硬件资源随着调度时间的增加，电子设备可以增加调度的硬件资源。

示例性的，当magin值为-16时，其对应的第二硬件资源量，例如，电子设备可以按照其支持的最大调度的硬件资源(负载1024)进行资源调度。

可选地，该方法还包括：

该电子设备确定该前台应用的帧绘制线程的第二过程窗口；

在从该第二过程窗口开始的第一时间段内，该电子设备根据第一硬件资源量进行硬件资源调度，该第一硬件资源量由该第一过程窗口的负载情况确定。

可选地，该第一硬件资源量为该第一过程窗口调度的硬件资源量的平均值。

应理解，本申请实施例中对该第一过程窗口的负载情况并不作任何限定，该第一过程窗口的负载情况可以是该第一过程窗口内某一个调度周期内调度的硬件资源量；或者，该第一过程窗口的负载情况为该第一过程窗口调度的硬件资源量的平均值的一半；或者，该第一过程窗口的负载情况为该第一过程窗口调度的硬件资源量的平均值的两倍。

一个实施例中，该电子设备保存有过程窗口调度的硬件资源量的下限值，在该第二过程窗口开始时，电子设备可以先确定该下限值和第一过程窗口的负载情况中比较大的一个，在第二过程窗口在第一时间段内可以按照其中比较大的一个硬件资源量进行硬件资源调度。该下限值可以是第二过程窗口之前的过程窗口中调度的硬件资源量的平均值中最低的一个值，也可以是一个预设的门限值。

示例性的，如图6所示，在该电子设备对过程窗口调度的第一时间段内(例如，0～t₁)内，该电子设备可以按照上一过程窗口负载的情况对该第二过程窗口进行资源的调度。

可选地，该第一过程窗口为该第二过程窗口的上一个过程窗口。

本申请实施例中，该第一过程窗口可以为该第二过程窗口的上一个过程窗口，也可以是该第二过长窗口的上两个过程窗口，还可以是该帧绘制线程中的第一个过程窗口，本申请实施例对此并不作任何限定。

可选地，该方法还包括：

在该第二过程窗口内，若按照该步进硬件资源调度策略调度的硬件资源量大于或者等于该第一硬件资源量时，执行该步进硬件资源调度策略。

示例性的，如图6所示，当该电子设备执行资源调度的时间达到t₁时，该电子设备可以继续执行该步进硬件资源调度策略，即随着时间的增加，该电子设备增加调度的资源。

应理解，在判断根据该步进硬件资源调度策略确定的硬件资源量和该第一硬件资源量的大小关系时，需要根据同一类型的硬件资源进行判断。

例如，该第一硬件资源量为上一个过程窗口调度的平均CPU资源(例如，小核900M)，则根据该步进硬件资源调度策略确定硬件资源量时，也可以确定其对应的CPU资源。在t₁时刻根据公式(1)计算得到的CPU资源(例如需要调度的CPU频率为900M)，则电子设备可以执行该步进硬件资源调度策略。

又例如，该第一硬件资源量为上一个过程窗口调度的平均GPU资源量，则电子设备根据该步进硬件资源调度策略确定硬件资源量时，也可以确定对应的GPU资源。

电子设备也可以在t₁时刻之后的某一个时刻确定需要调度的CPU频率是小核1100M时，停止按照该第一硬件资源量调度，而开始执行该步进硬件资源调度策略。

可选地，该方法还包括：

在该步进硬件资源调度策略所调度的硬件资源量达到第一阈值时，该电子设备停止执行该步进硬件资源调度策略；

该电子设备按照第二硬件资源量对该第一过程窗口进行硬件资源调度，该第二硬件资源量大于或者等于该第一阈值。

应理解，该第二硬件资源量可以为电子设备保存的过程窗口调度的硬件资源量的上限值。

示例性的，如图6中的(a)所示，当该电子设备执行资源调度的时间达到t₂时，该电子设备停止执行该步进硬件资源调度策略，并且按照该电子设备所支持的最大硬件资源量(例如，负载1024)进行资源调度。

示例性的，如图6中的(b)所示，当该电子设备执行资源调度的时间达到t₃时，该电子设备停止执行该步进硬件资源调度策略，并且按照该过程窗口所支持的最大硬件资源量(例如，负载900)进行资源调度。

可选地，该方法还包括：该第二硬件资源量为该电子设备支持的最大硬件资源量，或者，该第二硬件资源量为该第一过程窗口预设的最大可用硬件资源量。

可选地，该方法还包括：该电子设备确定该前台应用的帧绘制线程的第三过程窗口；在该第三过程窗口内，该电子设备按照第三硬件资源量进行硬件资源调度。

示例性的，如图4所示，当margin值为-16时，其对应的第二硬件资源量，例如，电子设备可以按照其支持的最大调度资源(负载1024)进行硬件资源调度。

可选地，该第二硬件资源量和该第三硬件资源量相同。

可选地，在该第一过程窗口内，执行步进硬件资源调度策略，包括：在该第一过程窗口内，一次或者多次增加调度的硬件资源量。

本申请实施例中，以CPU资源为例，电子设备一次或者多次增加调度的硬件资源量可以理解为，电子设备一次或者多次调整CPU核以及CPU频率；或者，以GPU资源为例，电子设备一次或者多次增加调度的硬件资源量可以理解为，电子设备一次或者多次调整GPU频率。

如表1所示，电子设备可以在第一过程窗口中从小核的900M增大到大核的1800M，即只进行了一次增加调度的硬件资源量；也可以是在第一过程窗口中从小核的900M、到小核的1100M，再到大核的2000M多次增加调度的硬件资源量。

示例性的，该电子设备可以根据该第一过程窗口的标识确定对应的margin值，从而可以确定deadline的值，进而确定计算实时负载的方式，或者，可以进而确定计算实时负载曲线的斜率，实时负载的计算方式或者实时负载曲线的斜率都可以反映出该电子设备增加资源调度的速度。如图4所示，当margin值为-8时，该电子设备增加调度的硬件资源的速率最快。

例如，如图6中的(a)所示，在该第一过程窗口的开始的0～t₁内，电子设备可以按照上一帧的平均负载(例如，300)进行资源调度；在t₁～t₂内，电子设备可以按照二次函数的曲线确定对应的硬件资源量。示例性的，t₁为从过程窗口开始第15ms，t₂为从过程窗口开始第35ms，调度周期为4ms，则在t₁～t₂内，一共有5个调度周期。电子设备可以在每个调度周期的起始时刻确定一个调度硬件资源量，然后在这个调度周期中按照起始时刻确定的调度硬件资源量进行硬件资源调度。例如，在第二个调度周期的起始时刻(第20ms时)，电子设备可以根据公式(1)确定vload为620，根据表1，电子设备可以选择大核，CPU频率为1400M进行资源的调度；又例如，在第三个调度周期的起始时刻(第25ms时)，电子设备可以根据公式(1)确定vload为740，根据表1，电子设备可以选择大核，CPU频率为1600M进行资源的调度。

应理解，该电子设备可以周期性增加调度的硬件资源，也可以不周期性得增加调度的硬件资源；该电子设备在该第一过程窗口内可以多次增加调度的硬件资源，也可以只增加一次调度的硬件资源。

应理解，本申请实施例中，第一过程窗口、第二过程窗口和第三过程窗口进行硬件资源调度时均可以按照图4至图6中所示的硬件资源调度方式进行。

可选地，该方法还包括：

在该帧绘制线程发生中断时，该电子设备确定与该帧绘制线程对应的关联线程；

该电子设备对该关联线程的资源进行硬件资源调度。

可选地，该调度的硬件资源包括中央处理器CPU资源、图形处理器GPU资源、内存资源或者输入输出IO资源中的一种或者多种。

可选地，若该资源为CPU资源，该CPU资源可以包括帧绘制线程运行的CPU核以及帧绘制线程运行的CPU核的频率，该电子设备可以根据计算得到的vload确定当前过程窗口的CPU核以及该CPU核对应的频率。

可选地，该CPU核至少包括一个大核和一个小核，每个CPU核至少包括两个不同的CPU频率。

可以理解的是，电子设备为了实现上述功能，其包含了执行各个功能相应的硬件和/或软件模块。

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

本实施例可以根据上述方法示例对电子设备进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块可以采用硬件的形式实现。需要说明的是，本实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

在采用对应各个功能划分各个功能模块的情况下，图19示出了上述实施例中涉及的电子设备900的一种可能的组成示意图，如图19所示，该电子设备900可以包括：接收单元901、获取单元902、确定单元903和资源调度单元904。

其中，接收单元可以用于支持电子设备900实现上述步骤801等，和/或用于本文所描述的技术的其他过程。

获取调度单元可以用于支持电子设备900实现上述步骤802等，和/或用于本文所描述的技术的其他过程。

确定单元903可以用于支持电子设备900实现上述步骤803等，和/或用于本文所描述的技术的其他过程。

资源调度单元904可以用于支持电子设备900实现上述步骤804等，和/或用于本文所描述的技术的其他过程。

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

本实施例提供的电子设备，用于执行上述资源调度的方法，因此可以达到与上述实现方法相同的效果。

在采用集成的单元的情况下，电子设备可以包括处理模块、存储模块和通信模块。其中，处理模块可以用于对电子设备的动作进行控制管理，例如，可以用于支持电子设备执行上述确定单元901和资源调度单元902执行的步骤。存储模块可以用于支持电子设备执行存储程序代码和数据等。通信模块，可以用于支持电子设备与其他设备的通信。

其中，处理模块可以是处理器或控制器。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。处理器也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，数字信号处理(digital signal processing，DSP)和微处理器的组合等等。存储模块可以是存储器。通信模块具体可以为射频电路、蓝牙芯片、Wi-Fi芯片等与其他电子设备交互的设备。

在一个实施例中，当处理模块为处理器，存储模块为存储器时，本实施例所涉及的电子设备可以为具有图1所示结构的设备。

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

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

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

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

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

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

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

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

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

以上内容，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。

Claims

1.一种资源调度的方法，所述方法应用于电子设备，其特征在于，包括：

接收到用户的第一操作；

响应于所述第一操作，获取所述电子设备的前台应用；

确定所述前台应用的帧绘制线程的第一过程窗口，所述第一过程窗口用于指示帧绘制过程，或者，所述第一过程窗口用于指示关键过程；

在所述第一过程窗口内，执行步进硬件资源调度策略，所述步进硬件资源调度策略为随着时间的增加，增加调度的硬件资源。

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

确定所述前台应用的帧绘制线程的第二过程窗口；

在从所述第二过程窗口开始的第一时间段内，根据第一硬件资源量进行硬件资源调度，所述第一硬件资源量由所述第一过程窗口的负载情况确定。

3.根据权利要求2所述的方法，其特征在于，所述第一过程窗口为所述第二过程窗口的上一个过程窗口。

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

在所述第二过程窗口内，若按照所述步进硬件资源调度策略调度的硬件资源量大于或者等于所述第一硬件资源量时，执行所述步进硬件资源调度策略。

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

在所述步进硬件资源调度策略所调度的硬件资源量达到第一阈值时，停止执行所述步进硬件资源调度策略；

按照第二硬件资源量对所述第一过程窗口进行硬件资源调度，所述第二硬件资源量大于或者等于所述第一阈值。

6.根据权利要求5所述的方法，其特征在于，所述第二硬件资源量为所述电子设备支持的最大硬件资源量，或者，所述第二硬件资源量为所述第一过程窗口预设的最大可用硬件资源量。

7.根据权利要求1至3中任一项所述的方法，其特征在于，所述方法还包括：

确定所述前台应用的帧绘制线程的第三过程窗口；

在所述第三过程窗口内，按照第三硬件资源量进行硬件资源调度。

8.根据权利要求1至3中任一项所述的方法，其特征在于，所述在所述第一过程窗口内，执行步进硬件资源调度策略还包括：

在所述第一过程窗口内，一次或者多次增加调度的硬件资源量。

9.根据权利要求8所述的方法，其特征在于，所述在所述第一过程窗口内，一次或者多次增加调度的硬件资源量，包括：

在所述第一过程窗口内，周期性得多次增加调度的硬件资源量。

10.根据权利要求1至3中任一项所述的方法，其特征在于，所述方法还包括：

当所述第一过程窗口结束时，停止执行所述步进硬件资源调度策略。

11.根据权利要求1至3中任一项所述的方法，其特征在于，所述方法还包括：

在所述帧绘制线程发生中断时，确定与所述帧绘制线程对应的关联线程；

根据对所述帧绘制线程调度的硬件资源量，对所述关联线程的资源进行硬件资源调度。

12.根据权利要求1至3中任一项所述的方法，其特征在于，所述帧绘制线程包括主线程和/或渲染线程。

13.根据权利要求1至3中任一项所述的方法，其特征在于，所述硬件资源包括中央处理器CPU资源、图形处理器GPU资源、内存资源或者输入输出IO资源中的一种或者多种。

14.根据权利要求1至3中任一项所述的方法，其特征在于，非帧绘制过程包括点击过程或者活动组件运行过程。

15.一种电子设备，其特征在于，包括：一个或多个处理器；存储器；多个应用程序；以及一个或多个程序，其中所述一个或多个程序被存储在所述存储器中，当所述一个或者多个程序被所述处理器执行时，使得所述电子设备执行如权利要求1至14中任一项所述的资源调度的方法。

16.一种计算机存储介质，其特征在于，包括计算机指令，当所述计算机指令在电子设备上运行时，使得所述电子设备执行如权利要求1-14中任一项所述的资源调度的方法。

17.一种计算机程序产品，其特征在于，当所述计算机程序产品在计算机上运行时，使得所述计算机执行如权利要求1-14中任一项所述的资源调度的方法。