A performance optimization method and related apparatus

Abstract

A performance optimization method and related device, the method comprising: a server receiving first running data from a plurality of terminals, determining first configuration parameters according to identification information of a first model, a first application and the first running data, and sending the first configuration parameters to a first terminal, the first running data comprising running data of the plurality of terminals in a first scenario of running the first application, the models of the plurality of terminals and the first terminal being the first model; the first terminal receiving the first configuration parameters from the server, determining the first scenario of running the first application, and running the first scenario of the first application according to the first configuration parameters. Through the method of the present application, the server can recommend configuration parameters for performance optimization for the same model, the same application and the same scenario, and the terminal can perform performance optimization on the first scenario of the first application according to the configuration parameters recommended by the server, thereby improving user experience.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and in particular to a performance optimization method and related equipment. Background Technology

[0002] Currently, electronic devices are becoming increasingly powerful, and more and more applications are installed on them. Taking gaming applications as an example, with the improvement of game graphics and the enrichment of gameplay and game scenes, higher demands are being placed on the performance of electronic devices.

[0003] The hardware chips of different electronic devices differ in design, and their support for algorithms and interfaces varies. This leads to performance differences for the same game on different electronic devices. For example, if the game application cannot make reasonable use of the electronic device's hardware resources, or if the scheduling strategy implemented by the game application conflicts with the pre-set system configuration strategy of the electronic device, or if the electronic device's system detects an anomaly (such as an abnormal temperature on the terminal) and triggers the electronic device's control strategy (such as hardware frequency reduction), game stuttering will occur, reducing game performance and affecting the user experience. Summary of the Invention

[0004] The purpose of this application is to provide a performance optimization method and related equipment, which is used to improve game performance.

[0005] In a first aspect, this application provides a method for optimizing the performance of a terminal. The method specifically includes: a server receiving first operating data from multiple terminals, the first operating data including operating data of the multiple terminals running a first scenario of a first application, wherein the models of the multiple terminals are a first model; the server determining first configuration parameters based on the first model, the identification information of the first application, and the first operating data, the first configuration parameters being used to configure the parameters of the first model terminal when running the first scenario of the first application; the server sending the first configuration parameters to a first terminal, the first terminal being the first model; the first terminal receiving the first configuration parameters from the server, wherein the first configuration parameters include configuration parameters corresponding to the first scenario of the first application; the first terminal determining the first scenario for running the first application and running the first scenario of the first application according to the first configuration parameters.

[0006] The first configuration parameter may include the identification information of the first scenario, and one or more of the following parameters corresponding to the identification information of the first scenario: CPU operating frequency, GPU operating frequency, number of CPU cores, GPU size, maximum temperature for triggering temperature control strategy, or network speed priority.

[0007] Through the above technical solution, the server can recommend configuration parameters for performance optimization for the same model, the same application, and the same scenario. When the terminal is running the first application, it can run the first scenario of the first application based on the configuration parameters recommended by the server, thereby optimizing the performance of the first application and improving the user experience.

[0008] Taking the first application as a game application as an example, when the terminal runs the game application in scenario 1, the game interface experiences lag due to insufficient cache, but the terminal has available GPU resources. In this case, the first configuration parameter sent by the server to the terminal may include the GPU size, such as 4M of GPU cache. In this way, the terminal can avoid the lag problem caused by insufficient cache when running the game application in scenario 1 according to the first configuration parameter, and can make reasonable use of the terminal's hardware resources.

[0009] For example, in scenario 2 where the terminal is running a game application, the game application implements a scheduling strategy of 4 CPU big cores and 4 CPU small cores. However, the terminal's own system has configured the game application with 2 CPU big cores and 2 CPU small cores. This causes a conflict between the scheduling strategy implemented by the game application and the system configuration strategy, reducing the gaming experience. In this case, the first configuration parameter sent by the server to the terminal can include the number of CPU big cores (e.g., 4 CPU big cores and 4 CPU small cores). In this way, the terminal can avoid the conflict between the scheduling strategy implemented by the game application and the system configuration strategy by running the game application according to the first configuration parameter.

[0010] For example, in scenario 3 where the terminal is running a game application, if the terminal's casing temperature is higher than the maximum temperature of the temperature control policy (e.g., 43 degrees Celsius) but not 50 degrees Celsius, the temperature control policy will be triggered, such as forcibly closing the game application or reducing the operating frequency of hardware (e.g., CPU, GPU). In this case, the first configuration parameter sent by the server to the terminal may include the maximum temperature that triggers the temperature control policy, such as increasing it from the original 43 degrees Celsius to 50 degrees Celsius. In this way, when the terminal runs the game application in scenario 3 based on the first configuration parameter, if the terminal casing temperature is greater than 43 degrees Celsius but less than 50 degrees Celsius, the temperature control policy will not be triggered, thereby improving the gaming experience.

[0011] In one possible design, the first scenario is a high-load scenario during the operation of the first application.

[0012] In one possible design, the first application is a game application.

[0013] In one possible design, before the server sends the first configuration parameter to the first terminal, the method may further include: the server verifying the first configuration parameter and determining that the verification of the first configuration parameter is successful.

[0014] Through the above design, the server can verify the first configuration parameter to ensure that the first configuration parameter can effectively optimize the performance of the first scenario when the first type of terminal runs the first application.

[0015] In one possible design, the method may further include: the first terminal verifying the first configuration parameters; if the verification of the first configuration parameters fails, the first terminal runs a first scenario of the first application according to second configuration parameters; if the verification of the first configuration parameters passes, the first terminal continues to run the first scenario of the first application according to the first configuration parameters. Furthermore, if the verification of the first configuration parameters fails, the first terminal may also send an exception message to the server.

[0016] Optionally, the second configuration parameter can be a configuration parameter stored locally on the first terminal. For example, the second configuration parameter can be the default configuration parameter when the first terminal leaves the factory, or the configuration parameter recommended by the server last time, or the configuration parameter after the first terminal system version is updated, or the configuration parameter after the first application version is updated, etc. This application embodiment does not limit this.

[0017] Through the above design, the first terminal can verify the first configuration parameters when running the first application in the first scenario according to the first configuration parameters. This can ensure that the first configuration parameters can effectively optimize the performance of the first application in the first scenario, thereby avoiding problems such as negative optimization caused by individual differences of electronic devices of the same model.

[0018] In one possible design, before the server sends the first configuration parameters to the first terminal, the method may further include: the first terminal sending a first request message to the server, the first request message including the identification information of the first model and the first application, the first request message being used to request the acquisition of the first configuration parameters; and the server receiving the first request message from the first terminal.

[0019] Using the above technical solution, the terminal can proactively obtain configuration parameters by sending request messages to the server. For example, when the first application starts, the terminal can send a first request message to the server so that the first scenario of the first application can run based on the latest configuration parameters.

[0020] In one possible design, before the first terminal receives the first configuration parameters from the server, the method may further include: the first terminal running a first scenario of the first application according to the second configuration parameters; the first terminal acquiring second running data, the second running data including running data of the first terminal when running the first scenario of the first application according to the second configuration parameters, the first running data including the second running data; and the first terminal sending the second running data to the server.

[0021] Through the above technical solution, the first terminal can report its operational data under high-load scenarios to the server. This allows the server to collect a large amount of operational data corresponding to the same scenario for the same model and application. Furthermore, based on this extensive operational data, the server can recommend configuration parameters for the first model terminal when running the first application in the first scenario.

[0022] In one possible design, the first operating data may include the identification information of the first model and the first application, scene parameters and performance parameters; wherein, the scene parameters include one or more of the following parameters: first scene entry / exit identifier, scene type or instance data; the performance parameters include one or more of the following parameters: rendering time of the first frame, average frame rate, jitter rate, low frame rate ratio, power consumption, device casing temperature or number of dropped frames.

[0023] Secondly, this application provides a method for optimizing the performance of a terminal. This method can be applied to a first terminal, the first terminal being a first model. Specifically, the method may include: the first terminal receiving first configuration parameters from a server, the first configuration parameters being used to configure the terminal's parameters when the first model terminal is running a first application in a first scenario, wherein the first configuration parameters are determined by the server based on the first model, the identification information of the first application, and first running data, the first running data including running data of multiple terminals running the first application in the first scenario, wherein the multiple terminals are of the first model; determining the first scenario for running the first application; and running the first scenario of the first application according to the first configuration parameters.

[0024] In one possible design, the first scenario is a high-load scenario during the operation of the first application.

[0025] In one possible design, the first application is a game application.

[0026] In one possible design, the method may further include: verifying the first configuration parameter; if the verification of the first configuration parameter fails, running a first scenario of the first application according to a second configuration parameter; if the verification of the first configuration parameter passes, continuing to run the first scenario of the first application according to the first configuration parameter. Furthermore, when the verification of the first configuration parameter fails, the first terminal may also send an exception message to the server.

[0027] In one possible design, verifying the first configuration parameter can be done by: collecting a first performance parameter when running the first application in a first scenario according to the first configuration parameter; and verifying the first configuration parameter according to a second performance parameter and the first performance parameter, wherein the second performance parameter is the performance parameter of the first terminal when running the first application in a first scenario according to the second configuration parameter.

[0028] Through the above technical solution, the first terminal can determine whether the first configuration parameter has effectively optimized the performance of the first scenario of the first application by comparing the performance parameters corresponding to the first configuration parameter and the second configuration parameter under the same scenario. For example, if the first terminal determines that effective optimization has been performed, i.e., the verification is successful, the first terminal can continue to run the first scenario of the first application based on the first configuration parameter; otherwise, the first terminal can run the first application based on the second configuration parameter. This ensures that the performance of the first scenario of the first application is reasonably optimized, avoids the problem of negative optimization, and improves the user experience.

[0029] In one possible design, before receiving the first configuration parameters from the server, the method may further include: a first terminal running a first scenario of the first application according to the second configuration parameters; acquiring second running data, the second running data including running data of the first terminal running the first scenario of the first application according to the second configuration parameters; and sending the second running data to the server.

[0030] In one possible design, before receiving the first configuration parameters from the server, the method may further include: a first terminal sending a first request message to the server, the first request message including the identification information of the first model and the first application, the first request message being used to request the acquisition of the first configuration parameters.

[0031] In one possible design, the first configuration parameter includes the identification information of the first scenario, and one or more of the following parameters corresponding to the identification information of the first scenario: CPU operating frequency, GPU operating frequency, number of CPU big and small cores, GPU size, maximum temperature for triggering temperature control strategy, or network speed priority.

[0032] In one possible design, the first operating data may include the first model, the identification information of the first application, scene parameters, and performance parameters; wherein, the scene parameters include one or more of the following parameters: first scene entry / exit identifier, scene type, or instance data; the performance parameters include one or more of the following parameters: rendering time of the first frame, average frame rate, jitter rate, low frame rate ratio, power consumption, device casing temperature, or number of dropped frames.

[0033] Thirdly, this application provides a performance optimization method applicable to a server. Specifically, the method may include: the server receiving first operational data from multiple terminals, the first operational data including operational data of the multiple terminals running a first application in a first scenario, wherein the models of the multiple terminals are a first model; determining first configuration parameters based on the first model, the identification information of the first application, and the first operational data, the first configuration parameters being used for parameter configuration of the terminals of the first model when running the first application in the first scenario; and sending the first configuration parameters to a first terminal, wherein the model of the first terminal is the first model.

[0034] In one possible design, the first scenario is a high-load scenario during the operation of the first application.

[0035] In one possible design, the first application is a game application.

[0036] In one possible design, before sending the first configuration parameter to the first terminal, the method may further include: verifying the first configuration parameter to determine that the verification of the first configuration parameter is successful.

[0037] In one possible design, verifying the first configuration parameter can be done by: simulating the first model of terminal and running the first scenario of the first application according to the first configuration parameter; collecting a third performance parameter when running the first scenario of the first application according to the first configuration parameter; and verifying the first configuration parameter according to a fourth performance parameter and the third performance parameter, wherein the fourth performance parameter is the performance parameter when running the first scenario of the first application according to the third configuration parameter.

[0038] In one possible design, before sending the first configuration parameter to the first terminal, the method may further include: the server receiving a first request message from the first terminal, the first request message including the identification information of the first model and the first application, the first request message being used to request the acquisition of the first configuration parameter.

