Cross-process communication method, system and equipment

Abstract

The embodiment of the invention discloses a cross-process communication method, system and device. According to the technical scheme provided by the embodiment of the invention, under the condition that the calling party of the current process triggers the service calling instruction of the target service, the service calling request corresponding to the service calling instruction is generated based on the channel client instance, and the service calling request is sent to the target process channel server instance; processing the service calling request based on the channel server instance, and generating an execution result of the target service; and returning the execution result to a calling party of the current process. By adopting the technical means, transparent calling and unified management of cross-process services can be realized, the reliability and maintainability of communication under a multi-process architecture are improved, and the requirements of applications on efficient and stable cross-process communication are met.

Description

TECHNICAL FIELD

[0001] Embodiments of the present application relate to the technical field of computer, and particularly, to a cross-process communication method, system and device. BACKGROUND

[0002] Currently, the lightweight program of a native application usually includes multiple business layers, and different layers use a multi-process architecture for communication, such as a rendering layer and a logic layer running in two independent processes. Under this architecture, data interaction is completed through inter-process communication, and the developer needs to handle the details of process communication. Each time a remote call is initiated, a unique request identifier is manually generated, the call parameters are serialized, and a message is delivered; the receiving end writes a message parser to extract the method identifier and parameters, and encapsulates the results after execution and returns them. In addition, a request ID and callback function mapping table needs to be maintained to achieve cross-process communication.

[0003] However, in the case of cross-process communication, business code needs to be created every time a call is made, resulting in complex and inefficient development and running, and the coupling of business logic and underlying communication mechanisms, making the code difficult to maintain, extend, and prone to errors, affecting development efficiency and communication reliability. SUMMARY

[0004] Embodiments of the present application provide a cross-process communication method, system and device, which can uniformly process service calls based on a channel client instance and a channel server instance, implement transparent calling and unified management of cross-process services, and solve the technical problems of low development efficiency, code redundancy and error-prone caused by fragmented and complex business code in existing cross-process communication solutions based on original message passing.

[0005] In a first aspect, embodiments of the present application provide a cross-process communication method, comprising: In the case where a calling party of a current process triggers a service call instruction of a target service, a service call request corresponding to the service call instruction is generated based on a channel client instance, and the service call request is sent to a channel server instance of a target process; The service call request is processed based on the channel server instance, and an execution result of the target service is generated; The execution result is returned to the calling party of the current process.

[0006] Further, generating a service call request corresponding to the service call instruction based on the channel client instance comprises: Sending the service call instruction to a corresponding proxy object based on a pre-constructed channel client instance, the proxy object being used to process the service call request of the target service, the proxy object being generated by the channel client instance according to a service interface predefined for the target service; Converting the service call instruction into a standardized service call request based on the proxy object.

[0007] Further, the agent object converts the service call instruction into a standardized service call request, including: parsing the service call instruction to obtain an identification parameter of a target service; generating a unique request identifier, and performing standardized request message packaging based on the request identifier and the identification parameter to generate the service call request.

[0008] The identification parameter includes a service identifier of the target service, a method identifier of a specified method called by the target service, and a call parameter of the target service.

[0009] Further, after generating the unique request identifier, the method further includes: building a mapping relationship between the request identifier and a target asynchronous processing interface; Correspondingly, the channel client instance returns the execution result to the caller of the current process, including: distributing the execution result to the target asynchronous processing interface based on the mapping relationship, so as to return the execution result to the caller of the current process through the target asynchronous processing interface.

[0010] Further, the service call request includes a method call request. The channel server instance processes the service call request to generate an execution result of the target service, including: The channel server instance parses the method identifier of the service call request; The channel server instance calls a specified method of the target service to process the method call request based on the method identifier, and generates an execution result of the target service.

[0011] Further, the service call request further includes an event subscription request. The channel server instance processes the service call request, including: The channel server instance registers an event listener in the target service based on the event subscription request; In the case that the target service triggers an event, the channel server instance sends event data to the channel client instance, so as to distribute the received event data to a corresponding event processing function in the current process through the channel client instance.

[0012] Further, the method further includes: The execution result is returned to the channel client instance, and the execution result is returned to the caller of the current process based on the channel client instance.

[0013] Further, the method further includes: The target process creates a service implementation class instance of the target service; convert the service implementation class instance into a channel instance through a proxy channel; register the channel instance to a channel server instance, and establish a binding relationship between a service identifier of the target service and the channel instance, so as to process a method call of the target service based on the channel instance.

[0014] Further, the channel client instance and the channel server instance communicate through a message passing protocol interface of the container layer.

[0015] In a second aspect, an embodiment of the present application provides a cross-process communication system, comprising: The request sending module is configured to, in a case where a calling party of a current process triggers a service call instruction of a target service, generate a service call request corresponding to the service call instruction based on a channel client instance, and send the service call request to a target process channel server instance. The request execution module is configured to process the service call request based on the channel server instance, and generate an execution result of the target service. The result returning module is configured to return the execution result to the calling party of the current process.

