CN117695626A - 游戏数据的识别方法、设备及存储介质 - Google Patents

Abstract

本申请提供了一种游戏数据的识别方法、设备及存储介质。该方法通过为每一个游戏应用创建独立的游戏感知线程，从而在多游戏场景下，也可以利用每一个游戏应用对应的游戏感知线程进行对应游戏数据的识别收集，进而保证了针对每一个游戏应用进行的资源调度的合理性。

Description

游戏数据的识别方法、设备及存储介质

技术领域

本申请涉及终端技术领域，尤其涉及一种游戏数据的识别方法、设备及存储介质。

背景技术

随着电子设备的功能越来越强大，电子设备中可安装的应用越来越多。以游戏应用为例，随着游戏画质的提升，游戏玩法、游戏场景的丰富，为了给用户带来更好的体验，就需要合理对电子设备的资源进行调度。

但是，游戏场景下，对资源的调度需要依赖较多的信息，如当前应用是否为游戏应用、游戏运行场景、游戏渲染线程、游戏主渲染线程等。

因此，如何精准地识别并获取到与游戏应用相关的游戏数据尤为重要。

发明内容

为了解决上述技术问题，本申请提供一种游戏数据的识别方法、设备及存储介质，旨在精准地识别并获取到与游戏应用相关的游戏数据，从而使得电子设备能够根据游戏数据进行合理的资源调度，保证游戏应用的体验效果。

第一方面，本申请提供一种游戏数据的识别方法，应用于电子设备。该方法包括：在接收到电子设备中安装的任一应用触发的绘制渲染请求时，确定触发绘制渲染请求的应用中是否存在游戏应用；在存在游戏应用时，为每一个游戏应用创建对应的游戏感知线程；基于每一个游戏应用对应的游戏感知线程，获取绘制渲染每一个游戏应用的图层所需的绘制调用信息，以及绘制渲染过程中记录的区域信息和电子设备的系统信息；根据每一个游戏应用对应的绘制调用信息、区域信息和系统信息，识别每一个游戏应用的游戏数据。

由此，通过为每一个游戏应用创建独立的游戏感知线程，从而在多游戏场景下，也可以利用每一个游戏应用对应的游戏感知线程进行对应游戏数据的识别收集，进而保证了针对每一个游戏应用进行的资源调度的合理性。

根据第一方面，在接收到电子设备中安装的任一应用触发的绘制渲染请求时，确定触发绘制渲染请求的应用中是否存在游戏应用，包括：在接收到电子设备中安装的任一应用对图形渲染库的加载时，确定触发绘制渲染请求的应用中是否存在游戏应用。

示例性的，在一种可能的实现方式中，可以在确定接收到电子设备中安装的任一应用对图形渲染库的加载时，确定触发了绘制渲染请求。

其中，图形渲染库，例如为libEGL、libGL ES、libvulkan等。

相应地，在接收到任一应用对图形渲染库的加载时，便可以执行确定该应用是否为游戏应用的操作，进而在确定该应用为游戏应用时，为其创建独立的游戏感知线程，以便对该游戏应用的游戏数据进行识别收集。

根据第一方面，或者以上第一方面的任意一种实现方式，在接收到电子设备中安装的任一应用触发的绘制渲染请求时，方法还包括：初始化图形渲染库对应的图形渲染驱动；获取每一应用的应用包名；获取绘制渲染每一个游戏应用的图层所需的绘制调用信息；获取绘制渲染过程中记录的区域信息。

其中，为了实现功能模块化，以便后续维护，图形渲染库中可以单独封装实现初始化图形渲染库对应的图形渲染驱动的初始化模块。

相应地，为了能够在当前应用为游戏应用时，及时创建游戏感知线程，初始化模块可以在初始化图形渲染驱动的过程中，获取当前加载图形渲染库的每一个应用的应用包名，并将获取到的应用包名发送给与图形渲染库处于相同级别的游戏感知模块。

示例性的，图形渲染库中也可以单独封装实现获取绘制渲染每一个游戏应用的图层所需的绘制调用(DrawCall)信息的绘制调用模块。

关于绘制调用模块获取到的绘制调用信息，可以传递至游戏感知模块进行后续处理，如确认当前的线程是渲染线程，还是用户界面线程。

示例性的，图形渲染库中也可以单独封装获取绘制渲染过程中记录的区域信息的区域(area)获取模块。

关于区域模块获取的区域信息，可以由区域获取模块传递至图像合成模块(SurfaceFlinger，即SF线程)进行记录。

根据第一方面，或者以上第一方面的任意一种实现方式，获取绘制渲染过程中记录的区域信息，包括：在图形渲染库使用第一图形程序接口时，获取当前视图元素的宽度和高度；根据宽度和高度，确定当前绘制渲染的面积大小；将宽度、高度和面积大小，作为区域信息。

其中，第一图形程序接口，例如libGL ES/OpenGL ES。

其中，视图元素，即Surface。

根据第一方面，或者以上第一方面的任意一种实现方式，获取绘制渲染过程中记录的区域信息，包括：在图像渲染库使用第二图形程序接口时，获取创建交换链时记录的宽度和高度；根据宽度和高度，确定当前绘制渲染的面积大小；将宽度、高度和面积大小，作为区域信息。

其中，第二图形程序接口，例如Vulkan/libvulkan。

其中，交换链，即Swapchain。

根据第一方面，或者以上第一方面的任意一种实现方式，确定触发绘制渲染请求的应用中是否存在游戏应用，包括：根据每一应用的应用包名，查询是否存在匹配的预设游戏应用包名；在存在匹配的预设游戏应用包名时，确定触发绘制渲染请求的应用中存在游戏应用。

其中，预设游戏应用包名可以预先存储在游戏控制模块对应的内存中。

示例性的，对于当前应用是否为游戏应用的识别确定，例如可以是通过游戏感知模块中封装的用于实现游戏应用识别的游戏感知子模块在接收到初始化模块传输的应用包名后，根据应用包名查询游戏控制模块对应的内存中存储的预设游戏应用包名实现的。

根据第一方面，或者以上第一方面的任意一种实现方式，在接收到电子设备中安装的任一应用触发的绘制渲染请求时，方法还包括：绘制触发绘制渲染请求的应用对应的图层，并获取系统信息；将系统信息传递至图像合成模块；将绘制好的图层传递至图像合成模块。

可理解地，目前图层的绘制可以由应用层直接触发图形用户界面库进行绘制。故而，在接收到电子设备中安装的任一应用触发的绘制渲染请求时，图形用户界面库可以实现图层的绘制，并在绘制过程中获取系统信息，进而将系统信息和绘制好的图层传递至图像合成模块处理。

其中，系统信息，例如可以包括电子设备当前的屏幕状态信息，如亮屏或灭屏，还可以包括焦点信息。

根据第一方面，或者以上第一方面的任意一种实现方式，游戏数据包括游戏应用当前的游戏运行场景变换信息；根据每一个游戏应用对应的绘制调用信息、区域信息和系统信息，识别每一个游戏应用的游戏数据，包括：对于每一个游戏应用，根据游戏应用的区域信息和系统信息，确定游戏应用当前的游戏运行场景；在游戏应用当前的游戏运行场景发生变换时，得到游戏运行场景变换信息。

示例性的，为了实现功能模块化，以便后续维护，游戏感知模块可以根据需要识别的游戏数据，封装多个功能子模块。如封装用于识别游戏运行场景变换信息的游戏运行场景感知子模块。

即，在一种可能的实现方式中，本方面的操作可以由游戏感知子模块实现。

其中，游戏运行场景变换信息，例如可以包括进入游戏运行场景(GameIn)，或退出游戏运行场景(GameOut)。

根据第一方面，或者以上第一方面的任意一种实现方式，游戏数据包括当前的线程信息；根据每一个游戏应用对应的绘制调用信息、区域信息和系统信息，识别每一个游戏应用的游戏数据，包括：对于每一个游戏应用，根据游戏应用对应的绘制调度信息，确定当前的线程信息；其中，线程信息包括渲染线程的信息或用户界面线程(User InterfaceThread，UI线程)的信息。

示例性的，为了实现功能模块化，以便后续维护，游戏感知模块可以根据需要识别的游戏数据，封装多个功能子模块。如封装用于识别当前线程是否为渲染线程的渲染线程感知子模块。

即，在一种可能的实现方式中，本方面的操作可以由渲染线程感知子模块实现。

