Thread control method and electronic device

Abstract

The application discloses a thread control method and an electronic device, relates to the software field, and is used for matching the priority of a thread with the characteristics of the running of the electronic device. The thread control method comprises the following steps: acquiring scene information and state information of the electronic device, wherein the scene information is used for describing the use scene of the electronic device, and the state information is used for describing the running state of the electronic device; obtaining the QoS level corresponding to a target thread according to the scene information, the state information and the thread control strategy of different types of characteristics; and controlling the target thread according to the QoS level.

Description

Technical Field

[0001] This application relates to the field of software, and more particularly to a thread control method and an electronic device. Background Technology

[0002] The control of threads in electronic devices such as mobile phones is very complex. Different threads may have different priorities, with higher-priority threads consuming more resources. During user operation of electronic devices, the characteristics (or functions) of the device may not match the thread priorities, resulting in wasted resources. For example, a high-priority InputReader thread is used to quickly respond to touch events on the touchscreen. However, if the knuckle recognition feature, which can be dynamically activated (selectively activated or deactivated), is implemented through the InputReader thread, then the InputReader thread will frequently check the touchscreen for knuckle taps with high priority. Summary of the Invention

[0003] This application provides a thread control method and an electronic device for matching the operating characteristics of the electronic device with the priority of the threads.

[0004] To achieve the above objectives, the embodiments of this application adopt the following technical solutions:

[0005] Firstly, a thread control method is provided, comprising: acquiring scene information and state information of an electronic device, wherein the scene information describes the usage scenario of the electronic device and the state information describes the operating state of the electronic device; obtaining the QoS level corresponding to the target thread based on the scene information, state information, and thread control strategies of different types of characteristics; and controlling the target thread according to the QoS level.

[0006] The thread control method provided in this application obtains the QoS level of the target thread to be controlled based on the scenario information (usage scenario) and state information (running state) of the electronic device, as well as the thread control strategies for different types of characteristics. Then, the target thread is controlled according to the QoS level. Since the QoS level represents the priority of the target thread, the determination of the QoS level is based not only on different types of characteristics but also on the scenario information and state information of the electronic device, thus achieving a match between the operating characteristics of the electronic device and the thread priority.

[0007] In one possible implementation, the QoS level corresponding to the target thread is obtained based on scene information, state information, and thread control strategies for different types of characteristics. This includes: obtaining a data pair corresponding to the first target thread based on scene information, state information, and thread control strategies for persistent characteristics. The data pair corresponding to the first target thread includes a first QoS level and a first hook function. The first target thread is a thread with persistent characteristics. Controlling the target thread according to the QoS level includes: calling the first hook function to control the first target thread according to the first QoS level. For the first target thread with persistent characteristics native to the system, the thread control strategy for persistent characteristics configures the data pair (first QoS level and first hook function) corresponding to the first target thread. Once this data pair is found, the first hook function can control the first target thread according to the first QoS level.

[0008] In one possible implementation, when the first hook function corresponds to multiple different QoS levels, the first QoS level is the lowest QoS level. This ensures that the first target thread is properly controlled according to its resource requirements.

[0009] In one possible implementation, the method further includes: obtaining a data pair corresponding to the second target thread based on state information, the call frequency of the activated dynamic feature, and the thread control strategy of the dynamic feature. The data pair corresponding to the second target thread includes a second QoS level and a second hook function, and the second target thread is a thread of the dynamic feature. The second hook function is then called to control the second target thread according to the second QoS level. For a second target thread belonging to a system-native dynamic feature, the thread control strategy of the dynamic feature configures a data pair (second QoS level and second hook function) corresponding to the second target thread. Once this data pair is found, the second hook function can control the second target thread according to the second QoS level.

[0010] In one possible implementation, when the second hook function corresponds to multiple different QoS levels, the second QoS level is the lowest QoS level. Retaining the lowest QoS level when the same hook function corresponds to multiple different QoS levels ensures that the second target thread is properly controlled according to its resource requirements.

[0011] In one possible implementation, obtaining the QoS level corresponding to the target thread based on scene information, state information, and thread control strategies of different types of characteristics includes: obtaining a data pair corresponding to the third target thread based on scene information, state information, and thread control strategies of third-party characteristics. The data pair corresponding to the third target thread includes a third QoS level and a thread identifier (TID), and the third target thread is a thread with third-party characteristics. Controlling the target thread according to the QoS level includes: invoking the system scheduling thread to control the third target thread corresponding to the TID according to the third QoS level. For a third target thread belonging to third-party characteristics, the thread control strategy of the third-party characteristics configures the data pair (third QoS level and TID) corresponding to the third target thread. Once this data pair is found, the system scheduling thread can control the first target thread corresponding to the TID according to the first QoS level.

[0012] In one possible implementation, when a TID corresponds to multiple different QoS levels, the third QoS level is the lowest QoS level. Retaining the lowest QoS level when the same hook function corresponds to multiple different QoS levels ensures that the third target thread is properly controlled according to its resource requirements.

[0013] In one possible implementation, the method further includes: comparing the data pair corresponding to the target thread obtained in this round of search with the data pairs that have already taken effect in the previous round of search, and obtaining identical data pairs; subtracting the identical data pairs from the data pairs corresponding to the target thread obtained in this round of search, to obtain the data pairs corresponding to the target thread that are effective in this round. This can prevent data pairs from being applied repeatedly.

[0014] In one possible implementation, the method further includes: subtracting identical data pairs from the data pairs that have already taken effect in the current search round to obtain the data pair corresponding to the target thread to be rolled back; and controlling the rollback of the target thread to be rolled back based on the QoS level in the data pair corresponding to the target thread to be rolled back. This is equivalent to rolling back the target thread that does not meet the thread control target of the current round to its initial state.

[0015] In a second aspect, an electronic device is provided, including a processor and a memory, wherein instructions are stored in the memory, and when the processor executes the instructions, the method described in the first aspect and any embodiment thereof is executed.

[0016] Thirdly, a computer-readable storage medium is provided, including instructions that, when executed on an electronic device, cause the electronic device to perform the method as described in the first aspect and any embodiment thereof.

[0017] Fourthly, a computer program product containing instructions is provided, which, when executed on the aforementioned electronic device, cause the electronic device to perform the method as described in the first aspect and any embodiment thereof.

[0018] Fifthly, a chip system is provided, including a processor for supporting electronic devices in implementing the functions described in the first aspect above. In one possible design, the device further includes interface circuitry for receiving signals from other devices (e.g., memory) or sending signals to other devices (e.g., a communication interface). The chip system may include a chip and may also include other discrete devices.

[0019] The technical effects of the second to fifth aspects refer to the technical effects of the first aspect and any of its embodiments, and will not be repeated here. Attached Figure Description

[0020] Figure 1 A schematic diagram illustrating the air gesture recognition feature provided in an embodiment of this application;

[0021] Figure 2 A schematic diagram of a video call scenario provided in an embodiment of this application;

[0022] Figure 3 A schematic diagram illustrating threads of different priorities provided in an embodiment of this application;

