Talk to the interviewer about Binder (0) and the interviewer about binder

Talk to the interviewer about Binder (0) and the interviewer about binder

During the interview, the interviewer asked you how to answer the question: what is the Android Binder Mechanism?

I think I will say that.

At Android startup, the Zygote process incubated the first sub-process named SystemServer. In this process, many systems provide services, such as ActivityManagerSerivce and PowerManagerService, all run on a thread in this process.

The applications developed by many users, which we often say, are assigned a unique UID when installed in the system based on security considerations, run in a separate process.

Linux-based user security mechanisms cannot directly access the above system services.

However, in practice, apps often need to communicate with these system services, that is, inter-process communication.

The Binder mechanism is one of the mechanisms for implementing inter-process communication (IPC) in the Android system.

The interviewer may ask, how is the Binder Mechanism implemented?

In my opinion, to know how the Binder mechanism is implemented, we must first understand the following four concepts:

1) Server

2) Client

3) ServiceManager

4) Binder driver

Server and Client do not need to be said, we only need to know one is used to provide services, one is to obtain services, and run in different processes respectively.

So what is ServiceManager used?

In the previous article, we mentioned that ServiceManager is the same as Zygote process and one of the daemprocesses of Android.

Its main function is to help the system maintain a large number of Service lists, so it is called Service Manager.

It is like a phone book. You want to call someone to ask something (to get a Service), but you don't have a call from this person (you don't know the Service access point, only the name is known), So you first find the ServiceManager and the phone number of the person in the phone book (by name ), then you can call him to get the Service ).


We know that ServiceManager is also a separate process. To find ServiceManager, it also involves inter-process communication, isn't it?

Yes.

From the Client and Server perspective, ServiceManager is always a Server, and any access to ServiceManager is a Client.

Let's first think about it. ServiceManager itself is a process. Why can this process become ServiceManager?

Recall what was done when Android started the ServiceManager process?

1) first open the "/dev/binder" device file and map it To the memory.

2) use the BINDER_SET_CONTEXT_MGR command to make yourself a context manager, which is actually a ServiceManager.

3) enter an infinite loop and wait for the Client's request to arrive.

Therefore, a process is made ServiceManager through the Binder driver and the command "BINDER_SET_CONTEXT_MGR.


At this time, the interviewer asked a proper question: what is the Binder driver used? Is it the same as NIC Driver and sound card driver?

Different.

The Binder driver has nothing to do with hardware. It is a piece of code that runs in the kernel space. It uses a file called "/dev/binder" to move data back and forth between the kernel space and the user space.

It is the core of the entire Binder Mechanism. It is through it that the Binder can realize inter-process communication.

Because the Server, Client, and ServiceManager run in the user space, different processes cannot access each other.

Data must be transmitted between different processes only through the kernel space,

Only the Binder driver works in the kernel space.

It is responsible for the establishment of the Binder node, the delivery of the Binder between processes, the management of the count referenced by the Binder, and the transmission of data packets among different processes and other underlying operations.

Most of the work of inter-process communication is implemented through file operations such as open (), mmap (), and ioctl () in the kernel space and user space.


The interviewer then asked, What is "BINDER_SET_CONTEXT_MGR?

Yes.

When the ServiceManager process is started, it is not ServiceManager yet.

However, when it opens the/dev/binder file and passes the BINDER_SET_CONTEXT_MGR command to the Binder driver, the Binder driver creates a node (binder_node) for it in the kernel space ),

This node is the binder_context_mgr_node, that is, the Binder object of ServiceManager.

The process of this node is ServiceManager.


The interviewer suddenly inserted a sentence, "So, how do you know where ServiceManager is? "

In the entire system, there is only one binder_context_mgr_node, so there is only one ServiceManager process. Then, when accessing ServiceManager, the driver can define its handle in the system, that is, 0.


So as long as you want to find the ServiceManager process, as long as you tell the Binder driver that you want to access a process with a handle of 0, the Binder driver knows that they are looking for ServiceManager.

