Plug-in dynamic loading method and device, equipment and medium

Abstract

The invention discloses a plug-in dynamic loading method and device, equipment and a medium, and relates to the technical field of plug-in loading, and the method comprises the steps that a plug-in list is acquired, and the plug-in list comprises a plurality of plug-ins sorted according to priorities; monitoring the thread to obtain resource data; the plug-ins are loaded in sequence according to the priorities of the plug-ins; predicting a future resource demand value in real time according to the resource data; and uninstalling the plug-in with the lowest priority in the loaded plug-ins according to the future resource demand value. The plug-ins are sequentially loaded according to the priorities to guarantee that the core functions are preferentially available, and the loaded plug-ins with the lowest priority are unloaded in combination with the future resource demand value, so that core function starting delay and resource waste caused by traditional disordered loading can be avoided, redundant resources can be released in advance to balance the system load, and the system performance is improved. The system crash caused by resource overrun is effectively prevented, and the resource utilization efficiency and the operation stability of the application are remarkably improved.

Description

Technical Field

[0001] This application relates to the field of plug-in loading technology, specifically to a method, apparatus, device, and medium for dynamic plug-in loading. Background Technology

[0002] In the context of rapid iteration of application software and increasing demand for multi-scenario deployment, traditional application software architecture is still mainly based on static compilation mode. Although it can meet basic functional requirements, it is difficult to adapt to complex business scenarios and multi-platform usage requirements.

[0003] While some related technologies mention the concepts of modularity and dynamic loading, they do not form a complete solution for the actual operating characteristics of application software. Static compilation architecture means that when adding new functions or updating modules, the entire application needs to be repackaged, tested, and fully released. During loading, the traditional disordered loading causes delays in the startup of core functions and waste of resources, affecting resource utilization efficiency and operational stability. Summary of the Invention

[0004] This application provides a method, apparatus, device, and medium for dynamically loading plugins, aiming to solve the problem that new features in a static compilation architecture need to be repackaged and released, resulting in a long iteration cycle.

[0005] This application provides a method for dynamically loading plugins, including the following steps: Get the plugin list, which includes multiple plugins sorted by priority; Monitor threads and obtain resource data; Plugins are loaded sequentially according to their priority. Predict future resource demand in real time based on resource data; Uninstall the lowest priority plugin from the already loaded plugins based on future resource requirements.

[0006] In some embodiments, each plugin includes an initialization module and a function execution module; plugins are loaded sequentially according to their priority, including: The plugin status of each plugin in the plugin list is determined according to its priority, including loaded and unloaded status. If the plugin is not loaded, perform the initialization module loading for the plugin and change the plugin state to loaded. In response to receiving a trigger command, load the plugin's function execution module.

[0007] In some embodiments, the method further includes: When the plugin is already loaded, the plugin's function execution module is loaded in response to the received trigger command.

[0008] In some embodiments, the method further includes: The idle time of loaded plugins is obtained through the dynamic priority scheduling module; If the idle time exceeds a preset time threshold, uninstall the plugin.

[0009] In some embodiments, before monitoring threads and obtaining resource data, the method further includes: Initialize the dynamic priority scheduling module and configure resource thresholds.

[0010] In some embodiments, predicting future resource demand values ​​in real time based on resource data includes: Obtain resource data from multiple past time windows to form a resource consumption sequence; The resource consumption sequence is input into the prediction model to obtain the future resource demand value, which is used to characterize the resources that need to be consumed within a future time window.

[0011] In some embodiments, resource data includes at least one of processor utilization and memory utilization, and resource thresholds include at least one of processor utilization thresholds and memory utilization thresholds.

[0012] In some embodiments, the lowest-priority plugin among the already loaded plugins is uninstalled based on future resource requirements, including: If future resource demand exceeds the resource threshold, the lowest priority plugin among the already loaded plugins will be uninstalled.

[0013] In some embodiments, the plugin includes an interface abstraction layer, which serves as an interface for interfacing with different platforms.

[0014] In some embodiments, obtaining the plugin list includes: Perform compatibility testing on the plugins and compile a list of all plugins that pass the compatibility test.

