Inter-process communication method and device, computer equipment and readable storage medium
By using virtual modules and proxy objects in Electron applications to capture and send function information to the main process, the problem of low efficiency in existing IPC communication is solved, achieving efficient inter-process communication and asynchronous response, thus improving system performance and user experience.
Patent Information
- Application Number
- CN202511775853.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-28
- Publication Date
- 2026-03-03
AI Technical Summary
Existing IPC communication methods require explicit definition of message processing logic in both the main process and child processes, resulting in low communication efficiency.
By loading a proxy object of a virtual module in a child process, function information is captured and sent to the main process. The main process executes the corresponding business logic based on the function information. Asynchronous communication is achieved using the proxy object and the commitment object, reducing the complexity of inter-process communication.
It improves the efficiency of inter-process communication, simplifies the module loading process, enhances code maintainability and system response speed, and ensures a better user experience.
Smart Images
Figure CN121597437A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the fields of desktop application development and inter-process communication technology, and in particular to a process communication method, apparatus, computer device, computer-readable storage medium, and computer program product. Background Technology
[0002] In Electron applications, communication between the main process and the rendering process (or child processes) is typically achieved through IPC mechanisms. The main process manages the application's lifecycle and system-level events, while the rendering process handles user interface logic. Existing IPC communication methods mainly include synchronous and asynchronous message passing.
[0003] Existing IPC communication methods require explicit definition of message processing logic in the main process and child processes, which results in low communication efficiency. Summary of the Invention
[0004] Therefore, it is necessary to provide an inter-process communication method, apparatus, computer device, computer-readable storage medium, and computer program product that can improve communication efficiency in response to the above-mentioned technical problems.
[0005] Firstly, this application provides an inter-process communication method, including:
[0006] In response to user-initiated commands for desktop applications, a main process and a corresponding child process are created.
[0007] The child process loads the required modules from the client's local directory, and if the loaded module is a virtual module, it loads the proxy object corresponding to the virtual module; the virtual module is the business service interface provided by the real module integrated by the main process.
[0008] The child process captures the function information stored in the virtual module loaded by the child process through the proxy object and sends it to the main process, so that the main process can execute the corresponding business logic according to the function information.
[0009] In one embodiment, after the child process captures the function information stored in the virtual module loaded by the child process through the proxy object and sends it to the main process, the method further includes:
[0010] The child process obtains the commitment object corresponding to the function information through the proxy object.
[0011] In one embodiment, the method further includes:
[0012] The child process receives the business logic execution results returned by the main process through the commitment object and caches them in the client's local directory.
[0013] In one exemplary embodiment, the child process loads the required modules from the client's local directory, including:
[0014] When a child process is detected to be starting, it loads the required modules from the client's local directory by overriding the require function.
[0015] In one embodiment, loading the proxy object corresponding to the virtual module includes:
[0016] The child process dynamically loads the proxy object corresponding to the virtual module as needed.
[0017] In one embodiment, the method further includes:
[0018] The child process captures new function information stored in the virtual module loaded by the child process through the proxy object;
[0019] Based on the identifier of the new function information, query the client's local directory to obtain the execution result of the business logic corresponding to the new function information.
[0020] Secondly, this application also provides an inter-process communication device, comprising:
[0021] The process creation module is used to respond to user-initiated calls to desktop applications and create the main process and the corresponding child processes.
[0022] The module loading module is used by the child process to load the required modules from the client's local directory, and, if the loaded module is a virtual module, to load the proxy object corresponding to the virtual module; the virtual module provides the business service interface to the real module integrated by the main process.
[0023] The inter-process communication module is used by the child process to capture function information stored in the virtual module loaded by the child process through the proxy object and send it to the main process, so that the main process can execute the corresponding business logic according to the function information.
[0024] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:
[0025] In response to user-initiated commands for desktop applications, a main process and a corresponding child process are created.
[0026] The child process loads the required modules from the client's local directory, and if the loaded module is a virtual module, it loads the proxy object corresponding to the virtual module; the virtual module is the business service interface provided by the real module integrated by the main process.
[0027] The child process captures the function information stored in the virtual module loaded by the child process through the proxy object and sends it to the main process, so that the main process can execute the corresponding business logic according to the function information.
[0028] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the following steps:
[0029] In response to user-initiated commands for desktop applications, a main process and a corresponding child process are created.
[0030] The child process loads the required modules from the client's local directory, and if the loaded module is a virtual module, it loads the proxy object corresponding to the virtual module; the virtual module is the business service interface provided by the real module integrated by the main process.
[0031] The child process captures the function information stored in the virtual module loaded by the child process through the proxy object and sends it to the main process, so that the main process can execute the corresponding business logic according to the function information.
[0032] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, performs the following steps:
[0033] In response to user-initiated commands for desktop applications, a main process and a corresponding child process are created.
[0034] The child process loads the required modules from the client's local directory, and if the loaded module is a virtual module, it loads the proxy object corresponding to the virtual module; the virtual module is the business service interface provided by the real module integrated by the main process.
[0035] The child process captures the function information stored in the virtual module loaded by the child process through the proxy object and sends it to the main process, so that the main process can execute the corresponding business logic according to the function information.
[0036] The aforementioned inter-process communication methods, apparatus, computer devices, computer-readable storage media, and computer program products, in response to user-initiated call commands for desktop applications, create a main process and a corresponding child process. The child process loads the required modules from the client's local directory, and, if the loaded module is a virtual module, loads the corresponding proxy object. The virtual module provides the business service interface to the real module integrated into the main process. Through the proxy object, the child process captures the function information stored in the virtual module loaded by the child process and sends it to the main process, enabling the main process to execute the corresponding business logic based on the function information. The child process achieves transparent calls to the main process's functions through the virtual module and the proxy object, reducing the complexity of inter-process communication and thus improving the efficiency of inter-process communication. Attached Figure Description
[0037] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.
[0038] Figure 1 This is a diagram illustrating the application environment of an inter-process communication method in one embodiment.
[0039] Figure 2 This is a flowchart illustrating an inter-process communication method in one embodiment;
[0040] Figure 3 This is a flowchart illustrating inter-process communication in one embodiment;
[0041] Figure 4 This is a block diagram of an inter-process communication device in one embodiment;
[0042] Figure 5 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation
[0043] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.
[0044] The inter-process communication method provided in this application can be applied to, for example... Figure 1The application environment is illustrated. The client's user interface displays a desktop application. When a user initiates a call command to the desktop, a corresponding main process and its child processes are created. The client responds to the user's call command to the desktop application, creating the main process and its corresponding child processes. The child processes load the required modules from the client's local directory. If the loaded module is a virtual module, it loads the corresponding proxy object. The virtual module provides the business service interface to the real module integrated into the main process. Through the proxy object, the child process captures the function information stored in the virtual module it loads and sends it to the main process, enabling the main process to execute the corresponding business logic based on the function information.
[0045] In one exemplary embodiment, such as Figure 2 As shown, an inter-process communication method is provided, which can be applied to... Figure 1 Taking the client as an example, the explanation includes the following steps S201 to S203. Wherein:
[0046] Step S201: In response to the user's call command for the desktop application, create the main process and the child process corresponding to the main process.
[0047] The main process can be understood as the process responsible for managing the application's lifecycle and system-level events, while the child process can be understood as the process responsible for handling user interface logic.
[0048] Optionally, the user initiates a call command for the desktop application on the client. In response to the call command, the client creates a main process for the call task and a child process corresponding to the main process to launch the desktop application and wait for the user to use it.
[0049] In step S202, the child process loads the required modules from the client's local directory, and if the loaded module is a virtual module, loads the proxy object corresponding to the virtual module; the virtual module is the business service interface provided by the real module integrated by the main process.
[0050] Among them, virtual modules can be understood as developing and debugging real modules to form different business services of real modules, and the main process integrates interfaces for different business services; proxy objects can be understood as a proxy entity that does not have a physical device.
[0051] For example, the child process uses the `rquire` function to load the functional modules required for the process to run from the client's local directory. If the functional module is a real module, it is loaded directly. If the functional module is a virtual module, the proxy object corresponding to the virtual module is dynamically loaded as needed.
[0052] In step S203, the child process captures the function information stored in the virtual module loaded by the child process through the proxy object and sends it to the main process, so that the main process can execute the corresponding business logic according to the function information.
[0053] Among them, function information can be understood as formal information, identifier information, execution information, etc. related to function association.
[0054] Optionally, the child process captures the function names and parameters stored in the virtual module loaded by the child process through a proxy object, generates a function call request with the function name and parameters, and sends it to the main process through the proxy object. The main process listens for function call requests through a message listener. When a request is heard, the main process executes the corresponding business logic according to the function name and parameters in the request, and returns the execution result of the business logic to the child process through IPC. The child process receives the execution result of the business logic, thus completing the inter-process communication.
[0055] In the aforementioned inter-process communication method, in response to a user-initiated call command for a desktop application, a main process and a corresponding child process are created. The child process loads the required modules from the client's local directory, and if the loaded module is a virtual module, it loads the corresponding proxy object. The virtual module provides the business service interface to the real module integrated into the main process. Through the proxy object, the child process captures the function information stored in the virtual module it loads and sends it to the main process, enabling the main process to execute the corresponding business logic based on the function information. The child process achieves transparent calls to the main process's functions through the virtual module and the proxy object, reducing the complexity of inter-process communication and thus improving its efficiency.
[0056] In one embodiment, after the child process captures the function information stored in the virtual module loaded by the child process through the proxy object and sends it to the main process, the method further includes: the child process obtaining the commitment object corresponding to the function information through the proxy object.
[0057] In this context, a commitment object can be understood as an object that represents the eventual completion (or failure) of an asynchronous operation and its resulting value.
[0058] Optionally, after the child process captures the function information stored in the virtual module loaded by the child process through the proxy object and sends it to the main process, the proxy object returns a promise object to the child process, enabling the child process to wait asynchronously for the response of the main process, avoiding blocking operations, improving the system's response speed and performance, and ensuring the user experience.
[0059] In one embodiment, the method further includes: the child process receiving the business logic execution result returned by the main process through a commitment object and caching it in the client's local directory.
[0060] For example, the child process receives the business logic execution result returned by the main process through the commitment object and caches it in the client's local directory. It receives and caches relevant data to provide a convenient data foundation for subsequent identical calls, thereby speeding up the response speed of instructions.
[0061] In one exemplary embodiment, the child process loads the required module from the client's local directory, including: when the child process is detected to have started, the child process loads the required module from the client's local directory by overriding the require function.
[0062] Overriding the require function can be understood as writing new custom logic into the client's existing module loading mechanism, which may include processing logic such as directly loading real modules and not directly loading virtual modules.
[0063] Optionally, upon detecting the start of a child process, the child process overrides the `require` function to load the required modules from the client's local directory. Specifically, if the module to be loaded is a real module, it is loaded directly; if the module to be loaded is a virtual module, the proxy object corresponding to the virtual module is loaded. By overriding the `require` function, the child process can load virtual modules, simplifying the module loading process and improving code maintainability.
[0064] In one embodiment, loading the proxy object corresponding to the virtual module includes: the subprocess dynamically loading the proxy object corresponding to the virtual module as needed.
[0065] For example, in a child process, the proxy object corresponding to the virtual module can be dynamically loaded as needed. This dynamic loading mechanism allows modules to be loaded or unloaded at runtime based on actual requirements, improving system flexibility and resource utilization.
[0066] In one embodiment, the method further includes: the child process capturing new function information stored in the virtual module loaded by the child process through a proxy object; and querying the client's local directory based on the identifier of the new function information to obtain the business logic execution result corresponding to the new function information.
[0067] Optionally, the child process captures new function information stored in the virtual module loaded by the child process through a proxy object. Based on the identifier of the new function information, it queries the client's local directory to obtain the execution result of the business logic corresponding to the new function information. If the corresponding result is found, it communicates with the main process in the manner described in the above embodiment to implement the corresponding function call. Through caching and querying mechanisms, the number of IPC communications is reduced, and the system response speed is improved.
[0068] In one exemplary embodiment, a specific implementation of inter-process communication is provided. Wherein:
[0069] Electron: A framework for developing cross-platform desktop applications, based on Node.js and Chromium.
[0070] IPC (Inter-Process Communication): Inter-process communication used to transfer data between different processes.
[0071] UUID (Universally Unique Identifier): A universally unique identifier used to identify a unique object.
[0072] CJS (CommonJS): A module specification primarily used in Node.js environments.
[0073] Proxy: A JavaScript object used to define custom behavior for basic operations (such as property lookup, assignment, etc.).
[0074] Main process steps:
[0075] 1. Define virtual modules:
[0076] By overriding the `require` function, child processes can load virtual modules. These virtual modules can be developed and debugged using real npm modules during the development phase, and achieve the same functionality when integrated into the main process.
[0077] 2. Use a Proxy object to capture function calls:
[0078] Use a Proxy object to capture function calls to virtual modules and send the call requests to the main process via IPC.
[0079] 3. The main process processes the request and returns the result:
[0080] The main process processes function call requests sent by child processes and returns the results via IPC.
[0081] In one embodiment, such as Figure 3 As shown, a communication flow for inter-application communication in desktop applications developed using the Electron framework is provided, wherein:
[0082] In a preferred embodiment:
[0083] 1. Rewrite the module loading and import the require function:
[0084] In the child process, override the `require` function to intercept module loading requests. When the child process attempts to load a module, check if the module is a virtual module. If it is a virtual module, return a proxy object instead of the actual module.
[0085] If it is not a virtual module, it will be processed according to the normal module loading process.
[0086] 2. Define virtual modules:
[0087] In child processes, the module loading mechanism is overridden, allowing them to load virtual modules. These virtual modules can be developed and debugged using real npm modules during the development phase, and achieve the same functionality when integrated into the main process.
[0088] 3. Capturing function calls:
[0089] Use a Proxy object to capture function calls to virtual modules. Each time a function is called, the proxy object sends the call request and parameters to the main process via IPC and returns a Promise object so that the child process can asynchronously wait for the main process's response.
[0090] 4. The main process processes the request and returns the result:
[0091] In the main process, define a message listener to receive function call requests sent by the child process. Based on the function name and parameters in the request, the main process executes the corresponding logic and returns the result to the child process via IPC. The child process receives the result through a Promise object and completes the call.
[0092] Detailed description of implementation steps:
[0093] 1. Override the require method:
[0094] Override the require method of the child process to make the module loading in the child process execute according to the preset mechanism.
[0095] 2. Define virtual modules:
[0096] When a child process starts, the module loading mechanism is rewritten so that the child process can load virtual modules.
[0097] Virtual modules are developed and debugged using real npm modules during the development phase, and achieve the same functionality when integrated into the main process.
[0098] 3. Capturing function calls:
[0099] Use a Proxy object to proxy virtual modules.
[0100] When a child process calls a function in a virtual module, the Proxy object captures the function call and sends the function name and parameters to the main process via IPC.
[0101] 4. The main process handles requests:
[0102] The main process sets up a message listener to receive function call requests sent by the child process.
[0103] Based on the function name and parameters in the request, the main process executes the corresponding logic and returns the result to the child process via IPC.
[0104] 5. Returned results:
[0105] The child process receives the result returned by the main process through the Promise object to complete the function call.
[0106] Expanding technical solutions:
[0107] 1. Dynamic module loading:
[0108] In child processes, virtual modules can be dynamically loaded as needed, eliminating the need to predefine all modules at startup. This dynamic loading mechanism allows modules to be loaded or unloaded at runtime based on actual requirements, improving system flexibility and resource utilization.
[0109] 2. Batch request processing:
[0110] In the main process, a batch request processing mechanism can be implemented. Frequent function call requests can be processed in batches, reducing the number of IPC communications and improving system performance.
[0111] 3. Caching mechanism:
[0112] In a child process, a result caching mechanism can be implemented. For repeated function call requests, the cached result can be returned directly, reducing the number of IPC communications and improving system response speed.
[0113] Compared with the prior art, this application has the following technical advantages:
[0114] 1. By rewriting the require function, child processes can load virtual modules, simplifying the module loading process and improving code maintainability.
[0115] 2. By using a Proxy object to capture function calls and sending the call requests to the main process via IPC, the transparency of the call process is improved and the code logic is simplified.
[0116] 3. Asynchronous communication is achieved through Promise and IPC, allowing child processes to wait for the main process's response, avoiding blocking operations and improving system response speed and performance.
[0117] 4. During the development phase, real npm modules are used for development and debugging. When integrated into the main process, the same functionality is achieved through virtual modules, which simplifies the development process and allows the development of child process modules to be completed independently, thus improving development efficiency.
[0118] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.
[0119] Based on the same inventive concept, this application also provides an inter-process communication device for implementing the inter-process communication method described above. The solution provided by this device is similar to the implementation described in the above method; therefore, the specific limitations in one or more embodiments of the inter-process communication device provided below can be found in the limitations of the inter-process communication method described above, and will not be repeated here.
[0120] In one exemplary embodiment, such as Figure 4 As shown, an inter-process communication device is provided, including: a process creation module 401, a module loading module 402, and a process communication module 403, wherein:
[0121] The process creation module 401 is used to create a main process and a child process corresponding to the main process in response to a user-initiated call command for a desktop application.
[0122] Module 402 is used by the subprocess to load the required modules from the client's local directory, and, if the loaded module is a virtual module, to load the proxy object corresponding to the virtual module; the virtual module is the business service interface provided by the real module integrated by the main process.
[0123] The process communication module 403 is used by the child process to capture the function information stored in the virtual module loaded by the child process through the proxy object and send it to the main process, so that the main process can execute the corresponding business logic according to the function information.
[0124] In one embodiment, after the child process captures the function information stored in the virtual module loaded by the child process through the proxy object and sends it to the main process, the inter-process communication device is also used for the child process to obtain the commitment object corresponding to the function information through the proxy object.
[0125] In one embodiment, the inter-process communication device is further configured to allow the child process to receive the business logic execution result returned by the main process through a commitment object and cache it in the client's local directory.
[0126] In one exemplary embodiment, the module loading module 402 is further configured to, upon detecting that a child process has started, have the child process load the required modules from the client's local directory by overriding the require function.
[0127] In one embodiment, module loading module 402 is also used for subprocesses to dynamically load proxy objects corresponding to virtual modules as needed.
[0128] In one embodiment, the inter-process communication device is further configured to allow the child process to capture new function information stored in the virtual module loaded by the child process through a proxy object; and to query the client's local directory based on the identifier of the new function information to obtain the execution result of the business logic corresponding to the new function information.
[0129] Each module in the aforementioned inter-process communication device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the operations corresponding to each module.
[0130] In one exemplary embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 5As shown, the computer device includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, Near Field Communication (NFC), or other technologies. When the computer program is executed by the processor, it implements an inter-process communication method. The display unit is used to form a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.
[0131] Those skilled in the art will understand that Figure 5 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.
[0132] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement:
[0133] In response to user-initiated commands for desktop applications, a main process and a corresponding child process are created.
[0134] The child process loads the required modules from the client's local directory, and if the loaded module is a virtual module, it loads the proxy object corresponding to the virtual module; the virtual module is the business service interface provided by the real module integrated by the main process.
[0135] The child process captures the function information stored in the virtual module loaded by the child process through the proxy object and sends it to the main process, so that the main process can execute the corresponding business logic according to the function information.
[0136] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program being implemented when executed by a processor:
[0137] In response to user-initiated commands for desktop applications, a main process and a corresponding child process are created.
[0138] The child process loads the required modules from the client's local directory, and if the loaded module is a virtual module, it loads the proxy object corresponding to the virtual module; the virtual module is the business service interface provided by the real module integrated by the main process.
[0139] The child process captures the function information stored in the virtual module loaded by the child process through the proxy object and sends it to the main process, so that the main process can execute the corresponding business logic according to the function information.
[0140] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements:
[0141] In response to user-initiated commands for desktop applications, a main process and a corresponding child process are created.
[0142] The child process loads the required modules from the client's local directory, and if the loaded module is a virtual module, it loads the proxy object corresponding to the virtual module; the virtual module is the business service interface provided by the real module integrated by the main process.
[0143] The child process captures the function information stored in the virtual module loaded by the child process through the proxy object and sends it to the main process, so that the main process can execute the corresponding business logic according to the function information.
[0144] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.
[0145] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.
[0146] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.
[0147] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.
Claims
1. An inter-process communication method, characterized in that, The method includes: In response to a user-initiated call command for a desktop application, a main process and a child process corresponding to the main process are created; The subprocess loads the required modules from the client's local directory, and if the loaded module is a virtual module, loads the proxy object corresponding to the virtual module; the virtual module provides the business service interface for the real module integrated by the main process. The subprocess captures the function information stored in the virtual module loaded by the subprocess through the proxy object and sends it to the main process, so that the main process executes the corresponding business logic according to the function information.
2. The method according to claim 1, characterized in that, After the child process captures the function information stored in the virtual module loaded by the child process through the proxy object and sends it to the main process, the method further includes: The subprocess obtains the commitment object corresponding to the function information through the proxy object.
3. The method according to claim 2, characterized in that, The method further includes: The child process receives the business logic execution result returned by the main process through the commitment object and caches it in the client's local directory.
4. The method according to claim 1, characterized in that, The subprocess loads the required modules from the client's local directory, including: When the start of the child process is detected, the child process loads the required modules from the client's local directory by overriding the require function.
5. The method according to claim 1, characterized in that, Loading the proxy object corresponding to the virtual module includes: The subprocess dynamically loads the proxy object corresponding to the virtual module as needed.
6. The method according to claim 3, characterized in that, The method further includes: The subprocess captures new function information stored in the virtual module loaded by the subprocess through the proxy object; Based on the identifier of the new function information, the client's local directory is queried to obtain the business logic execution result corresponding to the new function information.
7. An inter-process communication device, characterized in that, The device includes: The process creation module is used to respond to user-initiated call commands for desktop applications and create a main process and child processes corresponding to the main process. The module loading module is used by the subprocess to load the required modules from the client's local directory, and, if the loaded module is a virtual module, to load the proxy object corresponding to the virtual module; the virtual module provides the business service interface for the real module integrated by the main process. The process communication module is used by the child process to capture function information stored in the virtual module loaded by the child process through the proxy object and send it to the main process, so that the main process can execute the corresponding business logic according to the function information.
8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.
9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.
10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.