[0039] In one possible design, determining the first configuration parameter based on the first operating data can be achieved by: training a first parameter recommendation model based on the first model, the identification information of the first application, and the first operating data; and obtaining the first configuration parameter based on the first model, the identification information of the first application, and the first parameter recommendation model.

[0040] In one possible design, the first configuration parameter includes the identification information of the first scenario, and one or more of the following parameters corresponding to the identification information of the first scenario: CPU operating frequency, GPU operating frequency, number of CPU big and small cores, GPU size, maximum temperature for triggering temperature control strategy, or network speed priority.

[0041] In one possible design, the first operating data may include the first model, the identification information of the first application, scene parameters, and performance parameters; wherein, the scene parameters include one or more of the following parameters: first scene entry / exit identifier, scene type, or instance data; the performance parameters include one or more of the following parameters: rendering time of the first frame, average frame rate, jitter rate, low frame rate ratio, power consumption, device casing temperature, or number of dropped frames.

[0042] Fourthly, this application provides a communication device that may include modules / units for executing the second aspect or any possible design method of the second aspect; these modules / units may be implemented in hardware or by hardware executing corresponding software. For example, the communication device may include a processing module and a transceiver module. The processing module is used to execute the second aspect or any possible design method of the second aspect. The transceiver module is used to implement data and / or signaling interaction between the communication device and other devices, such as receiving first configuration parameters from a server.

[0043] Fifthly, this application provides a communication device that may include modules / units for executing the third aspect or any possible design method of the third aspect; these modules / units may be implemented in hardware or by hardware executing corresponding software. For example, the communication device may include a processing module and a transceiver module. The processing module is used to execute the third aspect or any possible design method of the third aspect. The transceiver module is used to realize data and / or signaling interaction between the communication device and other devices, such as sending first configuration parameters to a first terminal.

[0044] Sixthly, this application provides a communication device that may include one or more processors and a memory. The memory is used to store one or more computer programs, the first or second computer programs including instructions that, when executed by the communication device, cause the communication device to perform the method of the second aspect or any possible design of the second aspect.

[0045] In a seventh aspect, this application provides a communication device that may include one or more processors and a memory. The memory is used to store one or more computer programs, the first or second computer programs including instructions that, when executed by the communication device, cause the communication device to perform the method of the third aspect or any possible design of the third aspect.

[0046] Eighthly, this application provides a chip. This chip can be coupled to a memory in a communication device, enabling the chip to call program instructions stored in the memory during operation to implement the second aspect or any possible design method of the second aspect.

[0047] Ninthly, this application provides a chip. This chip can be coupled to a memory in a communication device, enabling the chip to call program instructions stored in the memory during operation, thereby implementing the third aspect or any of the possible design methods of the third aspect.

[0048] In a tenth aspect, this application provides a communication system comprising a communication device described in the fourth aspect or any possible design of the fourth aspect and a communication device described in the fifth aspect or any possible design of the fifth aspect, or comprising a communication device described in the sixth aspect or any possible design of the sixth aspect and a communication device described in the seventh aspect or any possible design of the seventh aspect, or comprising a chip described in the eighth aspect or any possible design of the eighth aspect and a chip described in the ninth aspect or any possible design of the ninth aspect.

[0049] Eleventhly, this application provides a computer-readable storage medium including a computer program that, when run on a communication device, causes the communication device to perform the method of the second aspect or any possible design of the second aspect.

[0050] In a twelfth aspect, this application provides a computer-readable storage medium comprising a computer program that, when executed on a communication device, causes the communication device to perform the method of the third aspect or any possible design of the third aspect.

[0051] In a thirteenth aspect, this application provides a computer program product including instructions that, when executed on a computer, cause the computer to perform the method of the second aspect or any possible design of the second aspect.

[0052] In a fourteenth aspect, this application provides a computer program product including instructions that, when executed on a computer, cause the computer to perform the method of the third aspect or any possible design of the third aspect.

[0053] In a fifteenth aspect, this application also provides an electronic device comprising one or more processors; one or more memories; one or more sensors; multiple applications; and one or more computer programs; wherein the one or more computer programs are stored in the one or more memories, and the one or more computer programs include instructions that, when invoked and executed by the one or more processors, cause the electronic device to perform the technical solutions of the second aspect described above and any possible design of the second aspect.

[0054] For the various aspects from the second to the fifteenth aspect above, and the technical effects that each aspect may achieve, please refer to the above description of the technical effects that the various possible solutions for the first aspect may achieve, which will not be repeated here. Attached Figure Description

[0055] Figure 1 This is a schematic diagram illustrating an application scenario applicable to the embodiments of this application;

[0056] Figure 2A This application provides a schematic diagram of the structure of a server according to an embodiment of the present application.

[0057] Figure 2B This is a schematic diagram of the structure of a terminal provided in an embodiment of this application;

[0058] Figure 2C This is a schematic diagram of the structure of another terminal provided in an embodiment of this application;

[0059] Figure 3 A flowchart illustrating a method for determining configuration parameters provided in an embodiment of this application;

[0060] Figure 4 A schematic flowchart of a performance optimization method provided in an embodiment of this application;

[0061] Figure 5A A schematic diagram of a system architecture provided for an embodiment of this application;

[0062] Figure 5B A schematic diagram of another system architecture provided for an embodiment of this application;

[0063] Figure 6 Another flowchart illustrating the performance optimization method provided in this application embodiment;

[0064] Figure 7 This is another flowchart illustrating the performance optimization method provided in the embodiments of this application. Detailed Implementation

[0065] First, some of the terms used in the embodiments of this application will be explained to facilitate understanding by those skilled in the art.

[0066] (1) Public beta testing phase refers to the phase in which the game application provider invites multiple users to experience the game application before the game application is released (or after the game application is updated but the updated content has not yet been released), and then debugs the game application based on the game operation data generated by the multiple users' experience of the game application.

[0067] The live network stage refers to the stage after a game application is released (or after a game application is updated and the updated content is released) when users actively experience the game application.

[0068] (2) The application (APP) involved in the embodiments of this application can be simply referred to as an application, which is a software program capable of performing one or more specific functions. Typically, multiple applications can be installed on a terminal, such as instant messaging applications, video applications, audio applications, image capture applications, etc. Instant messaging applications may include, for example, SMS applications, WeChat, WhatsApp Messenger, Line, Instagram, KakaoTalk, DingTalk, etc. Image capture applications may include, for example, camera applications (system camera or third-party camera applications). Video applications may include, for example, YouTube, Twitter, TikTok, iQiyi, Tencent Video, etc. Audio applications may include, for example, Kugou Music, Xiami, QQ Music, etc. The applications mentioned in the following embodiments may be applications pre-installed at the terminal's factory or applications downloaded by the user from the network or obtained from other terminals during the use of the terminal.

[0069] It should be noted that the performance optimization method provided in this application can be applied to the aforementioned game applications, or other applications, etc., and this application does not limit it. The following description uses a game application as an example. The first application involved in this application can be referred to as the first game application. Correspondingly, the first running data in the following description can be referred to as the first game running data, and the second running data can be referred to as the second game running data.

[0070] (3) The terminals involved in the embodiments of this application may also be referred to as electronic devices, terminal devices, etc., and this application does not limit this name. For example, mobile phone, tablet computer, laptop computer, handheld computer, mobile internet device (MID), wearable device (e.g., watch, bracelet, smart helmet, etc.), virtual reality (VR) device, augmented reality (AR) device, ultra-mobile personal computer (UMPC), netbook, personal digital assistant (PDA), wireless electronic device in industrial control, wireless electronic device in self-driving, wireless electronic device in remote medical surgery, wireless electronic device in smart grid, wireless electronic device in transportation safety, wireless electronic device in smart city, wireless electronic device in smart home, etc.

[0071] (4) The server involved in the embodiments of this application may also be called a big data platform, cloud, cloud server, or server cluster, etc. This application does not limit this name. However, this does not constitute a limitation, and other servers that can be used for big data computing are also possible.

[0072] (5) The terminology used in the embodiments of this application is for the purpose of describing specific embodiments only and is not intended to be a limitation of this application. As used in the specification and appended claims of this application, the singular expressions “a,” “an,” “the,” “the,” “the,” and “this” are intended to also include expressions such as “one or more,” unless the context clearly indicates otherwise. It should also be understood that in the embodiments of this application, “one or more” means one, two, or more; “and / or” describes the relationship between related objects, indicating that three relationships may exist; for example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character “ / ” generally indicates that the preceding and following related objects are in an “or” relationship.

[0073] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0074] The embodiments of this application involve at least one, including one or more; wherein, multiple means two or more. Furthermore, it should be understood that in the description of this application, terms such as "first" and "second" are used only for descriptive purposes and should not be construed as indicating or implying relative importance, nor as indicating or implying order.

[0075] Figure 1 This illustration shows an exemplary scenario diagram of the performance optimization method provided in an embodiment of this application. Figure 1 As shown, this scenario can include a server 200 and a communication system comprising one or more terminals (terminals 301 and 302 are used as examples in the diagram). After a connection is established between the server 200 and the terminals, the server 200 can provide network services to the terminals. Please refer to the preceding text for a brief introduction to the server and terminals. For example, a terminal may have one or more apps installed. During app operation, there is information exchange between the terminal and the server 200. This information may be app-related configuration parameters recommended by the server 200 for the terminal, and / or status information related to app operation reported by the terminal to the server 200.

[0076] Taking a game application as an example, the terminal has a game application installed. In response to the user's launch operation (such as clicking or touching the game application icon displayed on the terminal's screen), the terminal launches the game application. When the game application is running on the terminal, the terminal can collect game operation data. This game operation data may include, for example, one or more of the following: high-load scene entry / exit markers, scene category, instance data, rendering time of the first frame, average frame rate during the high-load scene period, jitter rate, number of stutters, low frame rate ratio, power consumption, device casing temperature, or number of dropped frames.

[0077] After the terminal collects game operation data, it can send the game operation data to the corresponding server 200, such as the server 200 connected to the terminal. This server 200 can be a server provided by the game application distributor, such as the server corresponding to Tencent Games; of course, it can also be other servers, such as the server corresponding to a mobile phone supplier. This application does not limit this. The server 200 can determine configuration parameters based on the game operation data. These configuration parameters can be software resources, hardware resources, or both recommended by the server 200.

[0078] For example, server 200 maintains a large amount of game runtime data. This large amount of game runtime data is generated by different game applications running on different types of terminals. Server 200 can store the game runtime data of different game applications using the game application's identifier as an index. For ease of understanding, Table 1 shows an example of the game runtime data present in server 200. Table 1 uses Knives Out and Honor of Kings as examples to show that the game runtime data generated by the same game application in different scenarios when running on different terminals is different, the game runtime data generated by different game applications running on the same type of terminal is different, and the game runtime data generated by the same game application running on different types of terminals is different.

[0079] Table 1

[0080]

[0081] For example, server 200 can generate training samples based on this game runtime data to train parameter recommendation models corresponding to different game applications, models, and scenarios. Server 200 maintains parameter recommendation models corresponding to different game applications, models, and scenarios. These parameter recommendation models are used to recommend usable hardware resources, software resources, or both for a game application during one or more scenarios while it is running on the terminal. For example, server 200 stores these parameter recommendation models indexed by the game application's identifier. For ease of understanding, Table 2 shows an example of the parameter recommendation models maintained by server 200. Table 2 uses Knives Out and Honor of Kings as examples to illustrate parameter recommendation models corresponding to different game applications, models, and scenarios.

[0082] Table 2

[0083]

[0084]

[0085] In summary, the server 200 can recommend hardware and / or software resources that can be used to configure game applications based on the game running data reported by the terminal.

[0086] It should be noted that the server 200 and the terminal can be interconnected via a communication network. This communication network can be a local area network (LAN) or a wide area network (WAN) relayed through a relay device. When the communication network is a LAN, examples include Wi-Fi hotspots, Wi-Fi P2P networks, Bluetooth networks, Zigbee networks, or near-field communication (NFC) networks. When the communication network is a WAN, examples include third-generation wireless telephone technology (3G), fourth-generation mobile communication technology (4G), fifth-generation mobile communication technology (5G), future public land mobile networks (PLMNs), or the Internet. Figure 1 In the scenario shown, different electronic devices can exchange data through a communication network. For example, the terminal sends scenario parameters and performance parameters to the server 200, and the server 200 sends configuration parameters to the terminal.

