CN111443961B

CN111443961B - Terminal equipment and cross-process communication method thereof

Info

Publication number: CN111443961B
Application number: CN202010212471.4A
Authority: CN
Inventors: 关安杰
Original assignee: Guangzhou Cubesili Information Technology Co Ltd
Current assignee: Guangzhou Cubesili Information Technology Co Ltd
Priority date: 2020-03-24
Filing date: 2020-03-24
Publication date: 2023-04-11
Anticipated expiration: 2040-03-24
Also published as: CN111443961A

Abstract

The invention relates to a terminal device and a cross-process communication method thereof, wherein the method comprises the following steps: the client process inquires an interface library which is registered with interface registration information in advance by the service process according to the call of the service module to the interface class to obtain an interface identifier of the interface class for format packaging, and initiates an interface creating request; the service process receives the interface creating request, analyzes the request, executes the creating operation of the corresponding implementation class by using the interface identifier in the request, generates an instance object of the implementation class, packages the instance object in a result format and feeds back result data generated by the creating operation to the client process; and the client process receives the result data, analyzes the result data into the proxy object of the instance object, and returns the proxy object of the instance object to the service module of the client process, so that the service module calls the instance object by calling the proxy object. The invention simplifies the development steps related to the realization of the communication interface in the development process of the application program and provides a more simple, convenient and efficient cross-process communication solution.

Description

Terminal equipment and cross-process communication method thereof

Technical Field

The invention relates to an application program development technology of an Android operating system, in particular to a cross-process communication method and corresponding terminal equipment.

Background

In the Android application development process, according to different service scales and scenes, a multi-process communication technology is introduced into a system in the prior art. By using the multi-process communication technology, the limitation of application allocable system resources can be broken through (the Android system resource allocation takes a process as a basic unit), the usable resources of the application are increased by times, and the service requirements of application keep-alive and the like can be realized.

The Android official itself provides a variety of techniques to address multi-process communications, and we commonly use AIDL to enable inter-process communications. AIDL is one of IPC (Inter-Process Communication) modes in Android, and is an abbreviation of Android Interface definition language. Although indexes of all aspects of AIDL are more in line with actual needs, the processing process is complex, and the development cost is high.

An interface method supporting multi-process communication is generally developed by using AIDL, and the following operations are required: 1. creating an aidl file, and defining an interface class in the aidl file; 2. if the parameters of the interface class method contain the custom type, an aidl file is required to be defined for the type; 3. a Service class is required to be established to provide communication Service of information for the process providing Service; 4. defining a Binder class to realize the interface class defined in aidl and realizing functional logic in the realization class; 5. the Service class returns the object of the Binder class in the step 4 to the Client program through the onBind interface; 6. the Client program needs to be connected with the Service class of the Server program, a proxy object of the Binder class is obtained in the onServiceConnected method, and the proxy object calls an interface method of the Binder class to obtain the function provided by the Binder class; 7. the Client program needs to maintain its connection state with the Service class because the Service class is the carrier of its communication interaction.

The key of the problem is that in general, each interface class providing the IPC service needs to be operated again according to the steps, so that although the prior art supports IPC communication, the development steps are complex and tedious, and the expandability is poor, thereby leading to higher development cost. This is particularly disadvantageous for the development of projects that need to be run in conjunction.

Disclosure of Invention

The invention aims to provide a cross-process communication method for improving the development efficiency of an application program.

Accordingly, as another object of the present invention, there is also provided a terminal device adapted thereto based on the method of the preceding object.

To meet the primary object of the present invention, the present invention provides a cross-process communication method, comprising the following steps:

the client process inquires an interface library which is registered with interface registration information in advance by the service process according to the call of a service module to the interface class to obtain an interface identifier of the interface class, packages the interface identifier according to a pre-protocol request format and initiates an interface creating request to the service process;

the service process receives the interface creating request, analyzes the request, executes the creating operation of the corresponding implementation class by using the interface identifier in the request, generates an instance object of the implementation class, reversely packages the instance object in a result format of a pre-protocol and feeds back result data generated by the creating operation to the client process;

and the client process receives the result data, analyzes the result data into a proxy object of the instance object according to a protocol, and returns the proxy object of the instance object to a service module of the client process, so that the service module calls the instance object by calling the proxy object.

Preferably, the service process is responsible for adding interface registration information of the implementation class to the interface library in advance by the service module, so as to realize the association between the interface identifier and the interface class and between the interface identifier and the implementation class, and the service process and the client process access the corresponding interface registration information in the interface library in the mutual interaction process so as to cooperate with the encapsulation and the analysis of the request format and the result format.

Preferably, to ensure reliable execution of the protocol, both the request format and the result format comply with a pre-specified protocol, so that both the service process and the client process can correctly parse the encapsulated format by one party.

In one embodiment, the proxy object is implemented based on Java proxy technology, which is built as a proxy for an instance object in a service process that is associated with the implementation class identified by the interface.

In one embodiment, after the client process runs, the client process is pre-registered with the service process and binding is performed on the running service component, so that subsequent interaction between the client process and the service process is realized.

Further, if the service component is not running, the client process requests the system to start the service component of the service process.

Preferably, the client process responds to the requirement of the service module thereof and realizes the process of calling the instance object by calling the proxy object, and the method comprises the following specific steps:

a service module of the client process initiates an interface calling request for calling the method of the proxy object;

the proxy object queries an interface library to determine corresponding attribute information of the method, forms the attribute information into a pre-protocol request format, and then sends the pre-protocol request format to a service process;

the service process receives and queries the interface library to analyze the attribute information, and calls the corresponding implementation class object to execute the corresponding method;

the service process feeds back result data after the method is executed to the client process in a result format of a pre-protocol;

the client process receives the result data, and returns the result data to the service module after analyzing and restoring the result data.

