Scene management method and system for fine regulation and control of resources and electronic equipment

Abstract

The embodiment of the invention discloses a scene management method and system for fine regulation and control of resources and electronic equipment, and the method comprises the steps: obtaining a hardware state of target equipment, triggering a hardware event in a kernel layer based on the hardware state, generating a scene management request based on the hardware event, responding to the scene management request, and determining a scene calling end based on the scene management request. The scene management request carries a scene label, the scene calling end comprises a native calling end and an expansion calling end, the scene management request is analyzed, and the scene manager is called to determine a target scene and scene configuration information of the target scene based on the scene label carried by the scene management request; the resource manager is called to obtain the target configuration content corresponding to the target scene based on the scene configuration information, and the target configuration content is sent to the kernel layer through the scene calling end, so that the kernel layer performs scene management according to the target configuration content, and the accuracy and flexibility of scene management can be improved.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to a method, system, and electronic device for fine-grained resource management in a scenario. Background Technology

[0002] In platform applications, scenario management is a core task to ensure efficient system operation, bearing the important mission of dynamically adjusting system performance. In existing technologies, scenario management largely relies on the native call client built into the Android system architecture and uses predefined patterns for resource control. However, the logic of these predefined patterns is relatively rigid, lacks scalability, and is difficult to adapt to the management needs of complex scenarios. Furthermore, any modification to the predefined patterns may violate the native compliance of the Android system, thereby affecting GMS tablet certification and limiting the overall flexibility of scenario management. Summary of the Invention

[0003] The following is an overview of the subject matter described in detail in this disclosure. This overview is not intended to limit the scope of the claims.

[0004] This disclosure provides a scenario management method for fine-grained resource control, which can improve the accuracy and flexibility of scenario management.

[0005] On the one hand, embodiments of this disclosure provide a scenario management method for fine-grained resource control, including: Obtain the hardware status of the target device, trigger a hardware event in the kernel layer based on the hardware status, and generate a scene management request based on the hardware event; In response to the scene management request, the scene calling end is determined based on the scene management request, wherein the scene management request carries a scene tag, and the scene calling end includes a native calling end and an extended calling end; The scene management request is parsed, and the scene manager is invoked to determine the target scene and the scene configuration information of the target scene based on the scene tag carried in the scene management request. The resource manager is invoked to obtain the target configuration content corresponding to the target scene based on the scene configuration information. The scenario caller sends the target configuration content to the kernel layer, enabling the kernel layer to manage the scenario based on the target configuration content.

[0006] On the other hand, this disclosure also provides a scenario management system for fine-grained resource control, including: The request generation module is used to obtain the hardware status of the target device, trigger hardware events in the kernel layer based on the hardware status, and generate scene management requests based on the hardware events. The calling end determination module is used to respond to scene management requests and determine the scene calling end based on the scene management requests, wherein the scene management requests carry scene tags; The content acquisition module is used to parse the scene management request, call the scene manager to determine the target scene and the scene configuration information of the target scene based on the scene tags carried in the scene management request, and call the resource manager to obtain the target configuration content corresponding to the target scene based on the scene configuration information. The scenario management module is used to call the scenario caller to send the target configuration content to the kernel layer, so that the kernel layer can perform scenario management according to the target configuration content. The scenario caller includes a native caller, an extended caller, and a kernel caller.

[0007] The embodiments disclosed herein include at least the following beneficial effects: By acquiring the hardware status of the target device, a hardware event is triggered in the kernel layer, and a scene management request is generated based on the hardware event. The scene management can be called through the kernel layer, and the scene management request can be responded to. The scene calling end is determined based on the scene management request. The scene calling end includes a native calling end and an extended calling end, which can support multiple scene calls. At the same time, since the scene management request carries a scene tag, when parsing the scene management request, the scene manager is called to determine the target scene and the scene configuration information of the target scene based on the scene tag carried in the scene management request. The resource manager is called to obtain the target configuration content corresponding to the target scene based on the scene configuration information, which can realize fine-grained control from scene to resource. On this basis, the target configuration content is sent to the kernel layer through the scene calling end, so that the kernel layer can perform scene management according to the target configuration content, which can improve the accuracy and flexibility of scene management.

[0008] Other features and advantages of this disclosure will be set forth in the following description and will be apparent in part from the description or may be learned by practicing this disclosure. Attached Figure Description

[0009] The accompanying drawings are provided to further understand the technical solutions of this disclosure and constitute a part of the specification. They are used together with the embodiments of this disclosure to explain the technical solutions of this disclosure and do not constitute a limitation on the technical solutions of this disclosure.

