CN110837420A - 资源调度方法、装置、终端及存储介质 - Google Patents

Abstract

本申请实施例公开了一种资源调度方法、装置、终端及存储介质，属于计算机技术领域，当终端中运行的目标应用发生卡顿事件时，终端获取资源调度数据，并根据资源调度数据，确定造成卡顿事件的异常资源调度事件，当异常资源调度事件是操作***调度造成的事件时，终端将对应的资源分配给目标应用。由于本申请能够在目标应用产生卡顿事件后，即刻获取资源调度数据并进行分析，当该事件是操作***调度造成的异常事件时，将异常资源调度事件对应的资源分配给目标应用，使得目标应用在卡顿事件发生后能够迅速确定造成卡顿的主要原因，并释放对应的资源，提升了目标应用的平均帧率和帧率稳定性，进而提高了目标应用的运行效果。

Description

资源调度方法、装置、终端及存储介质

技术领域

本申请实施例涉及计算机技术领域，特别涉及一种资源调度方法、装置、终端及存储介质。

背景技术

随着高性能的应用的日益发展和应用，安装在终端中的高性能的应用提高了用户的工作效率，并丰富了用户的娱乐生活。

相关技术中，高性能的应用对于终端的硬件资源的需求也较高。为了保证高性能的应用始终有较高的数据计算能力，本领域技术人员通常将高性能的应用的主线程绑定在终端的高性能核心上。

然而，在一些场景中，已将主线程绑定到高性能核心的应用仍会出现卡顿现象。

发明内容

本申请实施例提供了一种资源调度方法、装置、终端及存储介质，可以解决已将主线程绑定到高性能核心的应用仍会出现卡顿现象的问题。所述技术方案如下：

根据本申请的一方面内容，提供了一种资源调度方法，所述方法包括：

当目标应用发生卡顿事件时，获取资源调度数据，所述资源调度数据是所述目标应用在目标时段内调用资源的数据，所述目标时段是所述卡顿事件发生时前的指定时长的时段；

根据所述资源调度数据，确定造成所述卡顿事件的异常资源调度事件；

当所述异常资源调度事件属于***调度异常事件时，将所述异常资源调度事件对应的资源分配给所述目标应用。

根据本申请的另一方面内容，提供了一种资源调度装置，所述装置包括：

数据获取模块，用于当目标应用发生卡顿事件时，获取资源调度数据，所述资源调度数据是所述目标应用在目标时段内调用资源的数据，所述目标时段是所述卡顿事件发生时前的指定时长的时段；

异常确定模块，用于根据所述资源调度数据，确定造成所述卡顿事件的异常资源调度事件；

资源分配模块，用于当所述异常资源调度事件属于***调度异常事件时，将所述异常资源调度事件对应的资源分配给所述目标应用。

根据本申请的另一方面内容，提供了一种终端，所述终端包括处理器和存储器，所述存储器中存储有至少一条指令，所述指令由所述处理器加载并执行以实现如本申请实施提供的资源调度方法。

根据本申请的另一方面内容，提供了一种计算机可读存储介质，所述存储介质中存储有至少一条指令，所述指令由处理器加载并执行以实现如本申请实施提供的资源调度方法。

本申请实施例提供的技术方案带来的有益效果可以包括：

当终端中运行的目标应用发生卡顿事件时，终端获取资源调度数据，并根据资源调度数据，确定造成卡顿事件的异常资源调度事件，当异常资源调度事件是操作***调度造成的事件时，终端将异常资源调度事件对应的资源分配给目标应用。由于本申请能够在目标应用产生卡顿事件后，即刻获取资源调度数据并进行分析，当获知造成卡顿事件的异常资源调度事件后，终端能够当该事件是操作***调度造成的异常事件时，将异常资源调度事件对应的资源分配给目标应用，使得目标应用在卡顿事件发生后能够迅速确定造成卡顿的主要原因，并获取该原因侵占的资源，将该资源分配给目标应用，从源头上迅速解决了目标应用产生卡顿的问题，从而减少了目标应用的卡顿，提升了目标应用的平均帧率并提升了目标应用的帧率稳定性，进而提高了目标应用的运行效果。

附图说明

为了更清楚地介绍本申请实施例中的技术方案，下面将对本申请实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。

图1是本申请一个示例性实施例提供的一种终端的结构框图；

图2是本申请一个示例性实施例提供的一种资源调度方法的流程图；

图3是本申请另一个示例性实施例提供的另一种资源调度方法流程图；

图4是基于图3所示实施例提供的一种与低频异常模版相匹配的事件的资源调度数据示意图；

图5是基于图3所示实施例提供的一种与占核异常模版相匹配的事件的资源调度数据示意图；

图6是基于图3所示实施例提供的一种与应用逻辑异常模版相匹配的事件的资源调度数据示意图；

图7是本申请一个示例性实施例提供的一种资源调度装置的结构框图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。

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

在本申请的描述中，需要理解的是，术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性。在本申请的描述中，需要说明的是，除非另有明确的规定和限定，术语“相连”、“连接”应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或一体地连接；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连。对于本领域的普通技术人员而言，可以具体情况理解上述术语在本申请中的具体含义。此外，在本申请的描述中，除非另有说明，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。

