JS running environment snapshot caching method suitable for RTOS

Abstract

The invention discloses a JS running environment snapshot caching method suitable for RTOS, which comprises the following steps: when a page needs to be cached, storing key running data of a running environment of a to-be-cached page in a memory; receiving a page switching request for switching from a current page to a target page, and judging whether cached key operation data corresponding to the target page exists in a memory or not; if yes, directly multiplexing the cached key operation data; if not, key operation data of an operation environment is created and initialized for the target page; asynchronously scheduling the page switching request into an asynchronous task queue, and executing an asynchronous task; when the target page needs to be hidden, the target page enters a display state to be displayed, and when the target page needs to be hidden, the target page enters a background state; and when the target page needs to be destroyed, entering a destroying state, and releasing all the running environment resources and memory occupied by the target page. According to the method, the page loading time can be shortened, and the occupation of system resources is reduced.

Description

Technical Field

[0001] This invention relates to the field of environment caching technology, and in particular to a snapshot caching method for a JavaScript runtime environment suitable for RTOS. Background Technology

[0002] With the widespread application of embedded devices, Real-Time Operating Systems (RTOS) have been widely adopted in fields such as the Internet of Things (IoT), smart homes, and wearable devices. JavaScript, as a high-efficiency and flexible scripting language, is also gradually being introduced into embedded devices due to its cross-platform compatibility and rich ecosystem, used for implementing dynamic page rendering and interactive logic. However, due to the limited hardware resources of embedded devices, especially memory constraints, there are some technical bottlenecks when running JavaScript pages on these devices.

[0003] In existing technologies, embedded devices typically employ traditional JavaScript runtime environments. These environments require a series of complex initialization operations during page loading, including parsing JavaScript code, building the execution context, binding page parameters, and style managers. Due to limited hardware resources, particularly memory, embedded devices experience significant time consumption and memory depletion during the loading and initialization of complex JavaScript pages, resulting in inefficient page loading and a poor user experience. This is especially true in scenarios with frequent page transitions, where each transition necessitates reloading and initialization, further exacerbating system resource consumption.

[0004] To improve page loading efficiency, some existing technologies attempt to optimize performance through page caching mechanisms. For example, some static resources of the page (such as HTML templates and CSS stylesheets) are cached in memory to reduce the time spent on repeated loading. However, this method is limited to caching static resources and cannot effectively save and restore the dynamic state of the JavaScript runtime environment (such as execution context and page lifecycle state). Therefore, when switching pages or resuming, the JavaScript runtime environment still needs to be reloaded and initialized, further increasing system resource consumption and response time, and failing to fundamentally solve the problem of low loading efficiency.

[0005] Furthermore, existing technologies have other shortcomings. For example, traditional page caching mechanisms often lack fine-grained management of page state, resulting in low memory resource utilization. Simultaneously, on memory-constrained embedded devices, frequent memory allocation and deallocation operations can lead to memory fragmentation, further reducing system stability and performance.

[0006] In summary, existing technologies for running JavaScript pages on embedded devices mainly have the following problems: 1. Low page loading efficiency and long initialization time affect user experience; 2. The caching mechanism is limited to static resources and cannot save or restore the dynamic state of the JavaScript runtime environment; 3. Lack of granular management of page state, resulting in low memory resource utilization; 4. Memory allocation and deallocation operations may cause memory fragmentation problems, reducing system stability. Summary of the Invention

[0007] In view of this, the purpose of this invention is to propose a snapshot caching method for JS runtime environment suitable for RTOS, which effectively solves the problems of low JavaScript page loading efficiency and high resource consumption in embedded devices under memory-constrained environments, and provides an efficient and reliable solution for JavaScript page management in real-time operating systems.

[0008] To achieve the above-mentioned technical objectives, the technical solution adopted by this invention is as follows: This invention provides a snapshot caching method for a JavaScript runtime environment suitable for RTOS, comprising the following steps: Step 1: When a JavaScript page needs to be cached, the critical runtime data of the JavaScript page's runtime environment is stored in the RTOS memory to form a memory snapshot; Step 2: Upon receiving a page switching request from the current JavaScript page to the target JavaScript page, determine whether there is cached critical runtime data corresponding to the target JavaScript page in the RTOS memory; Step 3: If yes, then directly reuse the cached critical runtime data; if no, then create and initialize the critical runtime data of the runtime environment for the target JavaScript page. Step 4: Asynchronously schedule the page switching request to the asynchronous task queue and execute the asynchronous task; Step 5: Display the target JavaScript page; when it needs to be hidden, Put the target JavaScript page into the background. Step 6: When the target JavaScript page needs to be destroyed, enter the destruction state and release all runtime environment resources and memory occupied by the target JavaScript page.

