Intelligent application life cycle management method and system

Abstract

The invention discloses an intelligent application life cycle management method and system, and relates to the field of software management.The method comprises the steps that in response to an application version starting request or restarting request, an application information structural body is searched for according to an application name, and whether a target version index is valid or not is verified; if the current running state of the application is RUNNING and the target version is different from the current version, an elegant stop process is triggered, version switching preparation is carried out, and a starting process is entered; and if the current running state of the application is FREE or EXIT, directly skipping to a starting process to realize hot switching of application versions. According to the invention, efficient application management in a resource limited environment is realized, the method has the advantages of less resource occupation, fast switching speed, strong fault self-healing capability and simple operation, and the problem of application management pain points in embedded and edge computing scenes in the prior art is thoroughly solved.

Description

Technical Field

[0001] This invention relates to the field of software management, and more specifically to a method and system for intelligent application lifecycle management. Background Technology

[0002] Application lifecycle management (ALM) refers to a unified approach / system for managing software applications throughout their entire lifecycle, from deployment and operation to monitoring and uninstallation. In resource-constrained scenarios such as embedded devices, edge computing nodes, and IoT gateways, ALM faces numerous challenges.

[0003] The existing technology has the following shortcomings: (1) Weak version management capabilities: Traditional application management methods / systems usually only support the operation of a single version. When an application needs to be updated, the old version must be completely stopped and the new version must be started, resulting in service interruption. For example, although the systemd service management in the Linux system can manage the start and stop of services, it does not have the ability to coexist with multiple versions or to quickly roll back.

[0004] (2) Inadequate fault recovery mechanism: Existing technologies handle abnormal application exits in a relatively simple way, lacking intelligent fault detection and automatic recovery mechanisms. When applications crash frequently, simple automatic restarts may exhaust system resources.

[0005] (3) High resource consumption: Although containerization technologies such as Docker support multiple version management, they require an additional container runtime environment to run on embedded devices, which consumes a lot of storage space and memory resources, making them unsuitable for resource-constrained edge devices.

[0006] (4) Low communication efficiency: Existing application management methods / systems mostly use HTTP / RESTful APIs for inter-process communication, which has problems of high protocol overhead and high latency in local scenarios, and is not suitable for edge computing scenarios that require fast response.

[0007] (5) Lack of unified management interface: Application management in many embedded systems relies on scripts and manual operations, lacking a unified API interface and command line tools, resulting in high management complexity and easy errors.

[0008] In summary, existing technical solutions are insufficient in terms of resource consumption, response speed, and version management flexibility, making it difficult to meet the requirements of lightweight, high availability, and rapid switching in edge computing and embedded scenarios. Summary of the Invention

[0009] To address the aforementioned shortcomings in existing technologies, this invention provides an intelligent application lifecycle management method and system that solves the problem that existing technical solutions cannot meet the requirements for rapid application version switching in edge computing and embedded scenarios.

[0010] To achieve the above-mentioned objectives, the technical solution adopted by this invention is as follows: A method for intelligent application lifecycle management is provided, which includes the following application multi-version hot-switching process: In response to an application version launch or restart request, the application information structure is located based on the application name. The validity of the target version index is verified. If it is valid, the current running status of the application is checked. Otherwise, no action is taken. If the application is currently running in the RUNNING state and the target version is different from the current version, the graceful shutdown process is triggered to prepare for version switching and enter the startup process; if the application is currently running in the FREE or EXIT state, it directly jumps to the startup process. The startup process includes the following steps: Call fork() to create a child process, and save the child process's PID to a version information structure through the parent process; The application startup command is executed by replacing the process image through a child process calling execvp(); Update the application status to RUNNING and update the running version index to the target version index; The PID and status of the child process are persisted to the application information configuration file, and the switching result is returned to complete the hot switching between multiple versions.

[0011] The beneficial effects of this method are: 1. Extremely low resource consumption, suitable for edge devices This method employs native process management, eliminating the need for container runtime. The management service itself consumes only 5-10MB of memory and has a storage overhead of less than 1MB. Compared to Docker solutions, it reduces resource consumption by over 90%. It can still run smoothly on an IoT gateway with 64MB of RAM, significantly reducing hardware costs.

