WO2025025528A1 - Application program control method and apparatus - Google Patents

Abstract

An application program control method and apparatus, said method comprising: injecting a first dynamic library into an application program by means of loading at startup (201); loading, as a plug-in, a second dynamic library into the application program (202); and in response to determining that injection of the first dynamic library is complete and loading the second dynamic library is complete, on the basis of the second dynamic library, calling a specified interface provided by the first dynamic library, and controlling a function provided by the first dynamic library (203).

Description

Application program control method and device

CROSS-REFERENCE TO RELATED APPLICATIONS

This patent application claims priority to the Chinese patent application filed on July 28, 2023, with application number 202310942825.4 and invention name “Application Control Method and Device”, the full text of which is incorporated by reference into this disclosure.

Technical Field

The present disclosure relates to the field of computer technology, specifically to the field of application development technology, and more particularly to an application control method and device.

Background Art

In the prior art, the methods of dynamically extending the capabilities of applications at runtime mainly include plug-in extension and dynamic library injection. Among them, plug-in extension is usually used to indicate plug-in technology implemented based on dynamic libraries, and dynamic library injection is a technology that uses "hooks" or other similar dynamic code injection technologies in the dynamic library to "hijack" or "overwrite" the original code in the application, or inject new code, to change or expand the original application when loading the dynamic library.

However, plug-in extensions can generally only provide corresponding capability extensions based on the agreed interface between them and the application, and cannot go deep into more basic functions; although dynamic library injection can inject code into the application at runtime without being restricted by the plug-in interface, thus going deep into the underlying functions of the application, dynamic library injection is not controlled by the application itself.

Summary of the invention

Embodiments of the present disclosure provide an application control method, apparatus, device, and storage medium.

In one or more embodiments, an application control method is provided, the method comprising: injecting a first dynamic library into the application by loading it at startup; injecting a second dynamic library into the application The dynamic library is loaded into the application in a plug-in manner; in response to determining that the injection of the first dynamic library is completed and the loading of the second dynamic library is completed, based on the second dynamic library, a specified interface provided by the first dynamic library is called to control the function provided by the first dynamic library.

In one or more embodiments, an application control device is provided, which includes: an injection module, configured to inject a first dynamic library into the application by loading it at startup; a loading module, configured to load a second dynamic library into the application as a plug-in; and a control module, configured to, in response to determining that the injection of the first dynamic library is completed and the loading of the second dynamic library is completed, call a specified interface provided by the first dynamic library based on the second dynamic library to control the functions provided by the first dynamic library.

In one or more embodiments, an electronic device is provided, which includes one or more processors; a storage device on which one or more programs are stored, and when the one or more programs are executed by the one or more processors, the one or more processors implement an application control method as in any of the above embodiments.

In one or more embodiments, a computer-readable medium is provided, on which a computer program is stored. When the program is executed by a processor, the application control method of any of the above embodiments is implemented.

It should be understood that the content described in this section is not intended to identify the key or important features of the embodiments of the present disclosure, nor is it intended to limit the scope of the present disclosure. Other features of the present disclosure will become easily understood through the following description.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG1 is an exemplary system architecture diagram in which the present disclosure may be applied;

FIG2 is a flow chart of an embodiment of an application control method according to the present disclosure;

FIG3 is an architecture diagram of an embodiment of an application control method according to the present disclosure;

FIG4a is a flow chart of an embodiment of an application control method according to the present disclosure;

FIG4 b is a flow chart of an application scenario of the application control method according to the present disclosure;

FIG4c is a flow chart of another application scenario of the application control method according to the present disclosure;

FIG5 is a flow chart of an embodiment of an application control device according to the present disclosure;

FIG. 6 is a schematic diagram of the structure of a computer system suitable for implementing a server of an embodiment of the present disclosure.

DETAILED DESCRIPTION

The following is a description of exemplary embodiments of the present disclosure in conjunction with the accompanying drawings, including various details of the embodiments of the present disclosure to facilitate understanding, which should be considered as merely exemplary. Therefore, it should be recognized by those of ordinary skill in the art that various changes and modifications may be made to the embodiments described herein without departing from the scope and spirit of the present disclosure. Similarly, for the sake of clarity and conciseness, descriptions of well-known functions and structures are omitted in the following description.

It should be noted that, in the absence of conflict, the embodiments and features in the embodiments of the present disclosure may be combined with each other. The present disclosure will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

FIG. 1 shows an exemplary system architecture 100 to which an embodiment of the application control method of the present disclosure can be applied.

As shown in Fig. 1, system architecture 100 may include terminal devices 101, 102, 103, network 104 and server 105. Network 104 is used to provide a medium for communication links between terminal devices 101, 102, 103 and server 105. Network 104 may include various connection types, such as wired, wireless communication links or optical fiber cables, etc.

The terminal devices 101, 102, 103 interact with the server 105 via the network 104 to receive or send messages, etc. Various communication client applications, such as storage applications, communication applications, etc., may be installed on the terminal devices 101, 102, 103.

Terminal devices 101, 102, 103 can be hardware or software. When terminal devices 101, 102, 103 are hardware, they can be various electronic devices with display screens, including but not limited to mobile phones and laptops. When terminal devices 101, 102, 103 are software, they can be installed in the electronic devices listed above. They can be implemented as multiple software or software modules (for example, to provide application control services), or they can be implemented as a single software or software module. No specific limitation is made here.

The server 105 may be a server that provides various services, for example, injecting the first dynamic library into the application by loading it at startup; loading the second dynamic library into the application as a plug-in; in response to determining that the injection of the first dynamic library is completed and the injection of the second dynamic library is completed, After the loading is completed, based on the second dynamic library, the specified interface provided by the first dynamic library is called to control the functions provided by the first dynamic library.

It should be noted that the server 105 can be hardware or software. When the server 105 is hardware, it can be implemented as a distributed server cluster consisting of multiple servers, or it can be implemented as a single server. When the server is software, it can be implemented as multiple software or software modules (for example, for providing application control services), or it can be implemented as a single software or software module. No specific limitation is made here.

It should be noted that the application control method provided in the embodiment of the present disclosure can be executed by the server 105, or by the terminal devices 101, 102, 103, or by the server 105 and the terminal devices 101, 102, 103 cooperating with each other. Accordingly, the various parts (such as various units, sub-units, modules, sub-modules) included in the application control device can be all set in the server 105, or all set in the terminal devices 101, 102, 103, or respectively set in the server 105 and the terminal devices 101, 102, 103.

It should be understood that the number of terminal devices, networks and servers in Figure 1 is only illustrative. Any number of terminal devices, networks and servers may be provided according to implementation requirements.

FIG2 shows a process 200 of an embodiment of an application control method that can be applied to the present disclosure. In this embodiment, the application control method includes the following steps:

Step 201: inject the first dynamic library into the application by loading it at startup.

In this embodiment, the execution entity (such as the server 105 or the terminal devices 101 , 102 , 103 shown in FIG. 1 ) can inject the first dynamic library into the application when the application is started.

Here, the first dynamic library injected into the application by the execution subject may override the code of the application itself or the code of the dynamic library on which the application depends, which is not limited in the present disclosure.

Specifically, in the Linux system, the first dynamic library preloaded when starting the application can be set by specifying the environment variable "LD_PRELOAD"; when the application is started, the specified first dynamic library will be loaded into the memory address space of the process before the execution of the application. The relevant code is as follows:

[Linux]LD_PRELOAD＝/my/dir/injected.so./a.out

Through the above method, it can be ensured that the target code in the first dynamic library (injected.so) is injected into the application before the application (a.out) is run.

Here, when the application is started, the execution subject may inject the first dynamic library into the application in a variety of specific ways, such as inline injection, overlay injection, etc.

Among them, inline injection is used to indicate that the code is directly injected into the original code location, thereby "hijacking" the original code; overlay injection is used to indicate that the function pointer in the function jump table or symbol table is overwritten and redirected to the target function.

Here, the object of overlay injection can be the application itself or a library function that the application depends on.

Furthermore, the first dynamic library may provide various types of designated interfaces, such as application program interfaces, callback interfaces, etc., for calling.

Step 202: Load the second dynamic library into the application program in a plug-in manner.

