Now let's talk about drawing.
So every time you want to redraw a view,
you have to call a method called invalidate.
It's pretty easy to use,
but it can also be very expensive.
To give you an idea,
if you have a fairly reasonable view hierarchy--
so let's say that you create an application
like the contacts application.
When you call invalidate
on one of the widgets on the screen,
it can take up to 3 or 4 milliseconds
for the framework to do
whatever it has to do with that command,
and then comes back--
comes back to your view and sends you the draw command.
Another issue with invalidation
is that when you invalidate
several views at the same time onscreen--
so let's say I invalidate the view
in the bottom left corner,
and at the same time I have a view
that's invalidating itself in the top right corner,
the framework will take the union of those two regions,
which will be pretty much the entire screen,
and you will end up invalidating
a lot more than what you need.
So as much as you can,
you shouldn't validate small regions of the screen.
To do this, we have two methods
called invalidate, and you pass a rectangle,
or invalidate, and you press the coordinates
of the rectangle to invalidate.
Those methods are part of the API on the view class.
And they're really effective
to improve the performance of your application.
If you invalidate just a tiny portion of the screen,
the framework will be smart enough
to avoid drawing anything
that falls outside of this region.
And Skia itself, the rendering engine,
will just ignore all the drawing comments
that are not part of this dirty region.
I actually have a demo that shows you
how it can be using the application.
So here I have the emulator.
And I'm sure you all did this on the home screen.
So when you drag an item around,
it follows your finger.
And the homescreen has to invalidate the screen
to be able to draw the icon
at the new position when you move it.
The first implementation I did of that feature
was invalidating the whole screen
every time you moved the icon.
And the system was not able to follow the finger.
The icon was lagging behind
because it was drawing way too much.
So now, I'm using this invalidate
with a rectangle, and I'll show you exactly
what is redrawn every time.
So now when I drag an icon around,
you can see exactly the portion of the screen
that gets redrawn.
Everything else is just ignored.
And what I just did here--
so if you go to the Dev Tools,
that's part of--
isn't that part of the SDK?
Well, anyway, it's either part of the SDK
or available somewhere.
Yeah, somewhere to be defined.
It's probably in the source code
of the Android system.
Send me e-mails if you can't find it.
So if you click that box, "Show screen updates,"
every time invalidate happens,
you will see it flash in this beautiful pink color.
And it's a really awesome and easy way
to debug your application and make sure
that you're not updating too much on the screen.
So here, for instance, I'm showing you something
that's really bad and drives me nuts every time I see it.
So that's the new search system in Donut
that I demoed yesterday.
And when I click the search widget,
you can see that for some reason
the entire screen is being redrawn.
There's absolutely no reason to do that.
So we have to fix it.
So please do use that feature.
It's pretty awesome.
But let me disable it,
'cause it's also pretty annoying.
There we go.
Now to give you an idea--
so those numbers come actually from the home screen.
When I was using invalidate to redraw the icon
when it was following my-- trying to follow my finger,
I was getting about 18 frames per second.
And now that it's invalidating only the icon,
the new position and the old position,
we get almost 50 frames per second.
the improvements when you do these
can be pretty awesome.
And they highly depend on the number of views
you have in your application.
So the more complex your UI,
the more you will want to use that kind of trick.
Speaking of use--
okay, so that's one of my pet peeves.
From time to time, I go on the market,
I download an application and I look at its layout.
I look at the number of-- number of views it's using.
And very often, I'm really mad at
whoever wrote the application.
We do our best to have a framework
that's fairly solid, that has tons of features,
but that's also pre-performance.
we're still running on mobile phones.
And no matter what we do, we have constraints
in memory, in CPU, in memory bandwidth,
that kind of things.
And the more views you use,
the more views you put in your UI,
the worse the performance will be.
So if you have too many views, the start-up type--
the start-up time of the application
will be a lot longer.
It will take a lot more time to measure
and load the application.
It actually can become really bad
if you imbed several linear layouts that can trigger--
each layout can trigger several layout phases.
So you can end up-- just lay out the screen once.
Instantly, the system might end up
doing the layout 20 or 40 times.
And also, the drawing would be a lot slower.
And some of you may have encountered an issue
if you have way too many views.
If you have way too many layouts in your view hierarchy,
you will even get a StackOverflowException.
Have you guys ever run into this issue,
Yeah, one hand over there. Behind you.
The stack, the default stack size on Android
is currently 8 kilobytes.
That's not much.
So that means in Cupcake, if you have about
14 or 15 embedded view groups or layouts,
you will hit a StackOverflowException.
The system doesn't have enough memory to run the code.
We increased that size in Donut
because we're introducing new features that will--
that could prime your applications.
But the point here is, the more views you use,
the slower the application.
And actually, sometimes it's not that hard
to remove views.
And also, it helps you when you debug.
Like the less views you have,
the easier it will be to debug your UI.
Log in to save your progress and obtain a certificate in Alison’s free Fundamentals of Google Android Development online course
Sign up to save your progress and obtain a certificate in Alison’s free Fundamentals of Google Android Development online course
Please enter you email address and we will mail you a link to reset your password.