[Android] an in-depth understanding of findViewById principles and an in-depth understanding of android

[Android] an in-depth understanding of findViewById principles and an in-depth understanding of android

I used too much, but I don't know the principle. In Xutils, instead of using the findViewById annotation, I didn't understand it at the time. After learning it step by step, we found that the findViewById efficiency is very low compared to the annotation method. The process of annotation + reflection loading instances looks more efficient.

Start from onCreate () of the activity:

Click to view the source code and enter the method in the Activity. class:

Activity. class

The findViewById method of getWindow () is returned. What is getWindow?

Activity. class

The returned Window object is an abstract class. The abstract method can be used to manage the UI component of the Activity. First, we will understand the principle of findViewById.

Since the findViewById of the Activity is the findViewById method that calls getWindow () (that is, the Window object), go to the Window to find its findViewById.

Window. class

The returned result is the findViewById of getDecorView (). Previously, Window is an abstract class and cannot be used to manage the ActivityUI component. Therefore, getDecorView () returns a specific View object, to manage the UI components of the Activity.

This getDecorView is an abstract class that implements this class. The returned View can be used to manage the UI View.

Then, the findViewById method of the Activity is passed in to the findViewById of the View step by step through getDecorView () (return View. The following is the View class.

View. class

The logic is very simple. You can call findViewTraversal () directly and compare it with the passed-in id. If it exists, the current view is returned. If it does not exist, null is returned. FindViewTraversal literally means to repeatedly search for the view ID.

Here I have no clue. By the way, the mID search should be constantly compared with the ViewGroup. If it is ViewGroup and there is a View in it, it should also be a recursive process, it cannot be seen from here. So I see how to set the mID.

This is a set method that adds an ID to the sub-view control to identify the view. This ID can be seen in the R file.

First, I gave the id to the mID. If the mID is empty (that is, no ID is added), and it is not used as a label (not quite understandable), then I will add an ID to it, dynamically generate the Control ID.

Start with a fixed address and find IDs one by one. The IDS set appear to be continuous. Search for recursion and find a loop .. No similar code found.

It seems that you need to know the mID to know the answer. However, this analysis will fail.

Cause:

See the inheritance structure of layout, such as LinearLayout and RelativeLayout:

In ViewGroup, The findViewTraversal () method of View has been rewritten!

Click in to find the answer soon.

This is a method of rewriting: we can clearly see that the principle of findViewById is to find it from the beginning. If there is a child control, we will recursively find it. The specific details are not taken into consideration. Here, the initial conjecture is confirmed. Among them, v. findViewById calls the method in the View, while the findViewById of the View calls findViewTraversal (). This achieves a recursion.

Respect the author indicated the Source: http://blog.csdn.net/bless2015/article/details/46618639

When I was looking for findViewById, I began to ignore the override of the View method by the subclass ViewGroup. As a result, ten thousand lines of View. class Code were in an endless loop and I could not find the desired method. But I still found some interesting things and sorted them out later.