[0087] The following examples illustrate both server 200 and terminal:

[0088] I. Server 200:

[0089] Figure 2A The diagram shown is a partial structural block diagram of a server 200 related to various embodiments of this application. This server 200, for example, is a single server, a server cluster, or a cloud server, used to recommend and configure hardware and / or software resources usable by the game application for the terminal based on game running data reported by the terminal. Figure 2A As shown, the server 200 may include a processor 201, a memory 202, and a transceiver 203. One or more computer programs are stored in the memory 202 and configured to be executed by the one or more processors 201.

[0090] The processor 201 can be a central processing unit (CPU) or a digital processing unit, etc. The processor 201 can be the control center of the server 200, connecting various parts of the server 200 via various interfaces and lines. It executes computer programs stored in the memory 202 and calls historical game running data related to the game application stored in the memory 202 to perform various functions related to the game application, such as determining configuration parameters based on historical game running parameters and verifying the determined configuration parameters.

[0091] The transceiver 203 can be used to receive historical game running data related to the game application collected by the terminal, and to send the configuration parameters processed by the processor 201 to the terminal.

[0092] For example, the server 200 may also include a database 204. The database 204 may be used to store a large number of APP compressed files, such as game operation data related to each game application as shown in Table 1, and parameter recommendation models related to each game application as shown in Table 2.

[0093] This application embodiment does not limit the specific connection medium between the processor 201 and memory 202, or between the processor 201 and database 204, etc. This application embodiment... Figure 2A The processor 210, memory 202, transceiver 203, and database 204 are connected via bus 205. Figure 2A The connections between other components are shown in bold and are for illustrative purposes only, not as a limitation. The bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, Figure 2A The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0094] The memory 202 can be volatile memory, such as random-access memory (RAM); it can also be non-volatile memory, such as read-only memory, flash memory, hard disk drive (HDD), or solid-state drive (SSD); or it can be any other medium capable of carrying or storing program code in the form of instructions or data structures that can be accessed by a computer, but is not limited thereto. The memory 202 can be a combination of the above-mentioned memories.

[0095] II. Terminal:

[0096] Figure 2B A schematic diagram of one possible structure of a terminal is shown. This terminal is, for example,... Figure 1 The terminal in the illustrated architecture. Terminals include, for example, mobile phones and tablets. Figure 2B As shown, the terminal may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, a sensor module 180, buttons 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc.

[0097] Processor 110 may include one or more processing units, such as an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, memory, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural network processing unit (NPU). Different processing units may be independent devices or integrated into one or more processors. The controller may serve as the central nervous system and command center of terminal 100. The controller can generate operation control signals based on instruction opcodes and timing signals to control instruction fetching and execution. Processor 110 may also include memory for storing instructions and data. In some embodiments, the memory in processor 110 is a cache memory. This memory can store instructions or data that processor 110 has recently used or is recurring. If processor 110 needs to reuse an instruction or data, it can directly retrieve it from the memory. This avoids repeated access, reduces the waiting time of processor 110, and thus improves system efficiency.

[0098] USB interface 130 is a USB standard compliant interface, specifically a Mini USB interface, Micro USB interface, USB Type-C interface, etc. USB interface 130 can be used to connect a charger to charge the terminal, and can also be used for data transfer between the terminal and peripheral devices. Charging management module 140 receives charging input from the charger. Power management module 141 connects to battery 142, charging management module 140, and processor 110. Power management module 141 receives input from battery 142 and / or charging management module 140, providing power to processor 110, internal memory 121, external memory, display 194, camera 193, and wireless communication module 160, etc.

[0099] The terminal's wireless communication function can be implemented through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor, and baseband processor. Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in the terminal can be used to cover one or more communication frequency bands. Different antennas can also be multiplexed to improve antenna utilization. For example, antenna 1 can be multiplexed as a diversity antenna for a wireless local area network. In some other embodiments, the antennas can be used in conjunction with a tuning switch.

[0100] The mobile communication module 150 can provide solutions for wireless communication applications including 2G / 3G / 4G / 5G in terminals. The mobile communication module 150 may include at least one filter, switch, power amplifier, low-noise amplifier (LNA), etc. The mobile communication module 150 can receive electromagnetic waves via antenna 1, and perform filtering, amplification, and other processing on the received electromagnetic waves before transmitting them to a modem processor for demodulation. The mobile communication module 150 can also amplify the signal modulated by the modem processor and convert it into electromagnetic waves for radiation via antenna 1. In some embodiments, at least some functional modules of the mobile communication module 150 may be housed in the processor 110. In some embodiments, at least some functional modules of the mobile communication module 150 and at least some modules of the processor 110 may be housed in the same device.

[0101] The wireless communication module 160 can provide solutions for wireless communication applications on terminals, including wireless local area networks (WLANs), such as wireless fidelity (Wi-Fi), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), and infrared (IR) technologies. The wireless communication module 160 can be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via antenna 2, performs frequency modulation and filtering of the electromagnetic wave signals, and sends the processed signal to processor 110. The wireless communication module 160 can also receive signals to be transmitted from processor 110, perform frequency modulation and amplification, and convert them into electromagnetic waves for radiation via antenna 2.

[0102] In some embodiments, antenna 1 of the terminal is coupled to mobile communication module 150, and antenna 2 is coupled to wireless communication module 160, enabling the terminal to communicate with networks and other devices via wireless communication technology. The wireless communication technology may include Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Time-Division Code Division Multiple Access (TD-SCDMA), Long Term Evolution (LTE), BT, GNSS, WLAN, NFC, FM, and / or IR technology, etc. The GNSS may include Global Positioning System (GPS), Global Navigation Satellite System (GLONASS), BeiDou Navigation Satellite System (BDS), Quasi-Zenith Satellite System (QZSS), and / or Satellite Based Augmentation Systems (SBAS).

[0103] Display screen 194 is used to display the application's interface, such as the game interface of a game application. Display screen 194 includes a display panel. The display panel can be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a MiniLED, a MicroLED, a Micro-OLED, a quantum dot light-emitting diode (QLED), etc. In some embodiments, the terminal may include one or N displays 194, where N is a positive integer greater than 1.

[0104] The terminal can achieve shooting functions through ISP, camera 193, video codec, GPU, display 194 and application processor.

[0105] The ISP (Image Signal Processor) is used to process data fed back from the camera 193. For example, when taking a picture, the shutter is opened, and light is transmitted through the lens to the camera's photosensitive element. The light signal is converted into an electrical signal, and the camera's photosensitive element transmits the electrical signal to the ISP for processing, transforming it into an image visible to the naked eye. The ISP can also perform algorithmic optimization of image noise, brightness, and skin tone. The ISP can also optimize parameters such as exposure and color temperature of the shooting scene. In some embodiments, the ISP can be set in the camera 193.

