Android source code analysis-Binder Mechanism

First, let's take a look at the sequence chart for running the android binder system:

 

(This figure is from Google Search)

From the time sequence diagram, the entire android binder system is still somewhat complicated, but careful analysis may find that the operating mechanism of the entire android binder seems to be similar to a common system architecture. Yes, that is the RPC-based C/S architecture we often see.

To facilitate the comparison and interpretation of Android binder principles, we first analyze from a familiar scenario: For an RPC-based (remote process call) C/S system, we abstract and simplify it, basically by "server", "client", "service_manager", "RPC-API ", "Service-Info" (representing the information of each server that provides the service.

On the other hand, for a large number of RPC-based network-servers, we found that a considerable number of functions and components remain unchanged independently of specific service functions. For example, "multi-channel event distribution", "concurrency control", "memory management", and "session management "...... Therefore, to avoid "reinvent the wheel" again and again, many network-server frameworks were born. For example, Ace, boost. ASIO, libevent ...... Based on these frameworks, we only need to implement components specific to the specific service processing logic, and then assemble them with the Framework.

If you are familiar with network-server development or have some knowledge about it, you should be able to understand the basic framework of the entire RPC-based network server based on the above description.

After talking about this, what does it have to do with the binder? Let's first look at a picture.

 

 

"------" In the figure indicates that the components at both ends of the dotted line are equivalent. After reading this figure, we should have a clear understanding of the Android-binder component, which is not easy to understand :)

As the core basic component of the Android system, binder is used to simplify the development of underlying services in Android and data communication between services. Because these services run on the same Android machine, and the relationship between these services is similar to a C/S architecture, what is needed at this time is not the RPC framework, but the IPC framework. The binder framework in Android is the IPC framework that provides this function.

After reading this figure, some people may think that the client side of RPC is located on the specific server side based on IP: port. In the binder framework, what mechanism is the client based on to locate the server? The answer is "handler ". The process is as follows:

1) For service_manager, its handler is fixed and the value is 0.

2) When other services are registered with service_manager, service_manager assigns a unique handler value to the service and establishes a one-to-one ing relationship of "SERVICE_NAME handler.

3) when a client needs to access a specific service, it will pass the SERVICE_NAME of the Service to service_manager, then service_manager finds the corresponding handler in the managed service based on this SERVICE_NAME.

4) then, the client and server can use the "handler" as the identifier for communication and communicate based on the android binder settings. This is similar to when the client obtains the IP address of the server: after the port, it communicates with the server based on socket.

 

SubsequentArticleAndroid binder will be further analyzed. Please correct the error.

From http://www.cnblogs.com/xwroyal/archive/2012/01/15/2322733.html