[0009] Furthermore, step 1 specifically includes: Step 11: When a JavaScript page needs to be cached, obtain the key runtime data of the JavaScript page's runtime environment. The key runtime data includes at least the state machine object, JavaScript execution context, page lifecycle state, style manager, and page routing parameters. Step 12: Take the key runtime data of the runtime environment as the subject of the snapshot, and keep it in the RTOS memory in the form of a memory object instance to form a memory snapshot; Step 13: Associate the key runtime data with the identifier of the JavaScript page and store it in the RTOS memory. Maintain a cache mapping table through the routing manager. The cache mapping table is used to store the association between the identifier of the JavaScript page and the corresponding key runtime data.

[0010] Furthermore, the state machine object refers to a pattern that uses a state machine to manage the page state; The JavaScript execution context stores the JavaScript object instance corresponding to the JavaScript page, including the page's reactive data, member variables, and bound function methods, and maintains its reference in the JavaScript engine heap memory during the memory snapshot residency period; The page lifecycle state refers to the current lifecycle state of a JavaScript page, including undefined state, initialization state, ready state, displayed state, background state, and destroyed state. The style manager refers to the style information of a JavaScript page, including static CSS rules and dynamically calculated styles; The page routing parameters refer to the dynamic data set passed during page navigation, used to configure the initial state and behavior of the page.

[0011] Furthermore, step 2 specifically includes: Step 21: Receive a page switching request initiated by the user to switch from the current JavaScript page to the target JavaScript page, wherein the page switching request carries the identifier of the target JavaScript page; Step 22: Call the page switching function. First, based on the identifier of the target JavaScript page, query the cache mapping table in the RTOS memory to see if the key runtime data matches the identifier of the target JavaScript page. Step 23: Determine whether there is cached critical runtime data in the RTOS memory associated with the identifier of the target JavaScript page based on the query results.

[0012] Furthermore, step 3 specifically includes: Step 31: If the RTOS memory contains cached critical runtime data corresponding to the target JavaScript page, then directly reuse the state machine object in the critical runtime data and update the page routing parameters; Step 32: If the RTOS does not have cached critical runtime data corresponding to the target JavaScript page in memory, a new state machine object is created. The state machine initializes the runtime environment of the target JavaScript page. Specific operations include: binding page route parameters and style manager; generating the JavaScript file path of the target JavaScript page and loading and parsing the JavaScript code; and calling the page lifecycle callback function onInit to complete the initialization of the target JavaScript page.

[0013] Furthermore, step 4 specifically includes: Distribute the page switching request to the asynchronous task queue, release the JavaScript execution context in the current JavaScript page, and wait for the task to be executed; The asynchronous task queue is managed by the asynchronous task manager and adopts a first-in-first-out queue model to serialize the corresponding operations.

[0014] Furthermore, the operations performed by the asynchronous task manager include at least: Parse and execute JavaScript scripts: Call the EvalPage function to load the JavaScript file of the target JavaScript page and construct the ViewModel object; Building the component tree: Call the RenderPage function to execute the rendering function based on the data of the ViewModel object, and recursively create the native component tree and document object model structure of the C++ layer; Style Calculation and Layout: Parse CSS stylesheets and calculate the geometric properties and hierarchical relationships of components; Garbage collection: After the JavaScript page has finished rendering, clean up the unused objects left over from the old page and release heap memory.

[0015] Furthermore, a state machine pointer is maintained inside the route manager to indicate whether the current state is in the transitional state of page construction. During the dispatch and execution of asynchronous tasks, the state machine pointer remains non-empty. When all asynchronous tasks have been completed and the new page is ready, the state is cleaned up and the state machine pointer is set to empty. When a page switching request is initiated, the state machine pointer maintained internally by the route manager is checked. If the state machine pointer is null, it indicates that there is no asynchronous page building task currently being executed. The state machine pointer is immediately set to point to the state machine object that will be created for the page switching request, and the current page switching request is received and executed. If the state machine pointer is not null, it indicates that the previous asynchronous page building task has not yet been completed. The current repeated page switching request will be directly intercepted and rejected, and an error code will be returned.