In a more specific embodiment, the attribute information includes an object identifier of the proxy object, a method identifier of the method, an operation parameter transferred to the method, and a return value type, after the attribute information is analyzed by the service process, the service process determines a target instance object according to the object identifier, determines a target method in the instance object according to the uniqueness of the method identifier, and the target method receives the operation parameter transferred in the attribute information, then operates, and returns result data specified by the return value type in the attribute information.

Preferably, the method identifies the associations that are implemented in the interface library with the interface classes, implementation classes, and instance objects.

In some embodiments, the service process is adapted to start the client process according to a preset condition.

In some embodiments, one of said service processes performs the method interaction with one or more of said client processes in parallel, and/or at least one of said client processes runs in a different virtual machine than the service process.

To meet other objects of the present invention, the present invention provides a terminal device, which includes a central processing unit and a memory, wherein the central processing unit is used for calling and running a computer program stored in the memory to execute the steps of the cross-process communication method according to the previous object.

Compared with the prior art, the invention has the following advantages:

firstly, the method of the invention uses the interface library to store and manage the implementation class of the application program, the built-in implementation class is registered in the interface library in advance when the application program runs and then is called by the client process, in the process, the interface class of the client process, the implementation class of the application program, the example object of the implementation class, the proxy object and other memory resources are associated through the interface identifier, and the centralized scheduling and control function is realized for the calling between the processes, so that the interface calling between the application program (expressed as a service process) and the client process is more flexible and efficient. For the class method layer, the interface library also configures a storage and management mechanism for the class method layer, so that the related attribute information required by the operation of the built-in method of the instance object can realize cross-process intercommunication by inquiring the interface library, and therefore, the client process can realize the parameter transmission and calling of the built-in method of the instance object of the service process through the proxy object. Therefore, the interface library and the protocol analysis mechanism thereof are arranged, so that cross-process efficient communication is possible.

And secondly, the improvement of the cross-process communication efficiency is embodied in the development process, and particularly in the development process of an Android operating system, the program development efficiency can be greatly improved. In Android, when interfaces are called among different processes, completely consistent interface configuration flows do not need to be executed for new interfaces each time based on AIDL, namely, development steps of adding cross-process communication interfaces in an Android system are simplified. Therefore, when the application program implementing the present invention is upgraded, if the related cross-process communication interface is added or deleted in the upgraded version, the change of the interface registration information of the interface library will be reflected. Therefore, the method can greatly improve the program development efficiency and is beneficial to releasing the development capability, thereby comprehensively reducing the project development cost.

Moreover, because the service process is provided with the service component, the interface calling mechanism of the service process can provide services for a plurality of client processes in parallel, and no matter whether the client processes belong to the application program or other application programs, the service process provides a convenient technical implementation basis for some jointly developed projects such as a login module, an authorization module, a payment module, a filtering module and the like. The client process, whether the application program or different application programs, has the capability of realizing interaction with the application program as long as the client process complies with the protocol specified by the method of the invention, so that the resource of the application program can be called mutually, and the client process and the service process expressed by the application program share the memory resource. The basic technology is also beneficial to ensuring the survival of service processes or client processes in the memory, and the activities of the class interfaces are scheduled and realized through a mechanism that the service components bind with each other, so that the processes can be awakened mutually, the activity of each process in the memory is ensured, the processes are prevented from being finished in the memory cleaning process, and even another process can be restarted through one process, so that the processes are always operated in the system.

Furthermore, the service process realizes the capability of interface centralized maintenance and service, the client process can simplify development, and one or more client processes can provide interface service by the service process no matter the processes belong to the same application program or different programs, so that the efficient effect of the terminal program related to the joint development project for realizing some core functions in a centralized manner or some scenes needing extension plug-in can be reflected.

In addition, the invention adopts a protocol analysis mechanism between the service process and the client process aiming at the intermediate process data, particularly adopts a first format at a calling level and a second format at a result level, the two formats are parallel and are not contradictory, so that technical personnel in the field can develop analysis modules with concentrated functions to be configured in the client process and the service process, the analysis and encapsulation functions corresponding to different formats can be developed in a modularized way, and the development efficiency is further improved while the communication safety between different processes is ensured.

Additional aspects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention.

Drawings

The above and/or additional aspects and advantages of the present invention will become apparent and readily appreciated from the following description of the embodiments, taken in conjunction with the accompanying drawings of which:

FIG. 1 is a schematic diagram illustrating an architecture for implementing a client process and a service process according to the principles of the present invention;

FIG. 2 is a flowchart illustrating an API call control method according to an exemplary embodiment of the present invention;

FIG. 3 is a flow chart illustrating a cross-process communication method according to an exemplary embodiment of the present invention;

fig. 4 is a flowchart illustrating a specific step of step S23 in the cross-process communication method according to the present invention.

Detailed Description

Reference will now be made in detail to embodiments of the present invention, examples of which are illustrated in the accompanying drawings, wherein like reference numerals refer to the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the drawings are illustrative only and should not be construed as limiting the invention.

As used herein, the singular forms "a", "an", "the" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and/or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. It will be understood that when an element is referred to as being "connected" or "coupled" to another element, it can be directly connected or coupled to the other element or intervening elements may also be present. Further, "connected" or "coupled" as used herein may include wirelessly connected or wirelessly coupled. As used herein, the term "and/or" includes all or any element and all combinations of one or more of the associated listed items.

It will be understood by those skilled in the art that, unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of the prior art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.

