Android Binder Mechanism introduction, androidbinder Mechanism

Android Binder Mechanism introduction, androidbinder Mechanism

Some people who have developed Android may have some experience. At the early stage of getting started, their work mainly involves implementing various UI interfaces and implementing the business logic of applications. At this stage, we will gradually become familiar with the View system and learn to implement various interfaces and animation effects. In the future, when we want to learn more about the android system, such as the Startup Process of four android components, AMS and PMS, we will encounter something called a Binder. Based on the author's experience, Binder can be said to be an important basis for a deep understanding of the Android system. As a mechanism for inter-process communication in the android system, binder runs through all aspects. The most commonly used startActivity and startService communicate with the AMS process through the binder Mechanism. This article briefly introduces the architecture of the Binder mechanism. I believe that after reading this article, you will have a general understanding and grasp of the binder mechanism.

 

Note: When I was a beginner at binder, I had read some articles about binder, and I had to worry too early about the details of binder code in some articles. I felt very hard. This article only introduces the binder Mechanism from a macro perspective. I believe that the reader first understands the overall structure of the binder and then goes deep into the details to learn more effectively.

 

What is the Binder and what can it do?

Binder is the inter-process communication mechanism in the android system. In the androd system, different apps run in different processes, and different components of the same app may run in different processes (android: process in the androidManifest file ). When a process wants to provide services for other processes, it needs to provide services through inter-process communication. For example, we have an APP1 with a service component that provides the calculator service. When another APP2 wants to use the service calculator service in APP1, because different apps run in different processes, APP2 cannot directly use the service in APP1. Because the process is crossed, it can only be completed through the inter-process communication mechanism.

Besides, APP1 is in the process of object1, with a method of method1. Another process in which APP2 is located wants to use the method1 method of object1. The binder may help us get a reference to an object1 object in the process where APP2 is located, so that we can call it directly through object1.method1 () Just like calling a local object. With the binder, we can break through the process restrictions and pass the object to other processes, so that other processes can conveniently call the object method.

 

Why Binder?

After understanding what the binder is and what it can do, you may have questions: the android system is based on Linux, and linux itself has many inter-process communication methods to choose from, why does android create a new binder instead of using a built-in inter-process communication method in linux? Is it a duplicate wheel?

In Linux, inter-process communication methods include file, signal, socket, Pipe, and shared memory... Why is Binder used? I have summarized two reasons:

1. historical reasons. The earliest Binder was not designed for the Android system. At the beginning, there was an OpenBinder used in a kernel operating system called Palm Cobaltw. Later, Palm Cobaltw was transplanted to the Linux system, and OpenBinder was also transplanted. When setting up the Android Development Team, Google hired an engineer called Dianne Hackborn, who is the core of OpenBinder. Later, when we were engaged in communication between android processes, we found that the binder was very suitable, So we naturally used the Binder on the android system.

2. Some features and advantages of the binder. When implementing inter-process communication, Binder is suitable for android in terms of security and efficiency. Let's take an impression on this.

 

What are the components of the Binder?

A Binder system consists of four parts: the Binder client, the Binder server, the Binder driver, and the Service Registration query module.

Binder Client: Process to use the service

Binder Server: The process of actually providing services

Binder driver: The client first obtains an object reference in a server process through the Binder. Through this reference, the client directly calls the object method to obtain the result. When this reference object executes a method, it first sends the request for method calling to the binder driver, and then the binder driver sends the request to the server process. After the server process receives the request, call the "real" object on the server side to execute the called method. After the result is obtained, the result is sent to the binder driver, and the binder driver sends the result to our client. Finally, the return value is returned when a client process is called. The Binder driver is equivalent to the role of a transit person. With the help of this forwarder, we can call objects in other processes.

Service Registration query module: When we call objects in other processes, we must first obtain this object. This object actually represents what kind of service another process can provide to us (another point is: which methods of the object can be called by the client process ). First, the server process should register in a certain place and tell the system that I have an object that can be published to other processes to provide services. When the client process needs this service, it will go to the registration location and query it to find this object.

 

How does the Binder work?

The following describes the working mechanism of the binder from the perspective of the client process.