为了本申请实施例所示方案易于理解，下面对本申请实施例中出现的若干名词进行介绍。

卡顿事件：是指目标应用触发的一种事件。在一种可能的实现方式中，该卡顿事件可以是中断。在本申请的一种可能的实现方式中，卡顿事件在发生时可以同时生成卡顿信号。当***中的功能模块接收到卡顿信号时，相应的功能模块可以获知该卡顿事件。

资源调度数据：是目标应用在目标时段内调用资源的数据。需要说明的是，资源可以是处理器资源、网络资源、读写资源(又称：I/O资源)或存储资源中至少一种。其中，处理器资源可以是处理器核心大小、处理器核心数量、处理器负载或处理器频率中的至少一种。资源调度数据可以从进程或线程的粒度上反映目标应用调度各个资源的数据。例如，资源调度数据可以在进程的粒度上，反映各个进程在时间轴上使用的处理器核心是大核还是小核，处理器的核心运行时的频率是多少，且进程具体在哪些时段运行，在哪些时段等待运行，在哪些时段休眠。相同的，资源调度数据也能够在线程的粒度上获知各个线程的资源调度情况。

可选地，在一种落地的应用场景中，资源调度数据可以是systrace(英文：SystemTrace，中文：***追踪)数据。需要说明的是，本申请实施例还能够通过获取其它类型的资源调度数据，本申请实施例对此不作限定。

目标时段：是卡顿事件发生时前的指定时长的时段。需要说明的是，若卡顿事件发生在A时刻，则目标时段是以A时刻为结束时刻的指定时长的时段。可选地，指定时长是一个长度为常数值的时长，可以是500毫秒、1秒或2秒等数值，本申请实施例对此不作限定。

异常资源调度事件：用于造成卡顿事件最主要因素所组成的事件。可选地，该异常资源调度事件是目标应用中的一个线程调用资源时的事件，该线程既可以是目标应用的主线程(又称逻辑线程)，也可以是目标应用中除主线程之外的线程。

可选地，异常资源调度事件可以分为两类。第一类异常资源调度事件可以是操作***调度造成的异常事件。在该类异常资源调度事件中，操作***对于资源的调度不当造成了卡顿事件。第二类异常资源调度事件可以是目标应用本身的逻辑错误造成的异常事件。在该类异常资源调度事件中，目标应用本身的逻辑错误可以包括主线程死锁、休眠(英文：sleep)异常或主线程执行时间过长等问题。需要说明的是，目标应用的逻辑错误还可以是其它能够造成卡顿事件的错误，本申请实施例对此不作限定。

目标应用：指能够运行在终端的操作***中，并提供可视的用户界面的指定应用。其中，目标应用可以是游戏应用、购物程序、即时通讯程序、博客应用、制图绘画应用、文本编辑应用、订票应用、地图导航应用、视频播放应用、直播应用、浏览器应用、阅读应用、音乐应用、理财支付应用、相机应用、相片美化程序、智能设备控制应用、电话应用、短信程序、天气应用、时钟程序、***搜索应用、联系人程序、共享交通应用、物流应用、打车应用、外卖应用、考勤打卡应用和扫码应用中至少一种。

游戏应用：包括独立封装的游戏应用、通过第三方应用提供启动入口的游戏应用和集成在第三方应用中的游戏应用中的至少一种。

可选地，当游戏应用是独立封装的游戏应用时，该游戏应用可以是一个单独的应用、程序或者客户端。例如，游戏应用可以是通过apk(AndroidPackage，安卓安装包)安装在搭载安卓***的终端中的应用；或者，游戏应用也可以是通过ipa(iPhoneApplication，苹果应用)安装包安装在搭载ios操作***的终端中的应用。

可选地，当游戏应用是通过第三方应用提供入口的应用时，该游戏应用可以由指定的第三方应用提供入口。例如，该游戏应用可以是通过html5(HyperText MarkupLanguage 5，超级文本标记语言第5版)编写的小程序(mini program)、轻应用(Light App)或者快应用等。

可选地，游戏应用也可以根据进行游戏的方式进行分类，例如，可以包括第一人称射击类游戏应用(First-person Shooter，FPS)、角色扮演类游戏应用(Role PlayingGame，RPG)、动作角色扮演类游戏应用(Action Role Playing Game，ARPG)、多人在线战术竞技游戏应用(Multiplayer Online Battle Arena，MOBA)、大型多人在线类游戏应用(Massive Multiplayer Online Game，MMOG)、消除类游戏应用、捕鱼类游戏应用、卡牌类游戏应用、音乐类游戏应用和放置类游戏应用中的至少一种。

在一种可能的实现方式中，当游戏应用是大型多人在线类游戏应用MMOG时，该MMOG可以包括：策略类大型多人在线游戏应用(Massively Multiplayer OnlineSimulation Game，MMOSLG)、冒险类大型多人在线游戏应用(Massively MultiplayerOnline Adventure Game，MMOAVG)、模拟类大型多人在线游戏应用MMOSG、运动类大型多人在线游戏应用MMOSPT、赛车类大型多人在线游戏应用MMORCG和角色扮演类大型多人在线游戏应用MMORPG中的至少一种。

在一种可能的实现方式中，该通过第三方应用提供入口的应用无需下载安装包即可使用，相应的，在不需要使用该应用时，也无需卸载。需要说明的是，该应用在第一次使用时是通过指定的第三方应用提供入口，在后续使用过程中，用户可以为该应用创建桌面启动图标，通过桌面启动图标直接启动该应用。其中，第三方应用可以是上述目标应用中的至少一种，或者，也可以是应用市场或应用商店等应用。

可选地，当游戏应用是集成在第三方应用中的游戏应用时，该游戏可以在第三方应用运行时通过指定的启动按钮或者开启操作进行启动。该游戏无需独立安装和卸载，用于运行该游戏的配置文件和资源文件均可以集成在第三方应用中。

示例性地，本申请实施例所示的资源调度方法，可以应用在运行目标应用的终端中，该终端具备显示屏且具备防卡顿的资源调度功能。终端可以包括手机、平板电脑、膝上型电脑、台式电脑、电脑一体机、服务器、工作站、电视、机顶盒、智能眼镜、智能手表、数码相机、MP4播放终端、MP5播放终端、学习机、点读机、电纸书、电子词典、车载终端、虚拟现实(Virtual Reality，VR)播放终端或增强现实(Augmented Reality，AR)播放终端等。

请参考图1，图1是本申请一个示例性实施例提供的一种终端的结构框图，如图1所示，该终端包括处理器120、存储器140和显示组件160，所述存储器140中存储有至少一条指令，所述指令由所述处理器120加载并执行以实现如本申请各个方法实施例所述的资源调度方法。可选地，显示组件160用于显示经过处理器120渲染从存储器140中得到的图像数据所得的图像帧。

在本申请中，终端100是具备运行目标应用的电子设备。当终端100中的目标应用发生卡顿事件时，终端100能够获取资源调度数据，所述资源调度数据是所述目标应用在目标时段内调用资源的数据，所述目标时段是所述卡顿事件发生时前的指定时长的时段；根据所述资源调度数据，确定造成所述卡顿事件的异常资源调度事件；当所述异常资源调度事件是操作***调度造成的异常事件时，将所述异常资源调度事件对应的资源分配给所述目标应用。

处理器120可以包括一个或者多个处理核心。处理器120利用各种接口和线路连接整个终端100内的各个部分，通过运行或执行存储在存储器140内的指令、程序、代码集或指令集，以及调用存储在存储器140内的数据，执行终端100的各种功能和处理数据。可选的，处理器120可以采用数字信号处理(Digital Signal Processing，DSP)、现场可编程门阵列(Field－Programmable Gate Array，FPGA)、可编程逻辑阵列(Programmable LogicArray，PLA)中的至少一种硬件形式来实现。处理器120可集成中央处理器(CentralProcessing Unit，CPU)、图像处理器(Graphics Processing Unit，GPU)和调制解调器等中的一种或几种的组合。其中，CPU主要处理操作***、用户界面和应用程序等；GPU用于负责显示屏所需要显示的内容的渲染和绘制；调制解调器用于处理无线通信。可以理解的是，上述调制解调器也可以不集成到处理器120中，单独通过一块芯片进行实现。

存储器140可以包括随机存储器(Random Access Memory，RAM)，也可以包括只读存储器(Read-Only Memory，ROM)。可选的，该存储器140包括非瞬时性计算机可读介质(non-transitory computer-readable storage medium)。存储器140可用于存储指令、程序、代码、代码集或指令集。存储器140可包括存储程序区和存储数据区，其中，存储程序区可存储用于实现操作***的指令、用于至少一个功能的指令(比如触控功能、声音播放功能、图像播放功能等)、用于实现下述各个方法实施例的指令等；存储数据区可存储下面各个方法实施例中涉及到的数据等。

显示组件160用于显示暂时存放在缓存队列中的图像帧。缓存队列中的图像帧是处理器120从存储器140中获取的数据渲染得到的，当处理器120完成图像帧的渲染后，处理器120将完成渲染的图像帧添加到缓存队列中。显示组件160按照先入先出的规则，从缓存队列中提取图像帧进行显示。

可选地，显示组件160可以是显示屏、投屏组件、投影组件或全息显示组件，本申请实施例对此不作限定。

请参考图2，图2是本申请一个示例性实施例提供的一种资源调度方法的流程图。该资源调度方法可以应用在上述所示的终端中。在图2中，资源调度方法包括：

步骤210，当目标应用发生卡顿事件时，获取资源调度数据，资源调度数据是目标应用在目标时段内调用资源的数据，目标时段是卡顿事件发生时前的指定时长的时段。