[0010] Figure 1 A schematic diagram illustrating an optional implementation environment provided for an embodiment of this disclosure; Figure 2 An optional flowchart for a scenario management method for fine-grained resource control provided in this disclosure embodiment; Figure 3 This is a schematic diagram of an optional structure of the scenario-resource management framework provided in the embodiments of this disclosure; Figure 4 A schematic diagram of an optional information structure for scenario configuration information provided in this embodiment of the disclosure; Figure 5 A schematic diagram of an optional information structure for resource configuration information provided in this embodiment of the disclosure; Figure 6 This is a schematic diagram of the information structure of resource configuration information under multiple coexisting scenarios provided in the embodiments of this disclosure; Figure 7 A schematic diagram of an optional overall framework for a scenario management method for fine-grained resource control provided in this disclosure embodiment; Figure 8 A schematic diagram of the structure of a scenario management system for fine-grained resource control provided in an embodiment of this disclosure. Detailed Implementation

[0011] To make the objectives, technical solutions, and advantages of this disclosure clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and are not intended to limit the scope of this disclosure.

[0012] It should be noted that in the various specific embodiments of this disclosure, when processing is required based on data related to the characteristics of the target object, such as target object attribute information or a set of attribute information, the permission or consent of the target object will be obtained first. Furthermore, the collection, use, and processing of this data will comply with relevant laws, regulations, and standards. The target object can be a user. In addition, when embodiments of this disclosure require obtaining target object attribute information, separate permission or consent from the target object will be obtained through pop-ups or redirection to a confirmation page. Only after obtaining the target object's separate permission or consent will the necessary target object-related data for the normal operation of the embodiments of this disclosure be obtained.

[0013] In this disclosure, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0014] To facilitate understanding of the technical solutions provided in the embodiments of this disclosure, some key terms used in the embodiments of this disclosure will be explained below: The Android system framework is a layered software architecture designed from the bottom up. Its core components include the application layer, framework layer, hardware abstraction layer (HAL), and kernel layer. The overall architecture decouples and shields hardware differences through layering, forming a complete interaction chain of "application → framework → HAL → kernel → hardware".

[0015] Hardware events: Signals / notifications generated by the hardware itself or kernel drivers when the state of a hardware device changes. These events serve as carriers for transmitting state information between the kernel layer and user space.

[0016] In platform applications, scenario management is a core task ensuring efficient system operation, bearing the important mission of dynamically adjusting system performance. It intelligently matches performance output and power consumption control strategies by sensing scenario information such as application needs, application load, and user operations to balance high performance and low power consumption. In existing technologies, scenario management largely relies on the native call client built into the Android system architecture and uses predefined modes for resource regulation. However, the logic of predefined modes is relatively rigid, and the hardware configuration parameters corresponding to each mode are statically set, making it difficult to flexibly expand according to actual needs or personalized scenarios, and thus difficult to adapt to the management requirements of complex scenarios. On the other hand, predefined modes are deeply bound to the native compliance framework of the Android system. Any modification to the predefined modes may violate the native interface specifications and permission control mechanisms of the Android system, thereby affecting the certification of Android GMS tablets and limiting the overall flexibility of scenario management.

[0017] Based on this, the present disclosure provides a scenario management method for fine-grained resource control, which can improve the accuracy and flexibility of scenario management.

[0018] Reference Figure 1 , Figure 1 This diagram illustrates an optional implementation environment provided by an embodiment of the present disclosure. The implementation environment includes a terminal 101. Specifically, the terminal 101 is a target device. The hardware status of the terminal 101 is obtained, and a hardware event is triggered in the kernel layer based on the hardware status. A scene management request is generated based on the hardware event, and the scene management request is responded to. A scene calling terminal is determined based on the scene management request. The scene management request carries a scene tag. The scene management request is parsed, and the scene manager is invoked to determine the target scene and its scene configuration information based on the scene tag carried in the scene management request. The resource manager is invoked to obtain the target configuration content corresponding to the target scene based on the scene configuration information. The scene calling terminal is invoked to send the target configuration content to the kernel layer, enabling the kernel layer to perform scene management based on the target configuration content, thereby achieving hardware control of the terminal 101.

[0019] Reference Figure 2 , Figure 2This is an optional flowchart of a scenario management method for fine-grained resource control provided in an embodiment of the present disclosure. This scenario management method for fine-grained resource control can be applied to an Android system and includes, but is not limited to, the following steps S201 to S204.

[0020] Step S201: Obtain the hardware status of the target device, trigger a hardware event in the kernel layer based on the hardware status, and generate a scene management request based on the hardware event.

[0021] The target device refers to a device that applies the scene management method for fine-grained resource control provided in this embodiment. The hardware state refers to the operating status, parameters, and attributes of each hardware component in the target device, specifically including CPU frequency, CPU load, GPU frequency, GPU load, memory usage, and free memory. Hardware events serve as hardware state change signals and are used to push the hardware state to the kernel layer.

[0022] In one possible implementation, this embodiment of the disclosure calls scene management through the kernel layer. Specifically, during the process of acquiring the hardware state of the target device, triggering hardware events in the kernel layer based on the hardware state, and generating a scene management request based on the hardware events, the hardware state of the target device can be acquired. When the hardware state of the target device changes, a hardware event is triggered in the kernel layer. The hardware event triggered in the kernel layer is parsed to obtain the hardware data of the target device, and preset scene triggering conditions are obtained. When the hardware data meets the scene triggering conditions, a scene management request is generated. The scene triggering conditions are used to determine whether the change in hardware state meets the scene management conditions. For example, the scene triggering condition for scene A is that the battery level is below 20%. When the battery level of the target device drops from 20% to 19%, the scene triggering condition is met, and the execution of scene A is triggered.

