Cross-process communication method and device, equipment and storage medium
By determining the communication scenario and selecting the target process under the electron framework, cross-process communication is achieved, and the problems of high communication costs and insufficient support are solved under the framework, and a unified and easy-to-use process communication tool is provided.
Patent Information
- Application Number
- CN202411522373.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-10-29
- Publication Date
- 2025-03-25
AI Technical Summary
The cross-process communication under the electron framework has limitations such as high implementation cost, lack of support for complex communication, and inability to implement cross-process communication. In particular, the child processes created through fork can only communicate with the process that created it, and lack cross-process communication capabilities.
By responding to cross-process communication needs, determine the current communication scenario, and determine the target process based on the scenario, and conduct cross-process communication through the target process. The specific steps include getting events or messages in the rendering process or child process, parsing and processing to complete communication.
It solves the problem of cross-process communication under the electron framework, provides unified process communication capabilities, blocks underlying process differences, and transparent cross-process communication details, making it convenient for developers to use.
Smart Images
Figure CN119690695A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of communication technology, and in particular to a cross-process communication method, apparatus, device and storage medium. Background Art
[0002] The current cross-process communication under the electron framework mainly relies on the ipc channel (inter-process communication channel) provided by electron. ipcMain (IPC module of the main process) is provided in the main process, which can register methods through handle and listen to events through listen; ipcRenderer (IPC module of the rendering process) is provided in the rendering process, which can call methods through invoke, send events, and listen to events. The above scheme only supports simple cross-process communication, such as the rendering process directly calling the main process method. However, when it comes to complex cross-process communication, the implementation cost will be very high, such as the main process calling the rendering process method, and the rendering process calling other rendering process methods. At the same time, the above scheme also lacks support for other types. For example, the child process created by fork (derived child process) can only communicate with the process that created it, and does not have the ability to communicate across processes. Therefore, how to solve the cross-process communication under the electron framework has become an urgent problem to be solved. Summary of the invention
[0003] The main purpose of this application is to provide a cross-process communication method, device, equipment and storage medium, aiming to solve the technical problems of cross-process communication under the electron framework.
[0004] To achieve the above objectives, the present application proposes an inter-process communication method, which includes: In response to cross-process communication requirements, determine the current communication scenario; Determine a target process according to the current communication scenario; Inter-process communication is performed through the target process.
[0005] In one embodiment, the step of performing inter-process communication through the target process includes: When the target process is a rendering process and it is detected that the rendering process has a communication demand, obtaining a rendering event sent by the rendering process; triggering a rendering listener according to the rendering event, so that the rendering listener parses the rendering event to obtain a first parsing result; A first calling function is determined according to the first parsing result, event processing is performed through the first calling function, and the event processing result is sent to the rendering process to complete cross-process communication.
[0006] In one embodiment, the step of performing inter-process communication through the target process includes: When the target process is a subprocess and it is detected that the subprocess has a communication demand, obtaining a subprocess message sent by the subprocess; triggering a sub-process listener according to the sub-process message, so that the sub-process listener parses the sub-process message to obtain a second parsing result; A second calling function is determined according to the second parsing result, message processing is performed through the second target calling function, and the message processing result is sent to the child process to complete cross-process communication.
[0007] In one embodiment, the step of performing inter-process communication through the target process includes: When the target process is a calling process, obtaining process calling information sent by the calling process; Generate a process call message according to the process call information and the preset routing table, and send the process call message to the service process, so that the service process calculates the target return value according to the code file and the process call message and feeds back; Upon receiving the target return value sent by the service process, sending a call response message to the calling process corresponding to the target return value, so that the calling process updates the asynchronous call result and feeds back according to the call response message; When it is detected that the asynchronous call result is a call success result, the cross-process communication is completed.
[0008] In one embodiment, the step of generating a process call message according to the process call information and a preset routing table includes: Parsing the process call information to determine the corresponding process method name and process parameter information; Perform a process query according to the preset routing table and the process method name to obtain a process query result; When the process query result is a successful query result, the process method name and the process parameter information are serialized to obtain a process call message.
[0009] In one embodiment, the step of performing inter-process communication through the target process includes: When the target process is a service process to be registered, obtaining a monitoring event parameter sent by the service process to be registered; Parsing the monitoring event parameters to determine the corresponding process identification code; The process identification code is recorded in the target monitoring table to perform cross-process communication.
[0010] In one embodiment, the step of performing inter-process communication through the target process includes: When the target process is a listening process, obtaining an event broadcast message sent by the calling process; Determine the corresponding monitoring process according to the broadcast monitoring table and the event broadcast message; The event broadcast message is sent to the listening process, so that the listening process triggers the corresponding processing file according to the event broadcast message to perform cross-process communication.
[0011] In addition, to achieve the above-mentioned purpose, the present application also proposes an inter-process communication device, the inter-process communication device comprising: A response module is used to respond to the cross-process communication requirements and determine the current communication scenario; A processing module, used for determining a target process according to the current communication scenario; The communication module is used for performing cross-process communication through the target process.
[0012] In addition, to achieve the above-mentioned purpose, the present application also proposes a cross-process communication device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, and the computer program is configured to implement the steps of the cross-process communication method described above.
[0013] In addition, to achieve the above-mentioned purpose, the present application also proposes a storage medium, which is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by the processor, the steps of the cross-process communication method described above are implemented.
[0014] In addition, to achieve the above-mentioned purpose, the present application also provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, the steps of the cross-process communication method described above are implemented.
[0015] This application determines the current communication scenario in response to cross-process communication needs; determines the target process according to the current communication scenario; and performs cross-process communication through the target process. By responding to different cross-process communication needs, and then determining the corresponding cross-process communication scenarios, and then performing cross-process communication according to the target process corresponding to the cross-process communication scenario, the cross-process communication problem under the electron framework is solved, and a unified process communication capability is provided to different processes, while shielding the underlying process differences, making the cross-process communication details transparent, and providing developers with convenient and easy-to-use process communication tools. BRIEF DESCRIPTION OF THE DRAWINGS
[0016] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.
[0017] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.
[0018] Figure 1 A flowchart of the first embodiment of the cross-process communication method of the present application is provided; Figure 2 The overall structural diagram provided for the first embodiment of the cross-process communication method of the present application; Figure 3 A schematic diagram of an event monitoring process provided in Example 1 of the cross-process communication method of the present application; Figure 4 A schematic diagram of an event broadcast process provided in Example 1 of the cross-process communication method of the present application; Figure 5 A flowchart of the second embodiment of the cross-process communication method of the present application is provided; Figure 6 A schematic diagram of a method call flow provided for the second embodiment of the cross-process communication method of the present application; Figure 7 A schematic diagram of a method registration process provided for Embodiment 2 of the cross-process communication method of this application; Figure 8 A brief flowchart of the cross-process communication method provided in Example 1 of the present application; Fig. 9 This is a schematic diagram of the module structure of the inter-process communication device according to an embodiment of the present application; Fig.10 A schematic diagram of the device structure of the hardware operating environment involved in the cross-process communication method in the embodiment of the present application.
[0019] The purpose, features and advantages of this application will be further described in conjunction with the embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION
[0020] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of the present application and are not used to limit the present application.
[0021] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.
[0022] The main solution of the embodiment of the present application is: in response to the cross-process communication demand, determine the current communication scenario; determine the target process according to the current communication scenario; and perform cross-process communication through the target process.
[0023] The current cross-process communication under the electron framework mainly relies on the ipc channel (inter-process communication channel) provided by electron. ipcMain (IPC module of the main process) is provided in the main process, which can register methods through handle and listen to events through listen; ipcRenderer (IPC module of the rendering process) is provided in the rendering process, which can call methods through invoke, send events, and listen to events. The above scheme only supports simple cross-process communication, such as the rendering process directly calling the main process method. However, when it comes to complex cross-process communication, the implementation cost will be very high, such as the main process calling the rendering process method, and the rendering process calling other rendering process methods. At the same time, the above scheme also lacks support for other types. For example, the child process created by fork (derived child process) can only communicate with the process that created it, and does not have the ability to communicate across processes. Therefore, how to solve the cross-process communication under the electron framework has become an urgent problem to be solved.
[0024] This application determines the current communication scenario in response to cross-process communication needs; determines the target process according to the current communication scenario; and performs cross-process communication through the target process. By responding to different cross-process communication needs, and then determining the corresponding cross-process communication scenarios, and then performing cross-process communication according to the target process corresponding to the cross-process communication scenario, the cross-process communication problem under the electron framework is solved, and a unified process communication capability is provided to different processes, while shielding the underlying process differences, making the cross-process communication details transparent, and providing developers with convenient and easy-to-use process communication tools.
[0025] It should be noted that the execution subject of this embodiment may be a computing service device with data processing, network communication and program running functions, such as a tablet computer, a personal computer, a mobile phone, etc., or a cross-process communication device capable of realizing the above functions, etc. The following takes the cross-process communication device as an execution subject as an example, such as the main process, to illustrate this embodiment and the following embodiments.
[0026] Based on this, the present application embodiment provides a cross-process communication method, referring to Figure 1 , Figure 1 This is a flowchart of the first embodiment of the inter-process communication method of the present application.
[0027] In this embodiment, the inter-process communication method includes steps S10 to S30: Step S10, in response to the cross-process communication requirement, determining the current communication scenario; It should be noted that if Figure 2As shown, this embodiment mainly consists of two modules, namely RpcCenter (Remote Procedure Call Center) located in the main process and RpcAgent (Remote Procedure Call Agent) located in each sub-process. RpcCenter is the event center, responsible for responding to the function registration and call, event broadcast and monitoring of each RpcAgent; RpcAgent is responsible for providing functional interfaces to developers, encapsulating messages, and initiating calls to RpcCenter of the main process.
[0028] It can be understood that the cross-process communication demand refers to the need for data exchange and message passing between different processes in a multi-process application. The current communication scenarios include communication scenarios between rendering process and main process, communication scenarios between sub-process and main process, method registration scenarios, method calling scenarios, event listening scenarios, and event broadcasting scenarios.
[0029] In a specific implementation, the main process responds to the need for data exchange and message passing between different processes, and then determines the corresponding communication scenario based on the need for data exchange and message passing between different processes in a multi-process application. For example, when the rendering process needs to communicate with the main process, the current communication scenario is determined to be the communication scenario between the rendering process and the main process.
[0030] Step S20, determining a target process according to the current communication scenario; It can be understood that the target process refers to the process corresponding to the current communication scenario. For example, when the current communication scenario is the rendering process and the main process communication scenario, the process with communication requirements is determined to be the rendering process, that is, the target process is the rendering process.
[0031] Step S30: performing inter-process communication through the target process.
[0032] In the specific implementation, after the target process is determined, it is necessary to use appropriate communication mechanisms and methods to realize data exchange and message passing between these processes. For example, in Electron applications, the IPC (Inter-Process Communication) mechanism is usually used to realize the communication between the main process and the rendering process through the ipcMain and ipcRenderer modules.
[0033] In a feasible implementation, step S30 may include steps A31 to A33: Step A31, when the target process is a rendering process and it is detected that the rendering process has a communication demand, obtaining a rendering event sent by the rendering process; It should be noted that the rendering process refers to a type of process in modern browsers or multi-process applications, which is mainly responsible for user interface rendering and user interaction. The rendering event refers to the RpcMessage event, which is used for the message passing mechanism in the Remote Procedure Call (RPC) system.
[0034] In the specific implementation, when the target process is the rendering process and it is detected that the rendering process has a communication need with the main process, it indicates that the rendering process wants to send a message to the main process, and then calls ipcRenderer.send (a method used in the Electron framework to send messages from the rendering process to the main process) to send an RpcMessage event, so that the main process obtains the RpcMessage event sent by the rendering process.
[0035] Step A32, triggering a rendering listener according to the rendering event, so that the rendering listener parses the rendering event to obtain a first parsing result; It can be understood that the rendering listener refers to setting a listener in the main process to listen to messages from the rendering process, and when a specific message event occurs, the listener will trigger a predefined processing function and execute the corresponding logic. The first parsing result refers to the parsing result of the rendering event.
[0036] In a specific implementation, when the main process obtains the RpcMessage event sent by the rendering process, the listener for monitoring the rendering process is triggered, and then the RpcMessage event is parsed by the listener for monitoring the rendering process, and finally the parsing result of the rendering event, i.e., the first parsing result, is obtained.
[0037] Step A33, determining a first calling function according to the first parsing result, performing event processing through the first calling function, and sending the event processing result to the rendering process to complete cross-process communication.
[0038] It can be understood that the first calling function refers to the calling processing function corresponding to the first parsing result, and the event processing result refers to the result of the first calling function processing the RpcMessage event.
[0039] In the specific implementation, the actual calling requirement of the rendering process is obtained by parsing the RpcMessage event, and then the corresponding calling processing function is determined according to the actual calling requirement of the rendering process, so that the RpcMessage event is processed by the calling processing function, and the result of the first calling function processing the RpcMessage event is obtained, and the processing result is sent to the rendering process, and finally the communication between the rendering process and the main process is completed, that is, the cross-process communication is completed.
[0040] It should be noted that the rendering process and the main process communicate: based on the electron's ipc mechanism, 1) after the main process is started, the RpcCenter.start method is called, in which RpcCenter registers a message listener with ipcMain; 2) when the rendering process wants to send a message to the main process, it calls ipcRenderer.send to send an RpcMessage event; 3) when the main process receives the event, it will trigger the listener in step 1) and execute the RpcCenter function. In the above way, the cross-process communication capability between the rendering process and the main process is realized.
[0041] In a feasible implementation, step S30 may include steps B31 to B33: Step B31, when the target process is a subprocess and it is detected that the subprocess has a communication demand, obtaining a subprocess message sent by the subprocess; It can be understood that the sub-process message refers to a communication message sent by the sub-process.
[0042] In a specific implementation, when the target process is a child process and it is detected that the child process has a communication demand, indicating that the child process wants to send a message to the child process, a message is sent to the main process through process.send (a method used to send messages between processes in Node.js) provided by node.js (an open source, cross-platform JavaScript runtime environment), and finally the main process obtains the communication message sent by the child process.
[0043] Step B32, triggering a sub-process listener according to the sub-process message, so that the sub-process listener parses the sub-process message to obtain a second parsing result; It can be understood that the sub-process listener refers to a listener set in the main process to listen to messages from the sub-process, and the second parsing result refers to the parsing result of the sub-process message.
[0044] In a specific implementation, when the main process obtains a message sent by the child process, the listener for monitoring the child process is triggered, and then the message sent by the child process is parsed by the listener for monitoring the child process, and finally the parsing result of the message sent by the child process, i.e., the second parsing result, is obtained.
[0045] Step B33, determine the second calling function according to the second parsing result, perform message processing through the second target calling function, and send the message processing result to the child process to complete cross-process communication.
[0046] It can be understood that the second calling function refers to the calling processing function corresponding to the second parsing result, and the message processing result refers to the result of the second calling function processing the sub-process message.
[0047] In the specific implementation, the actual calling requirement of the sub-process is obtained by parsing the result of the sub-process message, and then the corresponding calling processing function is determined according to the actual calling requirement of the sub-process, so that the sub-process message is processed by the calling processing function, and the result of the second calling function processing the sub-process message is obtained, and the processing result is sent to the sub-process, and finally the communication between the sub-process and the main process is completed, that is, the cross-process communication is completed.
[0048] It should be noted that the Node child process (in Node.js, the child process refers to an independent process created by the main process) communicates with the main process: based on the process communication mechanism of node.js, 1) after creating the child process in the main process, pass it to the child process through the RpcCenter.register method, in which RpcCenter will register a message listener; 2) when the child process wants to send a message to the child process, send a message to the main process through process.send provided by node.js; 3) when the main process receives the message, it will execute the RpcCenter function through the listener in step 1). Through the above method, the cross-process communication problem in the communication scenario between the Node child process and the main process is solved.
[0049] In a feasible implementation, step S30 may include steps C31 to C33: Step C31, when the target process is a service process to be registered, obtaining a monitoring event parameter sent by the service process to be registered; It can be understood that the service process to be registered refers to the process that needs to register the service, and the service process to be registered is any one of the main process, rendering process and child process. The listening event parameters refer to the relevant information of the specific event that the service process wants to listen to. The listening event parameters include event name, event type and parameter list, etc.
[0050] In the specific implementation, when the target process is the process that needs to register the service, the process that needs to register the service (service process) will send relevant information about the specific events it wants to monitor, and then the main process obtains the relevant information about the specific events that the service process wants to monitor, that is, obtains the monitoring event parameters.
[0051] Step C32, parsing the monitoring event parameters to determine the corresponding process identification code; It can be understood that the process identification code refers to the identification code corresponding to the process that the service process wants to monitor. The identification code corresponding to the process that the service process wants to monitor is obtained by parsing the monitoring event parameters, so that the main process can determine the process to be monitored.
[0052] Step C33, recording the process identification code into the target monitoring table to perform cross-process communication.
[0053] In a specific implementation, the target monitoring table refers to a list of processes that the main process needs to monitor. The main process includes the identification code corresponding to the process that the service process wants to monitor in the list of processes that the main process needs to monitor, and then the main process monitors each process in the list to perform cross-process communication.
[0054] It should be noted that if Figure 3 As shown in the figure, in the process that needs to register the service, call the RpcAgent.listen(event, listener) method, RpcAgent serializes the monitored event parameters and sends them to RpcCenter. RpcAgent records the monitored processing function in the Listener table. The main process receives the listening event and counts the process ID into the listening table. The above method solves the cross-process communication problem in the event listening scenario.
[0055] In a feasible implementation, step S30 may include steps D31 to D33: Step D31, when the target process is a listening process, obtaining an event broadcast message sent by the calling process; It can be understood that the listening process refers to a process that registers interest in a specific event by calling the RpcAgent.listen(event, listener) method, and the event broadcast message refers to the name of the event (event) and parameters related to the event.
[0056] In the specific implementation, when the target process is a process that has registered its interest in a specific event by calling the RpcAgent.listen(event, listener) method, it indicates that the process that needs to call the method (the calling process) needs to broadcast the event to the listening process, and then send the name of the event (event) and the parameters related to the event to the main process. Finally, the main process obtains the name of the event (event) and the parameters related to the event sent by the calling process.
[0057] Step D32, determining the corresponding monitoring process according to the broadcast monitoring table and the event broadcast message; It can be understood that the broadcast monitoring table refers to a data structure maintained internally by RpcCenter, which is used to record which processes are interested in which events.
[0058] In a specific implementation, a traversal query is performed through a data structure maintained internally by RpcCenter according to the name of the event in the event broadcast message and parameters related to the event to determine the corresponding monitoring process.
[0059] Step D33, sending the event broadcast message to the listening process, so that the listening process triggers the corresponding processing file according to the event broadcast message to perform cross-process communication.
[0060] In the specific implementation, the processing file refers to the callback function for processing specific events provided when the listening process is registered. The main process sends the name of the event sent by the calling process and the parameters related to the event to the corresponding listening process, so that the listening process processes the event according to the callback function corresponding to the name of the event and the parameters related to the event, so as to perform event broadcasting, that is, complete cross-process communication.
[0061] It should be noted that if Figure 4 As shown in the figure, the event broadcast process is to call the RpcAgent.emit(event, args) method in the process that needs to call the method. RpcAgent serializes the broadcast parameters and sends the broadcast message to RpcCenter. RpcCenter searches the broadcast monitoring table for the listening process corresponding to the event and sends the event broadcast message to these listening processes. The listening process receives the message, searches the function table for the listener corresponding to the event and triggers it. In this way, the cross-process communication problem in the event broadcast scenario is solved.
[0062] This embodiment determines the current communication scenario in response to the cross-process communication demand; determines the target process according to the current communication scenario; and performs cross-process communication through the target process. By responding to different cross-process communication demands, and then determining the corresponding cross-process communication scenario, and then performing cross-process communication according to the target process corresponding to the cross-process communication scenario, the cross-process communication problem under the electron framework is solved, and a unified process communication capability is provided to different processes, while shielding the underlying process differences, making the cross-process communication details transparent, and providing developers with a convenient and easy-to-use process communication tool.
[0063] Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar contents as those in the above-mentioned embodiment 1 can be referred to the above introduction, and will not be repeated in the following. Figure 5 , step S30 in the cross-process communication method further includes steps S31 to S34: Step S31, when the target process is a calling process, obtaining process calling information sent by the calling process; It can be understood that the calling process refers to the process that needs to call the method, including any process in the main process, child process and rendering process, and the process calling information refers to the parameters related to the calling method, among which different types of methods correspond to different calling parameters, including parameters such as numbers and strings.
[0064] In the specific implementation, when the target process is the process that needs to call a method, it indicates that the process that needs to call the method initiates a call through the invoke method provided by RpcAgent, and serializes the call information and sends it to the main process in the form of a message, and then the main process obtains the call method related parameters sent by the process that needs to call the method.
[0065] Step S32, generating a process call message according to the process call information and the preset routing table, and sending the process call message to the service process, so that the service process calculates the target return value according to the code file and the process call message and feeds back; It can be understood that the preset routing table refers to the pre-set service process routing table, the process call message refers to the call message generated by the main process serializing the call method related parameters, the code file refers to the specific implementation code used by the service process to handle remote call requests, and the target return value refers to the value generated by the code file processing the process call message.
[0066] In the specific implementation, the main process determines the corresponding service process through a pre-set service process routing table combined with the process call information, then serializes the process call information to generate a call message, and sends the call message to the service process, so that the service process performs data processing according to the code file corresponding to the call message, obtains the target return value and feeds it back to the main process.
[0067] In a feasible implementation, step S32 may include steps A321 to A323: Step A321, parsing the process call information to determine the corresponding process method name and process parameter information; It can be understood that the process method name refers to the method name (identification code) of the process to be called, and the process parameter information refers to the parameters related to the process to be called.
[0068] In a specific implementation, the main process parses the acquired process call information, and then determines the method name (identification code) of the corresponding process to be called and the relevant parameters of the process to be called according to the parsing result.
[0069] Step A322, performing a process query according to the preset routing table and the process method name to obtain a process query result; It can be understood that the process query result refers to the query result of whether there is a service process corresponding to the process method name in the preset routing table.
[0070] In the specific implementation, the main process performs a process query through a preset service process routing table combined with the parsed process method name to determine whether there is a corresponding service process, and then obtains a query result of whether there is a service process corresponding to the process method name in the preset routing table, that is, the process query result.
[0071] Step A323, when the process query result is a successful query result, the process method name and the process parameter information are serialized to obtain a process call message.
[0072] In a specific implementation, when the process query result is a successful query result, it indicates that there is a service process corresponding to the process method name in the preset routing table, and then the main process serializes the process method name and process parameter information, and finally obtains the process call message.
[0073] Step S33, upon receiving the target return value sent by the service process, sending a call response message to the calling process corresponding to the target return value, so that the calling process updates the asynchronous call result according to the call response message and feeds back; It can be understood that the call response message means that after the service process processes the call request, the processing result is encapsulated into a message and sent back to the caller's process through the main process. This message contains the result information of the call. The caller process can update the status of the Promise according to this message and finally obtain the call result. The asynchronous call result refers to the result (Promise) used to manage the asynchronous call, so that the caller can easily handle the success or failure of the call.
[0074] In the specific implementation, when the main process receives the target return value sent by the service process, it searches the call table for the calling process corresponding to the call, and sends a call response message to the calling process, so that the calling process updates the state of Promise when receiving the call response message, and feeds back the call result to the calling process through the main process.
[0075] Step S34, when it is detected that the asynchronous call result is a call success result, the cross-process communication is completed.
[0076] In a specific implementation, when the main process detects that the asynchronous call result is a successful call result, it indicates that the method call process is completed, that is, the cross-process communication is completed.
[0077] It should be noted that if Figure 6As shown in the figure, the method calling process is as follows: in the process that needs to call the method, the call is initiated through the invoke method provided by RpcAgent; RpcAgent serializes the call information and sends it to the main process in the form of a message; RpcAgent generates a Promise based on the call and returns it to the caller; the main process queries the service process corresponding to the method in the routing table, and returns directly if it does not exist; if it does exist, the call information is serialized and a call message is sent to the service process; the service process receives the message, searches the function table for the handler corresponding to the method for processing; the handler is used to process the call, and the return value is encapsulated and sent to the main process; the main process receives the return value, searches the call process of the call in the call table, and sends a call response message to the call process; the calling process receives the call return and updates the Promise status; the call is completed, and the caller takes the call result from the Promise.
[0078] It should be noted that this embodiment also includes a method registration communication scenario, specifically: when the current communication scenario is a registration scenario, receiving the registration method name sent by the service process to be registered; detecting the registration method name according to a preset method routing table to obtain a method name detection result; sending the method name detection result to the service process to be registered, so that when the method name detection result of the service process to be registered is a successful detection result, the code file corresponding to the registration method name is recorded in the target file table for storage.
[0079] It is understandable that if Figure 7 As shown in the figure, the method registration process is as follows: in the process that needs to register the service, call the RpcAgent.handle(method, handler) method; RpcAgent records the registered method name and records the Handler in the temporary Handler table; sends a message to RpcCenter to apply for registration of the method; RpcCenter detects whether the method has been registered by other processes. If there is a conflict, the registration fails; if there is no conflict, the method is written into the method routing table; RpcCenter sends the registration result to RpcAgent; RpcAgent of the service process receives the registration result. If successful, it takes out the Handler from the temporary Handler table and records it in the formal Handler table; if it fails, it throws an exception. Through the above method, the cross-process communication problem in the method registration scenario is solved.
[0080] This embodiment obtains process call information sent by the calling process when the target process is the calling process; generates a process call message according to the process call information and a preset routing table, and sends the process call message to the service process, so that the service process calculates the target return value according to the code file and the process call message and feeds back; when receiving the target return value sent by the service process, sends a call response message to the calling process corresponding to the target return value, so that the calling process updates the asynchronous call result according to the call response message and feeds back; when detecting that the asynchronous call result is a call success result, the cross-process communication is completed.
[0081] For example, to help understand the implementation process of the cross-process communication method obtained by combining this embodiment with the above-mentioned embodiment 1, please refer to Figure 8 , Figure 8A brief flowchart of a cross-process communication method is provided, specifically: Initiate a call: When a process (such as a Renderer Process) needs to call a method of another process (such as a Node Child Process), it first sends a call request through its internal RpcAgent; Request packaging: RpcAgent converts the call request into a message in a standard format and sends it to RpcCenter through a corresponding communication channel (such as an electron ipc channel); Central distribution: After receiving the request, RpcCenter finds out which process should handle the request based on the target address and method name of the request, and forwards the request to the target process through a corresponding communication channel (such as a child process channel); Process the request: After receiving the request, the RpcAgent of the target process calls the local method to process the request and packages the result into a response message; Response sending: The response message is transmitted in the reverse direction through the same path, that is, it is first sent to RpcCenter and then forwarded back to the process where the original caller is located by RpcCenter; Result processing: After receiving the response, the process that initially initiated the call unpacks the result through its RpcAgent and provides it to the caller, where Node Child Process refers to the Node.js child process, Renderer Process refers to the rendering process, Main Process refers to the main process, RpcAgent is responsible for providing functional interfaces to developers, encapsulating messages, and initiating calls to the RpcCenter of the main process, Agent refers to the agent layer, Agent Connection refers to the agent connection layer, process channel refers to the process channel, electron ipc channel refers to the Electron IPC channel, message channel refers to the message channel, child process channel refers to the child process channel, and Center Connection refers to the center connection layer.
[0082] It should be noted that the above examples are only used to understand the present application and do not constitute a limitation on the cross-process communication method of the present application. More simple transformations based on this technical concept are all within the scope of protection of the present application.
[0083] This application also provides a cross-process communication device, please refer to Fig. 9 , the inter-process communication device comprises: A response module 10, for responding to the cross-process communication requirement and determining the current communication scenario; A processing module 20, configured to determine a target process according to the current communication scenario; The communication module 30 is used for performing cross-process communication through the target process.
[0084] Optionally, the communication module 30 is further used for: When the target process is a rendering process and it is detected that the rendering process has a communication demand, obtaining a rendering event sent by the rendering process; triggering a rendering listener according to the rendering event, so that the rendering listener parses the rendering event to obtain a first parsing result; A first calling function is determined according to the first parsing result, event processing is performed through the first calling function, and the event processing result is sent to the rendering process to complete cross-process communication.
[0085] Optionally, the communication module 30 is further used for: When the target process is a subprocess and it is detected that the subprocess has a communication demand, obtaining a subprocess message sent by the subprocess; triggering a sub-process listener according to the sub-process message, so that the sub-process listener parses the sub-process message to obtain a second parsing result; A second calling function is determined according to the second parsing result, message processing is performed through the second target calling function, and the message processing result is sent to the child process to complete cross-process communication.
[0086] Optionally, the communication module 30 is further used for: When the target process is a calling process, obtaining process calling information sent by the calling process; Generate a process call message according to the process call information and the preset routing table, and send the process call message to the service process, so that the service process calculates the target return value according to the code file and the process call message and feeds back; Upon receiving the target return value sent by the service process, sending a call response message to the calling process corresponding to the target return value, so that the calling process updates the asynchronous call result and feeds back according to the call response message; When it is detected that the asynchronous call result is a call success result, the cross-process communication is completed.
[0087] Optionally, the communication module 30 is further used for: Parsing the process call information to determine the corresponding process method name and process parameter information; Perform a process query according to the preset routing table and the process method name to obtain a process query result; When the process query result is a successful query result, the process method name and the process parameter information are serialized to obtain a process call message.
[0088] Optionally, the communication module 30 is further used for: When the target process is a service process to be registered, obtaining a monitoring event parameter sent by the service process to be registered; Parsing the monitoring event parameters to determine the corresponding process identification code; The process identification code is recorded in the target monitoring table to perform cross-process communication.
[0089] Optionally, the communication module 30 is further used for: When the target process is a listening process, obtaining an event broadcast message sent by the calling process; Determine the corresponding monitoring process according to the broadcast monitoring table and the event broadcast message; The event broadcast message is sent to the listening process, so that the listening process triggers the corresponding processing file according to the event broadcast message to perform cross-process communication.
[0090] The cross-process communication device provided by the present application adopts the cross-process communication method in the above embodiment, which can solve the technical problem of cross-process communication under the electron framework. Compared with the prior art, the beneficial effects of the cross-process communication device provided by the present application are the same as the beneficial effects of the cross-process communication method provided by the above embodiment, and the other technical features in the cross-process communication device are the same as the features disclosed in the above embodiment method, which will not be repeated here.
[0091] The present application provides a cross-process communication device, which includes: 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, and the instructions are executed by the at least one processor so that the at least one processor can execute the cross-process communication method in the above-mentioned embodiment one.
[0092] Reference below Fig.10, which shows a schematic diagram of the structure of an inter-process communication device suitable for implementing the embodiment of the present application. The inter-process communication device in the embodiment of the present application may include but is not limited to mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Fig.10 The inter-process communication device shown is merely an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.
[0093] like Fig.10 As shown, the inter-process communication device may include a processing device 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM: Read Only Memory) 1002 or a program loaded from a storage device 1003 to a random access memory (RAM: Random Access Memory) 1004. In RAM1004, various programs and data required for the operation of the inter-process communication device are also stored. The processing device 1001, ROM1002, and RAM1004 are connected to each other through a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Generally, the following systems can be connected to the I / O interface 1006: an input device 1007 including, for example, a touch screen, a touch pad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; an output device 1008 including, for example, a liquid crystal display (LCD: Liquid Crystal Display), a speaker, a vibrator, etc.; a storage device 1003 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 1009. The communication device 1009 can allow the inter-process communication device to communicate with other devices wirelessly or by wire to exchange data. Although the figure shows an inter-process communication device with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems can be implemented or have alternatively.
[0094] In particular, according to the embodiments disclosed in the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication device, or installed from a storage device 1003, or installed from a ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are executed.
[0095] The cross-process communication device provided by the present application adopts the cross-process communication method in the above embodiment, which can solve the technical problem of cross-process communication under the electron framework. Compared with the prior art, the beneficial effects of the cross-process communication device provided by the present application are the same as the beneficial effects of the cross-process communication method provided by the above embodiment, and the other technical features in the cross-process communication device are the same as the features disclosed in the method of the previous embodiment, which will not be repeated here.
[0096] It should be understood that the various parts disclosed in this application can be implemented by hardware, software, firmware or a combination thereof. In the description of the above embodiments, specific features, structures, materials or characteristics can be combined in any one or more embodiments or examples in a suitable manner.
[0097] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.
[0098] The present application provides a computer-readable storage medium having computer-readable program instructions (ie, computer programs) stored thereon, wherein the computer-readable program instructions are used to execute the cross-process communication method in the above-mentioned embodiment.
[0099] The computer-readable storage medium provided in the present application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, systems or devices, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM: Random Access Memory), a read-only memory (ROM: Read Only Memory), an erasable programmable read-only memory (EPROM: Erasable Programmable Read Only Memory or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM: CD-Read Only Memory), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program, which may be used by or in combination with an instruction execution system, system or device. The program code contained on the computer-readable storage medium may be transmitted using any appropriate medium, including but not limited to: wires, optical cables, RF (Radio Frequency: Radio Frequency), etc., or any suitable combination of the above.
[0100] The computer-readable storage medium may be included in the inter-process communication device; or may exist independently without being assembled into the inter-process communication device.
[0101] The above-mentioned computer-readable storage medium carries one or more programs. When the above-mentioned one or more programs are executed by the cross-process communication device, the cross-process communication device: determines the current communication scenario in response to the cross-process communication demand; determines the target process according to the current communication scenario; and performs cross-process communication through the target process.
[0102] Computer program code for performing the operations of the present application may be written in one or more programming languages or a combination thereof, including object-oriented programming languages such as Java, Smalltalk, C++, and conventional procedural programming languages such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).
[0103] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present application. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.
[0104] The modules involved in the embodiments described in this application may be implemented by software or hardware, wherein the name of the module does not constitute a limitation on the unit itself in some cases.
[0105] The readable storage medium provided by the present application is a computer-readable storage medium, which stores computer-readable program instructions (i.e., computer programs) for executing the above-mentioned cross-process communication method, and can solve the technical problems of cross-process communication under the electron framework. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided by the present application are the same as the beneficial effects of the cross-process communication method provided by the above-mentioned embodiment, and will not be repeated here.
[0106] The present application also provides a computer program product, including a computer program, which implements the steps of the above-mentioned cross-process communication method when executed by a processor.
[0107] The computer program product provided by this application can solve the technical problem of cross-process communication under the electron framework. Compared with the prior art, the beneficial effects of the computer program product provided by this application are the same as the beneficial effects of the cross-process communication method provided by the above embodiment, which will not be repeated here.
[0108] The above descriptions are only some embodiments of the present application, and are not intended to limit the patent scope of the present application. All equivalent structural changes made using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect applications in other related technical fields are included in the patent protection scope of the present application.
Claims
1. A cross-process communication method, characterized in that: The cross-process communication method comprises: In response to cross-process communication requirements, determine the current communication scenario; Determine a target process according to the current communication scenario; Inter-process communication is performed through the target process.
2. The method according to claim 1, characterized in that The step of performing cross-process communication through the target process includes: When the target process is a rendering process and it is detected that the rendering process has a communication demand, obtaining a rendering event sent by the rendering process; triggering a rendering listener according to the rendering event, so that the rendering listener parses the rendering event to obtain a first parsing result; A first calling function is determined according to the first parsing result, event processing is performed through the first calling function, and the event processing result is sent to the rendering process to complete cross-process communication.
3. The method according to claim 1, characterized in that The step of performing cross-process communication through the target process includes: When the target process is a subprocess and it is detected that the subprocess has a communication demand, obtaining a subprocess message sent by the subprocess; triggering a sub-process listener according to the sub-process message, so that the sub-process listener parses the sub-process message to obtain a second parsing result; A second calling function is determined according to the second parsing result, message processing is performed through the second target calling function, and the message processing result is sent to the child process to complete cross-process communication.
4. The method according to claim 1, characterized in that The step of performing cross-process communication through the target process includes: When the target process is a calling process, obtaining process calling information sent by the calling process; Generate a process call message according to the process call information and the preset routing table, and send the process call message to the service process, so that the service process calculates the target return value according to the code file and the process call message and feeds back; Upon receiving the target return value sent by the service process, sending a call response message to the calling process corresponding to the target return value, so that the calling process updates the asynchronous call result and feeds back according to the call response message; When it is detected that the asynchronous call result is a call success result, the cross-process communication is completed.
5. The method according to claim 4, characterized in that The step of generating a process call message according to the process call information and a preset routing table comprises: Parsing the process call information to determine the corresponding process method name and process parameter information; Perform a process query according to the preset routing table and the process method name to obtain a process query result; When the process query result is a successful query result, the process method name and the process parameter information are serialized to obtain a process call message.
6. The method according to claim 1, characterized in that The step of performing cross-process communication through the target process includes: When the target process is a service process to be registered, obtaining a monitoring event parameter sent by the service process to be registered; Parsing the monitoring event parameters to determine the corresponding process identification code; The process identification code is recorded in the target monitoring table to perform cross-process communication.
7. The method according to any one of claims 1 to 6, characterized in that The step of performing cross-process communication through the target process includes: When the target process is a listening process, obtaining an event broadcast message sent by the calling process; Determine the corresponding monitoring process according to the broadcast monitoring table and the event broadcast message; The event broadcast message is sent to the listening process, so that the listening process triggers the corresponding processing file according to the event broadcast message to perform cross-process communication.
8. An inter-process communication device, characterized in that: The device comprises: A response module is used to respond to the cross-process communication requirements and determine the current communication scenario; A processing module, used for determining a target process according to the current communication scenario; The communication module is used for performing cross-process communication through the target process.
9. An inter-process communication device, characterized in that: The device comprises: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the inter-process communication method according to any one of claims 1 to 7.
10. A storage medium, characterized in that: The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, the steps of the cross-process communication method according to any one of claims 1 to 7 are implemented.