Android core analysis-IPC framework analysis Binder, Service, Service manager

Source: Internet
Author: User
Tags mremote
IPC framework analysis Binder, Service, Service manager

First, I will look at the Binder, Service, and Service Manager from a macro perspective and describe their respective concepts. In the concept space of Linux, the Android design Activity is hosted in different processes, and services are hosted in different processes. The data exchanged between services between different processes belongs to IPC. The Binder is a lightweight IPC framework designed for Activity communication.

In code analysis, I found that in Android, the Binder is understood as the implementation of inter-process communication, which is a little narrow. Instead, we should understand the concept of Binder and Service at the height of Public Object Request proxy, in this way, we will see different patterns. From this perspective, we can understand the design intent, so that we will be surprised by some genius ideas in Android. From the concept space outside Android, we can't see the concept of process, but Activity, Service, AIDL, INTENT. Generally, in our deep-rooted ideas as a designer, these are the following C/S architecture. The client and server directly exchange data through the Binder and open the Binder to write data, you can use the Binder to read data and complete the communication.

 

Note that in the concept of Android, Binder is a very low-level concept. The above layer does not see the Binder at all. Instead, the Activity and the object of a Service are directly called by method to obtain the Service.

 

This is an external feature provided by Android: In Android, to complete an operation, you need to request a competent service object to complete the action, you don't need to know how the communication works and where the service is located. Therefore, Andoid's IPC is essentially an Object Request proxy architecture. Android designers use the concept of CORBA to package themselves and implement a miniature lightweight CORBA architecture, this is the intention of Andoid's IPC design. It not only solves communication, but also provides an architecture and design concept, which is the flash of Android. The Android Binder takes into account the convenience of data exchange and only solves the communication between processes on the local machine. Therefore, it is not as complicated as the CORBA, so it is called lightweight.

Therefore, to understand the Android IPC architecture, you need to understand the architecture of CORBA. In essence, the architecture of CORBA can be represented in the following figure:

 

 

On the server side, there is an additional proxy, which is more abstract and can be expressed.

 

 

 

Analysis and the general theoretical architecture of CORBA, I will give the following Android object proxy structure.

 

 

In the structure diagram, we can clearly understand that the Android IPC contains the following concepts:

 

  • ContextObject)

    The device context contains context information about the operation that is not passed as a parameter in the client, environment, or request. The application developer uses the operations defined on the ContextObject interface to create and operate the context.

  • Android Proxy: this refers to the proxy object.
  • Binder communication mechanism provided by the Linux Kernel

 

The external feature space of Android does not need to know where the service is located. As long as the request is completed through the proxy object, we need to explore how Android implements this architecture, first, you must know where the service is to complete the communication between the cloud server on the Client side? First, let's take a look at the data managed by Service Manger. Service Manager provides two important methods: add service and check service, and maintains a Service name and handle for service list record registration.

 

 

 

 

 

 

 

 

Service manager service uses 0 to identify itself. During initialization, BINDER_SET_CONTEXT_MGR ioctl is used by the binder device to convert itself into CONTEXT_MGR. Svclist stores the service name and Handle. This Handle serves as the target address when the Client initiates a request. The service registers its name and Binder ID handle in svclist using the add_service method. The service requestor obtains the Binder ID handle associated with the service in the service list by using the service name in the check_service method, and uses this Handle as the target address of the Request package to initiate a request.

 

 

 

 

 

We understand that the job of Service Manager is to register the function. Now we can go back to IPC and how does the client establish a connection? We first go back to the essence of communication: IPC. Generally speaking, Android designers design a device file called Binder in the Linux kernel to exchange Android data. From the perspective of data streams, Java objects are converted once from the Java VM space to the C ++ space, the function of the C ++ space is used to transmit the converted objects to the service process through the driver/binder device, so as to complete the IPC between processes. This process can be used to represent.

 

 

 

 

 

Here there are several layers of data flow conversion process.

(1) transfer from the JVM space to the C ++ space. JNI uses env to complete the object ing process.

(2) Pass in the kernel binder device from the C ++ space and use the processstate class to complete the work.

(3) The Service reads data from the binder device in the kernel.

