CN109933443B

CN109933443B - Inter-process communication method and device, computer equipment and readable storage medium

Info

Publication number: CN109933443B
Application number: CN201910172078.4A
Authority: CN
Inventors: 杜文涛
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2019-03-07
Filing date: 2019-03-07
Publication date: 2021-06-25
Anticipated expiration: 2039-03-07
Also published as: CN109933443A

Abstract

The application relates to an interprocess communication method, an interprocess communication device, a computer-readable storage medium and a computer device, wherein the method of one embodiment comprises the following steps: receiving an inter-process communication instruction, sending a calling service binding request to a target server process by calling a service binding interface function, establishing binding connection with the target server process, wherein the calling service binding request carries client process identification information; calling a service interface function, sending a calling service request to the target server through binding connection, wherein the calling service request carries information of a method to be called; and receiving an operation return value returned by the target server process based on the calling service request, wherein the operation return value is the operation of executing the method corresponding to the method information to be called by the target server process, obtaining an operation result, and determining based on the operation result. The scheme provided by the application simplifies the implementation process of interprocess communication, improves the development efficiency of the client process, and improves the efficiency of interprocess communication.

Description

Inter-process communication method and device, computer equipment and readable storage medium

Technical Field

The present application relates to the field of computer technologies, and in particular, to an inter-process communication method, an inter-process communication apparatus, a computer device, and a computer-readable storage medium.

Background

In the field of computer technology, IPC (inter-process communication) refers to a mechanism provided by an operating system that allows processes to manage shared data. Through the IPC mechanism, different processes can mutually access resources and work in coordination.

Then, the traditional inter-process communication mechanism is complex in implementation process and low in efficiency.

Disclosure of Invention

Therefore, it is necessary to provide an interprocess communication method, an interprocess communication apparatus, a computer-readable storage medium and a computer device, aiming at the problems of complicated implementation process and low efficiency of the conventional interprocess communication mechanism.

An interprocess communication method, comprising:

receiving an inter-process communication instruction, sending a calling service binding request to a target server process by calling a service binding interface function, and establishing binding connection with the target server process, wherein the calling service binding request carries client process identification information;

calling a service interface function, and sending a calling service request to the target server through the binding connection, wherein the calling service request carries information of a method to be called;

and receiving an operation return value returned by the target server process based on the calling service request, wherein the operation return value is the operation of executing the method corresponding to the to-be-called method information by the target server process, obtaining an operation result, and determining based on the operation result.

In some embodiments, receiving an inter-process communication instruction, sending a call service binding request to a target server process by calling a service binding interface function, and establishing a binding connection with the target server process includes:

receiving an inter-process communication instruction, and creating a service binding interface function instance by calling a service binding interface function;

and sending a calling service binding request to the target server process through the service binding interface function instance, and establishing binding connection with the target server process.

In some embodiments, further comprising the step of: and when the service binding interface function instance reaches the life cycle of the service binding interface function instance, recovering the service binding interface function instance.

In some embodiments, further comprising the step of: and when the service binding interface function instance reaches the life cycle of the service binding interface function instance, sending a service binding interface function instance recovery notice to the target server process.

In some embodiments, after establishing the binding connection with the target server process, the method further includes the steps of: receiving and caching a service agent handle which is returned by the target server process and is successfully connected;

the service calling request carries the service agent handle.

In some embodiments, further comprising the step of: and receiving the real parameters returned by the target server process, and performing function callback through the real parameters.

In some embodiments, further comprising the step of: and when the dynamic proxy instance reaches the dynamic proxy instance life cycle, recovering the dynamic proxy instance.

An interprocess communication method, comprising:

receiving a calling service binding request, wherein the calling service binding request carries client process identification information, and a binding connection with a client process is established through a service binding interface function, and the client process corresponds to the client process identification information;

receiving a calling service request, wherein the calling service request carries information of a method to be called;

and executing the operation of the method corresponding to the information of the method to be called through a service interface function to obtain an operation result, and returning an operation return value to the client process based on the operation result.

In some embodiments, after establishing the binding connection with the client process through the service binding interface function, the method further includes the following steps:

returning a service agent handle to the client process;

the service calling request carries the service agent handle.

In some embodiments, further comprising the step of: and calling back through the dynamic proxy, and returning the real parameters to the client process through the dynamic proxy.

In some embodiments, further comprising the step of: and when receiving a dynamic proxy instance recovery notification sent by the client process, recovering the cached dynamic proxy instance.

An interprocess communication apparatus, comprising:

the client binding module is used for receiving an interprocess communication instruction, sending a calling service binding request to a target server process by calling a service binding interface function, and establishing binding connection with the target server process, wherein the calling service binding request carries client process identification information;

the method calling module is used for calling a service interface function and sending a calling service request to the target server through the binding connection, wherein the calling service request carries the information of the method to be called;

and the result receiving module is used for receiving an operation return value returned by the target server process based on the calling service request, wherein the operation return value is the operation of executing the method corresponding to the to-be-called method information by the target server process, obtaining an operation result and determining based on the operation result.

In some embodiments, the client binding module receives an inter-process communication instruction, and creates a service binding interface function instance by calling a service binding interface function; and sending a calling service binding request to the target server process through the service binding interface function instance, and establishing binding connection with the target server process.

In some embodiments, the client binding module reclaims the service binding interface function instance when the service binding interface function instance reaches a service binding interface function instance lifecycle.

In some embodiments, the client binding module further receives and caches a service agent handle returned by the target server process and successfully connected after establishing a binding connection with the target server process;

the service calling request carries the service agent handle.

In some embodiments, the method call module executes the service interface function and sends a call service request to the target server when the service interface function is in the singleton mode.

In some embodiments, the method call module calls a service interface function to create a dynamic proxy instance when receiving an instance creation instruction; and sending a service calling request to the target server through the dynamic proxy instance.