In this embodiment, the execution entity can load the second dynamic into the application in a plug-in manner, that is, load the second dynamic library, namely the plug-in dynamic library, and the plug-in interface function into the application, and the loaded application can call the functions in the second dynamic library through the plug-in interface function.

Specifically, in the GNU Linux system, the second dynamic library can be loaded through the dl library in glibc. In the dl library, the three commonly used library functions are dlopen (open dynamic library), dlclose (close dynamic library) and dlsym (search for famous symbols from the symbol table of the dynamic library). Usually, the second dynamic library, that is, the plug-in dynamic library, is loaded through dlopen, and the interface function with the pre-agreed interface name is found from the symbol table of the dynamic library through dlsym. After the second dynamic library and the plug-in interface function are loaded, the application can call the function in the plug-in dynamic library through the interface function. After the second dynamic library, that is, the plug-in dynamic library, is used, the second dynamic library can be unloaded through the dlclose function.

Step 203, in response to the completion of injection of the first dynamic library and loading of the second dynamic library, based on the second dynamic library, calling a specified interface provided by the first dynamic library to control the function provided by the first dynamic library.

In this embodiment, after determining that the injection of the first dynamic library is completed and the loading of the second dynamic library is completed, the execution subject can call the first dynamic library through the parameters in the second dynamic library to provide A specified interface, such as an API (Application Program Interface), controls all or part of the functions (for example, functions that are not enabled by default, functions that require calling an API to be triggered, etc.) in the first dynamic library injected into the application, that is, controls the application, that is, combines the underlying functions corresponding to the first dynamic library with the application, and provides the application with controllable underlying function extensions.

Here, the functions provided by the first dynamic library are generally functions that the second dynamic library does not have.

In some optional methods, based on the second dynamic library, the specified interface provided by the first dynamic library is called to control the function provided by the first dynamic library, including: based on the second dynamic library, the specified interface provided by the first dynamic library is called to perform at least one of the following control operations on the function provided by the first dynamic library: underlying function switch, monitoring, auditing, optimization configuration, and automatic control.

In this implementation, the execution entity can call the specified interface provided by the first dynamic library through the parameters in the second dynamic library, and perform at least one of the following control operations on the function provided by the first dynamic library, that is, the injection part in the application: underlying function switch, monitoring, auditing, optimization configuration, and automatic control.

This implementation method calls the specified interface provided by the first dynamic library based on the second dynamic library, and performs at least one of the following control operations on the function provided by the first dynamic library: underlying function switch, monitoring, auditing, optimized configuration, and automatic control, thereby realizing the control of multiple underlying functions and the expansion of application functions.

In some optional embodiments, the method further includes: in response to determining that the second dynamic library is removed, disabling a new function in the first dynamic library that is opened or enabled by the second dynamic library.

In this implementation, some functions in the first dynamic library are not enabled by default. After these functions are enabled due to loading the second dynamic library, the execution subject can monitor the status of the second dynamic library in real time or periodically. If the second dynamic library is removed, such as uninstalling the second dynamic library, the new functions in the first dynamic library that are enabled or enabled due to the second dynamic library will be disabled.

This implementation achieves “pluggability” of the new function by disabling the new function in the first dynamic library that is turned on or enabled by the second dynamic library in response to determining that the second dynamic library is removed.

In some optional embodiments, the method further includes: in response to determining that the application program injected by the first dynamic library or the library function on which the application program depends has changed, and the changed application program or the library function on which the application program depends is incompatible with the first dynamic library injection mode, only The first dynamic library is re-adapted.

In this implementation, if the code of the application's development library or the application itself changes, it needs to be recompiled, and the changed application's development library or application is incompatible with the injection method of the first dynamic library. At this time, the code of the first dynamic library must also be changed to adapt. Further, the adapted code is recompiled to ensure that the first dynamic library can still be used when the application itself or the dependent development library changes.

Specifically, when an application is updated from version 1.0 to version 2.0, the first dynamic library used in the original version 1.0 is no longer compatible with version 2.0. At this time, the source code of the first dynamic library needs to be modified to adapt to version 2.0. The modified first dynamic library can be used on version 2.0.