Android designers need to use object-oriented technology to design a framework to block this process. These details should not be found in the upper-level conceptual space. How do Android designers do it? Through C ++ space code analysis, we can see the following spatial concept packaging (processstate @ (processstate. cpp)

The processstate class contains communication details. open_binder is used to open the Linux Device DEV/binder and the basic communication framework established through ioctrl. The servicehandle passed by the upper layer is used to determine the service to which the request is sent. Through analysis, I finally understood the name meaning of bnbinder and bpbinder. BN-represents native, while BP represents proxy. Once you understand this level, processstate is easy to understand.

 

Next we will look at the packaging of these concepts in the JVM concept space. To understand the device context, we need to connect the device context in the android VM conceptual space with the total device context in the C ++ space for research.

To use a unified interface on the upper layer, there are two things at the JVM layer. In Android, ServiceManger is introduced to simplify the management framework. All services start with ServiceManager. You only need to obtain a specific Service identifier through Service Manager to build the proxy IBinder. In Android design, the default Handle of Service Manager is 0. If the target Handle of the Request package is set to 0, it is sent to the Service Manager. Android creates a new Service Manager Proxy when making a Service request. Service Manager Proxy uses ContexObject as the Binder and Service Manager Service (server) for communication.

 

We can see that the Android code is generally used to obtain the Service to establish a local proxy as follows:

IXXX mIxxx = IXXXInterface. Stub. asInterface (ServiceManager. getService ("xxx "));

 

For example, use the input method service:

IInputMethodManager mImm =

IInputMethodManager. Stub. asInterface (ServiceManager. getService ("input_method "));

 

The Service proxy acquisition process is divided into the following:

 

(1) Call getcontextobject to obtain the upper and lower objects of a device. Note that the contextobject in the androidjvm concept space only corresponds to the proxy Binder for service manger service communication. This is different from the getcontextobject in the C ++ concept space.

Take a look at the key code

 

Binderinternal. getcontextobject () @ binderinteral. Java

Native JNI: getcontextobject () @ android_util_binder.cpp

Android_util_getconextobject @ android_util_binder.cpp

Processstate: Self ()-> getcotextobject (0) @ processstate. cpp

Getstrongproxyforhandle (0 )@

New bpbinder (0)

 

Note ProcessState: self ()-> getCotextObject (0) @ processtate. cpp: This function creates a ProcessState object in the process space, opens the Binder device dev/binder, and passes the parameter 0. This 0 indicates binding to the Service Manager.

(2) Call ServiceManager. asInterface (ContextObject) to create a proxy ServiceManger.

MRemote = ContextObject (Binder)

In this way, the ServiceManagerProxy communication framework is established.

(3) The client creates a proxy Binder by calling the getService method of ServiceManager.

 

ServiceMangerProxy. remote. transact (GET_SERVICE)

IBinder = ret. ReadStrongBinder ()-this is the proxy Binder of the JVM space.

JNI Navite: android_ OS _Parcel_readStrongBinder () @ android_util_binder.cpp

Parcel-> readStrongBinder () @ pacel. cpp

Unflatten_binder @ pacel. cpp

GetStrongProxyForHandle (flat_handle)

NEW BpBinder (flat_handle)-this is the proxy Binder created in the underlying c ++ space.

The entire creation process can be expressed as follows:

 

 

 

 

In order to establish an IPC, Activity requires two connections: the connection to the Servicemanager Service, and the connection between the proxy object of the specific XXX Service of IXXX and XXXService. These two connections correspond to BpBinder in the c ++ space ProcessState. The last operation on IXXX is the operation on BpBinder. When writing a Service, we write the Service Native part and Service Proxy part in a Package, while both Native and Proxy implement the same Interface: IXXX Interface, but one is on the server, one is at the customer end. The client sends a request to the Service using the remote-> transact method, while the OnTransact method on the server processes the request. Therefore, in Android
The Client space shows this effect: you only need to call the proxy object method to call the remote service. In fact, this call path is long and long.

 

In fact, we haven't studied part of it yet, that is, the object transfer between the same process is different from remote transfer. When a single process is used to deliver a service location and an object, no proxy BpBinder is generated, but only the direct application of the object. The application does not know whether data is transmitted between the same process or between different processes. This is only known by the Binder in the kernel, therefore, the kernel Binder driver can change the data type of the Binder object from BINDER_TYPE_BINDER to BINDER_TYPE_HANDLE or BINDER_TYPE_WEAK_HANDLE for reference transmission.

IPC framework analysis Binder, Service, Service manager

First, I will look at the Binder, Service, and Service Manager from a macro perspective and describe their respective concepts. In the concept space of Linux, the Android design Activity is hosted in different processes, and services are hosted in different processes. The data exchanged between services between different processes belongs to IPC. The Binder is a lightweight IPC framework designed for Activity communication.

In code analysis, I found that in Android, the binder is understood as the implementation of inter-process communication, which is a little narrow. Instead, we should understand the concept of binder and service at the height of Public Object Request proxy, in this way, we will see different patterns. From this perspective, we can understand the design intent, so that we will be surprised by some genius ideas in Android. From the concept space outside Android, we can't see the concept of process, but activity, service, aidl, intent. Generally, in our deep-rooted ideas as a designer, these are the following C/S architecture. The client and server directly exchange data through the binder and open the binder to write data, you can use the binder to read data and complete the communication.

 

Note that in the concept of Android, binder is a very low-level concept. The above layer does not see the binder at all. Instead, the activity and the object of a service are directly called by method to obtain the service.

 

This is an external feature provided by Android: In Android, to complete an operation, you need to request a competent service object to complete the action, you don't need to know how the communication works and where the service is located. Therefore, andoid's IPC is essentially an Object Request proxy architecture. Android designers use the concept of CORBA to package themselves and implement a miniature lightweight CORBA architecture, this is the intention of andoid's IPC design. It not only solves communication, but also provides an architecture and design concept, which is the flash of Android. The android binder takes into account the convenience of data exchange and only solves the communication between processes on the local machine. Therefore, it is not as complicated as the CORBA, so it is called lightweight.

Therefore, to understand the android IPC architecture, you need to understand the architecture of CORBA. In essence, the architecture of CORBA can be represented in the following figure:

 

 

On the server side, there is an additional proxy, which is more abstract and can be expressed.

 

 

 

Analysis and the general theoretical architecture of CORBA, I will give the following Android object proxy structure.

 

 

In the structure diagram, we can clearly understand that the android IPC contains the following concepts:

 

  • ContextObject)

    The device context contains context information about the operation that is not passed as a parameter in the client, environment, or request. The application developer uses the operations defined on the ContextObject interface to create and operate the context.

  • Android Proxy: this refers to the proxy object.
  • Binder communication mechanism provided by the Linux Kernel

 

