CN117138352B - 应用程序的运行方法、装置、设备及存储介质 - Google Patents

Abstract

本申请公开了一种应用程序的运行方法、装置、设备及存储介质，涉及计算机领域。该方法包括：在所述应用程序运行至核心场景的情况下，启动自适应服务获取所述终端的设备性能状态；所述核心场景包括所述应用程序中对运行性能要求高于阈值的运行场景；根据所述设备性能状态，自适应调整所述应用程序在所述核心场景下的运行参数；在所述核心场景结束的情况下，关闭所述自适应服务。该方法可以根据终端的设备性能状态自适应调整应用程序的运行参数。

Description

应用程序的运行方法、装置、设备及存储介质

技术领域

本申请涉及计算机领域，特别涉及一种应用程序的运行方法、装置、设备及存储介质。

背景技术

随着游戏品质的提高，游戏画面越来越精美细致，游戏玩法更加丰富多样，游戏应用运行中的性能消耗有所上升，这也给终端的状态调整优化带来新的挑战。

相关技术中，游戏应用可以在某个重要游戏进程明显受到影响时，自动启用优化性能的分级应对方案，根据游戏进程的受影响状况，一级一级地整体调节游戏性能指标，例如，适当降低所加载的游戏资源的品质，适当调节帧率，从而降低功耗，平衡设备状态，提高设备续航。

相关技术中的方法，不能很好地对异常状态进行针对性调节，在异常状态一直未好转的情况下，会一直降低整体游戏质量，陷入状态调整误区。

发明内容

本申请实施例提供了一种应用程序的运行方法、装置、设备及存储介质，根据终端的设备性能状态自适应调整应用程序的运行参数。所述技术方案如下。

根据本申请的一方面，提供了一种应用程序的运行方法，所述方法由终端执行，所述方法包括：

在所述应用程序运行至核心场景的情况下，启动自适应服务获取所述终端的设备性能状态；所述核心场景包括所述应用程序中对运行性能要求高于阈值的运行场景；

根据所述设备性能状态，自适应调整所述应用程序在所述核心场景下的运行参数；

在所述核心场景结束的情况下，关闭所述自适应服务。

根据本申请的另一方面，提供了一种应用程序的运行装置，所述装置用于实现终端，所述装置包括：

性能改进模块，用于在所述应用程序运行至核心场景的情况下，启动自适应服务获取所述终端的设备性能状态；所述核心场景包括所述应用程序中对运行性能要求高于阈值的运行场景；

应用模块，用于根据所述设备性能状态，自适应调整所述应用程序在所述核心场景下的运行参数；

所述性能改进模块，用于在所述核心场景结束的情况下，关闭所述自适应服务。

根据本申请的另一方面，提供了一种计算机设备，所述计算机设备包括：处理器和存储器，所述存储器中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由所述处理器加载并执行以实现如上方面所述的应用程序的运行方法。

根据本申请的另一方面，提供了一种计算机可读存储介质，所述存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由处理器加载并执行以实现如上方面所述的应用程序的运行方法。

根据本公开实施例的另一个方面，提供一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述可选实现方式中提供的应用程序的运行方法。

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

当应用程序运行至关键的核心场景时，为了保证核心场景的运行性能，可以自动开启自适应服务，通过自适应服务获取到终端的设备性能状态，基于终端的运行状态来自适应调整应用程序的各个运行参数，使应用程序可以基于终端的设备性能状态有针对性地调整运行参数。例如，当终端的某一设备性能状态较差时，对应降低与该设备性能状态相关的运行参数，以减轻该设备性能的负载；当终端的某一设备性能状态较佳时，可以适当提升与该设备性能状态相关的运行参数，以提升核心场景的用户体验。该方法可以在应用程序运行至核心场景时，自动根据终端的设备性能状态对运行参数进行自适应调整，避免核心场景的运行卡顿，提高核心场景的运行效果。当核心场景结束后，还可以自动关闭自适应服务，降低应用程序的运行负载。

附图说明

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

图1是本申请一个示例性实施例提供的计算机系统的框图；

图2是本申请一个示例性实施例提供的应用程序的运行方法的方法流程图；

图3是本申请另一个示例性实施例提供的应用程序的运行方法的方法流程图；

图4是本申请又一个示例性实施例提供的应用程序的运行方法的方法流程图；

图5是本申请一个示例性实施例提供的应用程序的运行方法的示意图；

图6是本申请再一个示例性实施例提供的应用程序的运行方法的方法流程图；

图7是本申请另一个示例性实施例提供的应用程序的运行方法的示意图；

图8是本申请又一个示例性实施例提供的应用程序的运行方法的示意图；

图9是本申请再一个示例性实施例提供的应用程序的运行方法的示意图；

图10是本申请一个示例性实施例提供的应用程序的运行方法的程序示意图；

图11是本申请一个示例性实施例提供的应用程序的运行装置的框图；

图12是本申请一个示例性实施例提供的终端的框图。

具体实施方式

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

图1示出了本申请一个示例性实施例提供的计算机系统的示意图，该计算机系统包括终端和服务器。

终端120可以包括智能手机、笔记本电脑、台式电脑、平板电脑、智能机器人中的至少一种。在一种可选的实现方式中，本申请提供的应用程序的运行方法可以应用于任一应用程序中，该应用程序可以是：游戏应用程序、即时通信程序、社交应用程序、浏览器应用程序、直播应用程序、视频播放程序、短视频播放程序、资讯程序、知识类程序、生活类程序、购物类程序、图片分享程序、社区程序、论坛应用程序、办公应用程序等。可选地，终端120上安装有该应用程序的客户端。本申请实施例以该应用程序为游戏应用程序进行举例说明。

可选的，该应用程序中集成有性能改进SDK（Software Development Kit，软件开发工具包），性能改进SDK是用于实现运行参数自适应调整功能的工具包，可以集成到任意应用程序中以实现本申请实施例提供的应用程序的运行方法。

示例性的，终端120上存储有自适应调整算法102，客户端可以运行该自适应调整算法102实现本申请实施例提供的应用程序的运行方法。

终端120包括第一存储器和第一处理器。第一存储器中存储有自适应调整算法；上述自适应调整算法被第一处理器调用执行以实现本申请提供的应用程序的运行方法。第一存储器可以包括但不限于以下几种：随机存取存储器（Random Access Memory，RAM）、只读存储器（Read Only Memory，ROM）、可编程只读存储器（Programmable Read-Only Memory，PROM）、可擦除只读存储器（Erasable Programmable Read-Only Memory，EPROM）、以及电可擦除只读存储器（Electric Erasable Programmable Read-Only Memory，EEPROM）。

第一处理器可以是一个或者多个集成电路芯片组成。可选地，第一处理器可以是通用处理器，比如，中央处理器（Central Processing Unit，CPU）或者网络处理器（NetworkProcessor，NP）。可选地，第一处理器可以通过运行程序或代码来实现本申请提供的应用程序的运行方法。

终端120与服务器140之间通过有线或者无线网络相互连接。

服务器140用于为终端120中的应用程序的客户端提供后台服务。或者，服务器140可以是性能改进SDK的后台服务器140。服务器140可以是一台服务器140，也可以是由多台服务器140组成的服务器140集群，或者是一个云计算服务中心。

示意性的，服务器140包括处理器和存储器，存储器又包括接入模块和信息流推送模块。服务器140用于为性能改进SDK提供后台服务。可选地，服务器140承担主要计算工作，终端120承担次要计算工作；或者，服务器140承担次要计算工作，终端120承担主要计算工作；或者，服务器140和终端120之间采用分布式计算架构进行协同计算。

服务器140包括第二存储器和第二处理器。第二存储器中存储有自适应调整算法；上述自适应调整算法被第二处理器调用来实现本申请提供的应用程序的运行方法。可选地，第二存储器可以包括但不限于以下几种：RAM、ROM、PROM、EPROM、EEPROM。可选地，第二处理器可以是通用处理器，比如，CPU或者NP。

图2示出了本申请一个示例性实施例提供的应用程序的运行方法的流程图。该方法可以由终端来执行，例如，如图1所示的终端来执行。该方法包括如下步骤。

步骤210，在应用程序运行至核心场景的情况下，启动自适应服务获取终端的设备性能状态；核心场景包括应用程序中对运行性能要求高于阈值的运行场景。

示例性的，该方法由终端执行，或者，该方法由终端上运行的应用程序执行，或者，该方法由终端上运行的应用程序的客户端执行。

核心场景是应用程序中需要保证运行性能的运行场景。核心场景包括预先设置的应用程序中的至少一个场景。应用程序在运行过程中会根据预先设置的判定条件，实时判定当前运行场景是否为核心场景。