In some embodiments, the method invocation module includes:

the dynamic proxy determining module is used for calling the service interface function and determining the currently called dynamic proxy class;

the serialization module is used for serializing the parameters to be transmitted to obtain the serialized parameters;

the encapsulation module is configured to encapsulate the to-be-invoked method information of the currently-invoked dynamic proxy class, and obtain the encapsulated to-be-invoked method information, where the to-be-invoked method information includes: the identification information of the method to be called, the serialized parameters and the operation return value;

and the request sending module is used for sending a calling service request to the target server, wherein the calling service request carries the packaged information of the method to be called.

In some embodiments, when the parameter to be transmitted is the first type parameter, the serialization module performs recursive serialization on the variables of the parameter to be transmitted one by one to obtain the parameter after serialization.

In some embodiments, when the parameter to be transmitted is the second type parameter, the serialization module multiplexes a predetermined serialization manner to serialize the parameter to be transmitted, so as to obtain a parameter after serialization.

In some embodiments, when the parameter to be transmitted is a third type parameter, the serialization module checks the internal variables of the parameter to be transmitted one by one, and then serializes the internal variables to obtain a serialized parameter.

In some embodiments, when the parameter to be transmitted is a fourth type parameter, the serialization module takes the class name as a parameter after serialization.

In some embodiments, the method invocation module further reclaims the dynamic proxy instance when the dynamic proxy instance reaches a dynamic proxy instance lifecycle.

An interprocess communication apparatus, comprising:

the server binding module is used for receiving a calling service binding request, the calling service binding request carries client process identification information, binding connection with a client process is established through a service binding interface function, and the client process corresponds to the client process identification information;

the method call receiving module is used for receiving a call service request, and the call service request carries the information of the method to be called;

and the method execution module executes the operation of the method corresponding to the information of the method to be called through a service interface function to obtain an operation result, and returns an operation return value to the client process based on the operation result.

In some embodiments, the server binding module further returns a service agent handle to the client process after establishing a binding connection with the client process through a service binding interface function;

the service calling request carries the service agent handle.

In some embodiments, a method execution module comprises:

the analysis module is used for analyzing the information of the method to be called through a service interface function to obtain a currently called dynamic proxy example, identification information of the method to be called and serialized parameters;

the deserializing module is used for deserializing the serialized parameters to obtain deserialized parameters;

and the execution module is used for executing the method corresponding to the identification information of the method to be called through the dynamic proxy class and the deserialized parameter to obtain an operation result.

In some embodiments, the method execution module performs a callback through the dynamic proxy and returns the argument to the client process through the dynamic proxy.

In some embodiments, the method execution module, upon receiving a dynamic proxy instance reclamation notification sent by the client process, reclaims the cached dynamic proxy instance.

A computer device comprising a memory and a processor, the memory storing a computer program, wherein the computer program, when executed by the processor, implements the steps of the method of inter-process communication as set forth in any one of the above.

A computer-readable storage medium, on which a computer program is stored, wherein the computer program, when being executed by a processor, carries out the steps of the method of inter-process communication according to any one of the above.

According to the interprocess communication method, the interprocess communication device, the computer readable storage medium and the computer equipment, through the process of packaging the binding service of the server and the execution process of the service, when interprocess communication is needed, the binding connection between the client process and the target server process can be conveniently and simply realized by calling the service binding interface function, and the calling of the method executed by the server process can be realized by calling the service interface function, so that the interprocess communication method, the interprocess communication device, the computer readable storage medium and the computer equipment are simple and convenient, the implementation process of interprocess communication is simplified, the development efficiency of the client process is improved, and the interprocess communication efficiency is improved.

Drawings

FIG. 1 is a diagram of an application environment for process communication, in one embodiment;

FIG. 2 is a diagram of an application environment for process communication in another embodiment;

FIG. 3 is a flow diagram that illustrates a method for inter-process communication, according to one embodiment;

FIG. 4 is a flow diagram that illustrates a method for inter-process communication, in one embodiment;

FIG. 5 is a schematic diagram illustrating an inter-process connection during inter-process communication, according to an embodiment;

FIG. 6 is a schematic diagram illustrating an example of invoking a dynamic proxy during interprocess communication according to an embodiment;

FIG. 7 is a schematic diagram illustrating data encapsulation and serialization during interprocess communication, according to an embodiment;

FIG. 8 is a schematic diagram illustrating a callback during inter-process communication, according to an embodiment;

FIG. 9 is a schematic diagram illustrating an example of reclamation during interprocess communication, according to an embodiment;

FIG. 10 is a block diagram of an inter-process communication device of an embodiment;

FIG. 11 is a block diagram of a method invocation module in one example;

FIG. 12 is a block diagram of an interprocess communication device according to another embodiment;

FIG. 13 is a block diagram of a method execution module in one example;

FIG. 14 is a block diagram showing the construction of a computer device according to one embodiment;

FIG. 15 is a block diagram showing a configuration of a computer device according to an embodiment.

Detailed Description

In order to make the objects, technical solutions and advantages of the present application more apparent, the present application is described in further detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the present application and are not intended to limit the present application.

The inter-process communication scheme mentioned in the embodiment of the application is an application scenario for communication between two processes. The two processes may be located in the same device, that is, two processes in the same device communicate with each other, as shown in fig. 1, where the device a may be a user terminal device or a server device. In addition, the two processes may also be processes located in different devices, that is, processes between two different devices, where the two devices may both be user terminal devices, may both be server devices, and may be one device that is a user terminal device and the other device that is a server device. In fig. 1 and fig. 2, a server process refers to a process for providing a service, which is also referred to as a server process in this embodiment, and a client process refers to a process for accessing a service, which is also referred to as a client process in this embodiment.