The external feature space of Android does not need to know where the service is located. As long as the request is completed through the proxy object, we need to explore how Android implements this architecture, first, you must know where the service is to complete the communication between the cloud server on the client side? First, let's take a look at the data managed by service manger. Service Manager provides two important methods: add service and check service, and maintains a service name and handle for service list record registration.

 

 

 

 

 

 

 

 

Service manager service uses 0 to identify itself. During initialization, BINDER_SET_CONTEXT_MGR ioctl is used by the binder device to convert itself into CONTEXT_MGR. Svclist stores the service name and Handle. This Handle serves as the target address when the Client initiates a request. The service registers its name and Binder ID handle in svclist using the add_service method. The service requestor obtains the Binder ID handle associated with the service in the service list by using the service name in the check_service method, and uses this Handle as the target address of the Request package to initiate a request.

 

 

 

 

 

We understand that the job of Service Manager is to register the function. Now we can go back to IPC and how does the client establish a connection? We first go back to the essence of communication: IPC. Generally speaking, Android designers design a device file called Binder in the Linux kernel to exchange Android data. From the perspective of data streams, Java objects are converted once from the Java VM space to the C ++ space, the function of the C ++ space is used to transmit the converted objects to the service process through the driver/binder device, so as to complete the IPC between processes. This process can be used to represent.

 

 

 

 

 

Here there are several layers of data flow conversion process.

(1) transfer from the JVM space to the c ++ space. JNI uses ENV to complete the object ing process.

(2) Pass in the kernel Binder device from the c ++ space and use the ProcessState class to complete the work.

(3) The Service reads data from the Binder device in the kernel.

