The source code has been analyzed, let's summarize it again.
1. About the message cache pool:
1. Android engineers make full use of the advanced language features of JAVA: that is, the class holds a property of the class itself as the next pointer of the linked list in the classic data structure, and realizes the header of the linked list with the characteristic that the static property belongs to the class itself.
2. Why is there a message cache pool?
To put it bluntly, the message function is simple, but the usage is large, so it is necessary to recycle the used message: it can reduce the waste of resources caused by repeated creation, and its recycling cost is very low.
3. Who will recycle the message?
We know that the message cache pool can be used through Message.obtain(), which is fetching; when looking at the source code, Looper distributes the message to the target (at this time the message has completed his mission: successfully used as a carrier to deliver the message content ), it is directly recycled.
Attachment: Timing of message recycling: after msg is removed from the message queue; after a single loop ends; after the developer actively calls recycle() of msg.
2. About blocking
The principle of changing the message queue maintained by MessageQueue to the messge buffer pool is the same. If there is no suitable message to be retrieved every time a message is dequeued, the thread will be blocked and wait for a suitable message to wake up for processing.
The way MessageQueue is implemented is not through java, but through jni to call the C++ code of the native layer (the C++ code implements a set of Looper+MessageQueue+handler). The way to block the thread is to call the Linux monitor file descriptor ePoll.
3. Why use handlers to implement inter-thread communication?
Android is an event-driven system. When an application is first created, its main thread will create a Looper to continuously receive various events. If we create an application and do nothing, the program may be in a blocked state. (because he has no events to handle). Conversely, if we perform time-consuming operations on the main thread, one of the main threads is performing this time-consuming operation, and cannot handle other transactions, causing the interface to freeze, which may cause ANR.
4. About the looper
Each handler must correspond to a looper.
After the main thread starts the application, it automatically creates the Looper object (we can get it through getMainLooper), and there is no need to create it manually.
When we create a new handler for the child thread, if we do not pass in the specified looper, then the looper will be bound to the looper of the thread that currently created the handler by default, and an error will be reported if there is no looper. So to open the handler in the child thread, you must first create a looper, and open the looper loop, that is, call loop().
5. Why does the looper infinite loop not cause the application to freeze?
After clicking the desktop icon to start the activity for the first time, it will eventually go to the main method of the ActivityThread. In the main method, a Looper is created (the looper has created a message queue) to process the messages of the main thread, and then Looper.loop() will enter the dead The loop, and then the life cycle of the activity and other transactions are executed through the loop method.
The main method of the UI thread is the message loop. Once the loop exits, the app also exits. Looper.loop() may cause the main thread to be blocked (it depends on what transaction it is executing, whether it takes time), but as long as the message loop is not blocked and the incoming transaction can be processed all the time, it will not return ANR.
What really causes ANR is not the blocking of the main thread, but the task blocking that occurs during the processing of the Looper message of the main thread. , but cannot respond to the user's operation in real time and refresh the UI in time. That is, there is no necessary relationship between blocking and ANR. Although the main thread is blocked when there is no message processing, as long as it can respond in time and process it immediately when there is a new message, it will not return ANR.
Summary: There is no relationship between application stuck and Looper's infinite loop. When there is no message processing, the application is sleeping and the thread is released; stuck is ANR, and Looper is sleeping.