根据第一方面，或者以上第一方面的任意一种实现方式，对于每一个游戏应用，游戏感知模块根据游戏应用对应的绘制调度信息，确定当前的线程信息，包括：对于每一个游戏应用，识别读取游戏应用对应的绘制调度信息的方法函数；在方法函数为第一方法函数时，确定当前的线程为用户界面线程，当前的线程信息为用户界面线程的信息；在方法函数为第二方法函数时，确定当前的线程为渲染线程，当前的线程信息为渲染线程的信息。

其中，第一方法函数，例如为专门供UI线程调用，读取DrawCall的eglSwapBuffersWithDamageKHR函数。

其中，第二方法函数，例如为专门供渲染线程调用读取DrawCall的eglswapbuffer函数。

由此，通过确定读取DrawCall的方法函数是哪一种，从而可以快速、准确地确定当前的线程是UI线程，还是渲染线程，进而得到精准地线程信息。

根据第一方面，或者以上第一方面的任意一种实现方式，对于每一个游戏应用，游戏感知模块根据游戏应用对应的绘制调度信息，确定当前的线程信息，包括：对于每一个游戏应用，根据顶点坐标获取函数获取当前的线程根据绘制调用信息绘制的图层的顶点坐标；在顶点坐标为二维坐标时，确定当前的线程为用户界面线程，当前的线程信息为用户界面线程的信息；在顶点坐标为三维坐标时，确定当前的线程为渲染线程，当前的线程信息为渲染线程的信息。

其中，顶点坐标获取函数，例如为Hook glVertexAttribPointer函数。

通过Hook glVertexAttribPointer函数获取当前线程传递的坐标顶点，从而根据坐标顶点的维度便可以快速、准确地确定当前的线程是UI线程，还是渲染线程，进而得到精准地线程信息。

根据第一方面，或者以上第一方面的任意一种实现方式，在游戏数据包括多个渲染线程的信息时，游戏数据还包括主渲染信息；确定主渲染信息，包括：确定每一个渲染线程在设定时间窗口内的绘制调用请求次数；将绘制调用请求次数最大的渲染线程确定为主渲染线程。

其中，设定时间窗口，可以根据业务需求设置时间，例如10s。

其中，绘制调用请求次数，即CPU写入命令缓冲区的DrawCall的次数。

由于渲染线程要处理的绘制调用请求次数越多，该渲染线程的活跃度越高，通常可以认为是主渲染线程。因此，在多渲染线程作业的场景下，通过确定每一个渲染线程对应的绘制调用请求次数，进而从选择绘制调用请求次数最大的渲染线程作为主渲染线程即可。

根据第一方面，或者以上第一方面的任意一种实现方式，在识别每一个游戏应用的游戏数据之后，方法还包括：根据每一个游戏应用的游戏数据，进行资源调度。

其中，游戏感知模块中各子功能模块识别出的游戏数据，可以经游戏控制模块转发至专门用于进行资源调度的调度服务，进而使得调度服务能够根据每一个游戏应用的游戏数据，进而合理的资源调度。

第二方面，本申请提供了一种电子设备。该电子设备包括：存储器和处理器，存储器和处理器耦合；存储器存储有程序指令，程序指令由处理器执行时，使得所述电子设备执行第一方面或第一方面的任意可能的实现方式中的方法的指令。

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

第三方面，本申请提供了一种电子设备。该电子设备的应用程序层安装了应用，应用包括游戏应用；该电子设备的本地服务和系统库层(Native层)包括图形渲染库、图形用户界面库、图像合成模块、游戏感知模块、游戏控制模块和调度服务。该电子设备包括：存储器和处理器，存储器和处理器耦合；存储器存储有程序指令，程序指令由处理器执行时，使得该电子设备执行如下步骤：

图形渲染库接收到电子设备中应用程序层安装的任一应用的加载时，确定接收到该应用的触发的绘制渲染请求；

图像渲染库中的初始化模块初始化图形渲染库对应的图形渲染驱动，并获取每一应用的应用包名，将应用包名传递至游戏感知模块中的游戏感知子模块；

游戏感知子模块根据每一应用的应用包名，查询游戏控制模块对应的内存中是否存在匹配的预设游戏应用包名；

在存在匹配的预设游戏应用包名时，确定触发绘制渲染请求的应用中存在游戏应用；

在存在游戏应用时，游戏感知子模块为每一个游戏应用创建对应的游戏感知线程；

基于每一个游戏应用对应的游戏感知线程，获取绘制渲染每一个游戏应用的图层所需的绘制调用信息，以及绘制渲染过程中记录的区域信息和该电子设备的系统信息；

游戏感知模块中的各种子功能模块，根据每一个游戏应用对应的绘制调用信息、区域信息和系统信息，识别每一个游戏应用的游戏数据。

根据第三方面，程序指令由处理器执行时，使得该电子设备还执行如下步骤：

游戏感知模块中的各种子功能模块，将识别出的游戏数据传递至游戏控制模块；

游戏控制模块将游戏数据转发至调度服务；

调度服务根据游戏数据进行资源调度。

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

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

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

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

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

第六方面，本申请提供了一种芯片，该芯片包括一个或多个接口电路和一个或多个处理器。其中，接口电路用于从电子设备的存储器接收信号，并向处理器发送该信号，该信号包括存储器中存储的计算机指令，该处理器执行计算机指令时，使得电子设备执行第一方面或第一方面的任一种可能的实现方式中的方法。

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

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

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

附图说明

图1为示例性示出的电子设备的硬件结构示意图；

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

图3A为示例性示出的游戏感知模块的内部功能模块的示意图；

图3B为示例性示出的游戏控制模块的内部功能模块的示意图；

图4为示例性示出的本申请实施例提供的一种游戏数据的识别方法的时序示意图；

图5为示例性示出的CPU和GPU进行DrawCall信息交互的示意图；

图6A为示例性示出的一种识别UI线程和渲染线程的示意图；

图6B为示例性示出的又一种识别UI线程和渲染线程的示意图；

图7为示例性示出的识别主渲染线程的示意图；

图8为示例性示出的装置的结构示意图。

具体实施方式

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

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

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

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

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

随着游戏画质的提升，游戏玩法、游戏场景的丰富，为了给用户带来更好的体验，就需要合理对电子设备的资源进行调度。然而，资源的调度，需要依赖很多信息，例如当前应用是否为游戏应用、游戏运行场景、游戏渲染线程、游戏主渲染线程等才可以完成。但是这些信息的识别与获取是一个难点。

因此，如何精准地识别并获取到与游戏应用相关的游戏数据尤为重要。

目前，在一些可能的实现方式中，会通过对图形用户界面库绘制的每一个图层进行识别。

例如，识别绘制的图层属于哪一应用线程等，进而通过确定该应用线程是否为预设的游戏应用线程的方式来确定当前应用是否为游戏应用。

还例如，识别绘制的图层的帧率、刷新频率等，确定是否为预设游戏应用要求的帧率、刷新频率。

但是，目前这种识别方式，在图形用户界面库同时绘制多个应用进程对应的图层时，将无法精准地识别出当前进行图层绘制渲染的渲染进程为主绘制渲染进程。

有鉴于此，本申请实施例提供了一种游戏数据的识别方法，旨在精准地识别并获取到与游戏应用相关的游戏数据，从而使得电子设备能够根据游戏数据进行合理的资源调度，保证游戏应用的体验效果。

为了更好地理解本申请实施例提供的技术方案，在对本申请实施例的技术方案说明之前，首先结合附图对本申请实施例适用于的电子设备(例如手机、平板电脑、可触控PC机等)的硬件结构进行说明。

参见图1，电子设备100可以包括：处理器110，外部存储器接口120，内部存储器121，通用串行总线(universal serial bus，USB)接口130，充电管理模块140，电源管理模块141，电池142，天线1，天线2，移动通信模块150，无线通信模块160，音频模块170，传感器模块180，按键190，马达191，指示器192，摄像头193，显示屏194，以及用户标识模块(subscriber identification module，SIM)卡接口195等。

其中，处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器(application processor，AP)，调制解调处理器(Modem)，图形处理器(graphicsprocessing unit，GPU)，图像信号处理器(image signal processor，ISP)，控制器，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器(neural-network processing unit，NPU)等，此处不再一一列举，本申请对此不作限制。

关于上述所说的作为处理单元的控制器，可以是电子设备100的神经中枢和指挥中心。在实际应用中，控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。

