CN112825539B

CN112825539B - Hardware management method and associated machine readable medium and electronic device

Info

Publication number: CN112825539B
Application number: CN202010932344.1A
Authority: CN
Inventors: 郭旺鑫; 张胜凯
Original assignee: MediaTek Inc
Current assignee: MediaTek Inc
Priority date: 2019-11-20
Filing date: 2020-09-08
Publication date: 2022-10-14
Anticipated expiration: 2040-09-08
Also published as: CN112825539A

Abstract

A hardware management method, comprising: examining an application on an electronic device to classify a scene of the application as a predefined application scene; and managing hardware components of the electronic device to respond to the predefined application scenario during the application running on the electronic device. For example, the hardware component may be a modem. By utilizing the invention, the hardware components of the electronic equipment can be better managed.

Description

Hardware management method and associated machine readable medium and electronic device

Technical Field

The present invention relates to hardware management, and more particularly, to a method of managing hardware components of an electronic device by referring to application (application) scenes (scenario) and an associated non-transitory machine-readable medium.

Background

In current designs, the modem (modulator-demodulator or modem) of a wireless communication device, such as a handset, supports many low power consumption tricks to reduce power consumption. However, it is not easy to implement the power consumption reduction function without harm. For example, the modem monitors (monitor) network traffic (traffic) to determine whether (enable) power reduction functionality is enabled. Since the upper layer information is not involved in controlling the enablement of the modem's power reduction function, the overall system performance may be degraded.

Therefore, innovative hardware management designs are needed to help modems apply these low power consumption techniques more aggressively.

Disclosure of Invention

It is an object of the present invention to provide a method of consulting an application scenario to manage hardware components of an electronic device and an associated non-transitory machine-readable medium, electronic device.

A first aspect of the present invention provides an exemplary hardware management method, comprising: examining an application on an electronic device to classify a scene of the application as a predefined application scene; and managing hardware components of the electronic device to respond to the predefined application scenario during execution of the application on the electronic device.

A second aspect of the invention provides an exemplary non-transitory machine readable medium storing program code that, when executed by a processor, causes the processor to: examining an application on an electronic device to classify a scene of the application as a predefined application scene; and managing hardware components of the electronic device to respond to the predefined application scenario during execution of the application on the electronic device.

A third aspect of the invention provides an exemplary electronic device comprising a processor which, when executing program code stored in a non-transitory machine-readable medium, performs the steps of the hardware management method proposed by the invention.

By utilizing the invention, the hardware components of the electronic equipment can be better managed.

The above and other objects of the present invention will become more apparent to those skilled in the art after a reading of the following detailed description of the preferred embodiments, which are illustrated in the accompanying drawings.

Drawings

FIG. 1 is a block diagram of an electronic device according to an embodiment of the invention.

FIG. 2 is a flow diagram of a hardware management method according to an embodiment of the invention.

Fig. 3 is a flowchart of a static information (static information) based low latency application detection method according to an embodiment of the present invention.

Fig. 4 is a flowchart of a dynamic information (dynamic information) based low latency application detection method according to an embodiment of the present invention.

Fig. 5 is a flowchart of an application scene classification method according to an embodiment of the present invention.

Detailed Description

Certain terms may be used throughout the description and following claims to refer to particular components. Those skilled in the art will appreciate that electronic device manufacturers may refer to components by different names. The invention is not intended to distinguish between components that differ in name but not function. In the detailed description and claims, the terms "include" and "comprise" are used in an open-ended fashion, and thus may be interpreted to mean "include, but not limited to, \8230;. Also, the term "coupling" is intended to mean either an indirect or direct electrical connection. Accordingly, if one device couples to another device, that connection may be through a direct electrical connection, or through an indirect electrical connection via other devices and connections.