[0023] Figure 4 A schematic diagram illustrating a three-finger swipe feature provided in an embodiment of this application;

[0024] Figure 5 A schematic diagram illustrating a thread control strategy with persistent characteristics provided in an embodiment of this application;

[0025] Figure 6 A schematic diagram illustrating a dynamic thread control strategy provided in an embodiment of this application;

[0026] Figure 7 A schematic diagram illustrating a thread control strategy based on third-party features provided in an embodiment of this application;

[0027] Figure 8 A schematic diagram of a thread control system provided in an embodiment of this application;

[0028] Figure 9 A schematic diagram of the software architecture of an electronic device provided in an embodiment of this application;

[0029] Figure 10 A schematic diagram of the software architecture of another electronic device provided in an embodiment of this application;

[0030] Figure 11 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application;

[0031] Figure 12A flowchart illustrating a thread control method provided in an embodiment of this application;

[0032] Figure 13 A flowchart illustrating another thread control method provided in an embodiment of this application;

[0033] Figure 14 A schematic diagram illustrating an example of a thread control strategy provided in an embodiment of this application;

[0034] Figure 15 This is a schematic diagram of a chip system provided in an embodiment of this application. Detailed Implementation

[0035] First, some concepts involved in this application will be described.

[0036] The terms "first" and "second" used in the embodiments of this application are only used to distinguish features of the same type and should not be construed as indicating relative importance, quantity, order, etc.

[0037] The terms "exemplary" or "for example" used in the embodiments of this application are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0038] The terms "coupling" and "connection" used in the embodiments of this application should be interpreted broadly. For example, they can refer to a physical direct connection or an indirect connection achieved through electronic devices, such as a connection achieved through resistors, inductors, capacitors or other electronic devices.

[0039] When users use mobile phones and other electronic devices in their daily lives, commonly used features (such as calls, games, short video apps, shopping apps, and chat apps) only account for a small portion of mobile applications, while other features (such as memos and calendars) have a lower usage rate. Furthermore, even the usage rate of the same feature may vary in different scenarios.

[0040] by Figure 1Taking the air gesture recognition feature as an example: its usage rate is relatively high in scenarios where hands are wet and it is inconvenient to operate the phone; its usage rate is relatively low in scenarios where both hands can easily operate the phone; its usage rate is extremely low in scenarios such as cycling, driving navigation, playing games (which require strong interaction with the touchscreen), and in very low-light environments; some users may reduce their usage rate or not use it at all after the novelty of air gesture recognition wears off; air gesture operation is not supported in scenarios that are incompatible with or do not support air gesture recognition, such as landscape mode, lock screen, text input method, split screen or floating window, phone and laptop collaboration, one-handed operation mode, screen reading, etc.

[0041] Furthermore, the specifications (e.g., display interface, resource consumption) of the same feature may differ in different scenarios. Figure 2 Taking the video call scenario shown as an example, such as Figure 2 As shown in Figure A, when a video call begins, both parties focus on the video call interface, at which point a full-screen video call can be used. (See Figure A for details.) Figure 2 As shown in Figure B, after a period of time, if one party no longer needs to focus on the video call interface but needs to browse the web, the call will switch to a pop-up video call format. Figure 2 As shown in C, after a while, if one party finds that the small-window video call interface still obscures the webpage and is inconvenient to move around, they will switch to a hidden voice call mode. After a while, if one party needs to rest their eyes, they will turn off the screen and switch to a screen-off voice call mode.

[0042] Furthermore, during operation, the system load is very heavy, and thread priority allocation may not be reasonable. The features running on the electronic device may not match the thread priorities, resulting in wasted resources. For example, considering the overall thread load, a mobile phone runs more than 6,000 threads after booting up, and in some scenarios, even more than 8,000 threads. Moreover, some threads are active threads with even higher loads. Taking the scenario of video call combined with web browsing as an example, the number of active threads exceeds 2,000 within 10 seconds.

[0043] like Figure 3 As shown in diagram A, high-priority threads (e.g., thread A) are typically used to execute critical functions, while low-priority threads (e.g., thread B) are typically used to execute non-critical functions, such as functions with certain characteristics. However, in some scenarios, to ensure a fast response to specific characteristics, these non-critical functions are added to high-priority threads. This can lead to bloated high-priority threads that may not actually execute high-priority tasks, resulting in lower execution efficiency. A more ideal scenario would be... Figure 3 As shown in Figure B, high-priority threads execute critical functions, while low-priority threads execute non-critical functions.

[0044] For example, a high-priority InputReader thread is used to quickly respond to touch events on the touchscreen. However, if a function (a non-critical function) that could originally be dynamically activated (selectably activated or deactivated) for knuckle recognition is added to the InputReader thread, i.e., implemented through the InputReader thread, then the InputReader thread will frequently check the touchscreen for knuckle tap events with high priority. As another example, a high-priority desktop thread is used to quickly respond to icon clicks, but if... Figure 4 The function (non-critical function) that could originally dynamically activate the three-finger swipe feature is added to the desktop thread, that is, implemented through the desktop thread. The desktop thread will then frequently check whether a three-finger swipe event has occurred with high priority.

[0045] The thread control method and electronic device provided in this application, by combining the scene information and state information of the electronic device, as well as thread control strategies for different types of characteristics, obtain the QoS level of the target thread to be controlled. The target thread is a thread with at least one characteristic among different types, and the QoS level represents the priority of the target thread. The target thread is then controlled according to the QoS level. This achieves matching between the operating characteristics of the electronic device and the priority of the thread. For details regarding the scene information and state information of the electronic device, please refer to... Figure 12 The relevant descriptions of S101 will not be repeated here.

[0046] The thread control strategies in this application include thread control strategies for persistent characteristics, dynamic characteristics, and third-party threads. Persistent characteristics refer to system-native, critical, and persistently running characteristics, such as touchscreen and display characteristics. Dynamic characteristics refer to non-critical, dynamically activated (selectably activated or deactivated) characteristics native to the electronic device system, such as air gesture recognition and knuckle recognition. Third-party characteristics refer to non-system-native characteristics, such as those found in chat applications and short video applications.

[0047] Since resident and dynamic characteristics are system-native, their target threads can be controlled via hook functions. Hook functions are code used to control threads and can be loaded into the system and executed via system call threads. Hook functions control the target thread based on its corresponding Quality of Service (QoS) level. The hook function corresponding to the target thread and its QoS level can form a data pair. The thread's QoS level indicates its priority (or importance); a higher QoS level indicates higher priority (or importance), and a lower QoS level indicates lower priority (or importance).

[0048] The correspondence between hook functions and target threads can be one-to-many or one-to-one.

[0049] One-to-many: When a process includes multiple threads, a hook function can control all threads within a process (the main thread and other threads of the process are the target threads corresponding to this hook function). It is not necessary for each thread to correspond to a hook function, which can reduce the calling frequency of hook functions and the implementation complexity.

[0050] One-to-one: When the target thread is a kernel thread or a process consists of only one main thread (as the target thread), one hook function corresponds to one target thread.

