Plug-in management method and management device, electronic equipment and storage medium
By using plugin management thread and process isolation technology, parallel isolation between plugins and the main program is achieved, which solves the instability problem of the main program caused by static loading of plugins and improves the plugin's extensibility and user experience.
Patent Information
- Application Number
- CN202510884653.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-06-27
- Publication Date
- 2025-11-11
AI Technical Summary
In existing technologies, the plug-in mechanism uses a static loading method, which leads to instability in the main program, lacks isolation measures, affects user experience, and poses system risks. Furthermore, plug-in loading and unloading require restarting the main program, which affects the security of business data.
The plugin management thread periodically checks plugin files, and each plugin is created into an independent process using process isolation. The plugin management thread monitors the running status, achieving parallel isolation between plugins and the main program, and supporting dynamic loading and exception repair.
It improves the startup speed of the main program and the expansion capabilities of plugins, ensures the stable operation of the main program, reduces the impact of anomalies, and enhances user experience and system security.
Smart Images
Figure CN120929148A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of computer technology, and in particular to a plug-in management method and management device, electronic device, and storage medium. Background Technology
[0002] The plug-in mechanism is a core technology for enabling the expansion of desktop software functionality. Its purpose is to improve the flexibility and scalability of software through modular design. In existing technologies, the plug-in mechanism of desktop software generally adopts a static loading method, that is, all plug-in modules are loaded at once when the main program starts.
[0003] However, this design has significant drawbacks: Firstly, plugin code runs directly within the main program's context, lacking effective isolation mechanisms. When plugin code malfunctions, it can cause the main program to crash, reducing its stability, security, and fault tolerance. Secondly, plugin loading and unloading rely on restarting the main program. When users need to update features or fix plugin defects, the main program must be interrupted, impacting user experience and potentially leading to the loss of critical business data. Furthermore, traditional plugin management solutions typically involve interaction between the main program and plugins via shared memory or direct calls, lacking proactive monitoring of plugin status and failing to isolate faulty plugins in a timely manner, further exacerbating system risks. Summary of the Invention
[0004] In view of the above problems, the purpose of this application is to provide a plug-in management method, management device, electronic device, and storage medium, which can improve the plug-in expansion capability and hot expansion capability of the main program while ensuring the stable operation of the main program.
[0005] According to one aspect of this application, a plugin management method is provided, comprising: running a main program; loading a plugin management thread in the main program; detecting plugin files through the plugin management thread; and creating an independent plugin process for each detected plugin file through process isolation.
[0006] Optionally, the step of detecting plugin files includes: providing plugin standards; periodically scanning files; verifying the scanned files according to the plugin standards, and determining that the scanned file is the plugin file when the scanned file conforms to the plugin standards.
[0007] Optionally, the step of detecting plugin files further includes: creating a plugin directory; and when it is determined that the scanned file is the plugin file, filling the plugin directory according to the scanned file.
[0008] Optionally, creating an independent plugin process for each detected plugin file through process isolation includes: creating an independent plugin process through a multi-process module or a sub-process module.
[0009] Optionally, the steps of creating the plugin process include: defining a plugin interface; providing lifecycle methods; and creating a communication mechanism between the main program and the plugin process.
[0010] Optionally, the plugin management method further includes: monitoring the running status of the plugin process through the plugin management thread; and repairing the plugin process that is running abnormally, wherein repairing the plugin process that is running abnormally includes uninstalling, restarting, or replacing the plugin process.
[0011] Optionally, the plugin management method further includes: generating a log file based on the running status of the plugin process; and extracting and isolating the erroneous log file when the plugin process runs abnormally.
[0012] Optionally, the plugin management method further includes: uninstalling the corresponding plugin process when an uninstallation command is detected.
[0013] Optionally, the main program includes a graphical user interface program applied to a desktop system or an embedded system.
[0014] According to another aspect of this application, a plug-in management device is provided, wherein the plug-in management device is designed as a thread of the main program, and the plug-in management device includes: a detection unit for detecting plug-in files; and a control unit for creating an independent plug-in process for each detected plug-in file through process isolation.
[0015] According to a third aspect of this application, an electronic device is provided, comprising: a memory for storing program instructions; and a processor for reading and executing the program instructions to implement the plug-in management method as described in any of the preceding claims.
[0016] According to a fourth aspect of this application, a storage medium is provided, wherein a computer program or instructions are stored on the storage medium, and when the program or instructions are executed, implement the plug-in management method as described in any of the preceding claims.
[0017] According to the plugin management method, management device, electronic device, and storage medium provided in this application, the main program can be started without plugins, thus improving the startup speed of the main program and enhancing the user experience. After the main program starts, plugins are dynamically loaded through a plugin management thread. Furthermore, by isolating processes, an independent plugin process is created for each plugin file, allowing the plugin processes to run in parallel and in isolation from the main program. Even if a plugin malfunctions, it will not affect the main program. Therefore, while ensuring the stable operation of the main program, the plugin extensibility and hot-scalability of the main program can be improved. Attached Figure Description
[0018] The above and other objects, features and advantages of the present invention will become more apparent from the following description of embodiments of the invention with reference to the accompanying drawings, in which:
[0019] Figure 1 A schematic flowchart of the plug-in management method of this application is shown;
[0020] Figure 2 It shows Figure 1 A schematic flowchart illustrating the detection plugin file;
[0021] Figure 3 It shows Figure 1 A schematic flowchart illustrating the plugin creation process;
[0022] Figure 4 A schematic diagram showing the relationship between the main program and the plugin processes is provided.
[0023] Figure 5 A schematic structural diagram of the plug-in management device of this application is shown;
[0024] Figure 6 A schematic structural diagram of the electronic device of this application is shown. Detailed Implementation
[0025] Various embodiments of the invention will now be described in more detail with reference to the accompanying drawings. In the various drawings, the same elements are indicated by the same or similar reference numerals. For clarity, the various parts in the drawings are not drawn to scale.
[0026] Furthermore, certain terms are used in this specification and claims to refer to specific components. Those skilled in the art will understand that manufacturers may use different names to refer to the same component. This specification and claims do not distinguish components based on differences in name, but rather on differences in function.
[0027] It should be understood that in the following description, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.
[0028] It should also be noted that in the various methods and processes of this application, the order of the steps does not imply the order of execution, nor does it constitute any limitation on the implementation process of the embodiments of this application.
[0029] Figure 1 A schematic flowchart of the plugin management method of this application is shown. (Reference) Figure 1 The plugin management method provided in this application includes:
[0030] Step S11: Run the main program;
[0031] Step S12: Load the plugin management thread in the main program;
[0032] Step S13: Detect plugin files through the plugin management thread;
[0033] Step S14: Create an independent plugin process for each plugin file by means of process isolation;
[0034] Step S15: Determine whether an uninstallation command has been detected; and
[0035] Step S19: Uninstall the plugin process when an uninstallation command is detected.
[0036] The main program specifically refers to an application program for a desktop or embedded system. More specifically, it can include graphical user interface programs developed using frameworks such as Pyside2 and PyQt. Desktop system applications include, for example, office software and image processing tools, while embedded system applications include, for example, automotive central control systems or smart home control panels. In the plugin management method provided in this application, the main program does not need to load any plugins at startup, which improves the responsiveness of the main program during startup and thus enhances the user experience.
[0037] The plugin management thread can be a pre-written functional module within the main program. In the plugin management method provided in this application, after the main program starts and runs, the plugin management thread periodically checks the plugin files to achieve dynamic loading of plugins.
[0038] Upon detecting a plugin file, an independent plugin process is created for each plugin using process isolation, achieving physical isolation between the main program and the plugin process. Because the plugin's runtime environment runs in parallel and is isolated from the main program, even if a plugin malfunctions, it will not affect the main program. Therefore, while ensuring the stable operation of the main program, the plugin's extensibility and hot-scalability can be improved. The process isolation method can include multiprocessing or subprocessing. That is, the plugin process can run in parallel with the main program process through a multiprocessing module, or a subprocessing module can create a plugin process that runs parallel to the main program process. Process isolation allows the isolated plugin process to share system resources with the main program process.
[0039] It should be noted that in some embodiments, a reminder may be sent to the user after the plugin file is detected, and the corresponding plugin process may be created according to the user's instructions, which is more conducive to saving system resources.
[0040] When an uninstallation command is detected in step S15, step S19 is executed to uninstall the corresponding plugin process and reclaim resources. In some embodiments, the user may issue a directive to uninstall the corresponding plugin. In other embodiments, the system may issue an uninstallation command to uninstall the plugin when it detects that an update is needed. Accordingly, the system may also issue a corresponding command to create a new plugin process for the updated plugin.
[0041] Furthermore, in some embodiments, the plugin management method provided in this application can also provide a plugin monitoring mechanism. Specifically, the plugin management method further includes:
[0042] Step S16: Monitor the running status of the plugin process through the plugin management thread;
[0043] Step S17: Determine if the plugin process is running abnormally; and
[0044] Step S18: Repair the abnormal plugin process.
[0045] The plugin management thread has the ability to communicate with each plugin process. During plugin process execution, the plugin management thread can monitor each plugin process to determine if a plugin process is malfunctioning when it fails to respond properly, and then repair the malfunctioning plugin process. Malfunctioning plugin processes include plugin process crashes or timeouts. Repairing malfunctioning plugin processes can include uninstalling the plugin process, restarting the plugin process, or replacing the plugin process.
[0046] Furthermore, in some embodiments, the plugin management thread generates log files while monitoring each plugin process. When a plugin process malfunctions, the plugin management thread also extracts and isolates the erroneous log files, making it easier to maintain, troubleshoot, and optimize the performance of the main program and plugin processes.
[0047] Figure 2 It shows Figure 1 A schematic flowchart illustrating the detection of plugin files. Combined with... Figure 2 The detection of plugin files in step S13 above can include the following steps:
[0048] Step S21: Create the plugin directory;
[0049] Step S22, provide plug-in standards;
[0050] Step S23: Perform document scanning periodically;
[0051] Step S24: Verify the scanned files according to the plugin standard, and if the scanned file conforms to the plugin standard, determine that the scanned file is a plugin file; and
[0052] Step S25: Fill in the plugin directory according to the plugin file.
[0053] The plugin directory provides a unified storage location for verified plugin files. It should be noted that, in the embodiments of this application, the plugin directory can be a subdirectory under the main program installation directory. Unified management of plugins is achieved by providing a unified storage location for plugin files.
[0054] For example, the plugin directory could include / plugins / <plugin_name> ` / plugin_main.py`. The ` / plugins` directory is the main directory for plugin files, where they are centrally stored for unified management.<plugin_name> The directory is a separate directory for each plugin, and its name is the plugin's name. Each / <plugin_name> The ` / plugin_main.py` file in the directory is used to define the plugin's initialization functions or core logic. When the plugin is loaded, this file is executed to implement the corresponding plugin functionality.
[0055] A plugin standard is a reference standard used by the plugin management thread to identify plugin files. In some embodiments, the plugin standard may be a provided plugin interface or annotation; only when a scanned file implements the plugin interface or has the annotation in the plugin standard is it considered a plugin file corresponding to the current main program. In still other embodiments, the plugin standard may be a directory framework; only when the structure of a scanned file matches this directory framework is it considered a plugin file corresponding to the current main program.
[0056] Periodic file scanning can promptly discover and verify new plugin files. In some embodiments, the scanning object can be the entire installation file of the main program, avoiding plugin omissions due to improper storage of plugin files. In other embodiments, the scanning object can be a specified temporary cache directory, saving system resources used for scanning. Accordingly, when a new file is provided to the main program, it needs to be specified that the file is stored in the temporary cache directory by default. When the plugin management thread scans and finds a newly stored file in the temporary cache directory, it verifies whether the file is a plugin file. If the file is verified to be a plugin file, it is copied to the plugin directory, and the temporary cache directory is cleaned up. The principle of "verify before storing" can reduce the number of invalid files and avoid system bloat. In addition, in some embodiments, the scanning method can be a timed polling method, periodically scanning and comparing the file list to determine if there are new files. In other embodiments, the scanning method can be an event listener or a combination of both to scan for new files; this application does not impose too many limitations on this comparison.
[0057] Furthermore, it should be noted that the aforementioned plugin directory is only used to provide storage addresses for plugin files. When a new plugin process needs to be created based on user instructions, or when a plugin process needs to be created for a newly detected plugin file, the plugin management thread creates a new plugin process based on the already verified plugin files in the plugin directory, and enables that plugin process to run independently.
[0058] Figure 3 It shows Figure 1 A schematic flowchart illustrating the plugin creation process. Combined with... Figure 3 The process of creating the plugin in step S14 above can include:
[0059] Step S31, define the plugin interface;
[0060] Step S32, providing plugin lifecycle methods; and
[0061] Step S33: Establish a communication mechanism between the main program and the plugin process.
[0062] The plugin interface defined here refers to the interaction specifications between the main program and the plugin process. It defines how the plugin process interacts with the main program. In some embodiments, the IPlugin interface can be used.
[0063] The communication mechanism is the way data is exchanged and commands are passed between the main program and the plugin process. In this application, the main program and the plugin can be regarded as parallel processes, so they can communicate with each other through an IPC channel, specifically through multiprocessing.Pipe or socket communication.
[0064] The lifecycle approach refers to the standard method for the entire process of a plugin process, from creation to uninstallation. For example, the plugin process's initialization logic can be executed by calling the on_load() function, the core functionality can be executed by calling the on_execute() function, and resource release and cleanup can be performed by calling the on_unload() function before the plugin process is uninstalled.
[0065] By constructing a unified interface definition, lifecycle, and communication mechanism, an environmental foundation is provided for the dynamic loading, execution, unloading, and replacement of plugins, which is conducive to providing compatibility, scalability, and stability between plugin processes and between plugin processes and the main program.
[0066] Figure 4 A schematic diagram illustrating the relationship between the main program and plugin processes is shown. According to the plugin management method provided in this application, the main program is started without plugins, thus improving its startup speed and enhancing user experience. After the main program starts, plugins are dynamically loaded on demand through a plugin management thread. Furthermore, by isolating processes, an independent plugin process is created for each plugin file, allowing the plugin processes to run in parallel and in isolation from the main program. Even if a plugin malfunctions, it will not affect the main program. Therefore, while ensuring the stable operation of the main program, the plugin extensibility and hot-scalability of the main program can be improved.
[0067] Furthermore, a communication mechanism is established between the main program and each plugin process, facilitating monitoring of each plugin process by the plugin management thread. When a plugin process malfunctions, the corresponding plugin process is automatically uninstalled, replaced, or restarted, enabling adaptive repair of the plugin process and further improving the stability of the main program.
[0068] This application also provides a plug-in management device. This plug-in management device can be designed as a thread of the main program, such as the plug-in management thread described above. Figure 5 A schematic structural diagram of the plug-in management device of this application is shown.
[0069] refer to Figure 5 The plugin management device 100 may include a detection unit 110 and a control unit 120. The detection unit 110 is used to detect plugin files. In some embodiments, the detection unit 110 may include a scanning module and a verification module. The scanning module scans the main program's system directory or a specified temporary cache directory to determine whether a new file has been provided to the main program. The verification module stores plugin standards and verifies the scanned files according to these standards. If verification is successful, the scanned file is determined to be a plugin file compatible with the main program and loadable. The control unit 120 creates an independent plugin process for each detected plugin file through process isolation. This process isolation method may include, for example, multiprocessing or subprocessing. When a new plugin file is detected, or when a user instruction is received, the control unit 120 creates a corresponding plugin process according to a preset interface definition, lifecycle method, and communication mechanism.
[0070] According to the plugin management device provided in this application, the main program can be started without plugins, thus improving the startup speed of the main program and enhancing the user experience. After the main program starts, plugins are dynamically loaded on demand through a plugin management thread. Furthermore, by isolating processes, an independent plugin process is created for each plugin file, allowing the plugin process to run in parallel and in isolation from the main program. Even if a plugin malfunctions, it will not affect the main program. Therefore, while ensuring the stable operation of the main program, the plugin extensibility and hot-scalability of the main program can be improved.
[0071] Figure 6 A schematic structural diagram of the electronic device of this application is shown. The electronic device 10 is, for example, a computer. (Reference) Figure 6 The electronic device 10 may specifically include a processor 11, a memory 12, a power supply 13, a communication interface 14, an input / output interface 15, and a communication bus 16. The memory 12 stores program instructions. These program instructions can be read and executed by the processor 11 to implement the plug-in management method provided in this application, thereby achieving any of the aforementioned beneficial effects.
[0072] Furthermore, this application also discloses a computer-readable storage medium for storing computer programs or instructions. When the computer program or instructions are executed by a processor, they implement the aforementioned plug-in management method. Specific steps of this method can be found in the corresponding content disclosed in the foregoing embodiments, and will not be repeated here.
[0073] As described above, these embodiments of this application do not exhaustively cover all details, nor do they limit this application to specific embodiments. Clearly, many modifications and variations can be made based on the above description. This specification selects and specifically describes these embodiments to better explain the principles and practical applications of this application, thereby enabling those skilled in the art to effectively utilize this application and its modifications. The scope of protection of this application should be determined by the scope defined in the claims of this application.
Claims
1. A plug-in management method, wherein, include: Run the main program; The plugin management thread is loaded in the main program; The plugin management thread detects plugin files. as well as Each detected plugin file is isolated into a separate plugin process.
2. The plug-in management method according to claim 1, wherein, The steps for detecting the plugin file include: Provide plug-in standards; Perform periodic document scans; and The scanned file is verified according to the plugin standard, and if the scanned file conforms to the plugin standard, the scanned file is determined to be the plugin file.
3. The plug-in management method according to claim 2, wherein, The step of detecting the plugin file also includes: Create a plugin directory; and When it is determined that the scanned file is the plugin file, the plugin directory is populated according to the scanned file.
4. The plug-in management method according to claim 1, wherein, The method of creating an independent plugin process for each detected plugin file through process isolation includes: creating an independent plugin process through a multi-process module or a sub-process module.
5. The plug-in management method according to claim 1, wherein, The steps for creating the plugin process include: Define the plugin interface; Provide lifecycle methods; and Establish a communication mechanism between the main program and the plugin process.
6. The plug-in management method according to claim 5, wherein, The plugin management method also includes: The plugin management thread monitors the running status of the plugin process; and Repair the abnormal plugin process. The repair of the abnormal plugin process includes uninstalling, restarting, or replacing the plugin process.
7. The plug-in management method according to claim 6, wherein, The plugin management method also includes: Generate log files based on the running status of the plugin process; and When the plugin process malfunctions, the erroneous log file is extracted and isolated.
8. The plug-in management method according to claim 1, wherein, The plugin management method also includes: When an uninstallation command is detected, the corresponding plugin process is uninstalled.
9. The plug-in management method according to claim 1, wherein, The main program includes a graphical user interface program applied to desktop or embedded systems.
10. A plug-in management device, wherein, The plug-in management device is designed as a thread of the main program, and the plug-in management device includes: The detection unit is used to detect plugin files; and The control unit is used to create an independent plugin process for each of the detected plugin files through process isolation.
11. An electronic device, wherein, include: Memory, used to store program instructions; as well as A processor for reading and executing the program instructions to implement the plug-in management method as described in any one of claims 1 to 9.
12. A storage medium, wherein, The storage medium stores a computer program or instructions, which, when executed, implement the plug-in management method as described in any one of claims 1 to 9.