[0023] Specifically, the Android system framework includes processing layers such as the kernel layer, framework layer, and hardware abstraction layer. The kernel layer runs in memory space, while the framework layer, hardware abstraction layer, and other processing layers run in user space. When the hardware state of the target device changes, a hardware event is triggered in the kernel layer and sent to the user space, which has a hardware event listener. The user space parses the hardware event to obtain the target device's hardware data. Preset scene trigger conditions are then obtained. When the hardware data meets the scene trigger conditions, a scene management request is generated based on the scene corresponding to those conditions. By triggering hardware events to enable the kernel layer to call scene management, the real-time nature of hardware state changes allows scene management to proactively respond and accurately trigger scenes based on real-time hardware states, thereby improving the accuracy of scene management.

[0024] It is understandable that this implementation describes generating scene management requests based on kernel-level hardware events, i.e., calling scene management through the kernel layer. In addition, scene management requests can also be generated through user interaction. Therefore, combining the method of generating scene management requests based on hardware events with the method of generating scene management requests through user interaction enables multi-channel scene control, thereby improving the flexibility of scene management.

[0025] Understandably, hardware event listeners can be set up in the hardware abstraction layer or the framework layer. The hardware event listener continuously receives hardware events sent by the kernel layer through at least one listening thread.

[0026] Step S202: Respond to the scene management request and determine the scene caller based on the scene management request.

[0027] The scene management request carries scene tags and scene-level requirements. Scene tags are used to distinguish different scenes; they can be words that summarize or represent the meaning of the scene, specifically scene types. Scene-level requirements clarify the overall direction of scene resource allocation; for example, scene-level requirements could be high performance or low power consumption. The scene caller is used to obtain configuration information and call the kernel layer for scene management. This includes native callers and extended callers. The native caller is the caller built into the Android system framework, while the extended caller is a call component added within the compatibility range of the Android system framework to adapt to custom scenes. The scene caller is set in the hardware abstraction layer.

[0028] In one possible implementation, before responding to a scene management request and determining the scene caller based on the request, the configuration information corresponding to the scene to be added needs to be stored. Specifically, this can involve creating a scene configuration file and a resource configuration file, obtaining the scene to be added, determining the scene configuration information corresponding to the scene to be added, and determining the resource configuration information corresponding to each scene configuration item in the scene configuration information. Based on the scene configuration information, the scene configuration text for the scene to be added is determined; based on the resource configuration information, the resource configuration text for the scene to be added is determined; and the scene configuration text is stored in the scene configuration file, and the resource configuration text is stored in the resource configuration file. The scene configuration file records scene configuration information, and the resource configuration file records resource configuration information. Both the scene configuration text and the resource configuration text are structured texts, specifically, they can be in XML format.

[0029] Specifically, scene configuration files and resource configuration files are created in the read-only partition of the target device. The storage path for the scene configuration file can be `vendor / etc / scene_config.xml`, and the storage path for the resource configuration file can be `vendor / etc / resource.xml`. The scene configuration information corresponding to the scene to be added and the resource configuration information corresponding to each scene configuration item in the scene configuration information are determined. The scene configuration information and resource configuration information can be in code format or other text formats such as JSON. The scene configuration information is converted to XML format to obtain scene configuration text, and the resource configuration information is converted to XML format to obtain resource configuration text. The scene configuration text is then stored in the scene configuration file, and the resource configuration text is stored in the resource configuration file, thus enabling the custom addition of scenes and resources. By storing the configuration information of the scene to be added in the scene configuration file or resource configuration file, scenes and resources can be quickly added without modifying the source code, effectively improving the flexibility of scene management.

[0030] It is understandable that multiple target scenarios can be configured with the same resource (resource management policy), meaning there is a many-to-one relationship between target scenarios and resources. For example, both target scenario A and target scenario B can be configured with resource management policy A. Therefore, when storing the resource configuration text in the resource configuration file, the resource management policy corresponding to each resource configuration item and the policy configuration value corresponding to the resource management policy are extracted from the resource configuration information. Based on the resource management policy and policy configuration value, a search is performed in the resource configuration text. If the resource management policy exists in the resource management file and the resource configuration information corresponding to the resource management policy includes the execution mode corresponding to the policy configuration value, then the resource configuration information corresponding to the resource management policy is not converted into resource configuration text. If the resource management policy does not exist in the resource management file, then the resource configuration information corresponding to the resource management policy is converted into resource configuration text and stored in the resource configuration file. If the resource management policy exists in the resource management file but the resource configuration information corresponding to the resource management policy does not include the execution mode corresponding to the policy configuration value, then the resource configuration information corresponding to the execution mode is converted into resource configuration text and stored in the resource configuration file. By querying resource management strategies and execution modes, we can avoid memory consumption caused by repeatedly storing the same resource configuration text, and also avoid time consumption caused by repeatedly parsing the same resource configuration text, thereby improving the accuracy and efficiency of subsequent resource control.

