WO2023085628A1 - Electronic device for improving application execution performance, and operation method thereof - Google Patents

Abstract

Disclosed is a server comprising: a communication module; a memory; and a processor. The processor may be configured to: receive a request for metadata of an application from an electronic device; transmit the metadata including a first performance parameter for the application to the electronic device; receive performance data related to execution of the application while the application is running on the electronic device; identify an in-play section on the basis of feature values related to the in-play section of the application extracted from the performance data; calculate a second performance parameter for improving application performance on the basis of the performance data and/or the feature values corresponding to the identified in-play section; and transmit the second performance parameter to the electronic device.

Description

Electronic device for improving application execution performance and its operating method

Embodiments of the present disclosure relate to a method of improving execution performance of an application in an electronic device.

BACKGROUND As electronic, information, and communication technologies develop, various functions are being integrated into a single portable communication device or electronic device. For example, a smart phone includes a communication function as well as a function of a sound reproducing device, an imaging device, or an electronic organizer, and more various functions can be implemented in the smart phone through the installation and execution of various applications. In addition, electronic devices are being implemented with various performances (or specifications), and performance levels required by applications (eg, game applications) executed on electronic devices are also increasing.

When the performance required to smoothly execute the application is high, but the performance of an electronic device on which the application is to be executed is low, performance may need to be improved when the application is executed. For example, for the same game application, the game application is smoothly executed (or driven) on a high-performance electronic device, whereas on a relatively low-performance electronic device, the reaction speed is slowed down, screen frames are cut off, or data The throughput load can cause problems, for example heat generation. Finding optimal performance parameters on the electronic device for the application may be important to enable the application to run smoothly on the electronic device.

Embodiments of the present disclosure may obtain a performance parameter for smooth execution of an application, provide an electronic device capable of executing the application based on the performance parameter, and improve execution performance of the application in the electronic device. .

Embodiments of the present disclosure can perform more accurate performance improvement and more accurately optimized performance by identifying an in-play section in which the game is actually played when a game application is executed and collecting performance data necessary for optimizing performance parameters in the in-play section. An electronic device capable of executing an application based on a parameter may be provided, and execution performance of the application may be improved in the electronic device.

An electronic device according to an embodiment may include a communication module, a display, a memory, and at least one processor operatively connected to the communication module, the display, and the memory. The at least one processor may be configured to execute the application based on a first performance parameter in response to an application execution request. The at least one processor may be configured to collect performance data related to the execution of the application while the application is being executed. The at least one processor may be configured to report the performance data to a server through the communication module. The at least one processor may be configured to receive a second performance parameter generated based on in-play data corresponding to an in-play section of the application among the performance data from the server through the communication module. The at least one processor may be configured to execute the application based on the second performance parameter.

A server according to an embodiment may include a communication module, a memory, and at least one processor operatively connected to the communication module and the memory. The at least one processor may be configured to receive a metadata request of an application from an electronic device through the communication module. The at least one processor may be configured to transmit metadata including a first performance parameter for the application to the electronic device through the communication module. The at least one processor may be configured to receive performance data related to execution of the application through the communication module while the application is being executed in the electronic device. The at least one processor may be configured to identify the in-play section based on feature values related to the in-play section of the application extracted from the performance data. The at least one processor may be configured to calculate a second performance parameter for improving the performance of the application based on the performance data and/or the characteristic values corresponding to the identified in-play period. The at least one processor may be configured to transmit the second performance parameter to the electronic device through the communication module.

An electronic device according to an embodiment may include a communication module, a display, a memory, and at least one processor operatively connected to the communication module, the display, and the memory. The at least one processor may be configured to execute the application based on a first performance parameter in response to an application execution request. The at least one processor may be configured to collect performance data related to the execution of the application while the application is being executed. The at least one processor may be configured to determine the performance data and/or the feature values corresponding to the in-play section of the application based on feature values related to the in-play section of the application extracted from the performance data. The at least one processor may be configured to obtain a second performance parameter for improving performance of the application based on the performance data and/or the characteristic values. The at least one processor may be configured to execute the application based on the second performance parameter.

An operating method of an electronic device according to an embodiment may include executing the application based on a first performance parameter in response to a request for executing the application. The method may include an operation of collecting performance data related to the execution of the application while the application is being executed. The method may include reporting the performance data to a server. The method may include receiving, from the server, a second performance parameter generated based on in-play data corresponding to an in-play period of the application among the performance data. The method may include an operation of executing the application based on the second performance parameter.

A method of operating a server according to an embodiment may include receiving a metadata request of an application from an electronic device. The method may include transmitting metadata including a first performance parameter for the application to the electronic device. The method may include receiving, from the electronic device, performance data associated with execution of the application while the application is being executed in the electronic device. The method may include an operation of identifying the in-play section based on feature values related to the in-play section of the application extracted from the performance data. The method may include an operation of calculating a second performance parameter for improving the performance of the application based on the performance data and/or the feature values corresponding to the identified in-play period. The method may include transmitting the second performance parameter to the electronic device.

An operating method of an electronic device according to an embodiment may include executing the application based on a first performance parameter in response to a request for executing the application. The method may include an operation of collecting performance data related to the execution of the application while the application is being executed. The method may include an operation of determining the performance data and/or the feature values corresponding to the in-play section of the application based on feature values related to the in-play section of the application extracted from the performance data. The method may include obtaining a second performance parameter for improving the performance of the application based on the performance data and/or the feature values. The method may include an operation of executing the application based on the second performance parameter.

1 is a diagram illustrating a network environment according to an exemplary embodiment.

2 is a block diagram illustrating configurations of an electronic device and a server according to an exemplary embodiment.

3a, 3b, 3c, 3d, 3e, and 3f (hereinafter collectively referred to as FIG. 3) illustrate execution screens of game applications.

4 is a diagram for explaining changes in performance data collected during execution of a game application.

5 is a diagram for comparing stability of performance data collected during execution of a game application.

6 is a diagram for explaining data flow between an electronic device 200 and a server 230 according to an exemplary embodiment.

7 is a signal flow diagram illustrating a procedure for improving the performance of the electronic device 200 according to an embodiment.

8 is a flowchart illustrating a procedure for reporting performance data in the electronic device 200 according to an exemplary embodiment.

9 is a flowchart illustrating a procedure of identifying an in-play section in the server 230 according to an embodiment.

10 is a flowchart illustrating a procedure of identifying an in-play section in the electronic device 200 according to an embodiment.

11 illustrates a distribution of feature values related to uploaded data according to an embodiment.

12 illustrates a distribution of feature values related to a battery percentage according to an exemplary embodiment.

13 illustrates a distribution of feature values related to surface temperature according to an exemplary embodiment.

14 illustrates a distribution of feature values related to FPS according to an embodiment.

15 illustrates a distribution of feature values related to game play time according to an embodiment.

16 illustrates a distribution of feature values related to changes in surface temperature according to an exemplary embodiment.

17 illustrates a distribution of feature values related to a battery percentage according to an embodiment.

18 illustrates a distribution of feature values related to game play time according to an embodiment.

19 illustrates a distribution of feature values related to processor frequency according to an embodiment.

20 illustrates a distribution of feature values related to processor usage according to an embodiment.

21 illustrates a distribution of feature values related to asymmetry of surface temperature according to an embodiment.

22 illustrates a distribution of feature values related to FPS stability according to an embodiment.

23 illustrates a distribution of feature values related to FPS change according to an embodiment.

24 illustrates a distribution of feature values related to FPS according to an embodiment.

25A and 25B are charts showing feature values related to FPS data in chronological order according to an embodiment.

26 illustrates importance of feature values related to determining an in-play section according to an embodiment.

27 illustrates a heatmap showing correlation of feature values related to determining an in-play section according to an embodiment.

In connection with the description of the drawings, the same or similar reference numerals may be used for the same or similar elements.

Hereinafter, electronic devices according to embodiments will be described with reference to the accompanying drawings. The term user used in embodiments of the present disclosure may refer to a person using an electronic device or a device (eg, an artificial intelligence electronic device) using an electronic device.

Terms used in this document are only used to describe a specific embodiment, and may not be intended to limit the scope of other embodiments. Singular expressions may include plural expressions unless the context clearly dictates otherwise. All terms used herein, including technical or scientific terms, may have the same meaning as commonly understood by a person of ordinary skill in the art of the present invention. Terms defined in commonly used dictionaries may be interpreted as having the same or similar meanings as those in the context of the related art, and unless explicitly defined in this document, they are not interpreted in ideal or excessively formal meanings. . In some cases, even terms defined in this document cannot be interpreted to exclude embodiments of the present invention.

1 is a block diagram of an electronic device 101 within a network environment 100 according to an embodiment.

Referring to FIG. 1 , in a network environment 100, an electronic device 101 communicates with an electronic device 102 through a first network 198 (eg, a short-range wireless communication network) or through a second network 199. It may communicate with at least one of the electronic device 104 or the server 108 through (eg, a long-distance wireless communication network). According to an embodiment, the electronic device 101 may communicate with the electronic device 104 through the server 108 . According to an embodiment, the electronic device 101 includes a processor 120, a memory 130, an input module 150, an audio output module 155, a display module 160, an audio module 170, a sensor module ( 176), interface 177, connection terminal 178, haptic module 179, camera module 180, power management module 188, battery 189, communication module 190, subscriber identification module 196 , or the antenna module 197 may be included. In some embodiments, in the electronic device 101, at least one of these components (eg, the connection terminal 178) may be omitted or one or more other components may be added. In some embodiments, some of these components (eg, sensor module 176, camera module 180, or antenna module 197) are integrated into a single component (eg, display module 160). It can be.

The processor 120, for example, executes software (eg, the program 140) to cause at least one other component (eg, hardware or software component) of the electronic device 101 connected to the processor 120. It can control and perform various data processing or calculations. According to one embodiment, as at least part of data processing or operation, processor 120 transfers instructions or data received from other components (e.g., sensor module 176 or communication module 190) to volatile memory 132. , processing commands or data stored in the volatile memory 132 , and storing resultant data in the non-volatile memory 134 . According to one embodiment, the processor 120 includes a main processor 121 (eg, a central processing unit or an application processor) or a secondary processor 123 (eg, a graphic processing unit, a neural network processing unit ( NPU: neural processing unit (NPU), image signal processor, sensor hub processor, or communication processor). For example, when the electronic device 101 includes the main processor 121 and the auxiliary processor 123, the auxiliary processor 123 may use less power than the main processor 121 or be set to be specialized for a designated function. can The secondary processor 123 may be implemented separately from or as part of the main processor 121 .

The secondary processor 123 may, for example, take the place of the main processor 121 while the main processor 121 is in an inactive (eg, sleep) state, or the main processor 121 is active (eg, running an application). ) state, together with the main processor 121, at least one of the components of the electronic device 101 (eg, the display module 160, the sensor module 176, or the communication module 190) It is possible to control at least some of the related functions or states. According to one embodiment, the auxiliary processor 123 (eg, an image signal processor or a communication processor) may be implemented as part of other functionally related components (eg, the camera module 180 or the communication module 190). there is. According to an embodiment, the auxiliary processor 123 (eg, a neural network processing device) may include a hardware structure specialized for processing an artificial intelligence model. AI models can be created through machine learning. Such learning may be performed, for example, in the electronic device 101 itself where the artificial intelligence model is performed, or may be performed through a separate server (eg, the server 108). The learning algorithm may include, for example, supervised learning, unsupervised learning, semi-supervised learning or reinforcement learning, but in the above example Not limited. The artificial intelligence model may include a plurality of artificial neural network layers. Artificial neural networks include deep neural networks (DNNs), convolutional neural networks (CNNs), recurrent neural networks (RNNs), restricted boltzmann machines (RBMs), deep belief networks (DBNs), bidirectional recurrent deep neural networks (BRDNNs), It may be one of deep Q-networks or a combination of two or more of the foregoing, but is not limited to the foregoing examples. The artificial intelligence model may include, in addition or alternatively, software structures in addition to hardware structures.

The memory 130 may store various data used by at least one component (eg, the processor 120 or the sensor module 176) of the electronic device 101 . The data may include, for example, input data or output data for software (eg, program 140) and commands related thereto. The memory 130 may include volatile memory 132 or non-volatile memory 134 .

The program 140 may be stored as software in the memory 130 and may include, for example, an operating system 142 , middleware 144 , or an application 146 .

The input module 150 may receive a command or data to be used by a component (eg, the processor 120) of the electronic device 101 from the outside of the electronic device 101 (eg, a user). The input module 150 may include, for example, a microphone, a mouse, a keyboard, a key (eg, a button), or a digital pen (eg, a stylus pen).

The sound output module 155 may output sound signals to the outside of the electronic device 101 . The sound output module 155 may include, for example, a speaker or a receiver. The speaker can be used for general purposes such as multimedia playback or recording playback. A receiver may be used to receive an incoming call. According to one embodiment, the receiver may be implemented separately from the speaker or as part of it.