例如，当应用程序为游戏应用程序时，核心场景可以是指玩家进入特定游戏状态或进行一系列特定游戏玩法操作后的场景。核心场景可以人为定义，例如，核心场景可以为：某游戏PVP（Player Versus Player，玩家对战玩家）战斗十五分钟以上爆发的团战时刻、连续PVE（Player Versus Enviroment，玩家对抗环境）战斗5场后的结束场景、挂机3倍速自动战斗1小时后的场景。

再如，当应用程序为视频应用程序时，核心场景可以是指播放电影类视频的场景。或者，核心场景可以是使用4K分辨率播放视频的场景。

再如，当应用程序为办公应用程序时，核心场景可以是指当前打开的文档数量大于数量阈值的场景。

基于上述举例可知，每个核心场景都对应判定条件，应用程序可以根据判定条件确定当前是否处于核心场景。

其中，步骤210中所说的运行性能要求高于阈值，可以是开发者的主观判断，当开发者主观判断某一场景的运行性能要求较高时，可以将该场景添加为核心场景，在核心场景的判定条件中加入该场景的判定条件。或者，步骤210中所说的运行性能高于阈值，也可以是应用程序判断核心场景的方式。例如，应用程序可以根据预设公式实时计算当前场景的运行性能要求分数，当运行性能要求分数高于阈值时，确定当前场景为核心场景。

可选的，核心场景为自适应服务的触发场景。在核心场景下，应用程序需要触发自适应服务，来根据终端的设备性能状态自适应调整应用程序的运行参数。因此，开发人员可以将需要触发自适应服务的场景定义为核心场景，在应用程序中预置核心场景的判定逻辑，在满足判定逻辑后应用程序确定当前处于核心场景。

可选的，自适应服务是在应用程序中定义的，被添加到系统服务（Server）中的一种系统服务。自适应服务用于采集终端的状态数据，并向应用程序提供终端的状态数据。

或者，应用程序集成了性能改进SDK，自适应服务是在性能改进SDK中定义的，在性能改进SDK初始化时被添加至系统服务中，在操作系统的进程中运行。自适应服务用于采集终端的状态数据，并向性能改进SDK提供终端的状态数据。性能改进SDK可以根据状态数据计算设备性能状态，向应用程序提供设备性能状态。

性能改进SDK用于实现终端的设备性能状态获取功能，应用程序可以通过性能改进SDK获取到终端的设备性能状态，并根据设备性能状态执行运行参数的自适应调整。

设备性能状态用于描述终端的运行状态。设备性能状态是与终端的运行新能相关的状态数据。

设备性能状态可以包括操作系统直接提供的状态数据，设备性能状态也可以包括基于操作系统直接提供的状态数据计算得到的数据。

当设备性能状态包括基于状态数据计算得到的数据时，设备性能状态的计算方式可以由应用程序定义，应用程序开发人员可以根据需求定义设备性能状态的计算方式，使性能改进SDK基于直接获得的状态数据按照指定计算方式计算得到设备性能状态。

设备性能状态包括以下至少一个：CPU（Central Processing Unit，中央处理器）的负载率、GPU（Graphics Processing Unit，图形处理器）的负载率、内存占用情况、电池参数、温度参数、线程数据、图形数据；其中，电池参数包括以下至少一种：电池容量、充电速度、放电速度、电池温度；温度参数包括以下至少一种：CPU温度、电池温度、环境温度、电源管理器温度。

其中，操作系统能够直接提供的状态数据可以包括以下至少一种：CPU型号、CPU当前的工作频率、CPU的每个CPU核上运行的线程数量、每个线程在CPU核上的运行时间、可用的GPU调度算法列表、GPU繁忙状态、当前GPU时钟频率、当前GPU调度算法、GPU可达的最大时钟频率、GPU可达的最小时钟频率、GPU型号、GPU纹理单元的数量、系统总内存、当前可用内存、电池容量、充电速度、放电速度、电池温度、CPU温度、电池温度、环境温度、电源管理器温度、线程负载情况、核心线程的CPU核调度频次、核心线程在CPU核上的累计运行时。

根据状态数据计算得到的设备性能状态可以包括以下至少一种：CPU负载率、GPU负载率、内存占用情况。

步骤220，根据设备性能状态，自适应调整应用程序在核心场景下的运行参数。

应用程序在获取到设备性能状态后，可以根据设备性能状态有针对性地调整运行参数。

示例性的，设备性能状态与运行参数具有关联关系，应用程序可以根据存在异常的设备性能状态，来调整该设备性能状态所对应的运行参数，以使该设备性能状态恢复正常。

示例性的，具有关联关系的设备性能状态和运行参数，还可以对应有调整策略，不同的设备性能状态和运行参数可以对应不同的调整策略，应用程序可以按照对应的调整策略来调整运行参数。

例如，设备性能状态和运行参数具有关系函数，应用程序可以按照关系函数中所指示的关联关系，将运行参数按照会使设备性能状态恢复正常的调整方向上调整。

示例性的，运行参数包括以下至少一种：分辨率、画面质量、图形质量、物理效果质量、音效质量、帧数、帧率、画面特效质量。

以游戏应用程序为例，（1）分辨率、画质设置、图形质量：决定了游戏的图像质量，影响着游戏画面的清晰度、细节和真实感。更高的分辨率、更高的画质、更高的图形质量可以提高游戏的视觉效果。

（2）游戏内物理效果质量：游戏内的物理效果包括角色的动作、场景的变化等。较高质量的物理效果会增加游戏的真实感。

（3）游戏内音效质量：游戏内音效质量会影响游戏的声音效果。较高的音效质量通常会提高游戏的真实感，让玩家有更好的游戏听觉体验。

（4）游戏帧数/帧率：帧率是指每秒钟游戏画面更新的次数，更高的帧率会提高游戏的流畅度和响应速度。

（5）游戏内画面特效质量：游戏内的画面特效包括雾、反射、阴影等等。开启这些特效或较高的特效质量可以提高游戏的视觉效果，给玩家带去更好的视觉体验。

例如，GPU负载率可以对应分辨率、画面质量、图形质量等运行参数，当GPU负载率存在异常时，应用程序可以通过降低分辨率、降低画面质量、降低图形质量等运行参数调整操作来降低GPU负载，保证应用程序在核心场景下的流畅运行。

再如，基于帧级别的优化。当游戏温度、电流值均正常，利用本申请提供的自适应调整方式，当提前预警到游戏瞬时高负载场景时，游戏可以及时应对，平衡游戏性能：或提升系统性能供给，或降低游戏负载。从而改善掉帧，保障游戏画面的流畅性。

再如，基于温度变化曲线的优化。当游戏运行中负载过高、温升过快时，利用本申请提供的自适应调整方式，当检测到终端设备温度过高时：可以调整游戏性能指标，降低游戏负载，使温度下降或保持在正常范围内。从而让用户设备在玩游戏的过程中始终处于正常温度的平衡状态，防止过热，保障游戏整体的资源效果呈现质量；防止温度过高给设备硬件带来损耗；防止终端发烫给玩家带来不好的体验。

再如，基于电流值的优化。底层系统提供基准的电流值与当前实际电流值，当游戏运行中电流值持续超出基准电流值一定程度时，会导致设备的功耗上升，温度也会随之上升，利用本申请提供的自适应调整方式，可以针对性优化导致电流值过大的进程。从而降低功耗，增加游戏整体可玩时长；防止过热，保证设备状态正常、游戏进程正常运行。

再如，基于CPU/GPU负载的优化。根据底层实时提供的CPU/GPU性能供给标准和使用率，调节游戏性能指标，从而降低负载或稳定负载。从而使设备性能供给更合理，性能利用率更高。

步骤230，在核心场景结束的情况下，关闭自适应服务。

示例性的，当应用程序识别到核心场景结束时，可以关闭自适应服务，不再根据设备性能状态自适应调整运行参数。其中，关闭自适应服务可以是指关闭自适应服务的运行进程。

在一种可选的实施例中，关闭自适应服务后，应用程序可以将运行参数恢复至自适应服务开启前的状态。例如，在进入核心场景开启自适应服务前，分辨率为1080p，在进入核心场景开启自适应服务后，分辨率被自适应调整为480p，则当核心场景结束关闭自适应服务后，应用程序可以自动将分辨率恢复至1080p。

可选的，应用程序可以在关闭自适应服务后，继续沿用自适应服务所调整的运行参数。