关于上述说的调制解调处理器，可以包括调制器和解调器。其中，调制器用于将待发送的低频基带信号调制成中高频信号。解调器用于将接收的电磁波信号解调为低频基带信号，以及将解调得到的低频基带信号传送至基带处理器处理。

关于上述所说的基带处理器，用于对调节器传输的低频基带信号进行处理，并将处理后的低频基带信号传递给应用处理器。

需要说明的，在一些实现方式中，基带处理器可以集成在调制解调器内，即调制解调器可以具备基带处理器的功能。

关于上述所说的应用处理器，用于通过音频设备(不限于扬声器170A，受话器170B等)输出声音信号，或通过显示屏194显示图像或视频。

关于上述所说的数字信号处理器，用于处理数字信号。具体地，数字信号处理器除了可以处理数字图像信号，还可以处理其他数字信号。例如，当电子设备100在频点选择时，数字信号处理器可用于对频点能量进行傅里叶变换等。

关于上述所说的视频编解码器，用于对数字视频压缩或解压缩。示例性的，电子设备100可以支持一种或多种视频编解码器。这样，电子设备100可以播放或录制多种编码格式的视频，例如：动态图像专家组(moving picture experts group，MPEG)1，MPEG2，MPEG3，MPEG4等。

关于上述所说的ISP，用于将数字图像信号输出到DSP加工处理。具体地，ISP用于处理摄像头193反馈的数据。例如，拍照、录像时，打开快门，光线通过镜头被传递到摄像头感光元件上，光信号转换为电信号，摄像头感光元件将所述电信号传递给ISP处理，转化为肉眼可见的图像。ISP还可以对图像的噪点，亮度，肤色进行算法优化。ISP还可以对拍摄场景的曝光，色温等参数优化。在一些实现方式中，ISP可以设置在摄像头193中。

关于上述所说的DSP，用于将数字图像信号转换成标准的RGB，YUV等格式的图像信号。

此外，还需要说明的，关于包括上述处理单元的处理器110，在一些实现方式中，不同的处理单元可以是独立的器件。即，每一个处理单元都可以看作为一个处理器。在另一些实现方式中，不同的处理单元也可以集成在一个或多个处理器中。例如，在一些实现方式中，调制解调处理器可以是独立的器件。在另一些实现方式中，调制解调处理器可以独立于处理器110，与移动通信模块150或其他功能模块设置在同一个器件中。

应当理解地是，上述说明仅是为了更好地理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

此外，在一些实现方式中，处理器110还可以包括一个或多个接口。其中，接口可以包括集成电路(inter-integrated circuit，I2C)接口，集成电路内置音频(inter-integrated circuit sound，I2S)接口，脉冲编码调制(pulse code modulation，PCM)接口，通用异步收发传输器(universal asynchronous receiver/transmitter，UART)接口，移动产业处理器接口(mobile industry processor interface，MIPI)，通用输入输出(general-purpose input/output，GPIO)接口，用户标识模块(subscriber identitymodule，SIM)接口，和/或通用串行总线(universal serial bus，USB)接口等，此处不再一一列举，本申请对此不作限制。

此外，处理器110中还可以设置存储器，用于存储指令和数据。在一些实现方式中，处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110刚用过或循环使用的指令或数据。如果处理器110需要再次使用该指令或数据，可从所述存储器中直接调用。避免了重复存取，减少了处理器110的等待时间，因而提高了系统的效率。

继续参见图1，外部存储器接口120可以用于连接外部存储卡，例如Micro SD卡，实现扩展电子设备100的存储能力。外部存储卡通过外部存储器接口120与处理器110通信，实现数据存储功能。例如将音乐，视频等文件保存在外部存储卡中。

继续参见图1，内部存储器121可以用于存储计算机可执行程序代码，所述可执行程序代码包括指令。处理器110通过运行存储在内部存储器121的指令，从而执行电子设备100的各种功能应用以及数据处理。内部存储器121可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统，至少一个功能所需的应用程序(比如声音播放功能，图像播放功能，以及本申请实施例中所说的立体声录制功能等)等。存储数据区可存储电子设备100使用过程中所创建的数据(比如基于本申请实施例提供的技术方案录制的立体声的音频数据)等。此外，内部存储器121可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件，闪存器件，通用闪存存储器(universal flash storage，UFS)等。

继续参见图1，充电管理模块140用于从充电器接收充电输入。其中，充电器可以是无线充电器，也可以是有线充电器。在一些有线充电的实现方式中，充电管理模块140可以通过USB接口130接收有线充电器的充电输入。在一些无线充电的实现方式中，充电管理模块140可以通过电子设备100的无线充电线圈接收无线充电输入。充电管理模块140为电池142充电的同时，还可以通过电源管理模块141为电子设备供电。

继续参见图1，电源管理模块141用于连接电池142，充电管理模块140与处理器110。电源管理模块141接收电池142和/或充电管理模块140的输入，为处理器110，内部存储器121，外部存储器，显示屏194，摄像头193，和无线通信模块160等供电。电源管理模块141还可以用于监测电池容量，电池循环次数，电池健康状态(漏电，阻抗)等参数。在其他一些实现方式中，电源管理模块141也可以设置于处理器110中。在另一些实现方式中，电源管理模块141和充电管理模块140也可以设置于同一个器件中。

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

需要说明的，天线1和天线2用于发射和接收电磁波信号。电子设备100中的每个天线可用于覆盖单个或多个通信频带。不同的天线还可以复用，以提高天线的利用率。例如：可以将天线1复用为无线局域网的分集天线。在另外一些实现方式中，天线可以和调谐开关结合使用。

继续参见图1，移动通信模块150可以提供应用在电子设备100上的包括2G/3G/4G/5G等无线通信的解决方案。移动通信模块150可以包括至少一个滤波器，开关，功率放大器，低噪声放大器(low noise amplifier，LNA)等。移动通信模块150可以由天线1接收电磁波，并对接收的电磁波进行滤波，放大等处理，传送至调制解调处理器进行解调。移动通信模块150还可以对经调制解调处理器调制后的信号放大，经天线1转为电磁波辐射出去。在一些实现方式中，移动通信模块150的至少部分功能模块可以被设置于处理器110中。在一些实现方式中，移动通信模块150的至少部分功能模块可以与处理器110的至少部分模块被设置在同一个器件中。

继续参见图1，无线通信模块160可以提供应用在电子设备100上的包括无线局域网(wireless local area networks，WLAN)(如无线保真(wireless fidelity，Wi-Fi)网络)，蓝牙(bluetooth，BT)，全球导航卫星系统(global navigation satellite system，GNSS)，调频(frequency modulation，FM)，近距离无线通信技术(near fieldcommunication，NFC)，红外技术(infrared，IR)等无线通信的解决方案。无线通信模块160可以是集成至少一个通信处理模块的一个或多个器件。无线通信模块160经由天线2接收电磁波，将电磁波信号调频以及滤波处理，将处理后的信号发送到处理器110。无线通信模块160还可以从处理器110接收待发送的信号，对其进行调频，放大，经天线2转为电磁波辐射出去。

继续参见图1，音频模块170可以包括扬声器170A，受话器170B，麦克风170C，耳机接口170D等。示例性的，电子设备100可以通过应用处理器和音频模块170中的扬声器170A，受话器170B，麦克风170C，耳机接口170D等实现音频功能。例如录音录像功能。

继续参见图1，传感器模块180可以包括压力传感器，陀螺仪传感器，气压传感器，磁传感器，加速度传感器，距离传感器，接近光传感器，指纹传感器，温度传感器，触摸传感器，环境光传感器，骨传导传感器等，此处不再一一列举，本申请对此不作限制。

继续参见图1，显示屏194用于显示图像，视频等。显示屏194包括显示面板。在一些实现方式中，电子设备100可以包括1个或N个显示屏194，N为大于1的正整数。电子设备100可以通过GPU，显示屏194，以及应用处理器等实现显示功能。GPU为图像处理的微处理器，连接显示屏194和应用处理器。GPU用于执行数学和几何计算，用于图形渲染。处理器110可包括一个或多个GPU，其执行程序指令以生成或改变显示信息。

具体到本申请实施例提供的技术方案中，图层的绘制渲染、合成，就涉及到GPU和应用处理器，如图1中示出的应用处理器AP 110A和GPU 110B。

关于电子设备100的硬件结构就介绍到此，应当理解地是，图1所示电子设备100仅是一个范例，在具体实现中，电子设备100可以具有比图中所示的更多的或者更少的部件，可以组合两个或多个的部件，或者可以具有不同的部件配置。图1中所示出的各种部件可以在包括一个或多个信号处理和/或专用集成电路在内的硬件、软件、或硬件和软件的组合中实现。

