Task dynamic management method and device in task management application

Abstract

The invention discloses a task dynamic management method and device in a task management application, and relates to the crossing field of mobile internet, digital medical treatment and intelligent control technologies, and the method comprises the steps: constructing a task control block for each task in the task management application; based on the task control block, obtaining a static priority and a task dynamic attribute of each task in the task management application, wherein the static priority represents the importance degree of the task; calculating the urgency level of each task according to the static priority and the dynamic attribute of each task; and executing the currently established task in the task management application according to the urgency level of the task. Task execution (reminding and display) is performed according to the urgency level of the task in the task management application, and the problem of key information display right under high concurrency is solved.

Description

Technical Field

[0001] This application relates to the intersection of mobile internet, digital healthcare and intelligent control technologies, and in particular to a method and apparatus for dynamic task management in a task management application. Background Technology

[0002] With the increasing aging population and the transformation of chronic disease management models, personal task management applications (mHealth Apps) based on mobile terminals (smartphones, wearable devices) are gradually becoming an important extension of the healthcare service system. However, existing health reminder applications, when faced with complex medical scenarios, employ AlarmManager or UserNotifications mechanisms, which are "open-loop triggering systems" lacking awareness of the runtime environment. In high-concurrency scenarios, this mechanism can lead to low-priority processes occupying the critical section of the system's UI thread, thus causing starvation of high-priority tasks.

[0003] Existing health reminder applications primarily rely on native timer mechanisms provided by the operating system, such as Android's AlarmManager or iOS's UserNotifications framework. Their core logic is linear triggering based on an absolute timestamp, i.e., "setting a time..." -> Trigger event.

[0004] In multi-task concurrent scenarios (e.g., an elderly person with multiple chronic diseases needs to simultaneously complete "fasting blood glucose measurement", "taking antihypertensive medication", "measuring blood pressure" and "drinking water" at 8:00 AM), existing task management applications typically adopt a "first-come, first-served" or simple "stack-style" display strategy, resulting in the delayed processing of more urgent tasks. Summary of the Invention

[0005] The purpose of this application is to provide a method and apparatus for dynamic task management in a task management application, which can execute (remind and display) tasks according to their priority in the task management application, thus solving the problem of displaying key information under high concurrency.

[0006] To achieve the above objectives, this application provides the following solution: Firstly, this application provides a method for dynamic task management in a task management application, including: For each task in the task management application, build a task control block; Based on the task control block, obtain the static priority and dynamic attributes of each task in the task management application that represent the importance of the task. The urgency level of each task is calculated based on its static priority and dynamic attributes. Execute currently created tasks in the task management application based on their urgency level.

[0007] Secondly, this application provides a computer device, including: a memory, a processor, and a computer program stored in the memory and capable of running on the processor, wherein the processor executes the computer program to implement the task dynamic management method described above in the task management application.

[0008] Thirdly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the task dynamic management method described above in the task management application.

[0009] Fourthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements the task dynamic management method described above in the task management application.

[0010] According to the specific embodiments provided in this application, this application has the following technical effects: This application provides a method and apparatus for dynamic task management in a task management application. The method involves acquiring the static priority and dynamic attributes of each task in the task management application, representing its importance; calculating the urgency level of each task based on its static priority and dynamic attributes; and executing currently established tasks in the task management application according to their urgency levels. This application executes tasks (reminders and displays) based on their urgency levels in the task management application. Through a hyperbolic urgency algorithm, it achieves deterministic scheduling of computing resources (CPU) and interactive resources (UI), eliminating the uncertainty of task latency under high load. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments 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.

[0012] Figure 1 This is an application environment diagram of a task dynamic management method in a task management application according to an embodiment of this application; Figure 2 A flowchart illustrating a dynamic task management method in a task management application provided in an embodiment of this application; Figure 3This is a schematic diagram illustrating the complete lifecycle state transition of a health task in a system, provided as an embodiment of this application. Figure 4 A schematic diagram of preemptive scheduling logic based on dynamic weights (urgency levels) provided for another embodiment of this application; Figure 5 A schematic diagram of a hierarchical closed-loop control process based on a cloud-based shadow countdown mechanism provided in an embodiment of this application; Figure 6 A schematic diagram of a scene decision logic tree for multimodal sensor fusion provided in an embodiment of this application; Figure 7 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0013] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0014] This application provides a dynamic task management method for task management applications, specifically a method for full lifecycle management of high-concurrency, heterogeneous health management tasks on resource-constrained mobile computing devices. In particular, it refers to a method that resolves UI resource conflicts through a dynamic weighting algorithm, utilizes multimodal sensor fusion technology to achieve adaptive adjustment of user scene perception and intervention intensity, and constructs a cross-terminal hierarchical closed-loop feedback control mechanism based on a heterogeneous network environment.