[0015] Secondly, this application provides a plug-in dynamic loading device, comprising: The plugin retrieval module is used to retrieve a list of plugins, which includes multiple plugins sorted by priority. The monitoring module is used to monitor threads and obtain resource data based on the dynamic priority scheduling module; The plugin loading module is used to load plugins sequentially according to their priority. The resource forecasting module is used to predict future resource demand values ​​in real time based on resource data; The plugin uninstallation module is used to uninstall the lowest priority plugins among the already loaded plugins based on future resource requirements.

[0016] Thirdly, this application provides an electronic device, including a memory and a processor, wherein the memory stores a computer program that, when executed by the processor, implements the method described thereon.

[0017] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, the computer program being loaded by a processor to perform the steps in the method described.

[0018] Beneficial effects: This application ensures the priority availability of core functions by loading plugins sequentially according to their priority and unloading the lowest priority plugins that have already been loaded based on future resource requirements. This not only avoids the startup delay and resource waste caused by traditional disordered loading, but also releases redundant resources in advance to balance the system load, effectively preventing system crashes caused by resource overruns, and significantly improving the resource utilization efficiency and operational stability of the application. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a flowchart illustrating a method for dynamically loading plugins provided in some embodiments of this application; Figure 2 This is another flowchart illustrating the dynamic loading method for plugins provided in some embodiments of this application; Figure 3 This is a flowchart illustrating the sliding window algorithm of the plugin dynamic loading method provided in some embodiments of this application; Figure 4 This is a schematic diagram of the module hierarchical loading process of the plug-in dynamic loading method provided in some embodiments of this application; Figure 5 This is a schematic diagram illustrating the process of lazy loading of plugins in an application, based on some embodiments of the plugin dynamic loading method provided in this application. Figure 6 This is a flowchart illustrating the dynamic priority scheduling of the plugin dynamic loading method provided in some embodiments of this application; Figure 7 This is a flowchart illustrating the interface abstraction layer of the plugin dynamic loading method provided in some embodiments of this application; Figure 8 This is a flowchart illustrating the compatibility detection process of the plugin dynamic loading method provided in some embodiments of this application; Figure 9This is a schematic flowchart illustrating the cross-platform compatibility detection process of the plugin dynamic loading method provided in some embodiments of this application; Figure 10 This is a flowchart illustrating the namespace isolation of the plugin dynamic loading method provided in some embodiments of this application; Figure 11 This is a schematic diagram illustrating the process of plugin module development and packaging for the plugin dynamic loading method provided in some embodiments of this application; Figure 12 This is a schematic diagram illustrating the cross-platform deployment process of the plugin dynamic loading method provided in some embodiments of this application; Figure 13 This is a flowchart illustrating the global variable isolation of the plugin dynamic loading method provided in some embodiments of this application; Figure 14 This is a schematic diagram of the structure of the plug-in dynamic loading device provided in some embodiments of this application; Figure 15 These are schematic diagrams of the structure of electronic devices provided in some embodiments of this application.

[0021] Icon labels: 101. Plugin Acquisition Module; 102. Monitoring Module; 103. Plugin Loading Module; 104. Resource Prediction Module; 105. Plugin Unloading Module; 200. Electronic Equipment; 201. Memory; 202. Processor; 203. Communication Components; 204. Bus. Detailed Implementation

[0022] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0023] In the description of this application, it should be understood that the terms "center," "longitudinal," "lateral," "length," "width," "thickness," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicating orientation or positional relationships based on the orientation or positional relationships shown in the accompanying drawings, are used only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this application. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, features defined with "first" and "second" may explicitly or implicitly include one or more of the stated features. In the description of this application, "a plurality of" means two or more, unless otherwise explicitly specified.

[0024] "A and / or B" includes the following three combinations: A only, B only, and a combination of A and B.

[0025] The use of "applies to" or "configured to" in this application implies open and inclusive language, which does not exclude the applicability to or configuration to devices performing additional tasks or steps. Additionally, the use of "based on" implies openness and inclusivity, because processes, steps, calculations, or other actions "based on" one or more of the stated conditions or values ​​may in practice be based on additional conditions or values ​​beyond those stated.

[0026] In this application, the term "exemplary" is used to mean "used as an example, illustration, or description." Any embodiment described as "exemplary" in this application is not necessarily to be construed as being more preferred or advantageous than other embodiments. The following description is provided to enable any person skilled in the art to make and use this application. Details are set forth in the following description for purposes of explanation. It should be understood that those skilled in the art will recognize that this application can be made without using these specific details. In other instances, well-known structures and processes are not described in detail to avoid obscuring the description of this application with unnecessary detail. Therefore, this application is not intended to be limited to the embodiments shown, but is consistent with the broadest scope of the principles and features disclosed in this application.