Taking two processes in the same device a as an example, an operating system type of the device a may be an Android system (Android system), and in the following description of related embodiments, the inter-process communication method according to the present application is described as an example of applying the inter-process communication method to an Android system.

Referring to fig. 3, a method of inter-process communication in one embodiment, which may be performed by a client process, includes steps S301 through S303 described below.

Step S301: receiving an inter-process communication instruction, sending a calling service binding request to a target server process by calling a service binding interface function, and establishing binding connection with the target server process, wherein the calling service binding request carries client process identification information.

The client process identification information is information for identifying a client process, and the form of the client process identification information is not limited, and in some embodiments, the client process identification information may be a name of the client process, in some embodiments, the client process identification information may also be a number of the client process in the case of numbering the client process, and in other embodiments, the client process identification information may also be information in other forms as long as the client process can be uniquely identified.

Before executing the inter-process communication method, the process of binding service (bind server) of the client is encapsulated, and the service binding interface function obtained after encapsulation can be registered on a system platform for each client to call. Under the condition that different service binding modes exist, a plurality of different service binding modes can be respectively packaged, so that a plurality of different service binding interface functions can exist. It can be understood that, in the actual inter-process communication process, the service binding interface function is already packaged and registered in the system platform, and the process of binding the service is completed by directly calling the service binding interface function.

In some embodiments, the client process may receive the interprocess communication instruction whenever interprocess communication is required. The inter-process communication instruction can be sent by a user of the equipment where the client process is located through interactive operation with the equipment, or can be sent by other processing logic of the equipment where the client process is located when the inter-process communication condition is met, and the scheme of the application does not limit the triggering scene of the inter-process communication.

In some embodiments, the sending a request for calling service binding to a target server process by calling a service binding interface function, and establishing a binding connection with the target server process may specifically include:

creating a service binding interface function instance by calling the service binding interface function; wherein, the service binding interface function instance can be created in any possible way;

and establishing binding connection with the target server process through the service binding interface function instance.

In some embodiments, establishing a binding connection with a target server process through a service binding interface function instance may specifically include:

and sending a calling service binding request to the target server process through the service binding interface function instance to indicate the target server process to execute a method corresponding to the service binding interface function so as to establish binding connection.

In some embodiments, for the created service binding interface function instance, a corresponding service binding interface function instance life cycle may also be set, where the service binding interface function instance life cycle may be set in any possible manner, and may be a fixed value or determined based on a process of inter-process communication of the service binding interface function instance. And at the moment, when the service binding interface function instance reaches the life cycle of the service binding interface function instance, recovering the service binding interface function instance.

In some embodiments, when the service binding interface function instance reaches the life cycle of the service binding interface function instance, a service binding interface function instance recovery notification may be further sent to the target server process to notify the target server process to recover the cached service binding interface function instance, so as to avoid the unordered growth of the service binding interface function instance.

In some embodiments, after establishing the binding connection with the target server process, the method further includes the steps of: and receiving and caching the service agent handle which is returned by the target server process and is successfully connected.

Step S302: and calling a service interface function, and sending a calling service request to the target server through the binding connection, wherein the calling service request carries the information of the method to be called.

Before the inter-process communication method is executed, services (services) provided by each server process are encapsulated, for example, definitions of the services can be encapsulated, service interface functions obtained after encapsulation can be registered in a system platform so that each client can call the service interface functions in the inter-process communication process, and meanwhile, each service interface function and the server process used by each service interface function can be declared in a related configuration file. Wherein a plurality of different services may be encapsulated to obtain a plurality of different service interface functions. It can be understood that, in the actual inter-process communication process, the service interface function is already packaged and registered in the system platform, and the service interface function is directly called to complete the process of executing the method.

In some embodiments, invoking a service interface function, and sending a service invocation request to the target server process through the bound connection, includes: and when the service interface function is in the singleton mode, executing the service interface function and sending a service calling request to the target server. At this time, in the singleton mode, one class has only one instance, and at this time, the service interface function may be directly executed to send a call service request to the target server.

In some embodiments, invoking a service interface function, and sending a service invocation request to the target server process through the bound connection, includes: when an instance creating instruction is received, calling a service interface function to create a dynamic proxy instance; and sending a service calling request to the target server through the dynamic proxy instance. At this time, in the non-singleton mode, a plurality of different instances may be created for one class, and at this time, after creating the dynamic proxy instance based on the service interface function, a call service request may be sent through the dynamic proxy instance.

In some embodiments, the invoking a service interface function and sending the invoking service request to the target server process through the bound connection includes the following steps S3021 to S3034.

Step S3021: and calling a service interface function and determining the currently called dynamic proxy class. When the service interface function is in the singleton mode, the dynamic proxy class can be directly determined by the singleton of the service interface function. When the service interface function is not in the singleton mode, the invoked dynamic proxy class may be determined by creating a dynamic proxy instance. It will be appreciated that in other embodiments, the dynamic proxy class may be determined in other manners.

In some embodiments, for the created dynamic proxy instance, a corresponding dynamic proxy instance lifecycle may also be set, and the dynamic proxy instance lifecycle may be set in any possible manner, and may be a fixed value or determined based on a method invocation process of the dynamic proxy instance. At this point, the dynamic proxy instance is also recycled when it reaches the dynamic proxy instance lifecycle.

In some embodiments, when the dynamic proxy instance reaches the dynamic proxy instance lifecycle, a dynamic proxy instance recycle notification is further sent to the target server process to notify the target server process to recycle the cached dynamic proxy instance, so as to avoid the unordered growth of the dynamic proxy instance.

Step S3022: and serializing the parameters to be transmitted to obtain the serialized parameters.

It can be understood that, for the same or different client processes, when inter-process communication is performed with different server processes, and under the condition that service interface functions to be called are different, the number and types of parameters to be transmitted of parameters that need to be serialized may not be the same, and the embodiment of the present application is not specifically limited.