在本申请实施例中，终端能够安装并运行目标应用。当目标应用运行时，目标应用的图像数据可以被终端中的处理器渲染，然后完成渲染所得到的图像帧能够显示在屏幕中。通常，当终端能够满足每秒显示24帧图像时，用户能够感受到目标应用显示的画面相对流畅。然而，当目标应用显示的图像帧每秒钟不足24帧时，用户将会感觉到卡顿，也即目标应用发生卡顿事件。

当目标应用发生卡顿事件时，终端将获取资源调度数据。在一种可能的实施方式中，终端能够***性能分析工具获取资源调度数据。可选地，该***性能分析工具可以是操作***内嵌的，也可以是操作***深度开发人员开发的，或者还可以是第三方服务商提供的工具。

可选地，操作***还能够获取资源调度数据后将该资源调度数据存储在本地。详细地，由于资源调度数据是实时获取并保存在内存中，保存的时长有限且会被定期清理。因此，本申请实施例将从内存中获取的资源调度数据存储在非易失性计算机可读存储设备中。

步骤220，根据资源调度数据，确定造成卡顿事件的异常资源调度事件。

在本申请实施例中，终端还能够对资源调度数据进行分析，获取该数据中包含的造成卡顿事件的异常资源调度事件。需要说明的是，资源调度数据可以包括目标时长内各个对象调度资源的情况。其中，对象可以是目标应用中的进程，对象也可以是目标应用中的线程，本申请实施例对此不作限定。

需要说明的是，终端具备识别造成卡顿事件的异常资源调度事件的能力。在一种可能的方式中，终端中设置有判别异常资源调度事件的条件，终端将根据该条件对资源调度数据中的事件进行判别，最后得到异常资源调度事件。可选地，该异常资源调度事件既可以是一个事件，也可以多个事件。

例如，若资源调度数据是1秒内目标应用的主线程A、资源回收线程B、渲染线程C1、渲染线程C2和突发线程D的资源调度数据，则资源调度数据可以提供1秒内上述五个线程调度各种资源的情况。

步骤230，当异常资源调度事件是操作***调度造成的异常事件时，将异常资源调度事件对应的资源分配给目标应用。

在本申请实施例中，终端能够进一步对异常资源调度事件的属性进行判别。当终端将异常资源调度事件确定为是操作***造成的异常事件时，终端能够将异常资源调度事件对应的资源分配给目标应用。需要说明的是，由于目标应用在运行的过程中，保证主线程有足够的资源运行即极大可能保证目标应用整体运行的流畅不卡顿。当终端将异常资源调度事件对应的资源分配给目标应用后，目标应用可以将该资源分配给主线程，以保证目标应用运行时的流畅性。

综上所述，本实施例提供的资源调度方法，当终端中运行的目标应用发生卡顿事件时，终端获取资源调度数据，并根据资源调度数据，确定造成卡顿事件的异常资源调度事件，当异常资源调度事件是操作***调度造成的事件时，终端将异常资源调度事件对应的资源分配给目标应用。由于本申请能够在目标应用产生卡顿事件后，即刻获取资源调度数据并进行分析，当获知造成卡顿事件的异常资源调度事件后，终端能够当该事件是操作***调度造成的异常事件时，将异常资源调度事件对应的资源分配给目标应用，使得目标应用在卡顿事件发生后能够迅速确定造成卡顿的主要原因，并获取该原因侵占的资源，将该资源分配给目标应用，从源头上迅速解决了目标应用产生卡顿的问题，从而减少了目标应用的卡顿，提升了目标应用的平均帧率并提升了目标应用的帧率稳定性，进而提高了目标应用的运行效果。

基于上一个实施例所公开的方案，终端还能够根据造成卡顿事件的异常资源调度的具体类型的不同，进行相应的资源调度，详情请参考如下实施例。

请参见图3，图3是本申请另一个示例性实施例提供的另一种资源调度方法流程图。该资源调度方法可以应用在上述图1所示的终端中。在图3中，该资源调度方法包括：

步骤311，记录第一时刻和第二时刻，第一时刻是渲染完成第一图像帧的时刻，第二时刻是渲染完成第二图像帧的时刻，第一图像帧和第二图像帧是目标应用的显示图像帧队列中相邻的图像帧。

步骤312，获取目标渲染时长，目标渲染时长是第二时刻和第一时刻之间的时间段的时长。

步骤313，当目标渲染时长大于预设时长阈值时，确认目标应用发生卡顿事件并获取资源调度数据。

在本申请实施例中，终端能够通过较为精细的方式确定终端中是否产生了卡顿事件。作为一种可能的实施方式，终端能够记录第一时刻和第二时刻。需要说明的是，终端能够确定出目标应用中每一个图像帧的完成渲染的时刻。第一图像帧和第二图像帧是显示图像帧队列中相邻的图像帧。终端在显示图像时，将按照显示图像帧队列中的图像帧排列的顺序，显示各个图像帧。

例如，目标应用中连续渲染图像帧p1、图像帧p2和图像帧p3，则终端能够分别记录图像帧p1的完成渲染时刻、图像帧p2的完成渲染时刻和图像帧p3的完成渲染时刻，详情可以参见表一所示的示例。

表一

图像帧名称	图像帧p1	图像帧p2	图像帧p3
				完成渲染时刻	21时22分1.322秒	21时22分1.371秒	21时22分1.461秒