综上所述，本实施例提供的方法，当应用程序运行至关键的核心场景时，为了保证核心场景的运行性能，可以自动开启自适应服务，通过自适应服务获取到终端的设备性能状态，基于终端的运行状态来自适应调整应用程序的各个运行参数，使应用程序可以基于终端的设备性能状态有针对性地调整运行参数。例如，当终端的某一设备性能状态较差时，对应降低与该设备性能状态相关的运行参数，以减轻该设备性能的负载；当终端的某一设备性能状态较佳时，可以适当提升与该设备性能状态相关的运行参数，以提升核心场景的用户体验。该方法可以在应用程序运行至核心场景时，自动根据终端的设备性能状态对运行参数进行自适应调整，避免核心场景的运行卡顿，提高核心场景的运行效果。当核心场景结束后，还可以自动关闭自适应服务，降低应用程序的运行负载。

示例性的，给出一种使用性能改进SDK实现运行参数的自适应调整的实施例。

图3示出了本申请一个示例性实施例提供的应用程序的运行方法的流程图。该方法可以由终端来执行，例如，如图1所示的终端来执行。基于图2所示实施例，步骤210可以包括步骤211和步骤212。

步骤211，在应用程序运行至核心场景的情况下，性能改进SDK启动自适应服务，获取终端的状态数据；自适应服务是用于采集状态数据的系统服务；状态数据是由终端的操作系统直接提供的数据。

终端中运行有应用程序，应用程序集成了性能改进SDK。性能改进SDK是封装的工具包，可以在任意应用程序中集成，以实现运行参数的自适应调整功能。性能改进SDK可以实现与操作系统的通信，从操作系统获取终端的状态数据或设备性能状态，并向应用程序提供获取到的状态数据或设备性能状态。

性能改进SDK用于从操作系统获取终端的设备性能状态，向应用程序提供终端的设备性能状态。

或者，性能改进SDK用于从操作系统获取终端的状态数据，并按照应用程序的需求基于状态数据计算设备性能状态，向应用程序提供终端的设备性能状态。

性能改进SDK还可以称为TGPA（Tencent Game Performance Amelioration，Tencent游戏性能改进）SDK。

性能改进SDK中定义了自适应服务。在性能改进SDK初始化过程中，性能改进SDK可以将自适应服务添加至系统服务（Sever）中，自适应服务可以由性能改进SDK控制开启和关闭。当性能改进SDK开启自适应服务，操作系统将运行自适应服务；当性能改进SDK关闭自适应服务，操作系统将关闭自适应服务。

示例性的，应用程序在检测到核心场景后，可以调用性能改进SDK开启自适应服务。

自适应服务开启后，自适应服务可以通过共享内存向性能改进SDK传递终端的状态数据，参见图4，步骤211可以包括步骤211-1至步骤211-5。

步骤211-1：在应用程序运行至核心场景的情况下，性能改进SDK启动自适应服务。

操作系统运行自适应服务。可选的，操作系统的自适应服务通过鉴权，向性能改进SDK返回代理对象的引用。代理对象用于建立性能改进SDK与自适应服务间的通信。鉴权用于校验性能改进SDK的数据通信权限。

步骤211-2：性能改进SDK向自适应服务发送共享内存创建请求；自适应服务用于响应于共享内存创建请求创建共享内存，共享内存用于存储采集到的状态数据。

示例性的，自适应服务在接收到共享内存创建请求后，创建共享内存，得到共享内存的FD（File Descriptor，文件描述符）。

在共享内存创建后，自适应服务可以自动采集终端的状态数据，向共享内存写入状态数据。示例性的，自适应服务可以周期性地向共享内存写入状态数据，以保证共享内存中状态数据的实时性。

步骤211-3：性能改进SDK向自适应服务发送共享内存查询请求。

共享内存查询请求用于请求获取共享内存的文件描述符。

自适应服务接收到共享内存查询请求后，向性能改进SDK发送共享内存的文件描述符。示例性的，自适应服务通过代理对象的接口向性能改进SDK发送共享内存的文件描述符。

步骤211-4：性能改进SDK接收自适应服务返回的共享内存的文件描述符。

步骤211-5：性能改进SDK根据共享内存的文件描述符，从共享内存中读取终端的状态数据。

示例性的，自适应服务用于采集终端的状态数据、向共享内存写入状态数据。

性能改进SDK可以周期性地从共享内存中读取状态数据。例如，性能改进SDK每隔100ms从共享内存中读取一次状态数据。

在一种可选的实施例中，步骤210之前还包括应用程序的初始化过程。参见图4，步骤210之前还包括步骤201至步骤203。

步骤201：在应用程序的初始化阶段，应用程序初始化性能改进SDK，将自适应服务添加至系统服务中。

步骤202：性能改进SDK向性能改进服务器发送能力询问请求，能力询问请求携带有终端的设备信息和应用程序的当前版本。

能力询问请求用于请求性能改进服务器查询：自适应服务是否支持在该设备、该应用程序的当前版本中使用；以及，应用程序的当前版本是否支持自适应服务。以便于性能改进SDK判断能否开启自适应服务。

性能改进服务器根据设备信息和应用程序的当前版本，查询自适应服务是否支持在该设备、该应用程序的当前版本中使用，以及，应用程序的当前版本是否支持自适应服务，并向性能改进SDK返回查询结果。

步骤203：性能改进SDK接收性能改进服务器返回的能力询问结果，能力询问结果包括第一指示信息和第二指示信息，第一指示信息用于指示自适应服务在终端和应用程序的当前版本中是否开启，第二指示信息用于指示应用程序的当前版本是否支持自适应服务。

若第一指示信息指示“是”，则表示自适应服务支持在终端以及应用程序的当前版本中使用；指示“否”则表示自适应服务不支持在该终端中使用，或者，自适应服务不支持在应用程序的当前版本中使用，或者，自适应服务不支持在该终端中使用、也不支持在该应用程序的当前版本中使用。

若第二指示信息指示“是”，则表示应用程序的当前版本支持自适应服务；第二指示信息指示“否”，则表示应用程序的当前版本不支持自适应服务。

如此，性能改进SDK可以根据第一指示信息和第二指示信息判断能否开启自适应服务。只有在第一指示信息指示“是”且第二指示信息指示“是”的情况下，性能改进SDK才能够在核心场景中开启自适应服务。

即，在应用程序的当前版本支持自适应服务，自适应服务支持在终端和应用程序的当前版本中使用，且应用程序运行至核心场景的情况下，启动自适应服务。

步骤212，应用程序调用性能改进SDK的数据获取接口获取终端的设备性能状态，设备性能状态是性能改进SDK基于状态数据计算得到的。

应用程序可以通过调用性能改进SDK来获取终端的设备性能状态。

设备性能状态可以包括根据状态数据计算得到的数据，即，性能改进SDK可以提供自定义的设备性能状态，自定义的设备性能状态由性能改进SDK按照自定义的计算方式，根据直接获取到的状态数据计算得到。

其中，自定义的设备性能状态可以采用以下两种方式确定其计算方式。

方式1：由性能改进服务器提供自定义的设备性能状态的默认计算方式。

参见图4，步骤203可以包括步骤203-1，步骤212可以包括步骤212-2。

步骤203-1，性能改进服务器向性能改进SDK返回能力询问结果和配置信息，配置信息包应用程序对应的设备性能状态的默认设置信息。

步骤212-2：应用程序调用性能改进SDK的数据获取接口请求获取终端的设备性能状态；性能改进SDK按照设备性能状态的默认设置信息，基于状态数据计算设备性能状态，向应用程序返回设备性能状态。

默认设置信息包括以下至少一种信息：设备性能状态的计算指标、计算指标对应的计算方式、计算结果的数据类型、计算结果的数据格式。

即，性能改进服务器在查询到应用程序的当前版本支持自适应服务时，还可以同时获取应用程序的当前版本所对应的设备性能状态的默认设置信息。默认设置信息包括设备性能状态的获取策略，例如，默认设置信息用于指示该应用程序需要获取的设备性能状态的计算指标，以及该计算指标的计算方式。性能改进服务器在返回能力询问结果时，可以携带该默认设置信息，以便于性能改进SDK可以根据该默认设置信息为应用程序提供其所需要的设备性能状态。

方式2：由应用程序提供自定义的设备性能状态的计算方式。

应用程序可以调用性能改进SDK来设置自定义的设备性能状态的计算指标、计算方式等，来使性能改进SDK提供应用程序所感兴趣的设备性能状态。

参见图4，步骤212可以包括步骤212-1。

步骤212-1：应用程序调用性能改进SDK的数据设置接口修改设备性能状态的设置信息。性能改进SDK向应用程序返回设置结果和设备性能状态，设备性能状态是按照设置信息基于状态数据计算得到的。

设置信息包括以下至少一种信息：设备性能状态的计算指标、计算指标对应的计算方式、计算结果的数据类型、计算结果的数据格式。