In some embodiments, the serializing the parameter to be transmitted to obtain the serialized parameter may specifically include the following process.

And when the parameter to be transmitted is the first type parameter, performing recursive serialization on the variables of the parameter to be transmitted one by one to obtain the parameter after serialization. In some embodiments, the first type parameter may be a parameter whose type is a common type, and which types may be common types may be set in combination with actual technical requirements.

And when the parameter to be transmitted is the second type parameter, multiplexing a preset serialization mode, and serializing the parameter to be transmitted to obtain the parameter after serialization. In some embodiments, the second type parameter may be a parameter of a paretable type or a primative type. In this case, the predetermined multiplexing serialization method may be a systematic Parcel serialization method. The method comprises the steps of performing Parcel serialization, writing byte stream data after object serialization into a shared memory, reading byte stream data from the shared memory through Parcel by other processes, and performing deserialization to obtain an object.

And when the parameter to be transmitted is the third type parameter, sequentially sequencing the internal variables after checking the internal variables of the parameter to be transmitted one by one to obtain the parameter after the serialization. In some embodiments, the third type parameter may be a Reference type parameter that is non-paretable.

And when the parameter to be transmitted is the fourth type parameter, taking the class name as a parameter after serialization. In some embodiments, the fourth type parameter may be a special type context type parameter. The class name here may be the class name of the dynamic proxy class determined above.

Step S3023: and encapsulating the information of the method to be called of the currently called dynamic proxy class, wherein the information of the method to be called comprises the following steps: the identification information of the method to be called, the serialized parameters and the operation return value.

The specific way of encapsulating the information of the method to be called can be implemented by any possible way of encapsulating data, and the embodiment of the present application is not particularly limited.

Step S3024: and sending a calling service request to the target server process, wherein the calling service request carries the packaged information of the method to be called.

It is to be understood that, when sending the call service request to the target server process, the call service request is sent to the target server process based on the called service interface function.

It can be understood that, in the case of receiving and caching the service agent handle which is returned by the target server process and has successfully connected, the service invocation request may also carry the service agent handle.

Step S303: and receiving an operation return value returned by the target server process based on the calling service request, wherein the operation return value is the operation of executing the method corresponding to the to-be-called method information by the target server process, obtaining an operation result, and determining based on the operation result.

In some embodiments, the operation return value may be carried in the call service request sent to the target server process, or may be agreed in the system.

In some embodiments, in the process of performing inter-process communication, an argument returned by the target server process may be received, and a callback function may be called through the argument. In some embodiments, the actual parameters may be determined in any possible manner. For example, it may be the service agent handle returned as described above.

Referring to fig. 4, a method of inter-process communication in one embodiment includes the following steps S401 to S403, and the method may be performed by a server process.

Step S401: receiving a calling service binding request, wherein the calling service binding request carries client process identification information, and establishing binding connection with a client process through a service binding interface function, wherein the client process corresponds to the client process identification information.

As shown in the type of the embodiment of the inter-process communication method corresponding to fig. 3, the client process identification information is information for identifying a client process, the form of the client process identification information is not limited, a process of binding a service (bind server) by a client is encapsulated before the inter-process communication method is executed, and a service binding interface function obtained after encapsulation can be registered on a system platform for each client to call.

In some embodiments, the invoking service binding request may be issued by the client process through the created service binding interface function instance after creating the service binding interface function instance by invoking the service binding interface function. At this point, the service binding interface function instance may be cached after receiving the invoke-service-binding request. Accordingly, in some embodiments, a service binding interface function instance recovery notification sent by the client process may also be received, and based on the service binding interface function instance recovery notification, the cached service binding interface function instance may be recovered, so as to avoid an out-of-order growth of the service binding interface function instance.

In some embodiments, after establishing the binding connection with the target server process, the method further includes the steps of: and returning the service agent handle to the client process.

Step S402: and receiving a calling service request, wherein the calling service request carries the information of the method to be called.

In some embodiments, the information of the method to be called carried by the call service request may be the information of the method to be called obtained after serialization and encapsulation are performed by the client process.

It is to be understood that, in the case that the service agent handle is returned, the service agent handle may also be carried by the service invocation request.

In some embodiments, the invoking service request may be issued by the client process through a dynamic proxy instance after the dynamic proxy instance is created by invoking a service interface function. At this point, the dynamic proxy instance may be cached after receiving the invoke service request. Accordingly, in some embodiments, the cached dynamic proxy instance may also be recycled when receiving the dynamic proxy instance recycling notification sent by the client process, so as to avoid the unordered growth of the dynamic proxy instance.

Step S403: and executing the operation of the method corresponding to the information of the method to be called through a service interface function to obtain an operation result, and returning an operation return value to the client process based on the operation result.

In some embodiments, the executing, by the service interface function, the operation of the method corresponding to the to-be-called method information to obtain an operation result includes the following steps S4031 to S4033.

Step S4031: and analyzing the information of the method to be called through a service interface function to obtain the currently called dynamic proxy instance, the identification information of the method to be called and the serialized parameters.

Step S4032: and performing deserialization operation on the serialized parameters to obtain deserialized parameters.

When the deserialization operation is performed, the deserialization mode corresponding to the serialization mode can be adopted based on the serialization mode performed by the client process. In some embodiments, the parameter type of the serialized parameter can be identified to adopt a corresponding deserialization mode. In some embodiments, the serialized parameters may carry parameter type identifiers, and a corresponding deserialization manner may be adopted by the parameter type identifiers. In some embodiments, the serialization and deserialization processes may be accomplished by encapsulating a unified serialization and deserialization interface function, and calling the unified serialization and deserialization interface function during both serialization and deserialization.

Step S4033: and executing the method corresponding to the identification information of the method to be called through the dynamic proxy class and the deserialized parameter to obtain an operation result, and returning an operation return value to the client process based on the operation result.

