Binder: a paper clip or paper clip. We often use pins to separate two sheets of paper. In the Android system, binder is the basic framework used to complete inter-process communication IPC, that is to say, different processes are separated so that each process can transmit messages to each other. If you have developed a Java server, you can also think of it as an RPC call, that is, directly calling functions in other processes locally. Understanding this mechanism will help you better understand the overall architecture design of Android, because the communication between core modules is completed through the binder, this is why the author puts this part of content in the first chapter of the kernel;
The binder framework consists of three parts: Server, binder driver, and client. For details, see:
- Server: a service provider. For example, Android provides many system services, such as alarm, WiFi, input, layout_inflater, and activity. Of course, developers can also implement their own services, then open the service to other applications. In code, the service interface must inherit the iinterface, and the service implementation class must inherit the binder;
- Binder DRIVER: in fact, it is a virtual driver that complies with the Linux Device Driver Model. The device node is/dev/binder. It is mainly used to implement client-side and server-side Request Transfer. Its source code is located in. /frameworks/native/libs/binder/directory;
The specific driver is enabled and listened to through the servicemanager daemon. It is defined in./init. Rc. The source code is located in./frameworks/base/cmds/servicemanager /;
- Client: a service consumer. To call functions in other processes, a local reference to a remote object must be provided, and the client and server must follow the same interface and data exchange protocol; these two points are the two core problems to be solved for implementing IPC communication;
To simplify the development and communication costs between service providers and consumers, the android system provides aidl (Android Interface Definition Language) tool support, this tool can convert an aidl file used for interface declaration into a Java file. The conversion process is to make the service automatically comply with the binder framework design specifications at the code level, and automatically solves the second of the two core issues mentioned above. The generated java files actually include three classes:
Service Interface Class ixxx extends Android. OS. iinterface;
Local stub class ixxx. Stub extends Android. OS. binderimplements ixxx;
Remote proxy class ixxx. stub. proxyimplements ixxx;
Those who have experienced the EJB age must be quite familiar with the above Code Format, haha!
After the above files are generated, the service provider can focus on writing specific logic code, and directly implement the specific method of extends ixxx. stub;
Can I generate code without the aidl tool? Of course, you can write the relevant code if you like, as long as it complies with the binder code specifications;
Core Method of the local stub class ixxx. Stub used by the service provider
- Public final Boolean transact (INT code, parcel data, parcel reply, int flags );
Actually, it is the method in the parent class binder. Because it is final, the subclass cannot be overloaded. This is also part of the binder framework design because it does not allow developers to change the calling mechanism at will, this method is used to receive service call requests, but instead of directly processing these requests, it is transferred to the ontransact method (which can be overloaded by subclass) for processing, this is a very important design concept in the Android system and is widely used in various scenarios. Later, you will see that onxxxx-related methods are generally related function callbacks or subclass overload points;
- Protected Boolean ontransact (INT code, Android. OS. Parcel data, Android. OS. Parcel reply, int flags );
Determine the specific business method in which the ixxx interface is executed based on the parameter code, and extract data from the data in order as the input parameter of the specific business method;
Note: the order in which data is retrieved from parcel must be the same as that in data storage (ixxx. stub. the description of the Business Method in the proxy is the same, otherwise the data will be messy, which is the core issue to be solved by the aidl tool to automatically generate the Code;
- Public static ixxx asinterface (Android. OS. ibinder OBJ );
Converts a remote object reference to a specific service interface. The local and remote call details are automatically blocked because the service provider can be called by other processes, it can also be called by other functional blocks in the process;
Core Method in the remote proxy class ixxx. stub. proxy used by the Service consumer
- Proxy (Android. OS. ibinder remote );
A constructor is a remote service reference. All service method calls are indirectly executed through this reference;
- XYZ (...) Various specific business methods;
Here, the implementation of the service interface is not really the business logic implementation. It is the remote service's local proxy in use, used for intermediate calls, mainly to complete the conversion from the input parameter to the package parcel, because IPC remote calls must pass messages based on the package parcel, which is part of the binder framework design specifications;
Call mremote. transact (…) after the input parameter is converted (...) Send the request to the service provider;
How do service consumers obtain remote object references?
- For system services (automatically loaded in the systemserver process when the system is started), Android provides a unified Acquisition Interface, using the factory mode, you can use servicemanager. getservice (.) obtain the reference ibinder of the remote object, and then use ixxx. stub. asinterface (.) method To get reference to the specific service interface ixxx;
Note: we generally do not directly use the service interface ixxx, but use the corresponding manager class (which can be understood as the broker of the remote service object ), this is also a common design specification of the Android system. This design is used to shield direct access to remote services and provide flexible and controllable API interfaces for applications;
It does not directly use servicemanager, but directly uses context. getsystemservice (.) to obtain the manager class corresponding to a specific service;
For more information about the relationship between service and manager, see:
- For non-system services, you can execute context. startservice (.) run bindservice (intent service, serviceconnection Conn, int flags) to obtain the remote object reference of the service, specifically in serviceconnection. onserviceconnected (componentname
Name, ibinder service); obtained in this callback function; see:
If the above content is reproduced, please indicate the source, welcome to visit the column http://blog.csdn.net/sfdev of laotang