[0106] Camera 193 is used to capture still images or videos. An object is projected onto a photosensitive element by generating an optical image through the lens. The photosensitive element can be a charge-coupled device (CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor. The photosensitive element converts the light signal into an electrical signal, which is then passed to an ISP for conversion into a digital image signal. The ISP outputs the digital image signal to a DSP for processing. The DSP converts the digital image signal into image signals in standard RGB, YUV, or other formats. In some embodiments, the terminal may include one or N cameras 193, where N is a positive integer greater than 1.

[0107] Digital signal processors (DSPs) are used to process digital signals. Besides digital image signals, they can also process other digital signals. For example, when a terminal selects a frequency, a DSP can perform a Fourier transform on the frequency energy.

[0108] Video codecs are used to compress or decompress digital video. A terminal can support one or more video codecs. This allows the terminal to play or record videos in various encoding formats, such as Moving Picture Experts Group (MPEG) 1, MPEG2, MPEG3, MPEG4, etc.

[0109] An NPU (Neural Processing Unit) is a computational processor for neural networks (NNs). By borrowing the structure of biological neural networks, such as the transmission patterns between neurons in the human brain, it can rapidly process input information and continuously learn on its own. NPUs enable intelligent cognitive applications in terminals, such as image recognition, facial recognition, speech recognition, and text understanding.

[0110] Internal memory 121 can be used to store computer executable program code, which includes instructions. Processor 110 executes various terminal functions and data processing by running the instructions stored in internal memory 121. Internal memory 121 may include a program storage area and a data storage area. The program storage area may store the operating system and software code for at least one application (e.g., iQiyi application, WeChat application, etc.). The data storage area may store data generated during terminal use (e.g., captured images, recorded videos, etc.). Furthermore, internal memory 121 may include high-speed random access memory and non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc.

[0111] The external storage interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device. The external memory card communicates with the processor 110 through the external storage interface 120 to perform data storage functions. For example, images, videos, and other files can be saved on the external memory card.

[0112] The terminal can implement audio functions, such as music playback and recording, through an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, and an application processor.

[0113] The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an accelerometer sensor 180E, a distance sensor 180F, a proximity sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

[0114] Pressure sensor 180A is used to sense pressure signals and can convert the pressure signals into electrical signals. In some embodiments, pressure sensor 180A may be disposed on display screen 194. Gyroscope sensor 180B can be used to determine the motion posture of the terminal. In some embodiments, the angular velocity of the terminal about three axes (i.e., x, y, and z axes) can be determined by gyroscope sensor 180B.

[0115] The gyroscope sensor 180B can be used for image stabilization. The barometric pressure sensor 180C is used to measure air pressure. In some embodiments, the terminal calculates altitude using the air pressure value measured by the barometric pressure sensor 180C to assist in positioning and navigation. The magnetic sensor 180D includes a Hall effect sensor. The terminal can use the magnetic sensor 180D to detect the opening and closing of the flip cover. In some embodiments, when the terminal is a flip phone, the terminal can detect the opening and closing of the flip cover using the magnetic sensor 180D. Based on the detected opening and closing state of the cover or the flip cover, features such as automatic flip unlocking can be set. The accelerometer sensor 180E can detect the magnitude of the terminal's acceleration in various directions (generally three axes). When the terminal is stationary, it can detect the magnitude and direction of gravity. It can also be used to identify the terminal's posture, applicable to applications such as landscape / portrait switching and pedometers.

[0116] A proximity sensor 180F is used to measure distance. The terminal can measure distance via infrared or laser. In some embodiments, during a shooting scene, the terminal can utilize the proximity sensor 180F to measure distance for fast focusing. A proximity sensor 180G may include, for example, a light-emitting diode (LED) and a light detector, such as a photodiode. The LED may be an infrared LED. The terminal emits infrared light outward through the LED. The terminal uses the photodiode to detect infrared reflected light from nearby objects. When sufficient reflected light is detected, it can be determined that an object is near the terminal. When insufficient reflected light is detected, the terminal can determine that no object is near the terminal. The terminal can use the proximity sensor 180G to detect when a user holds the terminal close to their ear for a call, automatically turning off the screen to save power. The proximity sensor 180G can also be used in holster mode and pocket mode for automatic unlocking and screen locking.

[0117] The ambient light sensor 180L is used to sense ambient light brightness. The terminal can adaptively adjust the display brightness 194 based on the sensed ambient light level. The ambient light sensor 180L can also be used to automatically adjust the white balance when taking photos. The ambient light sensor 180L can also work with the proximity sensor 180G to detect whether the terminal is in a pocket to prevent accidental touches. The fingerprint sensor 180H is used to collect fingerprints. The terminal can use the collected fingerprint characteristics to unlock the device, access app locks, take photos with fingerprints, and answer calls with fingerprints.

[0118] Temperature sensor 180J is used to detect temperature. In some embodiments, the terminal uses the temperature detected by temperature sensor 180J to execute a temperature processing strategy. For example, when the temperature reported by temperature sensor 180J exceeds a threshold, the terminal reduces the performance of the processor located near temperature sensor 180J to reduce power consumption and implement thermal protection. In other embodiments, when the temperature is below another threshold, the terminal heats battery 142 to prevent abnormal shutdown due to low temperature. In still other embodiments, when the temperature is below yet another threshold, the terminal boosts the output voltage of battery 142 to prevent abnormal shutdown due to low temperature.

[0119] Touch sensor 180K, also known as a "touch panel," can be located on display screen 194. The touch sensor 180K and display screen 194 together form a touchscreen, also known as a "touchscreen." Touch sensor 180K detects touch operations applied to or near it. The touch sensor can transmit the detected touch operation to the application processor to determine the type of touch event. Visual output related to the touch operation can be provided through display screen 194. In other embodiments, touch sensor 180K may also be located on the surface of the terminal, in a different position than display screen 194.

[0120] The bone conduction sensor 180M can acquire vibration signals. In some embodiments, the bone conduction sensor 180M can acquire vibration signals from vibrating bone fragments in the human vocal cords. The bone conduction sensor 180M can also contact the human pulse to receive blood pressure signals.

[0121] Buttons 190 include a power button, volume buttons, etc. Buttons 190 can be mechanical buttons or touch buttons. The terminal can receive button inputs and generate key signal inputs related to user settings and function control. Motor 191 can generate vibration alerts. Motor 191 can be used for incoming call vibration alerts or for touch vibration feedback. For example, different vibration feedback effects can correspond to different applications (such as taking photos, audio playback, etc.). Touch vibration feedback effects can also be customized. Indicator 192 can be an indicator light, used to indicate charging status, battery level changes, or to indicate information, missed calls, notifications, etc. SIM card interface 195 is used to connect a SIM card. The SIM card can be inserted into or removed from the SIM card interface 195 to achieve contact and separation with the terminal.

[0122] Understandable Figure 2B The components shown do not constitute a specific limitation on the terminal. The terminal may include more or fewer components than shown, or combine some components, or separate some components, or have different component arrangements. Furthermore, Figure 2B The combination / connection relationships between the components can also be adjusted and modified.

[0123] This application uses the layered architecture of the Android system as an example to illustrate the software structure of the terminal.

[0124] Figure 2C This is a software structure block diagram of the terminal according to an embodiment of the present invention.

[0125] A layered architecture divides software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, the Android system is divided into four layers, from top to bottom: the application layer, the application framework layer, the Android runtime and system libraries, and the kernel layer.

[0126] The application layer can include a series of application packages.

[0127] like Figure 2C As shown, the application package can include applications such as games, camera, gallery, calendar, calling, map, navigation, WLAN, Bluetooth, music, and video.

[0128] The application framework layer provides application programming interfaces (APIs) and a programming framework for applications in the application layer. The application framework layer includes some predefined functions.

[0129] like Figure 2CAs shown, the application framework layer may include the collection of Android application packages (APKs), verification modules, system performance modules, window managers, content providers, view systems, resource managers, notification managers, etc.

[0130] The collection APK is used to collect game operation data during game execution, report the collected game operation data to a cloud server, and download the corresponding configuration parameters of the game from the cloud server. This collection APK, as a functional implementation, can reside in the application framework layer or be integrated into the game application; this application embodiment does not limit this.

[0131] The verification module is used to verify the configuration parameters obtained from the cloud during game operation. This verification module, as a functional implementation, can reside in the application framework layer or be integrated into the game application or other applications; this application embodiment does not limit this.

[0132] The system performance module is used to collect performance parameters during game operation.

[0133] The window manager is used to manage windowed applications. It can retrieve screen size, determine the presence of a status bar, lock the screen, and capture screenshots, among other things.

[0134] Content providers store and retrieve data, making that data accessible to applications. This data may include videos, images, audio, made and received phone calls, browsing history and bookmarks, phone books, etc.

[0135] The file explorer provides applications with various resources, such as localized strings, icons, images, layout files, video files, and more.

[0136] The notification manager allows applications to display notifications in the status bar. These notifications can be used to deliver informational messages and can disappear automatically after a short pause, requiring no user interaction. For example, the notification manager can be used to notify users of completed downloads or message alerts. The notification manager can also display notifications as icons or scrolling text in the top status bar, such as notifications from background applications, or as dialog boxes on the screen. Examples include displaying text messages in the status bar, emitting sounds, vibrating electronic devices, and flashing indicator lights.

[0137] The Android Runtime consists of core libraries and a virtual machine. The Android runtime is responsible for scheduling and managing the Android system.

[0138] The core library consists of two parts: one part is the functionalities that need to be called by the Java language, and the other part is the Android core library.

[0139] The application layer and application framework layer run in a virtual machine. The virtual machine executes the Java files of the application layer and application framework layer as binary files. The virtual machine is used to perform functions such as object lifecycle management, stack management, thread management, security and exception management, and garbage collection.

[0140] System libraries can include multiple functional modules. For example: surface manager, media libraries, 3D graphics processing libraries (e.g., OpenGL ES), 2D graphics engines (e.g., SGL), etc.

[0141] The Surface Manager is used to manage the display subsystem and provides the blending of 2D and 3D layers for multiple applications.

[0142] The media library supports playback and recording of various common audio and video formats, as well as still image files. It supports multiple audio and video encoding formats, such as MPEG4, H.264, MP3, AAC, AMR, JPG, and PNG.

[0143] The 3D graphics processing library is used to implement 3D graphics drawing, image rendering, compositing, and layer processing.

[0144] A 2D graphics engine is a graphics engine for 2D drawing.

[0145] The kernel layer is the layer between hardware and software. The kernel layer contains at least the display driver, camera driver, audio driver, and sensor driver.

[0146] This application provides a method for optimizing terminal performance. In this method, a server receives first operational data from multiple terminals, including operational data of the multiple terminals running a first scenario of a first application, wherein the models of the multiple terminals are a first model. The server determines first configuration parameters based on the first model, the identification information of the first application, and the first operational data. These first configuration parameters are used to configure the terminals of the first model when running the first scenario of the first application. The server sends the first configuration parameters to a first terminal, and the first terminal receives the first configuration parameters from the server, wherein the model of the first terminal is the first model, and the first configuration parameters include configuration parameters corresponding to the first scenario of the first application. Finally, the first terminal determines the first scenario for running the first application and runs the first scenario of the first application according to the first configuration parameters. Through this application, the server can recommend configuration parameters for performance optimization for the same model, the same application, and the same scenario. The terminal can optimize the performance of the first scenario of the first application according to the configuration parameters recommended by the server, thereby improving the user experience.

[0147] Next, we will first introduce the process by which the server determines the first configuration parameter.

[0148] Figure 3 This illustration shows a flowchart of a configuration parameter determination method provided in an embodiment of this application. Figure 3 As shown, the flow of this method is as follows.

[0149] S31: The terminal collects second game running data when running the first scene of the first game application.

[0150] The first scenario is a high-load scenario. In this application embodiment, the first scenario can refer to one or more scenarios; that is, the first scenario can be a high-load scenario during the operation of the first game application, or it can be multiple high-load scenarios during the operation of the first game application. For ease of understanding, unless otherwise specified, the following description will use the first scenario as an example.

[0151] High-load scenarios, also known as high-performance scenarios or high-load scenarios, are not limited to any particular name in this application. A high-load scenario can refer to a scenario where the software and hardware resource requirements of the first game application exceed a set threshold during operation. For example, a high-load scenario can be marked by the game application's software development kit (SDK). In high-load scenarios, the game interface is prone to stuttering, unclear image quality, and increased device temperature, all of which negatively impact the user's gaming experience. For ease of understanding, Table 3 shows an example of a high-load scenario during game application operation. Taking Knives Out as an example, Table 3 shows that when two or more users are battling in the game interface, this scenario is high-load scenario 1; when four users are moving quickly in vehicles, this scenario is high-load scenario 2; and when multiple users and more than 20 supplies are present, this scenario is high-load scenario 3. Normal scenarios refer to scenarios other than high-load scenarios during the operation of the first game application, i.e., scenarios where the software and hardware resource requirements of the first game application do not exceed the set threshold.

[0152] Table 3

[0153]

[0154]

[0155] The second game operation data can be the operation data when the terminal runs the first game application in the first scenario according to the second configuration parameters. Accordingly, the first scenario refers to one or more high-load scenarios during the process of the terminal running the first game application based on the second configuration parameters. For example, if the terminal has the first game application installed, in response to the user's launch operation, the terminal runs the first game application according to the second configuration parameters. During the operation of the first game application, one or more high-load scenarios (i.e., the first scenario) will occur, and game operation data under these one or more high-load scenarios will be collected.

[0156] The second configuration parameter can be a configuration parameter stored locally on the current terminal. For example, the second configuration parameter can be the default configuration parameter when the terminal leaves the factory, or the configuration parameter recommended by the server last time, or the configuration parameter after the terminal system version is updated, or the configuration parameter after the first game application version is updated, etc. This application embodiment does not limit this.

[0157] The second game runtime data may include second scene parameters and second performance parameters. For example, the terminal can collect scene parameters and performance parameters under one or more high-load scenarios. For example, the terminal can collect scene parameters under high-load scenarios through the game service SDK integrated into the first game application. For example, the terminal can collect performance parameters under high-load scenarios through hardware-related control software.

[0158] Scene parameters refer to game data related to the current high-load scene during the operation of the first game application. Scene parameters may include, but are not limited to, one or more of the following: high-load scene entry / exit identifiers, scene type, or instance data, etc.

[0159] High-load scenario entry and exit identifiers refer to the identifiers for entering and exiting high-load scenarios. If the current scenario switches from a normal scenario to a high-load scenario, the terminal can determine the current time as the entry time of the high-load scenario and identify the entry time (e.g., by adding a timestamp); if the current scenario switches from a high-load scenario to a normal scenario, the terminal can determine the current time as the exit time of the high-load scenario and identify the exit time.

[0160] Scene type refers to the scene type corresponding to the current high-load scene. Taking Knives Out as an example, scene types can include combat scenes, parachute scenes, racing scenes, and escape scenes. Scene identification information is used to identify various scenes during the operation of the first game application. It is understood that different game applications may have the same or different scene types. For a game application, the scene type may be predefined or pre-set by the game application provider, etc., and this application embodiment does not limit this. High-load scenes may also be predefined or pre-set by the game application provider, etc., and this application embodiment does not limit this.

[0161] Instance data refers to the number of users, items, and building sizes on the same screen in the current high-load scenario.

[0162] Taking Knives Out as an example, Knives Out runs on a terminal. When the game interface switches from a parachute scene to a multiplayer battle scene, the terminal determines that the game has entered a high-load scene, marks the entry and exit times of this high-load scene, and identifies this high-load scene as scene type 1. Furthermore, the terminal counts the maximum (or average) number of users on screen simultaneously, the maximum (or average) number of items, item sizes, and other data within the time period corresponding to the high-load scene.

[0163] Performance parameters refer to system data related to the current high-load scenario during the operation of the first game application. These performance parameters may include, but are not limited to, one or more of the following: rendering time of the first frame, average frame rate, jitter rate, low frame rate ratio, power consumption, device casing temperature, or number of dropped frames, etc.

[0164] The rendering time of the first frame refers to the rendering time of the first frame when the first game application starts. For example, the rendering time of the first frame can be understood as the time from when the terminal receives the start operation of the first game application to when the terminal displays the login interface of the first game application.

[0165] Average frame rate refers to the average frame rate over a period of time corresponding to a high-load scenario. Frame rate refers to the frequency (or rate) at which bitmap images, measured in frames, continuously appear on the display interface.

[0166] Jitter rate is used to measure the stability of game visuals within a time period corresponding to high-load scenarios.

[0167] The number of stutters refers to the number of stutters in the first game application within a time period corresponding to a high-load scenario.

[0168] Low frame rate ratio refers to the proportion of low frame rate instances to the total number of frames within a time period corresponding to a high-load scenario. Low frame rate instances are those below a set threshold.

[0169] Power consumption refers to the power consumption of the terminal running the first game application during the time period corresponding to a high-load scenario.

[0170] Device casing temperature refers to the highest casing temperature of the terminal during a time period corresponding to a high-load scenario.

[0171] Frame drops refer to the number of frames dropped during the operation of the first game application within a time period corresponding to a high-load scenario.

[0172] Taking Knives Out as an example, Knives Out runs on a terminal. When the game interface switches from a parachute scene to a battle scene, the terminal determines that the game has entered a high-load scene. When the game interface switches from the battle scene back to a normal scene, the terminal determines that the game has exited the high-load scene and calculates the average frame rate, jitter rate, number of stutters, low frame rate ratio, power consumption, device casing temperature, and number of dropped frames during the corresponding time period of the high-load scene. Furthermore, the terminal can also collect the rendering time of the first frame when Knives Out starts.

[0173] Table 4 uses Knives Out as an example to illustrate scene and performance parameters. As shown in Table 4, the scene parameters for Scene 1 are: more than 50 but less than 100 objects on the game screen at the same time, and the performance parameter is: power consumption less than 1500 mAh; the performance parameter for Scene 2 is: multiple applications running simultaneously; the performance parameter for Scene 3 is: the highest device temperature is 48 degrees Celsius; the performance parameters for Scene 4 are: an average frame rate of 40 fps, lower than the recommended average frame rate (60 fps) for the first game application, and a low frame rate ratio greater than 5%.

[0174] Table 4

[0175]

[0176] S32: The terminal sends the second game running data to the server. Correspondingly, the server receives the second game running data.

[0177] The second game runtime data includes second scene parameters and second performance parameters. It is understood that since one or more high-load scenarios may occur during the operation of the first game application, the second game runtime data may include one set of scene parameters and performance parameters, or it may include multiple sets of scene parameters and performance parameters. For example, the terminal can report the scene parameters and performance parameters under high-load scenarios to the server in real time; that is, the terminal reports the scene parameters and performance parameters to the server every time it collects them, and the second game runtime data includes one set of scene parameters and performance parameters. Alternatively, the terminal can report the scene parameters and performance parameters under high-load scenarios to the server after the first game application finishes running; that is, the terminal reports the scene parameters and performance parameters under all high-load scenarios during the runtime of the first game application to the server. In this case, the second game runtime data includes one or more sets of scene parameters and performance parameters.

[0178] In one possible implementation, the second game operation data may also include the terminal model information. Different terminal models (such as different models of the same brand, or different models of different brands) have different factory hardware resources, so the same game application will perform differently on different terminal models. For example, the same game application may exhibit a high-load scenario on a low-end terminal, while exhibiting a normal scenario on a high-end terminal.

[0179] In another possible implementation, the second game operation data may further include identification information of the first game application to distinguish it from other game applications. For example, a server may maintain game operation data for multiple game applications on a terminal, and the identification information of the first game application can be used to distinguish it from other game applications among these multiple game applications.

[0180] In another possible implementation, the second game operation data may further include terminal identification information. In this embodiment, during the public beta testing phase, the server can receive second game operation data from multiple terminals of the same model. This second game operation data may include game operation data, terminal model information, identification information of the first game application, and terminal identification information. That is, during the public beta testing phase, the server collects game operation data of the first game application on multiple terminals of the same model. The terminal identification information can be used by the server to identify multiple terminals of the same model, so as to obtain more accurate configuration parameters for each terminal. For example, the terminal identification information may be an Internet Protocol (IP) address, a Media Access Control (MAC) address, or other identification information that distinguishes it from other terminals.

[0181] Through steps S31 and S32, the server can collect second game running data when multiple terminals run the first game application in the first scene. These multiple terminals are of the same model, all being the first model. For ease of understanding of the embodiments of this application, the second game running data collected by the server from multiple terminals will be referred to as first game running data below. That is, the first game running data can be understood as multiple sets of second game running data.

[0182] For example, the server can also receive game running data of the first game application on different models of terminals. For example, the server can maintain this game running data, such as storing the game running data of the first game application on multiple terminals using the terminal model information as an index. For ease of understanding, Table 5 shows an example of game running data maintained by the server. Taking Knives Out as an example, Table 5 shows the game running data of the same game application on multiple terminals of different models.

[0183] Table 5

[0184]

[0185] S33: The server trains the first parameter recommendation model based on the first game running data.

[0186] The first game operation data includes the second game operation data in step S32. This first game operation data can be game operation data obtained during the public beta phase, game operation data obtained during the live beta phase, or game operation data obtained during both the public beta and live beta phases; this application embodiment does not limit this.

[0187] The server can train the first parameter recommendation model based on the first game's runtime data. For example, the server can construct training samples based on the first game's runtime data and train the first parameter recommendation model based on the training samples until the model meets expectations, and then save the first parameter recommendation model, as shown in Table 2. The training sample data may include the terminal's model information, the identifier of the first game application, the identifier of the first scene, and the first game's runtime data (scene parameters and performance parameters).

[0188] After training, the first parameter recommendation model can be used to recommend configuration parameters for a terminal of a first model in a first scenario of a first game application. The input to the first parameter recommendation model can be the terminal model information and the game application's identification information. The output can include, but is not limited to, one or more of the following parameters: the identification information of the first scenario, and the operating frequency, temperature, memory size, network speed of the chip (such as CPU, and / or GPU) corresponding to the identification information of the first scenario, or data information (such as the number, network speed, etc.) of other applications running simultaneously.

[0189] For example, the server can periodically (e.g., weekly, or monthly) update the first parameter recommendation model based on the acquired game running data; alternatively, it can update the first parameter recommendation model non-periodically based on the acquired game running data. For instance, when the amount of acquired game running data reaches a set threshold (e.g., 1000 sets of second game running data), the server can update the first parameter recommendation model based on the acquired game running data. As another example, when the ratio between the number of terminals sending second game running data and the number of terminals currently installing the first game application of the first model reaches a set proportion (e.g., 10%, or 15%), the server can update the first parameter recommendation model based on the acquired game running data.

[0190] S34: The server obtains the first configuration parameter based on the first parameter model.

[0191] After the first parameter recommendation model is trained, the server can input the terminal model information and the identifier information of the first game application into the first parameter recommendation model to obtain the first configuration parameters. These first configuration parameters can be used to configure the hardware resources, software resources, or both available resources for the first game application in a first scenario when the first game application is running on a first-model terminal.

[0192] The first configuration parameter may include the identification information of the first scenario, and one or more of the following parameters corresponding to the identification information of the first scenario: CPU operating frequency, GPU operating frequency, number of CPU cores, GPU size, maximum temperature for triggering temperature control strategy, or network speed priority, etc.

[0193] It should be noted that the first scenario in the embodiments of this application may refer to one or more scenarios. Accordingly, when the first scenario is a single scenario, the first configuration parameter can be used to configure the hardware resources and / or software resources that the first game application can use in that single scenario; when the first scenario is multiple scenarios, the first configuration parameter can be used to configure the hardware resources and / or software resources that the first game application can use in those multiple scenarios.

[0194] In step S34, the server can obtain the first configuration parameters based on the first parameter recommendation model after the model has been trained. In another possible implementation, the server can store the trained first parameter recommendation model locally and receive a first request message from the terminal. The first request message includes the terminal's model information and the identifier of the first game application. For example, the terminal can send the first request message to the server periodically (e.g., weekly), or it can send the first request message non-periodically, such as after a version update of the first game application. Further, in response to the first request message, the server can obtain the first configuration parameters based on the first parameter recommendation model and send a first response message to the terminal device, which includes the first configuration parameters.

[0195] After determining the first configuration parameter, the server can update the first configuration parameter to the recommended configuration parameter for the first game application on the first model terminal, or it can verify the first configuration parameter by executing the content of step S35. This can determine whether the first configuration parameter can optimize the running performance of the first game application on the first model terminal and improve reliability.

[0196] S35: The server verifies the first configuration parameter. If the verification of the first configuration parameter passes, the process ends; if the verification of the first configuration parameter fails, the server executes the content of step S33.

[0197] After determining the first configuration parameters, the server can verify them to determine whether they effectively optimize the first game application for the first scenario running on the first type of terminal. For example, the server can verify the first configuration parameters once or multiple times using a cloud-based virtual machine. Specifically, the cloud-based virtual machine can simulate the first type of terminal, run the first scenario of the first game application according to the first configuration parameters, and collect third performance parameters when the cloud-based virtual machine runs the first scenario of the first game application according to the first configuration parameters. Then, the server verifies the first configuration parameters based on the third and fourth performance parameters. For example, the server can determine whether the first configuration parameters effectively optimize the first game application for the first scenario running on the first type of terminal by comparing the third and fourth performance parameters.

[0198] The fourth performance parameter is stored on the server. For example, the fourth performance parameter may be a predefined performance parameter or a performance parameter corresponding to the third configuration parameter. For instance, when a cloud-based real device simulates a first-model terminal and runs a first scene of a first game application according to the third configuration parameter, the performance parameters (i.e., the third performance parameter) of the cloud-based real device running the first scene of the first game application according to the third configuration parameter are obtained and stored. The third configuration parameter may be the default configuration parameter of the first-model terminal at the factory, or the configuration parameter from the last server update, or the configuration parameter after the system version update of the first-model terminal, or the configuration parameter after the version update of the first game application, etc. This application embodiment does not limit this.

[0199] It is understood that the third configuration parameter can be the same as the second configuration parameter in step S31 (e.g., both are the default configuration parameters when the first model terminal is shipped from the factory), or they can be different (e.g., the second configuration parameter is the default configuration parameter, and the third configuration parameter is the configuration parameter updated by the server).

[0200] The server can combine verification metrics to verify the first configuration parameter using a third performance parameter and a fourth performance parameter. These verification metrics can be predefined, provided by the first game application distributor, or provided by the terminal supplier, etc., and this application does not limit this. For example, the server can determine one or more parameters in the third performance parameter that are superior to the fourth performance parameter based on the verification metrics, and then determine whether the verification passes based on these one or more parameters. For example, the server can use a scoring system, scoring each parameter in the third performance parameter based on the fourth performance parameter to obtain a score for the third performance parameter, and then determining whether the verification passes based on whether the ratio between the score of the third performance parameter and the total score reaches a set threshold.

[0201] For ease of understanding, Table 6 shows an example of a validation metric. Taking a total score of 100 points for the verification indicators as an example, Table 6 shows that: when the rendering time of the first frame in the third performance parameter is shorter or the same as that in the fourth performance parameter, the third performance parameter scores 15 points; otherwise, it scores 0 points. When the average frame rate in the third performance parameter increases by more than or equal to 10% compared to the average frame rate in the fourth performance parameter, the third performance parameter scores 10 points; if the increase is greater than 0 but less than 10%, it scores 7 points; if it does not increase, it scores 0 points. When the jitter rate in the third performance parameter decreases by more than or equal to 10% compared to the jitter rate in the fourth performance parameter, the third performance parameter scores 10 points; if the decrease is greater than 0 but less than 10%, it scores 7 points; if it does not decrease, it scores 0 points. When the number of stutters in the third performance parameter decreases by more than or equal to 10% compared to the number of stutters in the fourth performance parameter, the third performance parameter scores 15 points; if the decrease is greater than 0 but less than 10%, it scores 12 points; if it does not decrease, it scores 0 points. If the frame rate decreases, the third performance parameter scores 0 points. If the low frame rate ratio in the third performance parameter decreases by 10% or more compared to the low frame rate ratio in the fourth performance parameter, the third performance parameter scores 10 points; if the decrease is greater than 0 but less than 10%, the third performance parameter scores 7 points; if it does not decrease, the third performance parameter scores 0 points. If the power consumption in the third performance parameter decreases by 5% or more compared to the power consumption in the fourth performance parameter, the third performance parameter scores 15 points; if the decrease is greater than 0 but less than 5%, the third performance parameter scores 12 points; if it does not decrease, the third performance parameter scores 0 points. If the device casing temperature in the third performance parameter decreases or remains the same compared to the device casing temperature in the fourth performance parameter, the third performance parameter scores 15 points; otherwise, the third performance parameter scores 0 points. If the frame drop rate in the third performance parameter decreases by 10% or more compared to the frame drop rate in the fourth performance parameter, the third performance parameter scores 10 points; if the decrease is greater than 0 but less than 10%, the third performance parameter scores 7 points; if it does not decrease, the third performance parameter scores 0 points. Using Table 6, the server can obtain the score of the third performance parameter. When the score of the third performance parameter is greater than or equal to a set threshold (such as 90 points or 80 points), the server can determine that the third performance parameter has passed verification; otherwise, the server determines that the third performance parameter has failed verification. It is understood that the data in Table 6 are merely examples used to facilitate understanding of the embodiments of this application, but the embodiments of this application are not limited thereto.

[0202] Table 6

[0203]

[0204] In step S35, the server may verify the first configuration parameter once or multiple times; this embodiment does not limit the number of verifications. For example, if the verification fails once, the server determines that the verification of the first configuration parameter has failed and retrains the first parameter recommendation model, i.e., executes step S33; otherwise, the server determines that the verification of the first configuration parameter has passed, and the process ends. As another example, if the verification is performed multiple times, if the set number of verifications (e.g., 10% of the total number of verifications) fails multiple times, the server determines that the verification of the first configuration parameter has failed and executes step S33; otherwise, the server determines that the verification of the first configuration parameter has passed, and the process ends.

[0205] If the verification of the first configuration parameter fails, the server can retrain the first parameter configuration model, such as adjusting the parameters in the model and retraining it based on the first game running data, i.e., executing steps S33 and S34, until the verification passes or the server sends the message of failure to the administrator for manual location.

[0206] If the first configuration parameter passes verification, the server can update the first configuration parameter to the recommended parameter for the first scene of the first game application on the first model of the terminal. According to Figure 3 The process shown illustrates how the server can obtain and maintain recommended parameters for different game applications, terminals, and scenarios. For ease of understanding, Table 7 provides an example of the configuration parameters maintained by the server. Taking Knives Out and Honor of Kings as examples, Table 7 shows the configuration parameters corresponding to different game applications, models, and scenarios.

[0207] Table 7

[0208]

[0209] exist Figure 3 In the illustrated process, the first configuration parameter is an optimization strategy derived by the server based on extensive game performance data generated by the first game application running on multiple terminals of the first model. Different terminal models have different hardware resources. The server simulates the first model's terminals using a cloud-based virtual machine, thus replicating the game application's operating environment on those terminals. Running the first game application on the cloud-based virtual machine based on the first configuration parameter allows the collection of performance parameters for the first scene running on the first model's terminals. These performance parameters are then used to verify the first configuration parameter. Only after successful verification is the first configuration parameter sent to the first model's terminals. This ensures that the first configuration parameter improves the performance of the first game application's first scene on the first model's terminals, enhancing both user experience and the reliability of the first configuration parameter.

[0210] At this point, the process of the server determining the first configuration parameter is complete.

[0211] The process of the server determining the first configuration parameter has been described above. The process of the terminal optimizing performance based on the first configuration parameter is described below.

[0212] Figure 4 A schematic flowchart of a performance optimization method provided in an embodiment of this application is shown. Figure 4 As shown, the flow of this method is as follows.

[0213] S41: The server sends the first configuration parameters to the terminal. Correspondingly, the terminal receives the first configuration parameters from the server.

[0214] The first configuration parameter is a server-recommended parameter used to optimize the performance of the first game application during terminal operation. Specifically, this first configuration parameter can be a parameter determined and verified by the server based on game operation data from multiple terminals running the first scene of the first game application. This first configuration parameter can be used to configure the hardware resources, software resources, or both available hardware and software resources for the first game application running on a first-model terminal in the first scene. All multiple terminals are of the same model, such as the first model. For a detailed description of the first configuration parameter, please refer to the description related to the first configuration parameter in step S34 above, which will not be repeated here.

[0215] In step S41, the server can proactively push the updated configuration parameters, i.e., the first configuration parameters, to the terminal. For example, after the new configuration parameters are verified, the server can update the locally stored configuration parameters and push the updated configuration parameters to the terminal. For instance, during the public beta testing phase, the server can proactively push the updated configuration parameters to the terminal based on the terminal's identification information.

[0216] Alternatively, the terminal can send a first request message to the server. Correspondingly, upon receiving the first request message, the server can send a first response message to the terminal. The first request message may include the terminal's model information and the identifier of the first game application, while the first response message includes first configuration parameters. For example, the terminal can send the first request message to the server when the first game application starts, such as when a user clicks the icon of the first game application on the terminal's display interface. In response, the terminal starts the first game application and sends the first request message to the server. Upon receiving the first request message, the server can send a first response message to the terminal, or determine the first configuration parameters based on the first parameter recommendation model and send the first response message to the terminal. As another example, the terminal can periodically (e.g., every morning or every Sunday). Correspondingly, upon receiving the first request message, the server can send a first response message to the terminal, or determine the first configuration parameters based on the first parameter recommendation model and send the first response message to the terminal.

[0217] The first request message mentioned above can be used to request updated configuration parameters, or it can be used to request configuration parameters.

[0218] For example, when the first request message is used to request updated configuration parameters, after receiving the first request message, the server can determine whether the configuration parameters of the first game application have been updated based on the terminal's model information and the identifier information of the first game application. If the configuration parameters of the first game application have been updated, the server sends a first response message to the terminal including the updated configuration parameters. If the configuration parameters of the first game application have not been updated (e.g., the updated configuration parameters have already been sent to the terminal), the server sends a first response message to the terminal that can be a negative acknowledgment (NACK) message. Furthermore, the terminal can run the first game application according to the second configuration parameters.

[0219] For example, when the first request message is used to request configuration parameters, after receiving the first request message, the server can determine the configuration parameters of the first game application as the first configuration parameters based on the terminal's model information and the identification information of the first game application; or, it can input the terminal's model information and the identification information of the first game application into the first parameter recommendation model to obtain the first configuration parameters. The server sends a first response message to the terminal, which includes the first configuration parameters. In this case, the first configuration parameters and the second configuration parameters can be the same or different.

[0220] S42: During the operation of the first game application, the terminal runs the first scene of the first game application according to the first configuration parameters.

[0221] After receiving the first configuration parameters from the server, the terminal can run the first scene of the first game application during its operation. For example, the terminal can store the first configuration parameters in the system directory using XML format, which can be invoked when the first game application runs. The first configuration parameters include scene identification information, etc. These parameters are specific to the first scene, which can be one or more scenes. Correspondingly, the first configuration parameters can include configuration parameters corresponding to one scene or multiple scenes. The scene identification information can be used to distinguish which scene the configuration parameters are applied to. Specifically, the terminal can determine the first scene during the operation of the first game application and run that first scene according to the first configuration parameters. For example, the terminal can call the game service SDK integrated into the first game application during its operation; the game service SDK determines whether the current scene is the first scene; if the current scene is determined to be the first scene, the terminal retrieves the configuration parameters corresponding to the first scene from the system directory based on the first scene's identification information and runs the first scene based on these configuration parameters.

[0222] During the operation of the first game application, the terminal configures parameters according to the first configuration parameters. For ease of understanding, Table 8 shows the corresponding configuration parameters for different scenarios. As shown in Table 8, if the current scenario is Scenario 1, the terminal can limit the GPU frequency according to the temperature control strategy, but not limit the CPU frequency, and prioritize the allocation of CPU big and small core resources to the first game application; if the current scenario is Scenario 2, the terminal can set the highest network speed priority to the first game application; if the current scenario is Scenario 3, the terminal can increase the maximum temperature of the temperature control strategy by 2 degrees Celsius, i.e., 50 degrees Celsius; if the current scenario is Scenario 4, the terminal can add 4MB of GPU cache resources and 4 CPU big and small cores to the first game application.

[0223] Table 8

[0224]

[0225] Taking the first configuration parameter for configuring two scenarios as an example, in the first scenario, the server recommends the following configuration parameters: an average frame rate of 60 frames per second, a frequency throttling policy triggered when the device casing temperature exceeds 50 degrees Celsius, limiting the GPU's operating frequency according to the temperature control policy, not limiting the CPU's operating frequency, network speed as the highest priority, 4 CPU cores each for big and small cores, and 4 megabytes (mbytes, M) of GPU cache. In the second scenario, the server recommends the following configuration parameters: an average frame rate of 50 frames per second, a frequency throttling policy triggered when the device casing temperature exceeds 45 degrees Celsius, not limiting the GPU's operating frequency, and limiting the CPU's operating frequency according to the temperature control policy. In this case, the format of the first configuration parameter recommended by the server to the terminal can be as follows:

[0226]

[0227]

[0228] S43: When running the first scene of the first game application according to the first configuration parameters, the terminal verifies the first configuration parameters. If the verification of the first configuration parameters passes, the terminal continues to run the first scene of the first game application according to the first configuration parameters, and the process ends; if the verification of the first configuration parameters fails, the terminal executes the content of S44.

[0229] During the execution of a first scenario of a first game application based on first configuration parameters, the terminal can verify the first configuration parameters to determine whether they effectively optimize the first scenario of the first game application running on the terminal. For example, the terminal can collect first performance parameters when running the first scenario of the first game application based on the first configuration parameters, and then verify the first configuration parameters based on the first performance parameters and second performance parameters. For example, the terminal can determine whether the first configuration parameters can optimize the performance of the first game application running on the terminal in the first scenario by comparing the second performance parameters and the first performance parameters. The second performance parameters can be stored locally on the terminal. For example, the second performance parameters can be predefined or be performance parameters corresponding to the second configuration parameters. For instance, if the terminal runs the first game application based on the second configuration parameters, obtains the performance parameters (i.e., the second performance parameters) in the first scenario during the running process, and stores them.

[0230] The terminal can verify the first configuration parameter by combining verification metrics with the first performance parameter and the second performance parameter. These verification metrics can be predefined, provided by the first game application distributor, or provided by the terminal supplier, etc., and this application does not limit them. The specific implementation process can be found in step S35 above, and will not be repeated here.

[0231] Optionally, once the verification of the first configuration parameter is successful, the terminal can delete the local second configuration parameter to improve the utilization of storage resources.

[0232] S44: The terminal runs the first scenario of the first game application according to the second configuration parameters.

[0233] When the verification of the first configuration parameter fails, the terminal runs the first scene of the first game application according to the second configuration parameter. This second configuration parameter is stored locally on the terminal. Specifically, the second configuration parameter can be a configuration parameter currently stored locally on the terminal; for example, it could be the default configuration parameter when the terminal was manufactured, the configuration parameter recommended by the server in the last update, the configuration parameter after the terminal system version update, or the configuration parameter after the first game application version update, etc. This embodiment of the application does not limit this.

[0234] As an electronic device, a terminal's performance is affected by factors such as usage frequency, usage duration, and system version updates. Taking mobile phones as an example, a phone's performance is best when it's first released. However, as user usage time increases or the system is updated once or multiple times, the phone's performance gradually declines, for example, the available memory resources decrease. Through steps S43 and S44, during the process of running the first scenario of the first game application according to the first configuration parameters, the terminal re-verifies the first configuration parameters that have been verified by the server. This avoids negative optimization issues caused by individual differences among terminals of the same model. Furthermore, when negative optimization occurs, the terminal can restore the original second configuration parameters and run the first scenario of the first game application based on these second configuration parameters. This ensures effective optimization of the first game application and improves the user experience.

[0235] S45: The terminal sends an exception message to the server. The server then receives the exception message.

[0236] When the verification of the first configuration parameter fails, the terminal can also send an exception message to the server. Correspondingly, the server receives the exception message from the terminal. This exception message may include the terminal's model information, the identifier information of the first application, and game running data from the first scene of the first game application run by the terminal based on the first configuration parameter. Furthermore, when the ratio between the number of terminals reporting exception messages and the number of terminals currently installing the first model of the first game application (e.g., the server can obtain the number of terminals currently installing the first model of the first game application by counting the number of downloaded first game application compressed packages) reaches a set ratio (e.g., 10%), the server re-determines the configuration parameters based on the game running data in the exception message, i.e., executes step S33.

[0237] For example, Figure 5AAn example of a software architecture for a communication system is shown. For example... Figure 5A As shown, the system architecture includes a cloud side and a terminal side. Figure 5A Taking terminal 1 and terminal 2 as examples (and terminal 1 and terminal 2 are of the same model), in this example, multiple terminals of the same model report game operation data during the operation of the first game application to the cloud side. The cloud side includes a data reporting module, and the terminal side includes a first game application module, an APK collection module, and a system performance module.

[0238] The first game application module can execute... Figure 4 S42, S44, etc., in the illustrated embodiment are used to run the first game application. The first game application module integrates a game service SDK, which can execute... Figure 3 In the illustrated embodiment, S31, etc., is used to collect scene parameters when the first game application module runs the first scene of the first game application, and send the scene parameters to the collecting APK.

[0239] The system performance module can execute... Figure 3 In the illustrated embodiment, S31, etc., is used to collect performance parameters when the first game application module runs the first scene of the first game application, and send the performance parameters to the collection APK.

[0240] Collect APKs, which can be executed. Figure 3 S31, S32, etc. in the illustrated embodiment are used to obtain scene parameters and performance parameters when the first game application module calculates the first scene of the first game application, and report the collected scene parameters and performance parameters to the cloud side.

[0241] The data reporting module can execute... Figure 3 S32, etc. in the illustrated embodiment, is used to collect game running data sent by the terminal and perform processing such as data storage.

[0242] exist Figure 5A In the scenario shown, the cloud-side data reporting module can collect game performance data of the first game application running on multiple terminals of the same model. This game performance data can be collected during the public beta phase, the live beta phase, or both. For example, before the first game application is released, the data reporting module can be understood as the public beta big data module, used to collect game performance data of the first scenario of the first game application running on multiple terminals of the same model during the public beta phase; after the first game application is released, the data reporting module can be understood as the live beta big data module, used to collect game performance data of the first scenario of the first game application running on multiple terminals of the same model during the live beta phase.

[0243] For example, Figure 5B Another example of the software architecture of a communication system is shown. For example... Figure 5B As shown, the system architecture includes a cloud side and a terminal side. In this example, the terminal side obtains the first configuration parameters from the cloud side and verifies these first configuration parameters during the operation of the first game application.

[0244] The cloud-based component includes a data reporting module, an artificial intelligence (AI) module, a cloud-based physical device module, and a configuration module. For details on the implementation of the data reporting module, please refer to [link to relevant documentation]. Figure 5A The description in the text will not be repeated here.

[0245] The AI ​​module can execute Figure 3 S33, S34, etc., in the illustrated embodiment are used to obtain game operation data of the first game application from the data reporting module, train the first parameter recommendation model based on this game operation data, and obtain the first configuration parameters based on the trained first parameter recommendation model. This game operation data can be game operation data from the public beta phase, game operation data from the live server phase, or game operation data from both the public beta and live server phases. For example, before the first game application is released, this game operation data is from the public beta phase; after the first game application is released, this game operation data can be from the live server phase, or game operation data from both the live server and public beta phases.

[0246] The cloud real device module can execute... Figure 3 S35, etc. in the illustrated embodiment, is used to verify the first configuration parameter based on the third performance parameter and the fourth performance parameter.

[0247] The configuration module can be executed. Figure 4 S41, etc. in the illustrated embodiment, is used to send the verified configuration parameters in the cloud real machine module to the terminal.

[0248] The terminal side includes: a first game application module, a data acquisition APK, a system performance module, and a verification module. The implementation process of the first game application module, the data acquisition APK, and the system performance module can be found in [link to documentation]. Figure 5A The description in the text will not be repeated here.

[0249] Collect APKs, and you can also execute them. Figure 4S41, etc., in the illustrated embodiment, is used to obtain configuration parameters from the cloud side. For example, the collection APK actively sends a request message to the configuration module to obtain the first configuration parameters and receives the first configuration parameters from the configuration module; or, the collection APK passively receives the first configuration parameters pushed by the configuration module. For example, during the public beta testing phase, the configuration module can actively push the first configuration parameters to the collection APK based on the terminal's identification information.

[0250] The system performance module is used to write the first configuration parameters to the corresponding performance components to configure the terminal's software and / or hardware resources, such as execution. Figure 4 S42, S44, etc. in the illustrated embodiment.

[0251] The verification module can be executed. Figure 4 S43, etc., in the illustrated embodiment, is used to verify the first configuration parameters recommended by the cloud side and feed the verification result back to the system performance module. For example, if the verification fails, the system performance module writes the second configuration parameters into the corresponding performance component to run the first scenario of the first game application based on the second configuration parameters; otherwise, it continues to run a scenario of the first game application based on the first configuration parameters.

[0252] The following is combined Figure 5A and Figure 5B The system architecture shown illustrates the performance optimization method provided in the embodiments of this application. Figure 6 A flowchart illustrating the performance optimization method provided in an embodiment of this application is shown.

[0253] S601: The terminal runs the first game application according to the second configuration parameters. The terminal model is the first model.

[0254] For example, the terminal can run a first scene of the first game application according to the second configuration parameters. For a description of the second configuration parameters, please refer to the description of the second configuration parameters in step S31 above, and it will not be repeated here.

[0255] S602: The first game application module sends the second scene parameters to the acquisition APK. Correspondingly, the acquisition APK receives the second scene parameters.

[0256] During the operation of the first game application, the game service SDK integrated in the first game application module can identify high-load scenarios (i.e., the first scenario) during the operation of the first game application, collect scenario parameters under the high-load scenario, and then send the collected scenario parameters to the collecting APK. The second scenario parameters may include one or more of the following: high-load scenario entry / exit identifier, scenario type, or instance data. The specific implementation of step S602 can be found in the aforementioned... Figure 3 The content described in step S31 will not be repeated here.

[0257] S603: The system performance module sends the second performance parameter to the acquisition APK. Correspondingly, the acquisition APK receives the second performance parameter.

[0258] During the operation of the first game application, the APK can obtain second performance parameters through the system performance module based on the second scene parameters reported by the SDK, such as the high-load scene entry / exit indicator. These second performance parameters may include one or more of the following: rendering time of the first frame, average frame rate, jitter rate, low frame rate ratio, power consumption, device casing temperature, or number of dropped frames. The specific implementation of step S603 can be found in the aforementioned... Figure 3 The content described in step S31 will not be repeated here.

[0259] S604: The APK collects the second game's runtime data and sends it to the cloud server. The data reporting module on the cloud server receives the first game's runtime data.

[0260] The second game operation data includes the terminal model information, the identification information of the first application, the second scene parameters, and the second performance parameters. Optionally, the second game operation data may also include the terminal identification information. The specific implementation of step S604 can be found in the preceding text. Figure 3 The content described in step S32 will not be repeated here.

[0261] Through steps S601 to S604, the data reporting module can collect second game running data from multiple terminals of the same model, denoted as first game running data. The first game running data includes the second game running data.

[0262] S605: The data reporting module sends the first game running data to the AI ​​module. Correspondingly, the AI ​​module receives the first game running data.

[0263] For example, the data reporting module can periodically (e.g., weekly, or monthly) send the acquired game operation data to the AI ​​module; alternatively, it can send the data non-periodically. For instance, when the amount of acquired game operation data reaches a set threshold (e.g., 1000 sets of second game operation data), the data reporting module will send the acquired game operation data to the AI ​​module. As another example, when the ratio between the number of terminals sending second game operation data and the number of terminals currently installing the first game application of the first model reaches a set proportion (e.g., 10% or 15%), the data reporting module will send the acquired game operation data to the AI ​​module.

[0264] S606: The AI ​​module trains a first-parameter recommendation model based on the first game's running data.

[0265] For example, the AI ​​module can construct training samples based on the first game's running data, and then train the first parameter recommendation model based on these training samples. The specific implementation of step S606 can be found in the aforementioned section. Figure 3 The content described in step S33 will not be repeated here.

[0266] S607: The AI ​​module obtains the first configuration parameters based on the first parameter and the recommended model.

[0267] For example, the AI ​​module can input the terminal's model information and the identifier of the first game application into the first parameter recommendation model to obtain the first configuration parameters. The first configuration parameters may include, but are not limited to, one or more of the following parameters: CPU operating frequency, GPU operating frequency, number of CPU cores, GPU size, maximum temperature to trigger the temperature control strategy, or network speed priority, etc. The specific implementation of step S607 can be found in the aforementioned... Figure 3 The content described in step S34 will not be repeated here.

[0268] S608: The AI ​​module sends the first configuration parameters to the cloud real device module. Correspondingly, the cloud real device module receives the first configuration parameters.

[0269] S609: The AI ​​module verifies the first configuration parameter.

[0270] The AI ​​module can verify the first configuration parameter based on the third and fourth performance parameters. The specific implementation of step S609 can be found in the preceding text. Figure 3 The content described in step S35 will not be repeated here. If the verification fails, the cloud real device module can send the verification failure message to the AI ​​module so that the AI ​​module can retrain the first parameter configuration module, that is, repeat the content of steps S606 to S609. If the verification passes, the cloud real device module can send the first configuration parameters to the configuration module.

[0271] S610: The cloud-based real device module sends the first configuration parameter to the configuration module. Correspondingly, the configuration module receives the first configuration parameter. After receiving the first configuration parameter, the configuration module can update the configuration parameters, such as deleting the locally stored third configuration parameter and storing the first configuration parameter.

[0272] For example, after receiving the first configuration parameters, the configuration module can actively push the first configuration parameters to one or more terminals of the first model that have the first game application installed, so that the one or more terminals can run the first game application according to the first configuration parameters after launching the first game application next time.

[0273] Alternatively, the configuration module may not actively push the first configuration parameters to the terminal. For example, when the terminal launches the first game application, the data collection APK can actively request the first configuration parameters from the configuration module. For instance, the data collection APK sends a first request message to the configuration module, which includes the terminal's model information and the identification information of the first game application; the configuration module then sends a first response message to the data collection APK, which includes the first configuration parameters.

[0274] The specific implementation of step S610 can be referred to the above. Figure 4 The content described in step S41 will not be repeated here. In this example, we will take the example of the configuration module actively recommending the first configuration parameter to the terminal.

[0275] S611: The configuration module sends the first configuration parameter to the acquisition APK.

[0276] The configuration module can push the first configuration parameters to the collection APK of one or more terminals. Multiple terminals all have the first game application installed, and all of these terminals are of the same model. For example, the configuration model can determine the terminal's identification information based on its internet access information and push the first configuration parameters to that terminal based on that identification information. Alternatively, the configuration module can push the first configuration parameters to the terminal based on the terminal's identification information in the game operation data reported by the terminal during the public beta phase. The first configuration parameters may include the identification information of the first scene, and one or more of the following parameters corresponding to the identification information of the first scene: CPU operating frequency, GPU operating frequency, number of CPU cores, GPU size, maximum temperature for triggering temperature control strategies, or network speed priority, etc.

[0277] S612: The terminal launches the first game application.

[0278] S613: The APK sends the first configuration parameters to the system performance module. Correspondingly, the system performance module receives the first configuration parameters.

[0279] After receiving the first configuration parameter, the APK sends it to the system performance module. The system performance module can configure the software resources, hardware resources, or both available software and hardware resources that the first game application can use in the first scenario during its operation, based on the first configuration parameter, that is, write the parameter into the corresponding performance component of the system.

[0280] S614: The terminal runs the first scene of the first game application according to the first configuration parameters. The specific implementation methods of steps S613 and S614 can be found in the preceding description. Figure 4 The content described in step S42 will not be repeated here.

[0281] S615: The system performance module sends the first performance parameter to the verification module. Correspondingly, the verification module receives the first performance parameter.

[0282] During the execution of the first game application according to the first configuration parameters, the system performance module can collect the first performance parameters under the first scenario and send the first performance parameters to the verification module. For example, the system performance module can determine the first performance parameters based on the high-load scenario entry / exit identifier in the first scenario parameters collected by the game service SDK, wherein the first scenario parameters are the scenario parameters corresponding to the first scenario during the execution of the first game application according to the first configuration parameters.

[0283] S616: Verify whether the verification module passes the verification of the first configuration parameter. If the verification module passes the verification of the first configuration parameter, then execute the steps shown in step S617 to continue running the first game application using the first configuration parameter; otherwise, execute the steps shown in steps S617 to S619.

[0284] The specific implementation of step S616 can be referred to the above. Figure 4 The content described in step S43 will not be repeated here.

[0285] S617: The terminal continues to run the first scenario of the first game application according to the first configuration parameters.

[0286] Optionally, the terminal can remove the local second configuration parameter to improve the utilization of storage resources.

[0287] S618: The verification module sends a verification failure message to the collection APK. Correspondingly, the collection APK receives the verification failure message.

[0288] S619: The APK sends an exception message to the data reporting module. Correspondingly, the data reporting module receives the exception message.

[0289] The error message includes the terminal's model information, the identifier of the first game application, and the first scene parameters and first performance parameters. Specifically, if the verification fails, the APK can collect the first scene parameters and first performance parameters when the first game application is run according to the first configuration parameters, and send the collected first scene parameters and first performance parameters to the data reporting module. The specific implementation of step 619 can be found in the previous section. Figure 4 The content described in step S45 will not be repeated here.

[0290] S620: The terminal runs the first scenario of the first game application according to the second configuration parameters.

[0291] If the verification fails, the terminal runs the first game application according to the second configuration parameters. The specific implementation of step 620 can be found in the previous section. Figure 4 The content described in step S44 will not be repeated here.

[0292] Understandable Figure 6 The execution order of each step is merely an example, and this application embodiment does not limit it. For example, the collection APK can first obtain the second scene parameters and then obtain the second performance parameters; or it can obtain the second scene parameters and the second performance parameters simultaneously. Another example is that when the terminal launches the first game application, it triggers the collection APK to obtain the first configuration parameters; alternatively, the configuration module can obtain the first configuration parameters and then actively send them to the collection APK. Yet another example is that when verification fails, the terminal can first send an exception message to the data reporting module and then run the first game application according to the second configuration parameters; alternatively, it can run the first game application according to the second configuration parameters while simultaneously sending the exception message to the data reporting module.

[0293] Figure 7 This illustration shows another flowchart of the performance optimization method provided in an embodiment of this application. In this example, the terminal triggers the server to obtain the first configuration parameters. Steps S701 to S706, S710 to S712, and S714 to S722 are respectively related to... Figure 6 Steps S601 to S606, S608 to S610, and S612 to S620 in the illustrated embodiment are the same, except that:

[0294] S707: The acquisition APK sends a first request message to the configuration module. Correspondingly, the configuration module receives the first request message.

[0295] The first request message includes the terminal's model information and the identifier of the first game application. This first request message is used to request configuration parameters of the first game application. For example, the terminal can send the first request message to the server periodically (e.g., weekly), or it can send the first request message to the server non-periodically, such as after the first game application version is updated.

[0296] S708: The configuration module forwards the first request message to the AI ​​module. Correspondingly, the AI ​​module receives the first request message.

[0297] S709: The AI ​​module recommends a model based on the first parameter and obtains the first configuration parameter.

[0298] After receiving the first request message, the AI ​​module, in response, inputs the terminal model information and the identifier information of the first game application into the first parameter recommendation model to obtain the first configuration parameters.

[0299] S713: The configuration module sends a first response message to the acquisition module. In response, the acquisition module receives the first response message. The first response message includes the first configuration parameters.

[0300] It should be noted that after the AI ​​module receives the first configuration parameter in response to the first request message, it can verify the first configuration parameter through the cloud real device module and send the verified configuration parameter to the terminal in the first response message. Alternatively, after the AI ​​module receives the first configuration parameter in response to the first request message, it can also directly send the first configuration parameter to the terminal device in the first response message. This can reduce the time for the cloud to respond to the first request message.

[0301] Understandable Figure 7 The execution order of each step is merely an example, and this application embodiment does not limit it. For example, the collection APK can send the first request message to the cloud before obtaining the first configuration parameters from the cloud, or it can send the first request message to the cloud after the first game application starts. Specifically, the collection APK sends the first request message to the configuration module in the cloud when the first game application starts, that is, the collection APK sends the first request message to the configuration module after step S714; correspondingly, after receiving the first request message, the configuration module, as a response, sends the first configuration parameters in a first response message to the collection APK.

[0302] The terminology used in the above embodiments is for the purpose of describing specific embodiments only and is not intended to be a limitation of this application.

[0303] Based on the above embodiments, this application also provides a computer storage medium storing a computer program, which, when executed by a computer, causes the computer to perform the performance optimization method for the application provided in the above embodiments.

[0304] This application also provides a computer program product, including instructions that, when run on a computer, cause the computer to execute the performance optimization method for the application provided in the above embodiments.

[0305] This application describes embodiments of methods, apparatus (systems), and computer program products according to embodiments of this application with reference to flowchart illustrations and / or block diagrams. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by instructions. These instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0306] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0307] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0308] The above description of the embodiments is only used to provide a detailed introduction to the technical solutions of this application. However, the description of the above embodiments is only for the purpose of helping to understand the methods of the embodiments of the present invention and should not be construed as a limitation of the embodiments of the present invention. Variations or substitutions that can be easily conceived by those skilled in the art should be covered within the protection scope of the embodiments of the present invention.