应用程序可以通过调用数据设置接口，来修改性能改进SDK所需要返回的设备性能状态。例如，应用程序可以新增一个设备性能状态，并设置该设备性能状态的计算方式。或者，应用程序可以删除原有的一个设备性能状态，使性能改进SDK后续无需再反馈该设备性能状态。示例性的，步骤212-1为可选步骤。

或者，可以结合上述方式1和方式2，由性能改进服务器预先指示设备性能状态的默认设置信息。然后，应用程序在需要更改所需的设备性能状态时，可以通过调用数据设置接口修改设备性能状态的默认设置信息得到新的设置信息，随后按照新的设置信息向应用程序返回设备性能状态。

如此，针对不同的应用程序，不同的应用程序的版本，性能改进SDK可以按照应用程序的需求，或者当前版本的需求，按需为其提供不同的设备性能状态，并且可以实时更新所能提供的设备性能状态，以使性能改进SDK可以满足不同应用程序、不同版本的多方位需求。

可选的，以CPU为例，设备性能状态可以包括CPU负载率。设置信息中可以包括计算指标“CPU负载率”，计算方式“CPU负载率=核心线程（一个或多个）在该CPU核的运行时间/CPU核的统计周期*100%”。则性能改进SDK计算核心线程在CPU核的运行时间除以CPU核的统计周期的百分比，得到CPU的负载率。

或者，以GPU为例，设备性能状态可以包括GPU负载率。设置信息中可以包括计算指标“GPU负载率”，计算方式“GPU负载率=GPU执行任务的时间/GPU负载统计周期时长*100%”。则性能改进SDK计算GPU执行任务的时间除以GPU负载统计周期的百分比，得到GPU的负载率。

当应用程序想要修改“GPU负载率”的计算方式时，就可以通过调用数据设置接口，来修改“GPU负载率”对应的计算方式，在修改完成后，性能改进SDK就会按照新的计算方式计算“GPU负载率”。

步骤220，根据设备性能状态，自适应调整应用程序在核心场景下的运行参数。

应用程序可以按照预设的策略来根据设备性能状态自适应调整运行参数。

应用程序也可以按照预设的调整函数来根据设备性能状态自适应调整运行参数。

应用程序还可以调用神经网络模型来根据设备性能状态确定运行参数的调整方式。

例如，应用程序可以将设备性能状态输入自适应调整模型，输出待调整指标和待调整指标对应的待调整量；自适应调整模型用于根据输入的设备性能状态输出运行参数的调整策略，待调整指标用于指示待调整的运行参数，待调整量用于指示待调整的运行参数的调整方式；根据待调整量，调整待调整指标所指示的运行参数。

示例性的，调整方式包括调整方向和调整幅度。待调整量包括正负号以及调整数值，其中，正负号用于指示调整方向（增加或减少），调整数值用于指示调整幅度。例如，待调整量为+10，则根据待调整量所指示的调整方式可以将原数值20调整为20+10=30。再如，待调整量为-20，则根据待调整量所指示的调整方式可以将原数值20调整为20-20=0。

需要说明的是，由于不同设备型号的终端，其运行性能的评价标准不一，性能改进服务器可以在反馈能力询问结果时，一并携带该终端的设备型号所对应的性能评价标准，使性能改进SDK向应用程序反馈该性能评价标准。如此，应用程序就可以按照当前终端所对应的性能评价标准来评价设备性能状态，以便于在设备性能状态不佳时及时调整运行参数。

其中，各个设备型号对应的性能评价标准可以是性能改进服务器从对应生产厂商处获得的。

应用程序的性能标准是什么，比如如何设置CPU占比阈值、内存占用阈值是最合适的，不同的应用程序、不同档位的终端，其CPU、内存占用完全不一样，可能不是一个量级，很难有统一的标准。

以内存为例：Android（安卓）平台对单个进程没有特别限制，只要VirtulMemory（虚拟存储）不超过进程地址空间（一般是4G），系统剩余内存RAM（Random Access Memory，随机存储器）不低于LKM（Loadable Kernel Modules，可加载内核模块），进程就不会OOM（Out Of Memory，内存溢出）。

iOS平台相对复杂，对进程有资源限制，与单个进程FootPrint Limit（1G内存，maxFootPrint=650MB，2G内存，maxFootPrint=1400MB）及系统剩余RAM都有关系。

因此，理论上只要应用程序不OOM，内存占用多少都可以。但实际上，内存占用过大会影响整机内存及性能，内存占用原则上是越小越好。

综上，应用程序的性能评价标准更多的依赖于应用程序在特定型号终端上的测试表现。例如，参考图5为一种游戏性能表现的衡量标准。对于iOS终端11，一档机型需要满足：内存消耗PeakFootPrints≤850MB、帧率≥25FPS；二挡机型需要满足：内存消耗PeakFootPrints≤650MB、帧率≥25FPS；三档机型需要满足：内存消耗PeakFootPrints≤500MB、帧率≥18FPS；同时CPU占有率应满足综合CPU平均占用小于80%，单核CPU峰值占用小于90%。对于安卓终端12，一档机型需要满足：内存消耗最高PSS≤1200MB、帧率≥25FPS；二挡机型需要满足：内存消耗最高PSS≤1000MB、帧率≥25FPS；三档机型需要满足：内存消耗最高PSS≤800MB、帧率≥18FPS；同时CPU占有率应满足综合CPU平均占用小于60%，单核CPU峰值占用小于90%。

在真实场景下，要根据特定应用程序具体看其在某种机型上的性能测试表现，来作为其真实的性能数据。不同设备、不同应用程序，其性能评测都需要一定数量的实测，而不能用过往经验简单得出。当有了一定数量的测试数据之后，可以将当前终端设备对应映射到图5中的安卓/iOS的机型档位，之后参考该档位的机型性能标准对所测试的特定应用程序在某种机型上的性能表现做出评价。

例如，表1是某MOBA（Multiplayer Online Battle Arena，多人在线战术竞技游戏）游戏单场PVP在某Android三档机型上的性能数据的测试用例统计情况。

从表1中可以看出，该终端的“PSS内存”不满足图5中给出的安卓三档机型的判定指标。

步骤230，在核心场景结束的情况下，关闭自适应服务。

综上所述，本实施例提供的方法，可以通过调用性能改进SDK，来获取终端的设备性能状态。性能改进SDK可以通过开启自适应服务，来使自适应服务自动采集终端的状态数据，并将状态数据写入共享内存。性能改进SDK可以直接从共享内存中读取终端的状态数据，并向应用程序返回其所需的设备性能状态，使应用程序可以通过性能改进SDK来获取到终端的底层数据，利用终端的设备性能状态来自适应调整应用的运行参数，保证应用程序在核心场景下的运行效果。

示例性的，给出一种在游戏应用程序中使用本申请实施例提供的应用程序的运行方法的示例性实施例。

图6示出了本申请一个示例性实施例提供的应用程序的运行方法的流程图。该方法可以由计算机系统来执行。计算机系统包括：终端中的应用程序、终端中的操作系统、应用程序中的性能改进SDK，以及性能改进服务器；其中，终端可以是如图1所示的终端，性能改进服务器可以是如图1所示的服务器，应用程序可以是游戏应用程序，性能改进SDK可以是TGPA、性能改进服务器可以是TGPA服务器。该方法包括以下步骤。

步骤601，游戏应用程序初始化TGPA。

步骤602，TGPA请求TGPA服务器，查询TGPA侧针对该游戏应用程序的自适应能力是否开启，以及该游戏应用程序的当前版本是否支持自适应服务。

步骤603，TGPA服务器向TGPA返回针对该游戏应用程序的自适应能力开关状态以及游戏应用程序的当前版本对自适应服务的支持状态。

游戏应用程序在初始化阶段初始化TGPA SDK。TGPA在初始化过程中用游戏版本信息以及设备信息（设备型号、系统版本等）请求TGPA服务器，TGPA后台向TGPA返回：（1）针对该设备型号、该游戏版本是否支持自适应能力的TGPA开关状态。若为开，则表示TGPA可以在游戏内的核心场景中为游戏提供自适应服务；若为关，则表示TGPA不支持该设备上该游戏的自适应能力，后续游戏内就不会有自适应的系列步骤。（2）当前游戏版本是否支持自适应能力。当游戏不支持自适应能力时，不会有后续自适应的系列步骤；当游戏支持自适应能力，在向TGPA返回支持状态的同时，还会向 TGPA返回游戏对自适应能力的需求，以下为两个示例：

例1：游戏支持自适应能力，且需要通过CPU、GPU这两个设备指标来对游戏参数进行自适应调整，从而影响游戏功耗，达到最佳适配，暂不考虑其他设备指标。

