Binder Binder mechanisms reason for introducing mechanisms that IPC mechanism for C / S architecture design, based on consideration of performance and safety, Android system outside of the traditional IPC mechanisms, and the introduction of Binder mechanism. The performance of traditional IPC mechanism the Socket / pipe / message queue have in common, the data transmission process, starting with the sender's copy buffer to the kernel buffer, and then copy the buffer from the kernel buffer to the receiving side, the data through at least two copy. Optimal Design Binder mechanism, it need only be copied from the transmission side data buffer to the kernel buffer, the recipient can read the data directly to the kernel buffer, the data only once Copy, improves data transfer performance. Binder security mechanisms provide UID and PID communicating party, help determine unauthorized access. And, Binder mechanisms to support anonymous Binder, can be used to avoid (ie conducted by guessing Socket communication port address) by guessing risk communication. Binder Binder role mechanism mechanisms include four roles:. Binder driver, Service Manager, Service, Client Binder driver Binder driver works in kernel mode (kernel space), As part of the linux kernel, follow linux system startup. It registered MISC equipment to the linux kernel, it is what we see dev / binder device file, when Service / Client calls the open / ioctl systems operating dev / binder file called, will enter into kernel mode execution Binder driver provided implement (binder_open / binder_ioctl), then the caller requested an operation (data write / transmission, data read / reception), the drive Binder perform different jobs. Binder driver did not own process, it is always work in progress Client, Service, ServiceManager in. Design based on the user address space which a physical memory mapped to the kernel space and the receiving process of Binder driver is located, when the data copy data from the transmission buffer of the sender to the kernel buffer, and also corresponds to the copy receiving process in the receive buffer, so that the entire data transmission process, the data required after only 1 Copy, improves data transfer performance. In addition, Binder driver also provides the caller's UID & PID, these data will help determine the validity of the data recipient data, to avoid unauthorized access, improve system security. Other terms, Binder driver Binder mechanism is also responsible for the user (client, service, service manager) cache management, but also provides data receiver thread management functions. Service Manager Service Manager for all the real-name Binder managers, manages the system commonly used in basic Service (Service here and set up one of the four Android is a different concept of Service), for example MediaPlayerService, CameraService, BlueToothService and so on. First of all, after all these Service starts, it will register itself to the Service Manager. Then, Service Manager Service put the handle in the interior added to the list. Finally, when the request Handle Service to Client Service Manager, Service Manager from the list to find the inside of the handle of the corresponding service, and returned to the Client, then Client can service their needs according to Handle an application to the Service. In a broad perspective, the process has Binder entity that is the Service, from this point of view, ServiceManager itself a Service, it is also within the system first starts of Service. From the functional point of view, Service Manager is equivalent to a global list, Service to add yourself to the list, so you can retrieve the Client Service they need from the list. Service Service That is the service provider, each Service has a Binder entity, Service may be required to register themselves to the Service Manager (that is, real name Binder), may not Registration (ie anonymous Binder). Binder Binder must rely on anonymous real name to work (because it must send to the Client via a Binder own end, to start Binder communication). User Client Client-service, Client holds a reference Binder, Binder and Binder reference points to a specific entity. Client references Binder communicate with the entity (ie Service) Through this Binder, thereby obtaining service Service. Broadly speaking, reference shall be held Binder Binder mechanisms Client, in addition to ServiceManager this particular case, ServicerManager Binder holds all the real-name references, but never call the Binder service. Binder works
Binder object performance in different scenarios in different forms: the kernel space that is here binder driver. Vague talk, BpBinder Binder and Binder_ref are referenced BBinder and Binder_node are binder entity. BBinder a service provider, which implements the specific business logic. Binder_node is subject Binder driver in the kernel space created for BBinder, BBinder always binder_node correspondence, binder_node members of ptr pointer to BBinder. A process can have multiple binder_node, binder_node members of ptr is "ID", the only in-process. Binder_ref is subject Binder driver in the kernel space created for the Client, node members binder_ref point binder_node, so a bind_ref always associated with a Binder_node, but a binder_node may be associated with multiple binder_ref. A process can have multiple binder_ref, desc members in the process binder_ref is "ID", the only in-process. BpBinder is BBinder proxy that implements the same BBinder interface, but does not provide specific services. BpBinder always handle member and a member of a binder_ref desc within the same process to associate such BpBinder to a binder_ref, otherwise BpBinder not work. (This figure was stolen from the old law blog) From the above chart, we can see the client through BpBinder "binder_ref" binder_node "BBinder ultimately linked to a Service, so, Client may initiate a request to the Service by BpBinder. The Service can not take the initiative to contact the Client, because at the same time can have multiple Client related to the Service. Binder mechanisms entire work process is this (not discussed anonymous Binder): 1. Linux system boot, Binder driver to work, register the device file / dev / binder 2. Android system startup, ServiceManager start working, registered ContextManager to Binder driver, this process, Binder driver created the first binder_node (Note: ServiceManager in kernel space binder_node, but not in the user space corresponding to BBinder). 3. Service process is started, the user space to create a BBinder, and ServiceManager registration service, the registration process, Binder driver created binder_node 4. Client starts to ServiceManager request specifies Serivce of the Handle in the kernel space Service, this process , Binder driver in kernel space for the Client creates a corresponding handle handle binder_ref 5. Client ServiceManager provided according to the service request service. And step 5 above, a "complete" Binder communication process (Client request to initiate "" read-Service Request "" Processing-Service Request "" returns the process result-Service "" Client side reading result), the process substantially as follows: . Client process in user interface 2. BpBinder call BpBinder ioctl call data is written to dev / binder files, data contained in its handle 3. process into kernel mode code execution binder driver, first find the handle associated binder_ref 4. further according binder_ref associated binder_node, determining a target process is saved Service (binder_proc) 5. the process data to the target (or target thread) todo queue time data added to the current thread (binder_thread) information, and wakeup Service 6. Client 7 start waiting for a reply.
(The timing diagram, BBinder and Service are drawn together because of inherited directly from BBinder Android in many Service, so the Service and may be one of the BBinder) Binder for understanding the individual as a mechanism designed for C / S architecture IPC mechanism, Binder mechanisms for the C / S architecture has quite good support: service can simultaneously serve multiple Client. Client Service can serve multiple calls simultaneously. Service and Client roles are not mutually exclusive, who is also the same process can simultaneously two roles (ie MediaPlayerService play a role in providing services to the Service MediaPlayer, but ServiceManager registration services to the process, then played the role of Client) . Binder communication support synchronous communication, asynchronous communication is also supported, but the asynchronous communication processing priority lower than synchronous communication. Binder mechanism but also defective, then Binder mechanisms to support duplex communication, but different from the pipeline and the Socket, the communication can only be initiated by the Client, and Service response (this is the HTTP protocol and the like). Service can not initiate any communication to a Client. Of course, this is not a problem can not be resolved, the two sides communicate at the same time play the role of Client Sevice and can solve the problem (ie ActivityManagerService when starting a new activity, ActivityManagerService and ActivityThread is the case: ActivityManagerService created by ApplicationThreadProxy control ApplicationThread Activity, and ApplicationThread ActivityManagerService notification operation results ActivityManagerProxy.)
Android Binder mechanism study concluded (b) Driver section January 17, 2014 17:45:52 a220315410 read the number: 5170 This paper analyzes the realization Binder Driver. Binder Driver android kernel implementation code located in:. \ Drivers \ staging \ android \ binder.c & \ drivers \ staging \ android \ binder.h small amount of code, a total of about 4,000 lines. Download About Kernal code, you can use the command (if https is not, try using http):
