(reprint please indicate the source: http://www.cnblogs.com/linguanh/, this article comes from: 【 kuan-hung Lin (ghost) fingertips blog])

Before the order

This article will clarify the following three questions and supplement a common view on the Internet:

1. During the startup of Android APP, the onCreate and other life-cycle functions of the Activity will never be executed due to the dead loop in looper.loop ().

2. How the View is drawn and why it never refreshes because the loop in looper.loop () is stuck.

3. The views of the Internet are as follows:

1. The handler mechanism is implemented using PIPE

2. The main thread blocks at the read end of the pipe when there is no message processing

3. Binder threads add messages to the main thread message queue and write a byte to the pipe writer, which wakes the main thread to return from the pipe reader, i.e. Queue.next () calls return






Answer the first question
Click me to view PDF images

 

Second question

Conclusion: The bottom rendering of the View is triggered by the Binder process communication, which is received and processed by the event mechanism of the bottom SurfaceFlinger worker thread, including handler, Looper and messageQueue. It has nothing to do with the Handler of an ActivityThread, or almost nothing to do with an ActivityThread, but if you call the View function inside an ActivityThread, For example, a setText for handleMessage (..) , which will send this information to SurfaceFlinger’s event mechanism, be processed accordingly, and finally refresh to the interface.

Click me to view PDF images


Third addition
Fourth question
　　 

1 void checkThread() { 2 3 if (mThread ! = Thread.currentThread()) { 4 5 throw new CalledFromWrongThreadException( 6 7 "Only the original thread that created a view hierarchy can touch its views."); 8 9} 10 11}Copy the code

The third line of code, where mThread is the thread that created the ViewRootImpl, and the ViewRootImpl is created in the main thread, so we call it the main thread. If the mThread and the current thread run the same equation, the error occurs. It’s not that the child thread can’t refresh the UI; rather, it’s the message that sends the UI refresh message, because the actual underlying refresh is not the main thread of the current APP. It’s limited, if when the view wrootimPL is created by a child thread, then you can send a message to update the UI in that child thread, and it naturally updates, so why is it limited?

The following analysis is quoted from Zhihu

Because the same is true not only in GUI, but in almost all programming areas, there is the overhead of thread synchronization. Obviously, two threads cannot draw at the same time, otherwise the screen will be drawn; Do not insert the map at the same time, otherwise memory will be spent. Do not write buffers at the same time, otherwise the file will be consumed. Mutual exclusion is required, such as locks. The result is that only one thread can do the UI at a time. So when the chances of two threads being mutually exclusive are high, or when the code guaranteeing mutual exclusion is complex, choosing one of them to hold the other messages for a long time is a typical solution. So the general requirement is that the UI be single-threaded.

If you think this article is good or informative, you can passScan the Alipay QR code belowTip me a cup of coffee [material support], you can also click on the lower right corner“Recommended”Button [spiritual support], because these two kinds of support are the biggest motivation for me to continue to write and share