为了更好地理解图1所示电子设备100的软件结构，以下对电子设备100的软件结构进行说明。在对电子设备100的软件结构进行说明之前，首先对电子设备100的软件系统可以采用的架构进行说明。

具体的，在实际应用中，电子设备100的软件系统可以采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构。

此外，可理解地，目前主流的电子设备使用的软件系统包括但不限于Windows系统、Android系统和iOS系统。为了便于说明，本申请实施例以分层架构的Android系统为例，示例性说明电子设备100的软件结构。

此外，后续关于本申请实施例提供的技术方案，在具体实现中同样适用于其他系统。

参见图2，为本申请实施例的电子设备100的软件结构框图。

如图2所示，电子设备100的分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实现方式中，将Android系统分为四层，从上至下分别为应用程序(Applications，APP)层，应用程序框架(Application Framework，FWK)层(可以理解为是系统服务框架)，安卓运行时(Android runtime)和系统库(即，本地框架和运行时环境，也可称为Native层)，以及内核(Kernel)层。

其中，APP层可以包括一系列应用程序包。具体到本申请实施例针对的游戏场景，APP层可以包括各种游戏平台提供的游戏应用和非游戏应用。

示例性的，在一种可能的实现方式中，APP层中的游戏应用例如可以包括平台1提供的游戏1、游戏2，平台2提供的游戏3。

继续参见图2，示例性的，在一种可能的实现方式中，平台1提供的各种游戏应用可以是集成了游戏终端技术优化(Tencent Game Performance Amelioration，TGPA)接口的游戏应用。由于TGPA打通了游戏和终端操作系统，构建了一座联通游戏和设备厂商，如手机厂商之间的桥梁。这样，针对集成了TGPA的游戏应用，通过TPGA对游戏场景的深入分析，上层和各个游戏统一对接，底层和不同的厂商进行对接，进而实现了统一的游戏性能解决方案。即，针对相同的游戏应用，安装该游戏应用的不同电子设备都可以实现统一的游戏性能解决方案，从而合理进行资源调度。

继续参见图2，示例性的，在一种可能的实现方式中，平台2提供的各种游戏应用可以是直接基于设备厂商提供的游戏软件开发工具包(GameSDK)实现的。这样，通过使用设备厂商提供的GameSDK进行游戏应用的开发，可以使得此类游戏应用被安装到设备厂商提供的电子设备后，电子设备可以通过游戏场景和运行状态的不同，使用不同策略调度系统资源，以达到更精细化的优化效果。

此外，需要说明的是，关于非游戏应用，具体到实际应用中，例如可以是设置应用、记事本应用、邮件应用、音视频应用等，此处不再一一列举，本申请对此不作限制。

其中，FWK层为APP层的应用程序提供应用编程接口(application programminginterface，API)和编程框架。在一些实现方式中，这些编程接口和编程框架可以描述为函数，或者服务。具体到本申请实施例针对的游戏场景，在APP层安装了基于TGPA和GameSDK实现的游戏应用的情况下，FWK层中可以包括TGPA对应的编程接口和编程框架，以及GameSDK对应的编程接口和编程框架。为了便于说明，本实施例将TGPA对应的编程接口和编程框架描述为TGPA Service，将GameSDK对应的编程接口和编程框架描述为GameKit Service。

此外，需要说明的是，在实际应用中，FWK层还可以包括其他编程接口和编程框架。例如，窗口管理器、内容提供器、视图系统、电话管理器、资源管理器等，此处不再一一列举，本申请对此不作限制。

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

其中，内容提供器用来存放和获取数据，并使这些数据可以被应用程序访问。所述数据可以包括视频，图像，音频，拨打和接听的电话，浏览历史和书签，电话簿等，此处不再一一列举，本申请对此不作限制。

其中，视图系统包括可视控件，例如显示文字的控件，显示图片的控件等。视图系统可用于构建应用程序。显示界面可以由一个或多个视图组成的。例如，包括短信通知图标的显示界面，可以包括显示文字的视图以及显示图片的视图。

其中，电话管理器用于提供电子设备100的通信功能。例如通话状态的管理(包括接通，挂断等)。

其中，资源管理器为应用程序提供各种资源，比如本地化字符串，图标，图片，布局文件，视频文件等，此处不再一一列举，本申请对此不作限制。

应当理解地是，上述说明仅是为了更好地理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

其中，Native层提供了一些本地服务和常用的系统库。具体到本申请实施例提供的技术方案中，为了实现各应用对应的图层的绘制渲染、合成，以及对游戏数据的识别获取，进而实现在游戏场景下进行资源调度，Native层中可包括图2示出的图形渲染库、游戏感知模块、图形用户界面库、图像合成模块、游戏控制模块、调度服务等。

其中，图形渲染库例如为libEGL、libGL ES、libvulkan等，此处不再一一列举，本申请对此不作限制。

具体到本申请实施例提供的技术方案中，为了实现游戏数据的识别获取，图形渲染库除了实现Android系统提供的原生功能，在图形渲染库中还新增了图2示出的初始化模块、绘制调用模块、区域获取模块。

其中，初始化模块具体用于在APP层中任一应用加载图形渲染库时，初始化图形渲染库，同时准备创建游戏感知线程。即，在初始化图形渲染库时，可以同时向游戏感知模块发送创建游戏感知线程的请求。

其中，绘制调用模块用于获取当前的绘制调用信息，即DrawCall信息。

其中，区域获取模块用于获取当前的区域(area)信息，如宽、高等。

其中，图形用户界面库例如为Graphics libs、libgui等，此处不再一一列举，本申请对此不作限制。

需要说明的是，APP层中触发的应用需要绘制渲染的图层具体是在图形用户界面库中完成的，即图形用户界面库中包括了绘制渲染图层的生产者。由于绘制渲染的图层均是以缓存Buffer的形式交换至图像合成模块(SurfaceFlinger，SF)的，为了便于描述，本实施例将图形用户界面库中绘制渲染图层的生产者描述为缓存队列生产者，即通常所说的BufferQueueProducer。

此外，基于每一帧绘制渲染好的图层，需要Buffer swap(缓存交换)至SF模块(或者说SF线程)，而APP侧的Buffer交换至SF线程需要借助跨线程缓存队列，即通常所说的BLASTBufferQueue实现。

故而，图形用户界面库中需要包括缓存队列生产者(BufferQueueProducer)和跨线程缓存队列(BLASTBufferQueue)，如图2所示。

其中，在一些可能的实现方式中，图像合成模块用于对图形用户界面库传递来的绘制渲染好的图层进行合成，以及将合成的画面进行送显。具体到本申请实施例提供的技术方案中，图像合成模块还用于对图层进行筛选，具体为筛选出与游戏场景相关的图层，并将筛选出的游戏场景的图层信息发送给游戏控制模块。

其中，游戏感知模块为实现本申请实施例提供的技术方案涉及的主要功能模块，即电子设备进行资源调度时所依赖的游戏数据的识别处理是在游戏感知模块中实现的。

在本申请实施例提供的技术方案中，游戏感知模块实现的具体功能可如图3A所示。

参见图3A，示例性的，游戏感知模块可以用于判断当前加载图形渲染库的应用是否为游戏应用。

可理解地，为了便于维护，可以将该功能单独封装为一个子模块，即判断当前加载图形渲染库的应用是否为游戏应用的处理可以由该子模块实现。为了便于说明，可以将该子模块描述为游戏感知子模块。

需要说明的是，由于在实际应用中，图层的绘制渲染可能是由用户界面线程(UserInterface Thread，UI线程)直接进行绘制渲染的，即并非真正的渲染线程。因此，游戏感知模块还可以用于判断当前线程是否为渲染线程。同样，为了便于维护，可以将该功能单独封装为一个子模块，即判断当前线程是否为渲染线程的处理可以由该子模块实现。为了便于说明，可以将该子模块描述为渲染线程感知子模块。