[0016] In a third aspect, an embodiment of the present application provides an electronic device, comprising: a memory and one or more processors; The memory is configured to store one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors are caused to implement the cross-process communication method according to the first aspect.

[0017] In a fourth aspect, an embodiment of the present application provides a storage medium containing computer executable instructions, which, when executed by a computer processor, are used to perform the cross-process communication method according to the first aspect.

[0018] The embodiments of the present application generate a service call request corresponding to the service call instruction based on a channel client instance in a case where a calling party of a current process triggers a service call instruction of a target service, and send the service call request to a target process channel server instance; process the service call request based on the channel server instance, and generate an execution result of the target service; and return the execution result to the calling party of the current process. By introducing the bidirectional communication architecture of the channel client instance and the channel server instance, and uniformly processing the service call based on the channel client instance and the channel server instance, the transparent call and unified management of the cross-process service are implemented. Compared with the existing cross-process communication scheme based on original message passing, the present application improves the reliability and maintainability of communication under a multi-process architecture, and meets the demand of the application for efficient and stable cross-process communication. BRIEF DESCRIPTION OF DRAWINGS

[0019] Figure 1 is a flowchart of a cross-process communication method provided by an embodiment of the present application; Figure 2 is a flowchart of a standardization processing of a service call request in the embodiment one of the present application; Figure 3 is a flowchart of a registration of a channel instance in the embodiment one of the present application; Figure 4 is a flowchart of a generation of an execution result of a target service in the embodiment one of the present application; Figure 5 is a flowchart of an event subscription of a target service in the embodiment one of the present application; Figure 6 is a flowchart of a cross-process communication between a rendering layer and a logic layer in the embodiment one of the present application; Figure 7 is a structural schematic diagram of a cross-process communication system provided by an embodiment two of the present application; Figure 8 is a structural schematic diagram of an electronic device provided by an embodiment three of the present application. DETAILED DESCRIPTION

[0020] In order to make the objects, technical solutions and advantages of the present application clearer, the following further describes the specific embodiments of the present application with reference to the drawings. It can be understood that the specific embodiments described herein are only used to explain the present application, but not to limit the present application. In addition, it should be noted that, for the convenience of description, only the parts related to the present application are shown in the drawings, but not all the contents. Before discussing the example embodiments in more detail, it should be mentioned that some example embodiments are described as processes or methods depicted by flowcharts. Although the flowcharts describe the operations (or steps) as sequential processes, many of the operations can be implemented in parallel, concurrently or simultaneously. In addition, the order of the operations can be rearranged. The processes can be terminated when the operations are completed, but can also have additional steps not included in the drawings. The processes can correspond to methods, functions, procedures, subroutines, subprograms, etc.

[0021] The cross-process communication method provided by the present application aims to uniformly process service calls based on channel client instances and channel server instances, and to realize transparent call and unified management of cross-process services.

[0022] In the lightweight program of the native application (which can be understood as a subprogram running on the parent program, such as a small program, a micro application, a small tool, etc.), the running environment of the lightweight program mainly includes a rendering layer, a logic layer and a container layer. Among them, the rendering layer is responsible for the UI rendering and user interaction of the page, the logic layer is responsible for processing business logic, data state and interface calling, and the container layer is responsible for managing the life cycle of the rendering layer and the logic layer, and realizing the communication between the logic layer and the rendering layer and the interaction with the native function. Different running environment layers usually adopt a multi-process architecture for communication, for example, the rendering layer and the logic layer are respectively run in two independent operating system processes. Under this architecture, any data interaction is completed through inter-process communication, and the developer needs to directly process the process communication details in the business code. Among them, each time a remote call needs to be initiated, the developer needs to manually generate a unique request identifier to distinguish and match the subsequent response. Then serialize the calling parameters into a transmittable format, and deliver the message through the underlying communication bridge. On the receiving end, a corresponding message parser needs to be written to extract the method identifier and parameters from the received message, and after execution, the above process is repeated to encapsulate and return the result to the calling party. In addition, the developer also needs to manually maintain a request ID and callback function mapping table to ensure that the asynchronous returned response can be correctly distributed and processed, so as to realize the cross-process communication of the lightweight program. However, in the case of cross-process communication of the lightweight program, corresponding business code needs to be created for each call, resulting in complex and inefficient code development and running process. And the business logic and the underlying communication mechanism are tightly coupled, making the code difficult to maintain and extend, and prone to errors, which seriously affects the development efficiency and communication reliability of the program.

[0023] Therefore, the cross-process communication method provided by the embodiments of the present application is provided to solve the technical problems of low development efficiency, code redundancy and error-prone caused by fragmented and complex business code in the existing cross-process communication scheme based on original message passing.