As will be appreciated by those skilled in the art, "client," "terminal," and "terminal device" as used herein include both devices that are wireless signal receivers, which are devices having only wireless signal receivers without transmit capability, and devices that are receive and transmit hardware, which have receive and transmit hardware capable of two-way communication over a two-way communication link. Such a device may include: cellular or other communication devices such as personal computers, tablets, etc. having single or multi-line displays or cellular or other communication devices without multi-line displays; PCS (Personal Communications Service), which may combine voice, data processing, facsimile and/or data communication capabilities; a PDA (Personal Digital Assistant), which may include a radio frequency receiver, a pager, internet/intranet access, a web browser, a notepad, a calendar and/or a GPS (Global Positioning System) receiver; a conventional laptop and/or palmtop computer or other device having and/or including a radio frequency receiver. As used herein, a "client," "terminal device" can be portable, transportable, installed in a vehicle (aeronautical, maritime, and/or land-based), or situated and/or configured to operate locally and/or in a distributed fashion at any other location(s) on earth and/or in space. The "client", "terminal Device" used herein may also be a communication terminal, a web terminal, a music/video playing terminal, such as a PDA, an MID (Mobile Internet Device) and/or a Mobile phone with music/video playing function, and may also be a smart tv, a set-top box, and the like.

The hardware referred to by the names "terminal device", "mobile terminal", etc. of the present invention is essentially a device having the performance of a personal computer, etc., and is a hardware device having necessary components disclosed by von neumann principles such as a central processing unit (including an arithmetic unit and a controller), a memory, an input device, and an output device, etc., in which a computer program is stored, and the central processing unit calls a program stored in an external memory into the internal memory to run, executes instructions in the program, and interacts with the input and output devices, thereby accomplishing specific functions.

The main implementation principle of the invention is disclosed in the following with the accompanying drawings:

the application program of the present invention runs in the form of a computer program in a terminal device such as a mobile terminal, e.g., a mobile phone, a tablet, etc., and the terminal device runs an operating system with Android or forward-compatible Android (e.g., "harmon" — Harmony OS newly developed by hua corporation). The application program is scheduled by the central processing unit to run in the memory, and the related method of the invention is realized.

Each application will run specifically in one virtual machine of the system, according to the mechanisms inherent to the operating system. Of course, operating systems also support multi-process architectures, and thus, the same application may include multiple processes, such as running its process providing service functionality through a registration service component on a host process basis.

Referring to fig. 1, after the application program of the related method implemented by the present invention runs in the memory, two types of processes associated with the related method of the present invention are allowed to exist in the memory, one type is a service process 2 that is the main body of the application program, and the other type is a client process 1 that belongs to the application program or to another application program but can interact with the service process 2 to implement interface call.

The service process 2 and the client process 1 establish a protocol mechanism, and both of them obey the related development protocol in advance, so that in the scene that the data format is needed, the encapsulation and the decapsulation (parsing) are included in the specific data format, and because the protocol exists between the two, the data encapsulated by the other party can be mutually identified, thereby correctly restoring the content transmitted by the other party. That is, the data format encapsulated by one of the client process 1 and the service process 2 can be correctly analyzed by the other in accordance with the protocol. The protocol between the service process 2 and the client process 1 defines two formats, the first being the request format and the second being the result format. The request format is used for packaging and unpacking various requests initiated by the client process 1, the related data mainly includes interface identifiers, method identifiers (and attribute information such as running parameters and return value types of methods) obtained after the client process analyzes the interface class annotations, object identifiers carried by the proxy objects and the like, the result format is used for packaging and unpacking various result data generated by the execution and calling of the service process 2, and mainly includes an instantiation implementation class, an object identifier distributed for the instance object after the instance object is generated, a return value after the built-in method of the instance object is called and executed, and the like. The request format is typically encapsulated by the client process 1 and parsed by the service process 2, and the resulting data is typically encapsulated by the service process 2 and parsed by the client process 1. For this purpose, as will be disclosed hereinafter, the client process 1 and the service process 2 will each build a dedicated functional module, i.e. the parsing module 13, 23, for implementing these data format related encapsulation and decapsulation functions.

The service process 2 is responsible for registering the interface and subsequently receiving the interface creating and calling request of the client process 1, so as to provide the interface creating and calling service for the client process 1. In order for the service process 2 to maintain its service function, it needs to register a service component 20 with the system, thereby implementing a background operation. The service process 2 mainly comprises a service module 21, an execution module 22, an analysis module 23, a transceiver module 24 and the service component 20, and maintains an interface library 25 by executing registration after starting, wherein the service module 21 is responsible for the registration function of the interface implementation class; its service component 20 primarily provides the client process 1 with bindings to ensure communication between the service process 2 and the client process 1; the transceiver module 24 is responsible for receiving various requests of the client process 1 on one hand, and for feeding back various result data to the client process 1 on the other hand, and the communication transmission between the service process 2 and the client process 1 is satisfied through the bidirectional service function; the parsing module 23 is mainly used for parsing various requests encapsulated by the client process 1 in a first format (request format), and encapsulating various result data in a second format (result format) to be sent to the client process 1 through the transceiver module 24; the execution module 22 is mainly responsible for creating the corresponding implementation class when the client process 1 requests the interface call and executing the built-in method of the implementation class.

The client process 1 is mainly responsible for interacting with the service process 2, serving the interface creation and call requirements of the service module 11, and maintaining the request process of the interface creation and call. The client process 1, upon its startup, seeks a binding with the service component 20 of the service process 2 and is responsible for maintaining the bound connection state. If the service process 2 is not started, the client process 1 may even be responsible for invoking the service component 20 running the service process 2 to facilitate its subsequent invocation of the relevant interface. Corresponding to the service process 2, the client process 1, except its own service module 11, similarly constructs a transceiver module 14 and an analysis module 13 corresponding to the service process 2, and the transceiver module 14 is responsible for receiving various result data of the service process 2 on one hand and for sending various requests initiated by its own service module 11 to the service process 2 on the other hand; the parsing module 13 is mainly used for parsing the interface identifier from the programming annotation of the interface to be called by the service module 11 and packaging the interface identifier into an interface creation request in a first format, and further used for parsing the attribute information from the programming annotation of the implementation class built-in method to be called by the service module 11 and packaging the attribute information into an interface calling request in the first format, so that the request is sent to the service process 2 by the transceiver module 14 of the client process 1 in the following; the analysis module 13 reversely analyzes various result data transmitted from the service process 2, including result data corresponding to the interface creation request and the interface calling request, so as to feed back to the service module 11 of the client process 1.