[0015] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0016] The task dynamic management method provided in this application embodiment can be applied to tasks such as... Figure 1In the application environment shown, terminal 102 communicates with server 104 via a network. A data storage system can store the data that server 104 needs to process. The data storage system can be set up independently, integrated into server 104, or placed in the cloud or on another server. Terminal 102 can obtain the static priority and dynamic attributes representing the importance of each task based on the task control block; it sends the static priority and dynamic attributes representing the importance of each task in the task management application to server 104. After receiving the relevant data, server 104 calculates the urgency level of each task based on its static priority and dynamic attributes; and executes the currently established tasks in the task management application according to their urgency levels. Server 104 can feed back the ranking results of the task urgency levels to terminal 102. In addition, in some embodiments, the task dynamic management method in the task management application can also be implemented by the server 104 or the terminal 102 separately. For example, the terminal 102 can directly perform task dynamic management in the task management application for the video to be processed, or the server 104 can obtain the video to be processed from the data storage system and perform task dynamic management in the task management application for the video to be processed.

[0017] The terminal 102 can be, but is not limited to, various desktop computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, and smart in-vehicle devices. Portable wearable devices can include smartwatches, smart bracelets, and head-mounted devices. The server 104 can be implemented using a standalone server or a server cluster composed of multiple servers, or it can be a cloud server.

[0018] In one exemplary embodiment, such as Figure 2 and Figure 3 As shown, a dynamic task management method is provided in a task management application. This method is executed by a computer device, specifically by a terminal or server alone, or by both a terminal and a server. In this embodiment, the method is applied to... Figure 1 Taking server 104 as an example, the explanation includes the following steps 201 to 203. Wherein: Step 201: For each task in the task management application, construct a task control block; based on the task control block, obtain the static priority and dynamic attributes of each task in the task management application that represent the importance of the task.

[0019] This embodiment uses a task management application as an example of a health management application. The static priority that characterizes the importance of a task can be a static priority that characterizes the medical importance of a task.

[0020] Each health task in a health management application is digitally modeled, and a Task Control Block (TCB) is maintained in memory for each health task. The TCB of a health task contains static priority and dynamic status attributes.

[0021] Static Priority Level: Based on a predefined baseline score of medical importance. Specifically, it includes: PL1 (High Risk / Critical): Life-threatening tasks (e.g., taking nitroglycerin, injecting insulin). Baseline Score Such tasks are "unmaskable".

[0022] PL2 (Health): Routine chronic disease management (e.g., taking antihypertensive medication, monitoring blood glucose). Baseline score. .

[0023] PL3 (Care): Lifestyle interventions (e.g., hydration, sedentary reminders). Baseline score .

[0024] The dynamic state attributes include: Valid Window ): The executable time period of the task. This is the deadline for the task to expire.

[0025] Mutex Group label: Defines logical mutual exclusion relationships (such as "before meal" and "after meal").

[0026] Retry Count ): Records the number of times a user fails to respond.

[0027] Step 202: Calculate the urgency level of each task based on its static priority and dynamic attributes.

[0028] Step 203: Execute the tasks currently created in the task management application according to the urgency level of the tasks.

[0029] Implementing steps 201 to 203 above, existing operating systems lack the intrinsic ability to perceive "medical urgency." This application addresses the issue of priority in displaying critical information under high concurrency by executing tasks (reminding and displaying them) based on the urgency level of tasks in a task management application.

[0030] In another exemplary embodiment of this application, the scheduling engine, as a background resident service, maintains a ready queue based on a max-heap structure to ensure that the query complexity of the highest-weighted task is O(n). .

[0031] In a typical list structure, finding the highest priority task requires traversing the entire list. However, in applications, task urgency changes dynamically over time. If the urgency is calculated for each scheduling operation, the system will become sluggish under high concurrency. This application adopts a strategy of "high-urgency tasks preempting the UI." The O(1) query capability ensures that when a new time slice arrives or a new task is inserted, the scheduling engine can instantly determine the most urgent task, thereby immediately triggering a context switch, which greatly improves the real-time performance of medical / health tasks.