[0051] Since third-party features are not native to the system, hook functions cannot be designed in advance. Therefore, the target thread can be identified using a thread identifier (TID), and the system scheduling thread can control the target thread corresponding to the TID based on the QoS level of the target thread. The TID and QoS level of the target thread can also form a data pair.

[0052] like Figures 5-7 As shown in Figure A, the data structure of the thread control strategy includes the starting address of the scenario lookup table for resident characteristics, the starting address of the characteristic lookup table for dynamic characteristics, and the starting address of the scenario lookup table for third-party characteristics. The scenario lookup tables for resident characteristics, dynamic characteristics, and third-party characteristics are stored independently, and the starting address is equivalent to a pointer used to index these lookup tables.

[0053] The scenario lookup table for persistent characteristics is used to control the first target thread of the persistent characteristic; that is, the scenario lookup table for persistent characteristics represents the thread control strategy of the persistent characteristic. The characteristic lookup table for dynamic characteristics is used to control the second target thread of the dynamic characteristic; that is, the characteristic lookup table for dynamic characteristics represents the thread control strategy of the dynamic characteristic. The scenario lookup table for third-party characteristics is used to control the third target thread of the third-party characteristic; that is, the scenario lookup table for third-party characteristics represents the thread control strategy of the third-party characteristic.

[0054] I. A scene lookup table for persistent characteristics, including the mapping relationship between scene information, status information and data pairs (hook functions and QoS levels) of electronic devices.

[0055] like Figure 5 As shown in Figure B, the scene lookup table for persistent characteristics includes the addresses of each scene (e.g., scene 1, scene 2) and the state type lookup tables for each scene (e.g., the state type lookup table for scene 1, the state type lookup table for scene 2). By querying the scene in the scene lookup table of persistent characteristics through the scene information of the electronic device, the address of the state type lookup table for that scene can be determined, and thus the state type lookup table for that scene can be determined. For example, scene 1 is a full-screen video call, and scene 2 is a voice call.

[0056] like Figure 5 As shown in Figure C, the state type lookup table for each scenario (e.g., the state type lookup table for scenario 1) includes a level, a first-level parameter, and optionally, second-level parameters and higher-level parameters. The level indicates the number of parameter levels. The first-level parameter is the address of the default base lookup table for resident characteristics. The second-level parameters and other level parameters include the state type (e.g., state type 1, state type 2) and the addresses of the value lookup tables for the state types of resident characteristics (e.g., the value lookup table for state type 1, the value lookup table for state type 2). Therefore, the level equals the number of state types plus 1. By querying the state type in the state type lookup table for each scenario through the state type in the electronic device's state information, the address of the value lookup table for the state type of the resident characteristic can be determined, and thus the value lookup table for the state type of the resident characteristic can be determined. For example, the state type 1 of the second-level parameter is temperature, the state type 2 of the third-level parameter is battery life level, and so on.

[0057] like Figure 5As shown in Figure D, the default base lookup table for resident features includes multiple entries. Each entry includes a hook function and a QoS level corresponding to a first target thread, which is the thread of the resident feature. The result of querying the default base lookup table for resident features is all entries (i.e., data pairs) of that lookup table. The meaning of the default base lookup table for resident features is that, in the absence of level 2 parameters or higher-level parameters, these entries in the default base lookup table for resident features can be active simultaneously, thereby controlling the first target threads of all resident features involved in this scenario to run in the default state. It should be noted that QoS level 1, QoS level 2, etc., in this application are only used to distinguish QoS levels and do not indicate that the QoS level value is 1 or 2.

[0058] like Figure 5 As shown in Figure E, the lookup table for the state type of a resident characteristic includes different values ​​for that state type, as well as the address of the base lookup table for the state type values ​​of the resident characteristic. By querying the value in the lookup table for the state type value in the electronic device's state information, the address of the corresponding base lookup table can be determined, and thus the corresponding base lookup table can be identified. The base lookup table for the state type values ​​of a resident characteristic includes multiple entries, each entry including a hook function and QoS level corresponding to a first target thread that constitute a data pair. The result of querying the base lookup table for the state type values ​​of a resident characteristic is all entries (i.e., data pairs) of the lookup table. Taking state type 1 as temperature as an example, when the value 1 of state type 1 is 37 degrees, the base lookup table for the value 1 of state type 1 of the resident characteristic is retrieved; when the value 1 of state type 1 is 42 degrees, the base lookup table for the value 2 of state type 1 of the resident characteristic is retrieved. It should be noted that in this application, the values ​​1 and 2 of the state type are only used to distinguish different values ​​of the same state type and do not represent the value as 1 or 2.

[0059] It should be noted that identical entries in different base lookup tables of resident characteristics (such as the default base lookup table of resident characteristics and the value lookup table of the state type of resident characteristics) can share storage space to save storage space.

[0060] After querying the entire scenario lookup table for resident characteristics, the set of data pairs with no duplicates and the lowest QoS level is obtained from the data pairs in the different basic lookup tables of the resident characteristics. The specific steps are as follows.

[0061] First, the union of data pairs from different base lookup tables for the resident characteristics retrieved is taken to obtain the initial set. For example, given two data pairs from one base lookup table (hook function 1, QoS level value 1) and (hook function 1, QoS level value 2), and two data pairs from another base lookup table (hook function 1, QoS level value 2) and (hook function 5, QoS level value 3), the initial set includes the data pairs (hook function 1, QoS level value 1), (hook function 1, QoS level value 2), and (hook function 5, QoS level value 3).

[0062] Then, for each hook function in the initial set, the data pair with the lowest QoS level (i.e., the first QoS level and the first hook function) is retained, resulting in a set of data pairs with no duplicates and the lowest QoS level. In other words, when the first hook function corresponds to multiple different or the same QoS level, the first QoS level is the lowest. For example, the data pairs in the initial set can be sorted twice: first by hook function, and then by QoS level for data pairs with the same hook function. For each hook function, the data pair with the lowest QoS level is selected, resulting in a set of data pairs with no duplicates and the lowest QoS level. This ensures that the first target thread is properly controlled according to its resource requirements. For example, if the initial set contains two data pairs (hook function 1, QoS level 1) and (hook function 1, QoS level 2), then the data pair (hook function 1, QoS level 1) is retained.

[0063] For each data pair that is ultimately retained, the first hook function controls the first target thread corresponding to that data pair according to the first QoS level.

[0064] II. The feature lookup table for dynamic features includes the feature call frequency, the mapping relationship between electronic device status information and data pairs (hook functions and QoS levels). The feature lookup table for dynamic features is not scenario-sensitive, meaning it can be traversed in any scenario.

[0065] like Figure 6 As shown in Figure B, the feature lookup table for dynamic features includes the addresses of each feature (e.g., feature 1, feature 2) and the frequency level lookup tables for each feature (e.g., the frequency level lookup table for feature 1 and the frequency level lookup table for feature 2). By traversing each feature in the feature lookup table of dynamic features, if a feature is activated, its usage frequency is queried from the system. Based on the usage frequency of the feature, the address of its frequency level lookup table can be determined, and thus the frequency level lookup table for that feature can be determined. For example, feature 1 is an air gesture recognition feature, and feature 2 is a knuckle recognition feature.