[0024] Embodiment one: Figure 1 A flowchart of a cross-process communication method provided by the first embodiment of the present application is given. The cross-process communication method provided in this embodiment can be executed by a cross-process communication device. The cross-process communication device can be realized by software and / or hardware. The cross-process communication device can be composed of two or more physical entities, or it can be composed of one physical entity. Generally, the cross-process communication device can be a terminal device such as a mobile phone, a computer, a tablet, etc. running a lightweight program of a native application.

[0025] The following describes the case that the cross-process communication device is the main body of the cross-process communication method. Referring to Figure 1 , the cross-process communication method specifically includes: S110, in the case of the calling party of the current process triggering the service call instruction of the target service, a service call request corresponding to the service call instruction is generated based on the channel client instance, and the service call request is sent to the target process channel server instance.

[0026] In the case of cross-process communication of different processes of a lightweight program, the application defines the process triggering the service call instruction as the current process by triggering the service call instruction of the corresponding service on another process through the business code entity in one process. For the service call instruction triggered by the current process, the application automatically processes the entire service call request generation process through the channel client instance, for example, the entire service call request generation process can be automatically processed through a pre-built channel client instance. The channel client instance communicates with the channel server instance of the target process, thereby realizing cross-process calling of the target service. Among them, the cross-process service instance that needs to be called by the current process is defined as the target service. Correspondingly, the independent operating system process running the target service is the target process. The target process can be a logical layer or a rendering layer process of a lightweight program. Similarly, the current process can also be a logical layer or a rendering layer process of a lightweight program. The channel client instance refers to a communication component running in the current process, which is responsible for intercepting local service call instructions, encapsulating local service call instructions into standardized request messages, and sending them to the target process through the underlying bridge, such as JSBridge or WebSocket long connection channel, while managing the matching of requests and responses. The channel server instance refers to a communication component running in the target process, which is responsible for receiving request messages from the channel client, routing the request messages to the corresponding target service registered for execution, and encapsulating the execution result for return. The calling party indicates the business code entity in the current process that initiates the target service call instruction.

[0027] Specifically, in the case that the calling party of the current process needs to call the target service of the target process, the current process will call its channel client instance, standardize the service call instruction through the channel client instance, serialize the service call instruction into a standardized request message format, and thus generate a standardized service call request.

[0028] Among them, the channel client instance and the channel server instance communicate through the message passing protocol interface of the container layer.

[0029] In the embodiments of the present application, the message passing protocol interface of the container layer of the lightweight program is essentially a highly abstracted and standardized encapsulation of the underlying native communication capability, which can be implemented based on the JSBridge technology, for example. The JSBridge is a bridge interface provided by the container layer for establishing bidirectional communication between the JavaScript runtime environment and the native system, which encapsulates the specific implementation of the underlying platform and provides a unified cross-context message passing capability for the upper layer. Specifically, when the channel client instance generates a standardized service call request, it does not directly handle the details of inter-process communication at the underlying level, but instead hands over the complete request message to the message passing protocol interface for transmission processing. The message passing protocol interface converts the message into a format suitable for cross-process transmission (such as a JSON string), thereby enabling cross-process communication of the lightweight program. In addition, the message passing protocol interface can also utilize the pre-established HTTP / WebSocket long connection channel between the WebView and the native environment for transmission of binary and structured data, thereby enabling cross-process communication. Alternatively, based on the specific inter-process communication primitives provided by the native platform, the message passing protocol interface can encapsulate and transmit data, thereby enabling cross-process communication. The present application does not make fixed restrictions on the specific configuration of the message passing protocol interface, and will not be described here.

[0030] Further, the message passing protocol interface, in the message sending phase, identifies the location of the target process and establishes a reliable communication connection to ensure that the message can be accurately delivered to the target channel server instance. Meanwhile, at the receiving end, when the channel server instance of the target process receives the original message through the same interface, the interface will first restore the original data in the interface transmission format to a standardized service call request, thereby enabling cross-process transmission of the service call request. Through the message passing protocol interface, the implementation complexity of cross-process communication is simplified, and a communication foundation is provided for the multi-process architecture of the lightweight program.

[0031] Optionally, with reference to Figure 2 , the service call request corresponding to the service call instruction generated by the channel client instance comprises: S1101, sending the service call instruction to the corresponding proxy object based on the pre-built channel client instance, the proxy object being used for processing the service call request of the target service, the proxy object being generated by the channel client instance according to the service interface predefined by the target service; S1102, converting the service call instruction into a standardized service call request based on the proxy object.