[0016] Furthermore, step 5 specifically includes: Step 51: The asynchronous task queue starts executing page switching tasks. During the lifecycle of the target JavaScript page, the state change method of the state machine is called to manage the state of the target JavaScript page through the state machine. Step 52: The state machine switches the state of the target JavaScript page from the initialization state to the ready state and performs the following operations: calls the page rendering function to complete the rendering of the target JavaScript page. After rendering is complete, calls the page lifecycle callback function onReady to notify the target JavaScript page that it is ready. Step 53: The state machine continues to switch the state of the target JavaScript page from the ready state to the display state, and performs the following operations: calls the page display function to render the target JavaScript page on the screen, and calls the page lifecycle callback function onShow to notify the target JavaScript page that it has been displayed; Step 54: When the target JavaScript page needs to be hidden, the state machine changes the state of the target JavaScript page from the display state to the background state and completes the following operations: The state machine calls the page hiding function to move the target JavaScript page from the foreground to the background. At the same time, it triggers the page lifecycle callback function onHide to notify the JavaScript page that it has entered the background. Step 55: When the target JavaScript page needs to switch from the background state to the display state, in the background state, the state machine restores the style and display state of the target JavaScript page, calls the page display function to re-render the target JavaScript page, and calls the page lifecycle callback function onShow to notify the target JavaScript page that it has been restored from the background to the foreground.

[0017] Furthermore, step 6 specifically includes: Step 61: Determine whether the target JavaScript page needs to be kept in RTOS memory. If not, proceed to step 62; if yes, proceed to step 63. Step 62: The state machine switches the target JavaScript page from the background state to the destruction state. The normal state includes the initialization state, the ready state, the display state, and the background state. In the destruction state, the state machine performs cleanup operations on the target JavaScript page resources, including releasing the target JavaScript page's runtime environment, destroying the style manager, and reclaiming memory. At the same time, it triggers the page lifecycle callback function onDestroy to notify the target JavaScript page that it has been destroyed. Step 63: Keep the target JavaScript page in the background.

[0018] By adopting the above technical solution, the present invention has the following beneficial effects compared with the prior art: By designing a state machine-based page management method combined with a caching mechanism, the page's runtime state and context information are serialized and stored in memory. When the page needs to be restored, the serialized data is directly loaded from the cache, avoiding repeated initialization operations. This method not only reduces page load time but also lowers system resource consumption, improving the stability and user experience of embedded devices running complex JavaScript pages.

[0019] 1. Significantly Improved Page Loading and Switching Efficiency: This invention achieves rapid saving and restoration of the execution context by serializing and caching the JavaScript runtime environment, avoiding the repetitive script parsing and compilation processes in traditional methods, thereby significantly improving the efficiency of page switching and restoration. On RTOS platforms, this method can greatly shorten page startup time and improve system response speed and user interaction smoothness.

[0020] 2. Enhanced System Flexibility: Supports dynamic page loading and caching, and combined with state machines and snapshot mechanisms, it can flexibly adapt to different page switching scenarios. This enhances the system's flexibility and operability, enabling embedded devices to support more complex JavaScript page management needs.

[0021] 3. Page Lifecycle Management: A state machine enables fine-grained management of the page lifecycle, including initialization, ready, display, background, and destruction states, ensuring clear transition logic between different states. This improves the modularity and maintainability of page management, avoids state confusion, and ensures the stability of page transitions.

[0022] 4. Effectively reduces memory usage and resource overhead: This invention achieves runtime state reuse and sharing through a snapshot caching mechanism, avoiding frequent creation and destruction of the JS runtime engine, thereby reducing memory fragmentation and resource duplication issues. This solution can significantly reduce the system's peak heap memory usage and garbage collection frequency, improving system stability and resource utilization.

[0023] This invention implements an efficient JavaScript page management mechanism on embedded devices, which significantly improves system performance and user experience, and has broad application value. Attached Figure Description

[0024] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, 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 the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0025] Figure 1 This is an execution flowchart of a snapshot caching method for a JS runtime environment suitable for RTOS, provided by an embodiment of the present invention.

[0026] Figure 2 This is a schematic diagram of the state machine management state transition of a JavaScript page provided in an embodiment of the present invention.

[0027] Figure 3 This is a schematic diagram of the JavaScript page switching process provided in an embodiment of the present invention. Detailed Implementation