[0032] To prevent low-priority tasks from being permanently blocked (Starvation) by high-priority task flows, and to ensure that tasks nearing their deadlines have an execution opportunity, this application introduces a urgency level function based on Early Deadline First (EDF) and Shortest Relaxed Time First (SSTF) variants.

[0033] The calculation formula for the dynamic weighting algorithm (urgency level calculation method) based on the urgency function is as follows: In the formula, Indicates the urgency level of task i; This represents the baseline score (e.g., 100 / 50 / 10) corresponding to the static priority of task i. This indicates the task reminder time set by the user; This indicates the number of times the task reminder has been retried before the user-set reminder time. As the number of retried attempts increases, the urgency level increases linearly, simulating "escalating anxiety due to user non-response". , , This represents the adjustment coefficient, used to balance the weighting of static importance, time urgency, and the number of retries. For example, take... =1.0, =1000, =20; t represents time t; This is a preset value, a minimum value, to prevent the denominator in the formula from being zero. The remaining slack time for the task. As the current time... Approaching the deadline The denominator tends to 0 ( To prevent division by zero for minimum values, the reciprocal term grows rapidly in a hyperbolic manner. This reflects the real-time scheduling principle that "the closer the deadline, the more urgent the task."

[0034] In another exemplary embodiment of this application, such as Figure 3 As shown, UI mutex and preemption logic is also provided: a global singleton controller AlertController is set up, and a boolean mutex is_Displaying is maintained.

[0035] Preemption determination: When a new task is launched Calculate the urgency level when an item arrives or is updated in the queue. With the mission currently being displayed Urgency level If the preemption conditions are met, the preemption process is triggered. The preemption conditions are: in, To prevent UI flickering caused by frequent switching between tasks with similar weights (to set a debouncing threshold). Suspend: to Send the onPause() signal, save its UI state (such as the notes entered by the user), and push it onto the suspend stack.

[0036] Execute: Acquire the mutex lock and render. The full-screen interface.

[0037] Resume: After the high-priority task is completed (Finish / Skip), release the mutex lock and pop the original task from the Suspend_Stack.

[0038] Figure 3This demonstrates the complete lifecycle state transitions of health tasks within the system. Specifically: Pending: The task waits in the priority queue, its urgency level increasing over time. Running: The task acquires the UI mutex lock and is being displayed to the user. Suspended: When a running task (e.g., PL2 blood pressure measurement) is interrupted by a higher-priority task (e.g., PL1 emergency medication), the current task is not destroyed but its context is saved, and it enters the suspended state. Once the higher-priority task completes, the system automatically restores the suspended task to the running state (Resumed), ensuring that lower-priority tasks are not lost due to concurrency conflicts. This constitutes a complete closed loop of "preemptive scheduling." Generally, for ordinary alarm clock apps, if two alarms collide, the older one is usually overwritten or overlapped. This application, however, achieves preemptive scheduling through the Suspended state, as well as the Preempted and Resumed states.

[0039] like Figure 4 The diagram illustrates a preemptive scheduling logic based on dynamic weights (urgency levels). At 08:00, a low-priority task A (such as a water reminder) is generated and executed, occupying the UI. At 08:05, a high-priority task B (such as taking emergency cardiac medication) suddenly occurs. At this time, the scheduling engine calculates that the urgency level of task B is significantly higher than that of task A, meeting the preemption threshold condition. It immediately triggers a "Suspend" operation, saving the current state of task A and forcibly transferring UI control to task B. After task B completes at 08:10, the mutex is released, task A is automatically popped from the suspend stack, and its display is "Resume," continuing the remaining interaction flow. This process ensures zero-latency display of critical medical information while preventing the loss of ordinary tasks. For ordinary alarm clock apps, the usual approach is to place a new alarm on top of an old one or wait in a queue. This application's solution adopts the idea of ​​"saving the current state -> forcibly jumping the queue -> restoring the current state."

[0040] Based on the above, the task dynamic management method in the task management application also includes: (1) When a new task is created in the task management application, calculate the urgency level of the new task.

[0041] (2) Determine whether the urgency level of the newly created task and the urgency level of the task currently being displayed in the task management application meet the conditions for preempting the new task.

[0042] (3) If so, save the context of the task process currently displaying the task, push it onto the suspend stack, and execute the newly created task. After the newly created task finishes execution and releases the UI mutex lock, pop the suspended task from the top of the stack and resume execution, and continue to execute the task pushed onto the suspend stack.

[0043] (4) If not, execute the tasks currently created in the task management application according to the urgency level of each task.

[0044] This application establishes a dynamic weight calculation and preemptive scheduling mechanism based on an urgency function to ensure that high-risk medical tasks have absolute control over the UI interface at all times, thus solving the problem of critical information display rights under high concurrency.

[0045] In another exemplary embodiment of this application, traditional alert systems typically employ a "blind triggering" mechanism, meaning that regardless of the user's physical state (e.g., deep sleep, driving, meeting) or psychological state, the system interrupts with a preset fixed volume and vibration pattern. This lacks real-time awareness of the user's context. A sudden high-decibel alarm during deep sleep may trigger a startle response, posing a potential risk to patients with cardiovascular disease; frequent interruptions in social situations (e.g., meetings) can cause embarrassment and aversion, leading users to actively close the application. In noisy environments (e.g., markets) or when the phone is deeply covered (e.g., at the bottom of a handbag), standard-intensity alerts are often imperceptible. This rigid interaction method is the core reason why users experience alarm fatigue and ultimately abandon the system. To address this, based on the aforementioned task ranking results, a hierarchical decision tree-driven multimodal sensor fusion technology is used to perceive and decide on the current user's scenario, thereby matching a corresponding adaptive intervention interaction strategy.

[0046] Within a millisecond window before the task is triggered, the multidimensional sensing module is activated. This module does not rely on energy-intensive deep neural networks, but instead uses an efficient hierarchical decision tree model to classify sensor feature vectors.

[0047] For multidimensional sensing data acquisition and feature extraction: The Hardware Abstraction Layer (HAL) interface is invoked to acquire the following sensor data and generate feature vectors. : Accelerometer: Extracting acceleration variance To determine whether the carrier equipment is stationary.

[0048] Ambient Light Sensor: Extracts the light intensity of the environment in which the carrier device is located. .

[0049] Proximity Sensor: Detects the distance between the carrier device and surrounding objects to determine whether the carrier device is in a near-ear / occlusion detection state. (Near / Far).

[0050] Microphone: Extracts ambient noise levels in decibels. .

[0051] System State: Extracts the package name of the currently foreground application. Telephone status Screen status .

[0052] Using decision trees based on feature vectors The system outputs the determination scenario of the carrier device and queries a pre-defined strategy mapping table (Table 1) to match the corresponding adaptive intervention strategy. For example, based on a hierarchical decision tree model, it first determines whether the device is stationary using data collected by the accelerometer; if so, it activates the light sensor to determine the ambient brightness; if the ambient brightness is below a threshold, it determines the scenario as a deep sleep scenario based on a time window; based on the determination results of each level, it terminates or activates subsequent sensor calls. A deep neural network model can also be used for scenario determination. For example, the data collected by the accelerometer, the data collected by the light sensor, and the current time can be input into the deep neural network model, and the model outputs the determined scenario.

[0053] Figure 5 This demonstrates a scene decision logic tree based on multimodal sensor fusion. Sensor data is collected within a millisecond-level window before the task is triggered, and intervention strategies are generated through hierarchical judgment. First layer (motion determination): Determine whether the device is stationary using an accelerometer.

[0054] The second layer (environmental assessment): combines a light sensor with a time window. If it is determined to be "deep sleep" (still and dark), it automatically selects a "gradual wake-up" strategy (volume gradually increasing) to avoid startle reflex.

[0055] The third layer (location determination): Determines location based on proximity sensor and device status. If determined to be in "pocket mode" (obstructed and inverted), automatically selects "strong penetration mode" (maximum volume + special vibration) to prevent missed calls. If determined to be in "call mode" (obstructed and not inverted), an alert tone is injected into the earpiece to protect user privacy.

[0056] The logic layering used in this application is as follows: first, check for movement (acceleration); then, check for brightness (light sensor); and finally, check for obstructions (distance). This order reflects the low-power design (if the first step determines that the object is stationary, there is no need to call the subsequent complex logic).

[0057] This logic ensures that adaptive intervention, where "machines adapt to humans," can be achieved, solving the problem of disturbance or failure caused by "blind reminders" in traditional technologies.

[0058] Table 1 Scenario Decision Logic Table

[0059] Based on the above, tasks currently created in the task management application are executed according to their urgency level, specifically including: (1) Obtain multi-dimensional sensing data of the carrier device of the task management application.

[0060] (2) Based on multidimensional sensing data, a hierarchical decision tree is applied to determine the scenario in which the carrier device of the task management application is located. For example... Figure 5 As shown, the system first checks if the acceleration variance is less than a corresponding threshold. If it is, the device is stationary. Next, it checks if the light intensity is less than a corresponding threshold. If so, the device is in a dark environment. Then, it checks if the current time is within the user's sleep window. If so, the user is in deep sleep. If the acceleration variance is greater than the corresponding threshold, the device is in motion. Next, it checks if the distance sensor's detection result is less than a corresponding threshold. If so, the device is obstructed. Finally, it checks if the device is inverted. If inverted, it's in a pocket; otherwise, it's in a contact position with the ear and in a call state. If the distance sensor's detection result is greater than the corresponding threshold, the device is not obstructed. Finally, it checks if the foreground application is on the device's desktop. If yes, the device is in immersive use; otherwise, it's in standby mode.

[0061] (3) Select the corresponding preset adaptive intervention strategy to execute the currently established task in the task management application according to the urgency level of the task and the current scenario of the carrier device; in the preset adaptive intervention strategy, the strategy used to execute the task will be different depending on the scenario of the carrier device and the urgency level of the task.

[0062] (4) Obtain historical user feedback information for each task and determine the feedback delay status of the corresponding task based on the historical user feedback information.

[0063] (5) Adjust the urgency level of the corresponding task based on the feedback of the delay.

[0064] This application utilizes multimodal sensor fusion technology to construct a user scenario inference model, achieving adaptive modulation of alert intensity and resolving the mismatch between alert methods and user states. Based on a multi-dimensional perception-based wake-up mechanism, it effectively reduces the average number of system interruptions and power consumption for persistent background services.

[0065] In another exemplary embodiment of this application, existing reminder systems are mostly based on an "open-loop control" architecture. This means that after the system issues a reminder signal, it does not require feedback on the execution result, or only performs limited retries locally. The entire monitoring link suffers from a serious single point of failure (SPOF) risk. If the user terminal crashes, the battery runs out, the operating system forcibly kills a background process, or the network disconnects, the local monitoring logic will be completely paralyzed. Due to the lack of closed-loop feedback and a dead man's switch mechanism across terminals (cloud or guardian's end), guardians cannot know the status of being out of contact, which is an unacceptable safety hazard for elderly people living alone or high-risk patients. To address this, this application, after issuing task reminders based on the aforementioned adaptive intervention strategy, uses a cloud-based shadow countdown to perform hierarchical closed-loop control under a heterogeneous network, thereby obtaining deterministic feedback from the user regarding the task execution result.