The display module 160 may visually provide information to the outside of the electronic device 101 (eg, a user). The display module 160 may include, for example, a display, a hologram device, or a projector and a control circuit for controlling the device. According to an embodiment, the display module 160 may include a touch sensor configured to detect a touch or a pressure sensor configured to measure the intensity of force generated by the touch.

The audio module 170 may convert sound into an electrical signal or vice versa. According to an embodiment, the audio module 170 acquires sound through the input module 150, the sound output module 155, or an external electronic device connected directly or wirelessly to the electronic device 101 (eg: Sound may be output through the electronic device 102 (eg, a speaker or a headphone).

The sensor module 176 detects an operating state (eg, power or temperature) of the electronic device 101 or an external environmental state (eg, a user state), and generates an electrical signal or data value corresponding to the detected state. can do. According to one embodiment, the sensor module 176 may include, for example, a gesture sensor, a gyro sensor, an air pressure sensor, a magnetic sensor, an acceleration sensor, a grip sensor, a proximity sensor, a color sensor, an infrared (IR) sensor, a bio sensor, It may include a temperature sensor, humidity sensor, or light sensor.

The interface 177 may support one or more designated protocols that may be used to directly or wirelessly connect the electronic device 101 to an external electronic device (eg, the electronic device 102). According to one embodiment, the interface 177 may include, for example, a high definition multimedia interface (HDMI), a universal serial bus (USB) interface, an SD card interface, or an audio interface.

The connection terminal 178 may include a connector through which the electronic device 101 may be physically connected to an external electronic device (eg, the electronic device 102). According to one embodiment, the connection terminal 178 may include, for example, an HDMI connector, a USB connector, an SD card connector, or an audio connector (eg, a headphone connector).

The haptic module 179 may convert electrical signals into mechanical stimuli (eg, vibration or motion) or electrical stimuli that a user may perceive through tactile or kinesthetic senses. According to one embodiment, the haptic module 179 may include, for example, a motor, a piezoelectric element, or an electrical stimulation device.

The camera module 180 may capture still images and moving images. According to one embodiment, the camera module 180 may include one or more lenses, image sensors, image signal processors, or flashes.

The power management module 188 may manage power supplied to the electronic device 101 . According to one embodiment, the power management module 188 may be implemented as at least part of a power management integrated circuit (PMIC), for example.

The battery 189 may supply power to at least one component of the electronic device 101 . According to one embodiment, the battery 189 may include, for example, a non-rechargeable primary cell, a rechargeable secondary cell, or a fuel cell.

The communication module 190 is a direct (eg, wired) communication channel or a wireless communication channel between the electronic device 101 and an external electronic device (eg, the electronic device 102, the electronic device 104, or the server 108). Establishment and communication through the established communication channel may be supported. The communication module 190 may include one or more communication processors that operate independently of the processor 120 (eg, an application processor) and support direct (eg, wired) communication or wireless communication. According to one embodiment, the communication module 190 may be a wireless communication module 192 (eg, a cellular communication module, a short-range wireless communication module, or a global navigation satellite system (GNSS) communication module) or a wired communication module 194 (eg, a : a local area network (LAN) communication module or a power line communication module). Among these communication modules, a corresponding communication module is a first network 198 (eg, a short-range communication network such as Bluetooth, wireless fidelity (WiFi) direct, or infrared data association (IrDA)) or a second network 199 (eg, legacy It may communicate with the external electronic device 104 through a cellular network, a 5G network, a next-generation communication network, the Internet, or a telecommunications network such as a computer network (eg, a LAN or a WAN). These various types of communication modules may be integrated as one component (eg, a single chip) or implemented as a plurality of separate components (eg, multiple chips). The wireless communication module 192 uses subscriber information (eg, International Mobile Subscriber Identifier (IMSI)) stored in the subscriber identification module 196 within a communication network such as the first network 198 or the second network 199. The electronic device 101 may be identified or authenticated.

The wireless communication module 192 may support a 5G network after a 4G network and a next-generation communication technology, for example, NR access technology (new radio access technology). NR access technologies include high-speed transmission of high-capacity data (enhanced mobile broadband (eMBB)), minimization of terminal power and access of multiple terminals (massive machine type communications (mMTC)), or high reliability and low latency (ultra-reliable and low latency (URLLC)). -latency communications)) can be supported. The wireless communication module 192 may support a high frequency band (eg, mmWave band) to achieve a high data rate, for example. The wireless communication module 192 uses various technologies for securing performance in a high frequency band, such as beamforming, massive multiple-input and multiple-output (MIMO), and full-dimensional multiplexing. Technologies such as input/output (FD-MIMO: full dimensional MIMO), array antenna, analog beam-forming, or large scale antenna may be supported. The wireless communication module 192 may support various requirements defined for the electronic device 101, an external electronic device (eg, the electronic device 104), or a network system (eg, the second network 199). According to an embodiment, the wireless communication module 192 is configured to achieve peak data rate (eg, 20 Gbps or more) for realizing 1eMBB, loss coverage (eg, 164 dB or less) for realizing mMTC, or U-plane latency (for realizing URLLC). Example: downlink (DL) and uplink (UL) each of 0.5 ms or less, or round trip 1 ms or less) may be supported.

The antenna module 197 may transmit or receive signals or power to the outside (eg, an external electronic device). According to an embodiment, the antenna module 197 may include an antenna including a radiator formed of a conductor or a conductive pattern formed on a substrate (eg, PCB). According to one embodiment, the antenna module 197 may include a plurality of antennas (eg, an array antenna). In this case, at least one antenna suitable for a communication method used in a communication network such as the first network 198 or the second network 199 is selected from the plurality of antennas by the communication module 190, for example. can be chosen A signal or power may be transmitted or received between the communication module 190 and an external electronic device through the selected at least one antenna. According to some embodiments, other components (eg, a radio frequency integrated circuit (RFIC)) may be additionally formed as a part of the antenna module 197 in addition to the radiator.

According to various embodiments, the antenna module 197 may form a mmWave antenna module. According to one embodiment, the mmWave antenna module includes a printed circuit board, an RFIC disposed on or adjacent to a first surface (eg, a lower surface) of the printed circuit board and capable of supporting a designated high frequency band (eg, mmWave band); and a plurality of antennas (eg, array antennas) disposed on or adjacent to a second surface (eg, a top surface or a side surface) of the printed circuit board and capable of transmitting or receiving signals of the designated high frequency band. can do.

At least some of the components are connected to each other through a communication method between peripheral devices (eg, a bus, general purpose input and output (GPIO), serial peripheral interface (SPI), or mobile industry processor interface (MIPI)) and signal ( e.g. commands or data) can be exchanged with each other.

According to an embodiment, commands or data may be transmitted or received between the electronic device 101 and the external electronic device 104 through the server 108 connected to the second network 199 . Each of the external electronic devices 102 or 104 may be the same as or different from the electronic device 101 . According to an embodiment, all or part of operations executed in the electronic device 101 may be executed in one or more external electronic devices among the external electronic devices 102 , 104 , or 108 . For example, when the electronic device 101 needs to perform a certain function or service automatically or in response to a request from a user or another device, the electronic device 101 instead of executing the function or service by itself. Alternatively or additionally, one or more external electronic devices may be requested to perform the function or at least part of the service. One or more external electronic devices receiving the request may execute at least a part of the requested function or service or an additional function or service related to the request, and deliver the execution result to the electronic device 101 . The electronic device 101 may provide the result as at least part of a response to the request as it is or additionally processed. To this end, for example, cloud computing, distributed computing, mobile edge computing (MEC), or client-server computing technology may be used.

The electronic device 101 may provide an ultra-low latency service using, for example, distributed computing or mobile edge computing. In another embodiment, the external electronic device 104 may include an internet of things (IoT) device. Server 108 may be an intelligent server using machine learning and/or neural networks. According to one embodiment, the external electronic device 104 or server 108 may be included in the second network 199 . The electronic device 101 may be applied to intelligent services (eg, smart home, smart city, smart car, or health care) based on 5G communication technology and IoT-related technology.

2 is a block diagram illustrating configurations of an electronic device and a server according to an exemplary embodiment.

Referring to FIG. 2 , an electronic device 200 (eg, the electronic device 101 of FIG. 1 ) includes at least one processor (hereinafter referred to as a processor) 210, a memory 206, a display 202, and an audio device. module 204 , and/or communication module 208 . The electronic device 200 is not limited thereto and may be configured to further include various elements or be configured to exclude some of the above elements. The electronic device 200 according to an embodiment may include all or part of the electronic device 101 shown in FIG. 1 .

The processor 210 downloads an execution package of an application from the server 230 (eg, the server 108 of FIG. 1) using the communication module 208 and installs and executes the application, or previously downloaded or electronic device 200. ) can run pre-stored applications.

The processor 210 may inquire of the server 230 whether the application is of a designated type based on an application execution request (eg, a user input or an automatic execution request according to a designated condition). For example, the designated type may be an application requiring optimization of performance parameters. For example, the designated type may be a game application or an application requiring high performance. The processor 210 can confirm that the execution-requested application is the designated type (eg, a game application, an application requiring performance optimization, or an application requiring high performance) based on the metadata provided from the server 230, Raw data associated with the execution of the application may be acquired. In one embodiment, the processor 210 may obtain performance data based on raw data associated with the execution of an application.

In one embodiment, the performance data may include a plurality of elements related to the execution of the application. The plurality of elements are the FPS (frame per second) of the application while the execution data (eg, execution screen) of the application is exposed on the display 202 (eg, during the foreground), the electronic device 200 ) temperature (eg central processing unit (CPU) temperature, graphic processing unit (GPU) temperature and/or surface temperature), load of the processor 210 (eg CPU or GPU), network input/output (I /O), the resolution of the display 202, the scan rate or refresh rate of the display 202, the screen brightness of the display 260, and/or the network the electronic device 200 is connected to (e.g. : mobile network).

For example, an application may be in a foreground state or a background state when executed in the electronic device 200, and a session may mean a foreground state. For example, when an application is executed in the background in the foreground (eg, the first foreground) and then again in the foreground (eg, the second foreground), the first foreground period may be the first session, and the first foreground period may be the first session. 2 Foreground periods may be the second session. The processor 210 according to an embodiment includes summary (or processed) information (eg, statistical values of each of a plurality of elements, and/or a partial value of each of a plurality of elements) may be obtained as performance data.

The processor 210 according to an embodiment may transmit the performance data related to the execution of the application to the server 230, and at least one performance parameter based on analysis of the performance data from the server 230 (for example, Clock and/or usage limits of the CPU/GPU may be received. The processor 210 according to an embodiment may directly calculate at least one performance parameter by analyzing the performance data, or may receive analysis information based on the analysis of the performance data from the server 230 and use the analysis information to perform performance. parameters can be calculated. Acquisition of performance parameters in the present disclosure may include reception from the server 230 and/or calculation in the electronic device 200 . The processor 210 may execute the application based on the performance parameter. For example, when obtaining a second performance parameter while executing an application based on a designated performance parameter (eg, a first performance parameter), the processor 210 may execute the application based on the second performance parameter. For example, the processor 220 may execute the application based on the third performance parameter when acquiring the third performance parameter while executing the application based on the second performance parameter.

In one embodiment, the processor 210 may include an application launcher 212 , a performance tuner 214 , and/or an agent 216 . For example, application launcher 212 , performance tuner 214 , and/or agent 216 may be software or firmware executed by processor 210 . Alternatively, the application launcher 212 , performance tuner 214 , and/or agent 216 may be included in the processor 210 or may be independent hardware modules.

The agent 216 may determine whether an application newly installed in the electronic device 200 is a designated type (eg, a game application, an application requiring performance optimization, or an application requiring high performance). If the type of application cannot be identified, the agent 216 queries the server 230 through a metadata request to receive information (for example, metadata) on whether the application is of the designated type, and the metadata Based on, it can be confirmed that the application is of the designated type.

The application launcher 212 may execute the application based on a given performance parameter (eg, a first performance parameter or a second performance parameter) based on an application execution request. In one embodiment, the application launcher 212 may apply performance parameters provided from the performance tuner 214 to the execution of the application.

The performance tuner 214 collects and stores performance data associated with the execution of the application while the application is running (e.g., during an entire gaming session, or while execution data of the application is exposed on the display 202) and stores it in the memory 206 ( For example, it may be stored in the performance database (database: DB) 218) or transmitted to the agent 216. For example, performance data may include a plurality of elements related to the execution of an application. The plurality of elements are the FPS of the application while the execution screen of the application is exposed on the display 202 (eg, during the foreground), the temperature of the electronic device 201 (eg, CPU/GPU temperature or surface temperature), the load of the processor 210 (eg, CPU or GPU), network input/output (I/O), the resolution of the display 202, the refresh rate or refresh rate of the display 222, the screen brightness of the display 202, and / or at least one of the types of networks to which the electronic device 200 is connected.

Performance tuner 214 receives at least one performance parameter from server 230 via agent 216 in response to delivery of performance data associated with the execution of the application, for example, processor 210 (eg, CPU or GPU). Can receive a clock or usage limit of The performance tuner 214 according to an embodiment may provide the performance parameter to the application launcher 212 to execute the application based on the received performance parameter.

The agent 216 may periodically transmit performance data related to the running application to the server 230 through the communication module 208 . In one embodiment, the agent 216 periodically reads performance data from the memory 206 (for example, the performance database 218) according to a given period and sends the performance data to the server 230 through the communication module 208. can be reported as In one embodiment, the agent 216 receives, from the server 230, a performance parameter calculated through analysis of performance data corresponding to an in-play section in which the application is actually played by a user, and the performance Parameters can be passed to the performance tuner 214. The performance parameter 230 may be calculated by the server 230 to improve execution performance of an application in the electronic device 200 through analysis of the performance data.

In one embodiment, agent 216 divides performance data collected by performance tuner 214 into data corresponding to an in-play period (eg, in-play data) and data not corresponding to an in-play period (eg, in-play data). : not-in-play data). Among the entire time intervals in which the session related to the application is progressing, the remaining time intervals other than the in-play intervals may be referred to as not-in-play intervals. The agent 216 according to an embodiment may report in-play data that satisfies a specified condition to the server 230 as a result of the classification. The agent 216 according to an embodiment may receive a performance parameter obtained based on the analysis of in-play data from the server 230 and transmit it to the performance tuner 214 . Agent 216 according to an embodiment may analyze in-play data to obtain performance parameters and transmit the performance parameters to performance tuner 214 .