此外，还需要说明的是，在实际应用中，电子设备可能多线程作业，例如同时运行这多个应用。这些应用中可能包括游戏应用。在这种场景中，用户可能会进行不同应用的切换，因此游戏应用的运行场景可能会频繁发生变化，如进入(Game In，即焦点作用于该游戏应用)，或退出(Game Out，即焦点不在该游戏应用)。因此，游戏感知模块还可以用于判断当前是进入游戏运行场景(Game In)，还是退出游戏运行场景(Game Out)。同样，为了便于维护，可以将该功能单独封装为一个子模块，即判断当前是进入游戏运行场景(Game In)，还是退出游戏运行场景(Game Out)的处理可以由该子模块实现。为了便于说明，可以将该子模块描述为游戏运行场景感知子模块。

此外，还需要说明的是，在实际应用中，电子设备在多线程作业场景下，会有多个绘制线程进行图层的绘制渲染。因此，游戏感知模块还可以用于判断当前的多个渲染线程中，哪一个为主渲染线程。同样，为了便于维护，可以将该功能单独封装为一个子模块，即判断当前的多个渲染线程中，哪一个为主渲染线程的处理可以由该子模块实现。为了便于说明，可以将该子模块描述为主渲染线程感知子模块。

继续参见图3A，示例性的，游戏感知模块识别出的上述游戏数据，还需要交由游戏控制模块，进而传递给调度服务，以便调度服务根据这些游戏数据进行资源调度。故而，游戏感知模块还用于发送调用信息和图层信息。示例性的，这两个功能同样可以单独封装为子模块。为了便于描述，可以将发送调用信息的子模块描述为调用信息发送子模块，将发送图层信息的子模块描述为图层信息发送子模块。

应当理解地是，上述说明仅是为了更好地理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。在实际应用中，可以根据业务需要进行功能模块的划分，本申请对此不作限制。

其中，游戏控制模块可用于确定游戏场景的图层的帧率，以及对游戏感知模块提供的游戏数据，SF线程筛选出的图层信息等进行调度转发，如图3B所示。

其中，调度服务用于根据游戏控制模块转发的调度信息，对电子设备的系统资源进行调度，以保证游戏应用的体验效果。

关于Native层的描述就介绍到此。可理解地，在实际应用中，Native层还可以包括其他本地服务和系统库，本申请对此不作限制。

继续参见图2，Kernel层是硬件和软件之间的层。示例性的，在一些可能的实现方式中，Kernel层可包含各种驱动，如图2示出的GPU驱动，AP驱动，显示驱动等。

关于电子设备100的软件结构就介绍到此，可以理解地是，图2示出的软件结构中的层以及各层中包含的部件，并不构成对电子设备100的具体限定。在本申请另一些实施例中，电子设备100可以包括比图示更多或更少的层，以及每个层中可以包括更多或更少的部件，本申请不做限定。

针对图2和图3所示的硬件结构和软件结构的电子设备，以下结合图4对实现本申请实施例提供的游戏数据的识别方法过程中，涉及的功能模块的交互流程进行说明。

参见图4，示例性的，本实施例以识别的游戏数据包括是否为游戏应用，是否为渲染线程，游戏运行场景等为例。针对这一游戏数据的识别需求，涉及的功能模块可包括图形渲染库中的初始化模块、绘制调用模块、区域获取模块，图形用户界面库，游戏感知模块中的游戏感知子模块、渲染线程感知子模块、游戏运行场景感知子模块，游戏控制模块，图像合成模块和调度服务等。

为了便于区分每个功能模块实现的操作，本实施例以图形渲染库中的功能模块实现的步骤用标号10X表示，如图4中示出的步骤101至步骤104；图形用户界面库实现的步骤用标号20X表示，如图4中示出的步骤201至步骤203；以游戏感知模块中的功能模块实现的步骤用标号30X表示，如图4中示出的步骤301至步骤308；游戏控制模块实现的步骤用户标号40X表示，如图4中示出的步骤401至步骤403；图像合成模块实现的步骤用标号50X表示，如图4中示出的步骤501至步骤504；调度服务实现的步骤用标号601表示。

此外，还需要说明的是，本实施例中的步骤101至步骤104，步骤201至步骤203，步骤301至步骤308，步骤401至步骤403，步骤501至步骤504，步骤601并没有具体的先后顺序关系，在实际处理流程中，只要当前步骤所需的数据存在，便可以进行下一个步骤的处理，图4仅示出了一种处理流程的示意图。

参见图4，本实施例提供的游戏数据的识别方法，具体包括：

101，初始化模块初始化图形渲染驱动。

具体地，当APP层任一存在界面绘制的应用加载图形渲染库时，图形渲染库中的初始化模块将初始化图形渲染驱动。

示例性的，在图形渲染库为libEGL时，则初始化的例如为EGL Driver。

应当理解地是，上述说明仅是为了更好地理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

继续参见图4，示例性的，在本实施例中，初始化模块在对初始化图形渲染驱动时，还会通知游戏感知模块创建对应的线程(后续称为：游戏感知线程)。

需要说明的是，当确定当前加载图形渲染库的应用为游戏应用时，才会真正创建游戏感知线程，进而使得游戏感知模块中的各子模块能够实现对应的功能，即实现游戏数据的识别。因此，在一些可能的实现方式中，初始化模块在通知游戏感知模块，具体为游戏感知模块中的游戏感知子模块创建游戏感知线程时，可以通过向游戏感知子模块发送携带了当前加载图形渲染库的应用的应用包名等信息的创建游戏感知线程请求，进而使得游戏感知子模块能够根据该请求中携带的应用包名进行游戏应用的识别，进而在确定当前应用为游戏应用时，创建游戏感知线程。

继续参见图4，示例性的，当初始化模块完成对图形渲染驱动的初始化操作后，会通知图形渲染库中的其他功能模块，如绘制调用模块、区域获取模块，图形渲染驱动已经初始化成功。

102，绘制调用模块获取绘制调用信息。

具体地，绘制调用模块在获知图形渲染驱动已经初始化成功后，将会获取电子设备产生的绘制调用信息，即DrawCall信息。

103，区域获取模块获取区域信息(宽、高等)。

具体地，区域获取模块在获知图形渲染驱动已经初始化成功后，将会获取当前要绘制的视图的信息，例如宽度和高度。

需要说明的是，在图形渲染库为不同的图形库时，其要记录的宽度和高度的来源也不同。

示例性的，一种可能的实现方式中，对于图形渲染库为libGL ES(也可以理解为是OpenGL ES)时，获取的是当前屏幕(Surface)的宽度和高度。

可理解地，Surface是Android系统中一个重要的原语，它是一块屏幕的抽象表示。它提供了一个支持绘制、更改尺寸、透明度、格式和管理SurfaceView的生命周期的接口。在Android应用程序中，Surface通常表示一个可以渲染、处理用户输入、与其他SurfaceView进行组合的视图元素。

示例性的，在另一种可能的实现方式中，对于图形渲染库为Vulkan(即上述所说的libvulkan)时，获取的是创建交换链(Swapchain)时记录的宽度和高度。

可理解地，Swapchain是一系列虚拟帧缓冲区，由显卡和图形API(ApplicationProgramming Interface，应用程序接口)用于稳定帧速率和其他一些功能。Swapchain通常存在于图形内存中，但也可以存在于系统内存中。

可理解地，Vulkan是一个跨平台的2D和3D绘图应用程序接口(API)，旨在提供更低的CPU开销与更直接的GPU控制。

由此可见，不论哪种形式的图形渲染库，区域获取模块均可以获取需要的高度和宽度。

104，区域获取模块向图像合成模块传递区域信息。

具体地，区域获取模块在获取到区域信息，如高度和宽度后，会将获取到的区域信息传递至图像合成模块中记录。

此外，还应当理解地，由于区域获取模块可以获取高度和宽度，因此基于高度和宽度，区域获取模块可以直接确定要绘制渲染的区域的面积大小，进而在向图像合成模块传递区域信息时，将当前要绘制渲染的区域的面积大小也传递至图像合成模块记录。

由此，游戏数据的识别方案中，在图形渲染库中进行的处理便完成了。

继续参见图4，示例性的，通常情况下，在APP层的应用加载图形渲染库时，也会向图形用户界面库发送绘制该应用所需的图层的请求，或者说指令。相应地，图形用户界面库在接收到绘制该应用的请求(指令)后，将开始绘制该应用所需的图层，即执行步骤201。

201，图形用户界面库绘制应用的图层。

通过图2可知，图形用户界面库中包括缓存队列生产者和跨线程缓存队列。其中，缓存队列生产者是用于进行图层绘制的。故而，该步骤中图形用户界面库绘制应用的图层的操作，具体是由缓存队列生产者实现的。

