The Android interprocess communication is based on the design pattern (1-1) of the proxy (proxy) and stub (pile or stub). wherein, Proxy will be the special interface into a universal interface, the stub will be the universal interface into a special interface, the data between the two of the conversion through parcel (packaging), Proxy is often used as a data sending agent, through the parcel data package sent, stub is often used as a data receiving pile , unpack and parse the parcel Data package. Android interprocess communication is done through the "agent-pile" design pattern.
Figure 1-1
Notice about proxy and stub:
The
- Stub is a pair of proxies, commonly known as "proxy-piles", and is commonly used in remote method invocations. The
- Proxy is equivalent to a remote control that is held in the hand, and the Stub is the remote receiver in the TV, which has one by one corresponding interface methods, but the direction of operation is just the opposite. The interface of the
- Proxy is called by the client program, which then wraps the information internally, passing it to the Stub in some way (for example, RMI), and then completes the "Remote Call" through the corresponding interface acting on the server system. This pattern is used when
- is generally different from interprocess communication.
- Asinterface (Binder) about stubs, you can return stubs or stub.proxy ( if the client and server are under the same process , then Asinterface () returns the stub object itself, otherwise the Stub.proxy object is returned. we all know that Binder works by client, Binder, server , both the client and the server are communicated through binders (binder is also a Java class in Android). In Java code generated by Aidl, the stub class is inherited from the binder class, which means that the stub instance is the binder instance.
- stub and Stub.proxy differences: (1) if under the same process, then Asinterface () will return to the server stub object itself, because at this time do not need to step into the communication, then directly call the stub object interface can be, The return implementation is the stub implementation of the service side, i.e. there is no cross-process communication at all; (2) If it is not the same process, then Asinterface () The return is a Stub.proxy object that holds a remote binder reference because it now needs to communicate across processes, so if you call Stub.proxy's interface, then they will all be IPC calls that will communicate with the server by calling the Transact method.
About AIDL definitions and implementing flowcharts:
AIDL is an abbreviation for Android Interface definition Language, which is the Android interface definition language. After we have finished writing the Aidl file, the compiler will help us automatically generate a. java file with the same name (in the gen corresponding directory). This. Java class can also be used for cross-process communication on both the server and the client side.
several objects and methods of the proxy class (the client finally communicates with the server through this proxy class):
- About _data and _reply objects : In general, we will store the data of the method's parameters in the _data, and the data of the method's return value into the _reply-without involving the directed tag. If the directed tag is involved, the situation will be slightly more complicated, specifically, see this post: Do you really understand the in,out,inout in Aidl?
- About Parcel : Simply put, Parcel is a container for storing and reading data. We can use it for data transfer between client and server, of course, it can only transmit serializable data. The use of specific Parcel and related principles can be found in this article: the analysis of Parcel in Android and its use
- About the transact () method : This is the core approach for client and server-side communication. After this method is called, the client suspends the current thread, waits for the server to notify and receive the returned _reply data stream after performing the related task. There are two points to note about this method of communication:
- Method The first parameter of the Id:transact () method is a method ID, which is the client and the service side of the contract to the method of encoding, one by one corresponds to each other. When the Aidl file is converted to a. java file, the system automatically assigns a method ID to each method in the Aidl file.
- The fourth parameter: the fourth parameter of the Transact () method is an int value, its role is to set the IPC mode, for 0 indicates that the data can flow in two directions, that is, the _reply stream can carry the data back, if 1 then the data will only flow in one direction, from the server back _rep The Ly stream will not carry any data.
Note: This parameter for the. java file generated by Aidl is 0.
About the client General workflow:
- 1, generate _data and _reply data streams, and deposit data to the client in _data.
- 2, pass them to the server through the Transact () method and request the service side to invoke the specified method.
- 3, receive the _reply data stream, and extract the data from the service side.
General workflow on the service side:
- 1, get the data sent by the client, and perform the corresponding operation according to the method ID.
- 2, the data will be sent out to call the local write the corresponding method.
- 3. Write the data that needs to be returned to the reply stream and back to the client.
For a simple example of aidl in Android, take the following demo:
53400288
(Note: In Android studio, the Aidl interface files on the client and server are not necessarily the same, it is best to configure the path in Gradle!) ）
Other reference Links:
49970217
51173668
52029091 (Detailed principle to analyze, good)
The implementation principle of inter-process communication-aidl of Android
