Resource allocation method for middleware, terminal equipment and storage medium

Abstract

The invention is suitable for the technical field of resource management, and provides a middleware resource allocation method, terminal equipment and a storage medium, the method comprises the steps of obtaining a user intention and preloading a matched target task, breaking through a traditional passive mode of starting resource scheduling after task triggering, and improving the resource allocation efficiency. And core resource preparation time is reserved for task execution in advance. The current state of the target middleware is synchronously monitored in the preloading link, key information such as the load condition and the response capability of the middleware can be mastered in the first time, and waiting delay generated due to the fact that the state of the middleware is unknown in the task execution process is avoided. The calling strategy generated based on the state information and the historical user behavior data can directly locate the optimal middleware resource configuration mode matched with the target task, and redundant steps of repeated attempts and resource adjustment in a traditional scheme are omitted.

Description

Technical Field

[0001] This application belongs to the field of resource management technology, and in particular relates to a middleware resource allocation method, terminal device and storage medium. Background Technology

[0002] Middleware is a type of software that sits between application systems and system software. It uses the basic services (functions) provided by the system software to connect various parts of application systems or different applications on the network, achieving resource sharing and function sharing. For the Android system, tasks initiated by users through various applications (APPs) (such as data requests, business processing, resource calls, etc.) rely on middleware at the system layer or application layer for forwarding, scheduling, and processing. As a key hub connecting applications with underlying hardware and the operating system kernel, middleware undertakes core functions such as task routing, protocol conversion, and resource coordination. Its operating efficiency and stability directly determine the user experience and system reliability.

[0003] In the process of processing user tasks and calling middleware, most traditional solutions of existing electronic devices adopt fixed calling logic. That is, a fixed middleware calling strategy is preset for specific types of user tasks. When the target middleware is under high load or in an abnormal state, it is still forcibly called according to the preset logic, which can easily lead to task execution lag, timeout or even failure, seriously affecting the user experience. Summary of the Invention

[0004] This application provides a middleware resource allocation method, terminal device, and storage medium, which can solve the problem of task execution being stuck, timed out, or even failed due to the use of fixed logic in middleware invocation.

[0005] In a first aspect, embodiments of this application provide a middleware resource allocation method, including: Obtain user intent; Preload the target task according to the user intent. During the preloading process, monitor the current state of the target middleware and obtain the state information of the target middleware. The target task is the task that matches the user intent, and the target middleware is the middleware that needs to be called when executing the target task. Based on the status information of the target middleware and historical user behavior data, the invocation strategy of the target middleware is obtained, wherein the historical user behavior data includes the resource allocation of the middleware invoked when the electronic device processes the user's historical tasks; The target middleware is invoked to execute the target task according to the invocation strategy.

[0006] In this application, the proposed solution prioritizes obtaining user intent and preloads matching target tasks, breaking away from the traditional passive mode of resource scheduling that only starts after task triggering. This allows for pre-emptive preparation time for core resources during task execution. Simultaneously monitoring the current status of the target middleware during the preloading phase enables immediate understanding of key information such as middleware load and responsiveness, avoiding delays caused by unknown middleware status during task execution. Furthermore, the invocation strategy generated based on status information and historical user behavior data directly identifies the optimal middleware resource configuration for the target task, eliminating the redundant steps of repeated trials and resource adjustments required in traditional solutions.

[0007] In one possible implementation of the first aspect, the method further includes: To obtain user instructions and the focus state of the electronic device's user interface; Based on the focus state of the user interface, determine the business scenario that the electronic device needs to execute and the priority of the business scenario; The user intent is determined based on the user instruction information and the business scenario; Based on the user intent, the business scenario, and the priority of the business scenario, a resource scheduling label is generated; Accordingly, obtaining the invocation strategy for the target middleware based on its status information and historical user behavior data includes: The invocation strategy for the target middleware is obtained based on the status information of the target middleware, the historical user behavior data, the business scenario, and the priority of the business scenario.

[0008] In one possible implementation of the first aspect, the user instruction information includes user voice information and a remote control operation sequence, wherein the remote control operation sequence is generated by the remote control of the electronic device based on the user's operation; Determining the user intent based on the user instruction information and the business scenario includes: Semantic analysis is performed on the user's voice information to obtain the user's semantic intent; The user's interaction intent is obtained by performing key flow analysis on the remote control operation sequence. The user intent is determined based on the semantic intent, the interaction intent, and the business scenario.

[0009] In one possible implementation of the first aspect, obtaining the invocation strategy for the target middleware based on the target middleware's state information, the historical user behavior data, the business scenario, and the priority of the business scenario includes: The target middleware's status information, the business scenario, and the priority of the business scenario are input into the trained strategy planning model. The target middleware is then regulated by the trained strategy planning model to obtain the target middleware's invocation strategy. The trained strategy planning model is obtained by training the strategy planning model to be trained using the historical user behavior data.

