System and method for realizing JS multi-application framework on RTOS platform

Abstract

The invention discloses a system for realizing a JS multi-application framework on an RTOS platform, and the system comprises a desktop service assembly which is used for managing application loading, task processing and message transmission; the Launcher desktop application is used for providing a main interface function, and a user selects and starts a JS application through an interface; the JS application is used for running the JS application developed by the user; the desktop service assembly comprises an application loader used for initializing a JS runtime environment and loading and starting a JS application; the task processor is used for managing task switching between the JS application and the Launcher desktop application and managing an application state through a state machine; and the message center is used for processing the asynchronous message and transmitting the message to the task processor. The invention discloses a method for realizing a JS (JavaScript) multi-application framework on an RTOS (Real Time Operating System) platform, which meets the requirement of multi-task processing, optimizes resource management and improves system performance.

Description

Technical Field

[0001] The present invention relates to the technical field of JS application running, and particularly to a system and method for implementing a JS multi-application framework on an RTOS platform. Background Art

[0002] With the popularization of JavaScript (JS) development and the development of JS engine technology, the emergence of lightweight JS parsing engines makes it possible to run JS code on traditional real-time operating system (RTOS) platforms. Represented by engines such as JerryScript and QuickJS, these engines have been optimized in terms of memory occupancy and performance and are suitable for resource-constrained embedded systems.

[0003] In classic JS multi-application frameworks, it is usually implemented based on processes, that is, each JS application runs in an independent process, and each process binds a JS engine. When the system starts a JS application, a new process will be created to run the JS runtime, parse and execute the application code. Data isolation between applications is achieved through processes to ensure independence from each other.

[0004] However, due to the hardware resource limitations of the RTOS platform, the system usually does not have the ability of a memory management unit (MMU), only supports threads and does not have the concept of processes. The technical means for multi-application management in traditional operating systems (such as multi-application frameworks based on process isolation) are difficult to directly migrate to the RTOS platform, which makes it difficult to implement the loading, switching, and management of multiple JS applications on the RTOS platform, especially on resource-constrained lightweight hardware platforms. Taking the OpenHarmony L0 system as an example, the officially provided version only supports a single-application framework, that is, after the system starts, it only parses and runs the JS application code stored in a fixed path, lacking the ability to load and switch multiple applications. The main reason is that the JS runtime requires a large amount of memory and CPU resources, and frequent startup and destruction of the JS runtime may lead to memory leaks. On Linux and Android platforms, the creation and destruction of processes contribute to resource recycling, but the RTOS platform usually does not have this ability. In addition, the lack of a standard native system desktop design similar to Android on the RTOS platform further restricts the implementation of multi-application management.

[0005] The deficiencies of the prior art are as follows:

[0006] 1. Insufficient resource management: Due to the lack of a process management mechanism, it is difficult for the RTOS platform to effectively manage the resources of multiple JS applications, which may lead to memory leaks and resource waste;

[0007] 2. Lack of multi-application support: Existing RTOS platforms usually only support the operation of a single application, lacking the ability to load and switch between multiple applications, and unable to meet the requirements of multi-task processing.

[0008] 3. Lack of standardized desktop design: The RTOS platform lacks a standard native system desktop design similar to Android, resulting in a lack of unity and standardization in the interaction and management between applications.

[0009] 4. Performance and memory occupancy issues: Frequent startup and destruction of the JS runtime may lead to performance degradation and increased memory occupancy, affecting the stability and response speed of the system. Summary of the Invention

[0010] In view of this, the purpose of the present invention is to propose a system for implementing a JS multi-application framework on an RTOS platform, propose a method for switching between a Launcher desktop application and a JS application runtime, and manage multiple JS applications on a lightweight RTOS hardware platform to meet the requirements of multi-task processing, optimize resource management, and improve the performance and stability of the system.

[0011] To achieve the above technical objectives, the technical solutions adopted by the present invention are as follows:

[0012] The present invention provides a system for implementing a JS multi-application framework on an RTOS platform, including:

[0013] A desktop service component for managing application loading, task processing, and message passing;

[0014] A Launcher desktop application for providing the main interface function, through which the user can select and start a JS application;

[0015] A JS application for running third-party JS applications developed by users;