[0012] 2. Fast version switching speed and short service interruption time. By using multi-version process hot-switching technology, the version switching time is controlled within 1-5 seconds, with the actual service interruption time being only the process startup time (usually <2 seconds). Compared to the traditional "uninstall-install-start" process, the switching speed is improved by more than 10 times, which is better than the switching speed of containerized solutions, but without the additional overhead of containerization.

[0013] Furthermore, the graceful stop process includes the following steps: Mark the application status as KILLING and send a SIGTERM signal to the target process; Start a timer, set a maximum number of checks, and check every 50 milliseconds to see if the target process has exited. If the target process exits within the maximum number of checks, reclaim resources via waitpid and enter version switching preparation. Otherwise, if the target process does not exit within the maximum number of checks, send SIGKILL to forcibly kill the process, forcibly reclaim resources, and enter version switching preparation.

[0014] Furthermore, version switch preparation includes the following steps: Retrieve the version information structure of the target version from the version list; Read the version configuration file from the version information structure of the target version and load the startup command; Prepare environment variables: set LD_LIBRARY_PATH to point to the target version's lib directory, and set the working directory to the target version's root directory.

[0015] Furthermore, the specific method for persisting the child process's PID and status to the application information configuration file is as follows: The PID and state of the child process are persisted to the application information configuration file by calling fsync; After persisting the child process's PID and state to the application information configuration file, the following operations are also included: Add the child process's PID to the monitoring list, set the SIGCHLD signal handler function, and start the health check timer.

[0016] Furthermore, the specific method for setting the SIGCHLD signal processing function to start the health check timer includes the following steps: The SIGCHLD signal is captured using the SIGCHLD signal handling function; the asynchronous wake-up flag is set in the SIGCHLD signal handling context. When the event loop detects the wake-up flag, it calls the process exit handling function in the main thread context: it calls waitpid in a loop to non-blockingly reclaim all exited child processes, and looks up the corresponding application information structure and version information structure according to the PID; Perform exit reason analysis: If the application status is KILLING, it is determined to be a voluntary stop, the status is updated to EXIT, resources are cleaned up and the process ends; if the application status is RUNNING, it is determined to be an abnormal exit and enters the self-healing decision process.

[0017] The beneficial effects of adopting the above-mentioned further solutions are as follows: The system passively detects changes in the state of child processes using the SIGCHLD signal; it uses a timer to poll and detect process exit status (50ms cycle, up to 30 seconds), preloads version configuration information, and reduces file I / O operations at startup; it handles process exit events uniformly in the event loop to avoid signal safety issues, and compared with the traditional timed polling method, the CPU utilization is close to 0%.

[0018] Furthermore, the self-healing decision-making process includes the following steps: Read the crash counter and error flag fields from the version information; Increment the current crash counter by 1; if the crash counter is less than 3, execute the restart strategy; if the crash counter is greater than or equal to 3 and less than 10, mark_err as 1 and attempt to switch the application to the previous stable version; where the stable version is the version that has not been marked as faulty; if the crash counter is greater than or equal to 10 or all versions have been marked as faulty, abandon the restart strategy, record it as a serious fault and send an alarm event.

[0019] Furthermore, the restart strategy includes the following steps: Create a timer task to perform a restart after a 1-second delay; Invoke the version startup process to restart; if the restart is successful and the process is still running after 60 seconds, set the crash counter to 0.

[0020] The beneficial effects of adopting the above-mentioned further solutions are as follows: The self-healing strategy, combined with an automatic version rollback mechanism, dynamically adjusts the recovery strategy based on the number of crashes. It also uses a time window mechanism to reset the crash counter, automatically restoring service when the application crashes without manual intervention. A version error marking mechanism prevents repeated switching to problematic versions, ensuring high availability while avoiding resource exhaustion. In actual testing, for occasional crashes (such as memory overflows), the average recovery time is less than 3 seconds; for persistent crashes caused by version defects, the success rate of automatic rollback to a stable version exceeds 98%, improving business availability to 99.99%.