[0010] In one possible implementation of the first aspect, the method further includes: Obtain resource usage data during the execution of user tasks within a historical time period, where user tasks include the target task; Based on the resource usage data, a resource contention dependency graph is constructed among multiple user tasks, wherein the resource contention dependency graph represents user tasks that have resource contention, and the resource information that is competed among the user tasks that have resource contention; Based on the resource contention dependency graph, the Nash equilibrium algorithm is used to reallocate resources for multiple user tasks to obtain the resource reallocation strategy for each user task. The resource reallocation strategy is compared with the corresponding resource usage data to determine the execution effect of the user task; The parameters of the trained policy planning model are adjusted based on the performance of the user task.

[0011] In one possible implementation of the first aspect, the method further includes: Obtain behavioral data of the application calling middleware in the electronic device; Determine whether there is malicious behavior in the behavioral data, wherein the malicious behavior includes behavior that calls the middleware more frequently than a preset threshold, and / or middleware call behavior that does not match the business scenario processed by the application; If malicious behavior is found in the behavioral data, a circuit breaker mechanism for the malicious behavior is generated, wherein the circuit breaker mechanism includes limiting the number of times the application can call the middleware corresponding to the malicious behavior.

[0012] In one possible implementation of the first aspect, the step of preloading the target task according to the user intent, and during the preloading process, monitoring the current state of the target middleware to obtain the state information of the target middleware, includes: Check if the user intent exists in the database, wherein the database stores the mapping relationship between historical user intents and middleware invocation strategies; If no historical user intent matching the user intent exists in the database, the target task is preloaded according to the user intent. During the preloading process, the current state of the target middleware is monitored to obtain the state information of the target middleware, and the step of obtaining the calling strategy of the target middleware based on the state information of the target middleware and historical user behavior data, as well as subsequent steps, are triggered.

[0013] In one possible implementation of the first aspect, after checking whether the user intent exists in the database, the method further includes: If a historical user intent that matches the user intent exists in the database, a target strategy is obtained, wherein the target strategy is the middleware invocation strategy corresponding to the user intent stored in the database; The middleware is invoked according to the target strategy to execute the task corresponding to the user intent.

[0014] Secondly, embodiments of this application provide a terminal device, including: The intent acquisition module is used to acquire user intent. The middleware monitoring module is used to preload a target task according to the user intent. During the preloading process, it monitors the current status of the target middleware and obtains the status information of the target middleware. The target task is a task that matches the user intent, and the target middleware is the middleware that needs to be called when executing the target task. The strategy planning module is used to obtain the calling strategy of the target middleware based on the status information of the target middleware and historical user behavior data, wherein the historical user behavior data includes the resource allocation of the middleware called when the electronic device processes the user's historical tasks. The task execution module is used to invoke the target middleware to execute the target task according to the invocation strategy.

[0015] Thirdly, embodiments of this application provide a terminal device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the resource allocation method of the middleware described in any of the first aspects above.

[0016] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the resource allocation method of the middleware described in any one of the first aspects.

[0017] Fifthly, embodiments of this application provide a computer program product that, when run on a terminal device, causes the terminal device to execute the middleware resource allocation method described in any of the first aspects above. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a flowchart illustrating a resource allocation method for middleware provided in an embodiment of this application; Figure 2 This is a flowchart illustrating a method for generating resource scheduling tags according to an embodiment of this application; Figure 3 This is a flowchart illustrating a method for generating user intent according to an embodiment of this application; Figure 4 This is a flowchart illustrating a method for revising a strategy planning model through reflection, as provided in an embodiment of this application. Figure 5 This is a flowchart illustrating a method for handling malicious behavior according to an embodiment of this application; Figure 6 This is a schematic diagram of the structure of a terminal device provided in an embodiment of this application; Figure 7 This is a schematic diagram of the structure of a terminal device provided in another embodiment of this application. Detailed Implementation

[0020] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0021] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0022] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0023] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0024] With the rapid development of mobile internet and IoT technologies, various business applications are increasingly reliant on basic resources such as location services and API calls, and the diversity and complexity of business scenarios are growing exponentially. Whether it's the high-frequency GPS positioning needs of navigation applications or the low-frequency precise positioning calls of payment services, both pose severe challenges to existing resource scheduling and security protection mechanisms. However, current mainstream technical solutions are gradually revealing numerous shortcomings in addressing these needs, such as poor adaptability, lagging protection, and insufficient coordination, making it difficult to meet the requirements for high-quality business operation.

[0025] At the resource allocation level, traditional solutions generally use fixed threshold rate limiting to control resource calls for various services, which fails to effectively distinguish the rationality of different service call behaviors. For example, navigation services, due to their core requirement of real-time route planning, have a high frequency of GPS calls, while payment services only use location for security verification, resulting in a lower call frequency. The fixed threshold mode places both types of services under the same standard, which can easily lead to problems such as location lag and response delays in navigation services due to threshold restrictions. At the same time, excessively high thresholds may cause resource waste in payment scenarios, making it difficult to achieve accurate and efficient resource allocation.