[0031] In one possible implementation, the scene configuration text includes a caller field. The scene caller includes a native caller and an extended caller. Specifically, in determining the scene caller based on the scene management request, the scene configuration text corresponding to the target scene can be obtained based on the scene tag carried in the scene management request. The caller field is then extracted from the scene configuration text, and the scene caller is determined based on the caller field. The caller field uniquely identifies the data field that can initiate the target scene management call.

[0032] Specifically, when adding a new scenario, the scenario caller that can support the scenario to be added is identified and written into the scenario configuration file as a caller field. When a scenario management request is received, the scenario configuration file is queried based on the scenario tag carried in the scenario management request to obtain the scenario configuration text corresponding to the target scenario. The caller field is extracted from the scenario configuration text, and the scenario caller is determined based on the caller field. By writing the scenario caller into the scenario configuration file, the scenario caller corresponding to the target scenario can be accurately matched through the caller field, avoiding confusion of call sources and illegal requests, which helps improve the accuracy of scenario management. In addition, when replacing or adding a caller in the future, only the configuration file needs to be updated without modifying the source code, effectively reducing subsequent maintenance costs.

[0033] In one possible implementation, during the process of determining the scene caller based on the scene management request, the following steps can be taken: First, obtain a list of scenes supported by the scene caller. Then, register the scenes in the scene list, generate a scene management registry, and query the scene management registry based on the scene tags carried in the scene management request. Finally, determine the corresponding scene caller according to the mapping relationship. The scene management registry contains the mapping relationship between the scene tags of the scenes in the scene list and the scene callers.

[0034] Specifically, the process involves obtaining a list of scenarios supported by the scenario caller. Since scenario callers include native callers and extended callers, if both types of callers support the same scenario, that scenario is categorized into the list of scenarios supported by the native caller. Next, scenarios from the scenario list are registered in the user space. Specifically, this can be done in the hardware abstraction layer of the user space. A scenario management registry is generated based on the mapping relationship between scenario tags and scenario callers. The scenario management registry is queried based on the scenario tags carried in the scenario management request, and the corresponding scenario caller is determined according to the mapping relationship. By uniformly registering the scenarios supported by the callers, centralized control of caller permissions can be achieved, effectively avoiding problems such as scattered caller permissions and chaotic rules in different scenarios. Especially in complex control scenarios involving hardware resources such as CPU, GPU, and DDR, the high scalability of the registry can fully adapt to the complex control requirements of multi-hardware collaboration and multi-scenario linkage. Global management of scenarios can further improve the reliability and efficiency of scenario management.

[0035] Step S203: Parse the scene management request, call the scene manager to determine the target scene and the scene configuration information of the target scene based on the scene tag carried in the scene management request, and call the resource manager to obtain the target configuration content corresponding to the target scene based on the scene configuration information.

[0036] The Scene Manager manages all scenes and controls scene entry and exit. The Resource Manager controls all resource management strategies, and the Scene Manager interfaces with the Resource Manager. The target scene is the scene that needs to be managed; there can be one or more target scenes. Scene configuration information records scene configuration details. The target configuration content is the resource configuration information required for scene management requests. For example, the resource configuration information includes resource configuration item A{pattern: A} and resource configuration item B{pattern: B}. The target configuration content obtained by matching the scene configuration information {resource management strategy: strategy 1, strategy configuration value: A} is resource configuration item A.

[0037] Specifically, the scene management request is parsed at the hardware abstraction layer. This involves retrieving the corresponding scene configuration information and resource configuration information from the scene configuration file and resource configuration file based on the scene tag and scene-level requirements carried in the scene management request. (Refer to...) Figure 3 , Figure 3 This is an optional structural diagram of the scenario-resource management framework provided in an embodiment of the present disclosure. The scenario manager manages scenario 1, scenario 2, scenario 3, scenario 4 and scenario 5. Correspondingly, the resource manager manages resources A, resource B, resource C, resource D and resource E corresponding to the above scenarios.

[0038] In one possible implementation, during the process of calling the scene manager to determine the target scene based on the scene tag carried in the scene management request, determining the scene configuration information of the target scene based on the scene switching information, and calling the resource manager to obtain the target configuration content corresponding to the target scene based on the scene configuration information, specifically, the scene manager can be called to determine the target scene and the scene configuration information of the target scene based on the scene tag carried in the scene management request. The scene configuration information includes at least one scene configuration item, and the scene configuration item includes a resource management policy and the policy configuration value corresponding to the resource management policy. The resource manager is then called to determine the target configuration content corresponding to at least one scene configuration item based on the resource management policy and the policy configuration value corresponding to the resource management policy. The resource management policies include CPU frequency modulation policies, DFS frequency modulation policies, IO scheduling policies, temperature control policies, NSI resource limitation policies, etc. IO scheduling policies can be implemented through an IO scheduler (input / output scheduler), and NSI resource limitation policies can achieve upper limit control or lower limit protection by setting thresholds. This embodiment does not specifically limit the type and number of policies. Resource configuration values ​​are specific states, rules, or values ​​set for specific resource management policies. For example, the policy configuration value for a CPU frequency adjustment policy could be "schedutil", where schedutil represents a specific frequency adjustment rule; the policy configuration value for an NSI resource limitation policy could be a preset threshold, which is a specific value.