The memory 206 according to an embodiment may store an application package and may store data and/or information related to execution of the application. For example, the application package may be downloaded from the server 230 or another server through the communication module 220 and installed in the electronic device 200 and/or stored in the memory 206 . The memory 206 may include a performance database 218 , and the performance database 218 receives and stores performance data collected by the performance tuner 214 in association with the execution of the application, provided from the performance tuner 214 . can In one embodiment, performance database 218 may be included in internal memory (not shown) of processor 210 .

The memory 230 may store various data generated during execution of the program 140 as well as programs used for functional operations (eg, the program 140 of FIG. 1 ). The memory 230 may largely include a program area 140 and a data area (not shown). The program area 140 may store program information related to driving the electronic device 200, such as an operating system (OS) for booting the electronic device 200 (eg, the operating system 142 of FIG. 1). The data area (not shown) may store transmitted and/or received data and generated data according to embodiments of the present disclosure. In addition, the memory 206 may be a flash memory, a hard disk, or a multimedia card micro type memory (eg, secure digital (SD) or extreme digital (XD) memory). , RAM (RAM), may be configured to include at least one storage medium of ROM (ROM).

The display 202 according to an embodiment may display various data and/or information based on the control of the processor 210 . For example, the display 202 may display a user interface including execution data (eg, an execution screen) of an application, a home screen, and/or screens related to various functions or operations of the electronic device 200. . According to one embodiment, the display 202 may be implemented in the form of a touch screen. When implemented together with an input module in the form of a touch screen, the display 202 may display various information generated according to a user's touch operation. According to one embodiment, the display 202 is a liquid crystal display (LCD), a thin film transistor LCD (TFT-LCD), organic light emitting diodes (OLED), a light emitting diode (LED), an active matrix organic LED (AMOLED), It may be composed of at least one or more of a micro LED, a mini LED, a flexible display, and a 3D display. Also, some of these displays may be of a transparent type or a light transmission type so that the outside can be seen through them. This may be configured in the form of a transparent display including a transparent OLED (TOLED). According to another embodiment, the electronic device 200 may further include other mounted display modules (eg, extended displays or flexible displays) in addition to the display 202 .

The audio module 204 according to an embodiment may display various data and/or information based on the control of the processor 210 . For example, the audio module 204 may output an audio signal related to application execution through a speaker or receive an audio signal related to application execution through a microphone.

Communication module 208 according to one embodiment may communicate with server 230 over network 220 . For example, the communication module 208 may receive metadata related to an application from the server 230 and may receive performance parameters. According to one embodiment, the communication module 208 may include a cellular module, a wireless-fidelity (Wi-Fi) module, a Bluetooth module, or a near field communication (NFC) module. In addition to this, other modules capable of communicating with the server 230 may be further included.

According to an embodiment, the electronic device 200 is not limited to the configuration shown in FIG. 2 and may further include various components. According to an embodiment, the electronic device 200 may further include an image processing module (not shown). The image processing module may perform 2D or 3D image processing and/or rendering operations under the control of the processor 210 .

The server 230 (eg, the server 108 of FIG. 1 ) according to an embodiment includes at least one processor (hereinafter referred to as a processor) 234, a memory 242, and a communication module 232. can be configured. The server 230 is not limited thereto and may further include various elements or may be configured except for some of the above elements.

The processor 234 may provide metadata corresponding to a designated application based on an application inquiry from the electronic device 200 through the communication module 232 . The processor 234 collects performance data when a designated application is executed from a plurality of electronic devices, and segments the collected performance data by session (eg, a first session, a second session, or another session) to segment each session. Performance data may be analyzed by extracting feature values of each segment and learning feature values of each segment for each session using a machine learning model. The processor 234 according to an embodiment extracts summary (or processed) information (eg, a statistical value of each of a plurality of elements and/or a partial value of each of a plurality of elements) of the performance data related to the performance data. can be obtained as a value.

The processor 234 according to an embodiment may receive performance data under a specified condition (eg, within an in-play period) from the electronic device 200 . The processor 234 according to an embodiment may obtain a performance parameter for a specified application by analyzing performance data under a specified condition, and may provide the performance parameter to the electronic device 200 through the communication module 232 .

The processor 234 according to one embodiment may include a performance data collector module 236, a data classifier module 238, and/or a performance analyzer module 240. can For example, performance data collection module 236 , data classification module 238 , and/or performance analysis module 240 may be software or firmware executed by processor 234 . Alternatively, the performance data collection module 236 , data classification module 238 , and/or performance analysis module 240 may be included in the processor 234 or may be independent hardware.

The performance data collection module 236 according to an embodiment collects performance data when a specified application is executed with a specified performance parameter from a specified number of electronic devices during a specified collection period, and stores the collected performance data in the memory 242. (e.g. performance database 246). According to one embodiment, the performance data may be used for machine learning by data classification module 238 . In one embodiment, performance database 246 may store performance data labeled with scene information. The scene information may be included in game source code.

The data classification module 238 according to an embodiment reads performance data (eg, performance data labeled with scene information) from the performance database 246, identifies characteristic values of the performance data for each session, and identifies the performance data for each session. Characteristic values are learned by a machine learning model to determine whether or not each performance data is collected in an in-play section in which an application is actually played by a user in the electronic device 200, and the performance data is converted into in-play data related to the in-play section. and not-in-play data that are not related to the in-play section.

The performance analysis module 240 according to an embodiment analyzes the in-play data collected from the electronic device 200 and classified by the data classification module 238 to improve the performance of the electronic device 200 for a designated application. Possible performance parameters may be calculated, and the calculated performance parameters may be stored in the parameter database 248 or transmitted to the electronic device 200 through the communication module 232 .

The memory 242 according to an embodiment may include a metadata database 244, a performance database 246, and a parameter database 248, based on performance data and performance data collected from a plurality of electronic devices. The acquired performance parameters may be stored.

The metadata database 244 according to an embodiment includes at least one application information (eg, App Store ^TM or Play Store ^TM ) generated based on application (eg, game application) information collected from an external server (eg, App Store TM or Play Store TM ). : metadata) can be stored. For example, metadata may include "apk name", "game status", and/or "game name". For example, metadata may include default values of performance parameters specified for the application.

The server 230 according to an embodiment checks application information included (stored or installed) in the electronic device 200 based on application information (eg, metadata) stored in the metadata database 244, and Identifies whether the application included in the device 200 is a designated type (eg, a game application), and if the application is the designated type, information indicating that the application included in the electronic device 200 is a designated type (eg, a game application) The metadata including may be provided to the electronic device 200 through the communication module 232.

In one embodiment, at least one of metadata database 244 , performance database 246 , or parameter database 248 may be included in internal memory (not shown) of processor 234 .

The server 230 according to an embodiment communicates the performance parameters stored in the parameter database 244 according to a request of the electronic device 200 or according to a specified condition (eg, installation or execution of an application, or a given period). It can be transmitted to the electronic device 200 through the module 232 .

The communication module 232 according to an embodiment may communicate with the electronic device 200 through the network 220 . For example, the communication module 232 may transmit metadata to the electronic device 200 and may receive performance data and/or performance data (eg, in-play data) under a specified condition from the electronic device 200 . there is.

In the above-described embodiments, main components have been described through the electronic device 200 and the server 230 of FIG. 2 . However, not all of the components shown in FIG. 2 are essential components, and the electronic device 200 and/or the server 230 may be implemented with more components than the illustrated components, and fewer components than those shown. The electronic device 200 and/or the server 230 may be implemented by elements.

According to an embodiment, the performance data collected by the electronic device 200 is a specified time unit (eg, 1 second unit) for all the time that the execution data (eg, execution screen) of the application is exposed on the display 202. Collected data may be included. Such performance data may include data unnecessary for optimizing performance parameters of the application (for example, performance data collected outside the in-play period).

3a, 3b, 3c, 3d, 3e, and 3f (hereinafter collectively referred to as FIG. 3) illustrate various execution screens of a game application.

The first screen 302 shown in FIG. 3A may include scenes displayed while an application (eg, game) is being loaded in the electronic device 200 and may be referred to as a loading screen hereinafter. The second screen 304 shown in FIG. 3B may include scenes provided for a tutorial while an application is running, and may be referred to as a tutorial screen below. The third screen 306 shown in FIG. 3C may provide scenes representing a waiting room before a game play (eg, battle) starts within an application, and may be referred to as a waiting room screen hereinafter. The fourth screen 308 shown in FIG. 3D may include scenes provided when a battle starts while an application is running, and may be referred to as a start battle screen hereinafter. The fifth screen 310 shown in FIG. 3E may include scenes provided when a battle is in progress while an application is running, and may be referred to as an in battle screen hereinafter. The sixth screen 312 shown in FIG. 3F may include scenes provided when a battle ends while an application is running, and may be referred to as an end battle screen hereinafter.

Referring to FIG. 3, performance data on not-in-play screens (eg, loading screen 302, tutorial screen 304, and/or waiting room screen) requires relatively low performance of the processor 210, It may be unnecessary for measuring the performance of the application, or may be relatively less important than in-play screens (eg, the battle start screen 308, the battle screen 310, and/or the battle end screen 312).

In one embodiment, performance data during not-in-play screens may act as an obstacle to improving the execution performance of applications on the electronic device 200, and thus the server 230 or the electronic device 200 may perform optimally. Parameters may not be found or wrong performance parameters may be determined.

4 is a diagram for explaining changes in performance data collected during execution of a game application.

Referring to FIG. 4 , reference number 404 indicates a change in FPS, which is one of performance data measured during execution of a game application, reference number 404 indicates a target FPS designated for the game application, and reference number 406 indicates a game application. It shows PST (predicted surface temperature), one of the performance data measured during the execution of

5 is a diagram for comparing stability of performance data collected during execution of a game application.

Referring to FIG. 5 , reference number 502 compares the average FPS of the entire game session (“Total avg FPS”) and the average FPS in the in-play section (“In play Avg FPS”), and reference number 504 represents the entire game session. Comparison of FPS stability ("Total FPS stability") and FPS stability in the in-play section ("In play FPS stability"), and reference number 506 indicates the target FPS stability of the entire game session ("Total target FPS stability") and This is a comparison of target FPS stability ("In play target FPS stability") in the in-play section.