[0026] In the field of security protection, existing mechanisms mostly rely on passive protection methods such as sandbox isolation and static permission checks. These methods can only trace malicious API calls after the fact, lacking effective real-time control capabilities. When faced with malicious middleware calls, traditional solutions can only locate the attack source through log tracing after business interruptions or data leaks have occurred. They cannot achieve real-time interception and blocking during the attack, leaving security protection in a passive, reactive state of post-attack remediation, posing a significant threat to the stability of business systems and data security.

[0027] In terms of collaborative scenarios, traditional modular design adopts a resource management model where each module focuses on its own resource needs and allocation logic, lacking a global awareness of cross-module and cross-process business scenarios. When multiple business scenarios have concurrent and complex requirements, resource conflicts are easily triggered. For example, when the high-frequency GPS calls of navigation services and the location sharing requirements of instant messaging services are triggered simultaneously, if each module independently competes for location resources, both types of services will experience problems such as resource acquisition failure and decreased response efficiency.

[0028] In summary, there is an urgent need in the field of business resource scheduling and security protection for a method that can accurately identify business needs, perceive security risks in real time, and dynamically coordinate resource conflicts. This would solve problems such as unbalanced resource allocation, lagging security protection, and insufficient collaboration capabilities in traditional solutions, thereby improving the operational stability, resource utilization efficiency, and security protection level of business systems.

[0029] Based on this, this application proposes a middleware resource allocation method, which determines the middleware invocation strategy by dynamically coordinating resource conflicts in advance based on the middleware's status and other factors. In addition, this application can also detect malicious invocation behavior of the middleware, and when malicious invocation behavior is detected, a circuit breaker mechanism is used to interrupt the malicious invocation behavior in real time, thereby reducing resource waste.

[0030] The following combination Figure 1 The resource allocation method of the middleware in the embodiments of this application will be described in detail. This method can be applied to electronic devices, such as televisions and mobile phones, without limitation.

[0031] Figure 1 A schematic flowchart illustrating the resource allocation method of the middleware provided in this application is shown, with reference to... Figure 1 The method is described in detail below: S101, Obtain user intent.

[0032] In this embodiment, the user intent represents the task that the user needs the electronic device to perform at the current moment. For example, the user intent could be to open video A or delete file B.

[0033] S102, preload the target task according to the user intent. During the preloading process, monitor the current state of the target middleware and obtain the state information of the target middleware. The target task is the task that matches the user intent, and the target middleware is the middleware that needs to be called when executing the target task.

[0034] In this embodiment, the user's intent is parsed to determine the specific operation that the electronic device needs to perform, thus obtaining the target task. Then, it is determined which middleware needs to be invoked to execute the target task, and these middlewares are designated as target middleware. Preloading is the process of preparing necessary resources or initializing services in advance before task execution. Preloading may include obtaining the status information of the target middleware, as well as establishing network connections, loading algorithm models, etc.

[0035] For example, if the target task is to play a video, playing a video requires calling middleware such as decoders, file transfer, and audio processing. The middleware such as decoders, file transfer, and audio processing is referred to as the target middleware.

[0036] In this embodiment, the state information of the target middleware is obtained by hijacking / intercepting the Binder communication layer. Binder is an inter-process communication (IPC) mechanism that enables communication between different application processes, applications, and system services, such as when an app calls the system's camera service or notification service. Binder is the core channel for inter-process communication in Android. All cross-process AIDL (Android Interface Definition Language) interface calls (such as when an app calls a system service or when there are cross-process calls between apps) ultimately complete data transmission, request forwarding, and response return through the Binder layer.

[0037] In this embodiment, the status information of the target middleware may include: AIDL interface call frequency, thread blocking duration, and memory consumption. Specifically, counting the number of AIDL interface calls per unit time (e.g., 50 calls per minute) can identify frequently called interfaces. Monitoring the thread blocking duration of the target middleware can pinpoint busy middleware.

[0038] For TV-specific components, it can also monitor DRM licensing requests and MediaCodec decoding queues.

[0039] The DRM authorization request is a Digital Rights Management (DRM) authorization request. Streaming platforms use DRM technology to encrypt videos to prevent illegal copying and distribution. MediaCodec is a multimedia codec application programming interface (API) at the Android system level, responsible for translating video and audio data.

[0040] S103, based on the status information of the target middleware and historical user behavior data, obtain the invocation strategy of the target middleware, wherein the historical user behavior data includes the resource allocation of the middleware invoked when the electronic device processes the user's historical tasks.

[0041] In this embodiment, historical tasks that match the status information and target task of the target middleware are searched from historical user behavior data. Then, the current calling strategy of each target middleware is determined based on the resource allocation of the middleware corresponding to the matched historical figures.

[0042] The invocation strategy can include how much CPU, memory, and bandwidth to allocate to the target middleware.