[0066] This application introduces a three-tiered closed-loop feedback mechanism of "device-cloud-guardian", such as Figure 6 As shown, a tiered upgrade strategy of "local T+5, cloud T+15" is adopted.

[0067] This includes employing a cloud shadow countdown mechanism, designed to address the single point of failure issue on user terminals. Specifically: Pre-registration: When a task management application generates a task locally, it immediately sends a pre-registration package to the cloud via HTTPS. .

[0068] Shadow Mirror: After receiving the data in the cloud, a separate countdown timer is started in the server's memory, with a timeout threshold set. .

[0069] Normal closed loop: User confirms medication on the APP -> APP sends ACK packet -> Shadow timer is destroyed in the cloud.

[0070] Abnormal Trigger: If the countdown reaches zero and the cloud still has not received an ACK packet (the reason may be that the phone is frozen, the network is disconnected, or the elderly person is unconscious), the cloud determines that it is "out of contact", triggers the dead hand switch, and actively sends an alarm to the guardian.

[0071] Figure 6 This demonstrates a hierarchical closed-loop control process based on a cloud-based shadow mechanism: Pre-registration mechanism: Before a high-risk task is triggered, the mobile device synchronizes the task information to the cloud, and the cloud starts an independent "shadow timer".

[0072] Dead Man's Switch Logic: The "Abnormal A" path in the diagram illustrates that when the mobile device is unable to send an acknowledgment signal (ACK) due to a crash, network outage, or physical damage, the shadow timer in the cloud will automatically run out. At this point, the cloud determines that the terminal is disconnected and directly sends an alarm to the guardian.

