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
Related
I'm tackling the task of an overlaying drawable over a view that animates the drawing of a checkmark as in the following video https://vid.me/MsQj
I don't have a preferred method for doing this but it's just not coming out the way I wanted it to, I tried:
Two views, each with on side of the checkmark to be revealed with an animation, however I'm stuck at the "revealed with an animation" since I can't use the circular reveal on -21
Frame by frame animation, this is the easiest but I'd hate to have 60 images for this stupid animation if it can be done programmatically
Drawing on a custom view canvas
My question would be, is there anything that can make this easier on me, or do I have to tackle it head first and just get on with it
You could create a custom View class which contains two lines defined by ShapeDrawables, one for each leg of the tick. Expose the lengths of these two lines as properties of the class, and then use Property Animation to animate the lengths of the lines.
Property Animation is flexible enough to handle pretty complex timing and sequencing of various properties. In this particular case you would probably want to use an AnimatorSet to sequence the two line animations so the second starts once the first has finished.
I ended up developing a custom View thanks to #SoundConception suggestion and finding out about ObjectAnimator which are very powerful in Android. In essence what goes on is we set a width for the first and second line that make the checkmark and using the animator change the value of those properties from 0 to the desired one.
On the setter for the property, we invalidate the View to redraw it with the new value and with a little tweaking I made a nice View that while its currently only working for my specific layout (ie it needs some more work on the offset calculation) it's able to draw an animated checkmark with some stuff that is customizable.
Precisely, you can set the line width, the color, the length and the animation time. And touching the java file, you can change the interpolator and all the rest of the stuff.
Hopefully the code, while not really commented serves as a basis for someone trying something similar.
For example the following code would generate something like this video, although not really because I was testing opacity and thinner lines, but you get my drift.
<coop.devtopia.CheckmarkView
android:layout_width="250dp"
android:layout_height="250dp"
android:layout_centerInParent="true"
android:id="#+id/view"
app:first_leg_length="50"
app:second_leg_length="100"
app:total_duration="1500"
app:stroke_width="20"
app:stroke_color="#22000000"/>
Repository
Update 4/2/15
I've played with this a little further and added dynamic offset calculation (fancy way of saying centering) to the tick, meaning we can generate big checkmarks, small checkmarks, skinny or thick, reversed or straight and they will be centered in the view. Can't guarantee the same for checkmarks bigger than the container, they will likely be cropped.
Here are a few of the checkmarks generated for this demonstration, of course the animate as if drawn and the effect can be very pleasing and resource friendly. This turn out to be a pretty interesting subject after all.
I've been working on this for a while but can't find anything that exactly addresses my question (at least not something easy to understand).
I have a main layout XML file where I define various layout objects like a Button or a TextView (and I know I can add SurfaceView, View, and view and other things too). I want to draw a shape (in my case it's an arc) in just one of these objects so it doesn't take up the whole screen and so I can position it relative to other things.
(In my case it will ultimately re-draw the arc kind of like a circle with a gap in a different position every time I call a method depending on a value I pass to the method, but that's separate from my basic question.)
I know the answer will have something to do with a canvas, an onDraw method, maybe Paint, probably a view. I have been able to draw a circle from a custom View object by setting the main java file's layout as that View (as opposed to R.layouts.main), but that takes up the whole screen, and I'm unsure how I might be able to have that dynamically draw with modifications.
A really clear explanation or better yet an actual example would just be awesome.
As i see it u need to draw a specific shape on widget and not on complete screen. Try using layer List.
you can refer this link for sample Link
I have two views in a ViewFlipper and have a fast/complex animation between them. The second view contains a list, so at the moment that view become visibile half way through the animation, getView() is called a bunch of times and causes a very noticeable stutter (usually stalling for the entire second half of the animation)
Ideally I would like to pre-render (measure, layout, draw) the second view before starting the animation, but I have not found a simple way to do this.
I have also explored using the drawing cache, off-screen canvases, etc - but I cannot find a simple way to achieve this either. Seems to be a problem anyone animating between two views would have. Any help?
You can do that by specifying a layer type and calling buildLayer() before you start your animation, which forces rendering the view.
newView.setLayerType(View.LAYER_TYPE_HARDWARE, null);
newView.buildLayer();
You could also use LAYER_TYPE_SOFTWARE. The default value is LAYER_TYPE_NONE, which prevents buildLayer() to do anything.
I am always confused about this and I need a pointer on how you would do it. If create a an xml layout with multiple imagesview and text view. And Lets say I want to draw line between two images and move an image along this line. How do I draw this line? I know I can get location of both images view so I have x1,y1 and x2,y2. My problem is with drawing.
Do I need surface view to have the drawing capabilities and loading bitmaps on the screen along the line?
If yes, then I guess I should always surface view to fill the screen and views on top just incase I need to draw which seems kinda wrong?
IF no (I hope thats the answer), then how do I draw lines, or load bitmaps on screen using only X,Y values?
I hope I was able to explain my confusion
Thanks
EDIT: Actually I thougth of a way of explaining my confusion better.
When you create an activity with xml layout you have something like
onCreate (){
setContentView(R.id.layout)
}
but when you have activity with drawing view you have something like
onCreate (){
SurfaceView v = new Surfaceview(this);
setContentView(v)
}
My problem is that we have to set the content layout to EITHER xml layout or to be drawing area . What if I want to set it to my xml layout and at the same time I can draw anywhere on the screen (over images view, empty areas, TextViews ..etc)
See my question?
That depends on what your desired result is and how much flexibility you need. You can have a look at this android Animations tutorial (the site is down at the time of posting but google has it cached).
If you don't need flexibility, then for your line, you might be able to create a View in your xml with an android:background fill color and a size that makes it look as you wish. You could then use an Animation on your bitmap's ImageView to translate it along the line, and use a listener on said Animation to show/hide the various Views as necessary at the beginning or end of your Animation.
If you need flexibility, the SurfaceView is probably your best bet.
I am guessing they are a quick overview of the time it took to draw the view, but I am not positive.
they are an indication of the time it took to (from left to right) measure, layout and draw; green being good, red being bad. In measuring and layout red blobs usually occur when the hierarchy is very deep, or you have a lot of views in general (say more than 100ish).
I would add that a green bubble doesn't mean it's 100% good and a red one doesn't mean that this view is bad. Green/Yellow/Red show how well does this View (or ViewGroup) behaves comparing to its siblings.
Here is an example: AppcompatCheckedTextView takes reasonable half of millisecond here, considering the fact it contains both text and image. It is red just because the other sibling view is super simple.
In the same time, the screen has another view with green bubbles that gets all the 16msec in which the whole frame should be rendered (Why 60 fps), what is bad. But because there is an even slower sibling, the tool shows it with green markers: