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

In this article, the editor introduces in detail "how to understand ANDROID's BINDER communication architecture". The content is detailed, the steps are clear, and the details are handled properly. I hope this "how to understand ANDROID's BINDER communication architecture" article can help you solve your doubts.

one。 Introduction 1.1 thoughts on the Binder architecture

Android kernel is based on Linux system, while Linux has many inter-process IPC modes: pipes, message queues, shared memory, sockets, semaphores, signals. Why does Android have to use Binder for interprocess communication?

Before talking about the Binder architecture, let's briefly talk about the familiar five-tier communication architecture of TCP/IP:

Application layer: provide services to users directly

Transport layer: messages (TCP data) or user datagrams (UDP data) are transmitted

Network layer: packets (Packet) are transmitted, such as routers

Data link layer: frames (Frame) are transmitted, such as Ethernet switches

Physical layer: bit is transmitted between neighboring nodes, such as hubs, twisted pair, etc.

This is the classic five-layer TPC/IP protocol architecture. With the idea of hierarchical design, each sub-problem is designed as an independent protocol, and the design / analysis / implementation / testing of this protocol becomes easier:

Layer and layer are independent, for example, the application layer can use the functions provided by the transport layer without knowing its implementation principle.

The design is flexible, and the interfaces are defined between layers. Even if the method in the layer changes, only the interface remains the same, it will have no effect on the system.

The decoupling of the structure allows each layer to use a more suitable technical solution and a more appropriate language.

Easy maintenance, layered debugging and positioning of problems

The Binder architecture is also designed with a hierarchical architecture, and each layer has its own different functions:

Java application layer: for the upper application, by calling AMP.startService, you don't have to care about the bottom layer. After layers of calls, you will eventually call AMS.startService.

Java IPC layer: Binder communication is based on Java framework S architecture. The infrastructure of Android system has been designed for Binder client class BinderProxy and service class Binder of Binder in Java framework layer.

Native IPC layer: for the Native layer, if you need to use Binder directly (such as media related), you can use BpBinder and BBinder directly (and JavaBBinder here, of course), and the communication of the upper layer Java IPC is also based on this level.

Kernel physical layer: 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 the kernel space can be shared. The core link of real communication is Binder Driver.

1.2 Analysis starting point

Binder is widely used in Android system, which is almost the backbone of the whole Android architecture. Binder system is so huge that we need to find a starting point to pierce the needle and thread and get a glimpse of the whole picture of Binder. Then this paper will take startService process analysis as an example to talk about the role of Binder from a new perspective. First, the AMP.startService is called in the initiator process, then the binder driver is used, and finally the system process AMS.startService is called, as shown below:

Both AMP and AMN implement the IActivityManager interface, and AMS inherits from AMN. AMP, as the client of Binder, runs in each app process, and AMN (or AMS) runs in the system process system_server.

1.3The principle of Binder IPC

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. Let's talk about the architecture diagram of the Binder objects involved in the startService process:

It can be seen that both the process of registering services and the process of obtaining services require ServiceManager. It should be noted that the ServiceManager here refers to ServiceManager (C++) in the Native layer, not ServiceManager (Java) in the framework layer. ServiceManager is the butler of the whole Binder communication mechanism and the daemon of Android inter-process communication mechanism Binder. When client and server communicate, they all need to get the ServiceManager interface before they can start the communication service. Of course, if the target information can be cached, you don't need to request ServiceManager every time.

The communication between the Client/Server/ServiceManage in the figure is based on the Binder mechanism. Since the communication is based on the Binder mechanism, then it is also the Cmax S architecture, so the three major steps in the figure all have corresponding client and server.

Registration service: first, AMS registers with ServiceManager. The process: the process in which the AMS resides (system_server) is the client and the ServiceManager is the server.

Get service: before the Client process uses AMS, it must obtain the proxy class AMP of AMS from ServiceManager. The process: the process in which the AMP resides (app process) is the client and the ServiceManager is the server.

Using the service: the app process can interact directly with the process where the AMS is based on the proxy class AMP. The process: the process in which the AMP is located (app process) is the client, and the process in which the AMS is located (system_server) is the server.

The interactions between the Client,Server,Service Manager in the figure are represented by dotted lines, because they do not interact directly with each other, but through interaction with Binder Driver, thus realizing the IPC communication mode. The Binder driver is located in kernel space and Client,Server,Service Manager is located in user space. Binder driver and Service Manager can be regarded as the infrastructure of Android platform, while Client and Server are the application layer of Android.

Each of these three processes is a complete Binder IPC process. From the point of view of source code, we will only introduce the third process to use the service, that is, to expand

Tips: if you only want to understand the general process, and do not intend to detail the source code, then you can skip the communication process source code analysis, just look at the first paragraph and the last paragraph of this article can also understand all the Binder.

two。 Communication process 2.1 AMP.startService

[→ ActivityManagerNative.java:: ActivityManagerProxy]

Main functions:

Gets or creates two Parcel objects, data for sending data and reply for receiving reply data.