Usually, the plug-in interface of the application and the specified interface provided by the first dynamic library will not change, and the second dynamic library does not need to be re-adapted.

This implementation method responds to determining that an application injected with the first dynamic library or a library function on which the application depends has changed, and that the changed application or the library function on which the application depends is incompatible with the first dynamic library injection method, and only re-adapts the first dynamic library, thereby achieving timely updating of the first dynamic library, thereby achieving timely and effective control of the first dynamic library, and isolating the impact of the application change on the plug-in.

In some optional methods, based on the second dynamic library, the specified interface provided by the first dynamic library is called to control the functions provided by the first dynamic library, including: based on the second dynamic library, the specified interface provided by the first dynamic library and the interface of the application itself are called to control the functions provided by the first dynamic library.

In this implementation, the execution entity can call the specified interface provided by the first dynamic library through the parameters in the second dynamic library, such as API (Application Program Interface), and the interface of the application itself to control all or part of the functions (for example, functions that are not enabled by default, functions that require calling API to be triggered, etc.) in the first dynamic library injected into the application.

This implementation method controls the functions provided by the first dynamic library by calling the specified interface provided by the first dynamic library and the interface of the application itself based on the second dynamic library, that is, combining the underlying capabilities provided by the first dynamic library with the characteristics of the application itself, which helps Implementing advanced capabilities such as operation and maintenance automation will help further expand the underlying capabilities of the application.

Continuing to refer to FIG. 3 , FIG. 3 is an architecture diagram of an application scenario of the application control method according to this embodiment.

In the application scenario of Figure 3, in the Linux system, the first dynamic library preloaded when starting the application can be set by specifying the environment variable "LD_PRELOAD"; when the application (such as a.out) is started, the specified first dynamic library (such as injected.so) will be loaded into the memory address space of the process before the execution of the application, so as to realize the injection of the object code in the first dynamic library into the application. Among them, the first dynamic library can provide a specified interface that can be called, for example, an API interface. Further, the second dynamic library (such as plugin.so) is loaded into the application as a plug-in, and the loaded application can call the function in the second dynamic library based on the plug-in interface function. In response to determining that the injection of the first dynamic library is completed and the loading of the second dynamic library is completed, the execution subject calls the specified interface provided by the first dynamic library (such as injected.so) based on the second dynamic library (plugin.so) to control the function provided by the first dynamic library, that is, to control the application.

FIG4a shows a process 400 of another embodiment of the application control method that can be applied to the present disclosure. In this embodiment, the application control method includes the following steps:

Step 401: inject the first dynamic library into the application by loading it at startup.

In this embodiment, the implementation details and technical effects of step 401 can refer to the description of step 201 and will not be repeated here.

Step 402: Load the second dynamic library into the application program in a plug-in manner.

In this embodiment, the implementation details and technical effects of step 402 can refer to the description of step 202 and will not be repeated here.

Step 403: Based on the plug-in level parameters provided by the second dynamic library, a designated interface provided by the first dynamic library is called to control the functions provided by the first dynamic library.

In this embodiment, the execution subject can call the corresponding designated interface provided by the first dynamic library through the plug-in level parameters provided by the second dynamic library to control the functions provided by the first dynamic library.

The plug-in level parameters include at least one of the following: configuration parameters and status parameters.

Specifically, MySQL supports developers to develop plug-ins through the interface agreed upon by its plug-in system. However, MySQL's own memory management capabilities are relatively weak, and it does not provide an interface for overloading its underlying memory allocator. Currently, MySQL's memory usage audit can only be tracked through memory-related instruments in performance_schema (PFS for short, used to manage system views related to MySQL performance monitoring), but this relies on the fact that when the MySQL kernel is coded, all codes involving memory allocation and recovery must be explicitly associated with a PFS instrument. But in fact, there are a large number of memory allocation/recycling codes in MySQL that are not associated with PFS, which causes a huge deviation between the memory usage statistics of PFS and the actual memory usage. In addition, MySQL compiled based on the GNU Linux environment uses ptmalloc in the C standard library as the memory allocator by default. However, ptmalloc is relatively slow in recovering and returning memory fragments to the operating system. Therefore, in high-concurrency and high-load scenarios, OOM (Out Of Memory) problems caused by excessive MySQL memory usage often occur.