It should be noted that in the Android and its compatible system, there is an IPC mechanism, which allows the interface to interact across processes. When developing, a Binder class is defined to realize the interface class predefined by AIDL, and the functional logic is realized in the realization class. After the service component 20 of the service process 2 runs, the client process 1 connects with it, obtains the proxy object of the Binder class in the onServiceConnected method, and obtains the function provided by the Binder class by calling the interface method of the Binder class through the proxy object. At the same time, the client process 1 is responsible for maintaining the connection state between itself and the service component 20. The implementation of the present invention is also based on the underlying mechanism, and the effective utilization of the mechanism is realized through the relevant steps of the present invention, as will be understood by those skilled in the art.

The interface library 3 of the present invention can implement unified execution of the access of the client process 1 and the service process 2 to the interface library 3 by constructing a relatively independent interface management module in terms of function. Of course, this is a logical requirement, and in fact, the interface management module can be generally constructed by the service process 2, and can also be constructed by the service process 2 and the client process 1 respectively to construct the required partial functions of itself, and the implementation manner is flexible. The interface library 3 maintained by the interface management module is logically maintained mainly by the service process 2 for the client process 1 to utilize, but in an interactive mode, both the service process 2 and the client process 1 access the interface library 3 so as to realize a relevant protocol analysis mechanism.

As mentioned above, the interface library 3 is mainly used for recording the relevant data related to the interface, and its representation form can be flexibly implemented by those skilled in the art. The interface library 3 is mainly used for storing interface registration information formed by the registration of the service process 2 and interface registration information related to instance objects generated in the interaction process of the service process 2 and the client process 1. For example, the interface registration information may be structured as the following table: class table, method table, instance table.

The class table is used for storing the information of the expression class table. The class table information is used to represent the corresponding relationship between the interface identifier of the interface and the implementation class, and through this corresponding relationship, the client process 1 can query and determine the relevant interface identifier according to the interface class to be called by its service module 11, and the service process 2 can query and determine the relevant implementation class according to the analyzed interface identifier, and they are corresponding to each other and can be uniquely determined.

The method table is used for storing the information of the expression method table. The method table information is used for representing the relationship between the implementation class and built-in methods thereof and the calling and running information of the built-in methods. The characterization of the relationship between the implementation class and the built-in method thereof can be realized by establishing a unique corresponding relationship between the calling operation information of the built-in method in the method table information and the interface identifier. The calling operation information is related information determined for each built-in method by the service process 2 when registering the implementation class, and includes a method identifier assigned to the built-in method, an operation parameter required by the operation of the method, and a return value type defined by the method. It can be understood by those skilled in the art that, after the client process 1 defines the built-in method of a certain implementation class specified by the service module 11, the method table information, more specifically, the method identifier related to the built-in method, can be obtained by querying the interface registration information, specifically, the method table, in the interface library 3. Then, the client process 1 merges the operation parameters and the return value types provided by the service module 11 corresponding to the built-in method, and transmits these pieces of call operation information to the service process 2. After parsing the calling operation information transmitted from the client process 1, the service process 2 obtains the method identifier therein, and queries the interface library 25 according to the method identifier to determine the built-in method in the specific instance object for execution.

The example table is used for storing and expressing the example table information. The instance table information is used to characterize information related to the implementation class instance object that is providing service for the client process 1, and specifically, a corresponding object identifier may be assigned to each instance object, and the proxy object also carries the identifier, so that the instance object is further associated with the proxy object, and the instance object may also be determined by the object identifier and called. Of course, other direct or indirect identifications can be given, and even interface identifications of related implementation classes can be further associated, in any case, the only requirement is that the call corresponding to the uniqueness of the instance object through the proxy object is enough to be ensured. And so on, as will be flexible to implement by those skilled in the art.

The interface registration information refers to information related to interface creation and call for implementing the method, and includes various information obtained by parsing the programming annotation of the implementation class when the service process 2 is started, and also includes instance information maintained in the operation process of the service process 2. The service module 21 of the service process 2 calls the implementation class of the API interface providing the service to register the method of the registered service class, and after receiving the registration request, the internal calling interface management module of the method of the registered service class obtains the relevant information of the registered implementation class, analyzes whether the class uses the relevant annotation to mark the interface identifier of the implementation class according to the protocol, and stores the interface identifier as the interface registration information for calling when the interface identifier exists. Then, whether the related built-in method of the type uses the annotation of the protocol of the invention is analyzed, and after the related built-in method uses the standard annotation, the interface identifier, the method identifier, the operation parameter, the return value type and the like related to the built-in method are stored in the method table as part of the interface registration information. The service process 2 completes the registration of the interface through the process, forms the basic data of the interface registration information and provides a key basis for the subsequent cross-process interface call.

On the basis of the interface registration information, when actually calling the built-in method of the instance object, the client process 1 is realized through the proxy object of the instance object, so that the proxy object of the client process 1 needs to call an analysis mechanism of the client process 1, query the interface library 3, generally method table information therein, determine an interface identifier or an object identifier corresponding to the built-in method and call running information thereof, and form attribute information required for running the built-in method, so as to finally provide the service process 2 with reverse analysis and utilize the attribute information, thereby ensuring that the built-in method of the instance object can be effectively called and executed by the service process 2. It should be noted that, depending on the specific implementation of the proxy object, although the following principle of the present invention discloses a case of implementation by using an object identifier, it should be understood by those skilled in the art that the same effect can be achieved by using the interface identifier as long as it is ensured that there is a one-to-one correspondence between the proxy object and the instance object and that the processes are agreed with each other.