Referring to FIGS. 4 and 5 , the target FPS 404 is 40, and about half of the time during the game session in which the game application is in progress has elapsed on the waiting screen (for example, the waiting room screen 306). It can be seen that the FPS 402 is relatively stable in the shaded in-play section (for example, the screen 310 during battle). According to reference number 504, the FPS stability (total target FPS stability") of the entire game session is 52.8%, indicating that there is a problem with game performance, but the FPS stability of the in-play section (In play target FPS stability) is 52.8%. At 96.68%, it can be seen that there is no problem with actual game performance.

Embodiments to be described below classify performance data necessary for measuring the performance of an application into data collected during actual play of the application (ie, in-play data) and remaining data (ie, not-in-play data), and analyze the in-play data to more effectively implement the application. You can determine performance parameters to run.

6 is a diagram for explaining data flow between an electronic device 200 and a server 230 according to an exemplary embodiment. In one embodiment, the processor 210 of the electronic device 200 and the processor 234 of the server 230 may be configured to execute at least one of the operations described below.

Referring to FIG. 6 , in operation 602, the processor 210 of the electronic device 200 may identify the application using the source code of the application (eg, game application) and obtain scene information included in the source code. there is. The scene information may represent the meaning of each scene of an application, and the scene information includes current execution data (eg, an execution screen) of an application being executed in the electronic device 200, an in-play screen (eg, a battle start screen ( 308), to identify whether it corresponds to the in-battle screen 310 or the battle end screen 312) or to a sickle-in-play screen (eg, a loading screen 302, a tutorial screen 304, or a waiting room screen) can be used

In one embodiment, the scene information may include a scene identifier (scene_id) as shown in Table 1 below.

Scene_Id		Meaning
0	Default scene
One	Game is starting
2	Game is updating
3	User is signing in
4	Game is in room
5	Game scene is loading (User is loading)
6	Game scene is loading (Other user is loading)
7001	Game is playing (Scene No 1. Talk with NPCs while performing quests )
7002	Game is playing (Scene No 2. The ongoing battle with the henchmen)
7003	Game is playing (Scene No 3. Battle with monsters in dungeons )
...	...
8	Game is in watching mode
9	End of the game

In one embodiment, scene_id=0 to 6 may mean a loading screen 302 . In one embodiment, scene_id=7xxx may mean in-play screens (eg, a battle start screen 308, a battle screen 310, and/or a battle end screen 312). In operation 604, the processor 210 (for example, the agent 216) transmits a metadata request for the application to the server 230 and the metadata for the application from the metadata database 244 of the server 230. can receive The metadata may include whether or not the application is a game, and a default value of a performance parameter (eg, a first performance parameter).

In operation 606, the processor 210 (for example, the agent 216) transfers the first performance parameter obtained from the metadata to the performance tuner 214, so that the performance tuner 214 determines the first performance parameter. It can be applied to the execution of the application. The processor 210 (eg, the performance tuner 214) determines performance related to execution of the application while the application is running (eg, while a session of the application is maintained) based on the first performance parameter. Data may be collected periodically (eg, every second) and stored in a storage (eg, performance database 218 ) within the electronic device 200 . In one embodiment, the performance data is the FPS of the application, surface temperature (eg, predicted surface temperature (PST)), GPU load, CPU load, network I/O, display resolution, refresh rate or refresh rate, screen brightness, or mobile It may include at least one of the types of networks.

In one embodiment, the processor 210 (eg, performance tuner 214) may collect segmented performance data (eg, segment data) for each session in which the application is executed. In one embodiment, the processor 210 ) (eg, the performance tuner 214) may tune the performance of the electronic device 200 according to the performance data while the application is being executed in the electronic device 200 .

In operation 608a, the processor 210 (eg, the performance tuner 214) transmits the performance data (eg, segment data) to the server 230 through the agent 216. The performance data is transmitted to the server ( may be received by the processor 234 (eg, performance data collection module 236) of 230. In operation 608b, the processor 234 (eg, performance data collection module 236) sends the performance data to a server. memory 242 (e.g., performance database 246) of 230. In one embodiment, processor 234 may be used by multiple electronic devices (e.g., electronic device 200) running the same application. ) and other electronic devices) may be stored in the performance database 246. In one embodiment, a plurality of electronic devices periodically (eg, It can be reported to the server 230 in units of seconds).

Table 2 below shows examples of performance data stored in the performance database 246 of the server 230 .

No.	Uuid	reporting_ time	duration	avg_ fps	median_fps	fps_ stability	target_ fps_ stability	play_ avg_ fps	play_ median_ fps	play_ fps_ stability
0	~5d12e4e	~775628	833	51.84	60	76.59	86.88	58.5	60	96.22
One	~150da6a	~868974	643	52.52	59	81.75	80.75	47.86	59.5	64.44
2	~be64e44	~156586	2207	31.37	30	84.01	84.04	30.3	30	99.85
3	~d618a9a	~584764	897	27.03	30	85.83	85.92	30.27	30	99.79
4	~f55a3d0	~046929	1051	26.71	30	87.45	87.58	30.29	30	99.74
5	~72c7f5d	~003475	887	30.22	30	90.43	90.52	30.27	30	99.81
6	~485e6cc	~610497	1439	28.7	30	91.93	92.06	29.66	30	96.44
7	~f5f3756	~053984	911	28.49	30	91.99	92.07	30.29	30	99.69
8	~5f5df53	~619821	779	56.04	60	92.03	92.63	58.72	60	98.24
9	~deab9ba	~852920	1999	57	60	92.2	92.29	59.73	60	99.79

In the example of <Table 2>, the performance data includes a universally unique identifier (Uuid) for identifying an electronic device (for example, the electronic device 200) or a user, reporting_time indicating reporting time, duration indicating a data collection period, and execution of an application. It may include a plurality of elements associated with.

In one embodiment, the elements may include at least one of the following values and may further include various values not mentioned in this document.

- duration: data collection period

- avg_fps: Average FPS

- median_fps: median of FPS

- fps_stability: FPS stability

- target_fps_stability: Target value for FPS stability

- play_avg_fps: Average FPS while being played

- play_median_fps: Median FPS during play

- play_fps_stability : FPS stability while playing

- play_target_fps_stability: Target value for FPS stability during play

At operation 610, processor 234 (eg, data classification module 238) may read performance data from performance database 246. In one embodiment, the processor 234 (eg, data classification module 238) classifies the performance data according to given conditions (eg, periodicity, user/operator request, or application installation/running/exit). When it is determined necessary, the performance data related to the application may be read. In one embodiment, processor 234 (eg, data classification module 238) determines whether the performance data corresponds to an in-play interval in electronic device 200, and if so, in-play It can be determined by data, and if not, it can be determined by not-in-play data.

Table 3 below shows examples of performance data reported from a user (eg, the electronic device 200) among performance data stored in the performance database 246 of the server 230.