[0028] The present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be particularly noted that the following embodiments are for illustrative purposes only and do not limit the scope of the invention. Similarly, the following embodiments are only some, not all, embodiments of the present invention, and all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0029] Please see Figures 1-3 This invention provides a snapshot caching method for a JavaScript runtime environment suitable for RTOS. By constructing a serializable JavaScript runtime environment storage mechanism, it enables rapid saving and restoration of the JavaScript execution context, thereby significantly improving the efficiency of page switching and restoration; it includes the following steps: Step 1: When a JavaScript page needs to be cached, the critical runtime data of the JavaScript page's runtime environment is stored in the RTOS memory to form a memory snapshot; In this embodiment, step 1 specifically includes: Step 11: When a JavaScript page needs to be cached, obtain the key runtime data of the JavaScript page's runtime environment. The key runtime data includes at least the State Machine object, JavaScript execution context, page lifecycle state, StyleManager, and page routing parameters. The state machine object refers to a pattern that uses a state machine to manage the state of a page. The JavaScript execution context stores the JavaScript object instance corresponding to the JavaScript page, including the page's reactive data, member variables, and bound function methods, and maintains its reference in the JavaScript engine heap memory during the memory snapshot residency period, ensuring that variable scope, closure state, and user input data are not lost; The page lifecycle state refers to the current lifecycle state of a JavaScript page, including undefined state, initialization state, ready state, displayed state, background state, and destroyed state. The style manager refers to the style information of a JavaScript page, including static CSS rules and dynamically calculated styles; The page routing parameters refer to the dynamic data set passed during page navigation, used to configure the initial state and behavior of the page.

[0030] Step 12: Take the key runtime data of the runtime environment as the subject of the snapshot, and keep it in the RTOS memory in the form of a memory object instance (C++ object instance) to form a memory snapshot, and keep the memory object instance from being destroyed; Step 13: The critical runtime data is associated with the JavaScript page identifier and stored in RTOS memory. A cache mapping table is maintained by the routing manager. This cache mapping table stores the association between the JavaScript page identifier and the corresponding critical runtime data. The purpose is to directly reuse the corresponding critical runtime data in RTOS memory through the cache mapping table when the page is restored, without re-parsing the JS (JavaScript) script or rebuilding the JavaScript execution context, thereby achieving instantaneous restoration of the execution environment.

[0031] Step 2: Upon receiving a page switching request from the current JavaScript page to the target JavaScript page, determine whether there is cached critical runtime data corresponding to the target JavaScript page in the RTOS memory; In this embodiment, step 2 specifically includes: Step 21: Receive a page switching request initiated by the user to switch from the current JavaScript page to the target JavaScript page, wherein the page switching request carries the identifier of the target JavaScript page; Step 22: Call the page switching function (its purpose is to perform a series of operations in steps 22-6 to switch from the current JavaScript page to the target JavaScript page). First, based on the identifier of the target JavaScript page, query the cache mapping table in the RTOS memory to see if it matches the identifier of the target JavaScript page. Step 23: Determine whether there is cached critical runtime data in the RTOS memory associated with the identifier of the target JavaScript page based on the query results.

[0032] Step 3: If yes, then directly reuse the cached critical runtime data; if no, then create and initialize the critical runtime data of the runtime environment for the target JavaScript page. In this embodiment, step 3 specifically includes: Step 31: If the RTOS memory contains cached critical runtime data corresponding to the target JavaScript page, the state machine object in the critical runtime data is directly reused, and the page routing parameters are updated. During the recovery process, the state machine object of the target JavaScript page does not perform the process of creating a new state machine object or initializing the runtime environment of the target JavaScript page, thereby improving page switching efficiency. Step 32: If the RTOS does not have cached critical runtime data corresponding to the target JavaScript page in memory, a new state machine object is created. The state machine initializes the runtime environment of the target JavaScript page. Specific operations include: binding page route parameters and style manager; generating the JavaScript file path of the target JavaScript page and loading and parsing the JavaScript code; and calling the page lifecycle callback function onInit to complete the initialization of the target JavaScript page.

[0033] Step 4: Asynchronously schedule the page switching request to the asynchronous task queue and execute the asynchronous task; In this embodiment, step 4 specifically includes: Dispatch the page switching request to the asynchronous task queue, release the JavaScript execution context in the current JavaScript page, and wait for the task to be executed; The asynchronous task queue is managed by the asynchronous task manager, employing a first-in-first-out (FIFO) queue model for serializing corresponding operations. Task serialization: The asynchronous task manager (AsyncTaskManager) uses a FIFO queue model. Even if a new request arrives and passes the initial check before the previous task is completed, it will be placed in the queue to wait instead of being executed immediately. This ensures serialization at the scheduling level, guaranteeing that only one routing task runs in the execution context at any given time, fundamentally eliminating concurrent write conflicts to the page stack and the current state machine. Asynchronous processing of page switching and recovery is achieved through the asynchronous task manager, avoiding blocking the main thread and improving system response speed. This invention uses the asynchronous task manager (AsyncTaskManager) to achieve asynchronous processing of page routing operations, separating the high-load page building process from user interaction responses.