[0066] like Figure 6 As shown in Figure C, the frequency level lookup table for each feature (e.g., the frequency level lookup table for feature 1) includes the addresses of multiple frequency level state type lookup tables. Each frequency level represents the frequency at which the feature is invoked; for example, frequency levels 1-4 correspond to the frequencies of never, extremely low frequency, very low frequency, and low frequency, respectively. By querying each frequency level through the invocation frequency of the feature, the address of the corresponding frequency level's state type lookup table can be determined, thus identifying the state type lookup table for that frequency level.

[0067] like Figure 6 As shown in Figure D, the frequency level state type lookup table includes the addresses of various state types (e.g., state type 1, state type 2) and dynamic characteristic state type value lookup tables (e.g., dynamic characteristic state type 1 value lookup table, dynamic characteristic state type 2 value lookup table). By querying the state type in the state type lookup table of each frequency level through the state type in the electronic device's state information, the address of the dynamic characteristic state type value lookup table can be determined, and thus the dynamic characteristic state type value lookup table can be determined. For example, state type 1 is temperature, state type 2 is battery life level, and so on.

[0068] Figure 6 As shown in Figure E, the lookup table for the state type of a dynamic characteristic includes the different values ​​for that state type, as well as the address of the base lookup table for the state type values ​​of the dynamic characteristic. By querying the value in the lookup table for the state type value in the electronic device's state information, the address of the base lookup table for the state type values ​​of the dynamic characteristic can be determined, and thus the base lookup table for the state type values ​​of the dynamic characteristic can be determined. Figure 5 Similar to the base lookup table for the state type values ​​of resident characteristics, the base lookup table for the state type values ​​of dynamic characteristics includes multiple entries. Each entry includes a hook function and QoS level corresponding to a second target thread, which is the thread of the dynamic characteristic. The result of querying the base lookup table for the state type values ​​of dynamic characteristics is all entries (i.e., data pairs) of that lookup table.

[0069] It should be noted that identical entries in different base lookup tables of dynamic characteristics (such as the base lookup table for the value of the state type of dynamic characteristics) can share storage space to save storage space.

[0070] After querying the entire feature lookup table for the dynamic feature, the set of unique data pairs with the lowest QoS level is obtained from the data pairs in the different base lookup tables of the retrieved dynamic feature. Similar to resident features, the specific steps are as follows:

[0071] First, the union of data pairs from different base lookup tables representing the retrieved dynamic characteristics is taken to obtain an initial set. Then, for each hook function in the initial set, the data pair with the lowest QoS level (i.e., the second QoS level and the second hook function) is retained, resulting in a set of unique data pairs with the lowest QoS level. In other words, when the second hook function corresponds to multiple different or identical QoS levels, the second QoS level is the lowest. This ensures that the second target thread is properly controlled according to its resource requirements.

[0072] For each data pair that is ultimately retained, the second hook function controls the second target thread corresponding to that data pair according to the second QoS level.

[0073] 3. A third-party feature-based scenario lookup table, which includes the mapping relationship between scenario information, status information and data pairs (TID and QoS level) of electronic devices.

[0074] like Figure 7 As shown in Figure B, the third-party feature scene lookup table includes the addresses of each scene (e.g., scene 1, scene 2) and the state type lookup tables for each scene (e.g., scene 1 lookup table, scene 2 lookup table). By querying the scene in the third-party feature scene lookup table using the scene information of the electronic device, the address of the state type lookup table for that scene can be determined, and thus the state type lookup table for that scene can be determined. For example, scene 1 is a full-screen video call, and scene 2 is a voice call.

[0075] like Figure 7 As shown in Figure C, the state type lookup table for each scenario (e.g., the state type lookup table for scenario 1) includes a level and a first-level parameter. Optionally, it may also include second-level parameters and higher-level parameters. The level indicates the number of parameter levels. The first-level parameter is the address of the default base lookup table for third-party features. Second-level parameters and other level parameters include the state type (e.g., state type 1, state type 2) and the address of the value lookup table for the state type of the third-party feature (e.g., the value lookup table for state type 1 of the third-party feature, the value lookup table for state type 2 of the third-party feature). Therefore, the level equals the number of state types plus 1. By querying the state type in the state type lookup table of each scenario through the state type in the electronic device's state information, the address of the value lookup table for the state type of the third-party feature can be determined, and thus the value lookup table for the state type of the third-party feature can be determined. For example, the state type 1 of the second-level parameter is temperature, the state type 2 of the third-level parameter is battery life level, and so on.

[0076] like Figure 7As shown in Figure D, the default base lookup table for third-party features includes multiple entries. Each entry includes the QoS level corresponding to a third target thread and the address of the thread context. The third target thread is the thread of the third-party feature. The thread context includes the process name, thread name, number of process identifiers (PIDs), and the address of the PID information. The number of PIDs indicates how many addresses of PID information exist. The same PID information includes the number of TIDs and a list of TIDs. The number of TIDs indicates how many TIDs are in the TID list. The thread represented by the TID in the TID list is the third target thread. The result of querying the default base lookup table for third-party features is all entries of the lookup table. The address of the PID information is retrieved through the address of the thread context. Then, based on the process name and thread name, the PID and the corresponding TID list for each PID are retrieved from the system. The PIDs and TIDs are filled into the reserved address space in the table entry. Each TID in the TID list forms a data pair with its corresponding QoS level. The meaning of the default base lookup table for third-party features is that, in the absence of second-level parameters and higher-level parameters, these entries in the default base lookup table for third-party features can be effective simultaneously, thereby controlling the third target threads of all third-party features involved in the scenario to run in the default state.

[0077] like Figure 7 As shown in Figure E, the lookup table for the status type of a third-party characteristic includes different values ​​for that status type, as well as the address of the base lookup table for that status type. By querying the lookup table for the status type value in the electronic device's status information, the address of the base lookup table for the corresponding third-party characteristic's status type can be determined, thus identifying the base lookup table itself. The result of querying the base lookup table for the status type of the third-party characteristic is all the entries in that lookup table. The address of the PID information is queried using the thread context address, which in turn retrieves the TID list. Each TID in the TID list forms a data pair with its corresponding QoS level.

[0078] It should be noted that identical entries in different base lookup tables of third-party features (such as the default base lookup table of third-party features and the base lookup table for the value of the state type of third-party features) can share storage space to save storage space.

[0079] After querying the entire scenario lookup table for third-party features, the set of unique data pairs with the lowest QoS level is obtained from the data pairs in the different base lookup tables of the retrieved third-party features. The specific steps are as follows:

[0080] First, the union of data pairs from different base lookup tables for the retrieved third-party features is taken to obtain the initial set. For example, given two data pairs from one base lookup table (TID1, QoS level 1) and (TID1, QoS level 2), and two data pairs from another base lookup table (TID1, QoS level 2) and (TID5, QoS level 3), the initial set would include the data pairs (TID1, QoS level 1), (TID1, QoS level 2), and (hook function 5, QoS level 3).