No.	Uuid	scene_ target_ fps	scene_ id	scene_ desc	scene_original_data
0	~be64e44	NaN	NaN	NaN	~41792:initSdk()
One	~be64e44	NaN	One	game is starting	~42412:updateGameInfo(){"sceneId":1, "fps":29, "0":"0"}
2	~be64e44	NaN	NaN	NaN	~42429:SsrmControl.setPerformanceLevel(){"perfLevel":3}
3	~be64e44	NaN	2	game is updating	~44454:updateGameInfo(){"sceneId":2}
4	~be64e44	NaN	3	game landing and loading	~49291:updateGameInfo(){"sceneId":3}
5	~be64e44	60	NaN	NaN	~54970:updateGameInfo(){"7":"60"}
6	~be64e44	NaN	4	game hall	~55976:updateGameInfo(){"1":"1.35.1","2":"11","sceneId":4,"8":"9","9":"2","51" :"19939", ...}
7	~be64e44	NaN	NaN	NaN	~59295:SsrmControl.setPerformanceLevel(){"perfLevel":3}
8	~be64e44	NaN	5	scene loading (own player side)	~66680:updateGameInfo(){sceneId":5}
9	~be64e44	NaN	NaN	NaN	~66692:SsrmControl.setPerformanceLevel(){"perfLevel":3}
10	~be64e44	NaN	NaN	NaN	~76682:SsrmControl.setPerformanceLevel(){"perfLevel":3}
11	~be64e44	NaN	6	scene loading (waiting other player side)	~89276:updateGameInfo(){sceneId":6}
12	~be64e44	NaN	7	playing game	~16477:updateGameInfo(){sceneId":7}

Here, NaN means Not a Number. In an embodiment, the performance data reported by the electronic device 200 may be stored in the performance database 246 using at least one of Uuid, reporting_time, and scene_id as a key.

In one embodiment, processor 234 (eg, data classification module 238) may classify in-play data or not-in-play data based on each feature value (eg, scene_id or scene_original_data) of the performance data. . Exemplary embodiments of data classification by processor 234 (eg, data classification module 238) will be described below with reference to FIGS. 11-27.

In one embodiment, the data classification module 238 may include a feature value extraction module 620 and a classification module 622 . The processor 234 (eg, the feature value extraction module 238 ) may extract feature values necessary for identifying an in-play section from performance data read from the performance database 246 . The feature values may be obtained from a plurality of elements included in the performance data, and may be, for example, summary (or processed) information on at least one of the elements. The processor 234 (eg, the classification module 622) may interpret the feature values by a machine learning model and determine whether the performance data corresponds to an in-play section based on the feature values.

In operation 612, the processor 234 (eg, the performance analysis module 240) may read performance data from the performance database 246. In one embodiment, the processor 234 (eg, data classification module 238) analyzes and analyzes performance data according to given conditions (eg, periodic, user/operator request, or execution/update/termination of the application). / Or the performance data related to the application may be read when it is determined that optimization of performance parameters is required.

In operation 614, the processor 234 (for example, the data classification module 238) may transfer performance data (for example, in-play data) corresponding to the in-play section determined as a result of the classification operation to the performance analysis module 240. there is. The processor 234 (eg, the performance analysis module 240) may perform in-play data provided from the data classification module 238 and/or the performance database 246 according to given conditions (eg, periodic or requested by a user/operator). ) may be analyzed and performance parameters optimized for the electronic device 200 may be calculated.

In one embodiment, the performance analysis module 240 may include an analysis module 624 and a parameter generation module 626 . The processor 234 (eg, the analysis module 624) may analyze the in-play data and/or performance data corresponding to each session of the application, and the processor 234 (eg, the parameter generation module 626) may calculate a performance parameter (eg, a second performance parameter) having a value capable of increasing execution performance of an application in the electronic device 200 . In one embodiment, the processor 234 (eg, the parameter generation module 626) includes a CPU clock or GPU clock value and/or processor usage limit that can increase the execution performance of the application according to data analysis. performance parameters can be determined.

In operation 616 , the processor 234 (eg, the parameter generation module 626 ) may store the determined second performance parameter in the parameter database 248 .

In operation 618, the processor 234 performs performance parameters stored in the parameter database 248 (eg, installation/execution/termination of an application in the electronic device 200, user/operator's request, or periodicity) under given conditions (eg, the electronic device 200). For example, the second performance parameter) may be provided (eg, distributed) to the electronic device 200 . In one embodiment, the processor 210 (eg, the performance tuner 214) of the electronic device 200 receives the second performance parameter from the server 230 and applies the second performance parameter to the execution of the application. can do. In one embodiment, the processor 210 (eg, the performance tuner 214) may operate according to a clock and/or usage limit specified by the second performance parameter while the application is running.

7 is a signal flow diagram illustrating a procedure for improving the performance of the electronic device 200 according to an embodiment. Here, a signal flow between modules included in the processor 210 of the electronic device 200 and the processor 234 of the server 230 is illustrated.

Referring to FIG. 7 , in operation 702, the processor 210 (for example, the performance tuner 214) of the electronic device 200 installs an application (eg, a game application) and extracts scene information included in the source code of the application. can be obtained. In operation 704, the processor 210 (for example, the agent 216) transmits a metadata request to the server 230 in order to query the installed application, and in response to the query, the server 230 (for example, the agent 216) For example, metadata related to the application may be received from the metadata database 244 . In one embodiment, the metadata includes information indicating that data collection is necessary to improve execution performance of the application (eg, information indicating that it is a game), and default values of performance parameters to be applied to execution of the application (eg, 1 performance parameters).

In operation 706, the processor 210 (eg, the agent 216) transfers the first performance parameter to the performance tuner 214 so that it can be applied to execution of the application. The processor 210 (eg, the performance tuner 214) may execute the application by applying the first performance parameter. In one embodiment, instead of obtaining the first performance parameter from metadata, processor 210 (e.g., agent 216) obtains the first performance parameter from server 230 (e.g., performance database 246) prior to execution of the application. ) can be obtained from

In operation 708a, the processor 210 (eg, the performance tuner 216) may collect performance data related to execution of the application while the application is being executed based on the first performance parameter. In one embodiment, the processor 210 (eg, the performance tuner 216) collects raw data related to the execution of the application while the application is running, and summarizes or processes the raw data to obtain the performance data. can be configured. In one embodiment, the performance data may be collected periodically, for example. In operation 710a, the processor 210 (eg, performance tuner 214) may report the performance data (eg, first performance data) to the server 230 through the agent 216. Processor 234 (eg, performance data collection module 236 ) of server 230 may store the performance data in performance database 246 .

In operation 708b, the processor 210 (eg, the performance tuner 216) may collect performance data related to execution of the application while the application is being executed based on the first performance parameter. In operation 710b, the processor 210 (eg, performance tuner 214) may report the performance data (eg, second performance data) to the server 230 through the agent 216. In one embodiment, the collection and reporting of the performance data according to operations 708a and 710a and/or operations 708b and 710b may be repeated periodically while the application is running (eg, while a session of the application is maintained). can

At operation 712 , processor 234 (eg, data classification module 238 ) of server 230 may read performance data from performance database 246 . In operation 714, the processor 234 (eg, the data classification module 238) may determine whether the performance data corresponds to an in-play section based on the performance data. In one embodiment, the processor 234 (for example, the data classification module 238) extracts feature values to be used for determining an in-play section from the performance data, and the performance data is converted to the in-play section based on the feature values. It can be determined whether it is in-play data corresponding to . Examples of the feature values will be described later with reference to FIGS. 11 to 27 .

In operation 716, the processor 234 (eg, the performance analysis module 240) may read the performance data stored in the performance database 246 to perform an analysis operation to improve the performance of the application. As an example, performance data provided from the performance database 246 may be collected during an entire section of a session in which the application is executed in the electronic device 200 .

In operation 718, the processor 234 (eg, the performance analysis module 240) may receive the in-play data determined by the data classification module 238 to perform an analysis operation for improving the performance of the application. . Among the performance data collected during the entire session, the in-play data may correspond to data collected during a section (in-play section) in which an application is actually played in the electronic device 200 .

In operation 720, the processor 234 (eg, the performance analysis module 240) performs an analysis operation based on the performance data of operation 716 and/or the in-play data of operation 718 so that the application in the electronic device 200 A performance parameter (eg, a second performance parameter) capable of improving execution performance of may be calculated and generated.

In operation 722, the processor 234 (eg, the performance analysis module 240) may store the second performance parameter in the memory 242 (eg, the parameter database 248).

In operation 722, the processor 234 (eg, the performance analysis module 240) may read the second performance parameter from the memory 242 (eg, the parameter database 248) and transmit it to the electronic device 200. there is. The second performance parameter may be provided to the performance tuner 214 through the agent 216 of the electronic device 200, and the processor 210 (eg, the performance tuner 214) may set the second performance parameter By applying, the application can be executed. Alternatively, the processor 210 (eg, the performance tuner 214) may apply the second performance parameter to the application currently being executed.

8 is a flowchart illustrating a procedure for reporting performance data in the electronic device 200 according to an exemplary embodiment. At least one of the operations described below may be executed by the processor 210 of the electronic device 200 .

Referring to FIG. 8 , in operation 802, the processor 210 may receive an application execution request (eg, a user input or an automatic execution request according to a specified condition). For example, the application may be a game application or an application requiring performance data collection and performance optimization.

In operation 804, in response to the execution request, the processor 210 requests the server 230 through the communication module 208 for metadata including an inquiry to determine whether the application is of a designated type (eg, a game application). and may receive metadata related to the application from the server 230 according to the metadata request. In one embodiment, the processor 210 may obtain the metadata from the server 230 according to a request for execution of the application or upon installation of the application.

In operation 806, the processor 210 may determine whether the application is a designated type, that is, a game application, based on the metadata. If it is not a game application, in operation 820, the processor 210 may execute the application in a conventional manner. On the other hand, if it is a game application, the processor 210 may proceed to operation 808.

In operation 808, the processor 210 may identify a first performance parameter included in the metadata and execute the application based on the first performance parameter. As an example, the first performance parameter may include a processor clock (eg, CPU clock and/or GPU clock).

In operation 810, the processor 210 may collect performance data related to the execution of the application according to a given condition (eg, periodically) while the application is being executed based on the first performance parameter. The performance data is the FPS of the application, the temperature of the electronic device 201 (eg CPU/GPU temperature or surface temperature), the load of the processor 210 (eg CPU or GPU), network input/output (I/O), It may include at least one of the resolution of the display 202, the refresh rate or refresh rate of the display 222, the screen brightness of the display 202, and/or the type of network to which the electronic device 200 is connected.

In operation 812, the processor 210 may report the performance data to the server 230 according to a given condition (eg, periodically). In one embodiment, operations 810 and 812 may be repeatedly performed at least once while the application is running.

In operation 814, the processor 210 may obtain a second performance parameter calculated based on performance data (eg, in-play data) of an in-play section among the reported performance data. In one embodiment, while the application is running, the processor 210 may receive the second performance parameter from the server 230 according to a period longer than a period for collecting and reporting the performance data or according to a given condition. . In an embodiment, the processor 210 may receive the second performance parameter from the server 230 when the application is terminated or executed next. In an embodiment, the processor 210 may obtain the second performance parameter directly or with the help of the server 230 based on the performance data reported while the application is running.

In operation 816, the processor 210 may execute the application by applying the second performance parameter. In one embodiment, the processor 210 may execute the application while operating according to the processor clock (eg, CPU clock and/or GPU clock) included in the second performance parameter. In an embodiment, the processor 210 may acquire the second performance parameter and apply the second performance parameter while executing the application. In one embodiment, the processor 210 may apply the second performance parameter to the next execution of the application.

In operation 818, the processor 210 may determine whether a request to terminate the application (eg, a user input or an automatic termination request according to a specified condition) is received. If the application does not end, the processor 210 may return to operation 810 and repeat subsequent operations (eg, operations 810, 812, 814, and 816). On the other hand, when a request to terminate the application is received, the processor 210 may terminate the execution of the application. In one embodiment, the processor 210 may report performance data according to the second performance parameter to the server 230 when the application is terminated.

9 is a flowchart illustrating a procedure of identifying an in-play section in the server 230 according to an embodiment. At least one of the operations described below may be executed by the processor 234 of the server 230 .

Referring to FIG. 9 , in operation 902, the processor 234 may receive a metadata request including a query about an application from the electronic device 200. In response to the metadata request, the processor 234 transmits metadata including information indicating that the application is a game application and default values of performance parameters (eg, a first performance parameter) for the application to the electronic device 200 . can be conveyed

In operation 904, the processor 234 may receive performance data related to the execution of the application from the electronic device 200. In one embodiment, the performance data may be received from the electronic device 200 periodically (eg, in units of seconds) while the application is executed in the electronic device 200 (eg, while a session of the application is maintained). can

In operation 906, the processor 234 determines that analysis of performance data and/or optimization of performance parameters is required according to given conditions (eg, periodicity, user/operator request, or execution/update/termination of the application). Characteristic values may be extracted by analyzing the performance data at the point in time, and an in-play section in which the application is actually played in the electronic device 200 may be identified based on the characteristic values. The processor 234 may determine performance data (or the feature values) corresponding to the identified in-play section as in-play data.

In one embodiment, the processor 234 determines a time period of a predetermined length after the application (eg, game application) is executed, a not in-play period in which operations such as loading a game and entering a waiting room are performed. play period). In addition, since an operation such as providing an ending screen is performed in a time period of a predetermined length before the game ends, it may be determined as a sickle-in-play period. The processor 234 may determine the performance data as sickle-inplay data when the reporting time of the performance data belongs to the determined sickle-inplay section. The processor 234 may determine performance data collected in the remaining time intervals other than the determined not-in-play interval as in-play data.

In one embodiment, the processor 234 calculates a statistical value (for example, a minimum value, a maximum value, an average value, a standard deviation, or a degree of asymmetry) of collected values for each element included in the performance data, and calculates the statistical value and the current collection value. Depending on the difference between the collected values, it may be determined whether the currently collected value corresponds to the in-play section. As an example, the processor 234 calculates a feature value representing the difference between the current surface temperature and the minimum surface temperature among the performance data, and converts the feature value to in-play data corresponding to an in-play section when the feature value exceeds a given threshold. can be classified.

In one embodiment, the processor 234 may track time-series data values of the performance data in chronological order, and determine that a transition between an in-play section and a not-in-play section is made at a point in time when the time-series data values are markedly different. The processor 234 may calculate each statistical value for each time window before and after a specific point in time, and compare the statistical values to determine whether a change in data before and after the specific point in time has occurred. As an example, the processor 234 may obtain an FPS difference between a specific point in time and 5 seconds later, and calculate a maximum value among 30 FPS difference values within a time window from the current point in time to 30 seconds later. If the maximum value is smaller than the given threshold value, the processor 234 may determine the maximum value of the FPS difference values as in-play data.

Various exemplary embodiments of operation 906 will be described below with reference to FIGS. 11-27.

In operation 908, the processor 234 calculates a second performance parameter for improving execution performance of the application based on the performance data (eg, in-play data) of the identified in-play section and/or feature values related thereto. can do.

In operation 910, the processor 234 transmits the second performance parameter to the electronic device 200 according to given conditions (eg, installation/execution/termination of an application in the electronic device 200, user/operator request, or periodicity). can be forwarded (e.g. distributed).

In the above embodiments, it has been described that the electronic device 200 reports performance data and identifies an in-play section in the server 230, but in other embodiments, the electronic device 200 determines an in-play section based on the collected performance data. It can act to identify.

10 is a flowchart illustrating a procedure of identifying an in-play section in the electronic device 200 according to an embodiment. At least one of the operations described below may be executed by the processor 210 of the electronic device 200 .

Referring to FIG. 10 , in operation 1002, the processor 210 may receive an application execution request (eg, a user input or an automatic execution request according to a specified condition). For example, the application may be a game application or an application requiring performance data collection and performance optimization.

In operation 1004, the processor 210 transmits a metadata request for confirming whether the application is a designated type (eg, a game application) to the server 230 through the communication module 208 in response to the execution request, and the Metadata related to the application may be received from the server 230 according to a metadata request. In one embodiment, the processor 210 may obtain the metadata from the server 230 according to a request for execution of the application or upon installation of the application.

In operation 1006, the processor 210 may determine whether the application is a designated type, that is, a game application, based on the metadata. If it is not a game application, in operation 1022, the processor 210 may execute the application in a conventional manner. On the other hand, if it is a game application, the processor 210 may proceed to operation 1008.

In operation 1008, the processor 210 may identify a first performance parameter included in the metadata and execute the application based on the first performance parameter. As an example, the first performance parameter may include a processor clock (eg, CPU clock and/or GPU clock).

In operation 1010, the processor 210 collects performance data related to the execution of the application according to a given condition (eg, periodically) while the application is being executed based on the first performance parameter. The collected performance data may be stored in the memory 206 (eg, the performance database 218) of the electronic device 200.

In operation 1012, the processor 210 determines that analysis of performance data and/or optimization of performance parameters is required according to given conditions (eg, periodicity, user/operator request, or execution/update/termination of the application). Characteristic values may be extracted by analyzing the performance data at the point in time, and an in-play section in which the application is actually played may be identified based on the characteristic values. In operation 1014, the processor 210 may determine performance data (and/or feature values) corresponding to the identified in-play section as in-play data.

In operation 1016, the processor 210 may obtain a second performance parameter calculated based on performance data (eg, in-play data) of an in-play section among the reported performance data. In an embodiment, the processor 210 may directly calculate the second performance parameter based on performance data (eg, in-play data) of the in-play section selected in operation 1014 . In one embodiment, the processor 210 reports the performance data (eg, in-play data) of the selected in-play section in operation 1014 to the server 230, and the second performance parameter calculated based on the in-play data is sent to the server ( 230).

In one embodiment, the processor 210 may obtain the second performance parameter according to a period longer than a period for collecting and reporting the performance data or according to a given condition while the application is running. In an embodiment, the processor 210 may obtain the second performance parameter when the application is terminated or executed next.

In operation 1018, the processor 210 may execute the application by applying the second performance parameter. In one embodiment, the processor 210 may execute the application while operating according to the processor clock (eg, CPU clock and/or GPU clock) included in the second performance parameter. In an embodiment, the processor 210 may acquire the second performance parameter and apply the second performance parameter while executing the application. In one embodiment, the processor 210 may apply the second performance parameter to the next execution of the application.

In operation 1020, the processor 210 may determine whether a request to terminate the application (eg, a user input or an automatic termination request according to a specified condition) is received. If the application does not end, the processor 210 may return to operation 1010 and repeat subsequent operations (eg, operations 1010, 1012, 1014, 1016, and 1018). On the other hand, when a request to terminate the application is received, the processor 210 may terminate the execution of the application. In one embodiment, the processor 210 may report performance data according to the second performance parameter to the server 230 when the application is terminated.

Hereinafter, embodiments of identifying an in-play section based on feature values extracted from performance data related to application execution in the electronic device 200 will be described. In the following, operations performed by the processor 234 of the server 230 will be described for convenience of description, but in a modified embodiment, the operations described below may be executed by the processor 210 of the electronic device 200, , but not limited thereto.

In one embodiment, at least one of the following characteristic values from performance data collected while an application is running in the electronic device 200 is determined by the processor 234 of the server 230 (for example, the data classification module 238). It may be extracted by the feature value extraction module 620).

- upload_bytes: Represents the amount of data uploaded to the game server over the network (for example, the network 220) while the game session is maintained.

- max_battery_pct_minus_battery_pct: Indicates the difference between the maximum battery percentage during a gaming session and the battery percentage at a specific point in time (eg the current point in time at which the corresponding performance data (i.e. battery percentage) is collected).

- pst_minus_min_pst: indicates the difference between the surface temperature of the electronic device 200 at a specific point in time and the minimum surface temperature during the game session.

- fps_stability: This is the stability of the FPS, indicating how much the FPS varied during the game session. A higher value may mean that the FPS is stable without change. It can be a value between 0 and 100.

- time_since_played: Indicates how long the game application has been played. It can represent the number of seconds since the game session started.