在表一所示的示例中，若完成渲染图像帧p1的时刻是第一时刻，完成渲染图像帧p2的时刻是第二时刻，则目标渲染时长是0.049秒(也即49毫秒)。若完成渲染图像帧p2的时刻是第一时刻，完成渲染图像帧p3的时刻是第二时刻，则目标渲染时长是0.09秒(也即90毫秒)。需要说明的是，第一时刻和第二时刻各自对应的图像帧需要是目标应用的显示图像帧队列中相邻的图像帧。若第一时刻对应的图像帧是p1，则要求第二时刻对应的图像帧是p2。

在本申请实施例中，还可以预置一个预设时长阈值，该预设时长阈值可以是一个常数值。例如，预设时长阈值可以是65毫秒、50毫秒或80毫秒等数值，本申请实施例对此不作限制。以预设时长阈值是65毫秒为例，若完成渲染图像帧p2的时刻是第一时刻，完成渲染图像帧p3的时刻是第二时刻，则终端确认目标应用发生卡顿事件且获取资源调度数据。

步骤321，将资源调度数据中的候选资源调度事件与异常调度模版相比对。

步骤322，当候选资源调度事件与异常调度模版匹配时，将候选资源调度事件确定为异常资源调度事件。

需要说明的是，当终端获取资源调度数据后，终端能够将资源调度数据中的候选资源调度事件与异常调度模版进行比对。若资源调度数据中包含目标应用的主线程A、资源回收线程B、渲染线程C1、渲染线程C2和突发线程D的资源调度数据，且每个线程包括运行时间事件、处理器占用频率事件和处理器占用时段事件共3个事件，则该资源调度数据中共包括15个候选资源调度事件。

以此为例进行说明，当上述15个候选资源调度事件中存在与异常调度模版匹配的事件时，终端将该匹配的候选资源调度事件确定为异常资源调度事件。

在本申请实施例中，异常调度模版包括低频异常模版、占核异常模版和应用逻辑异常模版。其中，异常调度模版，用于指示目标应用绑定的处理器核心在卡顿时段内的平均频率低于目标频率；占核异常模版，用于指示目标应用绑定的处理器核心被目标应用的突发线程抢占；应用逻辑异常模版，用于指示目标应用的主线程出现逻辑异常。

在本申请实施例中，终端能够根据候选资源调度事件具体的类型，执行相应的操作。可选地，终端可以执行步骤330、也可以执行步骤340或者还可以执行步骤351至步骤353，相关步骤的执行过程介绍如下：

步骤330，当异常资源调度事件是与低频异常模版相匹配的事件时，将目标应用绑定的处理器核心的频率拉升至最大频率。

需要说明的是，低频异常模版是目标应用绑定的处理器核心在卡顿时段内的平均频率低于目标频率的事件。其中，卡顿时段是发生卡顿事件时第一时刻与第二时刻之间的时段。目标频率可以是被目标应用绑定的处理器核心的最高频率，也可以接近该最高频率的一个频率，本申请实施例对此不作限定。在一个具体的示例中，若被目标应用绑定的处理器核心的最高频率是2.2GHz，则该目标频率可以是2GHz。

在本申请实施例中，当异常资源调度事件是与低频异常模版相匹配的事件时，终端能够将目标应用绑定的处理器核心的频率拉升至最大频率，也即，若目标应用绑定的处理器核心的最高频率是2.2GHz，则终端能够将该处理器核心的频率调整到2GHz。

请参考图4，图4是基于图3所示实施例提供的一种与低频异常模版相匹配的事件的资源调度数据示意图。在图4中，横轴410是时间轴，纵轴420是目标应用的主线程所绑定的处理器核心的频率。需要说明的是，该场景下，目标应用在卡顿时段(也即点4A至点4B的时段)中所绑定的处理器核心的频率不变，为1.8GHz。在时间轴410上，时段411表示目标应用的主线程处于运行的时段，时段412表示目标应用的主线程处于休眠的时段。

步骤340，当异常资源调度事件是与占核异常模版相匹配的事件时，将突发线程绑定到除目标应用所绑定处理器核心之外的处理器核心上。

需要说明的是，占核异常模版是用于指示目标应用绑定的处理器核心被目标应用的突发线程抢占。其中，突发线程是目标应用中除主线程之外的线程。

请参考图5，图5是基于图3所示实施例提供的一种与占核异常模版相匹配的事件的资源调度数据示意图。在图5中，横轴510是时间轴，纵轴520是目标应用的异常线程在卡顿时段(也即点4A至点4B的时段)中所运行的情况。其中，511时段表示该异常线程处于运行状态，512时段表示该异常线程处于待执行状态。由于该异常线程在目标线程中所有线程中，在卡顿时段中运行时长最长。因此，将该异常线程确定为本申请实施例中的突发线程。

由图5所示的内容可知，异常线程在卡顿时段中持续运行并抢占目标应用所绑定的处理器核心，导致了卡顿。可选地，在一种可能的实施方式中，终端可以将卡顿时段中除主线程外运行时间最长的线程确定为异常线程。