[0016] The desktop service component includes an application loader, a task processor, and a message center; the application loader is used to initialize the JS runtime environment, load and start a JS application; the task processor is responsible for polling and executing tasks in the task queue of the current application, managing task switching between the JS application and the Launcher desktop application, and managing the application state through a state machine; the message center is used to process asynchronous messages and pass the messages to the task processor.

[0017] Further, the task processor maintains two task queues:

[0018] A local task queue for processing tasks of the Launcher desktop application;

[0019] A JS task queue for processing tasks of the JS application.

[0020] Further, the state machine includes the following states:

[0021] The uninitialized state indicates that the JS runtime environment is not initialized, and the current running application is the Launcher desktop application;

[0022] The initialization state indicates that the JS runtime environment has been initialized, and the current running application is the JS application;

[0023] The exit state indicates that when the JS application calls the application exit interface, the application running is terminated, resources are recycled, and the JS runtime environment is cleaned up;

[0024] The exited state indicates that the cleanup of the JS runtime environment is completed, and the Launcher desktop application is restarted. Further, the task processor realizes the switching between different states through the state machine, specifically including:

[0025] Switching from the uninitialized state to the initialization state: After the user selects the JS application through the interface of the Launcher desktop application, the task processor calls the desktop service component to initialize the JS runtime environment, load and start the JS application;

[0026] Switching from the initialization state to the exit state: When the JS application calls the application exit interface, the task processor enters the resource cleanup process, destroys the JSContext object and performs garbage collection;

[0027] Switching from the exit state to the exited state: The task processor restarts the Launcher desktop application and resumes the execution of the local task queue;

[0028] Switching from the exited state to the uninitialized state: When the user selects the JS application again through the interface of the Launcher desktop application, the task processor re-initializes the JS runtime environment and loads a new JS application.

[0029] Further, different JS applications share the same JSRuntime object, and each JS application realizes data isolation through an independent JSContext object.

[0030] The present invention also provides a method for implementing a JS multi-application framework on an RTOS platform. The method is applied to the above-mentioned system for implementing a JS multi-application framework on an RTOS platform, and the method specifically includes the following steps:

[0031] Step 1, initialize the local application runtime environment. The task processor starts the Launcher desktop application through the application loader, sets the state of the state machine to the uninitialized state, and executes the tasks in the local task queue;

[0032] Step 2: After the user selects a JS application through the interface of the Launcher desktop application, the task processor calls the application loader to load and start the JS application, switches the state of the state machine to the initialization state, and executes the tasks in the JS task queue;

[0033] Step 3: When the JS application calls the application exit interface, the task processor switches the state of the state machine to the exit state and performs resource cleaning and memory recycling operations;

[0034] Step 4: After the resource cleaning is completed, the task processor calls the application loader to reload and start the Launcher desktop application, switches the state of the state machine to the exited state, and resumes executing the tasks in the local task queue;

[0035] Step 5: When the user selects a JS application again through the interface of the Launcher desktop application, the JS runtime environment is re-initialized, the task processor calls the application loader to load and start a new JS application, and switches the state of the state machine to the initialization state.

[0036] Further, Step 1 specifically includes:

[0037] Step 11: After the system starts, initialize the underlying graphics framework and enter the local application runtime environment;

[0038] Step 12: The task processor starts the Launcher desktop application through the desktop application start function of the application loader, and sets the state of the state machine in the task processor to the uninitialized state;

[0039] Step 13: In the uninitialized state, the task processor defaults to loop-processing the tasks in the local task queue.

[0040] Further, Step 2 specifically includes:

[0041] Step 21: When the user clicks on the JS application to be started on the interface of the Launcher desktop application, the task processor calls the desktop application start function of the application loader and passes the installation path of the corresponding JS application to the application loader to perform the initialization operation of the JS application;

[0042] Step 22: The application loader creates a JSRuntime object and a JSContext object to complete the initialization of the JS runtime environment;

[0043] Step 23: Add the callback function corresponding to the JS engine in the JSRuntime object to the JS task queue of the task processor;

[0044] Step 24: Load the corresponding JS file under the JS application file path, parse the JS file, execute the entry function of the JS application according to the JS file, and start the JS application;

[0045] After startup is completed, the task processor updates the state of the state machine from the uninitialized state to the initialized state, switches to execute the tasks in the JS task queue, and stops the task processing of the local task queue, so that the Launcher desktop application stops updating the UI and goes to the background.

[0046] Further, step 3 specifically includes:

[0047] When the user clicks the back button on the interface of the JS application, the JS application calls the application exit interface to exit. The task processor switches the state of the state machine to the exit state and notifies the task processor to enter the destruction process;

[0048] When the task processor determines that the current state is the exit state during the execution of the task loop, it will perform the cleanup operation of the JS runtime environment before the next task loop:

[0049] Call the Free function to destroy the JSContext object and recycle the application corresponding object associated with it;

[0050] Retain the JSRuntime object and call the garbage collection function to perform the garbage collection operation on the JSRuntime object to recycle the useless memory.

[0051] Further, step 5 specifically includes:

[0052] After the user clicks the icon of the target JS application in the Launcher desktop application, the Launcher desktop application calls the desktop application startup function of the application loader through the task processor to start a new JS application;

[0053] The application loader creates a new JSContext object;

[0054] Load the corresponding JS file under the path of the new JS application, parse the JS file, execute the entry function of the new JS application according to the JS file, and start the new JS application;

[0055] The task processor switches the state of the state machine to the initialized state and starts to execute the tasks in the JS task queue.

[0056] Adopting the above technical solution, compared with the prior art, the beneficial effects of the present invention are:

[0057] 1. Multi-application management mechanism: By designing two different types of application task queues and corresponding application state machine management mechanisms, and using a task processor to switch between different application task queues, the display and hiding of the native Launcher desktop application are realized, supporting the launching of different JS applications through the Launcher desktop application, providing a multi-application usage experience similar to Android. Such a design can effectively improve the user experience, enabling the loading and switching of multiple applications on an RTOS platform with limited resources, enhancing the flexibility and operability of the system.

[0058] 2. Memory management optimization: Aiming at the memory recycling problem during JS application switching, a design method of reusing JSRuntime and having independent JSContext for different JS applications is proposed. On the basis of ensuring application data isolation, the execution efficiency during application switching is effectively improved, and the risk of memory leakage is reduced. By reusing JSRuntime, the repeated allocation and release of memory are reduced, and the risk of memory fragmentation is lowered; the independent JSContext ensures data isolation between applications, avoiding data conflicts and leakage. Brief Description of the Drawings

[0059] In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings required for use in the description of the embodiments or the prior art. Obviously, the following drawings are only some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other drawings can be obtained based on these drawings.

[0060] Figure 1 It is a system architecture diagram of a JS multi-application framework implemented on an RTOS platform provided by an embodiment of the present invention.

[0061] Figure 2 It is a schematic diagram of multiple states of a state machine provided by an embodiment of the present invention.

[0062] Figure 3 It is a flowchart of the method execution for implementing a JS multi-application framework on an RTOS platform provided by an embodiment of the present invention. Detailed Embodiments

[0063] The following will further describe the present invention in detail in conjunction with the drawings and embodiments. It should be specifically noted that the following embodiments are only used to illustrate the present invention, but do not limit the scope of the present invention. Similarly, the following embodiments are only some embodiments of the present invention rather than all embodiments. All other embodiments obtained by those of ordinary skill in the art without creative efforts fall within the scope of protection of the present invention.

[0064] Please refer to Figure 1and Figure 2 A system for implementing a JS multi-application framework on an RTOS platform according to the present invention includes:

[0065] A Desktop service component, which is used to manage application loading, task processing, and message passing;

[0066] A Launcher desktop application (NativeLauncher), which is used to provide the main interface function. Through this interface, users can select and start JS applications; this part is the desktop application (Launcher) of the system, developed using C / C++, deployed in the native application C / C++, and based on the Lvgl graphics library to implement a desktop interaction logic similar to that of Android. NativeLauncher draws the icons of the JS applications installed on the device on the device screen, and users can click and select the JS application to be launched through the NativeLauncher interface.

[0067] A JS application (JSApplication), which is used to run third-party JS applications developed by users, adopts a classic Web development mode, uses HTML to describe the document structure, CSS to control the page style, and JS files to describe the application logic;

[0068] The Desktop service component includes an ApplicationLoader, a TaskHandler, and a MessageCenter; the ApplicationLoader is used to initialize the JS runtime environment, load and start the JS application; the TaskHandler is the processing center of application tasks, which is responsible for polling and executing the tasks in the task queue of the current application, managing the task switching between the JS application and the Launcher desktop application, and managing the application state through a state machine; the MessageCenter is used to process asynchronous messages and pass the messages to the TaskHandler.

[0069] The overall design of the system framework includes the interaction mechanism of the Launcher desktop application, the JS application, the ApplicationLoader, and the TaskHandler; the present invention designs a standard multi-application framework on the RTOS platform, uses the Launcher desktop application to complete the standard desktop function, and provides a main interface function similar to that of the Android system. This framework dynamically loads and starts different JS applications through the ApplicationLoader and realizes seamless switching between the Launcher desktop application and the JS application through the TaskHandler. Through this design, the present invention overcomes the deficiencies of traditional RTOS platforms in multi-application management and realizes an efficient and flexible JS application management mechanism.

[0070] In this embodiment, the TaskHandler maintains two task queues:

[0071] A local task queue for processing tasks of the Launcher desktop application;

[0072] A JS task queue for processing tasks of JS applications. Each queue corresponds to a different application type and processes tasks such as user input and UI updates.

[0073] A mechanism for switching task queues between the Launcher desktop application and JS applications to ensure efficient execution of task scheduling and application switching: In the present invention, the task processor maintains two task queues: one for processing tasks of the Launcher desktop application and the other for processing tasks of JS applications. According to the current application state, the task processor can dynamically switch task queues to ensure that different types of tasks are processed in a timely manner on the main thread. This mechanism can smoothly complete application switching and task scheduling when the user clicks to switch to a JS application or return to the Launcher desktop application.

[0074] In this embodiment, the state machine includes the following states:

[0075] The uninitialized state (UNINITIALIZED), indicating that the JS runtime environment is not initialized and the current running application is the Launcher desktop application;

[0076] The initialization state (INITIAL), indicating that the JS runtime environment has been initialized and the current running application is a JS application;

[0077] The exiting state (EXITING), indicating that when the JS application calls the application exit interface, the application runs are terminated, resources are recycled, and the JS runtime environment is cleaned up;

[0078] The exited state (EXITED), indicating that the JS runtime environment has been cleaned up and the Launcher desktop application is restarted. A multi-JS application loading and switching mechanism similar to that of the Android system is implemented. By managing the running state of the current JS application through a state machine, resource cleaning and isolation during application switching are ensured, and the technical problem of multi-application management on the RTOS platform is solved.

[0079] In this embodiment, the task processor realizes the switching between different states through the state machine, specifically including:

[0080] Switching from the uninitialized state to the initialization state: After the user selects a JS application through the interface of the Launcher desktop application, the task processor calls the desktop service component to initialize the JS runtime environment, load, and start the JS application;

[0081] Switching from the initialization state to the exit state: When the JS application calls the application exit interface, the task processor enters the resource cleanup process, destroys the JSContext object, and performs garbage collection;

[0082] Switching from the exit state to the exited state: The task processor restarts the Launcher desktop application and resumes the execution of the local task queue;

[0083] Switching from the exited state to the uninitialized state: When the user selects the JS application again through the interface of the Launcher desktop application, the task processor re-initializes the JS runtime environment and loads the new JS application. When the application environment changes, the task processor will select the corresponding task queue for execution, thus realizing the switching between applications.

[0084] State machine switching design for JS applications and Launcher desktop applications, as well as resource cleanup and memory management during state switching: The present invention introduces the design concept of a state machine in the task processor to manage the switching process between JS applications and Launcher desktop applications. This state machine includes multiple key states (such as UNINITIALIZED, INITIAL, EXITING, EXITED), and corresponding operations are performed when switching between each state. For example, when switching to the EXITING state, the system performs resource recycling and memory cleanup, while when switching to the INITIAL state, it re-initializes the JS runtime environment and loads the JS application. This state machine design effectively ensures resource management and system stability during the application switching process.

[0085] Process design for the startup and destruction of JS applications, including the initialization, destruction, and garbage collection mechanism of the JS runtime environment: The present invention proposes an efficient process for the startup and destruction of JS applications, which involves the creation, initialization, destruction, and resource recycling of JSRuntime objects and JSContext objects. Specifically, when the JS application starts, it dynamically loads and initializes the JS runtime environment through the application loader and switches to the JS task queue in the task loop; while when the application exits, relevant cleanup methods are called through the task processor, such as calling JS_FreeContext and JS_RunGC for memory recycling, to ensure the effective release of resources in the JS runtime environment.

