Implementation method and device of js timer

Abstract

This invention discloses a method for implementing a JS timer, comprising the following steps: Step S1: In a lightweight open-source HarmonyOS system, a JavaScript application creates a JS timer, which specifies a timing period and a callback function. Step S2: The JS timer is added as a task timer in the lightweight open-source HarmonyOS system, and executed by the task management module. Step S3: When the timing period of the task timer expires, an asynchronous message is sent to the JS APP thread, which then executes the asynchronous callback upon receiving the message. This invention automatically stops the JS timer when the device enters a low-power screen-off state, reducing unnecessary system wake-ups and saving device power. If the JS APP thread is busy, the JS timer cannot be scheduled and will not send unprocessable asynchronous messages, avoiding the problem of system crashes due to a full message queue and improving system robustness.

Description

Technical Field

[0001] This invention relates to the field of embedded technology, and in particular to an implementation method of a JS timer for a lightweight open-source HarmonyOS system. Background Technology

[0002] OpenHarmony is an open-source operating system for embedded devices, while HarmonyOS is a commercial operating system for smartphones.

[0003] The open-source HarmonyOS kernel has three branches: LiteOS-M, LiteOS-A, and Linux. The open-source HarmonyOS systems with LiteOS-M and LiteOS-A branches are called lightweight open-source HarmonyOS systems, which are suitable for use in Internet of Things (IoT) devices, home appliances, sensors, microcontrollers (MCUs), and small terminals. Application examples include smartwatches, switches, remote controls, blood pressure monitors, etc.

[0004] In the lightweight, open-source HarmonyOS system, JavaScript applications can only run through a JavaScript virtual machine (also known as a JavaScript engine). The JavaScript virtual machine (such as JerryScript) runs in the JS APP thread.

[0005] The lightweight, open-source HarmonyOS system creates a JS APP thread as the main UI (user interface) thread upon startup, and initializes multiple modules within this thread to support UI rendering and event handling. Please refer to [link / reference]. Figure 1 The existing modules executing on the JS APP thread include the JavaScript Virtual Machine, the JSAppTaskHandler (JavaScript application task handler) module, the foreground management module, the background management module, the task manager module, and the asynchronous message processing module (AYNCWORK). The JSAppTaskHandler module acts as a bridge between the JavaScript Virtual Machine and the foreground, background, task, and asynchronous message processing modules, primarily responsible for coordinating the interaction between the JavaScript application and other tasks. The foreground processing module is scheduled when the JSAppTaskHandler module receives an ACTIVE message. The background processing module is scheduled when the JSAppTaskHandler module receives a BACKGOUNRD message. The task management module time-division multiplexes the JS APP thread, scheduling each task serially and without contention, sequentially scheduling the input management module, animation management module, and rendering management module to execute tasks. The asynchronous message processing module processes asynchronous messages (AYNCWORK) accordingly upon receipt.

[0006] In the lightweight open-source HarmonyOS system, there is a software timer called SwtTimer driven by the system clock (systick). SwtTimer is used to trigger callback functions at specified times or periods and is the foundation for various timing functions at the application and system layers. Timers created by JavaScript applications are called JS timers, which specify a timing period and a callback function. Adding JS timers to the SwtTimer in the existing lightweight open-source HarmonyOS system raises the following two issues.

[0007] First, the SwtTimer includes not only the JS timer but also other system-level timers. Because it includes system-level timers, the SwtTimer has the ability to wake up the lightweight open-source HarmonyOS system, which incurs additional power consumption. When an embedded device using the lightweight open-source HarmonyOS system enters a low-power screen-off state, the JavaScript application remains in the foreground, and the JS timer remains attached to the SwtTimer's linked list. When the JS timer's timing cycle expires, it wakes up the lightweight open-source HarmonyOS system. The JavaScript application and JS timer are primarily used to render the embedded device's user interface. Waking up the embedded device in screen-off state to redraw the user interface is meaningless and only adds to the embedded device's power consumption.