[0039] Specifically, scene configuration information is stored in text format within a scene configuration file. The scene manager is invoked to determine the target scene based on the scene tags carried in the scene management request, and then queries the scene configuration file based on those tags to obtain the scene configuration information for the target scene. The scene configuration information includes at least one scene configuration item, which includes a resource management policy and its configuration value, as shown below. Figure 4 , Figure 4 This is a schematic diagram of an optional information structure for scene configuration information provided in an embodiment of this disclosure. The scene tags are interactive, i.e. Figure 4The scenario configuration information for interactive scenarios is displayed, including five scenario configuration items. These include: CPU frequency adjustment policy (cpu_governor) with a policy configuration value of schedutil; DFS frequency adjustment policy (dfs_governor) with a policy configuration value of simple_ondemand; IO scheduling policy (io_schedule) with a policy configuration value of mq_deadline_low_latency; temperature control policy (thermal_control) with a policy configuration value of enabled; and NSI resource limitation policy (nsi_limit) with a policy configuration value of limit. Next, the resource manager is invoked to determine the target configuration content for at least one scenario configuration item based on the resource management policy and its corresponding policy configuration value.

[0040] In one possible implementation, the resource manager is invoked to determine the target configuration content corresponding to at least one scenario configuration item based on the resource management policy and its corresponding policy configuration value. Specifically, the resource manager is invoked to determine the resource configuration information corresponding to the scenario configuration item based on the resource management policy. The resource configuration information includes at least one resource configuration item, and each resource configuration item includes the execution mode of the resource management policy. The execution mode of the resource management policy is determined based on its corresponding policy configuration value. A mode configuration path and its corresponding mode configuration value are set for the execution mode. The target configuration content corresponding to at least one scenario configuration item is then determined based on the mode configuration path and its corresponding mode configuration value. Here, the execution mode is the specific implementation method of executing the resource management policy. For example, if the policy configuration value for a CPU frequency modulation policy is "schedutil", it indicates that the current CPU frequency modulation policy's execution mode is to obtain load information for real-time adjustment; if the corresponding policy configuration value is "performance", it indicates that the current CPU frequency modulation policy's execution mode is to always maintain the highest frequency. The mode configuration path indicates the specific location where the configuration information of the execution mode is stored. Specifically, the mode configuration path can be the storage address of the resource configuration file, and the mode configuration value is the parameter actually stored in the resource configuration file, used to define the specific behavior or attributes of the execution mode.

[0041] Specifically, resource configuration information is stored in text format within a resource configuration file. The resource manager queries the resource configuration file based on the resource management policy to obtain the resource configuration information corresponding to that policy. The resource configuration information includes at least one resource configuration item, as shown below. Figure 5 , Figure 5 This is a schematic diagram of an optional information structure for resource configuration information provided in an embodiment of this disclosure. Figure 5This section displays resource configuration information for a CPU frequency scaling strategy, including two resource configuration items. One item has an execution mode of "performance," and the other has an execution mode of "schedutil." This resource management strategy operates on resources via sysfs, indicating that resources are manipulated through kernel file nodes. The default configuration is schedutil. When there are no scenario requests for this resource management strategy (i.e., the scenario management information for the target scenario does not contain any scenario configuration items related to this resource management strategy), the CPU frequency scaling strategy defaults to executing the schedutil mode. For the performance execution mode, the configuration priority, mode configuration path, and mode configuration value are set. When performance execution mode is enabled, the mode configuration value is written to the resource configuration file corresponding to the mode configuration path. For example, when performance execution mode is enabled, the mode configuration value "performance" is written to the mode configuration paths " / sys / cpu / cpufrep / policy0 / governor", " / sys / cpu / cpufrep / policy4 / governor", and " / sys / cpu / cpufrep / policy6 / governor". For the execution mode `schedutil`, in addition to writing the mode configuration value `schedutil` to the three mode configuration paths mentioned above, the mode configuration value `20000` also needs to be written to the mode configuration path ` / sys / cpu / cpufrep / schedutil / rate_limit`. Furthermore, the resource configuration information also has a read mode. The read mode is not affected by configuration priority and executes after any execution mode is started. The read mode supports reading the current configuration information of `cpub_governor` through the mode configuration path ` / sys / cpu / cpufrep / policy6 / governor`. The execution mode is determined based on the policy configuration value in the scenario configuration item. The target configuration content corresponding to the scenario configuration item is determined based on the mode configuration path and the corresponding mode configuration value in the execution mode, as well as the mode configuration path and read policy in the read mode. By subdividing the resource configuration information into multiple modes, all scenario resources can be finely controlled. Parameters such as the type of execution mode, mode configuration path, mode configuration value, resource operation method, and default configuration can be customized, effectively improving the flexibility of scenario management. In addition, the read mode setting can monitor the current configuration status of the target device in real time, providing a basis for decision-making on configuration modifications. This can avoid resource waste or resource occupation caused by configuration loss of control or repeated modifications. At the same time, it can also verify the configuration modification results to ensure that the configuration modifications take effect, effectively improving the accuracy and reliability of scenario management.