The default memory allocator of the FreeBSD system, jemalloc, has the characteristics of relatively timely memory fragmentation recovery and return to the operating system. In addition, the aforementioned "LD_PRELOAD+dynamic library injection" method can be used to overwrite the malloc/free and other library functions of the MySQL memory allocator at startup to take over the memory allocation/recycling operations of MySQL. That is, the first dynamic library (jemalloc) is injected into the application by loading at startup to alleviate the OOM phenomenon of MySQL.

In addition, jemalloc also provides a very rich API interface, which can realize functions such as real-time monitoring of memory allocation status (statistics APIs), auditing of memory allocation behavior (profiling APIs, common scenarios include: memory leak analysis, memory occupancy analysis, etc.), and memory recovery (dirty/muzzy decay APIs). However, these functions are not enabled by default, or require API calls to trigger, and the dynamic library injection method is "transparent" to MySQL itself. The MySQL kernel cannot perceive and actively call the jemalloc interface. In addition, although jemalloc has the ability to actively recycle memory and return it to the operating system, the triggering mechanism of memory recovery is still uncontrolled and cannot be managed through the MySQL interface itself. Therefore, even if jemalloc is used, MySQL still has a certain probability of generating OOM due to the untimely triggering of the memory recovery mechanism.

To solve the above problems, the my_jemalloc plug-in is developed based on the MySQL plug-in interface (the output is the dynamic library "my_jemalloc.so", that is, the second dynamic library, and the MySQL plug-in is named "jemalloc"), and the second dynamic library and the plug-in interface function are loaded into the application. Using the MySQL plug-in interface, a series of plug-in-level parameters are provided, through which the monitoring of the memory allocator and other advanced functions can be realized.

The MySQL plugin supports two types of parameters. One is called system parameters (i.e. "system variables"), which are named in the format of "plugin name (lowercase)_parameter name". This type of parameter is a configuration parameter and can be read and written. The other is called status parameters (i.e. "status variables"), which are named in the format of "plugin name (first letter uppercase)_parameter name". They are status monitoring (i.e. statistics) parameters and are read-only. The plugin my_jemalloc provides the following parameters:

The memory allocation status monitoring parameters (status parameters) of Jemalloc are named "Jemalloc_stats_xxx" and display the memory allocation status by calling the statistics APIs of jemalloc.

The memory recycling trigger parameter (system parameter) is named "jemalloc_manually_reclaim". When reading the parameter, the total amount of reclaimable physical memory is counted by accessing the statistics APIs of jemalloc; when writing any value to this parameter, the aging recycling of free memory pages is realized by calling the dirty/muzzy decay APIs of jemalloc.

Memory profiling switch parameter (system parameter), named "jemalloc_active_profiling". Jemalloc supports logging of memory allocation/recycling behavior, but this action has a great impact on performance and will occupy additional memory. Therefore, the my_jemalloc plugin does not enable this function by default. Users can manually enable it when they need to do memory analysis.

The memory log write parameter (system parameter, write-only) is named "jemalloc_dump_profiling" and is only available when memory profiling is turned on. When the user enters a writable profile file path to this parameter, the entire contents of the current jemalloc memory log can be dumped to this file.

The background memory reclaim thread switch parameter (system parameter), named "jemalloc_monitor_switch", is used to start or stop the automatic memory reclaim thread. The Jemalloc library itself provides the background memory reclaim thread function, but the jemalloc plug-in introduces its own background thread to implement the automatic memory reclaim strategy, and reclaims memory by explicitly calling the dirty/muzzy decay interface.

The polling interval parameter (system parameter) of the background memory recycling thread is named "jemalloc_monitor_interval". After the background thread is started, it will poll periodically according to the number of seconds set by this parameter to monitor whether the memory recycling action is automatically performed.

Memory high water level parameter (system parameter), named "jemalloc_high_water_mark". After the background thread is started, when the memory usage of the current MySQL instance reaches or exceeds the value specified by this parameter, the memory recycling action is automatically triggered (that is, calling dirty/muzzy decay APIs).