[0043] For example, the invocation strategy for payment scenarios includes allocating encrypted Binder channels and isolating insecure IPCs. The invocation strategy for cloud gaming scenarios includes pre-sizing low-latency audio service channels to an 8ms response time.

[0044] S104, The target middleware is invoked to execute the target task according to the invocation strategy.

[0045] In one possible implementation, user intent can be determined based on multi-dimensional parameters. Specifically, such as... Figure 2 As shown, the above method may further include: S201, Obtain user instruction information and the focus state of the user interface of the electronic device.

[0046] In this embodiment, the user instruction information includes user voice information and remote control operation sequence, wherein the remote control operation sequence is generated by the remote control of the electronic device based on the user's operation.

[0047] For example, user voice commands could include "Open WeChat" or "Play video." Remote control operations could include the user clicking the volume up button or repeatedly clicking the down button.

[0048] The focus state of a user interface (UI focus state) represents the goal of a user action. It refers to which control, window, or application in a graphical user interface currently has the user's attention and interaction rights. UI focus state is one of the key pieces of contextual information that helps the system understand the goal and scope of the user's intent.

[0049] For example, on a TV, if a user is watching a video in a certain app in full screen, the video playback window will have focus. Pressing the "Menu" button at this time will bring up the app's own settings menu, not the system menu.

[0050] S202, based on the focus state of the user interface, determine the business scenario that the electronic device needs to execute and the priority of the business scenario.

[0051] In this embodiment, different priorities for different business scenarios are pre-configured. After determining the current business scenario, the priority corresponding to that business scenario can be found.

[0052] For example, if the current business scenario of an electronic device changes from a social chat scenario to a video viewing scenario, the priority of searching for the video viewing scenario is level 1, while the priority of the social chat scenario is level 3. Therefore, the priority of the video viewing scenario is higher than that of the social chat scenario.

[0053] In another approach, the focus state of the user interface is input into a trained intent classification model to determine the business scenario and its priority. The intent classification model can be a neural network model, etc.

[0054] S203, determine the user intent based on the user instruction information and the business scenario.

[0055] In one approach, feature vectors of user instruction information and feature vectors of business scenarios are extracted, and user intent is determined based on these feature vectors.

[0056] In another approach, user instruction information includes user voice information and remote control operation sequences, see reference. Figure 3 As shown, methods for determining user intent may include: S11, Perform semantic analysis on the user's voice information to obtain the user's semantic intent.

[0057] In this embodiment, noise reduction processing is performed on the user's voice information, for example, using wavelet denoising methods or adaptive filters to remove interference signals such as environmental noise and device current noise, and to eliminate silent portions before and after voice segments, retaining the effective voice signal. Features of the effective voice signal are extracted to obtain voice features, and semantic intent is derived from these voice features. Alternatively, after obtaining the voice features, the voice features are converted into text data, and semantic recognition is performed on the text data to obtain the semantic intent.

[0058] S12, perform key flow analysis on the remote control operation sequence to obtain the user's interaction intent.

[0059] In this embodiment, the remote control operation sequence is identified and segmented according to button type (mute, page switching, etc.) to obtain multiple button sequences. Feature extraction is performed on the button sequences to obtain feature vectors for each button sequence; the user's interaction intent is analyzed by combining all feature vectors.

[0060] S13, Based on the semantic intent, the interaction intent, and the business scenario, determine the user intent.

[0061] In this embodiment, based on semantic intent, interaction intent, and business scenario, it is determined whether they point to the same core need. If they point to the same core need, then the core need is determined as the user intent. If they do not point to the same core need, the confidence scores of semantic intent, interaction intent, and business scenario can be calculated, and the intent with the highest confidence score is taken as the user intent.

[0062] For example, semantic intent: turn up the TV volume; interactive intent: increase volume; business scenario: the TV is in playback mode and supports volume adjustment; matching result: merged into the user intent to increase the TV volume.

[0063] In this application, user voice information represents what the user said, remote control operation sequence represents what the user did, and business scenario represents what the user is watching. Combining the above three features can more accurately determine the user's intent.

[0064] S204, Generate a resource scheduling tag based on the user intent, the business scenario, and the priority of the business scenario.

[0065] In this embodiment, the resource scheduling tag includes user intent, business scenario, and priority of the business scenario.

[0066] Accordingly, the implementation process of step S103 above may also include: The invocation strategy for the target middleware is obtained based on the status information of the target middleware, the historical user behavior data, the business scenario, and the priority of the business scenario.

[0067] In this embodiment, if there are other tasks being executed, which are tasks other than the target task, and these other tasks are occupying the target middleware, the target middleware invocation strategy can be allocated based on the priority of each task, the status information of the target middleware, the historical user behavior data, the business scenario, etc. If the target middleware resources are insufficient, the resource occupation of the target middleware by lower priority tasks can be reduced to ensure the smooth execution of higher priority tasks.