FIG. 1 is a block diagram of an electronic device according to an embodiment of the invention. By way of example and not limitation, the electronic device 100 may be a wireless communication device such as a cell phone, wearable device, or tablet computer. In this embodiment, the electronic device 100 may include an application processor 102, a storage device 104, a display panel 106, an audio processor 108, and a modem 110. The modem 110 may be part of a wireless communication module (not shown) capable of performing wireless communication with other devices. Application processor 102 may include a plurality of Processing circuits, such as a Central Processing Unit (CPU) 112 and a Graphics Processing Unit (GPU) 114. In implementation, the application processor 102 may have more than one CPU 112 and/or more than one GPU 114, depending on practical design considerations. The storage device 104 may be a non-transitory machine readable medium. For example, the storage device may be a volatile memory (volatile memory), a non-volatile memory, or a combination of volatile and non-volatile memory. As another example, the memory device 104 may be an on-chip memory, an off-chip memory, or a combination of both. An Application (APP) may include instructions, and the APP may be stored in the storage device 104. In practice, multiple APPs may be stored in the storage device 104, depending on practical design considerations. When loaded (loaded) and executed by CPU 112, the APP may instruct (instract) CPU 112 to perform its specified function. In addition, program code (program code) may include instructions, which may also be stored in the storage device 104. When loaded and executed by the CPU 112, the program code may instruct the CPU 112 to perform the proposed hardware management method. Please note that, only the functional modules related to the present invention are illustrated in fig. 1. In practice, the electronic device 100 may include additional modules to perform other functions.

FIG. 2 is a flow diagram of a hardware management method according to an embodiment of the invention. Assuming that the results are substantially the same, the steps of the method need not be performed in the exact order shown in fig. 2. In addition, additional steps may be inserted. When loaded and executed by the CPU 112, the program code may examine (check) the APP on the electronic device 100 to classify the scene of the APP as a predefined application scene (step 202). By way of example, the predefined application scene may be a low throughput scene, a high throughput scene, a low latency scene (such as a gaming scene, a live streaming scene, a video conference scene, a ticketing scene, a tele-surgery scene, a stock ticketing scene, or an online bidding scene), or a non-low latency scene (such as a social media messaging scene, an online ordering and delivery scene, an online shopping scene, or a filming scene). During the execution of the APP on the electronic device 100, program code executing on the CPU 112 may manage hardware components of the electronic device 100 to respond to a predefined application scenario (step 204). For example, the hardware components may be the CPU 112, GPU 114, display panel 106, audio processor 108, and modem 110, depending on practical design considerations.

With respect to the application scene classification of step 202, the program code may detect a User Interface (UI) behavior (behavior) of an APP running on the electronic device 100. For example, a foreground UI type (e.g., web view or list view) and/or a foreground UI event (event) (e.g., input method) may be examined by program code to determine whether an APP running on the electronic device 100 is operating in a low-throughput scenario or a high-throughput scenario. In the case (case) where the scenario of the APP is classified as a low throughput scenario, it may be indicated that the APP may only require the modem 110 to provide low network throughput. In another case where the scenario of the APP is classified as a high throughput scenario, it may be indicated that the APP may require the modem 110 to provide high network throughput.

In the live (stream) case, the program code may check a video codec (codec) (encoder and decoder), a live status (streaming status), and/or a video buffer status. For example, when the video codec is operating, the live broadcast is idle (idle) and the video buffer is full (full), which may indicate that the video codec may read the video data from the video buffer directly for decoding, and then may output the decoded frame (frame) to the display panel 106. At this time, the modem 110 may not need to receive video data from a live source (streaming source), so that the network throughput of the modem 110 is low. Thus, the program code may determine (judge) that the APP running on the electronic device 100 is operating in a low throughput scenario.

In a real-time messaging scenario, when an APP employs a list view that groups several items (items) and displays them in a vertically scrolling list on a UI, program code may determine that the APP running on electronic device 100 is operating in a low-throughput scenario. At this time, the modem 110 may not need to receive video data from the stream source, so that the network throughput of the modem 110 is low.

In another case of real-time messaging, when the APP is live in a surface view (surface view), the program code may determine that the APP running on the electronic device 100 is operating in a high-throughput scenario. At this time, the modem 110 needs to receive video data from a live source, so that the network throughput of the modem 110 is high.

In the browser (browser) case, when the APP employs a web view to display fully loaded web content, the program code may determine that the APP running on electronic device 100 is operating in a low-throughput scenario. At this time, the modem 110 may not need to receive video data from the web server, so that the network throughput of the modem 110 is low.