[0027] This embodiment provides a method for dynamically loading plugins, such as... Figure 1 As shown, it includes the following steps: S101. Get the plugin list.

[0028] The plugin list includes multiple plugins sorted by priority. The plugin list is a list that stores all plugins and their related information. The plugin information can include core information such as plugin name, function type, dependent libraries, compatible platforms, and priority identifier. The plugins in the plugin list are sorted by priority identifier, with higher priority indicating more core plugins.

[0029] S102. Monitor the threads and obtain resource data.

[0030] By using an independent monitoring thread, resource data of each plugin thread during application operation is collected in real time to characterize the resource consumption status and provide data support for subsequent resource prediction.

[0031] S103. Load plugins in order of priority.

[0032] The installation priority order of plugins in the plugin list is prioritized, with high-priority plugins loaded first, followed by low-priority plugins as needed, thereby reducing application startup time.

[0033] S104. Predict future resource demand values ​​in real time based on resource data.

[0034] The future resource demand value represents the resource consumption in the next sampling period. Predicting the risk of resource consumption in advance can help avoid the risk of system crash due to resource exhaustion.

[0035] S105. Uninstall the lowest priority plugin among the already loaded plugins based on future resource requirements.

[0036] If future resource requirements are insufficient, uninstall the lowest priority plugins to release redundant resources that have already been consumed, thus preventing the core plugins from being uninstalled and causing functional interruptions, thereby improving resource utilization and long-term operational stability.

[0037] This embodiment also provides another method for dynamically loading plugins, such as... Figure 2 As shown, it includes the following steps: S201. Perform compatibility testing on the plugins and compile a list of all plugins that pass the compatibility test.

[0038] In some embodiments, each plugin includes an initialization module, a function execution module, and an unloading module, and corresponding initialization interfaces, function execution interfaces, and unloading interfaces are set, such as init(), execute(), and unload(). The initialization interface is used to call the initialization module to perform lightweight initialization of the plugin, such as registering plugin metadata. The function execution interface is used to call the function execution module to execute the core functions of the plugin. The unloading interface is used to call the unloading module to unload the plugin and release resources.

[0039] When the plugin involves resource operations such as file reading and writing, configuration loading, it is necessary to call the resource identifier to obtain the path instead of hardcoding it. For example, the resource identifier is IAL_Resource::getPath. When loading the plugin configuration file, the correct path will be automatically generated according to the current platform to ensure that the path is adapted without any anomalies when deployed across platforms.

[0040] The plugin also includes an interface abstraction layer, which serves as the interface for interfacing with different platforms. For example, when deployed on a Windows desktop application, the interface abstraction layer calls the Windows API to implement file read and write operations; when deployed on a Linux server application, it calls the POSIX API to implement file read and write operations. This enables cross-platform deployment of the same plugin.

[0041] The plugin also includes dynamic library files (.dll / .so), metadata (metadata.json), and dependency declarations (manifest.xml). The dynamic library files are the core files for the plugin's functionality, the metadata is used to detect the plugin's compatibility, and the dependency declarations are used to list the plugin's dependencies.

[0042] When performing compatibility testing on plugins, all plugins under a preset path are scanned, and the metadata of each plugin is parsed. The metadata includes relevant compatibility testing information, such as a list of compatible systems, minimum memory / disk requirements, dependent library versions, and CPU architecture support. The parsed metadata is stored in a metadata cache to avoid repeated parsing, which consumes resources and time.

[0043] Determine whether the currently deployed system meets the metadata requirements. If it does, the compatibility test is considered passed; otherwise, it is considered failed.

[0044] Filter out plugins that fail compatibility testing, summarize plugins that pass compatibility testing, and sort them according to plugin priority.

[0045] By filtering incompatible plugins in advance, application crashes, functional abnormalities, or resource conflicts caused by plugin incompatibility with the system can be avoided, ensuring basic system stability. This eliminates the need to load incompatible plugins and reduces unnecessary resource consumption.

[0046] S202. Initialize the dynamic priority scheduling module and configure resource thresholds.