[0068] Specifically, the user behavior data is used to train the strategy planning model to be trained, resulting in a trained strategy planning model. The state information of the target middleware, the business scenario, and the priority of the business scenario are input into the trained strategy planning model. The trained strategy planning model is then used to regulate the target middleware, resulting in the invocation strategy of the target middleware.

[0069] In this embodiment, the strategy planning model can be a spatiotemporal graph neural network. Business scenarios are associated with corresponding target middleware, with nodes representing business scenarios and edges representing target middleware. Then, the invocation strategy for the target middleware is determined based on the relationship between nodes and edges.

[0070] It should be noted that after the strategy planning model has been trained, the trained strategy planning model can be used directly, and it is not necessary to train the strategy planning model every time a task is performed.

[0071] In one approach, historical user behavior data includes historical tasks, middleware status information before the execution of historical tasks, and resource allocation of the middleware when executing historical tasks.

[0072] Historical user behavior data is input into the strategy planning model to be trained, and the predicted resource allocation strategy is output. The execution effect of the predicted resource allocation strategy is evaluated to obtain the loss function. The parameters in the strategy planning model are corrected using the loss function. This process is repeated to obtain the trained strategy planning model.

[0073] In another approach, after the target task has completed and while the electronic device is idle, reference... Figure 4 As shown, the above method may further include: S301, Obtain resource usage data when executing user tasks within a historical time period, where user tasks include the target task.

[0074] In this embodiment, when executing a user task, resource usage data is recorded, such as CPU utilization, middleware call frequency, and memory usage.

[0075] S302, Based on the resource occupancy data, construct a resource contention dependency graph among multiple user tasks, wherein the resource contention dependency graph represents user tasks that have resource contention, and the resource information that is competed among the user tasks that have resource contention.

[0076] In this embodiment, when different user tasks are processed at the same time, it is queried which user tasks are experiencing resource contention, the situation is recorded, and a resource contention dependency graph is generated.

[0077] S303, Based on the resource contention dependency graph, the Nash equilibrium algorithm is used to reallocate resources for multiple user tasks to obtain the resource reallocation strategy corresponding to each user task.

[0078] In this embodiment, during the game, the Nash equilibrium algorithm ensures that each participant adopts the optimal strategy, and there is no incentive for them to change their strategy individually. The introduction of the Nash equilibrium algorithm adapts to the game-like resource demands of multiple tasks, and can find the globally optimal resource allocation balance point in scenarios where the interests (resource demands) of multiple tasks conflict.

[0079] The Nash equilibrium algorithm can be used to optimize cross-process coordination strategies. Resource reallocation can include bandwidth allocation, middleware call frequency allocation, etc.

[0080] S304, compare the resource reallocation strategy with the corresponding resource occupancy data to determine the execution effect of the user task.

[0081] S305, The parameters of the trained policy planning model are corrected based on the performance of the user task.

[0082] In this embodiment, the execution effect can be evaluated numerically. If the execution effect is greater than a preset threshold, no adjustment is needed to the parameters in the strategy planning model; if the execution effect is less than the preset threshold, the parameters of the strategy planning model need to be adjusted to make the strategy planning model more accurate.

[0083] In one possible implementation, the above method may further include: When an electronic device is idle, it can clean up invalid Binder connections, reallocate thread pool sizes, and optimize memory layout, thus resolving long-term memory fragmentation issues.

[0084] In one possible implementation, while processing tasks, the electronic device can also automatically check for malicious calls from middleware, and after confirming the existence of malicious calls from middleware, use a circuit breaker mechanism to terminate the malicious behavior, thereby achieving real-time processing of the malicious behavior.

[0085] Specifically, such as Figure 5 As shown, the above method may further include: S401, Obtain the behavior data of the application calling the middleware in the electronic device.

[0086] In this embodiment, behavioral data may include the call frequency of middleware and which middleware was called in the business scenario.

[0087] S402, determine whether there is malicious behavior in the behavior data, wherein the malicious behavior includes behavior that calls the middleware more frequently than a preset threshold, and / or middleware call behavior that does not match the business scenario processed by the application.

[0088] In this embodiment, the isolated forest algorithm is used to detect whether malicious behavior exists in the behavioral data.

[0089] For example, in a payment scenario, there is no need to frequently call the location middleware, but the behavior data of the middleware does show frequent calls to the location middleware. This behavior is malicious.

[0090] S403, if malicious behavior exists in the behavior data, generate a circuit breaker mechanism for the malicious behavior, wherein the circuit breaker mechanism includes limiting the number of times the application calls the middleware corresponding to the malicious behavior.

[0091] In this embodiment, if malicious behavior is found, the malicious behavior will be associated with and stored with the corresponding application signature.

[0092] In this embodiment, the circuit breaker mechanism can directly limit the call threshold to a fixed value (e.g., 30 times). When the number of times the middleware is called exceeds the fixed value, the call is ignored, meaning the middleware call is no longer executed. Alternatively, the circuit breaker mechanism can use a gray-scale threshold method to limit the number of times a violation occurs, thus blocking malicious behavior; that is, it only restricts the violation interface rather than the entire process.

