1. What is a Binder

Binder is cross-process communication in Android. Binder can also be understood from different angles as follows:

1. From the perspective of interprocess communication, Binder is an interprocess communication mechanism; 2. From the perspective of Server processes, Binder refers to the Binder entity objects in Server. 3. From the perspective of Client process, Binder refers to a remote proxy of Binder objects, which is a Binder entity object. 4. The Binder driver automatically converts the proxy object to the local object for this cross-process object.

2. The Binder

Linux provides IPC mechanisms such as pipes, message queues, shared memory, and sockets.

  1. Pipes/message queues: Information copied twice, extra CPU consumption; Not suitable for frequent or informative communication;

  2. Shared memory: without replication, the shared buffer is directly attached to the process virtual address space, which is fast. However, the synchronization problem between processes cannot be realized by the operating system and must be solved by each process using the synchronization tool.

  3. Socket: as a more common interface, it has low transmission efficiency (involving I/O read and write) and is mainly used for communication between disconnected machines or across networks.

  4. Semaphore: Often used as a locking mechanism to prevent other processes from accessing a shared resource while one process is accessing it. Therefore, it is mainly used as a means of synchronization between processes and between different threads within the same process.

  5. Signal: not suitable for information exchange, more suitable for process interrupt control, such as illegal memory access, kill a process and so on;

2.1 performance:

Binder data copy only needs one time, while pipes, message queues and sockets all need two times. Sharing does not need memory copy. Binders are second only to shared memory in terms of performance.

2.2 Stability:

Binder is based on C/S architecture. If the Client has any requirements, it is directly sent to the Server for completion. The structure is clear, the Server is relatively independent from the Client, and the stability is good.

However, the implementation of shared memory is complex, and there is no difference between client and server. Therefore, the concurrent synchronization of access to critical resources should be fully considered, otherwise deadlocks and other problems may occur. From this stability perspective, the Binder architecture is superior to shared memory.

2.3 performance:

The receiver of traditional Linux IPC cannot obtain the reliable UID/PID of the process of the other party, so it cannot identify the other party. (for example, the socket can only be filled with UID/PID by the user in the packet).

In the Android system, only the Client is exposed. The Client sends tasks to the Server. The Server determines whether the UID/PID meets the access permission according to the permission control policy.

Note: Binder is designed for systems like Android (primarily for security purposes), not that Linux’s existing IPC mechanisms are bad, but that different IPC mechanisms are selected for scenarios where they are not working, for example:

1. IPC of Zygote process in Android OS adopts Socket mechanism;

Reference: blog.csdn.net/qq_39037047…

2. Signal mechanism used by Kill Process in Android;

Binder is more commonly used for IPC interactions between system_server processes and the upper App layer (mainly for security lines).

3. Communication principle of Binder

3.1 Process space Division

Data in user space cannot be shared between processes, so user space = unshareable space

Data in kernel space can be shared between processes, so kernel space = shareable space

All processes share 1 kernel space

The interaction between in-process user space and kernel space is done through system calls, mainly through functions:

1, copy_from_user () : copies user-space data to kernel space

2, copy_to_user () : copies data from kernel space to user space

3.2 Binder drive

3.3 Memory Mapping

First, in the kernel virtual address space, apply for a block of memory with the same size as the user virtual memory. Then apply for a page size of physical memory, and map the same physical memory to the kernel virtual address space and user virtual memory space respectively, so as to realize the synchronous operation of Buffer in user space and Buffer in kernel space.

3.4 Communication principle of Binder

The Binder driver creates a data receive cache in kernel space.

2. Realize address mapping, map kernel cache and receiver process address space to Binde to create a data receiving cache;

3. The sender process copies the data to the kernel cache through the system call copy_from_user(). Since there is a memory mapping between the kernel cache and the address space of the receiving process, it is equivalent to sending the data to the user space of the receiving process, thus completing an inter-process communication.

Question: why can’t the kernel cache be mapped directly to the receiver address space instead of creating a data receiver cache?

Binder’s data acceptance cache is a block of physical memory that maps the kernel cache to the receiver address space.

4. Binder communication model

4.1 Communication Model

A process registers itself as a ServiceManager with Binder drivers using BINDER_SET_CONTEXT_MGR.

2. The Server uses drivers to register with ServiceManager Binder entities, that is, services that can be provided externally. The driver creates entity nodes in the kernel for the Binder and references to the entity by the ServiceManager, packages the name and the new reference to the ServiceManager, and the ServiceManger fills it in the lookup table.

3. The Client gets a reference to the Binder entity from the ServiceManager by name and with the help of Binder drivers, and communicates with the Server process through this reference.

Note:

The ServiceManager process registers itself as a ServiceManager using BINDER_SET_CONTEXT_MGR and creates a Binder entity

2. The reference to the Binder entity is fixed to 0 in all clients and no other means are required. That is, a Server that wants to register its Binder with a ServiceManager must communicate with the ServiceManager’s Binder through the 0 reference.

4.2 System Services and User-defined Services

1. System services are registered with the ServiceManager. The ServiceManager runs in a separate process.

2. After the process of the user-defined service is started, IBinder is exposed. The client binds the Service in the server process to transfer the IBinder to the client. The client then uses the IBinder to obtain the associated interface and use the customized Service. This process is done without the help of a ServiceManager.

Reference: www.jianshu.com/p/b39ffcbcb…

Android Binder communication code understanding

5.1 Binder Related categories

1. IBinder: IBinder is an interface that represents the ability to communicate across processes. Once this excuse is implemented, the object can be transferred across processes.

2, IInterface: IInterface represents the capabilities of the Server process object (which methods can be provided, in fact, corresponds to the interface defined in AIDL file)

Binder: The Java layer Binder class, which represents Binder native objects.

4. BinderProxy: local proxy for remote Binder objects at clientd end of the table;

Both classes inherit from IBinder and thus have the ability to transfer across processes; In fact, the Binder driver automatically converts the two objects across processes.

5. Stub: AIDL generates a static inner class named Stub. This class inherits Binder, which means it is a Binder native object. It implements the IInterface interface, which means it has the capabilities provided by the Server to the Client. A Stub is an abstract class, and the implementation of a concrete IInterface needs to be implemented by the developer.

5.2 AiDL Usage Flowchart:

6. Reference

  1. Juejin. Cn/post / 684490…
  2. www.jianshu.com/p/4ee3fd07d…
  3. www.jianshu.com/p/4ff66bfb5…
  4. www.jianshu.com/p/b39ffcbcb…
  5. Blog.csdn.net/fdsafwagdag…
  6. www.zhihu.com/question/39…
  7. Gityuan.com/2015/10/31/…
  8. www.jianshu.com/p/adaa1a39a…
  9. Paul. Pub/android – bin…
  10. Juejin. Cn/post / 684490…