[0047] The dynamic priority scheduling module is used to dynamically adjust the loading and unloading priorities of plugins. Resource thresholds include at least one of the following: sliding window size, processor utilization threshold, and memory utilization threshold.

[0048] The sliding window size represents the number of sampling points, used to subsequently calculate resource consumption trends; the processor utilization threshold and memory utilization threshold are the resource usage thresholds that trigger plugin uninstallation based on processor utilization and memory utilization, respectively.

[0049] S203. Monitor the threads and obtain resource data.

[0050] The resource data includes at least one of processor utilization and memory utilization.

[0051] S204. Load plugins in order of priority.

[0052] The plugin status of each plugin in the plugin list is determined according to the plugin priority. The plugin status includes loaded and unloaded. The loaded status indicates that the plugin has been loaded, and the unloaded status indicates that the plugin is waiting to be loaded.

[0053] When the plugin is not loaded, the initialization module is loaded and the plugin's state is changed to loaded. Only the initialization module is loaded, which realizes lightweight loading of the plugin and avoids loading all plugins and consuming resources.

[0054] In response to a received trigger command, the plugin's function execution module is loaded. When the main application needs to execute the plugin's corresponding function, it generates a trigger command. Upon receiving the trigger command, the function execution module is loaded to execute the plugin's core functionality.

[0055] When the plugin is already loaded, in response to a trigger command, the plugin's function execution module is loaded. If the plugin's initialization module is already loaded, the plugin's function execution module can be loaded directly to execute the plugin's core functionality.

[0056] By using a lazy loading strategy, only the plugin's initialization module is loaded, avoiding the need to load all plugins and consume resources.

[0057] S205. Get the idle time of the loaded plugins.

[0058] The dynamic priority scheduling module sets timers for loaded plugins to time their usage and idle time, thereby obtaining the idle time of the loaded plugins.

[0059] S206. Predict future resource demand values ​​in real time based on resource data.

[0060] Obtain resource data from multiple past time windows to form a resource consumption sequence; Among them, the resource consumption sequence is , For time window Internal resource data, , This is the size of the sliding window.

[0061] Each time window Resource data obtained from sampling Resource data is cached in a sliding window in chronological order, and the data is stored within the sliding window. If the quantity does not reach the size of the sliding window, new resource data will be added. Add to resource consumption sequence At the tail, construct a resource consumption sequence. Resource data within the sliding window When the number of data reaches the size of the sliding window, the earliest historical data is covered according to the first-in-first-out principle, and the sliding window always contains the resource data of the most recent 10 time windows to avoid data interference with trend judgment.

[0062] The resource consumption sequence is input into the prediction model to obtain the future resource demand value, which is used to characterize the resources that need to be consumed within a future time window.

[0063] In one embodiment, the formula for the prediction model can be expressed as: ,in This represents the future resource demand value for the next time window. This is a smoothing factor.

[0064] By analyzing resource data within the recent time window, such as processor and memory usage, we can calculate resource consumption trends, predict resource demands in the near future, and allow sufficient time for plugin uninstallation to avoid system crashes caused by high resource consumption.

[0065] S207. Uninstall the plugin with the lowest priority among the loaded plugins.

[0066] If future resource demand exceeds the resource threshold, the lowest priority plugin among the already loaded plugins will be uninstalled.

[0067] If the future resource demand for processor utilization exceeds the processor utilization threshold, it is determined that processor resources will be insufficient in the next time window. If the future resource demand for memory utilization exceeds the memory utilization threshold, it is determined that memory resources will be insufficient in the next time window. If either processor or memory resources are about to become insufficient, the plugin uninstallation step is triggered.

[0068] The priority of already loaded plugins is dynamically adjusted. The priority of each loaded plugin is calculated according to the following rules: ,in Priority As weight, The frequency of plugin usage. This is the resource data for the plugin. The weight takes values ​​of [0,1], and in one embodiment, the weight is 0.7.

[0069] Sort the loaded plugins by priority and uninstall the plugin with the lowest priority.

[0070] If multiple plugins have the same priority, their idle time will be compared, and the plugin with the longer idle time will be uninstalled.