[0034] The operations performed by the asynchronous task manager include at least the following: Parse and execute JavaScript scripts: Call the EvalPage function to load the JavaScript file of the target JavaScript page and construct the ViewModel object; Building the component tree: Call the RenderPage function to execute the rendering function based on the data of the ViewModel object, and recursively create the native component tree and document object module (DOM) structure of the C++ layer; Style Calculation and Layout: Parse CSS stylesheets and calculate the geometric properties (position, size) and hierarchical relationships of components; Garbage collection: After the JavaScript page has finished rendering, it cleans up unused objects left over from the old page and releases heap memory. If these operations are performed synchronously on the main thread, it will cause significant frame drops or stuttering, so an asynchronous strategy is required.

[0035] Performance comparison between asynchronous design and synchronous switching Improved response time: Synchronous mode: After the user clicks the button, the UI thread is completely blocked by the page loading logic. Until the new page is rendered, the screen cannot respond to any touch events, which can easily create the illusion of a "crash".

[0036] Asynchronous mode: The moment the user clicks, the page switching request only performs parameter validation and returns immediately, while the UI thread continues to respond to system interruptions or draw loading animations. The page loading task is executed in the next idle time slice, achieving an "instant response" interactive experience.

[0037] Real-time performance guarantee: In an RTOS environment, prolonged occupation of the main loop can lead to watchdog timeout or starvation of low-priority tasks. The asynchronous scheduling of this invention breaks down large page loading tasks into independent task units, allowing the system to handle higher-priority hardware interrupts or system events between tasks, thereby ensuring the system-level real-time performance of the device.

[0038] To prevent resource contention caused by frequent user clicks or concurrent tasks during asynchronous operations (such as creating multiple state machines simultaneously), this invention designs a mutual exclusion mechanism based on state guards: In this embodiment, a state machine pointer (newSm_) is maintained inside the router. The state machine pointer is used to identify whether the current state is in the transition state of page construction. During the dispatch and execution of asynchronous tasks, the state machine pointer is kept in a non-empty state. When all asynchronous tasks are completed and the new page is ready, the state is cleaned up and the state machine pointer is set to empty. When a page switching request is initiated, the state machine pointer maintained internally by the route manager is checked. If the state machine pointer is null, it indicates that there is no asynchronous page building task currently being executed. The state machine pointer is immediately set to point to the state machine object that will be created for the page switching request, and the current page switching request is received and executed. If the state machine pointer is not null, it indicates that the previous asynchronous page building task has not yet completed (it is in the process of loading or rendering). The current duplicate page switching request will be directly intercepted and rejected, and an error code will be returned. This ensures that only one asynchronous page building task is being executed at any given time, thereby avoiding the chaotic state of multiple "half-finished" pages existing in memory at the same time.

[0039] Step 5: Display the target JavaScript page; when it needs to be hidden, Put the target JavaScript page into the background. In this embodiment, step 5 specifically includes: Step 51: The asynchronous task queue starts executing page switching tasks. During the lifecycle of the target JavaScript page, the state change method of the state machine is called to manage the state of the target JavaScript page through the state machine. Step 52: The state machine switches the state of the target JavaScript page from the initialization state to the ready state and performs the following operations: calls the page rendering function to complete the rendering of the target JavaScript page. After rendering is complete, calls the page lifecycle callback function onReady to notify the target JavaScript page that it is ready. Step 53: The state machine continues to switch the state of the target JavaScript page from the ready state to the display state, and performs the following operations: calls the page display function to render the target JavaScript page on the screen, and calls the page lifecycle callback function onShow to notify the target JavaScript page that it has been displayed; Step 54: When the target JavaScript page needs to be hidden, the state machine changes the state of the target JavaScript page from the display state to the background state and completes the following operations: The state machine calls the page hiding function to move the target JavaScript page from the foreground to the background. At the same time, it triggers the page lifecycle callback function onHide to notify the JavaScript page that it has entered the background. Step 55: When the target JavaScript page needs to switch from the background state to the display state, in the background state, the state machine restores the style and display state of the target JavaScript page, calls the page display function to re-render the target JavaScript page, and calls the page lifecycle callback function onShow to notify the target JavaScript page that it has been restored from the background to the foreground.

[0040] Step 6: When the target JavaScript page needs to be destroyed, enter the destruction state and release all runtime environment resources and memory occupied by the target JavaScript page.