- max_pst_minus_pst: indicates a percentage difference between the maximum surface temperature during the game session and the surface temperature of the electronic device 200 at a specific point in time.

- battery_pct: Indicates the battery percentage of the electronic device 200.

- reverse_time_since_played: A value in seconds counting the time since the game session started in reverse order.

- cpu_limit_agg_std: Indicates the standard deviation for the maximum frequency of the CPU during the game session.

- cpu_usage: Indicates the average CPU usage during the game session.

- pst_agg_skew: may indicate skewness of the surface temperature of the electronic device 200 during a game session.

- pst_diff_-30: Indicates the difference between the surface temperature at a specific point in time and the surface temperature after 30 seconds.

- cur_fps_variability_pct_chg_-5_next_10_max: Represents the maximum value among 10 values representing the percentage change value between FPS variability (eg, fps_variability) at a specific point in time and FPS variability after 5 seconds.

- fps_pct_chg_-5_next_30_max: Indicates the maximum value among 30 values representing the percentage change value between the FPS at a specific point in time and the FPS after 5 seconds.

- fps_diff_-5_next_30_max: Indicates the maximum value among 30 values representing the difference between the FPS at a specific point in time and the FPS after 5 seconds.

- max_cur_fps_variability_minus_cur_fps_variability: Indicates the difference between the maximum FPS variability during the game session and the current FPS variability.

- cur_fps_stability_agg_mean: Indicates the average of FPS stability during the game session.

- cur_fps_variability_pct_chg_-5_next_20_max: Indicates the maximum value among 20 values representing the difference between the percentage of FPS volatility at a specific point in time and the percentage of volatility after 5 seconds.

- fps_prev_30_min: Indicates the FPS at a specific point in time and the minimum value among the previous 30.

- fps_agg_skew: Indicates the skewness of FPS during a game session.

- mean_battery_pct_minus_battery_pct: Shows the difference between the average battery percentage during a gaming session and the battery percentage at a specific point in time.

11 to 27 to be described later, examples of an operation (for example, operation 906) of extracting feature values and identifying data of an in-play section by the processor 234 of the server 230 will be described, but the operations described below will be described. These may be performed by the processor 210 of the electronic device 200 (eg, operations 1012 and 1014), and are not limited by the description below.

11 illustrates a distribution of feature values related to uploaded data according to an embodiment. In the illustrated graph, the X-axis may represent upload_bytes, and the Y-axis may represent a distribution (eg, kernel density estimation (KDE)).

Referring to FIG. 11 , as an application is executed in the processor 210 (eg, the performance tuner 214) of the electronic device 200, performance data values are collected in chronological order (or in real time) during a game session. It may be reported to processor 234 of server 230 (eg, performance data collection module 236). The processor 234 (for example, the data classification module 238) of the server 230 uses the feature values (for example, upload_bytes) extracted from the performance data to generate a distribution map 1102 of the in-play section and not-in-play. A distribution map 1104 of intervals may be obtained, and values of performance data having a distribution diagram 1102 of in-play intervals may be determined to be used for performance analysis. The processor 234 (for example, the data classification module 238) of the server 230 determines that the upload_bytes distribution 1102 of the in-play section has larger values than the not-in-play section from a predetermined point in time after the application starts. can be identified. Therefore, the processor 234 (for example, the data classification module 238) of the server 230 stores the amount of upload data at a specific point in time (for example, the current point in time) as upload_bytes based on the performance data, and the upload_bytes is given When the threshold value is exceeded, the upload_bytes may be classified as data of an in-play section (ie, in-play data).

12 illustrates a distribution of feature values related to a battery percentage according to an exemplary embodiment. In the illustrated graph, the X-axis may represent max_battery_pct_minus_battery_pct, and the Y-axis may represent a distribution (for example, KDE).

Referring to FIG. 12 , as an application is executed on the electronic device 200 (eg, the performance tuner 214), performance data values are collected in chronological order (or in real time) during a game session, and the values of the server 230 are calculated. processor 234 (eg, performance data collection module 236). The processor 234 (eg, the data classification module 238) uses the feature values (eg, max_battery_pct_minus_battery_pct) extracted from the performance data to obtain a distribution map 1202 of the in-play section and a distribution map 1204 of the not-in-play section. ) may be obtained, and it may be determined to use the performance data values having the distribution 1202 of the in-play section for performance analysis. The processor 234 (eg, the data classification module 238) of the server 230 may identify that the max_battery_pct_minus_battery_pct distribution 1202 of the in-play period has larger values than that of the not-in-play period. Therefore, the processor 234 (for example, the data classification module 238) of the server 230 determines that max_battery_pct_minus_battery_pct calculated based on the performance data at a specific point in time (for example, the current point in time) exceeds a given threshold value. can be classified as in-play data.

13 illustrates a distribution of feature values related to surface temperature according to an exemplary embodiment. In the illustrated graph, the X-axis may represent pst_minus_min_pst, and the Y-axis may represent a distribution (for example, KDE).

Referring to FIG. 13 , the processor 234 of the server 230 (eg, the data classification module 238) extracts feature values (eg, pst_minus_min_pst) from performance data reported from the electronic device 200. Using this, it can be identified that the pst_minus_min_pst distribution map 1302 of the in-play section has larger values than the distribution map 1304 of the sickle-in-play section. Processor 234 (e.g., data classification module 238) of server 230 determines, based on the performance data, the difference between the surface temperature at a specific point in time (e.g., the current point in time) and the minimum surface temperature during the gaming session. It is calculated and stored as pst_minus_min_pst, and when the pst_minus_min_pst exceeds a given threshold value, the pst_minus_min_pst may be classified as in-play data.

14 illustrates a distribution of feature values related to FPS according to an embodiment. In the illustrated graph, the X-axis may represent fps_stability, and the Y-axis may represent a distribution (for example, KDE).

Referring to FIG. 14 , the processor 234 (eg, the data classification module 238) of the server 230 uses feature values (eg, fps_stability) extracted from performance data reported from the electronic device 200. Using this, it can be identified that the fps_stability distribution 1402 of the in-play section has smaller values than the distribution 1404 of the sickle-in-play section. In one embodiment, the processor 234 (for example, the data classification module 238) of the server 230 stores the FPS stability at a specific time point (for example, the current time point) as fps_stability based on the performance data, and the fps_stability If is less than a given threshold, the fps_stability may be classified as in-play data.

15 illustrates a distribution of feature values related to game play time according to an embodiment. In the illustrated graph, the X-axis may represent time_since_played, and the Y-axis may represent a distribution (for example, KDE).

Referring to FIG. 15 , the processor 234 (eg, the data classification module 238) of the server 230 extracts feature values (eg, time_since_played) from performance data reported from the electronic device 200. Using this, it can be identified that the time_since_played distribution map 1502 of the in-play section has larger values than the distribution map 1504 of the sick-in-play section. In one embodiment, the processor 234 (eg, the data classification module 238) of the server 230 calculates time_since_played at a specific point in time (eg, the current point in time) based on the performance data, and calculates time_since_played as a threshold given the time_since_played. If the value is exceeded, the specific time point may be classified as an in-play section, and performance data collected at the specific point in time may be determined as in-play data.

16 illustrates a distribution of feature values related to changes in surface temperature according to an exemplary embodiment. In the illustrated graph, the X-axis may represent max_pst_minus_pst, and the Y-axis may represent a distribution (for example, KDE).

Referring to FIG. 16 , the processor 234 (eg, the data classification module 238) of the server 230 determines feature values (eg, max_pst_minus_pst) extracted from performance data reported from the electronic device 200. Using this, it can be identified that the max_pst_minus_pst distribution 1602 of the in-play section has substantially smaller values than the distribution 1604 of the sickle-in-play section. In one embodiment, the processor 234 (eg, the data classification module 238) calculates max_pst_minus_pst at a specific time point (eg, the current time point) based on the performance data, and if the max_pst_minus_pst is less than a given threshold, the max_pst_minus_pst may be determined as in-play data.

17 illustrates a distribution of feature values related to a battery percentage according to an embodiment. In the illustrated graph, the X-axis may represent battery_pct, and the Y-axis may represent a distribution (for example, KDE).

Referring to FIG. 17 , the processor 234 (eg, the data classification module 238) of the server 230 extracts feature values (eg, battery_pct) from performance data reported from the electronic device 200. Using this, it can be identified that the battery_pct distribution 1702 of the in-play section has generally smaller values than the distribution 1704 of the sickle-in-play section. In one embodiment, the processor 234 (eg, the data classification module 238) calculates battery_pct at a specific time point (eg, the current time point) based on the performance data, and if the battery_pct is less than a given threshold, the battery_pct may be determined as in-play data.

18 illustrates a distribution of feature values related to game play time according to an embodiment. In the illustrated graph, the X-axis may represent reverse_time_since_played, and the Y-axis may represent a distribution (eg KDE).

Referring to FIG. 18 , the processor 234 (eg, the data classification module 238) of the server 230 extracts feature values (eg, reverse_time_since_played) from performance data reported from the electronic device 200. Using this, it can be identified that the reverse_time_since_played distribution map 1802 of the in-play section has generally larger values than the distribution map 1804 of the sick-in-play section. In one embodiment, the processor 234 (eg, data classification module 238) calculates reverse_time_since_played at a specific point in time (eg, the current point in time) based on the performance data, and if the reverse_time_since_played is greater than a given threshold, the reverse_time_since_played is greater than a given threshold. A specific point in time may be classified as an in-play section, and performance data collected at the specific point in time may be determined as in-play data.

19 illustrates a distribution of feature values related to processor frequency according to an embodiment. In the illustrated graph, the X-axis may represent cpu_limit_agg_std, and the Y-axis may represent a distribution (for example, KDE).

Referring to FIG. 19 , the processor 234 (eg, the data classification module 238) of the server 230 determines feature values (eg, cpu_limit_agg_std) extracted from performance data reported from the electronic device 200. Using this, it can be identified that the cpu_limit_agg_std distribution map 1902 of the in-play section has generally larger values than the distribution map 1904 of the sickle-in-play section. In one embodiment, the processor 234 (eg, the data classification module 238) calculates cpu_limit_agg_std at a specific point in time (eg, the current point in time) based on the performance data, and if the cpu_limit_agg_std is greater than a given threshold, the cpu_limit_agg_std can be judged as in-play data.

20 illustrates a distribution of feature values related to processor usage according to an embodiment. In the illustrated graph, the X-axis may represent cpu_usage, and the Y-axis may represent a distribution (for example, KDE).

Referring to FIG. 20 , the processor 234 (eg, the data classification module 238) of the server 230 extracts feature values (eg, cpu_usage) from performance data reported from the electronic device 200. Using this, it can be identified that the cpu_usage distribution 2002 of the in-play section has substantially larger values than the distribution 2004 of the sick-in-play section. In one embodiment, the processor 234 (eg, the data classification module 238) obtains cpu_usage at a specific time point (eg, the current time point) based on the performance data, and if the cpu_usage is greater than a given threshold, the cpu_usage can be judged as in-play data.

21 illustrates a distribution of feature values related to asymmetry of surface temperature according to an embodiment. In the illustrated graph, the X-axis may represent pst_agg_skew, and the Y-axis may represent a distribution (for example, KDE).

Referring to FIG. 21 , the processor 234 (eg, the data classification module 238) of the server 230 determines feature values (eg, pst_agg_skew) extracted from performance data reported from the electronic device 200. Using this, it can be identified that the pst_agg_skew distribution map 2102 of the in-play section has generally smaller values than the distribution map 2104 of the sickle-in-play section. In one embodiment, the processor 234 (eg, the data classification module 238) calculates a pst_agg_skew at a specific point in time (eg, the current point in time) based on the performance data, and if the pst_agg_skew is less than a given threshold, the pst_agg_skew can be judged as in-play data.

22 illustrates a distribution of feature values related to FPS variability according to an embodiment. In the illustrated graph, the X-axis may represent cur_fps_variability_pct_chg_-5_next_10_max, and the Y-axis may represent a distribution (eg, KDE).

Referring to FIG. 22 , the processor 234 (eg, the data classification module 238) of the server 230 extracts feature values (eg, cur_fps_variability_pct_chg_-5_next_10_max) from performance data reported from the electronic device 200. ), it can be identified that the cur_fps_variability_pct_chg_-5_next_10_max distribution map 2202 of the in-play section has generally smaller values than the distribution map 2204 of the sick-in-play section. In one embodiment, the processor 234 (eg, the data classification module 238) calculates cur_fps_variability_pct_chg_-5_next_10_max at a specific time point (eg, the current time point) based on the performance data, and the cur_fps_variability_pct_chg_-5_next_10_max is a given threshold value. If it is less than, the cur_fps_variability_pct_chg_-5_next_10_max may be determined as in-play data.

23 illustrates a distribution of feature values related to FPS change according to an embodiment. In the illustrated graph, the X-axis may represent fps_diff_-5_next_30_max, and the Y-axis may represent a distribution (for example, KDE).

