Shulou(Shulou.com)06/03 Report--

This article introduces the relevant knowledge of "Android picture and text explains in detail what is the underlying principle of Binder process communication". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

? What is interprocess communication?

Inter-process communication (IPC,Inner Process Comunication) refers to the transmission of information between different processes.

Process is the basic unit of resource allocation and scheduling of the system and the basis of the structure of the operating system; an application has at least one process, and a process contains multiple threads (thread is the smallest unit of CPU scheduling), the process is equivalent to the ViewGroup of the thread, and the thread is equivalent to the View of the process assigned by the operating system.

? What is Binder?

Binder is a way of interprocess communication mechanism (IPC) in Android system, and it is the bridge of these inter-process communication. Like the name "adhesive", it binds the various components of the system together and is the bridge between the various components.

Application layer: is a Java class that initiates communication.

Client: for Binder proxy objects, it is a remote proxy for Binder entity objects.

Server: is a Binder entity object in Server.

Mechanism: it is an inter-process communication mechanism.

Driver: is a virtual physical device driver

For example, the diagram of startActivity:

Binder communication is used here, and you will find that there is also Socker communication, so why should I use Binder instead of Socket.

? The method name characteristics of IPC in Android use scenario Bundle only to realize serialization or some special objects supported by Android are suitable for process interaction files between four major components can not achieve instant communication between processes, and are not suitable for high concurrency scenarios suitable for SharedPreference and IO operations ContentProvider can access more data and support one-to-many high concurrency access Because ContentProvider has automatically done a mechanism about concurrency that is suitable for one-to-many data sharing and requires frequent CRUD operations on data Socket transmits byte streams over the network to support one-to-many real-time communication, but it is more complex to implement. The underlying principle of Messenger for network data sharing is AIDL, but it is encapsulated, but can not handle high concurrency scenarios very well. And the transmitted data can only support Bundle type multi-process, single-thread and thread-safe AIDL. It uses Binder mechanism to support one-to-many high concurrent real-time communication, but needs to deal with scenarios where threads synchronize one-to-many and have remote process communication. Binder advantage starting point: Binder shared memory Socket performance does not need to be copied twice at a time. Based on Candace S architecture, high ease of use, complex control, poor ease of use, low transmission efficiency, high overhead and security, each APP allocates UID, and supports real name and anonymous dependence on upper layer protocols. Access access points are open and insecure, and access points are open and insecure.

Through the above comparison, Android finally chose to build a set of Binder that is easy to use, efficient and safe.

Easy to use: based on Cramp S architecture, high ease of use

Efficient: memory mapping with mmap () requires only one copy

Strong security: each APP assigns UID (process ID number), and supports both real name (system service) and anonymity (self-created service).

You can allow your service to register with ServiceManager and use your real name after registration.

? The traditional IPC principle of Linux

Understanding the concepts and principles related to Linux IPC will help us to understand the principle of Binder communication. Therefore, before introducing the principle of Binder cross-process communication, let's talk about how to realize the traditional inter-process communication in Linux system.

? Basic concept

As can be seen from the above picture:

Process isolation.

Process space division: user space (User Space) / kernel space (Kernel Space).

System call: user mode / kernel state.

? Process isolation

In the operating system, memory between processes is not shared. The SCC process cannot directly access the data of the Service process. Interprocess communication (IPC) is necessary for data exchange between SCC processes and Service processes.

? Process space division

Now the operating system uses virtual memory. The core of the operating system is the kernel, which is independent of ordinary applications and can access protected memory space as well as the permissions of the underlying hardware devices. In order to protect the user process from directly operating the kernel and ensure the security of the kernel, the operating system logically divides the virtual space into user space (User Space) and kernel space (Kernel Space).

Kernel space (Kernel Space): the space in which the kernel of the system runs

User space (User Space): is the space where the user program runs.

All kernel spaces (virtual addresses) are mapped to the same physical memory, which enables memory sharing (all processes are accessible through IPC).

To ensure security, they are isolated. Even if the user program jumps, the kernel is not affected.