Note that the APP application scenario may vary depending on the functionality currently enabled by the APP running on the electronic device 100. It can also be said that when a first function of an APP running on the electronic device 100 is enabled by a user, the program code may determine that the APP is operating in one predefined application scenario, and when a second function of the APP is enabled by the user, the program code may determine that the APP is operating in another predefined application scenario. For example, consider a case when the APP is a social media application, the scenario of the APP running on the electronic device 100 may be classified as a low throughput scenario when the user is using the messaging functionality of the APP, and a low latency scenario when the user is using the video call functionality of the APP.

Further, in some embodiments of the present aspect, the gaming APP may be considered a low latency application operating in a low latency scenario and the non-gaming APP may be considered a non-low latency application operating in a non-low latency scenario. Thus, for a particular application, the type of application may also represent the scenario in which the APP is running on the application processor. In other words, the application scenario may be determined by detecting the type of application.

With respect to the application scenario classification of step 202, program code may detect whether the APP is a low latency application, such as a game APP. For example, static information of the APP and/or dynamic information of the APP may be checked to determine whether the APP is a low latency application, where the static information of the APP may be fixed during the running time of the APP and the dynamic information of the APP may not be fixed during the running time of the APP.

Fig. 3 is a flowchart of a low latency application detection method based on static information according to an embodiment of the present invention. Assuming that the results are substantially the same, the steps of the method need not be performed in the exact order shown in fig. 3. In addition, additional steps may be inserted. The low latency application detection method based on static information may be performed by program code running on the CPU 112. At step 302, an application program (such as an APP) may be loaded and executed by the CPU 112. By way of example, the application may be an Android application or an application of another platform. In some embodiments of the present invention, the application of step 302 may be a new application that is executed for the first time after installation. In some embodiments of the present invention, the application of step 302 may be an updated application that is first executed after the latest version is updated.

At step 304, the code may check package information (package information) for the application. At step 306, the program code may consult the package information for the application to determine whether the application is a low latency application, such as a game APP. For example, when the application has a package name with a keyword of "game" or "tmgp", the context of the application may be classified as a low latency context (step 316) because "game" or "tmgp" may indicate that the application is a game APP. For example, when an application has an activity name (activity name) with a keyword of "game", the scene of the application may be classified as a low latency scene because "game" may indicate that the application is a game APP (step 316). As another example, when the application manifest (manifest) Extensible Markup Language (XML) file record (record) of the application has a flag (flag) of game (isGame), a game Identifier (Identifier, ID), and/or an application category set to "game", the scene of the application may be classified as a low latency scene because "isGame" or "game" may indicate that the application is a game APP (step 316).

If the package information of the application does not indicate (hit) that the application is a low-latency APP, the process may proceed to step 308. At step 308, the program code can consult a predefined resource usage (resource usage) of the application. At step 310, program code may consult a predefined resource utilization of the application to determine whether the application is a low-latency APP. For example, when the manifest XML file of an application records that the application is written in a game engine (game engine) or a game library (game library), the application may be a game APP, and thus the application's scene may be classified as a low latency scene (step 316).

If the application's predefined resource utilization does not suggest that the application is a low-latency APP, the flow may proceed to step 312. At step 312, the program code may consult registry key (registry key) information for the application. At step 314, the program code may consult registry key information of the application to determine whether the application is a low-latency APP. When the registry key information indicates a low latency APP, the context of the application may be classified as a low latency context (step 316). When the registry key information does not indicate low latency APP, the context of the application may be classified as a non-low latency context (step 318).

Fig. 4 is a flowchart of a low latency application detection method based on dynamic information according to an embodiment of the present invention. Assuming that the results are substantially the same, the steps of the method need not be performed in the exact order shown in fig. 4. In addition, additional steps may be inserted. The low latency application detection method based on dynamic information may be performed by program code running on the CPU 112. At step 402, the program code may check whether a screen change (screen change) has occurred. If no application screen change has occurred, the program code can continue to check for the occurrence of an application screen change. If an application screen change occurs, a new application screen may be displayed on the display panel 106. For example, the application screen may change because new activities to interact with the user may be displayed on the UI. It is also possible that the currently running application may enter a low latency mode (such as a gaming mode) and thus may trigger an application screen change event. Thus, checking the dynamic information of the currently running application may check whether the currently running application enters the low-latency APP mode (step 404).