In some embodiments, returning an operation return value to the client process based on the operation result may be returning the operation return value when the operation result is that the method is successfully executed. The operation return value may be carried in the call service request sent to the target server process, or may be agreed in the system.

In some embodiments, during the inter-process communication, a callback may be performed by the dynamic proxy, and an argument may be returned to the client process by the dynamic proxy. The actual parameters may be determined in any possible manner. For example, it may be the service agent handle returned as described above.

Based on the embodiments described above, the following detailed description is given with reference to a specific application example of the scheme of the present application.

In order to enable interprocess communication (IPC) to be as convenient as common method calling, the scheme encapsulates the process of binding the service (Client bind Server) of the Client to obtain a service binding interface function. In addition, services (services) provided by each server process are encapsulated, for example, the definition of the services can be encapsulated to obtain a service interface function. The specific way of encapsulating the definitions of the Client bind Server and the service is not limited. And registering the service binding interface function and the service interface function obtained after packaging on a system platform.

The service binding interface function and the service interface function obtained after encapsulation can be declared in a related configuration file. For example, for a service interface function (e.g., definition of encapsulated service) obtained after encapsulation, the Services used and the running process thereof may be declared in a Manifest (root element of android Manifest). When declaring, the service interface function may declare all the encapsulated services. The encapsulated Service is provided with a Remote method, and the Remote method is used for realizing dynamic proxy of interprocess communication.

After the encapsulation and registration are performed, the inter-process communication process can be completed by calling the service binding interface function and the service interface function in the actual inter-process communication process.

In the process of interprocess communication, when a Client process (Client process) receives an interprocess communication instruction, a calling service binding request is sent to a target server process by calling a service binding interface function.

Referring to fig. 5, when the Client process receives the inter-process communication instruction, an inter-process communication engine (IPC engine) of the Client process sends a request for calling service binding through a function for calling service binding interface, and an inter-process communication engine (IPC engine) of the Server process receives the request for calling service binding, executes the function for calling service binding interface, and establishes a binding connection between the Client process and the Server process, wherein a method (service) executed by the Server process is executed in the Server process. After establishing the successful binding connection between the Client process and the Server process, the Server process generates a service agent handle (service agent handle) and returns the service agent handle to the Client process, so as to facilitate subsequent inter-process communication and instance recovery. The IPC engine shown in fig. 5 relates to an engine of a Client process and an engine of a Server process.

The same Client process can be bound and connected with a plurality of different server processes by calling a service binding interface function. One server may execute only one service or may execute a plurality of different services. It is understood that different services may have corresponding different service interface functions. Different services of different server processes can have different Service agent handles, and different Service services can be accessed according to the different Service agent handles.

Referring to fig. 6, after the client process and the server process successfully bind the service, in the singleton mode, the client process sends a dynamic proxy request, after receiving the dynamic proxy request, an IPC engine of the client process determines a dynamic proxy instance of a dynamic proxy class (remote class) of the service interface function, serializes a parameter to be transmitted through the dynamic proxy instance, encapsulates identification information of a method to be called, the serialized parameter, and an operation return value, and then sends a service calling request to the target server process.

Referring to fig. 6, after the client process and the server process successfully bind the service, in a non-singleton mode, the client process sends a dynamic proxy request, after receiving the dynamic proxy request, the IPC engine of the client process performs instantiation operation, creates a dynamic proxy instance by calling a service interface function, serializes a parameter to be transmitted through the dynamic proxy instance, encapsulates identification information of a method to be called, the serialized parameter, and an operation return value, and then sends a calling service request to the target server process. The IPC engine shown in fig. 6 relates to an engine of a Client process and an engine of a Server process.

Referring to fig. 7, when data encapsulation and serialization are performed, taking the parameter to be transmitted as a pareble type as an example, the parameter to be transmitted may be serialized in a system parel serialization manner, so as to obtain a serialized parameter. In the process, the dynamic proxy instance of the client process determines the IPC package through parcel serialization, the IPC package specifically comprises IPC method information and IPC parameters, the IPC method information comprises a method name, a method class of the method and a paragraph class of the method, the IPC parameters comprise a class name and corresponding data, and the IPC package determined through the serialization operation can also comprise other attributes and related classes. After the serialization is completed, the IPC packet obtained after the serialization can be written into a container in a ParcelUtil packet, wherein the container in the ParcelUtil packet comprises a designated Parcel content part and a Parcel content part designated by a system. In some embodiments, in the container, any one of the serialized parameter objects may include: the content of the type is a class name, is a Parcellable type (Parcellable), is not a Parcellable type (N-Parcellable), is a Primitive type (Primitive), and other related types, and when the content is determined not to be a Parcellable type (N-Parcellable), the content of the related types such as the class name can be further included.

After receiving the call service request, the IPC engine of the server process analyzes the information of the method to be called, obtains the currently called dynamic proxy instance, the identification information of the method to be called and the serialized parameters, and performs deserialization operation on the serialized parameters to obtain deserialized parameters. Referring to fig. 7, in the case of serialization in a system Parcel serialization manner, an IPC engine of a server process may read related to-be-called method information from a container in a Parcel util package.

In the singleton mode, the method of the identification information of the method to be called can be executed directly based on the deserialized parameters to obtain the operation result. In a non-singleton mode, the method of the identification information of the method to be called can be executed through the dynamic proxy class and the deserialized parameter, and an operation result is obtained. And when the execution is finished and the execution result is successful, storing the analyzed operation return value and returning the operation return value to the client process.

In the inter-process communication process, calling between functions is realized through a Callback function (Callback function). CALLBACK (CALLBACK function) is a function called by a function pointer. If a pointer (address) to a function is passed as a parameter to another function, the function is said to be a callback function when the pointer is used to call the function to which it points.