Through the above methods, on the one hand, the memory management capability is controllable and observable. In other words, users can accurately monitor the memory usage of MySQL by querying parameters such as Jemalloc_stats_xxx in the plug-in; and, by using profiling-related parameters, they can conduct a more accurate analysis of MySQL's memory allocation/recycling behavior. This expands MySQL's controllable memory observability capabilities that are far superior to its native PFS capabilities.

On the other hand, by managing the relevant parameters through the background thread, the configuration and start and stop of the automatic memory recovery strategy can be realized. In addition, by triggering the memory recovery behavior parameters, memory recovery driven by human intervention can also be realized. In other words, the my_jemalloc plug-in has expanded two sets of automatic/manual memory recovery strategies for MySQL, ensuring that the memory occupancy rate always runs below a certain expected water level, completely solving the OOM problem. Here, the process of the background memory recovery thread is specifically shown in Figure 4b.

In addition, the my_jemalloc plug-in also provides "pluggable" capabilities. When the plug-in is uninstalled, the advanced functions provided in the plug-in will be automatically disabled. The plug-in uninstallation process is shown in Figure 4c.

As can be seen from Figure 4, compared with the embodiment corresponding to Figure 2, the process 400 of the application control method in this embodiment reflects that in response to the completion of the injection of the first dynamic library and the completion of the loading of the second dynamic library, based on the plug-in level parameters provided by the second dynamic library, the specified interface provided by the first dynamic library is called to control the functions provided by the first dynamic library, and the plug-in level parameters include at least one of the following: state parameters, configuration parameters, which further realize the refined control and expansion of the underlying functions of the application.

Further referring to FIG. 5 , as an implementation of the methods shown in the above figures, the present disclosure provides an embodiment of an application control device, which is similar to the embodiment shown in FIG. Corresponding to the method embodiment, the device can be specifically applied to various electronic devices.

As shown in FIG. 5 , the application control device 500 of this embodiment includes: an injection module 501 , a loading module 502 and a control module 503 .

The injection module 501 may be configured to inject the first dynamic library into the application by loading it at startup.

The loading module 502 may be configured to load the second dynamic library into the application program in a plug-in manner.

The control module 503 may be configured to, in response to determining that the injection of the first dynamic library is completed and the loading of the second dynamic library is completed, call a specified interface provided by the first dynamic library based on the second dynamic library to control the function provided by the first dynamic library.

In some optional aspects of this embodiment, the control module is further configured to call a specified interface provided by the first dynamic library based on the plug-in level parameters provided by the second dynamic library to control the functions provided by the first dynamic library.

In some optional aspects of this embodiment, the control module is further configured to call a designated interface provided by the first dynamic library and an interface of the application program itself based on the second dynamic library to control the functions provided by the first dynamic library.

In some optional aspects of this embodiment, the device further includes: a closing module configured to close a new function in the first dynamic library that is opened or enabled by the second dynamic library in response to determining that the second dynamic library is removed.

In some optional modes of this embodiment, the control module is further configured to: based on the second dynamic library, call the specified interface provided by the first dynamic library, and perform at least one of the following control operations on the function provided by the first dynamic library: underlying function switch, monitoring, auditing, optimization configuration, and automatic control.

In some optional embodiments of this embodiment, the device also includes: a change module, which is configured to respond to determining that the application injected with the first dynamic library or the library function on which the application depends has changed, and the changed application or the library function on which the application depends is incompatible with the first dynamic library injection method, and only re-adapt the first dynamic library.

According to an embodiment of the present disclosure, the present disclosure also provides an electronic device and a readable storage medium.

As shown in FIG6 , it is a block diagram of an electronic device according to the application control method of an embodiment of the present disclosure.

600 is a block diagram of an electronic device according to an application control method of an embodiment of the present disclosure. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processing, cellular phones, smart phones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present disclosure described and/or required herein.