[0073] Signaling degradation logic: The "Abnormal B" path in the diagram illustrates that when the data network (WiFi / 4G) is unavailable, it automatically degrades to using the SMS channel to send confirmation signaling, ensuring the delivery of closed-loop information. The cloud-based timer in this application operates independently and does not rely on any subsequent operations on the mobile device. Even if a problem occurs on the mobile device, an alarm can be directly sent to the guardian through the cloud.

[0074] Based on the above, the task dynamic management method in the task management application also includes: (1) Determine whether user feedback information has been received and obtain the first judgment result; user feedback information refers to the feedback information of the user on the executed task in the task management application.

[0075] (2) If the first judgment result is yes, then send an ACK packet to the cloud through the task management application, and the cloud cancels the shadow countdown timer built; the shadow countdown timer is the shadow countdown timer built in the cloud for each task when a task is generated in the task management application.

[0076] The cloud-based shadow countdown timer operates independently and is decoupled from the client. Its operation is independent of the client's state. That is, even if the client's phone freezes, loses power, or experiences a complete network outage, the cloud-based shadow countdown timer will still independently complete its countdown and trigger an alarm, thus resolving the issue of the client being unable to send a distress signal due to a "single point of failure" (i.e., the "dead-end switch" logic).

[0077] (3) If the first judgment result is negative, determine whether the shadow countdown timer of the executed task has been reset to zero, and obtain the second judgment result.