[0041] In this embodiment, step 6 specifically includes: Step 61: Determine whether the target JavaScript page needs to be kept in RTOS memory. If not, proceed to step 62; if yes, proceed to step 63. Step 62: The state machine switches the target JavaScript page from the background state to the destruction state. The normal state includes the initialization state, the ready state, the display state, and the background state. In the destruction state, the state machine performs cleanup operations on the target JavaScript page resources, including releasing the target JavaScript page's runtime environment, destroying the style manager, and reclaiming memory. At the same time, it triggers the page lifecycle callback function onDestroy to notify the target JavaScript page that it has been destroyed. Step 63: Keep the target JavaScript page in the background.

[0042] Through the above steps, the page switching process is completed efficiently, the target JavaScript page is loaded and displayed quickly, and the current JavaScript page resources are managed reasonably, ensuring system performance and user experience.

[0043] Managing the state transitions of a JavaScript page using a state machine includes: The states of the JavaScript page include at least the undefined state, the initial state (INIT_STATE), the ready state (READY_STATE), the displayed state (SHOW_STATE), the background state (BACKGROUND_STATE), and the destroyed state (DESTROY_STATE). 1) Transition from undefined state to initialization state: In the undefined state, the state machine initializes the runtime environment of the JavaScript page. Specific operations include: binding page parameters, initializing the style manager, loading and parsing the user's JavaScript code, and calling the page lifecycle callback function onInit. After initialization is completed, the state machine transitions to the initialization state, indicating that the JavaScript page has been initialized. 2) Switching from the initialization state to the ready state: The state machine calls the page rendering function to complete the initial rendering of the JavaScript page. After rendering is complete, the page lifecycle callback function onReady is triggered to notify the JavaScript page that it is ready. The state machine switches to the ready state, indicating that the JavaScript page is ready to be displayed. 3) Switching from the ready state to the display state: In the ready state, the state machine updates the style manager and calls the page display function to present the JavaScript page to the user; at the same time, the page lifecycle callback function onShow is triggered to notify the JavaScript page that it has been displayed, and the state machine switches to the display state, indicating that the JavaScript page has been successfully displayed; 4) Switching from the display state to the background state: In the display state, the state machine calls the page hide function to move the JavaScript page from the foreground to the background. At the same time, the page lifecycle callback function onHide is triggered to notify the JavaScript page that it has entered the background. The state machine switches to the background state, indicating that the JavaScript page has been successfully hidden. 5) Switching from background state to display state: In the background state, the state machine restores the style and display state of the JavaScript page, calls the page display function to re-render the JavaScript page, and calls the page lifecycle callback function onShow to notify the JavaScript page that it has been restored from the background to the foreground. The state machine switches to the display state, indicating that the JavaScript page has been re-displayed. 6) Switching from any normal state or when an error occurs to the destroyed state: In any normal state or when an error occurs, the state machine switches to the destroyed state. The normal states include the initialization state, the ready state, the display state, and the background state. In the destroyed state, the state machine performs cleanup operations on the JavaScript page resources, including releasing the JavaScript page's runtime environment, destroying the style manager, and reclaiming memory. At the same time, it triggers the page lifecycle callback function onDestroy to notify the JavaScript page that it has been destroyed. The state machine switches to the destroyed state, indicating that the JavaScript page has been completely cleaned up. Through the state transition logic described above, the state machine can efficiently manage the lifecycle of a page, ensuring that the transition logic between different states is clear and stable.

[0044] Table 1: States of the State Machine

[0045] This invention coordinates the state machine and caching mechanism through a router, with the specific linkage logic as follows: Cache generation (retention) linkage: When a page is marked as a cached page and needs to be replaced, the route manager does not destroy the page's state machine object, but instead forces its state to switch to a background state. During this process, the state machine retains the JS execution context (JSContext), lifecycle state, and style manager, thus forming a "live snapshot" in memory.

[0046] Cache hit (activation) linkage: When the target page of a page switching request matches the state machine page in the cache, the route manager directly reuses the state machine object. At this time, the state machine management logic skips the regular initialization state (JS parsing) and ready state (rendering) process, and directly wakes up the state machine object from memory to enter the snapshot application's recovery process.

[0047] The key innovative points that this invention aims to protect are as follows: 1. Runtime Environment Snapshot Caching Mechanism: This invention designs a serializable JavaScript runtime environment storage mechanism to save dynamic data such as the page's execution context, lifecycle state, and style manager as snapshot files. This mechanism supports rapid loading of the runtime environment when switching or restoring the page, avoiding repeated initialization operations and thus significantly improving page loading efficiency.