Specifically, in the present application, referring to fig. 8, the interprocess communication engine may provide a common callback function, the Server process side may perform callback through the dynamic proxy instance as described above, and the dynamic proxy instance may return the argument to the Client process through the common callback. And the Client process calls the real Callback through the received real arguments, wherein the real Callback function is pre-cached at the Client process end).

As described above, in the inter-process communication process, referring to fig. 9, the Server process may cache a dynamic proxy Instance (Remote Instance). In order to avoid the unordered growth of the dynamic proxy instance on the server process side, the Remote instance needs to be recycled. The dynamic proxy instance may be reclaimed in a variety of possible ways. Specifically, in the scheme of the application, the life cycle of the dynamic proxy instance is set by the Client process, and the Client process recovers the dynamic proxy instance when the life cycle of the dynamic proxy instance is finished. In a specific example, the Client process tracks the recovery condition of the dynamic proxy instance through a virtual reference (PhantomReference) and a ReferenceQueue, and if the dynamic proxy instance is recovered, sends a dynamic proxy instance recovery notification to the Server process to notify the Server process of recovering the dynamic proxy instance. And when the Server process receives the notification of notifying the dynamic proxy instance to recover, recovering the cached dynamic proxy instance.

Referring to FIG. 10, an inter-process communication apparatus in one embodiment includes:

the client binding module 101 is configured to receive an inter-process communication instruction, send a calling service binding request to a target server process by calling a service binding interface function, and establish a binding connection with the target server process, where the calling service binding request carries client process identification information;

the method calling module 102 is configured to call a service interface function, and send a calling service request to the target server through the binding connection, where the calling service request carries information of a method to be called;

a result receiving module 103, configured to receive an operation return value returned by the target server process based on the call service request, where the operation return value is an operation of the target server process to execute the method corresponding to the to-be-called method information, obtain an operation result, and determine based on the operation result.

In some embodiments, the client binding module 101 receives an inter-process communication instruction, and creates a service binding interface function instance by calling a service binding interface function; and sending a calling service binding request to the target server process through the service binding interface function instance, and establishing binding connection with the target server process.

In some embodiments, the client binding module 101 recovers the service binding interface function instance when the service binding interface function instance reaches the life cycle of the service binding interface function instance.

In some embodiments, the client binding module 101 further receives and caches a service agent handle returned by the target server process and successfully connected after establishing a binding connection with the target server process;

the service calling request carries the service agent handle.

In some embodiments, the method invoking module 102, when the service interface function is in the singleton mode, executes the service interface function, and sends an invoking service request to the target server.

In some embodiments, the method call module 102, when receiving the instance creation instruction, calls a service interface function to create a dynamic proxy instance; and sending a service calling request to the target server through the dynamic proxy instance.

In some embodiments, the method invocation module 102 includes:

a dynamic proxy determining module 1021, configured to call a service interface function, and determine a currently called dynamic proxy class;

a serialization module 1022, configured to serialize the parameters to be transmitted, to obtain serialized parameters;

an encapsulating module 1023, configured to encapsulate the to-be-invoked method information of the currently-invoked dynamic proxy class, and obtain the encapsulated to-be-invoked method information, where the to-be-invoked method information includes: the identification information of the method to be called, the serialized parameters and the operation return value;

a request sending module 1024, configured to send a service invocation request to the target server, where the service invocation request carries the encapsulated information of the method to be invoked.

In some embodiments, when the parameter to be transmitted is the first type parameter, the serialization module 1022 performs recursive serialization on the variables of the parameter to be transmitted one by one, so as to obtain the serialized parameter.

In some embodiments, when the parameter to be transmitted is the second type parameter, the serialization module 1022 multiplexes a predetermined serialization manner to serialize the parameter to be transmitted, so as to obtain a serialized parameter.

In some embodiments, when the parameter to be transmitted is the third type parameter, the serialization module 1022 sequences the internal variables of the parameter to be transmitted after checking the internal variables one by one, so as to obtain a serialized parameter.

In some embodiments, the serialization module 1022 takes the class name as the serialized parameter when the parameter to be transmitted is the fourth type parameter.

In some embodiments, method invocation module 102 also reclaims the dynamic proxy instance when the dynamic proxy instance reaches a dynamic proxy instance lifecycle.

Referring to fig. 12, an inter-process communication apparatus includes:

the server binding module 121 is configured to receive a call service binding request, where the call service binding request carries client process identification information, and establish a binding connection with a client process through a service binding interface function, where the client process corresponds to the client process identification information;

a method call receiving module 122, configured to receive a call service request, where the call service request carries information of a method to be called;

and the method execution module 123 executes the operation of the method corresponding to the information of the method to be called through the service interface function to obtain an operation result, and returns an operation return value to the client process based on the operation result.

In some embodiments, the server binding module 121 further returns a service proxy handle to the client process after establishing a binding connection with the client process through the service binding interface function;

the service calling request carries the service agent handle.

In some embodiments, the method execution module 123 includes:

the analysis module 1231 is configured to analyze the information of the method to be called through a service interface function, and obtain a currently called dynamic proxy instance, identification information of the method to be called, and serialized parameters;

an deserializing module 1232, configured to perform deserializing operation on the serialized parameters to obtain deserialized parameters;

and an executing module 1233, configured to execute, through the dynamic proxy class and the deserialized parameter, the method corresponding to the identification information of the method to be called, so as to obtain an operation result.

In some embodiments, the method execution module 123 makes a callback through the dynamic proxy and returns an argument to the client process through the dynamic proxy.

In some embodiments, the method executing module 123, upon receiving a dynamic proxy instance recycle notification sent by the client process, recycles the cached dynamic proxy instance.