[0081] Then, for each TID in the initial set, the data pair with the lowest QoS level (i.e., the third QoS level and TID) is retained, resulting in a set of data pairs with no duplicates and the lowest QoS level. In other words, when a TID corresponds to multiple different or the same QoS level, the third QoS level is the lowest. For example, the data pairs in the initial set can be sorted twice: first by TID, then by QoS level for data pairs with the same TID, and finally, the data pair with the lowest QoS level for each TID is selected, resulting in a set of data pairs with no duplicates and the lowest QoS level. This ensures that the third target thread is properly controlled according to its resource requirements. For example, if the initial set contains two data pairs (TID1, QoS level value 1) and (TID1, QoS level value 2), then the data pair (TID1, QoS level value 1) is retained.

[0082] The constructed data pair TID and the third QoS level are sent to the system scheduler, which then controls the third target thread corresponding to the TID based on the third QoS level.

[0083] like Figure 8 As shown in the figure, this application embodiment provides a thread control system, including an electronic device 101 and a server 102.

[0084] At the software level, the electronic device 101 includes a scene recognition module 1011, a scene-based control platform 1012, a third-party feature strategy customization module 1013, a thread control strategy management module 1014, a system native resident feature and dynamic feature strategy customization module 1015, a thread control strategy database 1016, and a thread control effect evaluation and feedback module 1017.

[0085] The third-party feature strategy customization module 1013 is used to send the thread control strategy of the third-party feature to the thread control strategy management module 1014, and the system native resident feature and dynamic feature strategy customization module 1015 is used to send the thread control strategy of the resident feature and dynamic feature to the thread control strategy management module 1014.

[0086] The thread control policy database 1016 stores thread control policies, including those for third-party features, as well as those for persistent and dynamic features. On one hand, developers can pre-configure thread control policies in the database 1016; on the other hand, the thread control policy management module 1014 can update the thread control policies stored in the database 1016 based on these policies.

[0087] The scene recognition module 1011 is used to send the scene information and status information of the electronic device to the scene-based control platform 1012. For details regarding the scene information and status information of the electronic device, please refer to... Figure 12 The relevant description of S101 will not be repeated here. The scenario-based control platform 1012 obtains thread control policies from the thread control policy database 1016 through the thread control policy management module 1014, and executes the thread control policies in conjunction with the scenario information and status information of the electronic devices. Thread control specifically includes scheduling control, freeze control, service level control, bypass control, start / stop control, and delay avoidance control. For details on these thread control methods, please refer to [reference needed]. Figure 12 The relevant description of S103 will not be repeated here.

[0088] The thread control effect evaluation and feedback module 1017 is used to evaluate the thread control effect (such as the positive and negative gains of thread control), and also to synchronize the thread control strategy with the server 102, and send the synchronized thread control strategy to the thread control strategy management module 1014. The server 102 can synchronize the thread control strategy with a large number of electronic devices (not just electronic device 101, but also other electronic devices), and can also interact with R&D personnel to help update the thread control strategy in the cloud database.

[0089] like Figure 9 As shown, taking the Android operating system running on an electronic device as an example, the software architecture includes the application layer, framework layer, native layer, hardware abstraction layer (HAL) layer, and kernel layer.

[0090] The application layer can include a series of application packages, such as camera, call, game, short video, and chat applications. The framework layer provides application programming interfaces (APIs) and programming frameworks for the applications in the application layer. The framework layer includes some predefined functions. The native layer includes native services and linked libraries. The HAL layer is used to abstract the hardware. The HAL layer hides the details of the platform-specific hardware interface, providing the operating system with a virtual hardware platform, and is hardware independent. The kernel layer is the layer between hardware and software.

[0091] Figure 8 The scene recognition module 1011 in the middle can be located in Figure 9 In the application layer, the third-party feature strategy customization module 1013 and the system's native resident and dynamic feature strategy customization modules 1015 can be located in Figure 9 The framework layer. Other modules can be distributed across multiple layers; for example, the thread control strategy database 1016, the thread control strategy management module 1014, and the scenario-based control platform 1012 can be distributed across multiple layers. Figure 9 The framework layer, native layer, HAL layer, and kernel layer; the thread control effect evaluation and feedback module can be distributed in... Figure 9 The application layer, framework layer, local layer, HAL layer, and kernel layer are included.

[0092] For a scenario-based control platform, in one possible implementation, such as Figure 10 As shown in AD, the contextual control platform at the upper layer (non-kernel layer) can perform thread control on target threads at the same layer. Since the target thread calls other threads layer by layer downwards, the contextual control platform indirectly achieves thread control on other threads called by the target thread at lower layers by controlling the target thread at the same layer. For example... Figure 10 As shown in Figure A, the scenario-based control platform at the framework layer controls thread BB at the framework layer. Thread BB then calls thread CC at the local layer, thread DD calls thread DD at the HAL layer, and thread DD calls thread EE at the kernel layer. Therefore, the scenario-based control platform at the framework layer controls thread CC, thread DD, and thread EE layer by layer by controlling thread BB at the framework layer. In another possible implementation, as... Figure 10 As shown in Figure E, the scenario-based control platform at each layer can also independently control the target thread at the same layer based on the interface for inter-process or inter-thread communication.

[0093] The electronic device provided in this application embodiment can be mobile or fixed. It can be deployed on land (e.g., indoors or outdoors, handheld or vehicle-mounted), on water (e.g., ships), or in the air (e.g., airplanes, balloons, and satellites). This electronic device can be referred to as user equipment (UE), access terminal, terminal unit, subscriber unit, terminal station, mobile station (MS), mobile station, terminal agent, or terminal device, etc. For example, it can be a mobile phone, tablet computer, laptop computer, smart bracelet, smart screen, smartwatch, headphones, smart speaker, virtual reality (VR) device, augmented reality (AR) device, terminal in industrial control, terminal in self-driving, terminal in remote medical care, terminal in smart grid, terminal in transportation safety, terminal in smart city, terminal in smart home, etc. This application does not limit the specific type and structure of the electronic device. The following describes one possible structure of the electronic device.

[0094] like Figure 11 As shown, taking a mobile phone as an example, at the hardware level, the electronic device 101 may include a processor 210, an external memory interface 220, an internal memory 221, a universal serial bus (USB) interface 230, a power management module 240, a battery 241, a wireless charging coil 242, an antenna 1, an antenna 2, a mobile communication module 250, a wireless communication module 260, an audio module 270, a speaker 270A, a receiver 270B, a microphone 270C, a headphone jack 270D, a sensor module 280, buttons 290, a motor 291, an indicator 292, a camera 293, a display screen 294, and a subscriber identification module (SIM) card interface 295, etc. Optionally, in some embodiments, it may also include an audio digital signal processor (ADSP) 243.

[0095] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the electronic device 101. In other embodiments of this application, the electronic device 101 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0096] Processor 210 may include one or more processing units, such as: a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), a system-on-chip (SoC), a central processing unit (CPU), an application processor (AP), a network processor (NP), a digital signal processor (DSP), a microcontroller unit (MCU), a programmable logic device (PLD), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a video codec, a baseband processor, and a neural network processing unit (NPU), etc. Different processing units may be independent devices or integrated into one or more processors. For example, processor 210 may be an application processor (AP). Alternatively, processor 210 may be integrated into a system-on-chip (SoC). Or, processor 210 may be integrated into an integrated circuit (IC) chip. The processor 210 may include an analog front end (AFE) and a micro-controller unit (MCU) in an IC chip.