[0086] In this embodiment, different JS applications share the same JSRuntime object, and each JS application realizes data isolation through an independent JSContext object. The system core is jointly composed of a JavaScript language parsing engine (JS engine), a front-end data hijacking framework, and a back-end graphics framework (UI framework). In the RTOS platform, typical lightweight JS parsing engines include JerryScript and QuickJS. The present invention selects the QuickJS engine as the implementation basis, and the implementation logic of JerryScript is similar to it. In different JS engine designs, there are usually two key objects: the application runtime JSRuntime object and the application context JSContext object.

[0087] JSRuntime (application runtime): It is the underlying infrastructure of JavaScript applications, mainly composed of a JS engine, responsible for parsing and executing JavaScript code. At the same time, it undertakes the responsibility of global resource management, including memory allocation, garbage collection, and task scheduling.

[0088] JSContext (application context): It is the execution context of JavaScript code, associating the state during the execution of the currently running code (such as variables, function calls, etc.). A JSRuntime can contain multiple JSContexts. These JSContexts can share the same JSRuntime runtime resources, but the variables and object scopes associated under each JSContext are isolated from each other.

[0089] The design of JS runtime sharing and JSContext object isolation ensures the security isolation and resource management between JS applications: In the present invention, different JS applications share the same JS runtime (JSRuntime) object, but each JS application realizes data isolation through an independent JSContext object. The JSContext object provides an independent execution environment for each application, ensuring that the data, memory, and states between applications do not interfere with each other. This design method avoids the common memory conflict problems in the RTOS platform and improves the isolation and security between applications.

[0090] As Figure 3 shown, the present invention also provides a method for implementing a JS multi-application framework on the RTOS platform. The method is applied to the above-mentioned system for implementing a JS multi-application framework on the RTOS platform. The method specifically includes the following steps:

[0091] Step 1. Initialize the local application runtime environment. The task processor starts the Launcher desktop application through the application loader, sets the state of the state machine to the uninitialized state, and executes the tasks in the local task queue;

[0092] In this embodiment, step 1 specifically includes:

[0093] Step 11. After the system starts, initialize the underlying graphics framework and enter the local application runtime environment;

[0094] Step 12. The task processor starts the Launcher desktop application through the desktop application startup function of the application loader, and sets the state of the state machine in the task processor to the uninitialized state;

[0095] Step 13. In the uninitialized state, the task processor defaults to loop and process the tasks in the local task queue.

[0096] Step 2. After the user selects a JS application through the interface of the Launcher desktop application, the task processor calls the application loader to load and start the JS application, switches the state of the state machine to the initialized state, and executes the tasks in the JS task queue;

[0097] In this embodiment, step 2 specifically includes:

[0098] Step 21. When the user clicks on the JS application to be started on the interface of the Launcher desktop application, the task processor will call the desktop application startup function of the application loader and pass the installation path of the corresponding JS application to the application loader to perform the initialization operation of the JS application;

[0099] Step 22. The application loader creates a JSRuntime object and a JSContext object to complete the initialization of the JS runtime environment; different JS applications share the same JSRuntime object, and each JS application realizes data isolation through an independent JSContext object.

[0100] Step 23. Add the callback function corresponding to the JS engine in the JSRuntime object to the JS task queue of the task processor;

[0101] Step 24. Load the corresponding JS file under the JS application file path, parse the JS file, and execute the entry function of the JS application according to the JS file and start the JS application;

[0102] Step 25: After startup is completed, the task processor updates the state of the state machine from the uninitialized state to the initialized state, switches to execute the tasks in the JS task queue, and stops the task processing of the local task queue, so that the Launcher desktop application stops updating the UI and retreats to the background.

[0103] Step 3: When the JS application calls the application exit interface, the task processor switches the state of the state machine to the exit state and performs resource cleaning and memory recycling operations;

[0104] In this embodiment, the specific steps of Step 3 include:

[0105] Step 31: When the user clicks the back button on the interface of the JS application, the JS application calls the application exit interface to exit, and the task processor switches the state of the state machine to the exit state, notifying the task processor to enter the destruction process;

[0106] Step 32: When the task processor determines that the current state is the exit state during the execution of the task loop, it will perform the cleaning operation of the JS runtime environment before the next task loop:

[0107] Call the Free function to destroy the JSContext object and recycle the application corresponding objects associated with it;

[0108] Retain the JSRuntime object and call the garbage collection function to perform the garbage collection (GC) operation on the JSRuntime object to recycle the useless memory.