继续参见图4，示例性的，图形用户界面库在绘制应用所需的图层的过程中，会获取电子设备在该过程中的系统信息，如屏幕状态信息、焦点信息等，并将这些系统信息传递给图像合成模块记录，即执行步骤202。

202，图形用户界面库向图像合成模块传递系统信息(屏幕状态信息、焦点信息)。

其中，屏幕状态信息，例如包括电子设备当前屏幕的亮、灭状态信息。

其中，焦点信息，例如通过遍历绘制渲染好的所有图层的Focus(焦点)进而获得当前的焦点图层。

继续参见图4，示例性的，图形用户界面库在完成对所需图层的绘制后，会将绘制好的图层传递至图像合成模块进而合成处理，即执行步骤203。

203，图形用户界面库向图像合成模块传递绘制好的图层。

通过图2可知，图形用户界面库中包括缓存队列生产者和跨线程缓存队列。其中，跨线程缓存队列是用于将APP侧，即应用对应的图层传递至图像合成模块的。故而，该步骤中图形用户界面库向图像合成模块传递绘制好的图层的操作，具体是由跨线程缓存队列实现的。

由此，游戏数据的识别方案中，在图形用户界面库中进行的处理便完成了。

继续参见图4，示例性的，当初始化模块发送的创建游戏感知线程请求到达游戏感知子模块时，游戏感知子模块将根据该请求中携带的应用包名等信息，去游戏控制模块对应的内存中查找是否存在与该应用包名匹配的游戏包名。

当在游戏控制模块对应的内存中查找到与该应用包名匹配的游戏包名时，游戏感知子模块便可以创建游戏感知线程，即执行步骤步骤301和步骤302，从而使得游戏感知模块中的其他子模块实现的功能能够使用。

可理解地，游戏控制模块对应的内存中的游戏包名，可以为预先存储的已知游戏应用的包名。这样，通过进行应用包名的匹配，便可以确定当前加载图形渲染库的应用是否为游戏应用。

301，游戏感知子模块在游戏控制模块对应的内存中查找是否有与应用包名匹配的游戏包名。

302，游戏感知子模块在应用包名与预存的游戏应用包名匹配时，创建游戏感知线程。

继续参见图4，示例性的，游戏感知子模块在创建游戏感知线程后，便可以根据业务需求，通知游戏感知模块中封装的各个子模块，游戏感知线程创建成功，以便这些子模块能够进行游戏数据的识别处理。

示例性的，本实施例以游戏数据的识别需要包括渲染线程的识别、游戏运行场景的识别为例。在这种业务需求下，游戏感知子模块将通知渲染线程感知子模块和游戏运行场景感知子模块游戏感知线程创建成功。这样，渲染线程感知子模块便可以判断当前线程是否为渲染线程的识别处理，游戏运行场景感知子模块便可以判断当前是进入游戏场景，还是退出游戏场景。

应当理解地是，上述说明仅是为了更好地理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。在实际应用中，如果还需要涉及主渲染线程的识别，则游戏感知子模块还需要通知主渲染线程感知子模块游戏感知线程创建成功。这样，主渲染线程感知子模块便可以判断当前渲染线程是否为主渲染线程的识别处理。

此外，还应当理解地，在游戏感知线程创建后，表示当前存在游戏应用，因此在一些可能的实现方式中，游戏感知子模块还可以将当前识别出的游戏应用的相关信息传递至游戏控制模块，以便游戏控制模块进行帧率计算，并将计算出的帧率、接收到的游戏应用的相关信息传递至调度服务，进而实现对系统资源的合理调度。

此外，需要说明的是，在本申请实施例提供的技术方案中，针对APP层中每一个加载图形渲染库的应用，如果经过步骤301的处理确定该应用是游戏应用，则游戏感知模块中的游戏感知子模块都将为该游戏应用创建一个独立的游戏感知线程。这样，对于每一个游戏应用均有属于自己的游戏感知线程，进而通过对应的游戏感知线程，就可以调用游戏感知模块中各功能子模块，进而实现对应的功能。

本实施例为了便于说明，仅是从一个游戏应用的角度进行说明的。在实际应用中，可以存在多个游戏应用的运行场景。对于每一个游戏应用，均可按照本实施例提供的流程进行处理。

303，游戏运行场景感知子模块周期性地，根据区域信息和系统信息，确定游戏运行场景(进入or退出)。

继续参见图4，示例性的，由于步骤104中已经将区域信息传递至图像合成模块中记录，步骤202中已经将系统信息传递至图像合成模块中记录，因此在一种可能的实现方式中，图像合成模块可以主动将得到的区域信息和系统信息发送至游戏运行场景感知子模块进行处理，即执行步骤401。

示例性的，在另一种可行的实现方式中，也可以由游戏运行场景感知子模块主动向图像合成模块发起数据获取请求，进而从图像合成模块处获取到需要的区域信息和系统信息。

应当理解地是，上述说明仅是为了更好地理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。图4以图像合成模块主动向游戏运行场景感知子模块发送区域信息和系统信息，即执行步骤401为例。

可理解地，根据焦点信息可以确定当前绘制是哪一图层，或者说作业的是哪一应用的进程(线程)。因此，根据图像合成模块提供的区域信息和系统信息，便可以确定焦点所在的图层、应用的进程(线程)。

因此，关于游戏运行场景是属于进入，还是退出的判断，在一种可能的实现方式中，游戏运行场景感知子模块可以通过判断焦点所在的图层、应用的进程(线程)实现游戏运行场景的识别。

具体地，游戏运行场景感知子模块会在从图像合成模块处接收各个应用对应的Buffer信息，进而通过判断当前的Buffer中的图层是否处于Focus的状态。

示例性的，若处于Focus的状态，则记录对应的进程号，进而通过判断Focus的进程号是否为预设的游戏应用对应的进程号便可以确定，当前是否处于游戏运行场景。

具体地，若存在匹配的进程号，则认为当前游戏运行场景属于进入，即GameIn。反之，则认为当前游戏影响场景属于退出，即GameOut。

由此，游戏运行场景感知子模块通过确定当前的游戏运行场景，便可以获知游戏运行场景是否发生变换。

此外，需要说明的是，CPU(本实施例可以为AP)和GPU之间的数据是通过命令缓冲区进行传输的，如图5所示。命令缓冲区包含了一个队列，由CPU从队投向其中添加命令，GPU则从队尾去读取命令，添加和读取的命令都是相互独立的。当CPU需要渲染一个对象时，就可以向命令缓冲区中添加命令，而当GPU完成上一个渲染任务后，就会从命令缓冲区中再取出一条命令并执行它。

还需要说明的是，命令缓冲区中的命令可以有很多种类，DrawCall是其中的一种，即本实施例中所说的DrawCall信息便是CPU添加到命令缓冲区，指示GPU去完成的渲染任务的信息，如图5中示出的绘制渲染模型A、绘制渲染模型B、绘制渲染模型C等均为DrawCall。

还需要说明的是，命令缓冲区中还可以添加除DrawCll的命令(后续描述为其他命令)。示例性的，在一些可能的实现方式中，其他命令例如为用于改变渲染状态，如改变使用的着色器，使用不同的纹理等的命令。

由此可知，当处于游戏运行场景，即GameIn状态时，CPU会指示GPU针对每一帧进行绘制渲染处理，因此在GameIn状态下，会有源源不断的DrawCall信息。而当处于GameOut状态时，GPU将停止指示GPU针对每一帧进行绘制渲染处理，因此在GameOut状态下，GPU将无法从命令缓冲区中读取到DrawCall信息。

因此，关于游戏运行场景是属于进入，还是退出的判断，在另一种可能的实现方式中，游戏运行场景感知子模块可以通过判断设定时间，如5s内是否有DrawCall信息的方式确定当前的游戏运行场景。

具体地，如果超过设定时间，没有得到DrawCall信息，则认为当前游戏运行场景属于退出，即GameOut。反之，则认为当前游戏影响场景属于进入，即GameIn。

由此，游戏运行场景感知子模块在按照上述任意方式，确定当前的游戏运行场景相较于前一次识别，发生变换时，便可以通知游戏控制模块，游戏运行场景发生变换，并具体告知变换后的场景信息，如是GameIn，还是GameOut，即执行步骤304。

304，游戏运行场景感知子模块确定游戏运行场景发生变换，并将确定的信息传递至游戏控制模块。

由此，通过步骤401、步骤303和步骤304，实现的了游戏运行场景相关的游戏数据的识别。