例2：游戏支持自适应能力，且需要通过CPU、GPU、内存、电池、温度、线程、功耗等等这些设备指标的综合情况来对游戏参数进行综合性调整。

在TGPA侧针对该游戏应用程序的当前版本开启自适应能力，且该游戏应用程序的当前版本支持自适应能力的情况下，继续执行以下步骤。

在游戏应用程序的运行过程中，执行核心与非核心场景的切换。当进入游戏应用程序的核心场景时，执行步骤604。

步骤604，TGPA开始服务，TGPA开启自适应服务。

步骤605，操作系统的自适应服务执行鉴权，并返回Binder（一种安卓操作系统中的进程间通信机制）代理对象的引用。

当TGPA侧针对该游戏开启自适应能力且该游戏版本支持自适应服务时，可以继续执行步骤603之后的步骤。当游戏运行中（可能在核心与非核心场景之间切换）进入游戏核心场景（需要启动自适应服务保障游戏性能的场景）时，TGPA开启自适应服务，操作系统的自适应服务通过鉴权（TGPA与各厂商共同约定的数据通信权限校验）并向TGPA返回Binder代理对象的引用。

使用Binder对象建立TGPA与Android系统自适应service之间的通信的过程如图7所示。根据图7可知，使用Binder进行通信涉及4个角色：TGPA 701、操作系统的自适应服务702、ServerManager（服务管理）703和Binder驱动704。操作系统中的Binder实体对象先将自己的引用注册到ServerManager，TGPA通过特定的key（键）和这个引用进行绑定，ServerManager内部维护一个类似MAP（映射）的查找表来一一对应。下次TGPA再请求时，通过注册的key就可以向ServerManager获取到操作系统中Binder的引用。Binder作为操作系统中的一个实体对象，也提供一系列的对象方法来实现操作系统自适应服务和TGPA之间的通信，只要TGPA拿到Binder的引用或者一个有着这些方法的代理对象的引用，就可以进行通信。根据图7可知，TGPA想要向ServerManager直接请求Binder对象的引用，但通过Binder驱动层的处理之后，返回给TGPA了一个代理对象。实际上，如果TGPA和操作系统的自适应服务处于同一个进程，返回的就是当前Binder对象，但此处TGPA和操作系统的自适应服务不处于同一个进程，返回给TGPA的是一个代理对象。

步骤606，TGPA请求自适应服务创建共享内存。

步骤607，自适应服务创建共享内存，得到共享内存的FD。

TGPA请求自适应服务创建一块共享内存，自适应服务创建共享内存后，得到FD（File Descriptor，文件描述符）。

步骤608，TGPA向自适应服务查询共享内存的FD。

步骤609，自适应服务将共享内存的FD通过Binder接口传递给TGPA。

步骤610，TGPA根据共享内存的FD执行mmap（Memory Map，内存映射）。

TGPA向自适应服务查询共享内存的FD，自适应服务将共享内存FD 通过Binder接口传递给TGPA（此处TGPA的FD和自适应服务的FD不是同一个，但它们都指向同一块数据），之后TGPA根据该FD做mmap将共享内存映射到进程的地址空间。

随后，自适应服务正式运行。

步骤611，自适应服务采集底层设备指标数据（状态数据）并写入共享内存。

步骤612，游戏应用程序通过TGPA native（本地）接口设置/读取共享内存中的数据（实时的底层设备指标数据）。

步骤613，TGPA向游戏应用程序返回设置结果/共享内存中的底层设备指标数据。

步骤614，游戏应用程序根据底层设备指标数据进行游戏参数调整，平衡游戏应用程序的性能。

自适应服务采集底层设备指标数据并写入共享内存，游戏应用程序通过TGPAnative接口设置/定时读取共享内存中的数据（底层设备指标数据），得到返回之后，游戏应用程序根据该底层设备指标数据进行游戏参数调整，平衡性能。

步骤615，当该自适应服务不再需要使用时，TGPA会通知操作系统停止运行自适应服务并销毁。

当离开核心场景时，该自适应服务不再使用，TGPA会通知操作系统停止运行自适应服务并销毁。

需要说明的是，根据图6中最外层的循环可发现，在每次进入游戏核心场景时，都会执行开启自适应服务、建立共享内存……的步骤，在离开游戏核心场景时，TGPA会通知操作系统关闭自适应服务 ，在下一次进入游戏核心场景的时候再开启自适应服务，以此类推，达到自适应能力按需开启与关闭的效果。

下面分别对CPU、GPU、内存、电池、温度、线程数据等底层设备指标数据（设备性能状态）进行说明。

1、CPU

示例性的，可以用核心线程（例如，影响游戏UI（User Interface，用户界面）/FPS（Frame Per Second，画面每秒传输帧数）的线程，如主线程、渲染线程、RHI（RenderHardware Interface Thread，渲染硬件接口线程）线程等等）的CPU负载率来衡量CPU的负载情况。

例如，设备性能状态可以包括核心线程的CPU负载率，其计算公式如下：

核心线程的CPU负载率=核心线程（一个或多个）在该CPU核的运行时间/CPU核的统计周期*100%。

其中，核心线程（一个或多个）在该CPU核的运行时间，统计的是有核心线程正在运行的时间间隔，无论在该时间间隔内有几个核心线程在运行，也都只统计一次当前运行时间，不做时间的累计。

其中，统计周期一般为100ms（毫秒），可由上层应用动态调控。统计周期最小为一帧时间，最大为2s。当统计周期为100ms时，建议每隔100ms操作系统向共享内存写一次所有需要的设备指标数据（状态数据），此时，游戏应用程序也建议在核心场景中每100ms调用一次TGPA（Tencent Game Performance Amelioration，Tencent游戏性能改进）SDK（性能改进SDK）的接口获取设备指标数据。由于操作系统也有调度周期，可能每隔一定时间（例如n毫秒，n为任意值）就要改变一下大中小核的频率，因此可以以100ms为最小统计周期，在这个时间间隔内计算某个CPU核的负载率。

以上给出了一个CPU核（CPU核心）的负载率计算方式，而在一个CPU内部，可能有几个大核、几个中核、几个小核（例如，部分终端上的处理器采用1个大核、3个中核、4个小核的结构），多核的综合负载可以表征CPU的整体负载，当CPU所有核心的负载都位于其正常范围内时，可以通过权重累加的方式，认为所有核心权重平均，最终得到多核CPU的整体负载；而当CPU中有某个核心的负载已经超过临界值（不堪重负），该核心的权重会成倍放大，从而表示CPU整体负载过高（此处认为操作系统的调度策略等均表现优秀，处于理想状态），游戏参数应该为其调整，从而平衡游戏性能。

同样地，可以用运行时间占比最大的Top N线程在CPU的运行时间占比，来估算游戏应用程序中Top N线程的功耗占比。

2、GPU

示例性的，可以用GPU执行任务的时间在一个统计周期内的时间占比来衡量GPU的负载情况：

GPU负载率=GPU执行任务的时间/GPU负载统计周期时长*100%。

通常，GPU负载率数据存储在终端的特定文件中，且终端的所有GPU数据总存储在一个特定文件夹，该文件夹中的文件记录了终端GPU的各种参数。

例如，以存储在第一终端“/sys/kernel/gpu”目录（不同机型的CPU数据存储目录可能不同，该目录仅为例子中的第一终端）下的GPU参数为例，如图8所示，第一数据401是GPU数据在第一终端上的存储路径；第二数据402是第一终端上所存储的GPU数据文件，参见表2，分别对GPU文件夹中的文件所描述的GPU数据作出了相应解释。

在表2中，gpu_busy文件中的数据为可以用于计算GPU负载情况，结合表2中的其他GPU参数数据，可以指示该GPU的整体性能情况。

当某种游戏应用程序在某种机型（GPU型号相同）上批量实测时，可以划分一个使游戏表现最佳的gpu_busy数值，该数值取决于游戏应用程序和硬件的特定要求和限制。通常，较高的gpu_busy值可以提高GPU的利用率和性能、提高游戏的帧率和图形效果，但也可能导致能耗和温度升高，甚至引起稳定性问题。因此，需要进行机型实测来确定最佳的gpu_busy值，以平衡性能和能源效率，实现最佳的游戏性能和体验。一般来说，可以从较低的gpu_busy值开始，例如50-70％，然后逐步增加，从而找到使设备状态以及游戏表现均达到最佳的gpu_busy值域。

