References:

Why did Android adopt Binder as an IPC mechanism?

The principle of article

The serial number Title of article An overview of the
0 Binder series – Introduction Summary of Binder
1 Binder Series 3 – Start Service Manager The ServiceManager daemon registers and queries services
2 Binder Series 4 – Obtain Service Manager Gets the proxy object BpServiceManager
3 Binder series 5 – addService Registering for Media Services
4 Binder Series 6 — getService Get the Media agent, and DeathRecipient
5 Binder series 7 – Framework layer analysis Framework layer services registration and query, Binder registration
6 Understand the management of Binder thread pools Binder’s startThreadPool procedure
7 Thoroughly understand the Android Binder communication architecture StartService as the main line
8 Binder Series 10 – Summary A brief summary of Binder
9 Access control for Binder IPC clearCallingIdentity/restoreCallingIdentity
10 LinkToDeath with Binder death notification Binder death notification mechanism

Drive the article

1 Initial exploration of Binder Driver series 1 Drive open/ Mmap/IOCtl, and binder structures
2 Introduction to Binder Driver series 2 – Binder Driver Binder Communication protocol memory mechanism

Use paper

1 Binder 8 — How to use Binder Custom Binder services for Native layer and Framwrok layer
2 Binder series 9 — How to use AIDL Custom Binder services for App layer

An overview,

In the Android system, each application is composed of one or more of the four Swordsmen of Android: Activity, Service, Broadcast and ContentProvider. The communication between the four swordsmen involved in multi-process is all dependent on the Binder IPC mechanism. For example, when an Activity in process A communicates with A Service in process B, it relies on A Binder IPC. Binder mechanisms are widely used as IPC (interprocess communication) solutions throughout the Android system architecture. Of course, some other IPC methods also exist, such as Zygote communication using sockets.

Binder as an IPC mechanism provided by Android system, Binder is the most important component of Android system and the most difficult knowledge point to understand. All users should be familiar with Binder, whether engaged in system development or application development. The best way to learn more about Binder mechanisms is to Read The Source Code, to paraphrase Linus Torvalds, The father of Linux: Read The Fucking Source Code.

Second, the Binder

2.1 Principles of IPC Mechanism

Look at the IPC mechanism from a process perspective

Each Android process can only run in its own virtual address space. It corresponds to a 4GB virtual address space, in which 3GB is the user space and 1GB is the kernel space. Of course, the size of the kernel space can be adjusted by parameter configuration. For user space, different processes are not shareable with each other, while kernel space is shareable. The Client process communicates with the Server process precisely by using the shared kernel memory space between the processes to complete the underlying communication work. The Client and Server processes often use iocTL and other methods to interact with the driver of the kernel space.

2.2 principle of Binder

Binder communication uses the C/S architecture and consists of Client, Server, ServiceManager, and Binder drivers from a component perspective. The ServiceManager manages various services in the system. The architecture diagram is as follows:

It can be seen that both the process of registering services and obtaining services need ServiceManager. It should be noted that the ServiceManager here refers to the Native layer ServiceManager (C++). Does not refer to the Framework layer ServiceManager(Java). The ServiceManager is the daemon of the Binder interprocess communication mechanism. To master the Binder, you need to understand how the system starts the ServiceManager for the first time. After the Service Manager is started, the Client and Server must obtain the Service Manager interface before communicating with each other.

Figure in the mutual communication between a Client/Server/ServiceManage are based on the mechanism of Binder. Since communication is based on Binder mechanism and also C/S architecture, the three steps in the figure have corresponding Client side and Server side.

  1. Register Service (addService) : The Server process registers Service with the ServiceManager first. This process: The Server is the client, and the ServiceManager is the Server.

  2. GetService: The Client process obtains a Service from the ServiceManager before using a Service. The Client is the Client, and the ServiceManager is the server.

  3. Using a Service: The Client establishes a path to communicate with the Server process of the Service based on the obtained Service information, and then directly interacts with the Service. The process: Client is the client and server is the server.

The interactions among Client,Server and Service Manager in the figure are all dotted lines, because they do not directly interact with each other, but with Binder drivers to realize IPC communication. Binder drivers are located in kernel space, and Client,Server, and Service Manager are located in user space. Binder drivers and Service Manager can be regarded as the infrastructure of Android platform, while Client and Server are the application layer of Android. Developers only need to customize the implementation of Client and Server. The basic Android platform architecture enables direct IPC communication.