继续参见图4，示例性的，对于渲染线程相关的游戏数据的识别，可通过步骤305值步骤308实现。

305，渲染线程感知子模块获取绘制调用信息。

需要说明的，通常情况下，响应于与DrawCall，执行绘制渲染任务的线程便是渲染线程。但是，在一些可能的情况下，UI线程也一样存在DrawCall，这些UI线程对应的DrawCall有时对应Surface的渲染面积大小一致，或者窗口事件内DrawCall的请求次数多于游戏的渲染线程，因此UI线程相关的信息会干扰最终的资源调度。故而，需要将UI线程和渲染线程进行识别区分。

为了实现对渲染线程和UI线程的识别，渲染线程感知子模块需要先从绘制调用模块处获取绘制调用信息，进而根据绘制调用信息，确定当前线程是否为渲染线程，即执行步骤306。

306，渲染线程感知子模块根据绘制调用信息确定当前线程是否为渲染线程。

需要说明的，目前基于Android系统的原生接口可知，对于UI线程和渲染线程，其在读取命令缓冲区中的DrawCall时，使用的方法函数是不相同的。为了便于区分，在一种可能的实现方式中，将UI线程使用的方法函数描述为“eglSwapBuffersWithDamageKHR”，将渲染线程使用的方法函数描述为“eglswapbuffer”。

因此，在一种可能的实现方式中，渲染线程感知子模块可以通过判断读取命令缓冲区中DrawCall的方法函数便可以确定当前线程究竟为UI线程，还是游戏的渲染线程。

如图6A所示，示例性的，在使用的方法函数为“eglSwapBuffersWithDamageKHR”时，确定当前线程为UI线程。在使用的方法函数为“eglswapbuffer”时，确定当前线程为游戏的渲染线程。

此外，还需要说明的是，通常情况下UI线程绘制的图层为二维画面。即，UI线程绘制的图层对应的顶点信息为2D维度的，而游戏的渲染线程绘制的图层通常为三维画面。因此，在另一种可能的实现方式中，渲染线程感知子模块可以通过调用专门用来获取线程传递的顶点坐标的方法函数“Hook glVertexAttribPointer”，获取当前绘制的图层的顶点坐标。进而根据顶点坐标的维度，确定当前线程是UI线程，还是游戏的渲染线程。

如图6B所示，示例性的，在使用的方法函数“Hook glVertexAttribPointer”获取到的当前线程传递的顶点坐标是二维坐标时，可以确定当前线程为UI线程。反之，在使用的方法函数“Hook glVertexAttribPointer”获取到的当前线程传递的顶点坐标是三维坐标时，可以确定当前线程为游戏的渲染线程。

由此，在确定当前线程是UI线程，还是游戏的渲染线程后，渲染线程感知子模块便可以将确定的线程结果传递至游戏控制模块，以便游戏控制模块进行调度，将对应的信息传递至调度服务，使得调度服务能够根据这些游戏数据进行合理的资源调用。

307，渲染线程感知子模块确定当前线程为绘制渲染线程，并将确定的信息传递至游戏控制模块。

308，渲染线程感知子模块确定当前线程不是绘制渲染线程(如UI线程)，并将确定的信息传递至游戏控制模块。

由此，实现了关于游戏的渲染线程等游戏数据的识别。

此外，还需要说明的是，在多渲染线程，多图层的场景下，需要精准确定当前的主渲染线程，以使得游戏控制模块能够统计出准确地游戏帧率，进而使得调度服务能够更好的进行资源调用。针对这种场景和业务需求，渲染线程感知子模块在识别出当前存在多个渲染线程的情况下，可以通知主渲染线程感知子模块进一步进行主渲染线程的识别操作。

具体地，在图形渲染库中，每一个游戏应用绘制渲染时请求的DrawCall信息均会使用钩子函数(Hook)进行截取，以使得API的执行流向转向游戏感知模块，即每一个游戏应用对应的渲染线程请求的DrawCall都会有游戏感知模块保留记录。

这样，渲染线程感知子模块就可以基于DrawCall判断当前线程是否为游戏的渲染线程。相应地，主渲染线程感知子模块也可以基于DrawCall实现主渲染线程的识别。

示例性的，在一种可能的实现方式中，可以通过判断设定时间窗口内的DrawCall数量来确定主渲染线程。

参见图7，示例性的，以当前存在3个渲染线程，如渲染线程1、渲染线程2和渲染线程3为例。

继续参见图7，示例性的，在一个时间窗口(如10s)内，渲染线程1对应的平均DC(DrawCall)次数为2次，即DC_NUM1＝2。

继续参见图7，示例性的，在一个时间窗口(如10s)内，渲染线程2对应的平均DC(DrawCall)次数为2次，即DC_NUM2＝5。

继续参见图7，示例性的，在一个时间窗口(如10s)内，渲染线程3对应的平均DC(DrawCall)次数为3次，即DC_NUM3＝3。

通过对这3个渲染线程的DC次数进行取最大值的操作，可以确定MAX(DC_NUM1，DC_NUM2，DC_NUM3)＝5。通过上述描述可知，在一个时间窗口内，DC次数为5的渲染线程为渲染线程2。故而，可以将渲染线程2确定为主渲染线程。

由此，游戏数据的识别方案中，在游戏感知模块中进行的处理便完成了。

继续参见图4，示例性的，在图层的绘制渲染过程中，获取到的区域信息和系统信息都会传递至图像合成模块进行保存记录。而游戏感知模块对上述游戏数据的识别，需要依赖区域信息和系统信息，因此在一些可能的实现方式中，图像合成模块可以在得到区域信息和系统信息后，主动向游戏运行场景感知子模块传递区域信息和系统信息，即执行步骤401。在另一些可能的实现方式中，图像合成模块也可以在接收到游戏运行场景感知子模块的请求后，再将记录的区域信息和系统信息传递给游戏运行场景感知子模块。

401，图像合成模块向游戏运行场景感知子模块传递区域信息、系统信息。

402，图像合成模块对图层进行合成，并过滤出游戏场景的图层。

具体地，在本申请实施例提供的技术方案中，图像合成模块不仅需要对图层进行合成处理，还需要过滤出游戏场景的图层，并将过滤出的游戏场景的图层传递至游戏控制模块，即在执行完步骤402后，接着执行步骤403。

403，图像合成模块向游戏控制模块传递过滤出的游戏场景的图层信息。

由此，游戏数据的识别方案中，在图像合成模块中进行的处理便完成了。

继续参见图4，示例性的，游戏控制模块在得到来自游戏感知模块、图像合成模块的游戏数据后，可以将这些游戏数据传递至调度服务，以便调度服务根据游戏数据进行合理的资源调度。

关于游戏控制模块传递至调度服务的游戏数据，可以包括步骤501至步骤504的数据。

501，游戏控制模块向调度服务传递游戏运行场景变换信息。

502，游戏控制模块向调度服务传递渲染绘制线程信息。

503，游戏控制模块向调度服务传递UI线程信息。

由于本案针对的是游戏场景下系统资源的调度，因此对于这种场景，在一些可能的实现方式中，游戏控制模块可以过滤掉该信息，即不向调度服务传递。

504，游戏控制模块向调度服务传递游戏场景的图层信息。

由此，游戏数据的识别方案中，在游戏控制模块中进行的处理便完成了。

601，根据游戏控制模块转发的调度信息，进行资源调用。

关于资源调用的具体实现，可以参见现有根据调度信息进行资源调度的具体实现方案，此处不再赘述，本申请对此也不作限制。

此外，需要说明的是，在本申请实施例提供的技术方案中，每个游戏应用都用独立的游戏感知线程，即每次有应用加载图形渲染库时，游戏感知模块都会根据初始化模块提供的应用包名，确定该应用是否为游戏应用，进而在该应用是游戏应用时，为其创建对应的游戏感知线程。

也就是说，通过新增的绘制调用模块和区域获取模块，在图层绘制渲染前就可以实现信息的收集，实现了多游戏场景，如后台游戏/前台游戏+悬浮窗游戏/左右分屏游戏/上下分屏游戏下的信息收集。这样，就可以为不同游戏场景的应用创建对应的游戏感知线程，从而使得每一个游戏应用的游戏数据能够通过独立的游戏感知线程进行收集，进而保证了针对每一个游戏应用进行的资源调度的合理性。

此外，基于本申请实施例提供的游戏数据的识别方法，能够精准的识别出主渲染线程，这样在多渲染线程、多图层的情况下，就可以统计出准确地游戏帧率，使得调度服务能够更好的进行资源调用。

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