[0097] The ADSP 243 can be coupled to the audio module 270 and the sensor module 280. The ADSP 243 can process audio signals and sensor data. Even when the processor is in sleep mode, the ADSP 243 can remain operational, thereby reducing the power consumption of the electronic device.

[0098] It is understood that the interface connection relationships between the modules illustrated in the embodiments of this application are merely illustrative and do not constitute a structural limitation on the electronic device 101. In other embodiments of this application, the electronic device 101 may also adopt different interface connection methods or a combination of multiple interface connection methods as described in the above embodiments.

[0099] The wireless communication function of electronic device 101 can be realized through antenna 1, antenna 2, mobile communication module 250, wireless communication module 260, modem processor and baseband processor.

[0100] Antennas 1 and 2 are used to transmit and receive electromagnetic wave signals. Each antenna in electronic device 101 can be used to cover one or more communication frequency bands. Different antennas can also be multiplexed to improve antenna utilization. For example, antenna 1 can be multiplexed as a diversity antenna for a wireless local area network. In some other embodiments, the antennas can be used in conjunction with a tuning switch.

[0101] Mobile communication module 250 can provide wireless communication solutions including 2G / 3G / 4G / 5G for use on electronic device 101. Wireless communication module 260 can provide wireless communication solutions including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), and infrared (IR) for use on electronic device 101. In some embodiments, antenna 1 of electronic device 101 is coupled to mobile communication module 250, and antenna 2 is coupled to wireless communication module 260, enabling electronic device 101 to communicate with networks and other devices via wireless communication technology.

[0102] The external storage interface 220 can be used to connect an external memory card, such as a micro SanDisk (Micro SD) card, to expand the storage capacity of the electronic device 101. The external memory card communicates with the processor 210 through the external storage interface 220 to perform data storage functions. For example, music, video, and other files can be saved on the external memory card.

[0103] Internal memory 221 can be used to store computer executable program code, which includes computer instructions. Processor 210 executes various functional applications and data processing of electronic device 101 by running the computer instructions stored in internal memory 221. In addition, internal memory 221 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc.

[0104] The memory involved in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM). It should be noted that the memory used in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0105] Electronic device 101 can implement audio functions such as music playback and recording through audio module 270, speaker 270A, receiver 270B, microphone 270C, headphone jack 270D, and application processor.

[0106] Audio module 270 is used to convert digital audio information into analog audio signal output, and also to convert analog audio input into digital audio signal. In some embodiments, audio module 270 may be located in processor 210, or some functional modules of audio module 270 may be located in processor 210. Speaker 270A, also called a "loudspeaker," is used to convert audio electrical signals into sound signals. Receiver 270B, also called a "handpiece," is used to convert audio electrical signals into sound signals. Microphone 270C, also called a "microphone" or "microphone," is used to convert sound signals into electrical signals. Electronic device 101 may be equipped with at least one microphone 270C. Headphone jack 270D is used to connect wired headphones. Headphone jack 270D may be a USB interface 230, or a 3.5mm Open Mobile Terminal Platform (OMTP) standard interface, or a Cellular Telecommunications Industry Association of the USA (CTIA) standard interface.

[0107] Buttons 290 include a power button, volume buttons, etc. Buttons 290 can be mechanical buttons or touch buttons. Electronic device 101 can receive button input and generate key signal inputs related to user settings and function control of electronic device 101. Motor 291 can generate vibration alerts. Motor 291 can be used for incoming call vibration alerts or for touch vibration feedback. Indicator 292 can be an indicator light, used to indicate charging status, battery level changes, messages, missed calls, notifications, etc. SIM card interface 295 is used to connect a SIM card. The SIM card can be inserted into or removed from the SIM card interface 295 to achieve contact and separation with electronic device 101. Electronic device 101 can support one or N SIM card interfaces, where N is a positive integer greater than 1. SIM card interface 295 can support Nano SIM cards, Micro SIM cards, SIM cards, etc. In some embodiments, electronic device 101 employs an embedded SIM (eSIM) card, which can be embedded in electronic device 101 and cannot be separated from electronic device 101.

[0108] Electronic device 101 can implement shooting functions through an ISP, camera 293, video codec, GPU, display 294, and application processor. The ISP is used to process data fed back by the camera 293. In some embodiments, the ISP can be set in the camera 293. The camera 293 is used to capture still images or videos. In some embodiments, electronic device 101 may include one or N cameras 293, where N is a positive integer greater than 1.

[0109] Electronic device 101 can implement display functions through a GPU, display screen 294, and application processor. The GPU is a microprocessor for image processing, connected to the display screen 294 and the application processor. The GPU is used to perform mathematical and geometric calculations and for graphics rendering. Processor 210 may include one or more GPUs, which execute computer instructions to generate or modify display information.

[0110] The sensor module 280 may include a pressure sensor, a gyroscope sensor, a barometric pressure sensor, a magnetic sensor, an accelerometer, a distance sensor, a proximity sensor, a fingerprint sensor, a temperature sensor, a touch sensor, an ambient light sensor, an angle sensor, etc. When the display screen 294 is a foldable screen, the angle sensor can detect the folding angle of the display screen 294, which ranges from 0 to 180 degrees.

[0111] Battery 241 may include one or more batteries to power a load.

[0112] The power management module 240 is used to receive charging input from a charger. The charger can be a wireless charger, such as a wireless charging dock, or other electronic device 101 with reverse wireless charging capability. The power management module 240 can receive wireless charging input via the wireless charging coil 242 of the electronic device. The charger can also be a wired charger; for example, the power management module 240 can receive charging input from a wired charger via a USB interface 230. The power management module 240 is also referred to as a charging chip.

[0113] The power management module 240 charges the battery 241 while simultaneously supplying power to the electronic devices. It receives input from the battery 241 and powers the processor 210, internal memory 221, external memory interface 220, display screen 294, camera 293, and wireless communication module 260. The power management module 240 can also monitor parameters such as the battery 241's capacity, voltage, battery cycle count, and battery health status (leakage current, impedance). In some other embodiments, the power management module 240 may also be integrated into the processor 210.

[0114] The display screen 294 is used to display images, videos, etc. The display screen 294 includes a display panel. In some embodiments, the electronic device 101 may include one or more display screens 294.

[0115] The processor 210 may also include a memory for storing computer instructions and data. In some embodiments, the memory in the processor 210 is a cache memory. This memory can store computer instructions or data that the processor 210 has just used or that are being used repeatedly. If the processor 210 needs to use the same computer instructions or data again, it can retrieve them directly from the memory. This avoids repeated accesses, reduces the waiting time of the processor 210, and thus improves system efficiency.

[0116] In some embodiments, the processor 210 may include one or more interfaces. These interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a USB interface, etc.

[0117] The processor 210 executes the thread control method provided in this application embodiment by executing the program and computer instructions stored in the internal memory 221.