[0048] 2. Page Lifecycle Management via State Machine: This invention introduces a state machine for fine-grained management of the page lifecycle, including initialization, ready, display, background, and destruction states. By defining clear state transition logic, it ensures stable and efficient transitions between different page states, avoiding state chaos issues.

[0049] 3. Asynchronous Task Scheduling Mechanism: This invention utilizes an asynchronous task manager to achieve asynchronous processing of page switching and resumption, avoiding blocking the main thread. This mechanism significantly improves the system's concurrency capabilities and response speed, optimizing the smoothness of user operations.

[0050] 4. Dynamic binding of page parameters and style management: This invention supports dynamic binding and updating of page parameters and style managers, ensuring that the latest parameters and style configurations can be correctly loaded when the page is switched or restored, thereby improving the dynamic adaptability of the page.

[0051] 5. Resource Management and Recycling Mechanism: When a page is destroyed, this invention releases the page's runtime environment, style manager, and dynamic resources through a resource management and recycling mechanism, thereby avoiding memory leaks and improving system stability and reliability.

[0052] In summary, the key innovation of this invention lies in its ability to achieve efficient loading, switching, and management of JavaScript pages on embedded devices through runtime environment snapshots, state machines, and asynchronous task scheduling, demonstrating significant technical advantages and application value.

[0053] The above description is only a part of the embodiments of the present invention and does not limit the scope of protection of the present invention. Any equivalent device or equivalent process transformation made based on the content of the present invention specification and drawings, or direct or indirect application in other related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A JS runtime environment snapshot caching method suitable for an RTOS, characterized in that, The method comprises the following steps: Step 1, when a JavaScript page needs to be cached, storing the key running data of the running environment of the JavaScript page to be cached in the RTOS memory to form a memory snapshot; Step 2, receiving a page switching request from the current JavaScript page to a target JavaScript page, and judging whether the cached key running data corresponding to the target JavaScript page exists in the RTOS memory; Step 3, if yes, directly reusing the cached key running data; if no, creating and initializing the key running data of the running environment for the target JavaScript page; Step 4, asynchronously scheduling the page switching request to an asynchronous task queue and executing an asynchronous task; Step 5, when the target JavaScript page needs to be hidden, entering the background state of the target JavaScript page; Step 6, when the target JavaScript page needs to be destroyed, entering the destroy state and releasing all running environment resources and memory occupied by the target JavaScript page. The step 1 specifically comprises:

2. The JS runtime environment snapshot caching method for RTOS according to claim 1, wherein, Step 11, when a JavaScript page needs to be cached, obtaining the key running data of the running environment of the JavaScript page, wherein the key running data at least comprises a state machine object, a JavaScript execution context, a page life cycle state, a style manager and page routing parameters; Step 12, taking the key running data of the running environment as a snapshot main body and residing in the RTOS memory in the form of a memory object instance to form a memory snapshot; Step 13, storing the key running data in association with the identifier of the JavaScript page in the RTOS memory, and maintaining a cache mapping table through a routing manager, wherein the cache mapping table is used to store the association between the identifier of the JavaScript page and the corresponding key running data. The state machine object refers to a mode of managing the page state by using a state machine; 3. The JS runtime environment snapshot caching method for RTOS according to claim 2, wherein, The JavaScript execution context saves the JavaScript object instance corresponding to the JavaScript page, contains the responsive data, member variables and bound function methods of the page, and maintains the reference in the JavaScript engine heap memory during the residence of the memory snapshot; The page life cycle state refers to the current life cycle state of the JavaScript page, including an undefined state, an initialization state, a ready state, a display state, a background state and a destroy state; The style manager refers to the style information of the JavaScript page, including static CSS rules and dynamically calculated styles; The page routing parameters refer to a dynamic data set transmitted when the page is switched, and are used to configure the initial state and behavior of the page. The step 2 specifically comprises:

4. The JS runtime environment snapshot caching method for RTOS according to claim 1, wherein, ​ Step 21, receiving a page switching request initiated by a user to switch from a current JavaScript page to a target JavaScript page, the page switching request carrying an identification of the target JavaScript page; Step 22, calling a page switching function, and first querying, according to the identification of the target JavaScript page, whether there is key running data matching the identification of the target JavaScript page in a cache mapping table in the RTOS memory; Step 23, judging, according to a query result, whether there is cached key running data associated with the identification of the target JavaScript page in the RTOS memory.