[0008] Secondly, the JavaScript timer within the SwtTimer notifies the JavaScript application thread to execute its callback function via asynchronous messages. The SwtTimer has a high thread priority, while the JavaScript application thread has a low priority. Sending messages from a high-priority thread to a low-priority thread makes stable operation difficult and results in poor robustness. If the JavaScript application thread is busy and receives many asynchronous messages from the JavaScript timer within the SwtTimer, the JavaScript application thread may not be able to process them all. The accumulated asynchronous messages may exceed the message queue length, causing a system crash due to a full message queue. Summary of the Invention

[0009] The technical problem to be solved by this invention is: how to implement a lightweight open-source JS timer in HarmonyOS that can achieve both low power consumption and improved robustness.

[0010] To address the aforementioned technical problems, this invention proposes a method for implementing a JS timer, comprising the following steps: Step S1: In the lightweight open-source HarmonyOS system, the JavaScript application creates a JS timer, which specifies a timing period and a callback function. Step S2: The JS timer is added as a task timer in the lightweight open-source HarmonyOS system, and executed by the task management module. Step S3: When the timing period of the task timer expires, the JS APP thread is notified via an asynchronous message. Upon receiving the asynchronous message, the JS APP thread executes the asynchronous callback.

[0011] Furthermore, in step S2, the callback function of the task timer sends an asynchronous message to the JS APP thread, and the callback function of the asynchronous message is executed in the context of the JS APP thread.

[0012] Furthermore, in step S2, a task timer scheduling module is added to the task management module to be responsible for executing the task timer.

[0013] Furthermore, in step S2, when a device using the lightweight open-source HarmonyOS system enters a low-power screen-off state, the task management module stops working, the task timer scheduling module in the task management module also automatically stops working, and the task timer automatically stops.

[0014] Furthermore, in step S2, the TEEVENT message is a message that triggers the redrawing of the user interface in the lightweight open-source HarmonyOS system; if the screen is off, the user interface does not need to be updated, and the TEEVENT message also stops being sent; whether the TEEVENT message stops being sent is used as the basis for determining whether the embedded device has entered a low-power screen-off state.

[0015] Furthermore, in step S2, the front-end processing module adds the newly created JS timer as a task timer, and the back-end management module deletes the task timer.

[0016] Furthermore, in step S2, if the JS timer is a timer that ends after one execution, the task timer is deleted by the background management module after the JS timer finishes executing the callback function.

[0017] Furthermore, in step S3, executing the asynchronous callback refers to executing the callback function of the JS timer in the context of the JS APP thread.

[0018] Furthermore, in step S3, when the JS APP thread is busy with work outside the task management module, the JP APP thread has no time to schedule the task management module and must wait until the JS APP thread is idle before it can resume scheduling the task management module; during the period when the task management module is not scheduled, the task timer cannot be executed, and even if the timing period of the JS timer has expired, it will not send an asynchronous message to the JS APP thread.

[0019] This invention also proposes an implementation device for a JS timer, including a JS timer creation unit, a task timer addition unit, and a task timer execution unit. The JS timer creation unit is used to create a JS timer in a lightweight open-source HarmonyOS system, specifying a timing period and a callback function. The task timer addition unit is used to add the JS timer as a task timer in the lightweight open-source HarmonyOS system, which is executed by the task management module. The task timer execution unit is used to notify the JS APP thread via an asynchronous message when the timing period of the task timer has expired. Upon receiving the asynchronous message, the JS APP thread executes the asynchronous callback.

[0020] The technical advantages achieved by this invention are: when a device using the lightweight open-source HarmonyOS system enters a low-power screen-off state, the JS timer automatically stops, reducing unnecessary system wake-ups and significantly saving device power consumption. If the JS APP thread is busy, the JS timer cannot be scheduled, preventing the issuance of unprocessable asynchronous messages, thus avoiding system crashes due to a full message queue and improving system robustness. Attached Figure Description

[0021] Figure 1 This is a diagram illustrating the initialization of multiple modules within a single thread in an existing JavaScript app.

[0022] Figure 2 This is a flowchart illustrating the implementation method of the JS timer proposed in this invention.

[0023] Figure 3 This is a schematic diagram illustrating the initialization of multiple modules within a single thread of the JS APP according to the present invention.

[0024] Figure 4 This is a schematic diagram of the structure of the JS timer implementation device proposed in this invention.