[0032] In an optional implementation of the embodiments of the present application, the generation process of the service invocation request realizes the encapsulation of the service invocation request by introducing a proxy object mechanism. In the case that the calling party of the current process triggers a service invocation instruction, the calling instruction is first passed to the corresponding proxy object. The proxy object is dynamically generated by the channel client instance according to the service interface predefined by the target service, and serves as the proxy of the target service in the current process, containing the interface specification and behavior characteristics of the target service. The proxy object can analyze all the method signatures, parameter types and return types declared in the service interface, and create a corresponding interception mechanism. In the case that the calling party initiates a method call through the proxy object, the proxy object will capture all the calling information, including the method name, the input parameter, the calling context and the like, and package these information into an intermediate representation form.

[0033] After the capture of the calling information is completed, the proxy object will start the standardization conversion process of the service invocation instruction. The conversion process first performs deep analysis and structured processing on the calling information, extracts the key service invocation information, and performs message encapsulation based on the extracted information.

[0034] Specifically, the proxy object converts the service invocation instruction into a standardized service invocation request, including: parsing the service invocation instruction to obtain an identification parameter of a target service; generating a unique request identifier, performing standardized request message encapsulation based on the request identifier and the identification parameter, and generating a service invocation request.

[0035] The proxy object parses the service invocation instruction to extract the identification parameter therein, so as to identify the service invocation request generated subsequently. According to actual requirements, the identification information can be the unique identification information of the target service, or the identification information configured for the service invocation of the target service at this time. The present application does not make a fixed limitation on the specific identification parameter, and will not be described here.

[0036] Optionally, the identification parameter includes a service identifier of the target service, a method identifier of a specified method called by the target service, and a calling parameter of the target service. The proxy object extracts the globally unique service identifier of the target service, the method identifier of the specified method called by the target service, and the calling parameter of the target service by parsing the service calling instruction. Then, the proxy object generates a globally unique request identifier, which is used for request tracking and response matching. Then, the proxy object assembles these elements into a standardized service calling request according to a predefined protocol specification. The service calling request has a unified message structure and data coding format. Service calling requests generated from different services or different methods based on the unified message structure and data coding format can have consistent forms at the transmission level. In the assembly process, the proxy object can serialize and optimize the parameters, handle data types and circular references, and attach metadata information such as call timestamp, version identifier, and compression flag. Finally, the generated service calling request is a completely self-describing, independent of specific programming language and running platform standard data unit.

[0037] Through the proxy object mechanism and the standardized request conversion process, the complex cross-process communication details are completely encapsulated in the infrastructure layer, so that the developer can use the cross-process service without awareness, which improves the development efficiency while ensuring the reliability and consistency of the system.

[0038] S120, processing the service calling request based on the channel server instance to generate an execution result of the target service.

[0039] Further, after the service calling request is transmitted to the target process, the channel server instance of the target process is responsible for processing. The channel server instance is a unified access point of the target process, which manages all available services by maintaining a service channel registration table. In the case of receiving a service calling request, the channel server parses the service identifier in the request and routes the request to the corresponding service channel according to the registration table information. The service channel is an adapter of a business service, which is used to convert the standardized calling request into a call to a specific service method and pass related parameters. Through the service channel, the target service only needs to focus on the implementation of the business logic, without needing to focus on any communication details. Optionally, the channel server instance can also support a service delay binding mechanism, that is, even if the service calling request is received before the service is registered, it can be temporarily saved and automatically executed when the service is available, thereby enhancing the flexibility of service calling.

[0040] Specifically, referring to Figure 3 Before processing the service calling request, it further includes: S1201, creating a service implementation class instance of the target service in the target process; S1202, convert the service implementation class instance into a channel instance through the proxy channel; S1203, register the channel instance to the channel server instance, and establish a binding relationship between the service identifier of the target service and the channel instance, so as to process the method call of the target service based on the channel instance.

[0041] Before the channel server instance processes the service call request, the target process needs to complete the creation, conversion and registration process of the service instance. Specifically, first, a service implementation class that implements a predetermined service interface needs to be instantiated in the runtime environment of the target process, and this instance carries the specific business logic of the target service. Then, the service instance is dynamically encapsulated and adapted through the proxy channel, and the service instance is converted into a channel instance that conforms to the unified communication protocol. This conversion process realizes the protocol bridging between the business method and the remote call instruction, so that the original business logic can respond to the standardized remote call. The proxy channel, as an intermediate layer component, is used to encapsulate the service implementation class instance into a channel instance that conforms to the communication protocol, so that the server instance can respond to cross-process calls. For example, for a user service implementation class in the logic layer, a channel instance of the user service implementation class is generated through the proxy channel, so that the class is wrapped as a remotely callable method to realize the remote call of the class.