此外，需要说明的，在实际的应用场景中由电子设备实现的上述各实施例提供的游戏数据的识别方法，也可以由电子设备中包括的一种芯片系统来执行，其中，该芯片系统可以包括处理器。该芯片系统可以与存储器耦合，使得该芯片系统运行时调用该存储器中存储的计算机程序，实现上述电子设备执行的步骤。其中，该芯片系统中的处理器可以是应用处理器也可以是非应用处理器的处理器。

一个示例中，图8示出了本申请实施例的一种装置的示意性框图。如图8所示，该装置可包括：处理器和收发器/收发管脚，可选地，还包括存储器。

示例性的，在一种可能的实现方式中，该装置的各个组件通过总线耦合在一起，其中总线除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图中将各种总线都称为总线。

可选地，存储器可以用于前述方法实施例中的指令。该处理器可用于执行存储器中的指令，并控制接收管脚接收信号，以及控制发送管脚发送信号。

该装置可以是上述方法实施例中的电子设备或电子设备的芯片。

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

另外，本申请实施例还提供一种计算机可读存储介质，该计算机存储介质中存储有计算机指令，当该计算机指令在电子设备上运行时，使得电子设备执行上述相关方法步骤实现上述实施例中的游戏数据的识别方法。

另外，本申请实施例还提供了一种计算机程序产品，当该计算机程序产品在电子设备上运行时，使得电子设备执行上述相关步骤，以实现上述实施例中的游戏数据的识别方法。

另外，本申请的实施例还提供一种芯片(也可以是组件或模块)，该芯片可包括一个或多个处理电路和一个或多个收发管脚；其中，所述收发管脚和所述处理电路通过内部连接通路互相通信，所述处理电路执行上述相关方法步骤实现上述实施例中的游戏数据的识别方法，以控制接收管脚接收信号，以控制发送管脚发送信号。

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

以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细地说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (17)

1.一种游戏数据的识别方法，其特征在于，应用于电子设备，所述方法包括：

在接收到所述电子设备中安装的任一应用触发的绘制渲染请求时，确定触发所述绘制渲染请求的应用中是否存在游戏应用；

在存在所述游戏应用时，为每一个所述游戏应用创建对应的游戏感知线程；

基于每一个所述游戏应用对应的游戏感知线程，获取绘制渲染每一个游戏应用的图层所需的绘制调用信息，以及绘制渲染过程中记录的区域信息和所述电子设备的系统信息；

根据每一个所述游戏应用对应的绘制调用信息、区域信息和系统信息，识别每一个所述游戏应用的游戏数据。

2.根据权利要求1所述的方法，其特征在于，所述在接收到所述电子设备中安装的任一应用触发的绘制渲染请求时，确定触发所述绘制渲染请求的应用中是否存在游戏应用，包括：

在接收到所述电子设备中安装的任一应用对图形渲染库的加载时，确定触发所述绘制渲染请求的应用中是否存在游戏应用。

3.根据权利要求2所述的方法，其特征在于，所述在接收到所述电子设备中安装的任一应用触发的绘制渲染请求时，所述方法还包括：

初始化所述图形渲染库对应的图形渲染驱动；

获取每一应用的应用包名；

获取绘制渲染每一个游戏应用的图层所需的绘制调用信息；

获取绘制渲染过程中记录的区域信息。

4.根据权利要求3所述的方法，其特征在于，所述获取绘制渲染过程中记录的区域信息，包括：

在所述图形渲染库使用第一图形程序接口时，获取当前视图元素的宽度和高度；

根据所述宽度和所述高度，确定当前绘制渲染的面积大小；

将所述宽度、所述高度和所述面积大小，作为所述区域信息。

5.根据权利要求3所述的方法，其特征在于，所述获取绘制渲染过程中记录的区域信息，包括：

在所述图像渲染库使用第二图形程序接口时，获取创建交换链时记录的宽度和高度；

根据所述宽度和所述高度，确定当前绘制渲染的面积大小；

将所述宽度、所述高度和所述面积大小，作为所述区域信息。

6.根据权利要求3所述的方法，其特征在于，所述确定触发所述绘制渲染请求的应用中是否存在游戏应用，包括：

根据每一应用的应用包名，查询是否存在匹配的预设游戏应用包名；

在存在匹配的预设游戏应用包名时，确定触发所述绘制渲染请求的应用中存在游戏应用。

7.根据权利要求1所述的方法，其特征在于，所述在接收到所述电子设备中安装的任一应用触发的绘制渲染请求时，所述方法还包括：

绘制触发所述绘制渲染请求的应用对应的图层，并获取所述系统信息；

将所述系统信息传递至图像合成模块；

将绘制好的图层传递至所述图像合成模块。

8.根据权利要求1至7任一项所述的方法，其特征在于，所述游戏数据包括所述游戏应用当前的游戏运行场景变换信息；

所述根据每一个所述游戏应用对应的绘制调用信息、区域信息和系统信息，识别每一个所述游戏应用的游戏数据，包括：

对于每一个所述游戏应用，根据所述游戏应用的所述区域信息和所述系统信息，确定所述游戏应用当前的游戏运行场景；

在所述游戏应用当前的游戏运行场景发生变换时，得到所述游戏运行场景变换信息。

9.根据权利要求1至7任一项所述的方法，其特征在于，所述游戏数据包括当前的线程信息；

所述根据每一个所述游戏应用对应的绘制调用信息、区域信息和系统信息，识别每一个所述游戏应用的游戏数据，包括：

对于每一个所述游戏应用，根据所述游戏应用对应的所述绘制调度信息，确定当前的线程信息；其中，所述线程信息包括渲染线程的信息或用户界面线程的信息。

10.根据权利要求9所述的方法，其特征在于，所述对于每一个所述游戏应用，所述游戏感知模块根据所述游戏应用对应的所述绘制调度信息，确定当前的线程信息，包括：

对于每一个所述游戏应用，识别读取所述游戏应用对应的所述绘制调度信息的方法函数；

在所述方法函数为第一方法函数时，确定当前的线程为所述用户界面线程，当前的线程信息为所述用户界面线程的信息；

在所述方法函数为第二方法函数时，确定当前的线程为所述渲染线程，当前的线程信息为所述渲染线程的信息。

11.根据权利要求9所述的方法，其特征在于，所述对于每一个所述游戏应用，所述游戏感知模块根据所述游戏应用对应的所述绘制调度信息，确定当前的线程信息，包括：

对于每一个所述游戏应用，根据顶点坐标获取函数获取当前的线程根据所述绘制调用信息绘制的图层的顶点坐标；

在所述顶点坐标为二维坐标时，确定当前的线程为所述用户界面线程，当前的线程信息为所述用户界面线程的信息；

在所述顶点坐标为三维坐标时，确定当前的线程为所述渲染线程，当前的线程信息为所述渲染线程的信息。

12.根据权利要求9所述的方法，其特征在于，在所述游戏数据包括多个渲染线程的信息时，所述游戏数据还包括主渲染信息；

确定所述主渲染信息，包括：

确定每一个渲染线程在设定时间窗口内的绘制调用请求次数；

将绘制调用请求次数最大的渲染线程确定为主渲染线程。

13.根据权利要求8至12任一项所述的方法，其特征在于，在所述识别每一个所述游戏应用的游戏数据之后，所述方法还包括：

根据每一个所述游戏应用的游戏数据，进行资源调度。

14.一种电子设备，其特征在于，所述电子设备包括：存储器和处理器，所述存储器和所述处理器耦合；所述存储器存储有程序指令，所述程序指令由所述处理器执行时，使得所述电子设备执行如权利要求1至13任意一项所述的游戏数据的识别方法。

15.一种计算机可读存储介质，其特征在于，包括计算机程序，当所述计算机程序在电子设备上运行时，使得所述电子设备执行如权利要求1至13任意一项所述的游戏数据的识别方法。

16.一种计算机程序产品，其特征在于，当所述计算机程序产品在计算机上运行时，使得所述计算机执行如权利要求1至13任意一项所述的游戏数据的识别方法。

17.一种芯片，其特征在于，包括一个或多个接口电路和一个或多个处理器；所述接口电路用于从电子设备的存储器接收信号，并向所述处理器发送所述信号，所述信号包括存储器中存储的计算机指令；当所述处理器执行所述计算机指令时，使得所述电子设备执行权利要求1至13任意一项所述的游戏数据的识别方法。