当有了最佳gpu_busy值域，当用户在终端上使用游戏应用程序并进入触发自适应服务的核心场景时，若低于gpu_busy值域的最小值，则表示可以适当提高游戏帧率或者游戏图形效果的品质，为玩家带去更高品质的体验；若高于gpu_busy值域的最大值，则表示游戏需要适当降低游戏帧率或者游戏图形效果的品质，从而让gpu_busy值稍微降低从而映射到最佳值域范围，即让终端的GPU利用率达到最佳，防止设备能耗过高，防止电池温度过高，也是为游戏应用程序的稳定性保驾护航。

在考虑GPU整体功耗的同时，也可以对其功耗进行拆解分析：

例如，拆解GPU渲染的关键流程为四个阶段，每个阶段中的处理过程还可以继续拆解（通过计算每个阶段的耗时等占比，来估算GPU的功耗占比）：

阶段一：应用程序将渲染命令发送给GPU。这些命令通常包括几何数据、纹理、着色器程序等信息。

阶段二：GPU收到渲染命令后，通过一系列的管线将几何数据转化为屏幕上的像素。该过程通常包括顶点处理、图元装配、光栅化等。

阶段三：像素处理阶段，GPU根据着色器程序对每个像素进行颜色计算。该过程通常包括片元着色、纹理采样、深度测试等。

阶段四：GPU将渲染结果输出到帧缓冲区，并将其传输到显示设备上显示。

3、内存

示例性的，可以用“内存使用率”来衡量终端一段时间间隔的内存使用情况，例如，参见表3，使用操作系统提供的MemoryInfo（内存信息）类来表示内存使用率。

其中，totalMem表示系统总内存，availMem表示当前可用内存。通过计算totalMem和availMem之间的差值，就可以得到当前系统的内存使用量。再将其除以totalMem，就可以得到内存使用率。

需要注意的时，这里计算的是整个系统的内存使用率，而不是单个应用程序的内存使用率。如果需要计算单个应用程序的内存使用率，可以使用ActivityManager的getProcessMemoryInfo()方法获取指定进程的内存信息，并根据该进程使用的内存和总内存之间的比率来计算内存使用率。

需要说明的是，不推荐使用PSS（Proportional Set Size，实际使用的物理内存）/VSS（Virtual Set Size，虚拟内存）*100%来表示内存使用率。

内存使用率通常是用可用内存和总内存之间的比率来计算的。PSS和VSS不能直接用于计算内存使用率，因为操作系统还会使用缓存和预加载机制，这些机制的存在可能导致PSS和VSS之间存在重叠，这会导致使用率计算出现误差。所以想要准确地计算应用程序的内存使用率，还是需要使用操作系统提供的MemoryInfo类，或者使用第三方库如Android-DFN等来获取更准确的内存使用信息。

结合图9对PSS、VSS进行说明。其中，PSS对应图9中的单个进程按比例分配的占用内存502、进程占用的内存503（不包括已分配但未使用的内存504），是单个进程运行时实际占用的物理内存，其中包含比例分配共享库（例如，一个共享库有N个进程使用，那么该库比例分配给 PSS 的大小为1/N）占用的内存，表示单个进程在系统总内存中的实际使用量。

VSS对应图9中的共享库占用内存501、单个进程按比例分配的占用内存502、进程占用的内存503、已分配但未使用的内存504，是进程向系统申请的虚拟内存（包含共享库内存总数），即单个进程全部可访问的地址空间，其大小可能包括还尚未在内存中驻留的部分。

即使PSS和VSS不能直接用于计算内存使用率，但是PSS和VSS数值本身也从一定角度客观描述了终端的内存占用情况，可以为运行参数的优化提供终端的状态的参考。

在游戏应用程序的机型实测中，可以采用以下两种方式获取当前游戏应用程序的内存的使用情况，作为终端在运行某游戏应用程序时内存使用情况的参考。

方式一：参见表4，在操作系统的代码中获取游戏应用的内存使用情况：

其中：（1）Runtime.getRuntime().maxMemory()获取的是Java虚拟机进程可以使用的最大内存大小，但不包括共享库等非Java堆内存的占用。与VSS不同。VSS是指一个进程所能寻址的虚拟内存总大小，包括进程使用的所有内存，例如堆内存、栈内存、共享库、映射文件等。

（2）Runtime.getRuntime().totalMemory()获取的内存包括Java虚拟机进程使用的所有内存，包括Java堆内存、栈内存、方法区和共享库等。

（3）Runtime.getRuntime().freeMemory()获取的是Java虚拟机堆内存中当前空闲的内存大小，不包括共享库等非Java堆内存的占用。

参见表5，可以用以下函数输出上述变量结果：

得到表6中的变量结果：

参见表6，当前游戏应用程序在当前终端Java虚拟机进程可以使用的最大内存大小为128MB；现在已经分配的Java虚拟机进程使用的所有内存，包括Java堆内存、栈内存、方法区和共享库等内存约为9MB；Java虚拟机堆内存中当前空闲的内存大小约为3MB。

方式二：参见图10可以使用“adb shell dumpsys meminfo 包名”在终端中查看游戏应用程序进程的内存使用情况。

类似于gpu_busy，最佳的内存使用情况（或内存使用率）也取决于具体的游戏应用程序和终端的硬件配置。一般来说，较高的内存使用率可以提高游戏的图形效果和渲染速度，但也可能导致游戏性能下降或出现卡顿现象，甚至可能导致游戏崩溃。因此，我们也需要通过游戏应用程序在特定机型上的实测来确定最佳的内存使用情况，以实现最佳的游戏性能和体验。

通常，最佳的内存使用情况应该在硬件配置的限制范围内，并且应该避免出现内存泄漏或内存过度使用的情况。如果游戏需要大量的内存（指合理的理想状态下，此时游戏应用程序只使用所需的内存，且会及时释放不再使用的内存，但还是需要大量的内存）才能实现最佳性能，此时，升级到更高规格的内存可能是更好的解决方案。

4、电池

示例性的，可以考虑用表7中的电池的参数来评估终端对游戏性能的影响。

当电池容量较低（设备使用时间越长，其有效的电池容量会随时间降低）、充电速度较慢时，可以通过调整游戏帧率、关闭游戏中不必要的特效等等来降低游戏应用导致的设备功耗，从而保证更长的游戏时长（当然，通过调整屏幕亮度、关闭背景应用等非调整游戏参数的方式也可以降低功耗，但此处认为除游戏应用程序之外的其他设备状态、应用状态均处于理想状态，然后再来调整游戏参数从而平衡设备性能）。

以上指标是评估终端对游戏性能的影响的一部分，还需要结合其他因素，如处理器、显卡等硬件配置以及软件优化等因素来综合评估设备的游戏性能。

对于游戏应用程序来说，可以更好地支持游戏性能的最佳的电池状态应该是：高容量（电池容量越大，电池储存的能量就越多，可以支持更长时间的设备使用）、高放电效率（电池的放电效率越高，就可以更好地利用电池储存的能量，延长设备使用时间。通常锂离子电池放电效率一般在80%以上）、低自放电率（电池的自放电率越低，就可以更长时间地保持电量，延长电池寿命。通常锂离子电池自放电率一般在1%以下）、最好有快充支持（快充技术可以让电池更快地充满，为设备提供更长时间的使用时间）、高安全性（电池安全性是非常重要的指标，安全性好的电池可以避免电池爆炸或起火等问题）。

5、温度

如果终端的温度过高，会对设备的电池寿命和性能产生负面影响，同时还可能导致设备出现过热的情况，在游戏运行过程中影响玩家的游戏体验。

例如，参见表8是终端温度参数及其对应的最佳温度范围。

实际的最佳温度范围可能会因设备型号、环境条件和使用情况等因素而有所不同。因此，在使用终端时，应该注意保持设备在正常的工作温度范围内，避免过热或过冷对设备造成损害。

而当处理器或其他电子元件在达到设定的高温阈值时，会自动限制其运行速度以降低其温度，为了保护处理器或其他电子元件免受过热损坏的影响，所以有了“限频温度”：

当处理器或其他电子元件的温度超过限频温度时，系统会自动降低其时钟频率，以减少其功耗和热量产生，从而降低其温度。这可能会导致设备性能下降，但可以保护设备免受过热损坏的风险。不同的设备和处理器具有不同的限频温度，通常可以通过软件或硬件工具来查看设备和处理器的温度和限频情况。

由于不同的终端使用不同的处理器和电子元件，因此它们的限频温度可能会有所不同。例如，表9是一些常见终端的处理器和电子元件的限频温度范围。

但上例只是一般情况下的范围，具体的限频温度可能因设备型号、使用情况和环境条件而有所不同。在实际使用中，我们可以通过查看设备的手册或联系制造商以获取更详细的设备限频温度信息。