[0071] In one embodiment, such as Figure 3 As shown, the steps of the sliding window algorithm in this application include: Threads are monitored; sampling is triggered in each time window using a timer to obtain processor or memory resource data, and the resource data within the sliding window is updated. If the amount of resource data within the sliding window does not reach the size of the sliding window, sampling continues, and new resource data is appended to the end of the resource consumption sequence to construct the resource consumption sequence. If the amount of resource data within the sliding window reaches the size of the sliding window, future resource requirements are predicted; if the predicted future resource requirements are greater than a preset resource threshold, sampling continues; if the predicted future resource requirements are less than the preset resource threshold, a resource alarm signal is sent, the lowest priority plugin is uninstalled, background tasks are delayed, and sampling continues.

[0072] In one embodiment, such as Figure 4 As shown, the module hierarchical loading steps of this application include: The application starts, loads the static core module, parses the module list, and determines whether a dynamic module needs to be loaded. If not, it directly enters the main interface. If it needs to be loaded, it registers the plugin metadata and listens for module request signals. It checks whether a loading signal has been received. If a loading signal is received, it checks whether the dependencies are met. If the dependencies are not met, it loads the dependent modules first and then the plugin. If the dependencies are met, it loads the plugin. It initializes the plugin instance, adds the plugin to the loaded list, and triggers the module ready signal.

[0073] In one embodiment, such as Figure 5 As shown, the steps of the plugin in this application to implement a lazy loading strategy include: The user interface is initialized; a virtual proxy button is created and a click signal is bound to the lazy-loaded module; when the user clicks the button, a click signal is generated; upon receiving a click signal, the module status is checked; if the module is loaded, the function execution module is loaded to perform the actual function; if the module is not loaded, the plugin initialization module is loaded, the plugin initialization is performed, and after initialization, the plugin is marked as loaded and a loading completion signal is sent; the function execution module is loaded to perform the actual function. If the user does not click the button, no click signal is generated; the idle state of loaded plugins is monitored, and if the idle time exceeds a preset idle threshold, the corresponding plugin is unloaded and the proxy state is reset.

[0074] In one embodiment, such as Figure 6 As shown, the steps of dynamic priority scheduling in this application include: After the application starts, high-priority plugins are statically loaded. A sliding window is then used for monitoring. Firstly, a lazy loading strategy is initialized to determine if user actions trigger plugin loading. If a user triggers a plugin loading command, the plugin is dynamically loaded, resource monitoring is updated, and the usage time of each plugin is recorded. The idle time of a plugin is checked against an idle threshold; if it exceeds the threshold, the plugin is uninstalled; otherwise, it remains loaded. Secondly, periodic resource predictions are performed to forecast future resource demands. If the future demand exceeds a resource threshold, lower-priority plugins are uninstalled to release resources; otherwise, the current state is maintained.

[0075] In one embodiment, such as Figure 7 As shown, the steps of the interface abstraction layer in this application include: The plugin calls a unified API (Application Programming Interface), which interfaces with different platforms through an interface abstraction layer. It determines the current platform: if it's Windows, it calls the Windows implementation, invoking the Win32 API adapted for Windows to achieve file path conversion and window transparency; if it's macOS, it calls the macOS implementation, invoking the Cocoa API adapted for macOS to achieve file path conversion and font rendering; if it's Linux, it calls the Linux implementation, invoking the X11 / Wayland API to achieve file path conversion and browser functionality. It returns a unified format result, which the plugin receives.

[0076] In one embodiment, such as Figure 8 As shown, the compatibility testing steps of this application include: The plugin's metadata is read from the plugin directory or metadata cache scanned during application startup. The metadata is parsed, and the operating system is detected. The system checks whether the OS (Operating System) type matches, whether the OS version is satisfactory, whether the CPU (Central Processing Unit) architecture is supported, whether the memory is sufficient, whether the disk space is sufficient, whether the GPU (Graphics Processing Unit) is satisfactory, and whether the QT version is compatible. If any one of these conditions is not met, the system is marked as incompatible; if all conditions are met, the system is marked as compatible.

[0077] In one embodiment, such as Figure 9 As shown, the cross-platform compatibility testing steps of this application include: The main application sends a loading request to the plugin and reads the plugin's metadata. The main application then initiates a system compatibility check with the interface abstraction layer, obtaining the corresponding system information through the interface abstraction layer. The system API reports the system status back to the interface abstraction layer, completing the system compatibility check. If the compatibility check passes, the plugin can be loaded normally. The plugin sends a file operation request to the interface abstraction layer, calls the corresponding interface through the system API, and ensures a consistent format structure. If the compatibility check fails, loading the plugin is skipped, and an incompatibility warning is displayed on the interface.