[0042] In one possible implementation, there are multiple target scenarios, and the resource configuration items also include the configuration priority of the execution mode. When at least two target scenarios request to configure the same resource management strategy, the configuration priority of the execution mode in the target configuration content corresponding to at least two target scenarios is obtained, and the current execution mode is determined based on the configuration priority. The configuration priority is used to rank the execution modes by importance.

[0043] Specifically, when at least two target scenarios request the configuration of the same resource management policy, the resource management file is searched based on the resource management policy corresponding to each target scenario and its configuration value. This search determines the configuration priority of the execution mode for each of the at least two target scenarios within the target configuration content corresponding to that resource management policy. Taking two target scenarios as an example, if the execution modes for the two target scenarios are different, the current execution mode is determined based on the configuration priority. Using configuration priority to determine the execution mode of the resource management policy avoids resource conflicts, optimizes resource utilization, and thus improves the efficiency and reliability of scenario management.

[0044] Reference Figure 6 , Figure 6 This is a schematic diagram of the information structure of resource configuration information under multi-scenario coexistence provided in this embodiment of the disclosure. The currently executed resource management strategy is the DFS frequency modulation strategy. The resource identifier of the DFS frequency modulation strategy is 0×2, the resource operation method is sysfs, and the default configuration is simple_ondemand. In addition to the resource configuration information corresponding to the DFS frequency modulation strategy, it also includes the currently used configuration information and the currently requested configuration information. The scenario identifier of the target scenario currently using the DFS frequency modulation strategy is 0×0005, and its execution mode is performance. The target scenarios currently requesting to use the DFS frequency modulation strategy are 0×007 and 0×005. The execution mode set for target scenario 0×007 is simple_ondemand, and the execution mode set for target scenario 0×005 is performance. The smaller the number, the higher the configuration priority. According to the configuration priority of each execution mode in the resource configuration information of the DFS frequency modulation strategy, performance has a higher priority. Therefore, the execution mode of the current DFS frequency modulation strategy is performance.

[0045] Step S204: The scenario caller sends the target configuration content to the kernel layer, so that the kernel layer can manage the scenario according to the target configuration content.

[0046] Specifically, the kernel layer's scene management involves adjusting the hardware parameters of the target device. These parameters can include CPU, GPU, and DDR (memory) parameters. The scene caller includes a native caller and an extended caller. The native caller can be PowerHal, which includes multiple call functions, such as `setPowerMode` and `setBoost`. `setPowerMode` sets the power mode, and `setBoost` triggers performance acceleration for scenes supported by PowerHal. The extended caller can be ExtensionPower, also including multiple call functions, such as `setExtensionBoost`, which triggers performance acceleration for scenes supported by ExtensionPower. The framework or application layer sends scene-level requirements to the scene caller for parsing and combines them with scene tags to obtain the target configuration. Finally, the scene caller sends the target configuration to the kernel layer, which performs hardware adjustments based on the target configuration, ultimately achieving scene management.

[0047] Reference Figure 7 , Figure 7 This is a schematic diagram of an optional overall framework for a scenario management method for fine-grained resource control provided in this disclosure. The scenario management method for fine-grained resource control provided in this disclosure can be applied to scenarios such as resource management and resource control. The principle of the scenario management method for fine-grained resource control in this disclosure is described in its entirety below: Figure 7 The demonstrated scene management methods include two invocation methods: one is to invoke scene management through the kernel layer, as detailed below: First, obtain the scene to be added, convert the scene configuration information and resource configuration information of the scene to be added into XML format to obtain scene configuration text and resource configuration text, store the scene configuration text in the scene configuration file, and store the resource configuration text in the resource configuration file to realize the custom addition of scenes and resources, and store the scene configuration file and resource configuration file in the read-only partition of the target device.

[0048] Next, the list of scenarios supported by the scenario caller is obtained. If two callers support the same scenario, the scenario is categorized into the list of scenarios supported by the native caller. Scenarios from the scenario list are registered in the hardware abstraction layer in user space, and a scenario management registry is generated based on the mapping relationship between scenario tags and scenario callers.

[0049] Next, the hardware status of the target device, such as its Wi-Fi performance, is acquired. When the target device's hardware status changes, a hardware event is triggered in the kernel layer and sent to the user space where a hardware listener is configured. The user space hardware listener continuously receives hardware events sent from the kernel layer through a listening thread. The hardware events are parsed in user space to obtain the target device's hardware data. Then, preset scene trigger conditions are acquired. When the hardware data meets the scene trigger conditions, a scene management request is generated based on the scene corresponding to the scene trigger conditions.