[0042] Finally, the generated channel instance is formally registered in the channel server instance of the target process, and a stable binding relationship between the unique service identifier and the channel instance is established, thereby constructing a service routing table that can be queried. Thus, the channel server instance can quickly locate the corresponding channel instance according to the service identifier in the received service call request in the subsequent running process, and call the corresponding channel instance to process the specific method call, realizing the accurate routing and seamless conversion of the remote call request to the local business method execution, which not only guarantees the standardization and uniformity of service call, but also provides flexible architectural support for service management and expansion. Through the standardized service registration and adaptation mechanism, the business implementation and communication logic are separated, which improves the maintainability and scalability of the system, and lays a solid foundation for dynamic discovery and unified routing management of services.

[0043] Further, the service call request includes a method call request; with reference to Figure 4 , based on the channel server instance, processing the service call request to generate an execution result of the target service, including: S1204, parsing the method identifier of the service call request based on the channel server instance; S1205, calling the specified method of the target service based on the method identifier to process the method call request, and generating an execution result of the target service.

[0044] Specifically, in the case of the service invocation request being a method invocation request, the channel server instance first parses the received standardized service invocation request, extracts the method identifier encapsulated therein, which uniquely corresponds to a certain specific business method (i.e. the specified method) predefined in the target service. Subsequently, the channel server instance matches the parsed method identifier with the registered channel instances according to the established service routing table, and distributes the request to the corresponding target service instance through a dynamic invocation mechanism. Finally, the channel server instance executes the specified method in the target service corresponding to the method identifier, captures the native execution result returned by the target service, and encapsulates the result together with the relevant invocation context information to form a response data that can be transmitted between processes. Thus, through unified service routing, the automation of remote method invocation from reception to execution is realized, ensuring the accuracy of business logic execution and the reliability of data transmission.

[0045] Optionally, the service invocation request further includes an event subscription request; refer to Figure 5 , based on the channel server instance processing the service invocation request, comprising: S1206, the channel server instance registers an event listener in the target service based on the event subscription request; S1207, in the case of the target service triggering an event, the channel server instance sends event data to the channel client instance to distribute the received event data to the corresponding event handling function in the current process through the channel client instance.

[0046] In the case that the service call request is an event subscription request, the channel server instance first parses the event type identifier and subscription parameters carried in the event subscription request, and then dynamically registers a standardized event listener in the event emitter corresponding to the target service. The event listener is a callback function registered in the target service, which is used to listen to specific events (such as data updates) and trigger notifications when the events occur. For example, in a data service, the event listener can listen to data change events, and when the data is modified, the event data is automatically executed and sent. The event listener serves as a bridge for cross-process event delivery, and the life cycle of the event listener is bound to the subscription request. In the case that the internal state of the target service changes or a specific business condition is met, the built-in event emitter of the target service will trigger the corresponding event. At this time, the pre-registered listener will immediately capture the native event data, and through the standardized event encapsulation interface of the channel server instance, the event type, event data payload, and associated subscription context information will be serialized into a unified format event message. After the message is transmitted to the channel client instance that initiates the subscription via the underlying communication bridge, the client instance will accurately match the message embedded in the subscription identifier in the local event handling function mapping table, and finally distribute the deserialized event data to the corresponding event handling function to execute the response logic. The event handling function is a function defined in the current process, which is used to receive and process event data sent from the target process, and execute the corresponding business logic. For example, in the case that the rendering layer receives the data updated event sent by the logic layer, the event handling function will update the display content in the user interface.

[0047] Thus, through dynamic listener registration, standardized event encapsulation, and accurate callback distribution mechanism, a reliable event channel is established from the event trigger of the server instance to the callback execution of the client instance. The standardized management of cross-process event-driven architecture is realized, and the communication reliability and maintainability of event-type data in the cross-process communication environment are improved.

[0048] S130, return the execution result to the caller of the current process.

[0049] Finally, when the target service completes the business logic processing and returns the execution result, the execution result can be returned to the caller of the current process. The target service can return the execution result directly to the current process according to the requestor of the service call request (i.e. the current process), so as to distribute the execution result to the corresponding caller through the current process.

[0050] Optionally, returning the execution result to the caller of the current process comprises: returning the execution result to the channel client instance, and returning the execution result to the caller of the current process based on the channel client instance.

[0051] The channel server instance encapsulates the result and the previously received request identifier into a standardized response message, and returns the response message to the channel client instance in the current process through the inter-process communication bridge. At this time, the channel client instance returns the response message to the corresponding caller after receiving the response message. Thus, through the automatic response distribution mechanism, the accurate matching of requests and responses is ensured.

[0052] Based on the above cross-process communication method, by constructing a unified communication architecture of the channel client and the channel server instance, the decoupling of business logic and communication mechanism is realized, which not only improves the development efficiency and code maintainability, but also significantly enhances the reliability and system robustness of cross-process communication.