The proxy object referred to herein is implemented by using Java proxy technology, and those skilled in the art can map the instance object of the corresponding implementation class created by the service process 2 in response to the interface creation request to a corresponding proxy object at the client process by using Java proxy technology, where the proxy object is generated by the response of the interface creation request, the service process 2 allocates a corresponding object identifier after the instance object is generated, and provides the object identifier to the client process to generate the proxy object, and the proxy object also carries the object identifier.

Corresponding to the link of the interface creation request, the business module 11 of the client process 1 initiates a request service for a certain interface class, and the client process 1 responds thereto in a method of requesting the service. The method for requesting service utilizes an analysis mechanism to inquire an interface library 3 to determine the interface identification corresponding to the interface class, encapsulates the interface identification into request format data and transmits the request format data to a service process 2. The service process 2 receives the request format data, analyzes the request format data, inquires interface registration information in the interface library 3 by using the interface identifier in the request format data, determines a corresponding implementation class, creates an instance object of the implementation class, generates a unique object identifier for the object, and stores the corresponding relation between the object identifier and the object as instance table information, so that a proxy object generated by the subsequent client process 1 naturally carries the object identifier, so that the service process 2 can determine a corresponding instance object according to the uniqueness of the object identifier as long as the object identifier of the subsequent proxy object is transmitted to the service process 2. After the client process 1 has created the proxy object, it is returned to the service module 11 of the client process 1 for further method calls.

In a link corresponding to the interface call request, the service module 11 of the client process 1 takes the proxy object corresponding to the interface creation request, and then further initiates an interface call request for calling a relevant built-in method of the instance object pointed by the proxy object. The client process 1 responds to the interface call request, calls an analysis mechanism to obtain a method identifier, an operation parameter, a return value type and an object identifier related to a built-in method, forms attribute information by the information, packages the format and sends the attribute information to the service process 2. The service process 2 calls an analysis mechanism to analyze each item of specific information in the attribute information, then calls and executes the built-in method, can determine an instance object to be called according to the object identifier in the built-in method, can determine the specific built-in method according to the method identifier in the built-in method, then transmits related operation parameters to the built-in method to be used as transmission parameters for operation, and obtains a result which is in accordance with the type of the return value after the built-in method is operated. Then, the service process 2 can package the related result data in the second format and return the result data to the client process 1. The proxy object in the client process 1 obtains the data call analysis mechanism and returns the data call analysis mechanism to the service module 11 of the client process 1 after the data call analysis mechanism is correspondingly analyzed, and the response to the interface call request is completed.

It can be seen that, in any link, when the analysis mechanism of the pre-protocol is used between the client process 1 and the service process 2 for analysis or encapsulation, the application of the interface registration information in the interface library 3 needs to be matched, so that the related format data has a definite purpose.

Usually, after the client process 1 is unbound to the service component 20 of the service process 2, a step of cleaning the memory may be further performed, and by performing the step, the interface management module cleans up the relevant objects in the instance table of the interface library 3. On the other hand, for the purpose of program keep-alive, the client process 1 and the service process 2 may start or wake up each other in one way or in a mutual manner according to a preset rule, such as timing, according to a trigger condition, and the like, so that both sides can survive in the memory, and are prevented from being cleaned up by the memory cleaning program of the operating system or the third-party security software.

As can be seen from the above disclosure of the principles of the present invention, through the protocol between the client process 1 and the service process 2, the step of defining the cross-process interface by the aid l is multiplexed by the interface library 3, so that the repeated development rate related to the development of the cross-process interface can be greatly reduced, and a solid technical foundation is provided for high-level applications of cross-process communication.

In the aspect of simplifying the development process and improving the development efficiency, if the cross-process communication interface needs to be expanded in the development process of the application program applying the principle of the invention, only the interface class and the implementation class corresponding to the interface class need to be created, and the bottom-layer communication development is repeatedly performed for the interface class and the implementation class corresponding to the interface class. When the change is reflected in different application versions of the application program, it can be known that, after the service module 21 of the service process 2 of the application program with the updated new version registers all implementation classes to the interface library 3 again, the total number of interfaces in the interface library 3 will correspondingly increase or decrease. If the developer expands and adds interfaces, and correspondingly adds interface classes and implementation classes thereof, the total number of interfaces in the interface library 3 is correspondingly increased, and if the developer deletes interfaces, and correspondingly reduces interface classes and implementation classes thereof, the total number of interfaces in the interface library 3 is correspondingly reduced. In short, the AIDL does not need to be reused for more repeated development, and unnecessary AIDL definition files are avoided.

In understanding the implementation principle of the present invention described above, various manifestations of the present invention will be examined below from different perspectives of the implementation principle of the present invention.

Referring now to FIG. 2, an exemplary embodiment of the present invention is shown at the application level represented by the principles of the present invention. In this embodiment, the application program interface call control method of the present invention is implemented in the form of a computer program, and provides the application program of the present invention, where the application program is installed and run in an operating system, and then the execution includes the following steps:

step S11, after the service component 20 pre-registered in the operating system is started, the application receives binding communication with the client process 1 belonging to the same application or a different application through the service component 20.

Taking an Android system as an example, the application program may declare a service component 20 in an Android manifest (xml) file of an installation configuration file of the application program, and after the service component 20 is started by a system, the application program plays a role of a service process 2 in a memory, and may implement communication interaction with other client processes 1 through the service component 20. The client process 1 may be a process in which a service component of the application is located, for example, or may be a client process 1 that is expressed when other applications, particularly some applications that agree on a joint development project of a protocol scheme run.