Claims

1. A method for optimizing the performance of a terminal, characterized in that, The method includes: The server receives first operational data from multiple terminals. The first operational data includes operational data of the multiple terminals running a first scenario of a first application. The models of the multiple terminals are first models. The first operational data includes the first model, the identification information of the first application, scenario parameters, and performance parameters. The scenario parameters include: first scenario entry / exit identifier, scenario type, and instance data. The server determines a first configuration parameter based on the identification information of the first model, the first application, and the first running data. The first configuration parameter is used to configure the terminal when the terminal of the first model is running the first application in a first scenario. The server sends the first configuration parameters to the first terminal, wherein the model of the first terminal is the first model. The first terminal receives a first configuration parameter from the server, wherein the first configuration parameter includes configuration parameters corresponding to a first scenario of the first application; The first terminal determines the first scenario when the first application is running; The first terminal verifies the first configuration parameters based on the first performance parameter and the second performance parameter, wherein the first performance parameter is the performance parameter of the first terminal when running the first application in the first scenario based on the first configuration parameter, and the second performance parameter is the performance parameter of the first terminal when running the first application in the first scenario based on the second configuration parameter; If the first configuration parameter verification passes, the first terminal runs the first scenario of the first application according to the first configuration parameter; if the first configuration parameter verification fails, the first terminal runs the first scenario of the first application according to the second configuration parameter and sends an exception message to the server.