[0093] In one possible implementation, if the electronic device has not processed the target task within a historical period, then the method described in steps S101 to S104 above needs to be used to execute the target task; if the electronic device has processed the target task within a historical period, then steps S101 to S104 above do not need to be executed, and the previous calling strategy can be directly searched and executed.

[0094] Specifically, the execution process of step S102 above may also include: S1021, check if the user intent exists in the database, wherein the database stores the mapping relationship between historical user intents and middleware invocation strategies.

[0095] In this embodiment, the pre-similarity between the current user intent and the historical user intent in the database is calculated. If the cosine similarity is greater than a preset threshold, the two intents are determined to be the same.

[0096] S1022, if there is no historical user intent in the database that matches the user intent, the target task is preloaded according to the user intent. During the preloading process, the current state of the target middleware is monitored to obtain the state information of the target middleware, and the step of obtaining the calling strategy of the target middleware based on the state information of the target middleware and historical user behavior data, and subsequent steps are triggered.

[0097] In this embodiment, if there is no historical user intent in the database that matches the user intent, then the above steps S102 to S104 need to be executed.

[0098] S1023, if there is a historical user intent in the database that matches the user intent, obtain the target strategy, wherein the target strategy is the middleware invocation strategy corresponding to the historical user intent that matches the user intent stored in the database.

[0099] S1024, The middleware is invoked to execute the task corresponding to the user intent according to the target strategy.

[0100] In this embodiment, if a historical user intent that matches the user intent exists in the database, it is determined that a user intent exists in the database. The invocation strategy corresponding to the historical user intent that matches the user intent can be directly obtained and the found invocation strategy can be executed to improve task execution efficiency.

[0101] Specifically, if the database contains historical user intents that match the user intent, the above steps S102 to S104 are not executed.

[0102] Specifically, the execution process of step S103 above may also include: The database is searched to determine if the user intent exists, as well as the status information of the middleware that matches the user intent. The database stores the mapping relationship between historical user intents, middleware status information, and middleware invocation strategies.

[0103] If there is no historical user intent matching the user intent in the database, and / or there is no middleware status information matching the user intent, the invocation strategy of the target middleware is obtained based on the status information of the target middleware and the historical user behavior data.

[0104] If the database contains historical user intents that match the user intent, and also contains middleware status information that matches the user intent, a target strategy is obtained, wherein the target strategy is the middleware invocation strategy corresponding to the user intent stored in the database.

[0105] The middleware is invoked according to the target strategy to execute the task corresponding to the user intent.

[0106] It should be understood that the sequence number of each step in the above embodiments 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.

[0107] Corresponding to the middleware resource allocation method described in the above embodiments, Figure 6 A structural block diagram of a terminal device provided in an embodiment of this application is shown. For ease of explanation, only the parts related to the embodiment of this application are shown.

[0108] Reference Figure 6 The terminal device 500 may include: an intent acquisition module 510, a middleware monitoring module 520, a strategy planning module 530, and a task execution module 540.

[0109] Among them, the intent acquisition module 510 is used to acquire user intent; The middleware monitoring module 520 is used to preload a target task according to the user intent. During the preloading process, it monitors the current status of the target middleware and obtains the status information of the target middleware. The target task is a task that matches the user intent, and the target middleware is the middleware that needs to be called when executing the target task. The strategy planning module 530 is used to obtain the calling strategy of the target middleware based on the status information of the target middleware and historical user behavior data, wherein the historical user behavior data includes the resource allocation of the middleware called when the electronic device processes the user's historical tasks. The task execution module 540 is used to invoke the target middleware to execute the target task according to the invocation strategy.

[0110] In one possible implementation, the terminal device 500 further includes: The data acquisition module is used to acquire user instructions and the focus state of the user interface of the electronic device; The scenario determination module is used to determine the business scenario that the electronic device needs to execute and the priority of the business scenario based on the focus state of the user interface. An intent recognition module is used to determine the user intent based on the user instruction information and the business scenario; The resource integration module is used to generate resource scheduling tags based on the user intent, the business scenario, and the priority of the business scenario; Accordingly, the strategy planning module 530 can be specifically used for: The invocation strategy for the target middleware is obtained based on the status information of the target middleware, the historical user behavior data, the business scenario, and the priority of the business scenario.

[0111] In one possible implementation, the user instruction information includes user voice information and a remote control operation sequence, wherein the remote control operation sequence is generated by the remote control of the electronic device based on the user's operation; The intent recognition module can be specifically used for: Semantic analysis is performed on the user's voice information to obtain the user's semantic intent; The user's interaction intent is obtained by performing key flow analysis on the remote control operation sequence. The user intent is determined based on the semantic intent, the interaction intent, and the business scenario.