需要说明的是，在另一种可能的实现方式中，目标应用绑定的处理器核心是目标应用的主线程绑定的处理器核心。终端还能够在该处理器核心被抢占线程申请占用时，通过抢占线程的标识判断如何处理抢占线程的申请。由于操作***无法获知应用程序中的全部线程的功能，因此，操作***可以在目标应用的运行过程中持续维护一个黑名单，用于存储造成卡顿的抢占线程的标识。当抢占线程的标识处于黑名单时，操作***将抢占线程分配至终端的其它处理器核心上处理。当该抢占线程的标识不处于黑名单时，终端能够为抢占线程分配被限制时长的目标工作时段。其中，该目标工作时段的时长小于目标渲染时长。

例如，当目标应用是游戏应用时，该游戏应用的主线程绑定在2.4GHz频率的处理器核心上。当有游戏应用中的抢占线程L抢占该处理器核心时，操作***获取处理器核心L的标识，检查该抢占线程L是否在黑名单中。当抢占线程L在黑名单中时，操作***禁止该抢占线程L占用2.4GHz的线程，并将该抢占线程L绑定在1.8GHz或处理能力降低的其它处理器核心上。当抢占线程L不在黑名单中时，操作***为该抢占线程L分配目标工作时段。需要说明的是，该目标工作时段的时长小于目标渲染时长。若目标渲染时长是30毫秒，则操作***为抢占线程L分配的目标工作时段的时长将小于30毫秒。由于抢占线程使用游戏应用的主线程所绑定的处理器核心的时长被限制，因此，本申请能够在出现抢占线程抢占主线程所绑定的处理器核心时，通过限制抢占核心的使用时长，来达到初步的防止卡顿的目的，同时也能够保障抢占线程的运行，综合提高了目标应用的运行效率。

步骤351，当异常资源调度事件是与应用逻辑异常模版相匹配的事件时，将资源调度数据和异常资源调度事件发送至厂商服务器，厂商服务器是目标应用的开发方提供的服务器。

步骤352，接收厂商服务器反馈的逻辑更新资源包。

步骤353，根据逻辑更新资源包更新目标应用。

需要说明的是，终端能够在异常资源调度事件是与应用逻辑异常模版相匹配的事件时，将资源调度数据和异常资源调度事件发送至厂商服务器。在一种可能的情况中，该异常资源调度事件可以包括主线程死锁、休眠(英文：sleep)异常或主线程执行时间过长等问题。

在异常资源调度事件是与应用逻辑异常模版相匹配的事件时，造成目标应用卡顿的原因是其本身逻辑出错。因此，本申请在发现该问题时，将即时向厂商服务器发送资源调度市局和异常资源调度事件，以令厂商服务器查找对应的逻辑更新资源包。之后，终端接收厂商服务器反馈的逻辑更新资源包。

在一种可能的方式中，终端能够在目标应用运行的过程中，直接加载逻辑更新资源包，以实现不干扰用户使用目标应用的无感升级。在该升级方式中，目标应用可以是基于electron技术开发的客户端。

在另一种可能的方式中，终端能够在目标应用本次运行被确认退出时，先进行加载逻辑更新资源包，以完成更新。基于该更新方式，使得目标应用能够在后续运行过程中克服目标应用本身的逻辑错误，提升目标应用的流畅度并在下一次启动时迅速启动。

请参考图6，图6是基于图3所示实施例提供的一种与应用逻辑异常模版相匹配的事件的资源调度数据示意图。在图6中，横轴610是时间轴，卡顿时段的长度为63.808毫秒(时刻611至时刻613之间的时间段)，时刻611为主线程完成渲染第一图像帧的时刻，时刻612为主线程完成渲染第二图像帧的时刻，时刻613为主线程完成渲染第三图像帧的时刻。时刻621为请求渲染第二图像帧的时刻，时刻622为请求渲染第三图像帧的时刻。

基于图6所示的场景，目标线程在卡顿时段中的累积运行的时间段611大于允许逻辑运行时长阈值，因此，终端将异常资源调度事件确定为与应用逻辑异常模版相匹配的事件。

综上所述，本实施例提供的资源调度方法，能够根据记录完成渲染第一图像帧的第一时刻，以及完成渲染第二图像帧的第二时刻，通过计算第二时刻与第一时刻之间的时间段的时长，获取目标渲染时长，在该目标渲染时长大于预设时长阈值时，确认目标应用发生卡顿事件并获取资源调度数据，实现了终端检测卡顿的灵敏性，提高了终端在用户可感的卡顿发生前重新进行资源调度的能力。

本实施例提供的资源调度方法，还能够将资源调度数据中的候选资源调度事件与异常调度模版相对比，当候选资源调度事件与异常调度模版相匹配时，将候选资源调度事件确定为异常资源调度事件，从而加快了确定卡顿原因的速度，提高了终端解决卡顿的速度。