[0109] Step 4: After the resource cleaning is completed, the task processor calls the application loader to reload and start the Launcher desktop application, switches the state of the state machine to the exited state, and resumes the execution of the tasks in the local task queue; supports the normal exit and resource recycling of the JS application. When the JS application exits, the system can restore to the application main interface through the Launcher desktop application and can reload and start other JS applications as needed.

[0110] Step 5: When the user selects the JS application again through the interface of the Launcher desktop application, re-initialize the JS runtime environment. The task processor calls the application loader to load and start a new JS application, and switches the state of the state machine to the initialized state. By starting different JS applications through the independent Launcher desktop application, each JS application realizes data isolation through an independent JSContext object, thus avoiding memory conflicts and data pollution between JS applications.

[0111] In this embodiment, the specific steps of Step 5 include:

[0112] Step 51: After the user clicks the icon of the target JS application in the Launcher desktop application, the Launcher desktop application calls the desktop application startup function of the application loader through the task processor to start a new JS application;

[0113] Step 52: The application loader creates a new JSContext object;

[0114] Step 53: Load the JS file corresponding to the new JS application file path, parse the JS file, execute the entry function of the new JS application according to the JS file, and start the new JS application;

[0115] Step 54: The task processor switches the state of the state machine to the initialization state and starts to execute the tasks in the JS task queue.

[0116] By designing two different types of application task queues and corresponding application state machine management mechanisms, and using the task processor to switch between different application task queues, the display and hiding of the native Launcher desktop application are realized, supporting the startup of different JS applications through the Launcher desktop application, and providing a multi-application usage experience similar to Android. Such a design can effectively improve the user experience, enable the loading and switching of multiple applications on an RTOS platform with limited resources, and enhance the flexibility and operability of the system.

[0117] Regarding the memory recycling problem during JS application switching, a design method of reusing the JSRuntime object for different JS applications and having independent JSContext objects is proposed. On the basis of ensuring application data isolation, the execution efficiency during application switching is effectively improved, and the risk of memory leakage is reduced. By reusing the JSRuntime object, the repeated allocation and release of memory are reduced, and the risk of memory fragmentation is lowered; the independent JSContext object ensures data isolation between applications, avoiding data conflicts and leakage.

[0118] The above are only some embodiments of the present invention, and thus do not limit the protection scope of the present invention. Any equivalent device or equivalent process transformation made by using the content of the specification and drawings of the present invention, or directly or indirectly applied to other related technical fields, shall be equally included in the patent protection scope of the present invention.

Claims

1. A system for implementing a JS multi-application framework on an RTOS platform, characterized in that, Including: A desktop service component for managing application loading, task processing, and message passing; A Launcher desktop application for providing the main interface function, through which the user selects and launches a JS application; A JS application for running third-party JS applications developed by users; The desktop service component includes an application loader, a task processor, and a message center; the application loader is used to initialize the JS runtime environment, load, and start a JS application; the task processor is responsible for polling and executing tasks in the task queue of the current application, managing task switching between the JS application and the Launcher desktop application, and managing the application state through a state machine; the message center is used to process asynchronous messages and pass the messages to the task processor.

2. The system for implementing a JS multi-application framework on an RTOS platform according to claim 1, characterized in that, The task processor maintains two task queues: A local task queue for processing tasks of the Launcher desktop application; A JS task queue for processing tasks of the JS application.

3. A system for implementing a JS multi-application framework on an RTOS platform according to claim 1, characterized in that, The state machine includes the following states: An uninitialized state, indicating that the JS runtime environment is not initialized and the current running application is the Launcher desktop application; An initialized state, indicating that the JS runtime environment has been initialized and the current running application is a JS application; An exit state, indicating that when the JS application calls the application exit interface, the application runs are terminated, resources are recycled, and the JS runtime environment is cleaned up; A state of having exited, indicating that the JS runtime environment cleanup is completed and the Launcher desktop application is restarted.

4. The system for implementing a JS multi-application framework on an RTOS platform according to claim 3, wherein, The task processor realizes the switching between different states through the state machine, specifically including: Switching from the uninitialized state to the initialized state: After the user selects a JS application through the interface of the Launcher desktop application, the task processor calls the desktop service component to initialize the JS runtime environment, load, and start the JS application; Switching from the initialized state to the exit state: When the JS application calls the application exit interface, the task processor enters the resource cleanup process, destroys the JSContext object, and performs garbage collection; Switching from the exit state to the state of having exited: The task processor restarts the Launcher desktop application and resumes the execution of the local task queue; Switching from the state of having exited to the uninitialized state: When the user selects a JS application again through the interface of the Launcher desktop application, the task processor re-initializes the JS runtime environment and loads a new JS application.