According to the principle of the Android operating system, generally speaking, a process related to an application program is operated in an independent virtual machine, but a multi-process architecture is allowed to exist in the same application program, for example, the multi-process architecture can be realized by the application program in a mode of declaring a service component. Therefore, it can be understood that the client process 1 and the service process 2 can run in the same virtual machine or different virtual machines in parallel, and when the client process 1 does not belong to the application program, it means that the client process 1 and the service process 2 belong to different memory virtual machines, but due to the implementation of the present invention, the development related to interface calling between them becomes simpler.

After the service component 20 is started, the client process 1 can bind to it. In accordance with the principles of the present invention, the client process 1 is then responsible for maintaining the connection status between it and the service component to determine the stable connection between the client process 1 and the application. On the basis that the client process 1 and the service process 2 are bound, the follow-up party can further complete functions related to interface calling.

Step S12, the application program responds to an interface creating request initiated by the client process 1 based on the calling interface class, and creates an instance object of the implementation class corresponding to the interface class; the interface registration information corresponding to the implementation class is registered in the interface library 3 in advance by the application program, and is set in one-to-one correspondence with the interface class.

As mentioned previously, the client process 1 of the present invention will initiate an interface creation request to the present application program as required by its own business module 11 to use the relevant interface.

Within a client process 1, an interface call occurs when its business module 11 runs to an instruction that defines or calls the relevant interface class, where the business module 11 first needs the system to create the relevant interface for it. The client process 1 further queries the class table information in the interface library 3 according to the pre-agreed parsing mechanism, that is, calls the parsing module 13 thereof, determines the interface identifier uniquely corresponding to the interface to be created according to the class table information, encapsulates the query result by adopting the first format, encapsulates the query result into request format data, and sends the request format data to the application program.

Therefore, the transceiver module 24 of the service process 2 of the application receives the request through the service component and sends the request to the parsing module 23 for parsing, the parsing module 23 decapsulates the request format data to obtain the interface identifier, and then calls the execution module 22, and after the execution module 22 determines the corresponding implementation class from the class table information of the interface library 3 according to the interface identifier, the execution module executes to create the instance object of the implementation class. As described above, the application program has registered the interface registration information related to the implementation class in the interface library 3 in advance, and can avoid calling the implementation class by mistake according to the correspondence between the implementation class and the interface identifier.

After the instance object is created, an object identifier with unique characteristics is given, the one-to-one correspondence between the object identifier and the instance object is also updated into the interface library 3 by the application program, and the object identifier is also used as result data, packaged into result format data in a second format by the parsing module 23 of the service process 2 of the application program, and then fed back to the client process 1 by the transceiving module 24. After receiving the result format data, the transceiver module 14 of the client process 1 delivers the result format data to the parsing module 13 of the client process 1 to parse out the object identifier, and then creates a proxy object of the instance object by using the Java proxy technology, where the proxy object naturally carries the object identifier. Thus, when the service module 11 of the client process 1 is to initiate a call to the instance object through the proxy object, the proxy object can communicate with the service process 2 by its own object identifier, so that the service process 2 can correctly call the relevant instance object.

After the instance object is created, the related information is stored in the instance table of the interface library 3 as instance table information to provide a service. If the client process 1 is unbound from the service component 20 of the service process 2, the instance table information becomes redundant information that remains, so a parallel step can be provided to clean up the redundant information, specifically to delete the redundant information in the interface library 3 after the client process 1 is unbound from the service process 2. This step can be implemented in the service process 2 in theory to enable centralized management of memory, or can be provided in the client process 1, which is implemented by the client process 1 before it determines the unbinding itself.

On the basis of the successful creation of the instance object, the application program can further provide the client process 1 with a call service for the built-in method of the instance object.

Step S13, the application program responds to an interface call request initiated by the client process 1 for calling the built-in method of the instance object, where the request includes attribute information for executing the built-in method determined according to the interface registration information of the interface library 3, and calls the built-in method of the instance object according to the attribute information to generate result data to be fed back to the client process 1.

After the client process 1 successfully establishes the proxy object of the instance object, it returns to its service module 11 for further invocation. The service module 11 of the client process 1 will then initiate an interface call request to some built-in method of the instance object through the proxy object. Referring to the foregoing disclosure about the principle of the present invention, once the service module 11 initiates such a request, the proxy object may combine the calling operation information obtained by querying the method table information in the interface library 3, and package the object identifier carried by the proxy object, the method identifier of the built-in method, the operation parameter (data) of the built-in method passed by the service module 11, and the attribute information such as the return value type of the built-in method into an interface calling request in the request format by the calling analysis module 13, and then send the interface calling request to the application program through the transceiving module 14.

The transceiver module 24 of the application receives the interface call request transmitted by the proxy object, and calls the analysis module 23 to analyze the attribute information, and then calls the execution module 22 to execute the call of the built-in method. The execution module 22 queries the interface library 3, determines a corresponding instance object from the instance table according to the object identifier in the attribute information, and determines a built-in method of the corresponding instance object from the method table according to the method identifier, and then refers the running parameter data in the attribute information to the target built-in method in the target instance object, and invokes the execution to make the target built-in method return result data meeting the return value type specification. The result data obtained by operating the built-in method is packaged into a result format by the analysis module 23 of the application program and then is transmitted back to the proxy object of the client process 1, the proxy object reversely analyzes the result data and then returns the result data to the service module 11, and the service module 11 then obtains the call operation result of the built-in method of the instance object generated by calling the implementation class corresponding to the interface class, and the whole interface call process is completed.

In some embodiments, the return value type does not need to be added as attribute information, and on the one hand, it may be considered that the item does not need to be recorded in the method table information of the interface library 3, and on the other hand, the item does not need to be used in the interaction process of the client process 1 and the service process 2, and those skilled in the art should know this variation.

In some embodiments, as described above, the application program may independently construct an interface management module to centrally manage access to the interface library 3, and provide a call interface for a module that needs to access the interface library 3 to perform call execution, so that memory efficiency may be improved.