It is understood that the interprocess communication device shown in fig. 10 and fig. 12 may be configured differently according to different practical application scenarios. In the case where some processes are fixed to provide services to others, the inter-process communication means shown in fig. 12 may be provided to the processes, and in the case where some processes are fixed to use only services of other processes, the inter-process communication means shown in fig. 10 may be provided to the processes. In the case where some processes can request services of other processes and provide services to other processes, the inter-process communication means shown in fig. 10 and 12 may be provided at the same time.

FIG. 14 is a diagram illustrating an internal structure of a computer device in one embodiment. The computer device may specifically be the server in fig. 2. As shown in fig. 14, the computer device includes a processor, a memory, and a network interface connected by a system bus. Wherein the memory includes a non-volatile storage medium and an internal memory. The non-volatile storage medium of the computer device stores an operating system and may also store a computer program that, when executed by the processor, causes the processor to implement the inter-process communication method. The internal memory may also store a computer program, and the computer program, when executed by the processor, may cause the processor to perform the information pushing method.

Those skilled in the art will appreciate that the architecture shown in fig. 14 is merely a block diagram of some of the structures associated with the disclosed aspects and is not intended to limit the computing devices to which the disclosed aspects apply, as particular computing devices may include more or less components than those shown, or may combine certain components, or have a different arrangement of components.

In one embodiment, the interprocess communication apparatus 100 provided by the present application may be implemented in the form of a computer program, which may be run on a computer device as shown in fig. 14. The memory of the computer device may store therein respective program modules constituting the inter-process communication apparatus, and the computer program constituted by the respective program modules causes the processor to execute the steps in the inter-process communication method of the embodiments of the present application described in the present specification.

Fig. 15 is a diagram showing an internal structure of a computer device in another embodiment. The computer device may specifically be the terminal in fig. 1. As shown in fig. 15, the computer apparatus includes a processor, a memory, a network interface, an input device, and a display screen connected through a system bus. Wherein the memory includes a non-volatile storage medium and an internal memory. The non-volatile storage medium of the computer device stores an operating system and may also store a computer program that, when executed by the processor, causes the processor to implement the inter-process communication method. The internal memory may also have stored therein a computer program that, when executed by the processor, causes the processor to perform the inter-process communication method. The display screen of the computer equipment can be a liquid crystal display screen or an electronic ink display screen, and the input device of the computer equipment can be a touch layer covered on the display screen, a key, a track ball or a touch pad arranged on the shell of the computer equipment, an external keyboard, a touch pad or a mouse and the like.

Those skilled in the art will appreciate that the architecture shown in fig. 15 is merely a block diagram of some of the structures associated with the disclosed aspects and is not intended to limit the computing devices to which the disclosed aspects apply, as particular computing devices may include more or less components than those shown, or may combine certain components, or have a different arrangement of components.

In one embodiment, the interprocess communication means 120 provided by the present application may be implemented in the form of a computer program, which is executable on a computer device as shown in fig. 15. The memory of the computer device may store various program modules that make up the interprocess communication means 120. The computer program constituted by the respective program modules causes the processor to execute the steps in the inter-process communication method of the respective embodiments of the present application described in the present specification.

Accordingly, in one embodiment, a computer device is provided, comprising a memory and a processor, the memory storing a computer program which, when executed by the processor, causes the processor to perform the steps of the inter-process communication method described above. The steps of the inter-process communication method herein may be the steps in the inter-process communication methods of the respective embodiments described above.

It will be understood by those skilled in the art that all or part of the processes of the methods of the embodiments described above can be implemented by a computer program, which can be stored in a non-volatile computer-readable storage medium, and can include the processes of the embodiments of the methods described above when the program is executed. Any reference to memory, storage, database, or other medium used in the embodiments provided herein may include non-volatile and/or volatile memory, among others. Non-volatile memory can include read-only memory (ROM), Programmable ROM (PROM), Electrically Programmable ROM (EPROM), Electrically Erasable Programmable ROM (EEPROM), or flash memory. Volatile memory can include Random Access Memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms such as Static RAM (SRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDRSDRAM), Enhanced SDRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), Rambus Direct RAM (RDRAM), direct bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

Thus, in an embodiment, a computer-readable storage medium is provided, in which a computer program is stored which, when being executed by a processor, causes the processor to carry out the steps of the above-mentioned inter-process communication method. The steps of the inter-process communication method herein may be the steps in the inter-process communication methods of the respective embodiments described above.

The technical features of the above embodiments can be arbitrarily combined, and for the sake of brevity, all possible combinations of the technical features in the above embodiments are not described, but should be considered as the scope of the present specification as long as there is no contradiction between the combinations of the technical features.

The above-mentioned embodiments only express several embodiments of the present application, and the description thereof is more specific and detailed, but not construed as limiting the scope of the present application. It should be noted that, for a person skilled in the art, several variations and modifications can be made without departing from the concept of the present application, which falls within the scope of protection of the present application. Therefore, the protection scope of the present patent shall be subject to the appended claims.

Claims

1. An interprocess communication method, comprising:

receiving an inter-process communication instruction, sending a calling service binding request to a target server process by calling a service binding interface function, and establishing binding connection with the target server process, wherein the calling service binding request carries client process identification information; the service binding interface function is obtained by packaging the service binding process of the client;

calling a service interface function, and sending a calling service request to the target server process through the binding connection, wherein the calling service request carries information of a method to be called; the service interface function is obtained by encapsulating the service provided by the server process;

2. The method of claim 1, wherein invoking a service interface function and sending a call service request to the target server process over the bound connection comprises any one of:

the first item: when the service interface function is in a singleton mode, executing the service interface function, and sending a service calling request to the target server process;

the second term is: when an instance creating instruction is received, calling a service interface function to create a dynamic proxy instance; and sending a service calling request to the target server through the dynamic proxy instance.

3. The method of claim 2, wherein invoking a service interface function to send a call service request to the target server process over the bound connection comprises:

calling a service interface function, and determining a currently called dynamic proxy class;