5. The JS runtime environment snapshot caching method for RTOS according to claim 1, wherein, The step 3 specifically comprises: Step 31, if there is cached key running data corresponding to the target JavaScript page in the RTOS memory, directly reusing a state machine object in the key running data and updating page routing parameters; Step 32, if there is no cached key running data corresponding to the target JavaScript page in the RTOS memory, creating a new state machine object, initializing a running environment of the target JavaScript page, and the specific operation comprising: binding page routing parameters and a style manager; generating a JavaScript file path of the target JavaScript page, and loading and parsing JavaScript code; calling a page lifecycle callback function onInit to complete target JavaScript page initialization.

6. The JS runtime environment snapshot caching method for RTOS according to claim 1, wherein, The step 4 specifically comprises: Distributing the page switching request to an asynchronous task queue, releasing a JavaScript execution context in the current JavaScript page, and waiting for task execution; The asynchronous task queue is managed by an asynchronous task manager, adopts a first-in-first-out queue model, and is used for serializing execution of corresponding operations.

7. The JS runtime environment snapshot caching method for RTOS according to claim 6, wherein, The operations performed by the asynchronous task manager at least comprise: Parsing and executing JavaScript scripts: calling an EvalPage function to load a JavaScript file of the target JavaScript page, and constructing a ViewModel object; Building a component tree: calling a RenderPage function, executing a rendering function according to data of the ViewModel object, and recursively creating a native component tree and a document object model structure of a C++ layer; Style calculation and layout: parsing a CSS style sheet, calculating geometric properties and hierarchical relationships of components; Garbage collection: cleaning useless objects left by an old page after rendering of the JavaScript page is completed, and releasing heap memory.

8. The JS runtime environment snapshot caching method for RTOS according to claim 6 or 7, characterized in that, A state machine pointer is maintained in the routing manager, and the state machine pointer is used to identify whether a transition state in page building is present; the state machine pointer remains in a non-empty state during execution of the asynchronous task; when the asynchronous task is completely executed and the new page is ready, state cleaning is performed, and the state machine pointer is set to empty. When the page switching request is initiated, the state machine pointer maintained inside the route manager is checked; if the state machine pointer is empty, it indicates that there is no asynchronous page construction task being executed at present, the state machine pointer is immediately set to point to the state machine object to be created for the page switching request, the current page switching request is received and executed; if the state machine pointer is not empty, it indicates that the previous asynchronous page construction task has not been completed, the current repeated page switching request is directly intercepted and rejected, and an error code is returned.

9. The JS runtime environment snapshot caching method for RTOS according to claim 1, wherein, The step 5 specifically comprises: Step 51, the asynchronous task queue starts to execute the page switching task, and in the life cycle of the target JavaScript page, a state change method of the state machine is called to manage the state of the target JavaScript page by the state machine; Step 52, the state machine switches the state of the target JavaScript page from the initialization state to the ready state, and completes the following operations: a page rendering function is called to complete the rendering of the target JavaScript page, after the rendering is completed, a page life cycle callback function onReady is called to notify that the target JavaScript page is ready; Step 53, the state machine continues to switch the state of the target JavaScript page from the ready state to the display state, and completes the following operations: a page display function is called to present the target JavaScript page on the screen, and a page life cycle callback function onShow is called to notify that the target JavaScript page has been displayed; Step 54, when the target JavaScript page needs to be hidden, the state machine switches the state of the target JavaScript page from the display state to the background state, and completes the following operations: the state machine calls a page hiding function to move the target JavaScript page from the foreground to the background, and triggers a page life cycle callback function onHide to notify that the JavaScript page has entered the background; Step 55, when the target JavaScript page needs to be switched from the background state to the display state, in the background state, the state machine restores the style and display state of the target JavaScript page, calls a page display function to present the target JavaScript page again, and calls a page life cycle callback function onShow to notify that the target JavaScript page has been restored from the background to the foreground.

10. The JS runtime environment snapshot caching method for RTOS according to claim 1, wherein, The step 6 specifically comprises: Step 61, it is judged whether the target JavaScript page needs to be retained in the RTOS memory, if not, step 62 is entered; if yes, step 63 is entered; Step 62, the target JavaScript page is deleted from the RTOS memory; Step 62, the state machine switches the state of the target JavaScript page from the background state to the destroy state, wherein the normal state includes an initialization state, a ready state, a display state and the background state; in the destroy state, the state machine performs a cleaning operation on the target JavaScript page resource, including releasing the running environment of the target JavaScript page, destroying the style manager, recycling the memory, and triggering a page life cycle callback function onDestroy to notify that the target JavaScript page has been destroyed; Step 63, the target JavaScript page is kept in the background state.

Images