As shown in Figure 6, the electronic device includes: one or more processors 601, memory 602, and interfaces for connecting various components, including high-speed interfaces and low-speed interfaces. The various components are connected to each other using different buses, and can be installed on a common mainboard or installed in other ways as needed. The processor can process instructions executed in the electronic device, including instructions stored in or on the memory to display the graphical information of the GUI on an external input/output device (such as a display device coupled to the interface). In other embodiments, if necessary, multiple processors and/or multiple buses can be used together with multiple memories and multiple memories. Similarly, multiple electronic devices can be connected, and each device provides some necessary operations (for example, as a server array, a group of blade servers, or a multi-processor system). In Figure 6, a processor 601 is taken as an example.

The memory 602 is a non-transient computer-readable storage medium provided by the present disclosure. The memory stores instructions executable by at least one processor to enable the at least one processor to perform the application control method provided by the present disclosure. The non-transient computer-readable storage medium of the present disclosure stores computer instructions, which are used to enable a computer to perform the application control method provided by the present disclosure.

The memory 602 is a non-transient computer-readable storage medium that can be used to store non-transient software programs, non-transient computer executable programs and modules, such as program instructions/modules corresponding to the application control method in the embodiment of the present disclosure (for example, the injection module 501, the loading module 502 and the control module 503 shown in FIG. 5). The processor 601 executes the service by running the non-transient software programs, instructions and modules stored in the memory 602. The various functional applications and data processing of the device are implemented, that is, the application control method in the above method embodiment is implemented.

The memory 602 may include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function; the data storage area may store data created by the use of an electronic device controlled by an application, etc. In addition, the memory 602 may include a high-speed random access memory, and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some embodiments, the memory 602 may optionally include a memory remotely arranged relative to the processor 601, and these remote memories may be connected to the electronic device controlled by the application via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

The electronic device of the application control method may further include: an input device 603 and an output device 604. The processor 601, the memory 602, the input device 603 and the output device 604 may be connected via a bus or other means, and FIG6 takes the bus connection as an example.

The input device 603 can receive input digital or character information, such as a touch screen, a keypad, a mouse, a track pad, a touch pad, an indicator bar, one or more mouse buttons, a track ball, a joystick, and other input devices. The output device 604 may include a display device, an auxiliary lighting device (e.g., an LED), and a tactile feedback device (e.g., a vibration motor). The display device may include, but is not limited to, a liquid crystal display (LCD), a light emitting diode (LED) display, and a plasma display. In some embodiments, the display device may be a touch screen.

Various implementations of the systems and techniques described herein can be realized in digital electronic circuit systems, integrated circuit systems, dedicated ASICs (application specific integrated circuits), computer hardware, firmware, software, and/or combinations thereof. These various implementations can include: being implemented in one or more computer programs that can be executed and/or interpreted on a programmable system including at least one programmable processor, which can be a special purpose or general purpose programmable processor that can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device.

These computer programs (also called programs, software, software applications, or code) include machine instructions for a programmable processor and may be written using high-level procedural and/or object-oriented programming. Programming languages, and/or assembly/machine languages are used to implement these computer programs. As used herein, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, device, and/or means (e.g., disk, optical disk, memory, programmable logic device (PLD)) for providing machine instructions and/or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term "machine-readable signal" refers to any signal for providing machine instructions and/or data to a programmable processor.

To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user can provide input to the computer. Other types of devices can also be used to provide interaction with the user; for example, the feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including acoustic input, voice input, or tactile input).

The systems and techniques described herein may be implemented in a computing system that includes back-end components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes front-end components (e.g., a user computer with a graphical user interface or a web browser through which a user can interact with implementations of the systems and techniques described herein), or a computing system that includes any combination of such back-end components, middleware components, or front-end components. The components of the system may be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: a local area network (LAN), a wide area network (WAN), and the Internet.

A computer system may include clients and servers. Clients and servers are generally remote from each other and usually interact through a communication network. The relationship of client and server is generated by computer programs running on respective computers and having a client-server relationship to each other.

According to the technical solution of the embodiment of the present disclosure, the first dynamic library is injected into the application by loading at startup; the second dynamic library is loaded into the application in a plug-in manner; in response to determining that the injection of the first dynamic library is completed and the loading of the second dynamic library is completed, based on the first dynamic library, The second dynamic library calls the specified interface provided by the first dynamic library to control the functions provided by the first dynamic library, that is, by simultaneously loading the injected first dynamic library and the plug-in second dynamic library, the control and expansion of the underlying functions of the application are achieved.