[0053] Optionally, after generating the unique request identifier, the method further comprises: building a mapping relationship between the request identifier and the target asynchronous processing interface; Correspondingly, based on the channel client instance returning the execution result to the caller in the current process, the method comprises: distributing the execution result to the target asynchronous processing interface based on the mapping relationship, so as to return the execution result to the caller in the current process through the target asynchronous processing interface.

[0054] Before generating the unique request identifier for the service call request, the channel client instance builds a mapping relationship between the identifier and the target asynchronous processing interface, and stores the mapping relationship in a special mapping table maintained by the channel client instance. Thus, an association mechanism between requests and responses is established. In the case that the execution result returned by the target process reaches the current process through the communication bridge, the channel client instance will immediately start the response distribution process, first parse the received response message completely, and accurately extract the request identifier and the load data carried therein. Then, the request identifier is used as a query condition to quickly search in the pre-established mapping relationship table, and the corresponding target asynchronous processing interface is located. After successful matching, the execution result is passed as a parameter to the interface for subsequent processing. For method calls (such as Promise type calls), the corresponding resolve or reject method is triggered, so as to release the blocking state of the caller waiting statement and pass the return value to the business logic; for event callbacks, the corresponding processing function is executed and the event data is passed in. The whole process realizes complete automation, not only ensures the accurate transmission of response data from the communication layer to the business layer, but also guarantees the correct correspondence between each response and the initial request in a high-concurrency scenario through the identifier matching mechanism, eliminating the matching error risk of request response.

[0055] Exemplarily, based on the above cross-process communication method, with reference to Figure 6In the case of calling the remote service of the logic layer in the rendering layer, the calling party (such as business code) of the rendering layer initiates the remote service call through the proxy object. The proxy object delegates the call to the channel client instance, which generates a unique request ID, encapsulates the call information into a standardized service call request, and maintains the mapping relationship between the request ID and the callback. The encapsulated service call request is sent to the logic layer through the message passing protocol interface JSBridge. The channel server instance of the logic layer receives the request and routes it to the corresponding service channel according to the service identifier. The service channel calls the specific method of the target service to execute the business logic, and the execution result is returned to the channel client instance. Finally, the channel client instance matches the corresponding asynchronous processing interface according to the request ID, parses and returns the result to the original calling party.

[0056] In the case of calling the service call instruction of the target service by the calling party in the current process, the channel client instance generates a service call request corresponding to the service call instruction, and sends the service call request to the target process channel server instance; the channel server instance processes the service call request to generate the execution result of the target service; and the execution result is returned to the calling party in the current process. By introducing the bidirectional communication architecture of the channel client instance and the channel server instance, the channel client instance and the channel server instance uniformly process the service call, transparently call and uniformly manage the cross-process service. Compared with the existing cross-process communication scheme based on original message passing, the reliability and maintainability of communication in the multi-process architecture of the lightweight program are improved, and the demand of the lightweight program application for efficient and stable cross-process communication is met.

[0057] Embodiment Two On the basis of the above-mentioned embodiments, Figure 7 A structural schematic diagram of a cross-process communication system provided by Embodiment Two of the present application is shown in FIG. 2. Figure 7 The cross-process communication system provided in the embodiment specifically includes: The request sending module 21 is configured to, in the case of calling the service call instruction of the target service by the calling party in the current process, generate a service call request corresponding to the service call instruction based on the channel client instance, and send the service call request to the target process channel server instance. The request execution module 22 is configured to process the service call request based on the channel server instance to generate the execution result of the target service. The result returning module 23 is configured to return the execution result to the calling party in the current process.

[0058] Specifically, the channel client instance and the channel server instance communicate through the message passing protocol interface of the container layer.

[0059] Specifically, the service invocation request corresponding to the service invocation instruction based on the channel client instance comprises: The service invocation instruction is sent to the corresponding proxy object based on the pre-constructed channel client instance, and the proxy object is used to process the service invocation request of the target service, and the proxy object is generated by the channel client instance according to the service interface predefined by the target service; The service invocation instruction is converted into a standardized service invocation request based on the proxy object.

[0060] Specifically, the service invocation instruction is converted into a standardized service invocation request based on the proxy object, comprising: The identification parameter of the target service is obtained by parsing the service invocation instruction; A unique request identifier is generated, and the request identifier and the identification parameter are used for standardized request message packaging to generate the service invocation request.

[0061] The identification parameter comprises a service identifier of the target service, a method identifier of a specified method called by the target service, and a call parameter of the target service.

[0062] Specifically, after the unique request identifier is generated, it further comprises: A mapping relationship between the request identifier and the target asynchronous processing interface is constructed; Correspondingly, the execution result is returned to the caller of the current process based on the channel client instance, comprising: The execution result is distributed to the target asynchronous processing interface based on the mapping relationship, so that the execution result is returned to the caller of the current process through the target asynchronous processing interface.

