Android Process Communication, ibinder Model

Inter-process transmission of class objects, more efficient is the use of parcel; then combined with ibinder to form a communication model, more timely and efficient than broadcast, and more secure.
What is ibinder? First, you must understand that android remote calls (cross-process calls) are implemented through ibinder. The following is a translation of Android development documentation.
Ibinder is the basic interface of remote objects and is the core part of the lightweight Remote Call mechanism designed for high performance. But it is not only used for remote calls, but also for In-process calls. This interface defines the protocol for interaction with remote objects. Instead of directly implementing this interface, it should be derived from the binder.
The main API of ibinder is transact (), and another method corresponding to it is binder. ontransact (). The first method enables you to send a call to the remote ibinder object, and the second method enables your remote object to respond to the received call. Ibinder APIs are all synchronously executed. For example, TransAct () will not be returned until the peer's binder. ontransact () method is called. This is undoubtedly the case when a call occurs within a process, and the same effect is achieved with the help of IPC between processes.
The data sent through transact () Is parcel, and parcel is a general buffer. Besides data, it also contains metadata that describes its content. Metadata is used to manage references to ibinder objects so that these references can be saved when the buffer zone is moved from one process to another. This ensures that when an ibinder is written to parcel and sent to another process, if another process sends the reference of the same ibinder back to the original process, then the original process will be able to receive the reference of the issued ibinder. This mechanism enables ibinder and binder to manage processes as they do with the unique identifier.
The system maintains a thread pool for each process to store interaction threads. These interactive threads are used to send all IPC calls from other processes. For example, when an IPC is sent from process a to process B, the calling thread (which should not be in the thread pool) in process a is blocked in the transact. One thread in the interaction thread pool of process B receives this call. It calls binder. ontransact () and then uses a parcel to return the result. Then the waiting thread in process a can continue execution after receiving the returned parcel. In fact, another process looks like a thread of the current process, but it is not created by the current process.
The Binder Mechanism also supports recursive calls between processes. For example, process a executes its own ibinder Statement () to call the binder of process B, while process B is in its binder. in ontransact (), process a initiates a call to process a, while waiting for the response of the call, process a also uses the binder. ontransact () responds to the transact () of process B (). In short, the result of the binder is that we feel that cross-process calls are no different from intra-process calls.
When operating remote objects, you often need to check whether they are valid. There are three ways to use them:
The 1 transact () method will throw a RemoteException when the process where ibinder is located does not exist.
2. If the target process does not exist, false is returned when pingbinder () is called.
3. You can use the linktodeath () method to register an ibinder. deathrecipient with ibinder, which is called when the process represented by ibinder exits.

To implement ibinder to support remote calls, a class should be derived from the binder class. Binder implements the ibinder interface. However, you generally do not need to implement this type directly. Instead, it is generated by the tool in the development kit based on your needs. This tool is called Aidi. You can use the Aidi language to define the remote object method, and then use the Aidi tool to generate the derived class of the binder. However, however, you can also directly derive from the binder class to implement custom RPC calls, or simply instantiate an original binder object and use it directly as a token shared between processes.