2. The method according to claim 1, characterized in that, Before the server sends the first configuration parameter to the first terminal, the method further includes: The server verifies the first configuration parameter and determines that the verification of the first configuration parameter is successful.

3. The method according to claim 1 or 2, characterized in that, Before the server sends the first configuration parameter to the first terminal, the method further includes: The first terminal sends a first request message to the server. The first request message includes the identification information of the first model and the first application. The first request message is used to request the acquisition of the first configuration parameters. The server receives the first request message from the first terminal.

4. The method according to claim 1 or 2, characterized in that, Before the first terminal receives the first configuration parameter from the server, the method further includes: The first terminal runs the first scenario of the first application according to the second configuration parameters; The first terminal acquires second running data, which includes running data of the first terminal when running the first application in a first scenario according to the second configuration parameters. The first running data includes the second running data. The first terminal sends the second running data to the server.

5. A method for optimizing the performance of a terminal, applied to a first terminal, wherein the first terminal is a first model, characterized in that, The method includes: The system receives first configuration parameters from a server. These first configuration parameters are used to configure the parameters of the terminal of the first model when running the first application in a first scenario. The first configuration parameters are determined by the server based on the first model, the identification information of the first application, and first running data. The first running data includes running data of multiple terminals running the first application in the first scenario. The model of the multiple terminals is the first model. The first running data includes the first model, the identification information of the first application, scenario parameters, and performance parameters. The scenario parameters include: a first scenario entry / exit identifier, a scenario type, and instance data. Determine the first scenario when the first application is running; The first configuration parameter is verified based on the first performance parameter and the second performance parameter, wherein the first performance parameter is the performance parameter of the first terminal when running the first application in the first scenario according to the first configuration parameter, and the second performance parameter is the performance parameter of the first terminal when running the first application in the first scenario according to the second configuration parameter. If the first configuration parameter verification passes, the first scenario of the first application is run according to the first configuration parameter; if the first configuration parameter verification fails, the first scenario of the first application is run according to the second configuration parameter, and an exception message is sent to the server.