本实施例提供的资源调度方法，还能够在卡顿事件是由操作***调度造成的异常事件造成时，详细判别是目标应用绑定的处理器核心的频率不足还是有突发线程抢占了目标应用绑定的处理器核心。在目标应用绑定的处理器核心的频率不足时，拉升目标应用绑定的处理器核心的频率。在突发线程抢占了目标应用绑定的处理器核心时，将该突发线程绑定到除目标应用绑定的处理器核心之外的处理器核心上处理，从而有针对性地提高了终端解决卡顿的速度。

下述为本申请装置实施例，可以用于执行本申请方法实施例。对于本申请装置实施例中未披露的细节，请参照本申请方法实施例。

请参考图7，图7是本申请一个示例性实施例提供的一种资源调度装置的结构框图。该资源调度装置可以通过软件、硬件或者两者的结合实现成为终端的全部或一部分。该装置包括：

数据获取模块710，用于当目标应用发生卡顿事件时，获取资源调度数据，所述资源调度数据是所述目标应用在目标时段内调用资源的数据，所述目标时段是所述卡顿事件发生时前的指定时长的时段；

异常确定模块720，用于根据所述资源调度数据，确定造成所述卡顿事件的异常资源调度事件；

资源分配模块730，用于当所述异常资源调度事件属于***调度异常事件时，将所述异常资源调度事件对应的资源分配给所述目标应用。

在一个可选的实施例中，所述数据获取模块710，用于记录第一时刻和第二时刻，所述第一时刻是渲染完成第一图像帧的时刻，所述第二时刻是渲染完成第二图像帧的时刻，所述第一图像帧和所述第二图像帧是所述目标应用的显示图像帧队列中相邻的图像帧；获取目标渲染时长，所述目标渲染时长是所述第二时刻和所述第一时刻之间的时间段的时长；当所述目标渲染时长大于预设时长阈值时，确认所述目标应用发生所述卡顿事件并获取资源调度数据。

在一个可选的实施例中，所述异常确定模块720，用于将所述资源调度数据中的候选资源调度事件与异常调度模版相比对；当所述候选资源调度事件与所述异常调度模版匹配时，将所述候选资源调度事件确定为所述异常资源调度事件。

在一个可选的实施例中，所述装置涉及的所述异常调度模版包括低频异常模版、占核异常模版和应用逻辑异常模版，其中，所述异常调度模版，用于指示所述目标应用绑定的处理器核心在卡顿时段内的平均频率低于目标频率；所述占核异常模版，用于指示所述目标应用绑定的处理器核心被所述目标应用的突发线程抢占；应用逻辑异常模版，用于指示所述目标应用的主线程出现逻辑异常。

在一个可选的实施例中，所述异常确定模块720，用于当所述异常资源调度事件是与所述低频异常模版相匹配的事件时，将所述目标应用绑定的处理器核心的频率拉升至最大频率；和/或，当所述异常资源调度事件是与所述占核异常模版相匹配的事件时，将所述突发线程绑定到除所述目标应用所绑定处理器核心之外的处理器核心上。

在一个可选的实施例中，所述装置涉及的所述目标应用绑定的处理器核心为所述目标应用的主线程绑定的处理器核心，所述装置还包括标识获取模块、核心分配模块和时段分配模块，所述标识获取模块，用于当所述目标应用的主线程绑定的处理器核心被抢占线程申请占用时，获取所述抢占线程的标识；所述核心分配模块，用于当所述抢占线程的标识处于黑名单时，将所述抢占线程分配至终端的其它处理器核心上处理；所述时段分配模块，用于当所述抢占线程的标识不处于黑名单时，为所述抢占线程分配在所述目标应用的主线程绑定的处理器核心上的目标工作时段，所述目标工作时段的时长小于所述目标渲染时长。

在一个可选的实施例中，所述装置还包括数据发送模块、更新包接收模块和应用更新模块，所述数据发送模块，用于当所述异常资源调度事件是与所述应用逻辑异常模版相匹配的事件时，将所述资源调度数据和所述异常资源调度事件发送至厂商服务器，所述厂商服务器是所述目标应用的开发方提供的服务器；所述更新包接收模块，用于接收所述厂商服务器反馈的逻辑更新资源包；所述应用更新模块，用于根据所述逻辑更新资源包更新所述目标应用。

综上所述，本实施例提供的资源调度装置，能够根据记录完成渲染第一图像帧的第一时刻，以及完成渲染第二图像帧的第二时刻，通过计算第二时刻与第一时刻之间的时间段的时长，获取目标渲染时长，在该目标渲染时长大于预设时长阈值时，确认目标应用发生卡顿事件并获取资源调度数据，实现了终端检测卡顿的灵敏性，提高了终端在用户可感的卡顿发生前重新进行资源调度的能力。

本实施例提供的资源调度装置，还能够将资源调度数据中的候选资源调度事件与异常调度模版相对比，当候选资源调度事件与异常调度模版相匹配时，将候选资源调度事件确定为异常资源调度事件，从而加快了确定卡顿原因的速度，提高了终端解决卡顿的速度。