5. A system for implementing a JS multi-application framework on an RTOS platform according to claim 1, characterized in that, Different JS applications share the same JSRuntime object, and each JS application realizes data isolation through an independent JSContext object.

6. A method for implementing a JS multi-application framework on an RTOS platform, characterized in that, The method is applied to a system for implementing a JS multi-application framework on an RTOS platform as described in claim 1. The method specifically includes the following steps: Step 1, initialize the local application runtime environment. The task processor starts the Launcher desktop application through the application loader, sets the state of the state machine to the uninitialized state, and executes the tasks in the local task queue. Step 2: After the user selects a JS application through the interface of the Launcher desktop application, the task processor calls the application loader to load and start the JS application, switches the state of the state machine to the initialization state, and executes the tasks in the JS task queue; Step 3: When the JS application calls the application exit interface, the task processor switches the state of the state machine to the exit state and performs resource cleaning and memory recycling operations; Step 4: After the resource cleaning is completed, the task processor calls the application loader to reload and start the Launcher desktop application, switches the state of the state machine to the exited state, and resumes executing the tasks in the local task queue; Step 5: When the user selects a JS application again through the interface of the Launcher desktop application, the JS runtime environment is re-initialized, and the task processor calls the application loader to load and start a new JS application, switching the state of the state machine to the initialization state.

7. The method for implementing a JS multi-application framework on an RTOS platform according to claim 6, characterized in that, The specific steps of Step 1 include: Step 11: After the system starts, initialize the underlying graphics framework and enter the local application runtime environment; Step 12: The task processor starts the Launcher desktop application through the desktop application startup function of the application loader, and sets the state of the state machine in the task processor to the uninitialized state; Step 13: In the uninitialized state, the task processor defaults to loop and process the tasks in the local task queue.

8. The method for implementing a JS multi-application framework on an RTOS platform according to claim 6, wherein The specific steps of Step 2 include: Step 21: When the user clicks the JS application to be started on the interface of the Launcher desktop application, the task processor will call the desktop application startup function of the application loader and pass the installation path of the corresponding JS application to the application loader to perform the initialization operation of the JS application; Step 22: The application loader creates a JSRuntime object and a JSContext object to complete the initialization of the JS runtime environment; Step 23: Add the callback function corresponding to the JS engine in the JSRuntime object to the JS task queue of the task processor; Step 24: Load the corresponding JS file under the JS application file path, parse the JS file, and execute the entry function of the JS application according to the JS file, and start the JS application; Step 25: After the startup is completed, the task processor updates the state of the state machine from the uninitialized state to the initialization state, switches to execute the tasks in the JS task queue, and stops the task processing of the local task queue, so that the Launcher desktop application stops updating the UI and goes to the background.

9. A method for implementing a JS multi-application framework on an RTOS platform according to claim 8, characterized in that, The specific steps of Step 3 include: Step 31: When the user clicks the back button on the interface of the JS application, the JS application calls the application exit interface to exit, and the task processor switches the state of the state machine to the exit state, notifying the task processor to enter the destruction process; Step 32: When the task processor determines that the current state is the exit state during the execution of the task loop, it will perform the cleaning operation of the JS runtime environment before the next task loop: Call the Free function to destroy the JSContext object and recycle the application corresponding object associated with it; Retain the JSRuntime object and call the garbage collection function to perform garbage collection operations on the JSRuntime object to reclaim unused memory.

10. A method for implementing a JS multi-application framework on an RTOS platform, characterized in that, Step 5 specifically includes: Step 51: After the user clicks on the icon of the target JS application in the Launcher desktop application, the Launcher desktop application calls the desktop application startup function of the application loader through the task processor to start a new JS application; Step 52: The application loader creates a new JSContext object; Step 53: Load the corresponding JS file under the new JS application file path, parse the JS file, execute the entry function of the new JS application according to the JS file, and start the new JS application; Step 54: The task processor switches the state of the state machine to the initialization state and starts executing the tasks in the JS task queue.

Images