6. The method according to claim 5, characterized in that, The first scenario is a high-load scenario during the operation of the first application.

7. The method according to claim 5 or 6, characterized in that, The first application is a game application.

8. The method according to claim 5 or 6, characterized in that, Before receiving the first configuration parameters from the server, the method further includes: The first scenario of the first application is run according to the second configuration parameters; Acquire second operational data, which includes operational data of the first terminal when running the first application in a first scenario according to the second configuration parameters; The second running data is sent to the server.

9. The method according to claim 5 or 6, characterized in that, Before receiving the first configuration parameters from the server, the method further includes: A first request message is sent to the server. The first request message includes the identification information of the first model and the first application. The first request message is used to request the acquisition of the first configuration parameters.

10. The method according to claim 5 or 6, characterized in that, The first configuration parameters include the identification information of the first scenario, and one or more of the following parameters corresponding to the identification information of the first scenario: CPU operating frequency, GPU operating frequency, number of CPU big and small cores, GPU size, highest temperature for triggering temperature control strategy or network speed priority.

11. The method according to claim 5 or 6, characterized in that, The performance parameters include one or more of the following parameters: rendering time of the first frame, average frame rate, jitter rate, low frame rate ratio, power consumption, device casing temperature, or number of dropped frames.

12. A performance optimization method, characterized in that, Applied to a server, the method includes: The system receives first operational data from multiple terminals. The first operational data includes operational data of the multiple terminals when running a first scenario of a first application. The models of the multiple terminals are first models. The first operational data includes the first model, the identification information of the first application, scenario parameters, and performance parameters. The scenario parameters include: first scenario entry / exit identifier, scenario type, and instance data. The first configuration parameter is determined based on the identification information of the first model and the first application and the first running data. The first configuration parameter is used to configure the terminal when the terminal of the first model is running the first application in the first scenario. Send the first configuration parameters to the first terminal, wherein the model of the first terminal is the first model; The system receives an error message from the first terminal. The error message is sent when the first terminal fails to verify the first configuration parameter according to the first performance parameter and the second performance parameter. The first performance parameter is the performance parameter of the first terminal when running the first application in a first scenario according to the first configuration parameter, and the second performance parameter is the performance parameter of the first terminal when running the first application in a first scenario according to the second configuration parameter.