[0050] Next, the framework layer responds to the scene management request, triggering the power manager, extended services, or other services. The hardware abstraction layer receives the scene management request from the framework layer by calling functions (such as the `setPowerMode` and `setBoost` functions of the native caller, or the `setExtensionBoost` function of the extended caller). In the hardware abstraction layer, based on the scene tag carried in the scene management request, it queries the scene management registry and determines the corresponding scene caller according to the mapping relationship. Subsequently, the scene management request is parsed. The scene manager finds the corresponding scene configuration text in the scene configuration file based on the scene tag and scene-level requirements carried in the scene management request, and converts the scene configuration text into scene configuration information. The resource manager finds the corresponding resource configuration text in the resource configuration file based on the resource configuration policy of the scene configuration item in the scene configuration information, and converts the resource configuration text into resource configuration information. Then, based on the policy configuration value corresponding to the resource configuration policy, it determines the execution mode and the configuration priority of the execution mode. Based on the mode configuration path and the mode configuration value corresponding to the mode configuration path in the execution mode, and the mode configuration path and reading policy in the reading mode, it determines the target configuration content corresponding to the scene configuration item.

[0051] Finally, the scenario caller sends the target configuration content to the kernel layer. The kernel layer then adjusts hardware parameters such as CPU parameters, GPU parameters, and DDR parameters according to the target configuration content, ultimately achieving scenario management.

[0052] Another approach is to invoke scene management through user interaction behavior, as detailed below: When a user interacts with a scene, a scene management request is generated based on that interaction. The framework layer responds to the scene management request, triggering the power manager, extended services, or other services to perform scene management. The process of adding scenes and resources, registering scenes, and subsequent adjustments is similar to the method described above based on kernel layer calls, and will not be repeated here.

[0053] In summary, the scenario management method for fine-grained resource control provided in this disclosure continuously receives hardware events triggered by the kernel layer by setting a hardware event listener in user space. This allows the Android system to call scenario management at the kernel layer and generate scenario management requests based on user interaction behavior, thereby achieving multi-channel scenario control and improving the flexibility of scenario management. Simultaneously, the construction of a scenario-resource management framework enables hierarchical management of scenarios and resources, allowing for the custom addition of scenarios and resources, achieving fine-grained control from scenario to resource, thus improving the accuracy of scenario management. Furthermore, the scenario management method for fine-grained resource control provided in this disclosure allows for the custom addition of scenarios and resources without modifying the source code, further enhancing the flexibility of scenario management. Moreover, the method of setting configuration priorities enables priority conflict management of resources, avoiding resource conflicts and further improving the accuracy of scenario management.

[0054] Reference Figure 8 , Figure 8 This is a schematic diagram of the structure of a scenario management system for fine-grained resource control provided in an embodiment of this disclosure. The scenario management system 800 for fine-grained resource control includes: The request generation module 801 is used to obtain the hardware status of the target device, trigger hardware events in the kernel layer based on the hardware status, and generate scene management requests based on the hardware events. The caller determination module 802 is used to respond to scene management requests and determine the scene caller based on the scene management requests, wherein the scene management requests carry scene tags; The content acquisition module 803 is used to parse the scene management request, call the scene manager to determine the target scene and the scene configuration information of the target scene based on the scene tag carried in the scene management request, and call the resource manager to obtain the target configuration content corresponding to the target scene based on the scene configuration information. The scenario management module 804 is used to call the scenario caller to send the target configuration content to the kernel layer, so that the kernel layer can perform scenario management according to the target configuration content. The scenario caller includes the native caller, the extended caller, and the kernel caller.

[0055] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in this disclosure and the foregoing drawings are used to distinguish similar objects and are not necessarily used to describe a particular order or sequence. It should be understood that such data can be interchanged where appropriate to describe embodiments of this disclosure, for example, those that can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatuses.

[0056] It should be understood that in this disclosure, "at least one item" means one or more, and "more than one" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0057] It should be understood that in the description of the embodiments of this disclosure, "multiple" means two or more, "greater than", "less than", "exceeding" etc. are understood to exclude the number itself, and "above", "below", "within" etc. are understood to include the number itself.

[0058] In the embodiments provided in this disclosure, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, 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 apparatuses or units may be electrical, mechanical, or other forms.

[0059] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0060] Furthermore, the functional units in the various embodiments of this disclosure can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0061] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this disclosure, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this disclosure. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0062] It should also be understood that the various implementation methods provided in this disclosure can be combined arbitrarily to achieve different technical effects.

[0063] The above is a detailed description of the preferred embodiments of this disclosure. However, this disclosure is not limited to the above embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of this disclosure. All such equivalent modifications or substitutions are included within the scope defined by the claims of this disclosure.

Claims

1. A scenario management method for refined resource control, characterized in that, include: Obtain the hardware status of the target device, trigger a hardware event in the kernel layer based on the hardware status, and generate a scene management request based on the hardware event; In response to the scene management request, the scene calling end is determined based on the scene management request, wherein the scene management request carries a scene tag, and the scene calling end includes a native calling end and an extended calling end; The scene management request is parsed, and the scene manager is invoked to determine the target scene and the scene configuration information of the target scene based on the scene tag carried in the scene management request. The resource manager is invoked to obtain the target configuration content corresponding to the target scene based on the scene configuration information. The scenario caller sends the target configuration content to the kernel layer, enabling the kernel layer to manage the scenario based on the target configuration content.