[0078] (4) If the second judgment result is negative, then execute the tasks currently established in the task management application according to the urgency level of each task.

[0079] (5) If the second judgment result is yes, the shadow countdown timer built in the cloud will be canceled, and an alarm will be sent to the guardian of the user to whom the task management application belongs.

[0080] In another exemplary embodiment of this application, a signaling channel degradation mechanism is designed for scenarios where elderly users experience unstable home WiFi or data traffic exhaustion.

[0081] Level 1 (IP Data Channel): Alarm data is sent via MQTT / HTTP long connection by default.

[0082] Fault detection: If the Socket connection times out or throws a NetworkUnreachableException, the system will automatically catch the exception.

[0083] The determination of whether a network anomaly is due to WiFi failure or data exhaustion is implemented using the callback mechanism of the network connection manager in the Android / iOS system. When MQTT / Socket heartbeat packet transmission fails, the system immediately queries the current active network type (ActiveNetworkInfo). If the current system shows that it is connected to WiFi but cannot send packets, it is determined as "Home WiFi access point failure (external network unavailable)". If the current system shows that it is using mobile data but cannot send packets, and the signal strength is normal, it is determined as "Data traffic exhausted or carrier gateway restriction". Regardless of whether it is a WiFi failure or data exhaustion, if the IP data channel is unavailable, it immediately switches to the SMS signaling channel.

[0084] Level 2 (SMS signaling channel): Immediately downgrade and call the system's SmsManager interface.

[0085] Protocol encapsulation: Serialize alarm information into short text (e.g., {"T":"Med","L":"PL1","S":"Urgent"}).

[0086] Send: Send encrypted SMS (encrypted short text) to the cloud gateway or guardian's mobile phone via GSM / CDMA control channel.

[0087] In the design of communication base stations (Towers), voice and SMS messages are transmitted via the signaling control channel (Control Plane), while internet access is transmitted via the user data channel (User Plane). When a base station is congested (e.g., during a concert or disaster), the base station will prioritize discarding data packets but will keep the signaling channel alive. SMS signaling has a higher transmission priority and success rate than data traffic in congested or weak signal environments, ensuring uninterrupted network connectivity. This application is more reliable than ordinary app push notifications (which only use the data channel) in extreme network environments (congestion, weak network), ensuring that life-saving alarms are sent.

[0088] Based on the above, an alert will be sent to the guardian of the user who owns the task management application, specifically including: (1) Send network detection data to the carrier device of the task management application through MQTT / HTTP long connection to confirm whether the IP-based data channel of the carrier device is abnormal.

[0089] (2) If the IP-based data channel is abnormal (such as Socket connection timeout or NetworkUnreachableException), the signaling degradation strategy will be automatically triggered, the alarm prompt will be encapsulated, and the signaling channel will be switched to GSM / CDMA. The alarm prompt will be transmitted to the guardian of the user to which the task management application belongs based on the GSM / CDMA signaling channel.

[0090] This application constructs a hierarchical closed-loop control system for heterogeneous networks based on "cloud shadow countdown" and "SMS signaling degradation" to eliminate the risk of single-point failure of terminals and solve the problem of signaling delivery in weak network / crash environments.

[0091] In another exemplary embodiment of this application, a "supplementary recording card" is generated for failed tasks (tasks that do not provide feedback within a specified time period).