[0118] like Figure 12 As shown in the embodiments of this application, the thread control method includes:

[0119] S101, The scene recognition module acquires scene information and status information of the electronic device.

[0120] Context information for electronic devices describes their usage scenarios, such as full-screen video calls and voice calls. This context information can be uniquely identified through coding. Status information for electronic devices describes their operational state. This status information includes status types and corresponding values, both of which can be uniquely identified through coding. For example, status types include temperature, battery life rating, CPU load, battery level, and charging status. Correspondingly, the values ​​for each status type include temperature, battery life rating, CPU load, battery level, and whether charging is in progress.

[0121] S102. The scenario-based control platform obtains the data pairs (including the QoS level of the target thread) corresponding to the target thread to be controlled based on the scenario information, status information and thread control strategies of different types of electronic devices.

[0122] As mentioned earlier, thread control strategies with different characteristics include system-native persistent thread control strategies, system-native dynamic thread control strategies, and third-party thread control strategies. The target thread is a thread with at least one of the following characteristics: persistent, dynamic, or third-party.

[0123] Combination Figure 5 For persistent features, the scenario-based control platform obtains the data pair (including the first QoS level and the first hook function) corresponding to the first target thread based on the scenario information, state information of the electronic device, and the thread control strategy of the persistent feature. The first target thread is the thread of the persistent feature. This process refers to... Figure 5 The relevant descriptions will not be repeated here.

[0124] Combination Figure 6 For dynamic features, regardless of the scene information, the scene-based control platform obtains the data pair (including the second QoS level and the second hook function) corresponding to the second target thread based on the electronic device's state information, the activation frequency of the dynamic feature, and the thread control strategy of the dynamic feature. The second target thread is the thread of the dynamic feature. This process refers to... Figure 6 The relevant descriptions will not be repeated here.

[0125] Combination Figure 7 For third-party features, the contextual control platform obtains the data pair (including the third QoS level and TID) corresponding to the third target thread based on the electronic device's context information, status information, and the thread control strategy of the third-party feature. The third target thread is the thread of the third-party feature. This process refers to... Figure 7 The relevant descriptions will not be repeated here.

[0126] In addition, such as Figure 13 As shown in S201, if the data pair corresponding to the target thread cannot be found, the default data pair will be used as the data pair for the target thread to execute the default thread control strategy. This is because thread control strategies cannot exhaustively cover all scenarios; for scenarios not covered by existing thread control strategies, the default thread control strategy will be executed.

[0127] like Figure 13 As shown in S202, if a data pair corresponding to the target thread is found, the scenario-based control platform can compare the data pair found in this round with the data pairs that have already taken effect in the previous round, and obtain the same data pairs. Subtracting the aforementioned same data pairs from the data pairs found in this round yields the data pairs corresponding to the target thread that are effective in this round, thus avoiding duplicate data pair activation.

[0128] like Figure 13 As shown in S203, if a data pair corresponding to the target thread is found, the scenario-based control platform can subtract the aforementioned identical data pairs from the data pairs that have already taken effect in this round of search to obtain the data pair corresponding to the target thread to be rolled back. The rollback of the target thread is then controlled based on the QoS level in the data pair corresponding to the target thread to be rolled back. This is equivalent to rolling back a target thread that does not meet the control objective of this round of threading to its initial state. For example, if a target thread was controlled to switch from full mode to lightweight mode before this round of search, then target thread rollback means controlling that target thread to switch back from lightweight mode to full mode.

[0129] Steps S202 and S203 essentially implement the following: when the scene information changes, the data pair corresponding to the target thread is searched from the thread control strategy according to the updated scene information; when the state information changes, the data pair corresponding to the target thread is searched from the thread control strategy according to the updated state information; and when the activation status of the dynamic feature changes, the data pair corresponding to the target thread is searched from the thread control strategy according to the updated activation status of the dynamic feature.

[0130] S103. The scenario-based control platform controls the target thread based on the QoS level in the data pair corresponding to the target thread.

[0131] Combination Figure 5 For persistent characteristics, the scenario-based control platform calls the first hook function to control the first target thread based on the first QoS level. Combined with... Figure 6 For dynamic characteristics, the scenario-based control platform calls the second hook function to control the second target thread based on the second QoS level. Combined with... Figure 7For third-party features, the scenario-based control platform calls the system scheduling thread to control the third target thread corresponding to the TID according to the third QoS level.

[0132] It should be noted that hook functions can control the target thread themselves based on the QoS level (e.g., control the start or exit of the target thread), or send the QoS level to the target thread so that the target thread can control itself based on the QoS level (e.g., switch between full mode and lightweight mode).

[0133] When a process comprises multiple threads, a single hook function can control all threads within that process. That is, the process's main thread and all other threads are target threads corresponding to that hook function. This eliminates the need for a separate hook function for each thread, reducing the frequency of hook function calls and implementation complexity. A hook function can communicate with all threads of the process to control them, or it can control the process's other threads by controlling the main thread. For example, a hook function can send a QoS level to all threads of the process. Alternatively, a hook function can send a QoS level to the process's main thread, which then sets the QoS level as a shared thread environment variable within the process. Other threads within the same process can also obtain the QoS level through this thread environment variable.

[0134] The types of control applied to target threads include system capability control and thread QoS management control.

[0135] System capability controls include scheduling control and freezing control. Scheduling control involves the target thread sending its thread identifier (TID) to the system scheduling service. The system scheduling service then uses the TID to speed up or suppress the target thread in terms of core selection, frequency selection, and grouping. This control method relies on the scheduling system's capabilities. Freezing control involves the target thread adding its TID to a control group (cgroup). The freezer subsystem freezes or wakes up the control group periodically, thereby periodically freezing or waking up the target threads within the control group. Control groups are a mechanism used by the Linux kernel to control system resources. Control groups divide all threads into groups and control them accordingly. For example, the freezer subsystem can freeze or wake up threads in batches according to their groups.

[0136] Thread QoS management includes service level control, bypass control, start / stop control, and delay avoidance control.

[0137] Service level control (SLS) includes dynamic priority adjustment, full / lightweight mode control, and runtime frequency adjustment. Dynamic priority adjustment refers to dynamically adjusting the thread's priority based on its QoS level; the higher the QoS level, the higher the priority. Full / lightweight mode control involves dynamically switching between full and lightweight modes based on the QoS level. Full mode is used when the QoS level is above a threshold; otherwise, lightweight mode is used. For example, a chat application thread operates in full mode during a full-screen video call, while it operates in lightweight mode during a small-window video or voice call. Runtime frequency adjustment refers to controlling the sleep cycle or thread detection cycle based on the QoS level; the lower the QoS level, the longer the sleep cycle or thread detection cycle. Thread detection refers to statistically analyzing the thread's running status.

[0138] Bypass control refers to controlling the entire thread to stop performing business operations or stopping some functions of the thread based on the QoS level. For example, if the QoS level of the thread is lower than the threshold, the entire thread will be controlled to stop performing business operations or stopping some functions of the thread. Otherwise, the entire thread will not be controlled to stop performing business operations or stopping some functions of the thread.