serializing the parameters to be transmitted to obtain serialized parameters;

packaging the information of the method to be called of the currently called dynamic proxy class to obtain the packaged information of the method to be called, wherein the information of the method to be called comprises the following steps: the identification information of the method to be called, the serialized parameters and the operation return value;

and sending a calling service request to the target server process, wherein the calling service request carries the packaged information of the method to be called.

4. The method of claim 3, wherein the serializing the parameters to be transmitted to obtain the serialized parameters comprises any one of the following:

when the parameter to be transmitted is a first type parameter, carrying out recursive serialization on variables of the parameter to be transmitted one by one to obtain a parameter after serialization;

when the parameter to be transmitted is the second type parameter, multiplexing a preset serialization mode, and serializing the parameter to be transmitted to obtain a parameter after serialization;

when the parameter to be transmitted is a third type parameter, after the internal variables of the parameter to be transmitted are checked one by one, serializing the internal variables to obtain a serialized parameter;

and when the parameter to be transmitted is the fourth type parameter, taking the class name as a parameter after serialization.

5. An interprocess communication method, comprising:

receiving a calling service binding request, wherein the calling service binding request carries client process identification information, and a binding connection with a client process is established through a service binding interface function, and the client process corresponds to the client process identification information; the service binding interface function is obtained by packaging the service binding process of the client;

and executing the operation of the method corresponding to the information of the method to be called through a service interface function to obtain an operation result, and returning an operation return value to the client process based on the operation result, wherein the service interface function is obtained by encapsulating the service provided by the server process.

6. The method according to claim 5, wherein the performing, by a service interface function, the operation of the method corresponding to the method information to be called to obtain an operation result includes:

analyzing the information of the method to be called through a service interface function to obtain a currently called dynamic proxy example, identification information of the method to be called and serialized parameters;

performing deserialization operation on the serialized parameters to obtain deserialized parameters;

and executing the method corresponding to the identification information of the method to be called through the dynamic proxy class and the deserialized parameter to obtain an operation result.

7. An interprocess communication apparatus, comprising:

the client binding module is used for receiving an interprocess communication instruction, sending a calling service binding request to a target server process by calling a service binding interface function, and establishing binding connection with the target server process, wherein the calling service binding request carries client process identification information; the service binding interface function is obtained by packaging the service binding process of the client;

the method calling module is used for calling a service interface function and sending a calling service request to the target server process through the binding connection, wherein the calling service request carries information of a method to be called; the service interface function is obtained by encapsulating the service provided by the server process;

8. The apparatus of claim 7, wherein the client binding module receives an inter-process communication command and creates a service binding interface function instance by calling a service binding interface function; and sending a calling service binding request to the target server process through the service binding interface function instance, and establishing binding connection with the target server process.

9. The apparatus of claim 8, wherein the client binding module is configured to reclaim the service binding interface function instance when the service binding interface function instance reaches a service binding interface function instance lifecycle.

10. The apparatus of claim 7, wherein:

the client binding module is also used for receiving and caching a service agent handle which is returned by the target server process and is successfully connected after the binding connection with the target server process is established;

the service invocation request carries the service agent handle.

11. The apparatus of claim 7, wherein: and the method calling module executes the service interface function and sends a calling service request to the target server when the service interface function is in the singleton mode.

12. The apparatus of claim 7, wherein: the method calling module calls a service interface function to create a dynamic proxy example when receiving an example creating instruction; and sending a service calling request to the target server through the dynamic proxy instance.

13. The apparatus of claim 7, wherein the method call module comprises:

14. The apparatus of claim 13, wherein the serialization module recursively serializes the variables of the parameters to be transmitted one by one to obtain serialized parameters when the parameters to be transmitted are of a first type.

15. The apparatus according to claim 13, wherein the serialization module multiplexes a predetermined serialization manner to serialize the parameter to be transmitted when the parameter to be transmitted is the second type parameter, to obtain a serialized parameter.

16. The apparatus according to claim 13, wherein the serialization module performs serialization on the internal variables of the parameters to be transmitted after checking the internal variables one by one when the parameters to be transmitted are of the third type, so as to obtain the serialized parameters.

17. The apparatus according to claim 13, wherein the serialization module takes the class name as the serialized parameter when the parameter to be transmitted is the fourth type parameter.

18. The apparatus of claim 12, wherein the method invocation module further reclaims the dynamic proxy instance when the dynamic proxy instance reaches a dynamic proxy instance lifecycle.

19. An interprocess communication apparatus, comprising:

the server binding module is used for receiving a calling service binding request, the calling service binding request carries client process identification information, binding connection with a client process is established through a service binding interface function, and the client process corresponds to the client process identification information; the service binding interface function is obtained by packaging the service binding process of the client;

and the method execution module executes the operation of the method corresponding to the to-be-called method information through a service interface function to obtain an operation result, and returns an operation return value to the client process based on the operation result, wherein the service interface function is obtained by encapsulating the service provided by the server process.

20. The apparatus of claim 19, wherein:

the server binding module also returns a service agent handle to the client process after establishing binding connection with the client process through a service binding interface function;

the service invocation request carries the service agent handle.

21. The apparatus of claim 19, wherein the method executes modules comprising:

22. The apparatus of claim 19, wherein the method execution module makes a callback through a dynamic proxy and returns an argument to the client process through the dynamic proxy.

23. The apparatus of claim 21, wherein the method execution module retrieves the cached dynamic proxy instance upon receiving a dynamic proxy instance retrieval notification sent by the client process.

24. A computer device comprising a memory and a processor, the memory having stored thereon a computer program, characterized in that the processor, when executing the computer program, implements the steps of the method according to any of claims 1 to 6.

25. A computer-readable storage medium, on which a computer program is stored which, when being executed by a processor, carries out the steps of the method according to any one of claims 1 to 6.