The implementation of the exemplary embodiment is helpful for providing the application program with the cross-process service function at the application program level, and is convenient for accessing other application programs, thereby facilitating the development of the combined program project.

After the application program embodied in this exemplary embodiment is further installed in a mobile device such as a mobile terminal, a tablet, or the like, it may be embodied as another embodiment of the present invention, and this embodiment is embodied as a terminal device provided by the present invention, and includes a central processing unit and a memory, where the central processing unit is configured to call and run a computer program stored in the memory to execute the specific steps of the application program interface call control method described above.

Referring to fig. 3, another exemplary embodiment of the present invention is shown at the process level represented by the principles of the present invention. In this embodiment, a cross-process communication method according to the present invention includes the following steps:

step S21, according to the calling of the service module 11 to the interface class, the client process 1 queries the interface library 3 which is registered with the interface registration information in advance by the service process 2 to obtain the interface identifier of the interface class, packages the interface identifier according to the pre-agreed request format, and initiates an interface creation request to the service process 2.

As described in the principles and other embodiments of the present invention, the interface library 3 has been pre-configured by the service process 2, the service process 2 has registered class table information and method table information with the interface library 3, and also updated and maintained instance table information during interaction with the client process 1, so that the client process 1 can directly utilize the interface registration information of the interface library 3 in this step. In addition, the client process 1 and the service process 2 also implement their respective internal functional modules according to the principles of the present invention.

The service module 11 of the client process 1 first initiates a call to a specific interface class, and the client process 1 queries the interface registration information of the interface library 3 through the analysis module 13 according to the call to the interface class, specifically, through the class table in the interface library 3, queries and obtains the interface identifier corresponding to the interface class. Then, the parsing module 13 encapsulates the interface identifier into a request format in compliance with the protocol of the service process 2, and forms an interface creation request, which is sent to the service process 2 via the transceiver module 14 of the client process 1.

Step S22, the service process 2 receives the interface creating request, analyzes the request, executes the creating operation of the corresponding implementation class by using the interface identifier therein, generates the instance object of the implementation class, reversely packages the instance object in the result format of the pre-protocol and feeds back the result data generated by the creating operation to the client process 1;

after the service process 2 receives the interface creation request through the transceiving module 24, the parsing module 23 parses the interface identifier therein, and then the execution module 22 queries the interface library 3 to determine the implementation class corresponding to the interface identifier, and then executes an action of creating an instance object of the implementation class.

After the implementation object is created, an object identifier is assigned to the instance object, and the object identifier is available to the client process 1. After the service process 2 constructs the instance object, the object identifier of the instance object is encapsulated into result data according to the second format of the pre-protocol, and the result data is returned to the client process 1 through the transceiver module 24.

Step S23, the client process 1 receives the result data, parses the result data into a proxy object of the instance object according to a protocol, and returns the proxy object to the service module 11 of the client process 1, so that the service module 11 calls the instance object by calling the proxy object.

After receiving the result data through the transceiving module 14 of the client process 1, the client process sends the result data to the parsing module 13 of the client process to parse the object identifier of the client process, constructs a proxy object of the instance object pointed by the object identifier by using a Java proxy technology, wherein the proxy object carries the object identifier, and then returns the proxy object to the service module 11 of the client process 1 to perform next method invocation, and the service module 11 can implement invocation of the instance object by invoking the proxy object.

Referring to fig. 4, in addition to implementing the service module 11 by using the proxy object to implement the call to its corresponding instance object in a manner that can be understood by those skilled in the art, in a further optimized embodiment, the client process 1 may cooperate with the service process 2 to invoke the proxy object according to the following specific steps, so as to further implement the call to the built-in method of the instance object pointed to by the proxy object:

in step S231, the service module 11 of the client process 1 initiates an interface call request for calling the method of the proxy object.

When the service module 11 of the client process 1 needs to call the built-in method of the interface class of the corresponding proxy object, the service module initiates the interface call request, and expects a returned result by calling the proxy object, and the proxy object is responsible for executing the intermediate process to acquire the result.

Step S232, the agent object queries the interface library 3 to determine corresponding attribute information of the method, and sends the attribute information to the service process 2 after forming a pre-agreed request format.

As described above, the proxy object may combine the call operation information obtained by querying the method table information in the interface library 3, and send the object identifier carried by the proxy object, the method identifier of the built-in method, the operation parameter (data) of the built-in method transmitted by the service module 11, and the attribute information such as the return value type of the built-in method, after being encapsulated into the interface call request in the request format, the proxy object calls the analysis module 13 and then sends the interface call request to the service process 2 through the transceiver module 14.

Step S233, the service process 2 receives and queries the interface library 3 to parse the attribute information, and invokes the corresponding implementation class object to execute the corresponding method.

The transceiving module 24 of the service process 2 receives the interface call request transmitted by the proxy object, and after the calling analysis module 23 analyzes the attribute information therein, the calling execution module 22 executes the call to the target method. The execution module 22 queries the interface library 3, determines a corresponding instance object from the instance table according to the object identifier in the attribute information, and determines a built-in method of the corresponding instance object from the method table according to the method identifier, and then refers the running parameter data in the attribute information to a target built-in method in the target instance object, and invokes the execution to return the result data according with the return value type specification by the target method.

In step S234, the service process 2 feeds back result data after the method is executed to the client process 1 in a result format of the pre-agreement.

The result data obtained by the service process 2 calling the running target method is encapsulated into a result format by the parsing module 23 of the service process 2, and then is returned to the proxy object of the client process 1 via the transceiving module 24 of the service process 2, so as to be transmitted to the service module 11 of the client process 1 for use.

In step S235, the client process 1 receives the result data, and returns the result data to the service module 11 after parsing and restoring the result data.

