A brief understanding of the binder mechanism in Android

We know that in Android, every application runs in a separate process, which also guarantees that when one of the programs has an exception, it does not affect the normal functioning of another application. In many cases, we work with the service of various systems, and it is clear that the program we write is definitely not the same process as the system service, but how do they communicate? Binder is one of the ways in which an inter-process communication (IPC) is implemented in Android.

Understanding Binder

What does 1.binder do for you? Used to implement communication between different processes.

What is 2.Binder? Binder belongs to a driver, working at the Linux level, running in the kernel state, and its operation is done based on a memory. So the use of binders in the programs we develop is done through the call of the system.

How does the 3.binder implement process communication? Let's understand the process of implementing interprocess communication (IPC) through the binder architecture.

Binder architecture consists of three parts: server side, Binder driver, and client.

Where the client is in user space, and the binder driver is in kernel space.

Server-side. A binder server side is an object of binder class. When a binder object is created, a thread is opened inside to receive the information sent by the binder driver, and the associated service code is executed when the message is received. 、

Binder Drive. When a binder object is successfully created by the server, the binder driver creates a Mremote object that is also the binder class. Customers can use this Mremote object to access remote services.

Client. To access a binder's remote service, the client must obtain the Mremote reference for the binder object of the remote service in the binder driver layer. Once a reference to the Mremote object is obtained, the service of the corresponding binder object can be invoked.

Here, we can see that the client is using the binder driver to invoke the service-side related services. First, a Binder object is created on the server, then a Binder object is created in the binder drive, and the client invokes the service-side service by acquiring a reference to the binder object in the binder driver. In the binder mechanism, it is the binder that drives the components of different processes together to bind (glue) to achieve communication.

Why does Android use binder for interprocess communication?

First, reliability. On mobile devices, Client-server-based communication is often used to achieve internal communication between the Internet and devices. Currently the Linux support IPC includes traditional pipelines, System V IPC, i.e. Message Queuing/shared memory/semaphore, and only the socket supports the Client-server communication mode. The Android system provides developers with a rich interface for interprocess communication, media playback, sensors, and wireless transmission. These features are managed by different servers. Development is only concerned with building the client of your application and the server's communication to use this service. There is no doubt that the complexity of the system is increased by erecting a set of protocols at the bottom to achieve client-server communication. It is difficult to guarantee the reliability of this complex environment on mobile phones with limited resources.

Second, transmission performance. Sockets are mainly used for inter-process communication across the network and for inter-process communication on the native, but with low transmission efficiency and high overhead. Message Queuing and pipelines use storage-forwarding, where the data is copied from the sender's buffer to a buffer in the kernel, and then copied from the kernel buffer to the receiver buffer, with a process of at least two copies. Although shared memory does not need to be copied, control is complex. Compare the number of copies of data in various IPC ways. Shared memory: 0 times. Binder:1 times. socket/Pipe/Message queue: 2 times.

Third, security. Android is an open platform, so it's important to ensure that your application is secure. Android assigns Uid/pid to each of the installed apps, where the UID of the process can be used to authenticate process identities. Traditional only by the user in the data package to fill in uid/pid, so unreliable, easy to use by malicious programs. And we asked the kernel to add a reliable UID.

Therefore, for reliability, transport, security. Android has set up a new way of communicating between processes.

Here, we have some brief understanding of binder.

We will continue to discuss the bind mechanism in depth later:

How is the 1.Binder service-side designed?

How is the 2.Binder client designed?

How are 3.Binder objects obtained?