在设备本身限频温度的基础上，再考虑限频等级，一般来说，随着电池电量的下降，设备的限频等级会逐渐降低，CPU性能也会逐步降低。这样可以减少设备的功耗，从而延长电池寿命，但也可能会影响设备的响应速度和运行效率。限频等级可以通过操作系统的设置或第三方应用程序进行监测和管理，以便游戏侧可以了解设备的电池状态和性能水平，并采取适当的措施来优化设备的使用体验。

6、线程数据

游戏应用程序通过TGPA提供的接口向操作系统主动传入核心线程的TID（ThreadIdentifier，线程标识），此时操作系统会针对这些核心线程做调度策略的优先级保障。同时操作系统会统计各个核心线程的负载情况，以供应用层可以实时获取分析。

同时，操作系统还应统计以下两种异常情况的数据，可以辅助厂商进行调度策略的调整：

（1）核心线程从CPU大核往小核上的调度频次：用于统计异常调度频次，确定CPU调度异常情况。

（2）核心线程在小核上的累计运行时：核心线程长期运行在小核时会引发丢帧，确定CPU调度异常情况。

示例性的，给出一种共享内存中所写入的数据的定义。

{

"数据key": {

"name": "",// 数据描述

"start": 0,// 起始地址

"length": 8,// 数据长度

"type": "integer",// 数据类型, integer/boolean/string

"maximum": 100,// 数据值的最大值，由厂商决定

"minimum": 0,// 数据值的最小值，由厂商决定

}

}

例如，CPU_RUNNING_TIME = 10001事件的json数据描述定义为：

{

"10001": {

"name": "核心线程在全部CPU上运行时间在时间上的投影叠加，单位为%",// 数据描述

"start": 0,// 起始地址

"length": 8,// 数据长度

"type": "integer",// 数据类型, integer/boolean/string

"maximum": 100,// 数据值的最大值，由厂商决定

"minimum": 0,// 数据值的最小值，由厂商决定

}

}

示例性的，参见表10，给出几种自适应能力相关的API（Application ProgrammingInterface，应用程序编程接口）。

综上所述，本实施例提供的方法，游戏应用程序可以通过与TGPA SDK交互得到底层设备指标数据，并根据这些底层设备指标数据，有针对性地进行游戏参数调整，使游戏各项指标占用设备性能功耗更合理，达到游戏体验品质、游戏性能指标、设备运行最佳状态三者之间的平衡。

以下为本申请的装置实施例，对于装置实施例中未详细描述的细节，可以结合参考上述方法实施例中相应的记载，本文不再赘述。

图11示出了本申请的一个示例性实施例提供的应用程序的运行装置的结构示意图。该装置可以通过软件、硬件或者两者的结合实现成为终端的全部或一部分，该装置包括：

性能改进模块802，用于在所述应用程序运行至核心场景的情况下，启动自适应服务获取所述终端的设备性能状态；所述核心场景包括所述应用程序中对运行性能要求高于阈值的运行场景；

应用模块801，用于根据所述设备性能状态，自适应调整所述应用程序在所述核心场景下的运行参数；

所述性能改进模块802，用于在所述核心场景结束的情况下，关闭所述自适应服务。

在一种可选的实施例中，所述终端运行有所述应用程序，所述应用程序集成了性能改进软件工具开发包SDK；

所述性能改进模块802，用于启动所述自适应服务，获取所述终端的状态数据；所述自适应服务是用于采集所述状态数据的系统服务；所述状态数据是由所述终端的操作系统直接提供的数据；

所述应用模块801，用于调用所述性能改进SDK的数据获取接口获取所述终端的设备性能状态，所述设备性能状态是所述性能改进SDK基于所述状态数据计算得到的。

在一种可选的实施例中，所述性能改模块，用于启动所述自适应服务；

所述性能改进模块802，用于向所述自适应服务发送共享内存创建请求；所述自适应服务用于响应于所述共享内存创建请求创建共享内存，所述共享内存用于存储采集到的状态数据；

所述性能改进模块802，用于向所述自适应服务发送共享内存查询请求；

所述性能改进模块802，用于接收所述自适应服务返回的所述共享内存的文件描述符；

所述性能改进模块802，用于根据所述共享内存的文件描述符，从所述共享内存中读取所述终端的所述状态数据；

其中，所述自适应服务用于采集所述终端的所述状态数据、向所述共享内存写入所述状态数据。

在一种可选的实施例中，所述应用模块801，用于调用所述性能改进SDK的数据设置接口修改所述设备性能状态的设置信息；

所述应用模块801，用于调用所述性能改进SDK的数据获取接口获取所述终端的设备性能状态，包括：

所述性能改进模块802，用于向所述应用程序返回设置结果和所述设备性能状态，所述设备性能状态是按照所述设置信息基于所述状态数据计算得到的；

其中，所述设置信息包括以下至少一种信息：所述设备性能状态的计算指标、所述计算指标对应的计算方式、计算结果的数据类型、计算结果的数据格式。

在一种可选的实施例中，所述应用模块801，用于在所述应用程序的初始化阶段，初始化所述性能改进SDK，将所述自适应服务添加至系统服务中；

所述性能改进模块802，用于向性能改进服务器发送能力询问请求，所述能力询问请求携带有所述终端的设备信息和所述应用程序的当前版本；

所述性能改进模块802，用于接收所述性能改进服务器返回的能力询问结果，所述能力询问结果包括第一指示信息和第二指示信息，所述第一指示信息用于指示所述自适应服务在所述终端和所述应用程序的当前版本中是否开启，所述第二指示信息用于指示所述应用程序的当前版本是否支持所述自适应服务。

在一种可选的实施例中，所述性能改进模块802，用于在所述应用程序的当前版本支持所述自适应服务，所述自适应服务支持在所述终端和所述应用程序的当前版本中使用，且所述应用程序运行至所述核心场景的情况下，启动所述自适应服务。

在一种可选的实施例中，所述性能改进模块802，用于接收所述性能改进服务器发送的配置信息，所述配置信息包括所述应用程序对应的所述设备性能状态的默认设置信息；

所述应用模块801，用于调用所述性能改进SDK的数据获取接口请求获取所述终端的设备性能状态；

所述性能改进模块802，用于按照所述默认设置信息基于所述状态数据计算所述设备性能状态，向所述应用程序返回所述设备性能状态；

其中，所述默认设置信息包括以下至少一种信息：所述设备性能状态的计算指标、所述计算指标对应的计算方式、计算结果的数据类型、计算结果的数据格式。

在一种可选的实施例中，所述应用模块801，用于将所述设备性能状态输入自适应调整模型，输出待调整指标和所述待调整指标对应的待调整量；所述自适应调整模型用于根据输入的设备性能状态输出运行参数的调整策略，所述待调整指标用于指示待调整的运行参数，所述待调整量用于指示待调整的运行参数的调整方式；

所述应用模块801，用于根据所述待调整量，调整所述待调整指标所指示的运行参数。

在一种可选的实施例中，所述设备性能状态包括以下至少一个：

处理器CPU的负载率、图形处理器GPU的负载率、内存占用情况、电池参数、温度参数、线程数据、图形数据；

其中，所述电池参数包括以下至少一种：电池容量、充电速度、放电速度、电池温度；所述温度参数包括以下至少一种：CPU温度、电池温度、环境温度、电源管理器温度。

在一种可选的实施例中，所述运行参数包括以下至少一种：分辨率、画面质量、图形质量、物理效果质量、音效质量、帧数、帧率、画面特效质量。

在一种可选的实施例中，所述终端运行有所述应用程序，所述应用程序集成了性能改进SDK；

所述性能改进模块802，用于计算核心线程在CPU核的运行时间除以所述CPU核的统计周期的百分比，得到所述CPU的负载率。

在一种可选的实施例中，所述终端运行有所述应用程序，所述应用程序集成了性能改进SDK；

所述性能改进模块802，用于计算GPU执行任务的时间除以GPU负载统计周期的百分比，得到所述GPU的负载率。

本申请还提供了一种终端，该终端包括处理器和存储器，存储器中存储有至少一条指令，至少一条指令由处理器加载并执行以实现上述各个方法实施例提供的应用程序的运行方法。需要说明的是，该终端可以是如图12所提供的终端。

图12示出了本申请一个示例性实施例提供的终端900的结构框图。该终端900可以是：智能手机、平板电脑、MP3播放器（Moving Picture Experts Group Audio Layer III，动态影像专家压缩标准音频层面3）、MP4（Moving Picture Experts Group Audio LayerIV，动态影像专家压缩标准音频层面4）播放器、笔记本电脑或台式电脑。终端900还可能被称为用户帐号设备、便携式终端、膝上型终端、台式终端等其他名称。