At step 404, the program code may check at least one of static information of the new application screen/activity, GPU utilization, a running state of the game engine, and a state of a network socket connection (socket connection). It can also be said that the dynamic information of the currently running application may include static information of the new application screen/activity and/or changes in application resource utilization. At step 406, the program code may consult the dynamic information of the currently running application to determine whether the currently running application is a low-latency APP, such as a game APP. When the dynamic information of the currently running application indicates that the currently running application is a low-latency APP, the scene of the application may be classified as a low-latency scene (step 408). When the dynamic information of the currently running application does not indicate that the currently running application is a low-latency APP, the scenario of the application may be classified as a non-low-latency scenario (step 410).

In one exemplary design, the application scene classification of step 202 shown in FIG. 2 may include detecting UI behavior (UI behavior) of an application running on electronic device 100 for high-throughput/low-throughput scene detection. In another exemplary design, the application scene classification of step 202 shown in FIG. 2 may include detecting whether the application is a low-latency application for detection of the low-latency scene by using a static information-based low-latency application detection method as shown in FIG. 3 and/or a dynamic information-based low-latency application detection method as shown in FIG. 4. In yet another exemplary design, the application scene classification of step 202 shown in fig. 2 may include detecting whether the application is a low-latency application and detecting UI behavior of the application running on the electronic device 100, where the low-latency application detection may employ a static information-based low-latency application detection method as shown in fig. 3 and/or a dynamic information-based low-latency application detection method as shown in fig. 4.

Fig. 5 is a flowchart of an application scene classification method according to an embodiment of the present invention. Assuming that the results are substantially the same, the steps of the method need not be performed in the exact order shown in fig. 5. In addition, additional steps may be inserted. Step 202 shown in fig. 2 may employ the application scene classification method shown in fig. 5. At step 502, the program code may perform a static information based low latency application detection method as shown in fig. 3 and/or a dynamic information based low latency application detection method as shown in fig. 4. If the low-latency application detection result indicates that the application is a low-latency APP, then the program code may classify the application's scene as a low-latency scene (such as a game scene) (steps 504 and 514). If the low-latency application detection does not indicate that the application is a low-latency application, the process may proceed to step 506. At step 506, the program code may detect UI behavior of an application running on the electronic device 100. If the UI behavior detection result indicates that the application does not require high-throughput network packet (packet) communication, program code may classify the application's scenario as a low-throughput scenario (steps 508 and 510). If the UI behavior detection result indicates that the application requires high-throughput network packet communication, the program code may classify the context of the application as another application context (such as a high-throughput context) that is neither a low-latency context nor a low-throughput context (steps 508 and 512).

After classifying the scene of the application as a predefined application scene in step 202, the hardware components of the electronic device 100 may be managed with reference to the application scene classification result in step 204. In a first exemplary design, power consumption of hardware components may be managed in response to predefined application scenarios. For example, the hardware component may be the modem 110, and therefore, the power consumption of the modem 110 may be reduced on the condition that the scenario of the application is classified as a low throughput scenario. As another example, the hardware component may be the display panel 106, so that the power consumption of the display panel 106 may be reduced under the condition that the scene of the application program is classified as a low-throughput scene.

In a second exemplary design, the computing power of the hardware component may be managed in response to a predefined application scenario. For example, the hardware component may be the CPU 12, and therefore, the computing power of the CPU 112 may be increased if the scene of the application program is classified as a low-latency scene (such as a game scene). As another example, the hardware component may be the GPU 114, so that the computing capability of the GPU 114 may be improved under the condition that the scene of the application program is classified as a low-latency scene (such as a game scene).

In a third exemplary design, video shading (shade) provided by a hardware component may be managed in response to a predefined application scenario. For example, in some application scenarios where high visual quality is required, the video rendering provided by the hardware component may be enhanced.

In a fourth exemplary design, the audio quality provided by the hardware components may be managed in response to predefined application scenarios. For example, the hardware component may be the audio processor 108, and thus, in some application scenarios where high-quality audio playback (playback) is not required, the quality of the audio provided by the audio processor 108 may be reduced.

It is to be understood that the foregoing detailed description is for purposes of illustration only and is not intended to limit the invention. In practice, the electronic device may use the application scene classification results to manage the hardware components to achieve other purposes. These alternative designs are all within the scope of the present invention. It will be readily apparent to those skilled in the art that certain modifications and adaptations to the apparatus and methods described above may be made while maintaining the teachings of the present invention. Thus, the scope of the invention is defined and protected by the following claims and their equivalents.