[0139] Start-stop control refers to triggering the target thread to automatically exit or restart based on the QoS level. For example, if the QoS level of a thread is lower than the threshold, the target thread will be automatically exited; otherwise, the target thread will be restarted.

[0140] Delayed avoidance control refers to the strategy of staggering the startup of target threads or controlling the operation of target threads after startup based on their QoS levels for threads with dynamic characteristics. For example, threads with high QoS levels may be started first, while threads with low QoS levels may be delayed. Another example is that after multiple threads are started, threads with high QoS levels can start working normally first, while threads with low QoS levels may work with a delay.

[0141] For example, such as Figure 14 As shown in Figure A, in a video call scenario within a chat application, the electronic device can control the media decoding thread to reduce the frame rate (corresponding to frequency adjustment), for example, reducing the frame rate by 20%. It can also control the video post-processing thread's image enhancement function to be bypassed (corresponding to bypass control), thus stopping the image enhancement function from running.

[0142] like Figure 14As shown in Figure B, when a user is watching a video, if the air gesture recognition thread detects that the user is not using the air gesture recognition feature while watching the video, it can control the air gesture recognition thread to reduce its operating frequency (corresponding to the operating frequency adjustment in service level control), for example, reducing the operating frequency to 20% of the original. Additionally, the user will not use the always-on (AO) feature. The AO feature is used to control the image sensor to continuously acquire and recognize images; therefore, the frequency at which the AO thread outputs images can be reduced (corresponding to the operating frequency adjustment in service level control).

[0143] like Figure 14 As shown in Figure C, in full-screen video call scenarios within chat software, since users rarely perform knuckle operations, the knuckle recognition thread can be controlled to run in a lightweight mode (corresponding to full-lightweight mode control). For example, knuckle recognition can be performed solely based on the touchscreen's capacitance value, instead of relying on acceleration data and the touchscreen's capacitance value in full-scale mode. Alternatively, the knuckle recognition thread can be scheduled to run on a microkernel (corresponding to scheduling control) to reduce power consumption.

[0144] like Figure 14 As shown in D, electronic devices do not pose a risk of operating large amounts of memory during full-screen video calls in chat software. Therefore, the CameraProvider process can be controlled to stop the memory monitoring thread (corresponding to start / stop control) to stop monitoring memory.

[0145] The thread control method and electronic device provided in this application obtain the QoS level of the target thread to be controlled based on the electronic device's scenario information (usage scenario) and state information (running state), as well as thread control strategies for different types of characteristics. Then, the target thread is controlled according to the QoS level. Since the QoS level represents the priority of the target thread, the determination of the QoS level is based not only on different types of characteristics but also on the electronic device's scenario information and state information, thus ensuring that the characteristics of the electronic device's operation match the thread's priority.

[0146] like Figure 15 As shown, this application embodiment also provides a chip system. The chip system 150 includes at least one processor 1501 and at least one interface circuit 1502. The at least one processor 1501 and at least one interface circuit 1502 are interconnected via lines. The processor 1501 is used to support electronic devices in implementing the various steps in the above method embodiments, for example... Figure 12 , Figure 13The method shown allows at least one interface circuit 1502 to be used to receive signals from other devices (e.g., memory) or to send signals to other devices (e.g., a communication interface). The chip system may include a chip and may also include other discrete components.

[0147] This application also provides a computer-readable storage medium including instructions that, when executed on the electronic device, cause the electronic device to perform the steps described in the method embodiments, such as executing... Figure 12 , Figure 13 The method shown.

[0148] This application also provides a computer program product including instructions, which, when executed on the aforementioned electronic device, cause the electronic device to perform the various steps in the method embodiments described above, such as executing... Figure 12 , Figure 13 The method shown.

[0149] The technical effects of the chip system, computer-readable storage medium, and computer program product are described in the preceding method embodiments.

[0150] It should be understood that in the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0151] Those skilled in the art will recognize that the modules and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0152] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and modules described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0153] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or modules may be electrical, mechanical, or other forms.

[0154] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; that is, they may be located on one device or distributed across multiple devices. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0155] In addition, the functional modules in the various embodiments of this application can be integrated into one device, or each module can exist physically separately, or two or more modules can be integrated into one device.

[0156] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented using software programs, implementation can be, in whole or in part, in the form of a computer program product. This computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device containing one or more servers, data centers, etc., that can be integrated with the medium. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state disks, SSDs), etc.

[0157] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A thread control method, characterized in that, include: Acquire scene information and status information of an electronic device, wherein the scene information is used to describe the usage scenario of the electronic device, and the status information is used to describe the operating status of the electronic device; For the first target thread, based on the scene information, the state information, and the thread control strategy for the persistent characteristic, a data pair corresponding to the first target thread is obtained. The data pair corresponding to the first target thread includes a first QoS level and a first hook function. The first target thread is the thread with the persistent characteristic. The first hook function is called to control the first target thread according to the first QoS level. For the second target thread, based on the state information, the call frequency of the activated dynamic feature, and the thread control strategy of the dynamic feature, the data pair corresponding to the second target thread is obtained. The data pair corresponding to the second target thread includes the second QoS level and the second hook function. The second target thread is the thread of the dynamic feature. The dynamic feature refers to the system's native, non-critical, dynamically activated feature. The second hook function is invoked to control the second target thread according to the second QoS level; For the third target thread, based on the scene information, the state information, and the thread control strategy of the third-party feature, a data pair corresponding to the third target thread is obtained. The data pair corresponding to the third target thread includes the third QoS level and the thread identifier TID. The third target thread is the thread of the third-party feature. The system scheduling thread is invoked to control the third target thread corresponding to the TID according to the third QoS level.

2. The method according to claim 1, characterized in that, When the first hook function corresponds to multiple different QoS levels, the first QoS level is the lowest QoS level.

3. The method according to claim 1, characterized in that, When the second hook function corresponds to multiple different QoS levels, the second QoS level is the lowest QoS level.

4. The method according to claim 1, characterized in that, When the TID corresponds to multiple different QoS levels, the third QoS level is the lowest QoS level.

5. The method according to claim 1 or 2, characterized in that, Also includes: Compare the data pairs corresponding to the target thread obtained in this round of search with the data pairs that have already taken effect in the previous round of search, and find the same data pairs; Subtract the identical data pairs from the data pairs corresponding to the target threads found in this round to obtain the data pairs corresponding to the target threads that are effective in this round.

6. The method according to claim 5, characterized in that, Also includes: Subtract the identical data pairs from the data pairs that have already taken effect in the previous round of search to obtain the data pairs corresponding to the target thread to be rolled back; The rollback of the target thread is controlled based on the QoS level in the data pair corresponding to the target thread to be rolled back.

7. An electronic device, characterized in that, It includes a processor and a memory, wherein instructions are stored in the memory, and when the processor executes the instructions, the method as described in any one of claims 1-6 is performed.

8. A computer-readable storage medium, characterized in that, Includes instructions that, when executed on an electronic device, cause the electronic device to perform the method as described in any one of claims 1-6.

Images