本领域技术人员可以理解，图12中示出的结构并不构成对终端900的限定，可以包括比图示更多或更少的组件，或者组合某些组件，或者采用不同的组件布置。

所述存储器还包括一个或者一个以上的程序，所述一个或者一个以上程序存储于存储器中，所述一个或者一个以上程序包含用于进行本申请实施例提供的应用程序的运行方法。

本申请还提供一种计算机设备，该计算机设备包括：处理器和存储器，该存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，该至少一条指令、至少一段程序、代码集或指令集由处理器加载并执行以实现上述各方法实施例提供的应用程序的运行方法。

本申请还提供一种计算机可读存储介质，该存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，该至少一条指令、至少一段程序、代码集或指令集由处理器加载并执行以实现上述各方法实施例提供的应用程序的运行方法。

本申请还提供一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述可选实现方式中提供的应用程序的运行方法。

应当理解的是，在本文中提及的“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。以上仅为本申请的可选实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

需要进行说明的是，本申请在收集用户的相关数据之前以及在收集用户的相关数据的过程中，都可以显示提示界面、弹窗或输出语音提示信息，该提示界面、弹窗或语音提示信息用于提示用户当前正在搜集其相关数据，使得本申请仅仅在获取到用户对该提示界面或者弹窗发出的确认操作后，才开始执行获取用户相关数据的相关步骤，否则（即未获取到用户对该提示界面或者弹窗发出的确认操作时），结束获取用户相关数据的相关步骤，即不获取用户的相关数据。换句话说，本申请所采集的所有用户数据都是在用户同意并授权的情况下进行采集的，且相关用户数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准。

Claims (14)

1.一种应用程序的运行方法，其特征在于，所述方法由终端执行，所述终端运行有所述应用程序，所述应用程序集成了性能改进软件工具开发包SDK，所述方法包括：

在所述应用程序运行至核心场景的情况下，所述性能改进SDK启动自适应服务；所述自适应服务是用于采集所述终端的状态数据的系统服务，所述自适应服务用于采集所述状态数据、向共享内存写入所述状态数据；所述状态数据是由所述终端的操作系统直接提供的数据，所述共享内存用于存储所述状态数据；所述核心场景包括所述应用程序中对运行性能要求高于阈值的运行场景；

所述性能改进SDK向所述自适应服务发送共享内存查询请求；

所述性能改进SDK接收所述自适应服务返回的所述共享内存的文件描述符；

所述性能改进SDK根据所述共享内存的文件描述符，从所述共享内存中读取所述终端的所述状态数据；

所述应用程序调用所述性能改进SDK的数据获取接口获取所述终端的设备性能状态，所述设备性能状态是所述性能改进SDK基于所述状态数据计算得到的；所述设备性能状态用于描述所述终端的运行状态，所述运行性能用于指示所述应用程序在所述核心场景下的运行参数；

根据所述设备性能状态与运行参数的关联关系，所述应用程序根据存在异常的设备性能状态，调整所述设备性能状态所对应的运行参数，以使所述设备性能状态恢复正常；

在所述核心场景结束的情况下，关闭所述自适应服务。

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

所述性能改进SDK向所述自适应服务发送共享内存创建请求；所述自适应服务用于响应于所述共享内存创建请求创建所述共享内存。

3.根据权利要求1所述的方法，其特征在于，所述应用程序调用所述性能改进SDK的数据获取接口获取所述终端的设备性能状态，包括：

所述应用程序调用所述性能改进SDK的数据设置接口修改所述设备性能状态的设置信息；

所述性能改进SDK向所述应用程序返回设置结果和所述设备性能状态，所述设备性能状态是按照所述设置信息基于所述状态数据计算得到的；

其中，所述设置信息包括以下至少一种信息：所述设备性能状态的计算指标、所述计算指标对应的计算方式、计算结果的数据类型、计算结果的数据格式。

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

在所述应用程序的初始化阶段，所述应用程序初始化所述性能改进SDK，将所述自适应服务添加至系统服务中；

所述性能改进SDK向性能改进服务器发送能力询问请求，所述能力询问请求携带有所述终端的设备信息和所述应用程序的当前版本；

所述性能改进SDK接收所述性能改进服务器返回的能力询问结果，所述能力询问结果包括第一指示信息和第二指示信息，所述第一指示信息用于指示所述自适应服务在所述终端和所述应用程序的当前版本中是否开启，所述第二指示信息用于指示所述应用程序的当前版本是否支持所述自适应服务。

5.根据权利要求4所述的方法，其特征在于，所述在所述应用程序运行至核心场景的情况下，所述性能改进SDK启动所述自适应服务，包括：

在所述应用程序的当前版本支持所述自适应服务，所述自适应服务支持在所述终端和所述应用程序的当前版本中使用，且所述应用程序运行至所述核心场景的情况下，所述性能改进SDK启动所述自适应服务。

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

所述性能改进SDK接收所述性能改进服务器发送的配置信息，所述配置信息包括所述应用程序对应的所述设备性能状态的默认设置信息；

所述应用程序调用所述性能改进SDK的数据获取接口获取所述终端的设备性能状态，包括：

所述应用程序调用所述性能改进SDK的数据获取接口请求获取所述终端的设备性能状态；

所述性能改进SDK按照所述默认设置信息基于所述状态数据计算所述设备性能状态，向所述应用程序返回所述设备性能状态；

其中，所述默认设置信息包括以下至少一种信息：所述设备性能状态的计算指标、所述计算指标对应的计算方式、计算结果的数据类型、计算结果的数据格式。

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

将所述设备性能状态输入自适应调整模型，输出待调整指标和所述待调整指标对应的待调整量；所述自适应调整模型用于根据输入的设备性能状态输出运行参数的调整策略，所述待调整指标用于指示待调整的运行参数，所述待调整量用于指示待调整的运行参数的调整方式；

根据所述待调整量，调整所述待调整指标所指示的运行参数。

8.根据权利要求1至3任一所述的方法，其特征在于，所述设备性能状态包括以下至少一个：

处理器CPU的负载率、图形处理器GPU的负载率、内存占用情况、电池参数、温度参数、线程数据、图形数据；

其中，所述电池参数包括以下至少一种：电池容量、充电速度、放电速度、电池温度；所述温度参数包括以下至少一种：CPU温度、电池温度、环境温度、电源管理器温度。

9.根据权利要求1至3任一所述的方法，其特征在于，所述运行参数包括以下至少一种：分辨率、画面质量、图形质量、物理效果质量、音效质量、帧数、帧率、画面特效质量。

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

基于所述性能改进SDK计算核心线程在CPU核的运行时间除以所述CPU核的统计周期的百分比，得到所述CPU的负载率。

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

基于所述性能改进SDK计算GPU执行任务的时间除以GPU负载统计周期的百分比，得到所述GPU的负载率。

12.一种应用程序的运行装置，其特征在于，所述装置用于实现终端，所述终端运行有所述应用程序，所述应用程序集成了性能改进软件工具开发包SDK，所述装置包括：

性能改进模块，用于在所述应用程序运行至核心场景的情况下，所述性能改进SDK启动自适应服务；所述自适应服务是用于采集所述终端的状态数据的系统服务，所述自适应服务用于采集所述状态数据、向共享内存写入所述状态数据；所述状态数据是由所述终端的操作系统直接提供的数据，所述共享内存用于存储所述状态数据；所述核心场景包括所述应用程序中对运行性能要求高于阈值的运行场景；所述性能改进SDK向所述自适应服务发送共享内存查询请求；所述性能改进SDK接收所述自适应服务返回的所述共享内存的文件描述符；所述性能改进SDK根据所述共享内存的文件描述符，从所述共享内存中读取所述终端的所述状态数据；所述应用程序调用所述性能改进SDK的数据获取接口获取所述终端的设备性能状态，所述设备性能状态是所述性能改进SDK基于所述状态数据计算得到的；所述设备性能状态用于描述所述终端的运行状态，所述运行性能用于指示所述应用程序在所述核心场景下的运行参数；

应用模块，用于根据所述设备性能状态与运行参数的关联关系，所述应用程序根据存在异常的设备性能状态，调整所述设备性能状态所对应的运行参数，以使所述设备性能状态恢复正常；

所述性能改进模块，用于在所述核心场景结束的情况下，关闭所述自适应服务。

13.一种计算机设备，其特征在于，所述计算机设备包括：处理器和存储器，所述存储器中存储有至少一段程序，所述至少一段程序由所述处理器加载并执行，以实现如权利要求1至11任一项所述的应用程序的运行方法。

14.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有至少一段程序，所述至少一段程序由处理器加载并执行，以实现如权利要求1至11任一项所述的应用程序的运行方法。