I am trying to understand the hierarchy view.
So I was reading on developer.android.com the meaning of the three dots :
Green: For this part of the render time, this View is in the faster 50% of all the View objects in the tree. For example, a green dot for the measure time means that this View has a faster measure time than 50% of the View objects in the tree.
Yellow: For this part of the render time, this View is in the slower 50% of all the 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 render time, this View is the slowest one in the tree. For example, a red dot for the draw time means that this View takes the most time to draw of all the View objects in the tree.
If I'm not mistaken, doesn't that mean that there should always be at most 3 views with red dots (the slowest views for each category : measure, layout, draw), and then half of views yellow and half green.
First of all I see more than 3 views with red dots and I don't understand why.
Second, I don't see how these values can help improve performance considering that these are relative values. There will always be half of the views faster than the other half.
And looking at the Tree View I am seeing views with visibility gone
that have a small draw time. Shouldn't GONE views be completely ignored?
If I'm not mistaken, doesn't that mean that there should always be at most 3 views with red dots
Your logic is good, but the document must not say tree but at a node. The tool4s function of the hierarchy viewer you use to get these 3 dots is Profile Node
, and this will start to profile the tree from the selected node (the arbitrary root of the tree) to the end of the tree.
Every View
, into a ViewGroup
(layouts are based on ViewGroup) which contains more than a View, will have the dots. In the opposite case there is no dots.
So the comparison is only made on a node level, not for all the tree, and this is why you can get more that three red dot (one for measure, one for layout, one for draw) for all the tree, but not for a node.
Second, I don't see how these values can help improve performance considering that these are relative values. There will always be half of the views faster than the other half.
The Dots help you to know which view inside a view group is the slowest to Measure/Layout/Draw. To avoid the screen to freeze, the total of an operation must be under 16.6ms (android should keep a frame rate of 60 frames per second).
The red dot will just give you an hint about which view you should profile but this doesn't mean that a view is not optimized, especially with a complex hierarchy with lots of children.
Also if you have to build a custom view, the hierarchy viewer can help you to know if you are correctly doing a quick rendering.
I am seeing views with
visibility gone
that have a small draw time. Shouldn't GONE views be completely ignored?
A View
which has a visibility set to GONE
will not go through onMeasure
, onLayout
and onDraw
. You can easily try it if you extends a widget like a TextView and override these methods with a Log.d to know what happen.
But I guess the time on draw comes because the view will be created, then attach to the window and finally change its visibility.
Example with a TextView. First step the object is created via the java constructor public Text(Context context, AttributeSet attrs){...}
), then a call to attach the window will be performed with protected void onAttachedToWindow() {...}
and the visibility changed with protected void onWindowVisibilityChanged(int visibility) {}
Now if you want to debug more your U.I., try with a phone which have the option Debug GPU Overdraw
into the Developer Options (not all the phone have it) or with the emulator. You can then see where the app is overdrawing and then optimized your interface.
Debug GPU Overdraw walkthrough
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With