It will wake up ServiceManager and make it accept access.

Therefore, "BINDER_SET_CONTEXT_MGR" means that a certain process tells the driver that it wants to become ServiceManager. As long as it is the first to send this command, it is ServiceManager.

The interviewer seemed to understand a little bit, but after thinking about it, he asked: "What is a handle? "

Well, I don't know how to say this. The handle should be an identifier that distinguishes different services. However, in the Android system, the handle is used only for cross-process communication, because there is no direct access method.

If the service runs in a local process and shares the same process space, it can be accessed directly. At this time, it is not described by a handle, but referred to as a reference.

Therefore, the difference between a handle and a reference lies in remote access (cross-process) and local access (same process ).


The interviewer looked at the person in front of him thoughtfully and looked at him with a bit skeptical, but he did not continue to ask questions.

But he suddenly said another sentence, "You haven't answered me yet. How is the Binder Mechanism implemented? Let's just talk about it first? "

Through the simple description above, we can think that every Server providing services will use the Binder driver to register itself in ServiceManager, to help clients who want to obtain services, go to ServiceManager to find themselves.

Then, these services will all go through the Binder driver of the kernel space. In fact, this "pass" statement is essentially that the Server will take itself as an object and encapsulate it in a packet, copy the data to the kernel space for access by the Binder driver.

When the Binder driver reads data packets, if a service provider such as ServiceManager finds a Binder entity, a corresponding Binder node (BinderNode) is created for the corresponding Binder entity ).

These nodes are located in the process to which the Server belongs.

The Binder driver also allocates handles (greater than 0) to these services, records these handles in the Binder driver, and sends these handles and names to ServiceManager, it is maintained by ServiceManager.

That is to say, the Server communicates with the Binder driver, and the Binder driver does the following:

1) A Binder node is created in the kernel space and belongs to the processes of the Server.

2) the driver allocates a handle greater than 0 to these Binder nodes and sends these handles and names to ServiceManager.

So how does the Client communicate with the Binder driver?

Obviously, in any case, the Client needs to know who to communicate with, and they know a name.

So,

1) They encapsulate the name of the service to be obtained with a value of 0 for the handle into a data packet, open the Binder device file, and send the data to the Binder driver.

2) When the Binder driver receives a handle of 0, it will throw the packet to ServiceManager.

3) When ServiceManager receives this packet, it will analyze and find a service with a name, so it will look for it, then, send the corresponding service handle back (a handle greater than 0 ).

4) The driver sends the handle back to the Client.

5) after the Client obtains the handle, it will add the desired service and the handle to the Binder driver. Then, the Binder driver will find the corresponding handle and then ....


The interviewer sat down quietly, without an emoticons, and did not know what he was thinking. Finally, he said, "First, let's go back first. You will be notified of the result. "

I went to a company for review today. When I left, the interviewer gave me a message and waited for the notification. If there was no notification, will we cooperate next time?

Yes. After the interview, the specific notification date indicates that there is a drama. If so, you will give up waiting.

"What do you want the lowest salary? "The interviewer asked me how to answer

If you don't talk about your salary, others will think you are a poor person. So it must be said.
Yes. What's more.
Why.
1. If it is said, it means that you have so much money, it means that you have so many capabilities.
2. Be sure to let others see your self-confidence. Looking for a job, self-confidence is the most important thing. Don't be so timid, just like a mouse seeing a cat. Others will look down upon it.
As for how much it will take, it depends on the situation. If you have previously done similar jobs and want to change jobs, add a little bit on your previous salary, which indicates that, you skip the nest because your salary is not high.
If you have never done this before, let's estimate and add one more point based on your current life.
Last, remember: do not report a low price. People will definitely think you are worthless. Even if the report is high, you must be calm and confident. The boss will think that you are talented to report such a high level.
Finally, I wish you a successful interview !!!!!