[0092] Knowledge graph feedback: The system uses user data entry behavior to adjust task scheduling. For example, if a user postpones a 9:00 AM task to 9:30 AM for a week, the system automatically suggests shifting the scheduled time to 9:30 AM, achieving "data-driven compliance evolution".

[0093] This application, by introducing a full lifecycle management mechanism based on Task Control Blocks (TCBs) and combining real-time scheduling theory with ubiquitous computing technology, significantly overcomes the core defects of existing mobile health applications, such as "alarm overload," "mechanical interference," and "single point of failure." Specific beneficial effects are as follows: (1) It achieves "deterministic delivery" of medical-grade tasks, eliminating the risk of information overwhelmed under high concurrency. Traditional solutions rely on the operating system's native linear time triggering (such as AlarmManager), and use a "stack-style" display when multiple tasks are running concurrently, which makes it easy for high-risk emergency information to be squeezed out or covered by low-priority notifications.

[0094] This application utilizes a "dynamic weight drift algorithm based on urgency function" and a "UI mutex lock mechanism" to calculate the medical urgency of tasks in real time. Even under high system load, it ensures that PL1-level high-risk tasks (such as insulin injection) can forcibly preempt screen focus and suspend low-priority tasks, thereby guaranteeing zero-latency and unobstructed display of critical medical instructions.

[0095] (2) An adaptive intervention mechanism of "machine adapting to human" was constructed, which significantly reduced alarm fatigue. Traditional solutions employ a "blind triggering" mechanism, disturbing users at a fixed volume regardless of whether they are sleeping, in a meeting, or driving. This can easily trigger a negative reaction in users (closing the app) or a startle response (inducing cardiac risks).

[0096] This application utilizes "hierarchical decision tree-driven multimodal sensor fusion" technology, enabling the system to perceive user context within a millisecond-level window. For example, it employs "progressive light / sound wake-up" during deep sleep and automatically switches to "strong penetrating vibration" when the device is occluded by a pocket. This refined interference modulation significantly enhances the user experience and extends the lifespan and compliance of the health management system.

[0097] (3) A cross-terminal heterogeneous network "dead hand switch" was established to solve the security blind spot of single point of failure. Traditional apps operate on an "open-loop control" model. If a user's phone crashes, loses internet access, or is killed in the background by the system, the server cannot detect it, causing a break in the monitoring chain. This poses a fatal threat to elderly people living alone.

[0098] This application innovatively introduces a "cloud-based shadow countdown" mechanism. The cloud operates independently as a "watchdog," counting down the timer without relying on client reports. If the client loses contact (failing to send an ACK within the specified time), the cloud proactively triggers an alarm. Combined with an "SMS signaling channel degradation" strategy, even in extreme environments where data networks (WiFi / 4G) are paralyzed, alarm signals can still reach the guardian via GSM SMS.

[0099] (4) Possesses the system's self-evolution capability based on compliance feedback. This application, through compliance compensation, not only records task results but also uses knowledge graphs to analyze users' supplementary recording behavior (such as habitual postponement), and can dynamically adjust the scheduling parameters of subsequent tasks (such as reserving longer relaxation time), thereby achieving self-optimization of the scheduling strategy and enabling the system to better understand user needs the more it is used.

[0100] This application also provides an application scenario in which the task dynamic management method described above in a task management application is applied. Specifically, the task dynamic management method provided in this embodiment can be applied to a task dynamic management scenario in a health management application. This scenario includes a data acquisition stage and a data analysis stage; the data acquisition stage is used to obtain the static priority and dynamic attributes of each task in the task management application, which represent the importance of the task; the data analysis stage is used to calculate the urgency level of each task based on its static priority and dynamic attributes; and to execute the currently established tasks in the task management application according to their urgency levels. The task dynamic management method provided in this embodiment belongs to the data analysis stage.

[0101] In one exemplary embodiment, a computer device is provided, which may be a server or a terminal, and its internal structure diagram may be as follows. Figure 7 As shown, this computer device includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media. The database stores dynamic task management data for task management applications. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements a dynamic task management method for a task management application.

[0102] Those skilled in the art will understand that Figure 7The structures shown are merely block diagrams of some structures related to the present application and do not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than shown in the figures, or combine certain components, or have different component arrangements. In an exemplary embodiment, a computer device is provided, including a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0103] In one exemplary embodiment, a computer-readable storage medium is provided storing a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0104] In one exemplary embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0105] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Moreover, the collection, use and processing of the relevant data are carried out in compliance with the relevant data protection laws and policies of the country where the location is located, and with the authorization granted by the owner of the corresponding device.