Encapsulate all startService-related data into the Parcel object data, where descriptor = "android.app.IActivityManager"

Pass the data through Binder and write the reply message to reply

Read the exception and component object of the reply reply message

2.2 Parcel.obtain

[→ Parcel.java]

SOwnedPool is a 6-sized cache pool that holds parcel objects, so it is designed to save the overhead of creating Parcel objects each time. The purpose of the obtain () method:

First try to query whether there is a cache Parcel object from the cache pool sOwnedPool, and return the object directly if it exists

If no Parcel object is available, create the Parcel object directly.

2.2.1 new Parcel

[→ Parcel.java]

NativeCreate this is the native method, enter the native layer through JNI and call the android_os_Parcel_create () method.

2.2.2 android_os_Parcel_create

[→ android_os_Parcel.cpp]

Create a Parcel object for the C++ layer, which is cast to a long pointer and saved to the mNativePtr object for the Java layer. After creating the Parcel object, use the Parcel object to write the data. Next, take writeString as an example.

2.2.3 Parcel.recycle

Put Parcel objects that are no longer in use into the cache pool, which can be recycled and reused. When the cache pool is full, it will no longer join the cache pool. There are two Parcel thread pools, the mOwnsNativeParcelObject variable, to determine:

MOwnsNativeParcelObject=true, that is, the object obtained by calling the obtain () method without parameters will be put into the sOwnedPool object pool when it is reclaimed.

MOwnsNativeParcelObject=false, that is, the object obtained by calling the obtain (long) method with nativePtr parameter, which will be put into the sHolderPool object pool when it is reclaimed

2.3 writeString

[→ Parcel.java]

2.3.1 nativeWriteString

[→ android_os_Parcel.cpp]

2.3.2 writeString16

[→ Parcel.cpp]

Tips: except for writeString (), a large number of native methods in Parcel.java call the corresponding methods of android_os_Parcel.cpp, which then call the corresponding methods of Parcel.cpp.

Call process: Parcel.java-> android_os_Parcel.cpp-> Parcel.cpp.

2.4 what on earth is mRemote

The birth of mRemote, first talk about the creation of ActivityManagerProxy object (referred to as AMP), AMP is obtained through ActivityManagerNative.getDefault ().

2.4.1 AMN.getDefault

[→ ActivityManagerNative.java]

The data type of gDefault is Singleton, which is a singleton pattern. Let's take a look at the process of Singleto.get ().

2.4.2 gDefault.get

It needs to be created when it is called for the first time, and persisted to the mInstance object after creation, and then can be used directly.

2.4.3 gDefault.create

The article Binder series 7-framework layer analysis shows that ServiceManager.getService ("activity") returns the proxy object BinderProxy object pointing to the target service AMS, from which the process of the target service AMS can be found.

2.4.4 AMN.asInterface

[→ ActivityManagerNative.java]

At this point, obj is the BinderProxy object, which records the handle of the binder thread of the AMS service in the remote process system_server.

2.4.5 queryLocalInterface

[Binder.java]

In the process of Binder IPC, the call to the same process will be the local Binder object returned by the asInterface () method, and the call to different processes will be the remote proxy object BinderProxy.

2.4.6 create AMP

[→ ActivityManagerNative.java:: AMP]

MRemote is the BinderProxy object that points to the AMS service.

2.5 mRemote.transact

[→ Binder.java:: BinderProxy]

Code=START_SERVICE_TRANSACTION and data in the mRemote.transact () method store six items of information: descriptor,caller, intent,resolvedType, callingPackage, and userId.

TransactNative is the native method, and the android_os_BinderProxy_transact method is called through jni.

2.6 android_os_BinderProxy_transact

[→ android_util_Binder.cpp]

What is saved in gBinderProxyOffsets.mObject is the BpBinder object, which is when Zygote calls the AndroidRuntime::startReg method to complete the registration of the jni method.

The register_android_os_Binder () process has an initial and registered BinderProxy operation to complete the gBinderProxyOffsets assignment process. Then enter the method.

2.7 BpBinder.transact

[→ BpBinder.cpp]

IPCThreadState::self () uses singleton mode, which ensures that there is only one instance object per thread.

2.8 IPC.transact

[→ IPCThreadState.cpp]

The main process of transact:

Execute writeTransactionData () first to write data to mOut of Parcel data type, while mIn has no data yet

The waitForResponse () method is then executed in a loop until a reply message is received. Call talkWithDriver () to interact with the driver, receive a reply message, it will be written to mIn, then according to the different response received, the corresponding operation is performed.

Call waitForResponse here based on whether there is a flag that sets the TF_ONE_WAY:

When oneway is set, waitForResponse (NULL, NULL) is called

When oneway is not set, waitForResponse (reply) or waitForResponse (& fakeReply) is called

2.9 IPC.writeTransactionData

[→ IPCThreadState.cpp]

Write data to mOut

After reading this, the article "how to understand ANDROID's BINDER communication architecture" has been introduced. If you want to master the knowledge points of this article, you still need to practice and use it yourself. If you want to know more about related articles, welcome to follow the industry information channel.

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.