[0021] Furthermore, the installation of multiple versions of the application is executed in an asynchronous thread and includes the following steps: In response to the installation request, an asynchronous task handle is created, and the task is delivered to the event loop via the uv_async_t mechanism; the installation request carries the installation package path parameter, metadata file and application binary; The process parses the metadata files and application binary in the installation package, extracting the application name, version number, build version, and startup command. It checks if an application with the same name already exists. If the application does not exist, it creates the application root directory, initializes the application information structure, assigns a minimum index number, adds the application to the version list, and proceeds to the decompression step. If the application already exists, it calculates the next available version index. If an available version index exists, it proceeds to the decompression step. If no available version index exists, it returns an installation failure message. The application information structure includes a doubly linked list node, a version list head, the currently running version index, the application name, running status, the current process PID, whether it should start automatically on boot, and a pointer to the manager instance. Unzip: Unzip the installation package to the target version directory, execute the installation script, and persist the version information to the version configuration file; Create a version information structure and add it to the application's version list; the version information structure includes a doubly linked list node, application name, version index, version number array, build version string, build timestamp, startup command, version installation path, crash counter, error flag, reserved flag, and pointer to the application's information; Update the application information configuration file to record the current version index and installation status, and ensure state consistency through atomic operations; The entire process involves triggering an installation completion event and returning the installation result via IPC.

[0022] Furthermore, the occupancy status of the version index is recorded using a 10-bit mask, with each bit of the mask corresponding to an index, where 1 indicates that it is occupied and 0 indicates that it is free. The specific methods for calculating the index of the next available version include: Use bitwise operations to quickly find the index of the next available version, and use the popcount instruction to query the number of versions.

[0023] The beneficial effects of adopting the above-mentioned further solutions are as follows: 1. Fast version switching and short service interruption time: Through multi-version pre-deployment, the version switching time is controlled within 1-5 seconds, and the actual service interruption time is only the process startup time (usually <2 seconds). Compared with the traditional "uninstall-install-start" process, the switching speed is improved by more than 10 times, which is better than the switching speed of containerized solutions, but without the additional overhead of containerization.

[0024] 2. Supports canary releases and A / B testing: The ability to coexist with multiple versions allows for the simultaneous deployment of multiple versions, dynamically switching based on traffic strategies, and supports canary release scenarios. For example, 10% of requests can be routed to the new version for verification, and a full switch can be made after successful verification, reducing the risk of version releases.

[0025] 3. Version auditing and traceability capabilities: Installation time, build version, and crash history for each version are persistently stored for easy post-event analysis. Historical version sequences can be quickly viewed using version masks, supporting compliance auditing requirements.

[0026] 4. Instead of the traditional version number naming, a fixed index mapping version directory management method is adopted. Bitmap masks are used to quickly allocate and query version usage status, enabling fast switching and independent management between versions and avoiding version conflicts.

[0027] 5. Define the standard installation package of tar.gz + info.ini, support custom deployment logic for installation script (install.sh), and support automated version directory creation and environment configuration.

[0028] A system is provided for a method of intelligent application lifecycle management, comprising: The management service module, as the core daemon process of the system, implements asynchronous task scheduling based on the libuv event loop and coordinates the collaborative work of various modules. The IPC communication module uses Unix Domain Socket to establish a local inter-process communication channel, with the communication path being / run / sfapp-manager-ctl.sock. It encapsulates control commands using AT command format and implements a 200-millisecond timeout response. The version management module is used to maintain the application version index table, supporting 10 versions with indexes 0-9 coexisting; each version is stored in an independent directory, and version metadata is recorded through the INI configuration file; The process monitoring module captures changes in the state of child processes through the SIGCHLD signal handling mechanism, calls waitpid to non-blocking poll to detect process exits, counts the number of crashes, and triggers a self-healing strategy. The command control module provides user-space command-line tools, parses user commands, and forwards them to the management service module via the IPC communication module. The storage management module manages application installation package storage, version installation directory, and persistent state files, using INI format to store runtime state. The persistent state files are generated by persisting state to the application information configuration file. The specific methods for persisting state to the application information configuration file include writing crash counters, error flags, and application state to the application information configuration file to ensure that the self-healing decision process remains effective after system restart.

[0029] The beneficial effects of this invention are as follows: The system employs a single-threaded event loop (libuv) to handle concurrent task management; time-consuming operations are executed asynchronously through a worker thread pool, without blocking the main process; the combination of Unix Domain Socket and AT command protocol results in a single IPC round-trip latency of <5ms, reducing latency by 80% compared to HTTP RESTful APIs. In high-frequency query scenarios (such as monitoring systems querying status every second), it can support higher QPS, meeting the real-time requirements of edge computing. Detailed Implementation