[0106] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM).

[0107] The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0108] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0109] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. Furthermore, those skilled in the art will recognize that, based on the ideas of this application, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A dynamic task management method in a task management application, characterized in that, include: For each task in the task management application, build a task control block; Based on the task control block, obtain the static priority and dynamic attributes of each task in the task management application that represent the importance of the task; The urgency level of each task is calculated based on its static priority and dynamic attributes. Execute currently created tasks in the task management application based on their urgency level.

2. The task dynamic management method in the task management application according to claim 1, characterized in that, The formula for calculating the urgency level is: In the formula, Indicates the urgency level of task i; This represents the baseline score corresponding to the static priority of task i; This indicates the task reminder time set by the user; This indicates the number of times the task reminder has been retried before the user-defined reminder time. , , The adjustment coefficient is represented by t; t represents time t. This is a preset value.

3. The task dynamic management method in the task management application according to claim 1, characterized in that, The task dynamic management method in the task management application also includes: When a new task is created in the task management application, the urgency level of the new task is calculated. Determine whether the urgency level of the newly created task and the urgency level of the tasks currently displayed in the task management application meet the conditions for preempting the new task. If so, the context of the currently displayed task process is saved and pushed onto the suspend stack, and the newly created task is executed; when the newly created task releases the UI mutex lock, the suspended task is popped from the top of the suspend stack and resumed, and the task pushed onto the suspend stack continues to be executed. If not, then execute the tasks currently created in the task management application according to the urgency level of each task.

4. The task dynamic management method in the task management application according to claim 3, characterized in that, The conditions for securing a new mission are: In the formula, Indicates the urgency level of the newly created task; This indicates the current urgency level of the task being displayed; This indicates the image stabilization threshold.

5. The task dynamic management method in the task management application according to claim 1, characterized in that, Execute currently created tasks in the task management application based on their urgency level, specifically including: Acquire multi-dimensional sensing data from the carrier devices of task management applications; Based on multidimensional sensing data, a hierarchical decision tree is applied to determine the scenario in which the carrier device of the task management application is located; Based on the urgency level of the task and the current scenario of the carrier device, the corresponding preset adaptive intervention strategy is selected to execute the currently established task in the task management application; in the preset adaptive intervention strategy, the strategy used to execute the task will be different depending on the scenario of the carrier device and the urgency level of the task. Obtain historical user feedback information for each task, and determine the feedback delay status of the corresponding task based on the historical user feedback information; Adjust the urgency level of the corresponding task based on the feedback and delays.

6. The task dynamic management method in a task management application according to claim 1 or 5, characterized in that, The task dynamic management method in the task management application also includes: Determine whether user feedback information has been received to obtain the first determination result; user feedback information refers to the user's feedback information on the executed tasks in the task management application; If the first judgment result is yes, then an ACK packet is sent to the cloud through the task management application, and the cloud cancels the shadow countdown timer that was built. The shadow countdown timer is a shadow countdown timer built in the cloud for each task when a task is generated in the task management application. If the first judgment result is negative, check whether the shadow countdown timer of the executed task has returned to zero to obtain the second judgment result; If the second judgment result is negative, then the tasks currently created in the task management application will be executed according to the urgency level of each task. If the second judgment result is yes, the cloud-based shadow countdown timer will be canceled, and an alarm will be sent to the guardian of the user to whom the task management application belongs.

7. The task dynamic management method in the task management application according to claim 6, characterized in that, Send an alert to the guardian of the user who owns the task management application, specifically including: Send network detection data to the carrier device of the task management application via MQTT / HTTP long connection to confirm whether the carrier device's IP-based data channel is abnormal; If the IP-based data channel is abnormal, the signaling degradation strategy will be automatically triggered, the alarm message will be encapsulated, and the system will switch to the GSM / CDMA signaling channel. The alarm message will then be transmitted to the guardian terminal of the user to which the task management application belongs via the GSM / CDMA signaling channel.

8. A computer device, comprising: A memory, a processor, and a computer program stored in the memory and capable of running on the processor, characterized in that the processor executes the computer program to implement the task dynamic management method in the task management application according to any one of claims 1-7.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the dynamic task management method in the task management application as described in any one of claims 1-7.

10. A computer program product, comprising a computer program, characterized in that, When executed by a processor, the computer program implements the dynamic task management method in the task management application as described in any one of claims 1-7.

Images