? System call

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

Copy_from_user (): copy user space data to kernel space

Copy_to_user (): copies data from kernel space to user space.

User mode: when a process is executing the user's own code, we call it in the user running state (user mode)

Kernel state: when a process executes a system call and falls into kernel code execution, the process is said to be in the kernel running state (kernel state).

System calls are the only way for user space to access kernel space.

? Traditional IPC communication principle

As shown in the picture, this is a copy of Sokcet twice.

Of course, at present, Linux has introduced Binder communication mechanism.

? Binder IPC principle

The above is a bunch of related concepts and principles of IPC under Linux, and then we formally introduce the principle of Binder IPC.

? Binder is designed with hierarchical architecture

Application layer: for applications, by calling startActivity () and then calling AMP.startService, after layers of calls, it is bound to call AMS.startService.

Framework: customer class BinderProxy and service class Binder (Binder communication is based on the Android S architecture, and the infrastructure of the Android system has been designed for Binder in Java).

Native layer: for the Native layer, you can use BpBinder and BBinder directly (and JavaBBinder here, of course), and the communication for the upper layer Framework is also based on this layer.

Kernel: this is Binder Driver. The first three layers run in user space. Memory resources in user space are not shared. Each Android process can only run in the virtual address space owned by its own process, while kernel space can be shared. The core link of real communication is Binder Driver.

? Binder driver

In Android systems, the kernel module that runs in kernel space and is responsible for the communication of various user processes through Binder is called the Binder driver (Binder Dirver).

? Binder IPC memory mapping

Binder IPC is implemented based on memory mapping (mmap), and a complete Binder IPC communication process usually looks like this:

1. The Binder driver creates a data receiving cache in kernel space.

2. Open up a kernel cache in the kernel space

Establish the mapping relationship between kernel cache and data receiving cache in kernel

Mapping relationship between data receiving cache and user space address of receiving process in kernel

3. Sending data completes a communication between processes.

The sender process copies the data to the kernel cache in the kernel by calling copy_from_user ().

Because there is a memory mapping between the kernel cache and the data receiving cache, it is equivalent to sending data to the data receiving cache.

Because there is a memory mapping between the data receiving cache and the user space of the process, it is equivalent to sending the data to the user space of the receiving process.

Memory mapping can reduce the number of data copies and achieve efficient interaction between user space and kernel space. The modifications of the two spaces can be directly reflected in the mapped memory area, so that they can be perceived by each other's space in time. Because of this, memory mapping can provide support for inter-process communication.

Restrictions on passing Binder values:

Original BINDER_VM_SIZE: (1 * 1024 * 1024)-4096 * 2)

Now BINDER_VM_SIZE: (1 * 1024 * 1024)-sysconf (_ SC_PAGE_SIZE) * 2)

Sysconf (_ SC_PAGE_SIZE): this function is used to get the configuration information executed by the system. For example, page size, maximum number of pages, number of cpu, maximum number of open handles, and so on.

This value means that you can pass so many Binder at most, if you exceed it, you will fail.

? Android Binder schematic? Bind schematic diagram

Binder communication adopts Cramp S architecture, which includes Client, Server, ServiceManager and Binder drivers from a component point of view, in which ServiceManager is used to manage various services in the system.

The ServiceManager here refers to the ServiceManager (C++) of the Native layer, not the ServiceManager (Java) reason of the framework layer:

Therefore, the schematic can be represented as follows:

? Bind schematic interaction

Client, Server and ServiceManager belong to the user space of process space and cannot interact with each other (shown by dotted lines in the following figure).

So they all interact with Binder drivers to achieve IPC communication.

Therefore, the schematic can be represented as follows:

? Bind schematic interaction route

So far, the Binder principle is settled. I don't know how much you know, if you have any questions, please contact me and we'll discuss it together. In the next article, we will learn about the specific implementation of Binder in Android.

This is the end of the content of "Android picture and text details what is the underlying principle of Binder process communication". Thank you for your reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.