[0063] Specifically, the cross-process communication system further comprises: The service implementation class instance of the target service is created in the target process; The service implementation class instance is converted into a channel instance through the proxy channel; The channel instance is registered to the channel server instance, and a binding relationship between the service identifier of the target service and the channel instance is established, so that the method call of the target service is processed based on the channel instance.

[0064] Specifically, the service invocation request comprises a method call request; The service invocation request is processed based on the channel server instance to generate the execution result of the target service, comprising: The method identifier of the service invocation request is parsed based on the channel server instance; The specified method of the target service is called based on the method identifier to process the method call request and generate the execution result of the target service.

[0065] Specifically, the service call request further includes an event subscription request; The channel server instance processes the service call request, including: The channel server instance registers an event listener in the target service based on the event subscription request; In the case that the target service triggers an event, the channel server instance sends event data to the channel client instance, so as to distribute the received event data to the corresponding event processing function in the current process through the channel client instance.

[0066] Specifically, the execution result is returned to the invoker of the current process, including: The execution result is returned to the channel client instance, and the execution result is returned to the invoker of the current process based on the channel client instance.

[0067] In the case that the invoker of the current process triggers a service call instruction of the target service, the service call request of the corresponding service call instruction is generated based on the channel client instance, the service call request is sent to the target process channel server instance, the execution result of the target service is generated based on the channel server instance processing the service call request, and the execution result is returned to the invoker of the current process. By introducing the bidirectional communication architecture of the channel client instance and the channel server instance, the service call is uniformly processed based on the channel client instance and the channel server instance, the transparent call and unified management of the cross-process service are realized, compared with the existing cross-process communication scheme based on the original message transmission, the reliability and maintainability of the communication under the multi-process architecture are improved, and the demand of the application for efficient and stable cross-process communication is met.

[0068] The cross-process communication system provided in Embodiment Two of the present application can be used to execute the cross-process communication method provided in Embodiment One, and has corresponding functions and advantages.

[0069] Embodiment Three Embodiment Three of the present application provides an electronic device, which refers to Figure 8 The electronic device includes a processor 31, a memory 32, a communication module 33, an input device 34, and an output device 35. The number of processors in the electronic device can be one or more, and the number of memories in the electronic device can be one or more. The processor, memory, communication module, input device, and output device of the electronic device can be connected through a bus or other means.

[0070] The memory, as a computer readable storage medium, can be used to store software programs, computer executable programs and modules, such as the program instructions / modules (for example, the request sending module, the request executing module and the result returning module in the cross-process communication system) corresponding to the cross-process communication method described in any embodiment of the present application. The memory can mainly include a program storage area and a data storage area, wherein the program storage area can store an operating system and at least one application required by a function; and the data storage area can store data created according to the use of the device and the like. In addition, the memory can include a high-speed random access memory, and can also include a non-volatile memory, such as at least one magnetic disk storage device, a flash memory device or other non-volatile solid-state memory device. In some examples, the memory can further include a memory remotely arranged with respect to the processor, and the remote memory can be connected to the device through a network. Examples of the above network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network and a combination thereof.

[0071] The communication module is used for data transmission.

[0072] The processor executes various functional applications and data processing of the device by running the software programs, instructions and modules stored in the memory, that is, implements the cross-process communication method described above.

[0073] The input device can be used to receive input digital or character information, and generate key signal input related to user settings and function control of the device. The output device can include a display device such as a display screen.

[0074] The electronic device provided above can be used to execute the cross-process communication method provided in Embodiment One, and has corresponding functions and advantages.

[0075] Embodiment Four The embodiments of the present application also provide a storage medium containing computer executable instructions, which, when executed by a computer processor, are used to execute a cross-process communication method, the cross-process communication method comprising: when a service calling instruction of a target service is triggered by a calling party of a current process, generating a service calling request corresponding to the service calling instruction based on a channel client instance, and sending the service calling request to a target process channel server instance; processing the service calling request based on the channel server instance, generating an execution result of the target service; and returning the execution result to the calling party of the current process.

[0076] Storage medium - any type of memory device or storage device. The term "storage medium" is intended to include an installation medium, e.g., a CD-ROM, floppy disks, or tape apparatus; computer system memory or random access memory such as DRAM, DDR RAM, SRAM, EDO RAM, Rambus RAM, etc.; or a non-volatile memory such as a magnetic medium (e.g., a hard drive or optical storage); registers or other similar types of memory elements, etc. The memory medium can also include other types of storage medium and combinations thereof. In addition, the memory medium can reside in a first computer system's internal storage device, external storage device, or both. Furthermore, the memory medium can store, in addition to program instructions, digital content, e.g., object files, source code, binary code, computer programs, resources, and any other types of programs, program components, or program instructions. The term "memory medium" can also include two or more memory media that reside in different locations, e.g., in different computer systems that are connected over a network such as the Internet. The memory medium can store program instructions that can be executed by one or more processors of a computer system. As an example of this, a computer can be configured with at least a first and a second memory medium. The first memory medium can be configured to store computer program instructions that are executed by a first processor of the computer. The second memory medium can be configured to store computer program instructions that are executed by a second processor of the computer. The computer program instructions configured to be executed by the second processor can be configured to cause the second processor to perform one or more operations that are the same as or similar to one or more operations performed by the first processor.