[0025] The attached diagrams are labeled as follows: JS timer creation unit 1, task timer addition unit 2, and task timer execution unit 3. Detailed Implementation

[0026] Please see Figure 2 The implementation method of the JS timer proposed in this invention includes the following steps.

[0027] Step S1: In the lightweight open-source HarmonyOS system, the JavaScript application creates a JS timer, which specifies a timing period and a callback function.

[0028] Step S2: Add the JS timer as a task timer (TETimer) in the lightweight open-source HarmonyOS system, which is executed by the task management module. The callback function of the task timer sends an asynchronous message to the JS APP thread, and the callback function of this asynchronous message is executed in the context of the JS APP thread.

[0029] The task management module is an existing module in the lightweight open-source HarmonyOS system. Its characteristic is that when an embedded device using the lightweight open-source HarmonyOS system enters a low-power screen-off state, the task management module stops working. This step adds a JS timer as a task timer. When the embedded device using the lightweight open-source HarmonyOS system enters a low-power screen-off state, the task management module stops working, and the task timer scheduling module within the task management module also automatically stops working. Therefore, the task timer automatically stops, preventing the lightweight open-source HarmonyOS system from waking up and reducing the power consumption of the embedded device.

[0030] Step S3: When the task timer's timeout period has expired, the JS APP thread is notified via an asynchronous message. After receiving the asynchronous message, the JS APP thread executes the asynchronous callback, that is, the callback function of the JS timer is executed in the context of the JS APP thread.

[0031] In this step, if the JS App thread is busy working on other modules outside the task management module, the JP App thread doesn't have time to schedule the task management module. It must wait until the JS App thread becomes idle before resuming task management. While the task management module is not being scheduled, the task timer will not execute, and even if the JS timer's timeout period has expired, it will not send an asynchronous message to the JS App thread. This prevents the JS timer from crashing due to a full asynchronous message queue.

[0032] In step S2, the front-end processing module adds the newly created JS timer as a task timer, and the back-end management module deletes the task timer. For example, if the JS timer is a timer that ends after one execution, the back-end management module deletes the task timer after the JS timer has finished executing its callback function.

[0033] In step S2, this invention adds a task timer scheduling module to the task management module, which is responsible for executing the task timers. Please refer to [link / reference]. Figure 3The modules executed on the JS APP thread of this invention include a JavaScript virtual machine, a JSAppTaskHandler module, a front-end management module, a back-end management module, a task management module, and an asynchronous message processing module. Among them, the task management module time-division multiplexes the JS APP thread, scheduling each task serially and without contention, and sequentially scheduling the input management module, task timer scheduling module, animation management module, and rendering management module to execute tasks.

[0034] Please see Figure 4 The implementation device for the JS timer proposed in this invention includes a JS timer creation unit 1, a task timer addition unit 2, and a task timer execution unit 3. Figure 4 The device shown corresponds to Figure 2 The method shown.

[0035] The JS timer creation unit 1 is used to create JS timers in the lightweight open-source HarmonyOS system. The JS timers specify a timing period and a callback function.

[0036] The task timer adding unit 2 is used to add the JS timer as a task timer in the lightweight open-source HarmonyOS system, which is executed by the task management module.

[0037] The task timer execution unit 3 is used to notify the JS APP thread via an asynchronous message when the timer period has expired. After receiving the asynchronous message, the JS APP thread executes an asynchronous callback.

[0038] In the existing lightweight open-source HarmonyOS system, the JS timer is managed by the SwtTimer software timer, which is driven by the native system clock. The SwtTimer timer is an interrupt-driven timer; once a timed task is attached, an interrupt will occur when the timer expires, waking the system up once via hardware.