13. The method according to claim 12, characterized in that, The method further includes: Verify the first configuration parameter.

14. The method according to claim 13, characterized in that, Verification of the first configuration parameter includes: By simulating the terminal of the first model, the first scenario of the first application is run according to the first configuration parameters; Collect third performance parameters when the first application is run in a first scenario based on the first configuration parameters; The first configuration parameter is verified based on the fourth performance parameter and the third performance parameter, wherein the fourth performance parameter is the performance parameter when the first application is run in the first scenario according to the third configuration parameter.

15. The method according to any one of claims 12 to 14, characterized in that, Before sending the first configuration parameter to the first terminal, the method further includes: A first request message is received from the first terminal. The first request message includes the identification information of the first model and the first application. The first request message is used to request the acquisition of the first configuration parameters.

16. The method according to any one of claims 12 to 14, characterized in that, The first configuration parameters are determined based on the first model, the identification information of the first application, and the first operating data, including: Based on the identification information of the first model and the first application, and the first running data, train the first parameter recommendation model; The first configuration parameters are obtained based on the identification information of the first model and the first application, and the first parameter recommendation model.

17. The method according to any one of claims 12 to 14, characterized in that, The first configuration parameters include the identification information of the first scenario, and one or more of the following parameters corresponding to the identification information of the first scenario: CPU operating frequency, GPU operating frequency, number of CPU big and small cores, GPU size, highest temperature for triggering temperature control strategy or network speed priority.

18. The method according to any one of claims 12 to 14, characterized in that, The performance parameters include one or more of the following parameters: rendering time of the first frame, average frame rate, jitter rate, low frame rate ratio, power consumption, device casing temperature, or number of dropped frames.

19. An electronic device, characterized in that, It includes one or more processors and a memory for storing one or more computer programs, the one or more computer programs including instructions that, when executed by the one or more processors, implement the method as claimed in any one of claims 5 to 11, or implement the method as claimed in any one of claims 12 to 18.

20. A chip, characterized in that, The chip is coupled to the memory in the communication device, so that the chip can call the program instructions stored in the memory during operation to implement the method as described in any one of claims 5 to 11, or to implement the method as described in any one of claims 12 to 18.

21. A communication system, characterized in that, It includes a communication device for implementing the method as described in any one of claims 5 to 11 and a communication device for implementing the method as described in any one of claims 12 to 18.

22. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a computer program that, when run on a communication device, causes the communication device to perform the method as claimed in any one of claims 5 to 11, or to perform the method as claimed in any one of claims 12 to 18.

23. A computer program product, characterized in that, Includes a computer program or instructions that, when executed, cause the method as described in any one of claims 5 to 11 to be implemented, or cause the method as described in any one of claims 12 to 18 to be implemented.

Images