Claims

1. A hardware management method, comprising:

examining an application on an electronic device to classify a scene of the application as a predefined application scene; and

managing hardware components of the electronic device in response to the predefined application scenario during execution of the application on the electronic device,

wherein the predefined application scenario is determined at least by detecting user interface behavior of the application running on the electronic device, the user interface behavior comprising a foreground user interface type comprising a list view and a surface view,

wherein the application running on the electronic device is determined to be operating in a low throughput scenario when the application employs the list view, or

Determining that the application running on the electronic device is operating in a high-throughput scenario when the application employs the surface view.

2. The hardware management method of claim 1 wherein said predefined application scenarios comprise one or more of said low throughput scenarios, said high throughput scenarios, low latency scenarios, and non-low latency scenarios.

3. The hardware management method according to claim 1, wherein the predefined application scenario is determined according to a function currently enabled by the application, wherein,

determining that the application program operates in a first predefined application scenario when a first function of the application program is enabled,

determining that the application operates in a second predefined application scenario when a second function of the application is enabled.

4. The hardware management method of claim 1, wherein said checking said application on said electronic device comprises:

detecting whether the application program is a low-latency application program.

5. The method for hardware management as claimed in claim 4, wherein said detecting whether said application is said low latency application comprises:

checking static information of the application, wherein the static information is fixed during runtime of the application.

6. The hardware management method of claim 5, wherein the static information comprises at least one of packet information, predefined resource utilization, and registry key information.

7. The hardware management method of claim 4, wherein said detecting whether said application is said low latency application comprises:

checking dynamic information of the application running on the electronic device, wherein the dynamic information is not fixed during the runtime of the application.

8. The hardware management method of claim 7, wherein the dynamic information of the application is checked in response to an application screen change.

9. The hardware management method of claim 8, wherein the dynamic information comprises at least one of static information of a new application screen, graphics processor utilization, a running state of a game engine, and a state of a web socket connection.

10. The hardware management method of claim 1, wherein the hardware component comprises one or more of a modem, a display panel, a central processor, a graphics processor, or an audio processor.

11. The hardware management method of claim 1, wherein said managing the hardware component comprises:

managing power consumption of the hardware component, computational power of the hardware component, video shading provided by the hardware component, or audio quality provided by the hardware component.

12. A non-transitory machine-readable medium storing program code that, when executed by a processor, causes the processor to:

managing hardware components of the electronic device to respond to the predefined application scenario during execution of the application on the electronic device,

13. The non-transitory machine readable medium of claim 12, wherein the predefined application scenarios comprise one or more of the low throughput scenarios, the high throughput scenarios, low latency scenarios, and non-low latency scenarios.

14. The non-transitory machine readable medium of claim 12, wherein the predefined application scenario is determined according to a function currently enabled by the application, wherein,

determining that the application operates in a first predefined application scenario when a first function of the application is enabled,

15. The non-transitory machine-readable medium of claim 12, wherein said inspecting the application on the electronic device comprises:

detecting whether the application program is a low-latency application program.

16. The non-transitory machine-readable medium of claim 15, wherein said detecting whether the application is the low-latency application comprises:

17. The non-transitory machine readable medium of claim 16, wherein the static information comprises at least one of package information, predefined resource utilization, and registry key information.

18. The non-transitory machine-readable medium of claim 15, wherein said detecting whether the application is the low-latency application comprises:

19. The non-transitory machine readable medium of claim 18, wherein the dynamic information of the application is checked in response to an application screen change.

20. The non-transitory machine readable medium of claim 19, wherein the dynamic information comprises at least one of static information of a new application screen, graphics processor utilization, a running state of a game engine, and a state of a web socket connection.

21. The non-transitory machine readable medium of claim 12, wherein the hardware component comprises one or more of a modem, a display panel, a central processor, a graphics processor, or an audio processor.

22. The non-transitory machine-readable medium of claim 12, wherein the managing the hardware component comprises:

23. An electronic device for hardware management, comprising:

a processor, which when executing program code stored in a non-transitory machine-readable medium performs the steps of the hardware management method of any of claims 1-11.