[0030] The specific embodiments of the present invention are described below to enable those skilled in the art to understand the present invention. However, it should be understood that the present invention is not limited to the scope of the specific embodiments. For those skilled in the art, various changes are obvious as long as they are within the spirit and scope of the present invention as defined and determined by the appended claims. All inventions utilizing the concept of the present invention are protected.

[0031] In one embodiment of the present invention, the intelligent application lifecycle management system includes: The management service module (sfapp-manager), as the core daemon process of the system, implements asynchronous task scheduling based on the libuv event loop and is responsible for coordinating the collaborative work of various modules; The IPC communication module uses Unix Domain Socket to establish a local inter-process communication channel, with the communication path being / run / sfapp-manager-ctl.sock. It encapsulates control commands using AT command format and implements a 200-millisecond timeout response. The version management module maintains an application version index table, supporting up to 10 versions running concurrently (index 0-9). Each version is stored in a separate directory (format: / userdata / sfapp-root / install / ).<app_name> / v <index>Version metadata (version number, build timestamp, startup command, etc.) is recorded through the INI configuration file. The process monitoring module captures changes in the state of child processes through the signal handling mechanism (SIGCHLD), calls waitpid to non-blocking poll to detect process exits, counts the number of crashes, and triggers a self-healing strategy. The command control module (sfapp-ctl) provides user-space command-line tools, parses user commands, and forwards them to the management service module via the IPC communication module. The storage management module manages the application installation package storage ( / userdata / sfapp-root / package), the version installation directory, and the persistent state files. It uses the INI format to store runtime states. The persistent state files are generated by persisting the state to the application information configuration file. The specific methods for persisting the state to the application information configuration file include writing crash counters, error flags, and application states to the application information configuration file to ensure that the self-healing decision process remains effective after the system restarts.

[0032] In its implementation, this system uses the libuv cross-platform event library to build a single-threaded event loop model. All time-consuming operations (installation, uninstallation, file I / O) are submitted to the worker thread pool via uv_async_t, and the main thread is returned via callback upon completion, avoiding blocking the event loop. A single management service can handle dozens of concurrent requests simultaneously.

[0033] This system uses Unix Domain Sockets as the transport layer, which reduces protocol stack overhead compared to TCP Sockets and lowers latency by more than 50% in local communication scenarios. It adopts AT command format (e.g., AT+START=xxx) as the application layer protocol, which is simple to parse, and the data packet for a single communication is less than 1KB, making it suitable for embedded environments.

[0034] This system uses a version index bitmap for management, employing a 10-bit mask (mask field) to record version occupancy. Each bit corresponds to an index, with 1 indicating occupied and 0 indicating free. When allocating a new version, free indexes are quickly found using bitwise operations, with a time complexity of O(1). The number of versions is counted using the popcount instruction, which is far more efficient than traversing the linked list.

[0035] This system employs a zero-polling process monitoring design, passively waiting for changes in the state of child processes using the Linux signal mechanism. This eliminates the need for active polling, resulting in near-zero CPU utilization. Signal handling functions only set flags; actual processing is performed within the event loop, thus avoiding signal safety issues.

[0036] The intelligent application lifecycle management method includes a multi-version installation process and a multi-version hot-swap process. The multi-version installation process includes the following steps: Step 1: The user initiates an installation request through the command control module, carrying the installation package path parameter (format: AT+INSTALL=).<package_path> The installation package is in tar.gz format and contains an info.ini metadata file and the application binary. Step 2: The IPC communication module receives the request, the management service module creates an asynchronous task handle, and the task is delivered to the event loop through the uv_async_t mechanism; Step 3: The version management module parses the info.ini file in the installation package, extracts the application name, version number, build version, and startup command, and checks if an application with the same name already exists. If the application does not exist, it creates the application root directory and initializes the application information structure (sfapp_app_info_t), adding it to the application linked list. If the application already exists, it calculates the next available version index. When calculating the next available version index, it calls the version index allocation algorithm: iterates through indices 0-9 to find the smallest unused index number. If the number of versions has reached the upper limit (10), it returns an installation failure. Step 4: Extract the installation package to the target version directory (install / )<app_name> / v <index>), execute the installation script (install.sh), and persist the version information to the version configuration file (v <index> / info.ini); Step 5: Create a version information structure (sfapp_app_edition_info_t), initialize fields such as version number, build timestamp, and startup command, and add it to the application's version list; Step 6: Update the application information configuration file (app_info.ini) to record the current version index and running status (0-idle / 1-success / 2-failure / 3-installing), and ensure status consistency through atomic operations; Step 7: Trigger the installation complete event and return the installation result via IPC. The entire process is executed in an asynchronous thread and does not block the main event loop.