2. The scene management method for refined resource control according to claim 1, wherein calling the scene manager to determine the target scene and the scene configuration information of the target scene based on the scene tag carried in the scene management request, and calling the resource manager to obtain the target configuration content corresponding to the target scene based on the scene configuration information, includes: The scene manager is invoked to determine the target scene and the scene configuration information of the target scene based on the scene tag carried by the scene management request. The scene configuration information includes at least one scene configuration item, and the scene configuration item includes a resource management policy and a policy configuration value corresponding to the resource management policy. The resource manager is invoked to determine the target configuration content corresponding to at least one of the scenario configuration items based on the resource management policy and the policy configuration value corresponding to the resource management policy.

3. The scenario management method for refined resource control according to claim 2, characterized in that, The step of invoking the resource manager to determine the target configuration content corresponding to at least one of the scenario configuration items based on the resource management policy and the policy configuration value corresponding to the resource management policy includes: The resource manager is invoked to determine the resource configuration information corresponding to the scenario configuration item based on the resource management policy. The resource configuration information includes at least one resource configuration item, and the resource configuration item includes the execution mode of the resource management policy. The execution mode of the resource management strategy is determined based on the strategy configuration value corresponding to the resource management strategy. A mode configuration path and a mode configuration value corresponding to the mode configuration path are set for the execution mode. The target configuration content corresponding to at least one scenario configuration item is determined based on the mode configuration path and the mode configuration value corresponding to the mode configuration path.

4. The scenario management method for refined resource control according to claim 3, characterized in that, The target scenarios are multiple, the resource configuration items also include the configuration priority of the execution mode, and the scenario management method for fine-tuning resource control also includes: When at least two target scenarios request the configuration of the same type of resource management strategy, obtain the configuration priority of the execution mode in the target configuration content corresponding to the at least two target scenarios, and determine the execution mode of the current configuration based on the configuration priority.

5. The scenario management method for refined resource control according to claim 1, characterized in that, The process of determining the scene invoking end based on the scene management request includes: Obtain the list of scenarios supported by the scenario caller, register the scenarios in the scenario list with the scenario manager, and generate a scenario management registry. The scenario management registry contains the mapping relationship between the scenario tags of the scenarios in the scenario list and the scenario caller. Based on the scene tag carried in the scene management request, the corresponding scene calling end is determined in the scene management registry.

6. The scenario management method for refined resource control according to claim 1, characterized in that, Before responding to a scenario management request and determining the scenario invoking end based on the scenario management request, the scenario management method for fine-tuning resource control further includes: Create a scene configuration file and a resource configuration file. The scene configuration file is used to record scene configuration information, and the resource configuration file is used to record resource configuration information. Obtain the scene to be added, determine the scene configuration information corresponding to the scene to be added and the resource configuration information corresponding to each scene configuration item in the scene configuration information, determine the scene configuration text of the scene to be added based on the scene configuration information, and determine the resource configuration text of the scene to be added based on the resource configuration information; The scene configuration text is stored in the scene configuration file, and the resource configuration text is stored in the resource configuration file.

7. The scenario management method for refined resource control according to claim 6, characterized in that, The scenario configuration text includes a calling end field, and determining the scenario calling end based on the scenario management request includes: Based on the scene tag carried in the scene management request, obtain the scene configuration text corresponding to the target scene, extract the calling end field from the scene configuration text, and determine the scene calling end based on the calling end field.

8. The scenario management method for refined resource control according to claim 1, characterized in that, The process of obtaining the hardware status of the target device, triggering a hardware event in the kernel layer based on the hardware status, and generating a scene management request based on the hardware event includes: The hardware state of the target device is obtained. When the hardware state of the target device changes, a hardware event is triggered in the kernel layer. The hardware event triggered in the kernel layer is parsed to obtain the hardware data of the target device. Obtain preset scene trigger conditions, and when the hardware data meets the scene trigger conditions, generate the scene management request.

9. A scenario management system for refined resource control, characterized in that, include: The request generation module is used to obtain the hardware status of the target device, trigger hardware events in the kernel layer based on the hardware status, and generate scene management requests based on the hardware events. The calling end determination module is used to respond to scene management requests and determine the scene calling end based on the scene management requests, wherein the scene management requests carry scene tags; The content acquisition module is used to parse the scene management request, call the scene manager to determine the target scene and the scene configuration information of the target scene based on the scene tags carried in the scene management request, and call the resource manager to obtain the target configuration content corresponding to the target scene based on the scene configuration information. The scenario management module is used to call the scenario caller to send the target configuration content to the kernel layer, so that the kernel layer can perform scenario management according to the target configuration content. The scenario caller includes a native caller, an extended caller, and a kernel caller.

10. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the scenario management method for fine-tuning resources as described in any one of claims 1 to 8.

Images