After the client process 1 receives the result data returned to the proxy object by the service process 2 through the transceiver module 14, the proxy object calls the parsing module 13 to reversely parse the result data and directly return the parsed result data to the service module 11, and the service module 11 then obtains the call operation result of the built-in method of the instance object generated by the implementation class corresponding to the call interface class, thereby completing the whole interface call process.

Similarly, in some embodiments, the return value type does not need to be added as attribute information, and on the one hand, it may be considered that the item does not need to be recorded in the method table information of the interface library 3, and on the other hand, the item does not need to be used in the interaction process of the client process 1 and the service process 2, and those skilled in the art should know this variation.

The implementation of the exemplary embodiment provides a bottom-layer implementation scheme of cross-process communication, so that the principle of the invention can be applied to the bottom layer, and the technical obstacle existing in cross-process communication is solved.

Similarly, the application program embodied in this exemplary embodiment may be embodied as another embodiment of the present invention after being installed on a mobile device such as a mobile terminal or a tablet, and the embodiment is embodied as a terminal device provided by the present invention and includes a central processing unit and a memory, where the central processing unit is configured to call and run a computer program stored in the memory to execute the steps of the cross-process communication method described above.

In conclusion, the invention simplifies the development steps related to the communication interface realization in the application program development process, and provides a simpler, more convenient and more efficient cross-process communication solution for the jointly developed program project.

Those skilled in the art will appreciate that the present invention includes apparatus relating to performing one or more of the operations, methods described in the present invention. These devices may be specially designed and manufactured for the required purposes, or they may comprise known devices in general-purpose computers. These devices have computer programs stored in their memories that are selectively activated or reconfigured. Such a computer program may be stored in a device (e.g., a computer) readable medium, including, but not limited to, any type of disk including floppy disks, hard disks, optical disks, CD-ROMs, and magnetic-optical disks, ROM (Read-Only memories), RAM (Random Access memories), EPROMs (Erasable Programmable Read-Only memories), EEPROMs (Electrically Erasable Programmable Read-Only memories), flash memories, magnetic cards, or optical cards, or any type of media suitable for storing electronic instructions, and each coupled to a bus. That is, a readable medium includes any medium that stores or transmits information in a form readable by a device (e.g., a computer).

It will be understood by those within the art that each block of the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations, can be implemented by computer program instructions. Those skilled in the art will appreciate that the computer program instructions may be implemented by a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, implement the aspects specified in the block diagrams and/or flowchart block or blocks of the present disclosure.

Those of skill in the art will appreciate that various operations, methods, steps in the processes, acts, or solutions discussed in the present application may be alternated, modified, combined, or deleted. Further, various operations, methods, steps in the flows, which have been discussed in the present application, may be interchanged, modified, rearranged, decomposed, combined, or eliminated. Further, steps, measures, schemes in the various operations, methods, procedures disclosed in the prior art and the present invention can also be alternated, changed, rearranged, decomposed, combined, or deleted.

The foregoing is only a partial embodiment of the present invention, and it should be noted that, for those skilled in the art, various modifications and decorations can be made without departing from the principle of the present invention, and these modifications and decorations should also be regarded as the protection scope of the present invention.

Claims

1. A method of cross-process communication, the method comprising the steps of:

the client process inquires an interface library which is registered with interface registration information in advance by the service process according to the call of the service module to the interface class to obtain an interface identifier of the interface class, packages the interface identifier according to a pre-protocol request format and initiates an interface creating request to the service process;

and the client process receives the result data, analyzes the result data into the proxy object of the instance object according to a protocol, and returns the proxy object of the instance object to the service module of the client process, so that the service module calls the instance object by calling the proxy object.

2. The method of claim 1, wherein:

the service process adds the interface registration information of the implementation class to the interface library in advance by the service module, realizes the association between the interface identification and the interface class and the implementation class, and accesses the corresponding interface registration information in the interface library to cooperate with the encapsulation and the analysis of the request format and the result format during the mutual interaction process of the service process and the client process.

3. The method of claim 1, wherein the request format and the result format both conform to a pre-specified protocol such that both the service process and the client process, one encapsulating format can be properly parsed by the other.

4. The method of claim 1, wherein the proxy object is implemented based on Java proxy technology, and is constructed as a proxy for an instance object associated with the implementation class identified by the interface in a service process.

5. The method of claim 1, further comprising the steps of:

after the client process runs, the client process is pre-registered with the service process and binding is implemented on the running service component, so that subsequent interaction between the client process and the service process is realized.

6. The method of claim 5, wherein the client process requests a system to start the service component of a service process if the service component is not running.

7. The method according to any one of claims 1 to 6, wherein a client process responds to the requirement of its business module to implement the process of calling the instance object by calling the proxy object, and comprises the following specific steps:

the proxy object inquires and determines corresponding attribute information of the method from an interface library, and sends the attribute information to a service process after forming a pre-protocol request format;

8. The method according to claim 7, wherein the attribute information includes an object identifier of the proxy object, a method identifier of the method, an operation parameter transferred to the method, and a return value type, after the attribute information is parsed by the service process, the service process determines a target instance object according to the object identifier, uniquely determines a target method in the instance object according to the method identifier, and the target method operates after receiving the operation parameter transferred in the attribute information, and returns result data specified according to the return value type in the attribute information.

9. The method of claim 1, wherein the method identifies that associations with the interface class, implementation class, and instance object are implemented in the interface library.

10. A method according to claim 1, characterized in that the service process is adapted to start the client process according to preset conditions.

11. A method according to any one of claims 1 to 6, wherein one of said service processes performs the method's interactions with one or more of said client processes in parallel, and/or at least one of said client processes runs in a different virtual machine than the service process.

12. A terminal device comprises a central processing unit and a memory, and is characterized in that: the central processor is configured to invoke execution of a computer program stored in the memory to perform the steps of the cross-process communication method according to any of claims 1 to 11.