[0037] In some embodiments, the multi-version hot-switching process includes the following steps: Step 1: Respond to the user-initiated startup request for the specified version (AT+START_INDEX=<app_name> , <index>) or restart request (AT+RESTART_INDEX=<app_name> , <index>); Step 2: The version management module searches for the application information structure based on the application name and verifies whether the target version index is valid (range 0-9 and the version is already installed). Step 3: The process monitoring module checks the current running status of the application. If the status is RUNNING (1) and the target version is different from the current version, the graceful stop process is triggered; if the status is FREE (0) or EXIT (3), the process jumps directly to the startup process. The graceful stop process includes: Step 3.1: Mark the application status as KILLING (2) and send a SIGTERM signal to the target process; Step 3.2: Start a timer (uv_timer_t) to check if the process has exited every 50 milliseconds, and wait for a maximum of 30 seconds (600 checks); if the process exits within the timeout period, reclaim resources using waitpid and proceed to step 4; if the process does not exit within the timeout period, send SIGKILL to forcibly kill the process, forcibly reclaim resources, and proceed to step 4. Step 4: Version Switching Preparation Step 4.1: Obtain the target version information structure (sfapp_app_edition_info_t) from the version list; Step 4.2: Read the version configuration file and load the startup command (start_cmd field); Step 4.3: Prepare environment variables, set LD_LIBRARY_PATH to point to the version's lib directory, and set the working directory to the version's root directory; Step 5: Process Startup Procedure: Step 5.1: Call fork() to create a child process, and the parent process saves the child process's PID to a version information structure; Step 5.2: The child process calls execvp() to replace the process image and executes the application startup command; Step 5.3: Update the application status to RUNNING and update using_edition_index to the target version index; Step 5.4: Persist the PID and status to app_info.ini, and call fsync to ensure that it is written to disk; Step 6: Register process monitoring: Add the new process PID to the monitoring list, set the SIGCHLD signal handler function, and start the health check timer; Step 7: Return the switching result. The entire switching process usually takes 1-5 seconds (depending on the application's downtime), achieving a near-hot-switch effect.

[0038] The purpose of setting the SIGCHLD signal processing function and starting the health check timer is to perform fault self-healing, which includes the following steps: Step 1: The process monitoring module captures the SIGCHLD signal through a signal handling function and sets the asynchronous wake-up flag in the signal handling context; Step 2: The event loop detects the wake-up flag and calls the process exit handling function in the main thread context: Step 2.1: Repeatedly call waitpid(-1,&status, WNOHANG) to non-block and reclaim all exited child processes; Step 2.2: Locate the corresponding application information structure and version information structure based on the PID; Step 3: Exit Reason Analysis: Step 3.1: If the application status is KILLING, it means that it has been actively stopped. Update the status to EXIT, clean up resources, and end the process. Step 3.2: If the application status is RUNNING, it indicates an abnormal exit and the self-healing decision process will begin. Step 4: Self-healing decision algorithm: Step 4.1: Read the crash_times (crash counter) and mark_err (error marker) fields of the version information; Step 4.2: Increment crash_times by 1. If crash_times < 3, execute the restart strategy; if crash_times >= 3 and crash_times < 10, mark mark_err as 1 and attempt to switch to the previous stable version (search for an unmarked error version through the version list); if crash_times >= 10 or all versions have been marked as errors, abandon automatic restart, record a critical failure log, and send an alarm event. Step 5: Restart execution: Step 5.1: Create a timer task to restart after a 1-second delay (to avoid rapid loop crashes); Step 5.2: Invoke the version startup process; Step 5.3: If the restart is successful, check if the process is still running after 60 seconds, then reset crash_times to 0; Step 6: State persistence: Write crash_times, mark_err and application state to the configuration file to ensure that the self-healing strategy remains effective after system restart.

[0039] The above process dynamically adjusts the recovery strategy based on the number of crashes: 0-2 crashes result in a direct restart of the current version; 3-9 crashes require switching to a historically stable version; and more than 10 crashes require manual intervention. Combined with a time window mechanism, if the application runs stably for more than 60 seconds, the counter is reset to prevent the accumulation of sporadic errors.

