Hierarchyviewer measure, layout, and drawing time (better)

Question

I am trying to understand the presentation of a hierarchy.

So, I read developer.android.com the meaning of three points:

Green: for this part of the rendering time, this view is faster than 50% of all View objects in the tree. For example, a green dot for the measurement time means that this view has a faster measurement time than 50% of the View objects in the tree.

Yellow: for this part of render time, this view is in the slower 50% of all View objects in the tree. For example, a yellow dot for the layout time means that this view has a slower layout time than 50% of the View objects in the tree.

Red: for this part of the rendering time, this view is the slowest one in the tree. For example, a red dot for drawing time means that this view takes the most time to draw all View objects into the tree.

If I’m not mistaken, doesn’t this mean that there should always be no more than 3 views with red dots (the slowest views for each category: measurement, layout, draw), and then half of the views are yellow and half green.

First of all, I see more than three views with red dots, and I don’t understand why.

Secondly, I don’t see how these values ​​can help improve performance, given that these are relative values. There will always be half the views faster than the other half.

And looking at the Tree View, I see visibility gone views that have little drawing time. Should I completely ignore the GONE views?

Answer 1

If I'm not mistaken, doesn't that mean there should always be a majority of 3 views with red dots

Your logic is good, but the document should not indicate a tree, but in a node. The hierarchy viewer tool4s function that you use to get these three points is Profile Node , and this will begin to profile the tree from the selected node (arbitrary tree root) to the end of the tree.

Each View , in the ViewGroup ( layouts based on the ViewGroup ), which contains more than the View, will have points, Otherwise, there are no points.

Thus, the comparison is made only at the node level, and not on the whole tree, and that is why you can get more than three red dots (one for measurement, one for layout, one for drawing) for all the tree, but not for node.

Secondly, I don’t see how these values ​​can help improve performance given that these are relative values. There will always be half views faster than the other half.

The dots will help you find out which view inside the viewing group is the slowest to measure / layout / draw. To avoid freezing the screen, the total amount of operation should be lower than 16.6 ms (the android must support a frame rate of 60 frames per second).

The red dot will just give you a hint about what kind of profile you should have, but that does not mean that the presentation is not optimized, especially with a complex hierarchy with many children.

Also, if you need to create your own view, a hierarchy viewer can help you find out if you are performing fast rendering correctly.

I see visibility gone species that have little drawing time. Should I completely ignore the GONE views?

A View , which has the visibility set to GONE , will not go through onMeasure , onLayout and onDraw . You can easily try if you extend the widget like TextView and override these methods with Log.d to find out what will happen.

But I suppose that the time for the rally is because the presentation will be created, then attached to the window and, finally, change its appearance.

Example with TextView. First step: the object is created using the java public Text(Context context, AttributeSet attrs){...} constructor public Text(Context context, AttributeSet attrs){...} ), then the call to attach the window will be made using protected void onAttachedToWindow() {...} , and the visibility is changed using protected void onWindowVisibilityChanged(int visibility) {}

Now, if you want to debug more than your UI, try with a phone that has the Debug GPU Overdraw in the developer’s settings (not on all phones) or with an emulator. You can then see where the application overloads, and then optimizes your interface. Debugging GPU Overdraw firmware