[0039] This invention replaces the JS timer with a task timer scheduling mechanism driven by TEEVENT messages in the lightweight open-source HarmonyOS system. TEEVENT messages trigger the redrawing of the user interface in the lightweight open-source HarmonyOS system. If the screen is off, the user interface does not need to be updated, and TEEVENT messages stop being sent. Therefore, whether TEEVENT messages stop being sent can be used as the criterion for determining whether the embedded device has entered a low-power screen-off state. The task timer scheduling mechanism is a mechanism where the JS APP thread actively queries tasks. If the JS APP thread is in a normal working state, it calls the task manager to execute various tasks, including the task timer, in a time-division multiplexing manner. If the JS APP thread is in a low-power suspended state, it cannot call the task manager to execute any tasks. Therefore, suspending the JS timer under the task timer does not cause the problem of waking up the system in a low-power state, thus reducing power consumption. When the JS APP thread is busy, such as busy drawing the user interface, the JP APP thread does not have time to call the task manager to execute any tasks and must wait until the JP APP thread is idle before it can call the task manager to execute tasks. Therefore, busy JS application threads will not receive any asynchronous messages triggered by JS timers, avoiding the message queue fullness and crashes that occur when high-priority threads send messages to low-priority threads in native code, thus improving robustness. Furthermore, this invention requires minimal code changes to the lightweight open-source system, achieving the beneficial effects of low power consumption without system wake-ups and no accumulation of asynchronous messages with minimal code modifications.

[0040] The above are merely preferred embodiments of the present invention and are not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for implementing a JS timer, characterized in that, Includes the following steps; Step S1: In the lightweight open-source HarmonyOS system, the JavaScript application creates a JS timer, which specifies a timing period and a callback function; Step S2: Add the JS timer as a task timer in the lightweight open-source HarmonyOS system, which will be executed by the task management module; Step S3: When the task timer's timeout period has expired, the JS APP thread is notified via an asynchronous message. Upon receiving the asynchronous message, the JS APP thread executes the asynchronous callback.

2. The method of claim 1, wherein the JS timer is implemented by, In step S2, the callback function of the task timer sends an asynchronous message to the JS APP thread, and the callback function of the asynchronous message is executed in the context of the JS APP thread.

3. The method of claim 1, wherein the JS timer is implemented by a software timer. In step S2, a new task timer scheduling module is added to the task management module, which is responsible for executing the task timer.

4. The method of claim 3, wherein the JS timer is implemented by, In step S2, when a device using the lightweight open-source HarmonyOS system enters a low-power screen-off state, the task management module stops working, the task timer scheduling module in the task management module also stops working automatically, and the task timer stops automatically.

5. The method of claim 4, wherein the JS timer is implemented by, In step S2, the TEEVENT message is a message that triggers the redrawing of the user interface in the lightweight open-source HarmonyOS system; if the screen is off, the user interface does not need to be updated, and the TEEVENT message will stop being sent. Whether the TEEVENT message stops being sent is used as the criterion for determining whether the embedded device enters a low-power screen-off state.

6. The method of claim 1, wherein the JS timer is implemented by a software timer. In step S2, the front-end processing module adds the newly created JS timer as a task timer, and the back-end management module deletes the task timer.

7. The method of claim 6, wherein the JS timer is implemented by, In step S2, if the JS timer is a timer that ends after one execution, the task timer is deleted by the backend management module after the JS timer finishes executing the callback function.

8. The method of claim 1, wherein the JS timer is implemented by a software timer. In step S3, executing an asynchronous callback means executing the callback function of the JS timer in the context of the JS APP thread.

9. The method of claim 1, wherein the JS timer is implemented by, In step S3, when the JS APP thread is busy with non-task management module work, the JP APP thread has no time to schedule the task management module and must wait until the JS APP thread is idle before it can resume scheduling the task management module. While the task management module is not scheduled, the task timer will not be executed, and even if the JS timer's timeout period has expired, it will not send an asynchronous message to the JS APP thread.

10. A JavaScript timer implementation device, characterized in that, This includes a JS timer creation unit, a task timer addition unit, and a task timer execution unit; The JS timer creation unit is used to create JS timers in the lightweight open-source HarmonyOS system. The JS timers specify a timing period and a callback function. The task timer adding unit is used to add the JS timer as a task timer in the lightweight open-source HarmonyOS system, which is executed by the task management module. The task timer execution unit is used to notify the JSAPP thread via an asynchronous message when the task timer's timing period has expired. Upon receiving the asynchronous message, the JSAPP thread executes an asynchronous callback.

Images