[0078] In one embodiment, such as Figure 10 As shown, the namespace isolation steps in this application include: During the compilation phase, exported symbols are defined, a symbol table is generated, and linker options are set.

[0079] During the plugin invocation phase, a plugin instance is created, an isolation container is initialized, thread-local storage is set up, dynamic libraries are loaded, and application symbol visibility control is implemented.

[0080] During the runtime phase, an independent object tree is created, plugin instances are mounted, plugin logic is executed, and it is determined whether the request is a global access request. If not, the plugin logic is re-executed; if so, it is redirected to TLS, accesses the isolation variable, and then returns to re-execute the plugin logic.

[0081] In one embodiment, such as Figure 11 As shown, the steps for developing and packaging the plugin module in this application include: Write plugin code, call the Interface Abstraction Layer (IAL) interface, and the platform implements dispatch. For Windows systems, call the Win32 API to generate the plugin.dll file; for Linux systems, call the POSIX API to generate the plugin.so file. Package the plugin.dll file and the plugin.so file into a metadata file metadata.json to form a complete plugin package.

[0082] In one embodiment, such as Figure 12 As shown, the steps for cross-platform deployment in this application include: For the same plugin code, if the compilation platform is Windows, the IAL_File_win.cpp file is called to generate the plugin.dll file; if the compilation platform is Linux, the IAL_File_linux.cpp file is called to generate the plugin.so file, so that the same metadata file metadata.json can be used.

[0083] In one embodiment, such as Figure 13 As shown, the steps for global variable isolation in this application include: During the plugin process, namespace isolation is implemented through independent file system views and independent grid lines. Behavior is monitored across different platforms. For Linux systems, monitoring is conducted through the eBPF (extended Berkeley Packet Filter) program, while for Windows systems, monitoring is conducted through ETW (Event Tracing for Windows) hooks. Illegal calls are intercepted and the violating process is terminated.

[0084] Secondly, such as Figure 14 As shown, this application provides a plugin dynamic loading device, including: a plugin acquisition module 101, a monitoring module 102, a plugin loading module 103, a resource prediction module 104, and a plugin unloading module 105.

[0085] The plugin acquisition module 101 is used to acquire a list of plugins, which includes multiple plugins sorted by priority; the monitoring module 102 is used to monitor threads based on the dynamic priority scheduling module and acquire resource data; the plugin loading module 103 is used to load plugins sequentially according to their priority; the resource prediction module 104 is used to predict future resource demand values ​​in real time based on resource data; and the plugin unloading module 105 is used to unload the lowest priority plugin among the loaded plugins based on future resource demand values.

[0086] Thirdly, such as Figure 15 As shown, an electronic device 200 is provided, characterized in that it includes: a memory 201 and a processor 202; The memory 201 stores computer-executed instructions; The processor 202 executes the computer execution instructions stored in the memory 201, causing the processor 202 to perform the above-described method.

[0087] In one embodiment, the electronic device 200 includes at least one processor 202 and a memory 201. Optionally, the electronic device 200 further includes a communication component 203. The processor 202, memory 201, and communication component 203 are connected via a bus 204.

[0088] In a specific implementation, at least one processor 202 executes computer execution instructions stored in memory 201, causing at least one processor 202 to perform the above-described method.

[0089] The specific implementation process of processor 202 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0090] In the above embodiments, it should be understood that the processor 202 can be a central processing unit (CPU), or other general-purpose processors 202, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor 202 can be a microprocessor 202, or any conventional processor 202. The steps of the method disclosed in this invention can be directly manifested as execution by the hardware processor 202, or execution by a combination of hardware and software modules in the processor 202.

[0091] The memory 201 may include high-speed memory 201 (random access memory, RAM) and may also include non-volatile memory 201 (NVM), such as at least one disk storage 201.

[0092] Bus 204 can be an industry standard architecture (ISA) bus 204, a peripheral component (PCI) bus 204, or an extended industry standard architecture (EISA) bus 204, etc. Bus 204 can be divided into address bus 204, data bus 204, control bus 204, etc. For ease of illustration, the bus 204 in the accompanying drawings of this application is not limited to only one bus 204 or one type of bus 204.