Referring to FIG. 23 , the processor 234 of the server 230 (eg, the data classification module 238) extracts feature values from performance data reported from the electronic device 200 (eg, fps_diff_-5_next_30_max ), it can be identified that the fps_diff_-5_next_30_max distribution map 2302 of the in-play section has substantially smaller values than the distribution map 2304 of the sickle-in-play section. In one embodiment, the processor 234 (eg, the data classification module 238) calculates fps_diff_-5_next_30_max at a specific time point (eg, the current time point) based on the performance data, and the fps_diff_-5_next_30_max is a given threshold value If it is smaller than fps_diff_-5_next_30_max, it can be determined as in-play data.

24 illustrates a distribution of feature values related to FPS according to an embodiment. In the illustrated graph, the X-axis may represent fps_prev_30_min, and the Y-axis may represent a distribution (for example, KDE).

Referring to FIG. 24 , the processor 234 (eg, the data classification module 238) of the server 230 uses feature values (eg, fps_prev_30_min) extracted from performance data reported from the electronic device 200. Using this, it can be identified that the fps_prev_30_min distribution map 2402 of the in-play section has generally larger values than the distribution map 2404 of the sick-in-play section. In one embodiment, the processor 234 (eg, the data classification module 238) calculates fps_prev_30_min at a specific time point (eg, the current time point) based on the performance data, and if the fps_prev_30_min is greater than a given threshold value, the fps_prev_30_min may be determined as in-play data.

25A and 25B are charts showing feature values related to FPS data in chronological order according to an embodiment.

Referring to FIG. 25A , a chart 2502 shows changes in feature values, eg, fps, fps_next_10_min, and fps_prev_10_min, according to data_timestamp representing reporting time of performance data during a game session. Here, fps denotes an FPS at a specific time point, fps_next_10_min denotes a minimum value among 10 subsequent FPS values, and fps_prev_10_min denotes a minimum value among 10 previous FPS values. As shown in the figure, it can be confirmed that the feature values are remarkably changed at a time when the in-play section and the sickle-in-play section are switched. The processor 234 (for example, the data classification module 238) of the server 230 tracks changes in the feature values, for example, fps, fps_next_10_min, and fps_prev_10_min, and detects changes in the feature values. The start or end of the in-play section may be determined, and performance data collected within the in-play section may be determined as the in-play data.

Referring to FIG. 25B , a chart 2504 shows changes in feature values, eg, fps, fps_diff_5_prev_10_mean, and fps_diff_-5_next_10_mean, according to data_timestamp during a game session. Here, fps_diff_5_prev_10_mean represents the average value of 10 values representing the difference between the FPS at a specific point in time and the FPS 5 seconds before, and fps_diff_-5_next_10_mean represents the average value of 10 values representing the difference between the FPS at a specific point in time and the FPS 5 seconds later. indicates As shown in the figure, it can be confirmed that the feature values are remarkably changed at a time when the in-play section and the sickle-in-play section are switched. The processor 234 (eg, the data classification module 238) of the server 230 tracks changes in the feature values, eg, fps, fps_diff_5_prev_10_mean, and fps_diff_-5_next_10_mean, so that changes in the feature values are detected It is possible to determine the start or end of the in-play section at the point in time, and determine performance data collected within the in-play section as the in-play data.

26 illustrates importance of feature values related to determining an in-play section according to an embodiment.

Referring to FIG. 26, normalized importance for upload_bytes and 20 feature values is shown. The processor 234 (for example, the data classification module 238) of the server 230 may analyze the performance data using a boosting tree-based machine learning model capable of producing high performance in tabular format data. A machine learning model based on a boosting tree may calculate the importance of feature values and use the importance to improve modeling performance or may be used for decision making. The processor 234 (eg, the data classification module 238) may identify an in-play section using a predetermined number of feature values having relatively high importance according to the calculated importance.

27 illustrates a heatmap showing correlation of feature values related to determining an in-play section according to an embodiment.

Referring to FIG. 27 , a heat map 2702 is a correlation between feature values that can be extracted for use in determining an in-play section by the processor 234 (eg, the data classification module 238) of the server 230. relationship can be shown. In one embodiment, the processor 234 (eg, the data classification module 238) determines the characteristic values (eg, upload_bytes, max_battery_pct_minus_battery_pct, or pst_minus_min_pst) that have a positive correlation with in_play, which is a parameter indicating the determination of the in-play section. ) may determine that the higher the value (for example, when it exceeds a given threshold), the higher the probability of being in-play data. In one embodiment, processor 234 (e.g., data classification module 238) determines that feature values that have a negative correlation with in_play (e.g., fps_stability, max_pst_minus_pst, battery_pct, or pst_agg_skew) are low. It may be determined that there is a high probability that the data is in-play data (for example, if it is smaller than a given threshold value).

As described in the above-described embodiments, the processor 234 (eg, the data classification module 238) of the server 230 may identify performance data (eg, in-play data) belonging to the in-play section, and the processor 234 may 234 (eg, the performance analysis module 240) may determine performance parameters for the electronic device 200 based on the in-play data.

The electronic device 200 according to an embodiment includes a communication module 208, a display 203, a memory 206, and at least one processor operatively connected to the communication module, the display, and the memory ( 210) may be included. The at least one processor may be configured to execute the application based on a first performance parameter in response to an application execution request. The at least one processor may be configured to collect performance data related to the execution of the application while the application is being executed. The at least one processor may be configured to report the performance data to the server 230 through the communication module. The at least one processor may be configured to receive, from the server, a second performance parameter generated based on in-play data corresponding to an in-play section of the application among the performance data. The at least one processor may be configured to execute the application based on the second performance parameter.

In one embodiment, the performance data includes FPS (frame per second), surface temperature, processor load, network input/output, resolution of the display, refresh rate or refresh rate of the display, while the execution screen of the application is displayed on the display, It may include at least one of the screen brightness of the display or the type of network to which the electronic device is connected.

In one embodiment, the second performance parameter is the performance data collected in the remaining time intervals other than a time interval of a predetermined length after the application is executed and a time interval of a predetermined length before the application is terminated. It can be generated based on the first element of

In one embodiment, the second performance parameter is the current value identified as corresponding to the in-play section according to a difference between a current value of the second element of the performance data and a minimum value of the second element during a session related to the application. can be created based on

In an embodiment, the second performance parameter may be generated based on a fourth element of the performance data identified as corresponding to the in-play section according to a change in the third element of the performance data during a session related to the application. there is.

In an embodiment, the second performance parameter may be generated based on at least one fifth element having a relatively high importance related to the determination of the in-play section among the performance data.

The server 230 according to an embodiment may include a communication module 232, a memory 242, and at least one processor 234 operatively connected to the communication module and the memory. The at least one processor may be configured to receive a metadata request of an application from an electronic device through the communication module. The at least one processor may be configured to transmit metadata including a first performance parameter for the application to the electronic device through the communication module. The at least one processor may be configured to receive performance data related to execution of the application through the communication module while the application is being executed in the electronic device. The at least one processor may be configured to identify the in-play section based on feature values related to the in-play section of the application extracted from the performance data. The at least one processor may be configured to calculate a second performance parameter for improving the performance of the application based on the performance data and/or the characteristic values corresponding to the identified in-play period. The at least one processor may be configured to transmit the second performance parameter to the electronic device through the communication module.

In one embodiment, the performance data includes frames per second (FPS) related to the application, surface temperature, processor load, network input/output, resolution of the display, refresh rate or refresh rate of the display, screen brightness of the display, or the electronic It may include at least one of the types of networks to which the device is connected.

In one embodiment, the at least one processor determines a time interval of a predetermined length after the application is executed and a time interval of a predetermined length before the application is terminated as sickle-in-play intervals, and the sickle - A time interval other than the in-play interval may be determined as the in-play interval, and the second performance parameter may be generated based on the first element of the performance data collected in the in-play interval.

In one embodiment, the at least one processor determines whether the current value belongs to the in-play section according to a difference between a current value of a second element of the performance data and a minimum value of the second element during a session related to the application; , When the current value is identified as corresponding to the in-play section, the second performance parameter may be generated based on the current value.

In one embodiment, the at least one processor determines the start or end of the in-play section at a time point when a change in the third element of the performance data is detected during a session related to the application, and determines the in-play section according to the determination result. and generate the second performance parameter based on a fourth element of the performance data corresponding to the identified in-play section.

In one embodiment, the at least one processor determines the amount of upload data when the amount of upload data transmitted through the network from the electronic device at a first point in time during the session of the application among the performance data exceeds a first threshold. It may be configured to determine the in-play data corresponding to the in-play section.

In one embodiment, when a difference between a maximum battery percentage of the electronic device during the session and a current battery percentage at a second time point exceeds a second threshold value, the at least one processor corresponds to the current battery percentage to the in-play period. It can be configured to determine the in-play data to be.

In an embodiment, when a difference between a minimum surface temperature of the electronic device and a current surface temperature at a third time point during the session exceeds a third threshold, the at least one processor corresponds to the current surface temperature as the in-play section. It can be configured to determine the in-play data to be.

In one embodiment, the at least one processor may be configured to determine the FPS as in-play data corresponding to the in-play section when a frame per second (FPS) of a fourth time point during the session is less than a fourth threshold value. .

The electronic device 200 according to an embodiment includes a communication module 208, a display 203, a memory 206, and at least one processor operatively connected to the communication module, the display, and the memory ( 210) may be included. The at least one processor may be configured to execute the application based on a first performance parameter in response to an application execution request. The at least one processor may be configured to collect performance data related to the execution of the application while the application is being executed. The at least one processor may be configured to determine the performance data and/or the feature values corresponding to the in-play section of the application based on feature values related to the in-play section of the application extracted from the performance data. The at least one processor may be configured to obtain a second performance parameter for improving performance of the application based on the performance data and/or the characteristic values. The at least one processor may be configured to execute the application based on the second performance parameter.

An operating method of an electronic device according to an embodiment may include an operation 808 of executing the application based on a first performance parameter in response to a request for executing the application. The method may include an operation 810 of collecting performance data related to the execution of the application while the application is being executed. The method may include an act 812 of reporting the performance data to a server. The method may include an operation 814 of receiving a second performance parameter generated based on in-play data corresponding to an in-play section of the application among the performance data from the server through the communication module. The method may include an operation 816 of executing the application based on the second performance parameter.

In one embodiment, the performance data includes FPS (frame per second), surface temperature, processor load, network input/output, resolution of the display, refresh rate or refresh rate of the display, while the execution screen of the application is displayed on the display, It may include at least one of the screen brightness of the display or the type of network to which the electronic device is connected.

In one embodiment, the second performance parameter is the performance data collected in the remaining time intervals other than a time interval of a predetermined length after the application is executed and a time interval of a predetermined length before the application is terminated. It can be generated based on the first element of

In one embodiment, the second performance parameter is the current value identified as corresponding to the in-play section according to a difference between a current value of the second element of the performance data and a minimum value of the second element during a session related to the application. can be created based on

In an embodiment, the second performance parameter may be generated based on a fourth element of the performance data identified as corresponding to the in-play section according to a change in the third element of the performance data during a session related to the application. there is.

In an embodiment, the second performance parameter may be generated based on at least one fifth element having a relatively high importance related to the determination of the in-play section among the performance data.

A method of operating the server 230 according to an embodiment may include an operation 902 of receiving a metadata request of an application from an electronic device. The method may include an operation 902 of transmitting metadata including a first performance parameter for the application to the electronic device. The method may include an operation 904 of receiving performance data associated with execution of the application from the electronic device while the application is being executed in the electronic device. The method may include an operation 906 of identifying the in-play section based on feature values related to the in-play section of the application extracted from the performance data. The method may include an operation 908 of calculating a second performance parameter for improving the performance of the application based on the performance data and/or the characteristic values corresponding to the identified in-play period. The method may include an operation 910 of transmitting the second performance parameter to the electronic device.

In one embodiment, the performance data includes frames per second (FPS) related to the application, surface temperature, processor load, network input/output, resolution of the display, refresh rate or refresh rate of the display, screen brightness of the display, or the electronic It may include at least one of the types of networks to which the device is connected.

In an embodiment, the operation of calculating the second performance parameter determines a time interval of a predetermined length after the application is executed and a time interval of a predetermined length before the application is terminated as a sickle-in-play interval. an operation of determining a time interval other than the sickle-in-play interval as the in-play interval, and an operation of generating the second performance parameter based on the first element of the performance data collected in the in-play interval. can include

In an embodiment, the operation of calculating the second performance parameter may include setting the current value in the in-play period according to a difference between a current value of the second element of the performance data and a minimum value of the second element during a session related to the application. It may include an operation of determining whether it belongs, and an operation of generating the second performance parameter based on the current value when it is identified that the current value corresponds to the in-play section.

In an embodiment, the calculating of the second performance parameter may include determining the start or end of the in-play section at a point in time when a change in the third element of the performance data is sensed during a session related to the application; and generating the second performance parameter based on a fourth element of the performance data corresponding to the in-play section identified according to a result.

