The Java layer Binder of the Android Master Road

A lot of people say that the binder is a proxy model, more than the same, can understand the essence of less. This article analyzes Java Layer Binder design objectives from a design perspective, as well as design ideas, design flaws, and thus harness it.

For "Bond son" understanding, from the communication point of view, is a way of communication, and socket is no different.  Client transact, server-side ontransact. However, from the "bond" itself, if the client and the server in a process, then through the underlying driver to turn the data to the past is superfluous. Based on this theory, when the client and the server are in a process, the direct function is called, and the driver is not passed. For the caller, he just needs to get an interface for Transact. Do not want to know the specifics of the communication. That is to say, do not care whether it is transmitted through the "bond son" drive, or directly in the same process through the function of the call transmission. The caller really does not want to care, the caller does not want to care, then the callee will have to care, or code who will write. So "Bond" itself has to deal with both of these situations:

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

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

For the caller, these two things implement the Transact function in the IBinder interface. The binderproxy transmits data to the server through the underlying driver, and the binder is transferred directly to the ontransact process via an internal call.

Note:

Spit it out here on Google. Naming inexplicably mysterious. Seeing a ibinder, there was no other thought in his mind except for Bond. I think that in the design transact should correspond to a isenderbinder, and ontransact corresponds to a ireceiverbinder. Binder implements the Isenderbinder and Ireceiverbinder interfaces. This logic is clear enough. As long as the client sees Isenderbinder is very cordial, the service side as long as sees Ireceiverbinder feels oneself is doing for others good. The first thing to do is to open the communication channel, that is, isenderbinder this object corresponding to the objects to the client. and the service end with WHO does not matter, as long as is with Isenderbinder is a pair of OK. Binderproxy should be called Senderbinder.

So what does he need for the application? He needs a function call, not transact such things. If you care about these bottom-up packaging solutions all day long, then it's a big head. Iactivitymanager This is the user needs of the interface, the previous Transact interface is obviously inappropriate for the user to use. The disgusting Transact function is adapted to the Iactivitymanager. It's better for users to use them. Since it is adaptable, there is an interface transformation. One is called Asinterface, and one is called Asbinder. On the Internet, this thing is said to be an agent. This is actually a fit. The Asinterface IBinder is adapted to a iactivitymanager. and Asbinder the Iactivitymanager to IBinder.

In Google's code, it's often called a proxy for something that can represent a remote object. That's all. As long as it can represent the remote object and execute the function. Then it's called an agent. Specifically how to achieve, do not care. Acting here is just a vision to get out of the real code.

The Java layer Binder of the Android Master Road