Android player path: java-layer Binder and Android binder

Android player path: java-layer Binder and Android binder

Many people refer to the proxy mode when talking about Binder. There are a lot of people, and there is little understanding of the essence. This article analyzes the design objectives, design ideas, and design defects of the java-layer BInder from the perspective of design, so as to control it.

For [bond], from the perspective of communication, it is only a communication method, and there is no difference with socket. Client transact, server onTransact. However, for [bond] itself, if the client and server are in a process, it is unnecessary to switch the data through the underlying driver. Based on this theory, during the design, if the client and server are in a process, the function is called directly without passing the driver. The caller only needs to obtain an interface for transact. Do not want to know the specific communication details. That is to say, it does not matter whether it is transmitted through the [bond] driver, or directly transmitted through function calls in the same process. The caller is really unwilling to care, and the caller is not willing to care about it, so the caller has to care about it, or who else will write the code. Therefore, bond must handle the two situations:

1. In the same process. This corresponds to the Binder.

2. Not in the same process. This corresponds to BInderProxy.

For callers, both of these functions implement the transact function in the IBinder interface. BInderProxy transmits data to the server through the underlying driver, while BInder transfers data directly to onTransact through internal calls.

Note:

Let's talk about google. The name is inexplicable. When I see an IBinder, I have no idea except bond. In my opinion, in design, transact should correspond to an ISenderBinder, while onTransact corresponds to an IReceiverBinder. The Binder implements the ISenderBinder and IReceiverBinder interfaces. This logic is clear enough. As long as the client sees the ISenderBinder, it will feel more cordial, and the server will feel like it is doing a good job for others as long as it sees the IReceiverBinder. The first thing to do is to open the communication channel, that is, to send the object corresponding to the ISenderBinder to the client. It doesn't matter who serves the server, as long as it is a pair of ISenderBinder, OK. BInderProxy should be called SenderBinder.

 

 

So what does an application need? He needs function calls, rather than transact. If you care about the underlying package and unpackage all day, it will be very big. IActivityManager is the interface required by the user. The previous transact interface is obviously not suitable for users. Adapt disgusting transact functions to IActivityManager. It is easier for users to use. Since it is adaptive, there is an interface conversion. One is asInterface and the other is asBInder. This is a proxy. This is actually an adaptation. AsInterface adapts IBinder to IActivityManager. AsBInder adapts IActivityManager to IBinder.

In google's code, this often refers to something that represents a remote object as a proxy. That's all. As long as it can represent a remote object and execute a function. It is called a proxy. The specific implementation is not concerned. Here, proxy is just a kind of ambition out of the actual code.