As a developer, everyone has areas that everyone is good at, and naturally there are areas that they are not good at. It is difficult to become a perfect full-stack developer. One of the most feared things in an interview is that the interviewer will ask questions in areas that you are not good at. The purpose is to see your ability to respond to problems.
Next, I will share with you a knowledge point that is easy to be asked in an interview: " Tell me about your understanding of the binder driver ". Although this question is a bit helpless for "interviewing rockets", the difficulty is also a highlight and reflects the value. It is a screening interview. effective means. If you were asked to answer, how much could you say? Let's take a look at the answers of students A, B, and C respectively!
Student A: He thinks he knows everything, and his level has reached the ceiling of application development. The current monthly salary is 10k
Interviewer ️ : Tell me about your understanding of the binder driver
A : The binder driver is a very low-level thing. In the system kernel, it is the cornerstone of the binder mechanism.
Interviewer : Is it gone? tell me everything you know
A : Just let me say that I don’t know the answer, so please ask me a question
Interviewer : Okay, you mentioned the system kernel just now, so let’s introduce user space and kernel space
A : I don’t know, it’s useless to understand this thing! I have a better understanding of business development APIs, such as the layout of RecycleView, which I wrote as a thief~
Interviewer : Okay, go back and wait for the notice
Student B: I often play games, watch dramas, and stay up late in my spare time. My current monthly salary is 15k
Interviewer : Tell me about your understanding of the binder driver
B : The binder mechanism is divided into four parts, binder driver, Service Manager, client, and server. Analogous to network communication, the Service Manager is DNS, and the binder driver is a router. It runs in the kernel space, and different processes can communicate through the binder driver.
Interviewer : Why does the binder driver run in the kernel space? Can it be moved to userspace?
B : No, the process spaces of the two processes have different virtual address mapping rules, the memory is not shared, and they cannot communicate directly. Linux divides the process space into user space and kernel space, running user programs and system kernel respectively.
Although user space and kernel space are also isolated, data can be copied from user space to kernel space through copy_from_user, and data can be copied from kernel space to user space through copy_to_user.
Therefore, the binder driver must be in the kernel space to realize the communication between the two processes. The general IPC method needs to call these two functions separately, and the data is copied twice, but the binder mmaps the kernel space and the target user space, and only needs to call copy_from_user to copy once.
Interviewer : How to call the binder driver of kernel space from user space?
B : I don’t understand this, I haven’t read the binder source code, but I just know the general communication method
Interviewer : Tell me what else do you know about the binder driver?
B : Well... no more
Interviewer : Okay, go back and wait for the notice
Classmate C: Persist in studying every day and constantly improve yourself. The current monthly salary is 30k
Interviewer : Tell me about your understanding of the binder driver
C: Simply draw a picture:
For the Binder mechanism, it is a router for IPC communication, responsible for realizing data interaction between different processes, and is the core of the Binder mechanism; for the Linux system, it is a character-driven device that runs in the kernel space and provides/ dev/binder device node and system calls such as open, mmap, and ioctl.
Interviewer : You mentioned the driver device, so let’s talk about the driver device of Linux first.
C : Linux abstracts all hardware access to read, write and set files. The specific implementation of this "abstract" is the driver. The driver acts as a hub between hardware and software, provides a set of standardized calls, and maps these calls to actual hardware device-related operations, hiding the details of the device's work from the application.
Linux driver devices are divided into three categories, namely character devices, block devices and network devices. A character device is a device that can be accessed like a byte stream file. When a character device is read/written, the actual hardware I/O operation usually occurs immediately after. Character device drivers usually implement open, close, read, and write system calls, such as display screens, keyboards, serial ports, LCDs, and LEDs.
A block device refers to a device that is accessed by transferring data blocks (usually 512 or 1k), such as hard disks, SD cards, U disks, and CDs. Network devices are devices that can exchange data with other hosts, such as network cards, Bluetooth and other devices.
There is a special misc miscellaneous device in the character device, the device number is 10, which can automatically generate device nodes. Android's Ashmem and Binder are all misc miscellaneous devices.
Interviewer : Have you seen the specific implementation of the binder-driven open, mmap, and ioctl methods?
C : They correspond to the binder_open(), binder_mmap(), and binder_ioctl() methods in the driver source code binder.c, binder_open() mainly creates and initializes binder_proc, and binder_proc is a structure used to store binder-related data. unique to each process.
The main job of binder_mmap() is to establish a mapping of the virtual memory of the application process in the kernel, so that the application program and the kernel have a shared memory space to prepare for a subsequent copy.
The binder driver does not provide conventional read(), write() and other file operations, all are implemented through binder_ioctl(), so binder_ioctl() is the one with the largest workload in the binder driver, and it undertakes most of the business of the binder driver.
Interviewer : How does only one method of binder_ioctl() realize most of the business?
C : The binder mechanism divides the business into different commands. When calling binder_ioctl(), specific commands are passed in to distinguish the business, such as the BINDER_WRITE_READ command for reading and writing data, and the dedicated DNS registration command for Service Manager.
The BINDER_WRITE_READ command is the most critical, and it subdivides some subcommands, such as BC_TRANSACTION, BC_REPLY, etc. BC_TRANSACTION is the most commonly used IPC call command in the upper layer, and the transact method of the AIDL interface is this command.
Interviewer : In order to realize these business functions in the binder driver, some data structures must be used to store relevant data, such as the binder_proc mentioned above when you mentioned the binder_open() method. Do you know other structures?
C : know some, such as:
| structure | illustrate |
|---|---|
| binder_proc | Describes the process using binder, which is created when the binder_open function is called |
| binder_thread | Describes the thread that uses the binder, which is created when the binder_ioctl function is called |
| binder_node | Describe the binder entity node, corresponding to a serve, that is, the BpBinder object in user mode |
| binder_ref | Describes a reference to a binder entity node, associated to a binder_node |
| binder_buffer | Describe the Buffer that stores data during binder communication |
| binder_work | Describe a binder task |
| binder_transaction | Describe the data information related to a binder task |
| binder_ref_death | Describe the death information of binder_node, that is, binder server |
The main structure reference relationship is as follows:
Interviewer : Okay, let's talk about something else.
If you were asked these questions, how would you answer them?
If you haven't mastered Binder yet, and want to get a thorough understanding of it in the shortest time, you can refer to "Android Framework Core Knowledge Points" , which includes: Init, Zygote, SystemServer, Binder, Handler, AMS, PMS, Launcher... ... and other knowledge point records.
"Framework Core Knowledge Point Summary Manual" :https://qr18.cn/AQpN4J
Part of the implementation principle of the Handler mechanism:
1. Macro-theoretical analysis and Message source code analysis
2. MessageQueue source code analysis
3. Looper source code analysis
4. Handler source code analysis
5. Summary
Binder principle:
1. Knowledge points that must be understood before learning Binder
2. Binder mechanism in ServiceManager
3. System service registration process
4. ServiceManager startup process
5. System service acquisition process
6. Java Binder initialization
7. Java The registration process of system services in Binder
Zygote ：
- The startup process of the Android system and the startup process of Zygote
- The startup process of the application process
AMS source code analysis:
- Activity life cycle management
- onActivityResult execution process
- Detailed Explanation of Activity Stack Management in AMS
In-depth PMS source code:
1. PMS startup process and execution process
2. APK installation and uninstallation source code analysis
3. Intent-filter matching structure in PMS
WMS:
1. The birth of WMS
2. The important members of WMS and the addition process of Window
3. The deletion process of Window
"Android Framework Study Manual":https://qr18.cn/AQpN4J
- Boot Init process
- Start the Zygote process at boot
- Start the SystemServer process at boot
- Binder driver
- AMS startup process
- The startup process of the PMS
- Launcher's startup process
- The four major components of Android
- Android system service - distribution process of Input event
- Android underlying rendering-screen refresh mechanism source code analysis
- Android source code analysis in practice
