Shulou(Shulou.com)05/31 Report--

This article mainly introduces the relevant knowledge of what the Binder thread pool working process is, the content is detailed and easy to understand, the operation is simple and fast, and has a certain reference value. I believe you will gain something after reading this Binder thread pool working process. Let's take a look at it.

Based on the analysis of the source code of Android 6.0, the Binder thread pool and the start-up process of Binder thread are analyzed.

one。 Overview

After the Android system is started, ActivityManager, PackageManager and other major services are running in the system_server process. App applications need to use system services to complete the communication between processes through binder. How is the binder thread managed and how is it created? In fact, both the system_server process and the app process start the binder thread pool during the execution of onZygoteInit () in the new process after the process fork is completed. Next, use this as a starting point to look at the world of binder from a threaded perspective.

two。 Binder thread creation

Binder thread creation and the creation of its own process are generated in the creation of Java layer processes. The socket message of the creation process is sent to the Zygote process through the Process.start () method. After receiving the message, Zygote will call Zygote.forkAndSpecialize () to fork the new process. In the new process, the RuntimeInit.nativeZygoteInit method will be called. After jni mapping, the method will eventually be called to the onZygoteInit in app_main.cpp, so let's start with this method.

2.1 onZygoteInit

[- > app_main.cpp]

ProcessState::self () is a singleton mode, the main work is to call open () to open / dev/binder driver device, and then use mmap () to map the kernel address space, and assign the Binder-driven fd to the variable mDriverFD in the ProcessState object for interoperation. StartThreadPool () is to create a new binder thread and keep doing talkWithDriver ().

2.2 PS.startThreadPool

[- > ProcessState.cpp]

After starting the Binder thread pool, set mThreadPoolStarted=true. Use the variable mThreadPoolStarted to ensure that each application process is allowed to start only one binder thread pool, and this time the binder main thread (isMain=true) is created. Threads in the rest of the binder thread pool are created under the control of the Binder driver.

2.3 PS.spawnPooledThread

[- > ProcessState.cpp]

Gets the Binder thread name in the format Binder_x, where x is an integer. The binder encoding in each process starts at 1 and increases in turn; only threads created through the spawnPooledThread method conform to this format, and thread names that add the current thread directly to the thread pool through joinThreadPool do not conform to this naming convention. In addition, at present, the Binder command in Android N has been changed to Binder:_x format, which is very helpful for analyzing problems.

2.3.2 PoolThread.run

[- > ProcessState.cpp]

In the case of isMain=true, command is BC_ENTER_LOOPER, which represents the main thread of Binder and will not exit.

In the case of isMain=false, command is BC_REGISTER_LOOPER, indicating that the thread is created by the binder driver.

2.5 processPendingDerefs

[- > IPCThreadState.cpp]

2.6 getAndExecuteCommand

[- > IPCThreadState.cpp]

2.7 talkWithDriver

The isMain=true that is called here, that is, what is written to mOut, for example, is BC_ENTER_LOOPER. After talkWithDriver (), where does the program go next? Move on from binder_thread_write () to the BC_ENTER_LOOPER process.

2.7.1 binder_thread_write

[- > binder.c]

You will enter the done when one of the following three situations occurs:

An error occurred in the return_error of the current thread

When the Binder driver sends a death notification to the client

When the type is BINDER_WORK_TRANSACTION (that is, the command received is BC_TRANSACTION or BC_REPLY)

Any Binder thread generates a BR_SPAWN_LOOPER command for creating a new thread when both of the following conditions are met:

No binder thread is requested in the current process, that is, requested_threads = 0

There are no binder threads available for the current process, that is, ready_threads = 0; (the number of threads that go into sleep is the number of idle threads)

The number of started threads in the current process is less than the maximum limit (default 15)

The current thread has received a BC_ENTER_LOOPER or BC_REGISTER_LOOPER command, that is, it is currently in the BINDER_LOOPER_STATE_REGISTERED or BINDER_LOOPER_STATE_ENTERED state. [section 2.6] the status has been set to BINDER_LOOPER_STATE_ENTERED, and obviously this condition is satisfied.

The flow is executed all the time from the binder thread of system_server: IPC.joinThreadPool-> IPC.getAndExecuteCommand ()-> IPC.talkWithDriver (), but after talkWithDriver receives the transaction, it goes into IPC.executeCommand (), and then starts with executeCommand.

2.8 IPC.executeCommand

The Binder main thread is created together with the process in which it is created, and the normal binder thread that is created later is created by the spawnPooledThread (false) method.

2.9 thinking

By default, the maximum number of threads in the binder thread pool of each process is 15. The upper limit does not count the binder main threads created by the BC_ENTER_LOOPER command, but only the threads created by the BC_REGISTER_LOOPER command, or many people do not understand, for example, chestnut: if the main thread of a process executes the following methods, what is the upper limit on the number of binder threads that the process can create?

First of all, the maximum number of binder threads in the thread pool is 6, the main thread created by startThreadPool () is not in the maximum thread limit, and the last sentence is to turn the current thread into a binder thread, so the upper limit of the number of binder threads that can be created is 8. If you do not understand, it is recommended to take a look at the source code of these solutions and think more about the entire binder architecture.

three. Summary

In the Binder design architecture, only the first Binder main thread (that is, the Binder_1 thread) is actively created by the application, and the ordinary threads in the Binder thread pool are all created by the Binder driver according to the IPC communication requirements, and the creation flow chart of the Binder thread:

Each time a new process is created by Zygote fork, along with the creation of the binder thread pool, spawnPooledThread is called to create the binder main thread. When a thread finds that there are currently no idle threads, no request to create a thread, and does not reach the upper limit during the execution of the binder_thread_read, a new binder thread is created.

There are three types of transactions for Binder:

Call: the thread that initiates the process is not necessarily in the Binder thread. In most cases, the receiver only points to the process and is not sure which thread will handle it, so the thread is not specified.

Answer: the initiator must be a binder thread, and the recipient thread is the originating thread of the last call (this thread is not necessarily a binder thread, it can be any thread).

Async: similar to the call type, except that async does not require a reply in oneway mode, the thread that initiates the process is not necessarily in the Binder thread, the receiver only points to the process, and is not sure which thread will handle it, so the thread is not specified.

There are three types of binder threads in Binder systems:

Binder main thread: the process creation process calls startThreadPool () and then enters spawnPooledThread (true) to create the Binder main thread. The number starts at 1, which means that the binder main thread is named binder_1, and the main thread does not exit.

Binder normal thread: it is up to Binder Driver to decide whether to create a binder thread based on whether there are idle binder threads, callback spawnPooledThread (false), isMain = false, the thread name format is binder_x.

Binder other threads other threads do not call the spawnPooledThread method, but call IPC.joinThreadPool () directly to queue the current thread into the binder thread queue. For example, the main thread of both mediaserver and servicemanager is a binder thread, but the main thread of system_server is not a binder thread.

This is the end of the article on "what is the working process of the Binder thread pool". Thank you for reading! I believe you all have a certain understanding of the knowledge of "what is the working process of Binder thread pool". If you want to learn more, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.