[0112] In one possible implementation, the strategy planning module 530 can specifically be used for: The target middleware's status information, the business scenario, and the priority of the business scenario are input into the trained strategy planning model. The target middleware is then regulated by the trained strategy planning model to obtain the target middleware's invocation strategy. The trained strategy planning model is obtained by training the strategy planning model to be trained using the historical user behavior data.

[0113] In one possible implementation, the terminal device 500 further includes: The historical data acquisition module is used to acquire resource usage data when executing user tasks within a historical time period, where the user tasks include the target task. The relationship identification module is used to construct a resource competition dependency graph among multiple user tasks based on the resource occupancy data, wherein the resource competition dependency graph represents user tasks that have resource competition, and the resource information that is competed among the user tasks that have resource competition; The reallocation module is used to reallocate resources for multiple user tasks according to the resource contention dependency graph and the Nash equilibrium algorithm to obtain the resource reallocation strategy corresponding to each user task. The effect calculation module is used to compare the resource redistribution strategy with the corresponding resource usage data to determine the execution effect of the user task; The correction module is used to correct the parameters of the trained policy planning model based on the performance of the user task.

[0114] In one possible implementation, the terminal device 500 further includes: The data lookup module is used to obtain behavioral data of the application calling middleware in the electronic device; The behavior recognition module is used to determine whether there is malicious behavior in the behavior data, wherein the malicious behavior includes behavior that calls the middleware more frequently than a preset threshold, and / or middleware call behavior that does not match the business scenario processed by the application; A circuit breaker module is used to generate a circuit breaker mechanism for malicious behavior if malicious behavior is found in the behavior data. The circuit breaker mechanism includes limiting the number of times the application can call the middleware corresponding to the malicious behavior.

[0115] In one possible implementation, the middleware monitoring module 520 can specifically be used for: Check if the user intent exists in the database, wherein the database stores the mapping relationship between historical user intents and middleware invocation strategies; If no historical user intent matching the user intent exists in the database, the target task is preloaded according to the user intent. During the preloading process, the current state of the target middleware is monitored to obtain the state information of the target middleware, and the step of obtaining the calling strategy of the target middleware based on the state information of the target middleware and historical user behavior data, as well as subsequent steps, are triggered.

[0116] In one possible implementation, the middleware monitoring module 520 can specifically be used for: If a historical user intent that matches the user intent exists in the database, a target strategy is obtained, wherein the target strategy is the middleware invocation strategy corresponding to the user intent stored in the database; The middleware is invoked according to the target strategy to execute the task corresponding to the user intent.

[0117] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.

[0118] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments 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. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0119] This application also provides a terminal device, see [link to relevant documentation] Figure 7 The terminal device 600 may include: at least one processor 610, a memory 620, and a computer program stored in the memory 620 and executable on the at least one processor 610. When the processor 610 executes the computer program, it implements the steps in any of the above method embodiments, for example... Figure 1 Steps S101 to S104 in the illustrated embodiment. Alternatively, when the processor 610 executes the computer program, it implements the functions of each module / unit in the above-described device embodiments, for example... Figure 6 The schematic diagram illustrates the functions of module 510 to task execution module 540.

[0120] For example, a computer program may be divided into one or more modules / units, one or more of which are stored in memory 620 and executed by processor 610 to complete this application. The one or more modules / units may be a series of computer program segments capable of performing specific functions, which describe the execution process of the computer program in terminal device 600.

[0121] Those skilled in the art will understand that Figure 7 This is merely an example of a terminal device and does not constitute a limitation on the terminal device. It may include more or fewer components than shown, or combine certain components, or different components, such as input / output devices, network access devices, buses, etc.

[0122] The processor 610 can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0123] The memory 620 can be an internal storage unit of the terminal device or an external storage device, such as a plug-in hard drive, a smart media card (SMC), a secure digital (SD) card, or a flash card. The memory 620 is used to store the computer program and other programs and data required by the terminal device. The memory 620 can also be used to temporarily store data that has been output or will be output.

[0124] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0125] The middleware resource allocation method provided in this application embodiment can be applied to terminal devices such as computers, tablets, laptops, netbooks, and personal digital assistants (PDAs). This application embodiment does not impose any restrictions on the specific type of terminal device.

[0126] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0127] Those skilled in the art will recognize that the units 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.

[0128] In the embodiments provided in this application, it should be understood that the disclosed terminal devices, apparatuses, and methods can be implemented in other ways. For example, the terminal device embodiments described above are merely illustrative. For instance, the division of modules or 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 an indirect coupling or communication connection through some interfaces, apparatuses, or units, and may be electrical, mechanical, or other forms.

[0129] 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.

[0130] Furthermore, the functional units in the various embodiments of this application 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.

[0131] 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, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by one or more processors, it can implement the steps of the various method embodiments described above.

[0132] 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, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by one or more processors, it can implement the steps of the various method embodiments described above.