[0040] In some embodiments, a version rollback process is also provided, which includes the following steps: Step 1: The user identifies a problem with the new version and initiates a request to start the old version through the command control module; Step 2: The system automatically stops the currently running version and switches to the specified old version (reusing the hot-swap process); Step 3: Optional uninstallation of problematic versions: Send an uninstallation request for the specified version (AT+UNINSTALL_EDITION=<app_name> , <index>The version management module deletes the corresponding version directory and removes the version node from the version list; Step 4: The entire rollback process is completed in seconds, minimizing service interruption time.

[0041] In some embodiments, the application information structure (sfapp_app_info_t) includes: - list: doubly linked list nodes - edition_list: Header of the version list - using_edition_index: Index of the currently running version (-1 indicates it is not running). - name: Application name - status: Running status (0-Idle / 1-Running / 2-Stopping / 3-Exited) - pid: The PID of the current process - autostart: Whether to start automatically on boot. - mgr: A pointer to the manager instance.

[0042] The version information structure (sfapp_app_edition_info_t) includes: - list: doubly linked list nodes - name: Application name - edition_index: Version index (0-9) - ver[3]: Version number array (major version number, minor version number, revision number) - build_ver

[256] : Build version string - build_timestamp: Build timestamp - start_cmd: Startup command - edition_path: Version installation path - crash_times: Crash count statistics - mark_err: Error flag (1 indicates the version is unstable) - keep: Keep flag (1 indicates it cannot be deleted) - app_info: A pointer to the application information it belongs to.

[0043] In summary, this invention achieves efficient application management in resource-constrained environments through an event-driven asynchronous processing architecture, a lightweight IPC communication mechanism, and an intelligent version management strategy. It has the following advantages: low resource consumption, fast switching speed, strong fault self-healing capability, and simple operation, and completely solves the pain points of application management in embedded and edge computing scenarios in the prior art.< / index> < / index> < / index> < / index> < / index> < / index>

Claims

1. A method for intelligent application lifecycle management, characterized in that, This includes the following application version hot-switching process: In response to an application version launch or restart request, the application information structure is located based on the application name. The validity of the target version index is verified. If it is valid, the current running status of the application is checked. Otherwise, no action is taken. If the application is currently running in RUNNING state and the target version is different from the current version, the graceful shutdown process is triggered to prepare for version switching and enter the startup process. If the application is currently running in a FREE or EXIT state, then proceed directly to the startup process. The startup process includes the following steps: Call fork() to create a child process, and save the child process's PID to a version information structure through the parent process; The application startup command is executed by replacing the process image through a child process calling execvp(); Update the application status to RUNNING and update the running version index to the target version index; The PID and status of the child process are persisted to the application information configuration file, and the switching result is returned to complete the hot switching between multiple versions.

2. The intelligent application lifecycle management method according to claim 1, characterized in that, The graceful stop process includes the following steps: Mark the application status as KILLING and send a SIGTERM signal to the target process; Start a timer, set a maximum number of checks, and check every 50 milliseconds to see if the target process has exited. If the target process exits within the maximum number of checks, reclaim resources via waitpid and enter version switching preparation. Otherwise, if the target process does not exit within the maximum number of checks, send SIGKILL to forcibly kill the process, forcibly reclaim resources, and enter version switching preparation.

3. The intelligent application lifecycle management method according to claim 1, characterized in that, Version switching preparation includes the following steps: Retrieve the version information structure of the target version from the version list; Read the version configuration file from the version information structure of the target version and load the startup command; Prepare environment variables: set LD_LIBRARY_PATH to point to the target version's lib directory, and set the working directory to the target version's root directory.

4. The intelligent application lifecycle management method according to claim 1, characterized in that, The specific method for persisting the PID and status of a child process to the application information configuration file is as follows: The PID and state of the child process are persisted to the application information configuration file by calling fsync; After persisting the child process's PID and state to the application information configuration file, the following operations are also included: Add the child process's PID to the monitoring list, set the SIGCHLD signal handler function, and start the health check timer.

5. The intelligent application lifecycle management method according to claim 4, characterized in that, The specific steps for setting up the SIGCHLD signal handling function to start the health check timer include the following: The SIGCHLD signal is captured using the SIGCHLD signal handling function; the asynchronous wake-up flag is set in the SIGCHLD signal handling context. When the event loop detects the wake-up flag, it calls the process exit handling function in the main thread context: it calls waitpid in a loop to non-blockingly reclaim all exited child processes, and looks up the corresponding application information structure and version information structure according to the PID; Perform exit reason analysis: If the application status is KILLING, it is determined to be a voluntary stop, the status is updated to EXIT, resources are cleaned up and the process ends; if the application status is RUNNING, it is determined to be an abnormal exit and enters the self-healing decision process.

6. The intelligent application lifecycle management method according to claim 5, characterized in that, The self-healing decision-making process includes the following steps: Read the crash counter and error flag fields from the version information; Increment the current crash counter by 1; if the crash counter is less than 3, execute the restart strategy; if the crash counter is greater than or equal to 3 and less than 10, mark_err as 1 and attempt to switch the application to the previous stable version; where the stable version is the version that has not been marked as faulty; if the crash counter is greater than or equal to 10 or all versions have been marked as faulty, abandon the restart strategy, record it as a serious fault and send an alarm event.

7. The intelligent application lifecycle management method according to claim 6, characterized in that, The restart strategy includes the following steps: Create a timer task to perform a restart after a 1-second delay; Invoke the version startup process to restart; if the restart is successful and the process is still running after 60 seconds, set the crash counter to 0.

8. The intelligent application lifecycle management method according to claim 1, characterized in that, The installation of multiple versions of the application is executed in an asynchronous thread and includes the following steps: In response to the installation request, an asynchronous task handle is created, and the task is delivered to the event loop via the uv_async_t mechanism; the installation request carries the installation package path parameter, metadata file and application binary; The process parses the metadata files and application binary in the installation package, extracting the application name, version number, build version, and startup command. It checks if an application with the same name already exists. If the application does not exist, it creates the application root directory, initializes the application information structure, assigns a minimum index number, adds the application to the version list, and proceeds to the decompression step. If the application already exists, it calculates the next available version index. If an available version index exists, it proceeds to the decompression step. If no available version index exists, it returns an installation failure message. The application information structure includes a doubly linked list node, a version list head, the currently running version index, the application name, running status, the current process PID, whether it should start automatically on boot, and a pointer to the manager instance. Unzip: Unzip the installation package to the target version directory, execute the installation script, and persist the version information to the version configuration file; Create a version information structure and add it to the application's version list; the version information structure includes a doubly linked list node, application name, version index, version number array, build version string, build timestamp, startup command, version installation path, crash counter, error flag, reserved flag, and pointer to the application's information; Update the application information configuration file to record the current version index and installation status, and ensure state consistency through atomic operations; The entire process involves triggering an installation completion event and returning the installation result via IPC.

9. The intelligent application lifecycle management method according to claim 8, characterized in that, The usage status of the version index is recorded using a 10-bit mask, with each bit of the mask corresponding to an index, where 1 indicates that it is occupied and 0 indicates that it is free. The specific methods for calculating the index of the next available version include: Use bitwise operations to quickly find the index of the next available version, and use the popcount instruction to query the number of versions.

10. A system for the intelligent application lifecycle management method according to any one of claims 1 to 9, characterized in that, include: The management service module, as the core daemon process of the system, implements asynchronous task scheduling based on the libuv event loop and coordinates the collaborative work of various modules. The IPC communication module uses Unix Domain Socket to establish a local inter-process communication channel, with the communication path being / run / sfapp-manager-ctl.sock. It encapsulates control commands using AT command format and implements a 200-millisecond timeout response. The version management module is used to maintain the application version index table, supporting 10 versions with indexes 0-9 coexisting; each version is stored in an independent directory, and version metadata is recorded through the INI configuration file; The process monitoring module captures changes in the state of child processes through the SIGCHLD signal handling mechanism, calls waitpid to non-blocking poll to detect process exits, counts the number of crashes, and triggers a self-healing strategy. The command control module provides user-space command-line tools, parses user commands, and forwards them to the management service module via the IPC communication module. The storage management module is used to manage application installation package storage, version installation directory, and persistent state files, and stores runtime state in INI format; The state persistence file is the file generated by persisting the state to the application information configuration file. The specific methods for persisting the state to the application information configuration file include writing the crash counter, error flags and application state to the application information configuration file to ensure that the self-healing decision process remains effective after the system restarts.