Android inter-process communication (IPC) mechanism binder brief introduction and learning plan

In the Android system, every application is composed of activities and services. Generally, services run in independent processes, and activities may run in the same process, it may also run in different processes. So how does the activity or service of different processes communicate? This is the communication mechanism between binder processes described in this article.

We know that the Android system is based on the Linux kernel, and the Linux kernel inherits and is compatible with a variety of UNIX system inter-process communication (IPC) mechanisms. There are traditional pipelines (PIPE), signals (signal), and traces. These three communication methods can only be used between parent and child processes, or between sibling processes; later, the command pipeline (Named Pipe) was added, so that inter-process communication is no longer limited to between parent and child processes or between brother processes. In order to better support transaction processing in commercial applications, in at&t's UNIX System V, three inter-process communication mechanisms, called "System v ipc", are added: Message Queue (Message) and shared memory (share memory) and semaphores (semaphore). Later, bsd unix expanded the "System v ipc" mechanism and provided an inter-process communication mechanism called socket. If you want to learn more about these inter-process communication mechanisms, we recommend that you refer to the Linux kernel source code Scenario Analysis in the android learning startup article.

However, the android system does not use the aforementioned inter-process communication mechanisms, but uses the Binder Mechanism. Is it because of the poor hardware performance and low memory of mobile devices? Unknown. In fact, the binder is not a new set of inter-process communication mechanism proposed by Android. It is implemented based on openbinder. Openbinder was first developed by be inc., followed by Palm Inc. Dianne hackborn, author of openbinder, is working on Google and is responsible for Android platform development.

As mentioned above, binder is a communication mechanism between processes. It is similar to the distributed component architecture of COM and CORBA. In other words, it provides the Remote Procedure Call (RPC) function. In terms of English text, the binder has the meaning of binder, so what does it bond together? In the Binder Mechanism of the Android system, a system component is composed of client, server, Service Manager, and binder drivers. The client, server, and service manager run in the user space, the kernel space of the binder driver program. Binder is a binder that binds these four components together. The core component is the binder driver, and service manager provides the auxiliary management function, the client and server communicate with the client-server on the infrastructure provided by the binder driver and service manager. The Service Manager and binder drivers have been implemented on the Android platform. Developers only need to implement their own client and server components according to the specifications. It is easy to say and difficult to start. For Beginners, The Binder Mechanism of the Android system is the most difficult to understand, and the binder mechanism is from the perspective of system development and application development, it is the most important component of the Android system. Therefore, it is necessary to have a deep understanding of the working method of the binder. To learn more about the working method of the binder, the best way is to read the Source Code related to the binder. Linux's originator Linus Torvalds once said a famous saying rtfsc: Read the fucking source code.

Although reading the source code of the binder is the best way to learn the Binder Mechanism, you must never be unprepared, because the source code of the binder is boring and hard to understand, it would be better to add some theoretical knowledge. There are still a lot of information about the Binder Mechanism on the Internet, so I don't want to write it in detail here. I strongly recommend the following two articles:

Android Binder Mechanism

Android Binder Design and Implementation-design

Android introduces the relationship between the client, server, and service manager of the three binder components in the user space, the document on Android Binder Design and Implementation describes in detail the data structure and design principles of the binder driver in the kernel space. Thank you very much for bringing us such good binder learning materials. To sum up, the relationships between the client, server, Service Manager, and binder drivers in the Binder Mechanism of the Android system are shown in:

1. Client, server, and service manager are implemented in the user space. The binder driver is implemented in the kernel space.

2. The binder driver and service manager have been implemented on the Android platform. Developers only need to implement their own client and server in the user space.

3. The binder Driver provides the device file/dev/binder to interact with the user space. The client, server, and service manager communicate with the binder driver through the open and IOCTL file operation functions.

4. inter-process communication between client and server is indirectly implemented through the binder driver

5. Service Manager is a daemon for managing the server and providing the client with the ability to query the server interface.

At this point, I have a perceptual knowledge of the binder mechanism, but I still feel that the entire IPC communication process cannot be well run from top to bottom. Therefore, we plan to analyze the binder source code in the following four scenarios to further understand the Binder Mechanism:

1. How does Service Manager become a daemon? That is, how service manager notifies the binder driver that it is the context manager of the binder mechanism.

2. How does the server and client obtain the Service Manager interface? That is, how the defaservicservicemanager interface is implemented.

3. How does the Server start its own service? How does Service Manager provide services to the server during server startup? That is, how the iservicemanager: addservice interface is implemented.

4. How does Service Manager provide services for the client? That is, how the iservicemanager: getservice interface is implemented.

In the next four articles, the binder source code will be analyzed based on the four scenarios, and the binder source code from the user space to the kernel space will be involved. Why is there no scenario where the client and server communicate with each other? This is because service manager acts as a daemon and also acts as a server. Therefore, as long as we can understand the third and fourth scenarios, we understand how the client and server communicate with each other through the binder driver in the binder mechanism.

In order to easily describe the principles and implementation of the binder mechanism for inter-process communication in the Android system, we will introduce the implementation of the Binder Mechanism in the following four articles based on the C/C ++ language, however, when we develop applications in the Android system, they are all based on the Java language. Therefore, in the last article, describes in detail the Java interface Implementation of the binder mechanism for inter-process communication in the Android system at the application framework layer:

5. Java Interface source code analysis of the binder mechanism for inter-process communication in the Android system at the application framework layer.

Lao Luo's Sina Weibo: http://weibo.com/shengyangluo. welcome to the attention!