[0133] Similarly, as a computer program product, when the computer program product is run on a terminal device, it enables the terminal device to implement the steps in the above-described method embodiments.

[0134] The computer program includes computer program code, which can be in the form of source code, object code, executable file, or some intermediate form. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drive, portable hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium can be appropriately added or removed according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media may not include electrical carrier signals and telecommunication signals.

[0135] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A resource allocation method for middleware, characterized in that, include: Obtain user intent; Preload the target task according to the user intent. During the preloading process, monitor the current state of the target middleware and obtain the state information of the target middleware. The target task is the task that matches the user intent, and the target middleware is the middleware that needs to be called when executing the target task. Based on the status information of the target middleware and historical user behavior data, the invocation strategy of the target middleware is obtained, wherein the historical user behavior data includes the resource allocation of the middleware invoked when the electronic device processes the user's historical tasks; The target middleware is invoked to execute the target task according to the invocation strategy.

2. The middleware resource allocation method as described in claim 1, characterized in that, The method further includes: To obtain user instructions and the focus state of the electronic device's user interface; Based on the focus state of the user interface, determine the business scenario that the electronic device needs to execute and the priority of the business scenario; The user intent is determined based on the user instruction information and the business scenario; Based on the user intent, the business scenario, and the priority of the business scenario, a resource scheduling label is generated; Accordingly, obtaining the invocation strategy for the target middleware based on its status information and historical user behavior data includes: The invocation strategy for the target middleware is obtained based on the status information of the target middleware, the historical user behavior data, the business scenario, and the priority of the business scenario.

3. The middleware resource allocation method as described in claim 2, characterized in that, The user instruction information includes user voice information and remote control operation sequence, wherein the remote control operation sequence is generated by the remote control of the electronic device based on the user's operation; Determining the user intent based on the user instruction information and the business scenario includes: Semantic analysis is performed on the user's voice information to obtain the user's semantic intent; The user's interaction intent is obtained by performing key flow analysis on the remote control operation sequence. The user intent is determined based on the semantic intent, the interaction intent, and the business scenario.

4. The middleware resource allocation method as described in claim 2, characterized in that, The step of obtaining the invocation strategy for the target middleware based on the target middleware's status information, historical user behavior data, business scenario, and the priority of the business scenario includes: The target middleware's status information, the business scenario, and the priority of the business scenario are input into the trained strategy planning model. The target middleware is then regulated by the trained strategy planning model to obtain the target middleware's invocation strategy. The trained strategy planning model is obtained by training the strategy planning model to be trained using the historical user behavior data.

5. The middleware resource allocation method as described in claim 4, characterized in that, The method further includes: Obtain resource usage data during the execution of user tasks within a historical time period, where user tasks include the target task; Based on the resource usage data, a resource contention dependency graph is constructed among multiple user tasks, wherein the resource contention dependency graph represents user tasks that have resource contention, and the resource information that is competed among the user tasks that have resource contention; Based on the resource contention dependency graph, the Nash equilibrium algorithm is used to reallocate resources for multiple user tasks to obtain the resource reallocation strategy for each user task. The resource reallocation strategy is compared with the corresponding resource usage data to determine the execution effect of the user task; The parameters of the trained policy planning model are adjusted based on the performance of the user task.

6. The middleware resource allocation method as described in claim 1, characterized in that, The method further includes: Obtain behavioral data of the application calling middleware in the electronic device; Determine whether there is malicious behavior in the behavioral data, wherein the malicious behavior includes behavior that calls the middleware more frequently than a preset threshold, and / or middleware call behavior that does not match the business scenario processed by the application; If malicious behavior is found in the behavioral data, a circuit breaker mechanism for the malicious behavior is generated, wherein the circuit breaker mechanism includes limiting the number of times the application can call the middleware corresponding to the malicious behavior.

7. The middleware resource allocation method as described in claim 1, characterized in that, The step of preloading the target task according to the user intent, and monitoring the current state of the target middleware during the preloading process to obtain the state information of the target middleware, includes: Check if the user intent exists in the database, wherein the database stores the mapping relationship between historical user intents and middleware invocation strategies; If no historical user intent matching the user intent exists in the database, the target task is preloaded according to the user intent. During the preloading process, the current state of the target middleware is monitored to obtain the state information of the target middleware, and the step of obtaining the calling strategy of the target middleware based on the state information of the target middleware and historical user behavior data, as well as subsequent steps, are triggered.

8. The middleware resource allocation method as described in claim 7, characterized in that, After checking if the user intent exists in the database, the method further includes: If a historical user intent that matches the user intent exists in the database, a target strategy is obtained, wherein the target strategy is the middleware invocation strategy corresponding to the user intent stored in the database; The middleware is invoked according to the target strategy to execute the task corresponding to the user intent.

9. A terminal device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the middleware resource allocation method as described in any one of claims 1 to 8.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the resource allocation method of the middleware as described in any one of claims 1 to 8.

Images