It should be understood that the various forms of processes shown above can be used to reorder, add or delete steps. For example, the steps recorded in this application can be executed in parallel, sequentially or in different orders, as long as the desired results of the technical solution disclosed in this disclosure can be achieved, and this document is not limited here.

The above specific implementations do not constitute a limitation on the protection scope of the present disclosure. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions can be made according to design requirements and other factors. Any modification, equivalent substitution and improvement made within the spirit and principle of the present disclosure shall be included in the protection scope of the present disclosure.

Claims (14)

An application control method, the method comprising: Inject the first dynamic library into the application by loading it at startup; Loading the second dynamic library into the application program in a plug-in manner; In response to determining that the injection of the first dynamic library is completed and the loading of the second dynamic library is completed, based on the second dynamic library, a designated interface provided by the first dynamic library is called to control the function provided by the first dynamic library. The method according to claim 1, wherein the step of calling a specified interface provided by the first dynamic library based on the second dynamic library to control a function provided by the first dynamic library comprises: Based on the plug-in level parameters provided by the second dynamic library, the specified interface provided by the first dynamic library is called to control the functions provided by the first dynamic library, wherein the plug-in level parameters include at least one of the following: configuration parameters and state parameters. The method according to claim 1, wherein the step of calling a specified interface provided by the first dynamic library based on the second dynamic library to control a function provided by the first dynamic library comprises: Based on the second dynamic library, the specified interface provided by the first dynamic library and the interface of the application program itself are called to control the functions provided by the first dynamic library. The method according to claim 1, wherein the step of calling a specified interface provided by the first dynamic library based on the second dynamic library to control a function provided by the first dynamic library comprises: Based on the second dynamic library, the specified interface provided by the first dynamic library is called to perform at least one of the following control operations on the function provided by the first dynamic library: underlying function switch, monitoring, auditing, optimized configuration, and automatic control. The method according to any one of claims 1 to 4, further comprising: In response to determining that the second dynamic library is removed, a new function in the first dynamic library opened or enabled by the second dynamic library is disabled. The method according to any one of claims 1 to 4, further comprising: In response to determining that the application injected by the first dynamic library or the library function on which the application depends has changed, and the changed application or the library function on which the application depends is incompatible with the first dynamic library injection method, only the first dynamic library is re-adapted. An application control device, the device comprising: An injection module is configured to inject the first dynamic library into the application program by loading it at startup; A loading module configured to load the second dynamic library into the application in a plug-in manner; The control module is configured to, in response to determining that the injection of the first dynamic library is completed and the loading of the second dynamic library is completed, call a specified interface provided by the first dynamic library based on the second dynamic library to control the function provided by the first dynamic library. The device according to claim 7, wherein the control module is further configured to: Based on the plug-in level parameters provided by the second dynamic library, the specified interface provided by the first dynamic library is called to control the functions provided by the first dynamic library, wherein the plug-in level parameters include at least one of the following: configuration parameters and state parameters. The device according to claim 7, wherein the control module is further configured to: Based on the second dynamic library, the specified interface provided by the first dynamic library and the interface of the application program itself are called to control the functions provided by the first dynamic library. The device according to claim 7, wherein the control module is further configured to: based on the second dynamic library, call the specified interface provided by the first dynamic library to The functions provided by the first dynamic library perform at least one of the following control operations: underlying function switch, monitoring, auditing, optimized configuration, and automated control. The device according to any one of claims 7 to 9, wherein the device further comprises: The closing module is configured to close the new function in the first dynamic library opened or enabled by the second dynamic library in response to determining that the second dynamic library is removed. The device according to any one of claims 7 to 9, wherein the device further comprises: The change module is configured to re-adapt only the first dynamic library in response to determining that the application injected by the first dynamic library or the library function on which the application depends has changed, and the changed application or the library function on which the application depends is incompatible with the first dynamic library injection method. An electronic device, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor so that the at least one processor can perform the method according to any one of claims 1 to 6. A non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause the computer to execute the method according to any one of claims 1 to 6.