Android designers need to use object-oriented technology to design a framework to block this process. These details should not be found in the upper-level conceptual space. How do Android designers do it? Through c ++ space code analysis, we can see the following spatial concept packaging (ProcessState @ (ProcessState. cpp)

The ProcessState class contains communication details. open_binder is used to open the Linux Device dev/binder and the basic communication framework established through ioctrl. The servicehandle passed by the upper layer is used to determine the Service to which the request is sent. Through analysis, I finally understood the name meaning of Bnbinder and BpBinder. Bn-represents Native, while Bp represents Proxy. Once you understand this level, ProcessState is easy to understand.

 

Next we will look at the packaging of these concepts in the JVM concept space. To understand the device context, we need to connect the device context in the Android VM conceptual space with the total device context in the C ++ space for research.

To use a unified interface on the upper layer, there are two things at the JVM layer. In Android, ServiceManger is introduced to simplify the management framework. All services start with ServiceManager. You only need to obtain a specific Service identifier through Service Manager to build the proxy IBinder. In Android design, the default Handle of Service Manager is 0. If the target Handle of the Request package is set to 0, it is sent to the Service Manager. Android creates a new Service Manager Proxy when making a Service request. Service Manager Proxy uses ContexObject as the Binder and Service Manager Service (server) for communication.

 

We can see that the android code is generally used to obtain the Service to establish a local proxy as follows:

Ixxx mixxx = ixxxinterface. stub. asinterface (servicemanager. getservice ("XXX "));

 

For example, use the input method service:

Iinputmethodmanager mimm =

Iinputmethodmanager. stub. asinterface (servicemanager. getservice ("input_method "));

 

The Service proxy acquisition process is divided into the following:

 

(1) Call getcontextobject to obtain the upper and lower objects of a device. Note that the contextobject in the androidjvm concept space only corresponds to the proxy Binder for service manger service communication. This is different from the getcontextobject in the C ++ concept space.

Take a look at the key code

 

Binderinternal. getcontextobject () @ binderinteral. Java

Native JNI: getcontextobject () @ android_util_binder.cpp

Android_util_getConextObject @ android_util_Binder.cpp

ProcessState: self ()-> getCotextObject (0) @ processState. cpp

GetStrongProxyForHandle (0 )@

NEW BpBinder (0)

 

Note ProcessState: self ()-> getCotextObject (0) @ processtate. cpp: This function creates a ProcessState object in the process space, opens the Binder device dev/binder, and passes the parameter 0. This 0 indicates binding to the Service Manager.

(2) Call ServiceManager. asInterface (ContextObject) to create a proxy ServiceManger.

MRemote = ContextObject (Binder)

In this way, the ServiceManagerProxy communication framework is established.

(3) The client creates a proxy Binder by calling the getService method of ServiceManager.

 

ServiceMangerProxy. remote. transact (GET_SERVICE)

IBinder = ret. ReadStrongBinder ()-this is the proxy Binder of the JVM space.

JNI Navite: android_ OS _Parcel_readStrongBinder () @ android_util_binder.cpp

Parcel-> readStrongBinder () @ pacel. cpp

Unflatten_binder @ pacel. cpp

Getstrongproxyforhandle (flat_handle)

New bpbinder (flat_handle)-this is the proxy binder created in the underlying C ++ space.

The entire creation process can be expressed as follows:

 

 

 

 

In order to establish an IPC, Activity requires two connections: the connection to the Servicemanager Service, and the connection between the proxy object of the specific XXX Service of IXXX and XXXService. These two connections correspond to BpBinder in the c ++ space ProcessState. The last operation on IXXX is the operation on BpBinder. When writing a Service, we write the Service Native part and Service Proxy part in a Package, while both Native and Proxy implement the same Interface: IXXX Interface, but one is on the server, one is at the customer end. The client sends a request to the Service using the remote-> transact method, while the OnTransact method on the server processes the request. Therefore, in Android
The Client space shows this effect: you only need to call the proxy object method to call the remote service. In fact, this call path is long and long.

 

In fact, we haven't studied part of it yet, that is, the object transfer between the same process is different from remote transfer. When a single process is used to deliver a service location and an object, no proxy BpBinder is generated, but only the direct application of the object. The application does not know whether data is transmitted between the same process or between different processes. This is only known by the Binder in the kernel, therefore, the kernel Binder driver can change the data type of the Binder object from BINDER_TYPE_BINDER to BINDER_TYPE_HANDLE or BINDER_TYPE_WEAK_HANDLE for reference transmission.

Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.