本实施例提供的资源调度装置，还能够在卡顿事件是由操作***调度造成的异常事件造成时，详细判别是目标应用绑定的处理器核心的频率不足还是有突发线程抢占了目标应用绑定的处理器核心。在目标应用绑定的处理器核心的频率不足时，拉升目标应用绑定的处理器核心的频率。在突发线程抢占了目标应用绑定的处理器核心时，将该突发线程绑定到除目标应用绑定的处理器核心之外的处理器核心上处理，从而有针对性地提高了终端解决卡顿的速度。

本申请实施例还提供了一种计算机可读介质，该计算机可读介质存储有至少一条指令，所述至少一条指令由所述处理器加载并执行以实现如上各个实施例所述的资源调度方法。

需要说明的是：上述实施例提供的资源调度装置在执行资源调度方法时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的资源调度装置与资源调度方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

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

Claims (10)

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

当目标应用发生卡顿事件时，获取资源调度数据，所述资源调度数据是所述目标应用在目标时段内调用资源的数据，所述目标时段是所述卡顿事件发生时前的指定时长的时段；

根据所述资源调度数据，确定造成所述卡顿事件的异常资源调度事件；

当所述异常资源调度事件是操作***调度造成的异常事件时，将所述异常资源调度事件对应的资源分配给所述目标应用。

2.根据权利要求1所述的方法，其特征在于，所述当目标应用发生卡顿事件时，获取资源调度数据，包括：

记录第一时刻和第二时刻，所述第一时刻是渲染完成第一图像帧的时刻，所述第二时刻是渲染完成第二图像帧的时刻，所述第一图像帧和所述第二图像帧是所述目标应用的显示图像帧队列中相邻的图像帧；

获取目标渲染时长，所述目标渲染时长是所述第二时刻和所述第一时刻之间的时间段的时长；

当所述目标渲染时长大于预设时长阈值时，确认所述目标应用发生所述卡顿事件并获取资源调度数据。

3.根据权利要求2所述的方法，其特征在于，所述根据所述资源调度数据，确定造成所述卡顿事件的异常资源调度事件，包括：

将所述资源调度数据中的候选资源调度事件与异常调度模版相比对；

当所述候选资源调度事件与所述异常调度模版匹配时，将所述候选资源调度事件确定为所述异常资源调度事件。

4.根据权利要求3所述的方法，其特征在于，所述异常调度模版包括低频异常模版、占核异常模版和应用逻辑异常模版，

其中，所述异常调度模版，用于指示所述目标应用绑定的处理器核心在卡顿时段内的平均频率低于目标频率；所述占核异常模版，用于指示所述目标应用绑定的处理器核心被所述目标应用的突发线程抢占；应用逻辑异常模版，用于指示所述目标应用的主线程出现逻辑异常。

5.根据权利要求4所述的方法，其特征在于，所述当所述异常资源调度事件是操作***调度造成的异常事件时，将所述异常资源调度事件对应的资源分配给所述目标应用，包括：

当所述异常资源调度事件是与所述低频异常模版相匹配的事件时，将所述目标应用绑定的处理器核心的频率拉升至最大频率；

和/或，

当所述异常资源调度事件是与所述占核异常模版相匹配的事件时，将所述突发线程绑定到除所述目标应用所绑定处理器核心之外的处理器核心上。

6.根据权利要求4所述的方法，其特征在于，所述目标应用绑定的处理器核心为所述目标应用的主线程绑定的处理器核心，所述方法还包括：

当所述目标应用的主线程绑定的处理器核心被抢占线程申请占用时，获取所述抢占线程的标识；

当所述抢占线程的标识处于黑名单时，将所述抢占线程分配至终端的其它处理器核心上处理；

当所述抢占线程的标识不处于黑名单时，为所述抢占线程分配在所述目标应用的主线程绑定的处理器核心上的目标工作时段，所述目标工作时段的时长小于所述目标渲染时长。

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

当所述异常资源调度事件是与所述应用逻辑异常模版相匹配的事件时，将所述资源调度数据和所述异常资源调度事件发送至厂商服务器，所述厂商服务器是所述目标应用的开发方提供的服务器；

接收所述厂商服务器反馈的逻辑更新资源包；

根据所述逻辑更新资源包更新所述目标应用。

8.一种资源调度装置，其特征在于，所述装置包括：

数据获取模块，用于当目标应用发生卡顿事件时，获取资源调度数据，所述资源调度数据是所述目标应用在目标时段内调用资源的数据，所述目标时段是所述卡顿事件发生时前的指定时长的时段；

异常确定模块，用于根据所述资源调度数据，确定造成所述卡顿事件的异常资源调度事件；

资源分配模块，用于当所述异常资源调度事件属于***调度异常事件时，将所述异常资源调度事件对应的资源分配给所述目标应用。

9.一种终端，其特征在于，所述终端包括处理器、和与所述处理器相连的存储器，以及存储在所述存储器上的程序指令，所述处理器执行所述程序指令时实现如权利要求1至7任一所述的资源调度方法。

10.一种计算机可读存储介质，所述存储介质中存储有程序指令，其特征在于，所述程序指令被处理器执行时实现如权利要求1至7任一所述的资源调度方法。

Images