As a Client process, you only want to use the services provided by the server process. However, due to the isolation of the process, the ProcessA of the Client cannot read or write the content in the ProcessB of the Service, but the system kernel can, the Binder driver is running in the kernel state. The Binder driver can help us transfer requests: With the Binder driver, the Client and Service must deal with the Binder driver separately, to help the Client and Service end block the low work of dealing with the Binder driver, we can design a proxy for the Client and Service respectively so that they can only deal with the proxy, put the tasks dealing with the Binder driver in the proxy: The reader may ask, if you want to implement the Client and Service on your own, through the above method, although two proxies are logically independent (client Proxy and server Proxy Stub), are these two proxies not implemented by themselves? If you still want to implement it on your own, what is the practical significance? Android SDK provides an AIDL tool. You only need to create an AIDL file and define interface methods in it like creating a common interface (slightly different. After the definition, androidSDK automatically generates a java file for US based on the Interface Definition in aidl, which includes the client Proxy and server Proxy Stub, it is nice to have automatically generated code for communication with the Binder driver. In the above image, the client Proxy is called Proxy, and the server Proxy is called Stub, because in the Proxy automatically generated by aidl, the class names of the two proxies are Proxy and Stub. The actual work we are doing is only the real service function logic. Let's take a closer look. For the client, the ideal state is that the client does not need to know whether the called object is a local object or an object in the server process. According to the above picture, the client obviously knows that it is calling a remote object, so it is called through a Proxy. During the development of android applications, XXXManager (ActivityManager, PackageManager, WifiManager, PowerManager, and so on) provided by some systems will be used, it helps the Client block the implementation details of the Binder. With these managers, the Client first obtains a Manager object through getServiceManager (xxx), and then directly calls the encapsulated service method in the manager. In this way, the manager actually communicates with the xxxService running in another process through the Client proxy through the binder driver, but you do not need to know it for the Client. For example, for some system services, such as ActivityManager and PackagerManager, you can filter and control the service APIs provided by the Real Server objects without providing Binder details for the Client screen, only a subset of service APIs can be exposed for the Client. Last question: the premise is that the Client obtains a Proxy or Manager before it completes inter-process communication. So how does the Client obtain the Manager or Proxy? First, take some system services as an example: As mentioned above, one of the four components of the Binder mechanism is the "Service Registration query module", corresponding to the Context Manager, the running process in Android is servicemanager. Among all service processes, servicemanager is the first to start. The reason is not hard to understand. If other service processes are started before servicemanager, where can they be registered? As shown in, if the Service process ProcessB starts after the servicemanager process starts, ProcessB needs to register with servicemanager. The "register" action is essentially cross-process communication, from ProcessB to servicemanager. At this time, Service becomes the client for cross-process communication and ContextManager becomes the server. For communications between the client and the server, a Proxy or Manager is required as described above. Where can I obtain this Proxy or Manager? The problem seems to be a loop deadlock? Because of the special position of ContextManager, the reader can understand that the system has some special treatment for it, and the Service can directly obtain the Proxy or Manager from a globally fixed place, instead of querying Proxy/Manager like a Client. The client proxy is obtained. The specific registration communication process is no longer repeated as described above. So far, the Service is successfully registered to ContextManager. When the Client initializes the Manager, the manager obtains the ContextManager Proxy from a fixed location, and queries the ContextManager through the proxy, obtain a "proxy object that provides the service ". With this object, the Client can use the Service through the manager. How does the Client obtain the Proxy object when calling the logic and implementing the Client and Service on its own? First, let's talk about the implementation method: Generally, we will create a Service in the App through the Service component method. Other apps connect to the Service through BindService. The Proxy object can be obtained through the onServiceConnected callback. Specific implementation can refer to: http://blog.csdn.net/singwhatiwanna/article/details/17041691 Summary

This article briefly introduces the logic of the Binder cross-process communication mechanism, hoping to help beginners of Binder quickly get started and submit learning efficiency. The images and explanations used in this article come from this document:

Bytes. If any errors occur in some areas, please contact us.

Another article on getting started with binder: http://weishu.me/2016/01/12/binder-index-for-newer/