In an embodiment, the operation of calculating the second performance parameter may include, when an amount of upload data transmitted through a network from the electronic device at a first point in time during a session of the application among the performance data exceeds a first threshold value An operation of determining the amount of uploaded data as in-play data corresponding to the in-play section may be included.

In an embodiment, the calculating of the second performance parameter may include calculating the current battery percentage when a difference between the maximum battery percentage of the electronic device during the session and the current battery percentage at a second time point exceeds a second threshold value. An operation of determining the in-play data corresponding to the in-play section may be included.

In an embodiment, the calculating of the second performance parameter may include setting the current surface temperature as the current surface temperature when a difference between the minimum surface temperature of the electronic device during the session and the current surface temperature at a third time point exceeds a third threshold value. An operation of determining the in-play data corresponding to the in-play section may be included.

In one embodiment, the operation of calculating the second performance parameter may include determining the FPS as in-play data corresponding to the in-play section when a frame per second (FPS) of a fourth time point during the session is smaller than a fourth threshold value. Actions may be included.

An operating method of the electronic device 200 according to an embodiment may include an operation 1008 of executing the application based on a first performance parameter in response to a request for executing the application. The method may include an operation 1010 of collecting performance data related to the execution of the application while the application is being executed. The method may include operations 1012 and 1014 of determining the performance data and/or the feature values corresponding to the in-play section of the application based on feature values related to the in-play section of the application extracted from the performance data. there is. The method may include an operation 1016 of obtaining a second performance parameter for improving the performance of the application based on the performance data and/or the feature values. The method may include an operation 1018 of executing the application based on the second performance parameter.

An electronic device according to embodiments of the present disclosure may obtain performance parameters for smooth execution of an application and execute the application based on the performance parameters, thereby improving perceived execution performance of the application.

According to the embodiments of the present disclosure, when an application is executed in an electronic device, more accurate performance parameters can be obtained by collecting data necessary for improving execution performance in an in-play section where a game is actually played, and based on the more accurate performance parameters, the application , it is possible to reduce performance deterioration or generation of heat due to inaccurate performance parameters.

Effects obtainable in the present disclosure are not limited to the effects mentioned above, and other effects not mentioned may be clearly understood by those skilled in the art from the description below. will be.

Electronic devices according to various embodiments disclosed in this document may be devices of various types. The electronic device may include, for example, a portable communication device (eg, a smart phone), a computer device, a portable multimedia device, a portable medical device, a camera, a wearable device, or a home appliance. An electronic device according to an embodiment of the present disclosure is not limited to the aforementioned devices.

Various embodiments of the present disclosure and terms used therein are not intended to limit the technical features described in this document to specific embodiments, but should be understood to include various modifications, equivalents, or substitutes of the embodiments. In connection with the description of the drawings, like reference numbers may be used for like or related elements. The singular form of a noun corresponding to an item may include one item or a plurality of items, unless the relevant context clearly dictates otherwise. In this document, "A or B", "at least one of A and B", "at least one of A or B," "A, B or C," "at least one of A, B and C," and "A Each of the phrases such as "at least one of , B, or C" may include any one of the items listed together in that phrase, or all possible combinations thereof. Terms such as "first", "second", or "first" or "secondary" may simply be used to distinguish a given component from other corresponding components, and may be used to refer to a given component in another aspect (eg, importance or order) is not limited. A (e.g., first) component is said to be "coupled" or "connected" to another (e.g., second) component, with or without the terms "functionally" or "communicatively." When mentioned, it means that the certain component may be connected to the other component directly (eg by wire), wirelessly, or through a third component.

The term "module" used in this document may include a unit implemented by hardware, software, or firmware, and may be used interchangeably with terms such as logic, logic block, component, or circuit, for example. A module may be an integrally constructed component or a minimal unit of components or a portion thereof that performs one or more functions. For example, according to one embodiment, the module may be implemented in the form of an application-specific integrated circuit (ASIC).

Various embodiments of the present disclosure provide one or more stored in a storage medium (eg, internal memory 136 or external memory 138) readable by a machine (eg, electronic device 101). It may be implemented as software (eg, program 140) containing instructions. For example, a processor (eg, the processor 120 ) of a device (eg, the electronic device 101 ) may call at least one command among one or more instructions stored from a storage medium and execute it. This enables the device to be operated to perform at least one function according to the at least one command invoked. The one or more instructions may include code generated by a compiler or code executable by an interpreter. Device-readable storage media may be provided in the form of non-transitory storage media. Here, 'non-temporary' only means that the storage medium is a tangible device and does not contain signals (e.g., electromagnetic waves), and this term refers to the case where data is stored semi-permanently in the storage medium. It does not discriminate when it is temporarily stored.

According to one embodiment, the method according to the example disclosed in this document may be included and provided in a computer program product. Computer program products may be traded between sellers and buyers as commodities. A computer program product is distributed in the form of a device-readable storage medium (e.g. compact disc read only memory (CD-ROM)), or through an application store (e.g. Play Store™) or on two user devices (e.g. It can be distributed (eg downloaded or uploaded) online, directly between smartphones. In the case of online distribution, at least part of the computer program product may be temporarily stored or temporarily created in a device-readable storage medium such as a manufacturer's server, an application store server, or a relay server's memory.

According to various embodiments, each component (eg, module or program) of the above-described components may include a single entity or a plurality of entities. According to various embodiments, one or more components or operations among the aforementioned corresponding components may be omitted, or one or more other components or operations may be added. Alternatively or additionally, a plurality of components (eg modules or programs) may be integrated into a single component. In this case, the integrated component may perform one or more functions of each of the plurality of components identically or similarly to those performed by a corresponding component of the plurality of components prior to the integration. . According to various embodiments, operations performed by modules, programs, or other components are executed sequentially, in parallel, iteratively, or heuristically, or one or more of the operations are executed in a different order, omitted, or , or one or more other operations may be added.

According to various embodiments, in a non-volatile storage medium storing instructions, the instructions, when executed by at least one processor, cause the at least one processor to perform at least one operation according to the embodiments described in the present disclosure. It may be set to perform.

In addition, the embodiments of the present invention described in the present specification and drawings are only presented as specific examples to easily explain the technical content according to the embodiments of the present invention and help understanding of the embodiments of the present invention, and the scope of the embodiments of the present invention is not intended to limit Therefore, the scope of various embodiments of the present invention should be construed as including all changes or modified forms derived based on the technical spirit of various embodiments of the present invention in addition to the embodiments disclosed herein are included in the scope of various embodiments of the present invention. do.

Claims (15)

1. In electronic devices,

   communication module;

   display;

   Memory; and

   at least one processor in operative connection with the communication module, the display, and the memory, the at least one processor comprising:

   Executing the application based on a first performance parameter in response to a request for execution of the application;

   Collecting performance data associated with the execution of the application while the application is running;

   Reporting the performance data to a server through the communication module;

   Receiving a second performance parameter generated based on in-play data corresponding to an in-play section of the application among the performance data from the server through the communication module;

   The electronic device, characterized in that configured to execute the application based on the second performance parameter.
2. The method of claim 1, wherein the performance data,

   FPS (frame per second) while the execution screen of the application is displayed on the display, surface temperature, processor load, network input/output, resolution of the display, refresh rate or refresh rate of the display, screen brightness of the display, or the electronic An electronic device comprising at least one type of network to which the device is connected.
3. The method of claim 1 or 2, wherein the second performance parameter is

   It is generated based on the first element of the performance data collected in the remaining time intervals other than a time interval of a predetermined length after the application is executed and a time interval of a predetermined length before the application is terminated;

   Generated based on the current value identified as corresponding to the in-play section according to a difference between the current value of the second element of the performance data and the minimum value of the second element during a session related to the application;

   It is generated based on the fourth element of the performance data identified as corresponding to the in-play section according to the change of the third element of the performance data during the session related to the application, or

   The electronic device characterized in that it is generated based on at least one fifth element having a relatively high importance related to the determination of the in-play section among the performance data.
4. in the server,

   communication module;

   Memory; and

   at least one processor operatively coupled with the communication module and the memory, the at least one processor comprising:

   Receiving a metadata request of an application from an electronic device through the communication module;

   Transmitting metadata including a first performance parameter for the application to the electronic device through the communication module;

   Receiving performance data related to the execution of the application through the communication module while the application is being executed in the electronic device;

   Identifying the in-play section based on feature values related to the in-play section of the application extracted from the performance data;

   Calculate a second performance parameter for improving the performance of the application based on the performance data and/or the feature values corresponding to the identified in-play section;

   and configured to transmit the second performance parameter to the electronic device via the communication module.
5. The method of claim 4, wherein the performance data,

   Characterized in that it includes at least one of FPS (frame per second) related to the application, surface temperature, processor load, network input/output, display resolution, display refresh rate or refresh rate, display screen brightness, or the type of network to which the electronic device is connected. server with .
6. The method of claim 4 or 5, wherein the at least one processor,

   A time interval of a predetermined length after the application is executed and a time interval of a predetermined length before the application is terminated are determined as sickle-in-play intervals;

   The remaining time interval excluding the sickle-in-play interval is determined as the in-play interval;

   and generating the second performance parameter based on the first element of the performance data collected in the in-play period.
7. The method of any one of claims 4 to 6, wherein the at least one processor,

   determining whether the current value belongs to the in-play section according to a difference between a current value of a second element of the performance data and a minimum value of the second element during a session related to the application;

   and generating the second performance parameter based on the current value when it is identified that the current value corresponds to the in-play section.
8. In electronic devices,

   communication module;

   display;

   Memory; and

   at least one processor in operative connection with the communication module, the display, and the memory, the at least one processor comprising:

   Executing the application based on a first performance parameter in response to a request for execution of the application;

   Collecting performance data associated with the execution of the application while the application is running;

   determining the performance data and/or the feature values corresponding to the in-play section of the application based on feature values related to the in-play section of the application extracted from the performance data;

   Obtaining a second performance parameter for improving performance of the application based on the performance data and/or the feature values;

   The electronic device, characterized in that configured to execute the application based on the second performance parameter.
9. In the method of operating an electronic device,

   Executing the application based on a first performance parameter in response to a request to execute the application;

   collecting performance data related to the execution of the application while the application is being executed;

   An operation of reporting the performance data to a server;

   receiving, from the server, a second performance parameter generated based on in-play data corresponding to an in-play section of the application among the performance data;

   and executing the application based on the second performance parameter.
10. The method of claim 9, wherein the performance data,

    FPS (frame per second) while the execution screen of the application is exposed on the display, surface temperature, processor load, network input/output, resolution of the display, refresh rate or refresh rate of the display, screen brightness of the display, or the electronic device A method comprising at least one of the types of networks being accessed.
11. 11. The method of claim 9 or 10, wherein the second performance parameter is

    It is generated based on the first element of the performance data collected in the remaining time intervals other than a time interval of a predetermined length after the application is executed and a time interval of a predetermined length before the application is terminated;

    Generated based on the current value identified as corresponding to the in-play section according to a difference between the current value of the second element of the performance data and the minimum value of the second element during a session related to the application;

    It is generated based on the fourth element of the performance data identified as corresponding to the in-play section according to the change of the third element of the performance data during the session related to the application, or

    Characterized in that the method is generated based on at least one fifth element having a relatively high importance related to the determination of the in-play section among the performance data.
12. In the method of operating the server,

    Receiving a metadata request of an application from an electronic device;

    Transmitting metadata including a first performance parameter for the application to the electronic device;

    receiving performance data related to the execution of the application from the electronic device while the application is being executed in the electronic device;

    identifying the in-play section based on feature values related to the in-play section of the application extracted from the performance data;

    Calculating a second performance parameter for improving the performance of the application based on the performance data and/or the characteristic values corresponding to the identified in-play section;

    and transmitting the second performance parameter to the electronic device.
13. The method of claim 12, wherein the performance data,

    FPS (frame per second) while the execution screen of the application is exposed on the display, surface temperature, processor load, network input/output, resolution of the display, refresh rate or refresh rate of the display, screen brightness of the display, or the electronic device A method comprising at least one of the types of networks being accessed.
14. The method of claim 12 or 13, wherein the calculating of the second performance parameter comprises:

    Determining a time interval of a predetermined length after the application is executed and a time interval of a predetermined length before the application is terminated as sickle-in-play intervals;

    Determining a remaining time section excluding the sickle-in-play section as the in-play section;

    and generating the second performance parameter based on the first element of the performance data collected in the in-play section.
15. In the method of operating an electronic device,

    Executing the application based on a first performance parameter in response to a request to execute the application;

    collecting performance data related to the execution of the application while the application is being executed;

    determining the performance data and/or the feature values corresponding to the in-play section of the application based on feature values related to the in-play section of the application extracted from the performance data;

    obtaining a second performance parameter for improving the performance of the application based on the performance data and/or the feature values;

    and executing the application based on the second performance parameter.

Images