[0093] Fourthly, this application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by the processor 202, implement the above-described method.

[0094] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory 201 (SRAM), electrically erasable programmable read-only memory 201 (EEPROM), erasable programmable read-only memory 201 (EPROM), programmable read-only memory 201 (PROM), read-only memory 201 (ROM), magnetic storage 201, flash memory 201, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0095] An exemplary readable storage medium is coupled to a processor 202, enabling the processor 202 to read information from and write information to the readable storage medium. Alternatively, the readable storage medium can be an integral part of the processor 202. The processor 202 and the readable storage medium can reside in application-specific integrated circuits (ASICs). Alternatively, the processor 202 and the readable storage medium can exist as discrete components in the device.

[0096] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0097] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0098] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0099] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause an electronic device 200 (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0100] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0101] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0102] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0103] The above provides a detailed description of a plug-in dynamic loading method, apparatus, device, and medium provided in the embodiments of this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A plug-in dynamic loading method, characterized by, The method comprises the following steps: obtaining a plug-in list comprising a plurality of plug-ins sorted by priority; monitoring threads to obtain resource data; loading the plug-ins in turn according to the priority of the plug-ins; real-time predicting a future resource demand value according to the resource data; uninstalling the plug-in with the lowest priority among the loaded plug-ins according to the future resource demand value.

2. The method of claim 1, wherein, Each of the plug-ins comprises an initialization module and a function execution module; the loading of the plug-ins in turn according to the priority of the plug-ins comprises: determining the plug-in state of each of the plug-ins in the plug-in list in turn according to the priority of the plug-ins, the plug-in state comprising loaded and unloaded; when the plug-in is in the unloaded state, loading the initialization module of the plug-in and converting the plug-in state of the plug-in to loaded; loading the function execution module of the plug-in in response to receiving a trigger instruction.

3. The method of claim 2, wherein, The method further comprises: when the plug-in is in the loaded state, loading the function execution module of the plug-in in response to receiving the trigger instruction.

4. The method of claim 3, wherein, The method further comprises: obtaining the idle time of the loaded plug-in by a dynamic priority scheduling module; uninstalling the plug-in when the idle time is greater than a preset time threshold.

5. The method of claim 4, wherein, Before the monitoring of the threads to obtain the resource data, the method further comprises: initializing the dynamic priority scheduling module and configuring a resource threshold.

6. The method of claim 5, wherein, The real-time predicting of the future resource demand value according to the resource data comprises: obtaining the resource data in a plurality of past time windows to form a resource consumption sequence; inputting the resource consumption sequence into a prediction model to obtain the future resource demand value, the future resource demand value being used to represent the resource to be consumed in a future time window.

7. The method of claim 5, wherein, The resource data comprises at least one of processor usage and memory usage, and the resource threshold comprises at least one of a processor usage threshold and a memory usage threshold.

8. The method of claim 7, wherein, The uninstalling of the plug-in with the lowest priority among the loaded plug-ins according to the future resource demand value comprises: uninstalling the plug-in with the lowest priority among the loaded plug-ins when the future resource demand value is greater than the resource threshold.

9. The method of claim 1, wherein, The plug-in comprises an interface abstraction layer, which is used as an interface for connecting different platforms.

10. The method of claim 1, wherein, The obtaining of the plug-in list comprises: performing compatibility detection on the plug-ins and obtaining the plug-in list by aggregating all the plug-ins passing the compatibility detection.

11. A plug-in dynamic loading device, characterized in that, The method comprises: a plug-in obtaining module, configured to obtain a plug-in list comprising a plurality of plug-ins sorted by priority; a monitoring module, configured to monitor threads based on a dynamic priority scheduling module to obtain resource data; a plug-in loading module, configured to load the plug-ins in turn according to the priority of the plug-ins; a resource predicting module, configured to real-time predict a future resource demand value according to the resource data; a plug-in uninstalling module, configured to uninstall the plug-in with the lowest priority among the loaded plug-ins according to the future resource demand value.

12. An electronic device, comprising: A computer program product comprising a memory and a processor, said memory having stored thereon a computer program, said computer program being executable by said processor to implement the method of any of claims 1-10.

13. A computer-readable storage medium, characterized in that, A computer program product comprising a memory and a processor, said memory having stored thereon a computer program, said computer program being executable by said processor to implement the method of any of claims 1-10.

Images