[0077] Of course, the storage medium provided by the embodiments of the present application includes computer executable instructions, which are not limited to the cross-process communication method as described above, but can also perform the related operations in the cross-process communication method provided by any of the embodiments of the present application.

[0078] The cross-process communication system, storage medium and electronic device provided in the above embodiments can perform the cross-process communication method provided by any of the embodiments of the present application, and the technical details not described in detail in the above embodiments can be referred to the cross-process communication method provided by any of the embodiments of the present application.

[0079] The above are only the preferred embodiments of the present application and the technical principles applied. The present application is not limited to the specific embodiments described herein, and various obvious changes, re-adjustments and replacements made by those skilled in the art will not deviate from the protection scope of the present application. Therefore, although the present application has been described in more detail through the above embodiments, the present application is not limited to the above embodiments, and can include more other equivalent embodiments without deviating from the concept of the present application, and the scope of the present application is determined by the scope of the claims.

Claims

1. A cross-process communication method, characterized in that, include: When the caller of the current process triggers a service call instruction for the target service, a service call request corresponding to the service call instruction is generated based on the channel client instance, and the service call request is sent to the channel server instance of the target process; The service call request is processed based on the channel server instance, and the execution result of the target service is generated. The execution result is returned to the caller of the current process.

2. The cross-process communication method according to claim 1, characterized in that, The process of generating a service invocation request corresponding to the service invocation instruction based on the channel client instance includes: The service invocation command is sent to the corresponding proxy object based on the pre-built channel client instance; The proxy object is used to convert the service call instruction into a standardized service call request.

3. The inter-process communication method according to claim 2, characterized in that, The step of converting the service invocation instruction into a standardized service invocation request based on the proxy object includes: Parse the service invocation instruction to obtain the identification parameters of the target service; A unique request identifier is generated, and a standardized request message is encapsulated based on the request identifier and the identifier parameter to generate the service call request.

4. The cross-process communication method according to claim 3, characterized in that, After generating the unique request identifier, the process also includes: Construct a mapping relationship between the request identifier and the target asynchronous processing interface; Accordingly, the step of returning the execution result to the caller of the current process based on the channel client instance includes: Based on the mapping relationship, the execution result is distributed to the target asynchronous processing interface, so that the execution result can be returned to the caller of the current process through the target asynchronous processing interface.

5. The cross-process communication method according to claim 3, characterized in that, The identification parameters include the service identifier of the target service, the method identifier of the specified method called by the target service, and the calling parameters of the target service.

6. The inter-process communication method according to claim 5, characterized in that, The service invocation request includes a method invocation request; The process of processing the service call request based on the channel server instance and generating the execution result of the target service includes: The method identifier of the service call request is parsed based on the channel server instance; Based on the method identifier, the specified method of the target service is invoked to process the method invocation request and generate the execution result of the target service.

7. The inter-process communication method according to claim 3, characterized in that, The service call request includes an event subscription request; The process of handling the service call request based on the channel server instance includes: The channel server instance registers an event listener in the target service based on the event subscription request; When the target service triggers an event, the channel server instance sends event data to the channel client instance, so that the channel client instance can distribute the received event data to the corresponding event handling function in the current process.

8. The cross-process communication method according to claim 1, characterized in that, Returning the execution result to the caller of the current process includes: The execution result is returned to the channel client instance, and based on the channel client instance, the execution result is returned to the caller of the current process.

9. The inter-process communication method according to claim 1, characterized in that, The method further includes: An instance of the service implementation class of the target service is created in the target process; The service implementation class instance is converted into a channel instance through the proxy channel; Register the channel instance to the channel server instance and establish a binding relationship between the service identifier of the target service and the channel instance, so as to process the method calls of the target service based on the channel instance.

10. The cross-process communication method according to claim 1, characterized in that, The channel client instance and the channel server instance communicate through the message passing protocol interface of the container layer.

11. A cross-process communication system, characterized in that, include: The request sending module is used to generate a service call request corresponding to the service call instruction based on the channel client instance when the caller of the current process triggers a service call instruction for the target service, and send the service call request to the channel server instance of the target process. The request execution module is used to process the service call request based on the channel server instance and generate the execution result of the target service; The result return module is used to return the execution result to the caller of the current process.

12. An electronic device, characterized in that, include: Memory and one or more processors; The memory is used to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the inter-process communication method as described in any one of claims 1-10.

Images