I guess we don't have to worry now :)
Now let's talk about backgrounds and images.
Yeah, "Don't be greedy."
when you set background drawable on the view,
you can set the background drawable as a--
you can pass a drawable instance that you created yourself.
You can set a resource
that comes from your drawable directory,
or you can pass a bitmap or color.
The background will always fill the view.
That is, it will be as large as your view.
Where it can become a problem
is when you use something like a bitmap.
So if you have a background
that comes from a bitmap resource, that's--
that bitmap will be stretched to be as big as the view.
Or as small as the view.
And the problem here is that scaling a bitmap
at runtime is very expensive.
One of the reasons for this is that we always turn on--
the bilinear filtering by default,
which--you know, which makes stretching even slower,
but it looks better.
And also because Skia, a rendering engine,
is currently only implemented in software.
So we don't have hardware acceleration
that kind of operation.
So to avoid this, make sure--
So to avoid this,
make sure that you pre-scale your bitmaps.
If you know that the resource you have will be stretched,
because the view that you're gonna--
on which you're gonna use it as a background drawable
will be bigger than the bitmap, or even smaller,
do the pre-scaling first.
Pre-scale the bitmap and then set it as a background.
And here, I have a simple example.
I just set--
so the image was 640 x 480 pixels large.
And I set it as the background of my activity.
And then I was drawing the application
as fast as I could.
So with the different version
that was scaling the bitmap at runtime,
I can get 25 frames per second.
By doing the scaling first and then setting
the result of the scaling on the activity background,
I get 50 frames per second.
So you can double your frame rate
if you use bitmaps correctly.
And pre-scaling bitmaps is actually really easy.
If you have a handle on the bitmap object,
you can actually extract it from a bitmap drawable.
If you want to, there's a GetBitmap method.
You can use the method of the bitmap class
where you pass the original bitmap--
you pass the widths and the heights
of the target size.
So most often,
you will pass the width and the height of the view.
And the last--the last--
the last parameter should probably always be set to true.
The bilinear filtering I was talking about,
because it's a bit slower, but it makes--
it gives you better results.
By default, all activities are in a window.
And all windows have a default background.
So the default background currently on the T-Mobile G1,
or on the device that you got at Google I/O,
is just simple color drawables.
We just fill the screen with a single color.
And in some cases,
we don't really need to have the background.
For instance, if you are writing a maps application
and you have a map view that fills the entire screen,
that map view is opaque.
Like you will never see the background of the window
that's behind the map view.
Unfortunately, the UI toolkit
is really stupid in that situation.
And every time it has to refresh the map view,
it will still redraw the background of the window
even though you don't see it.
Again, totally my fault.
So--ahem--you can be mad at me for that.
And actually, it's pretty expensive
to draw the window background.
The fastest background you can draw
is a simple color.
Like it's a solid color.
So this is the default background we have.
And on the T-Mobile G1 one,
because of the limitation of the memory bus,
it takes about 3 to 4 milliseconds
to draw that background.
Which means that if you're trying
to animate something onscreen
at 60 frames per second, you're really 4 milliseconds
out of the 60 milliseconds you have per frame
to be able to achieve that frame rate.
So a quarter of your allocated time
is already going into something
that's totally useless for you.
So when you have an application
in which you have a view that fills the screen
that covers the entire window background,
you can get rid of the window background.
And the best way to do this
is to create a new theme for your activity.
So in the--
You just have to create the style--
the XML file in the values directory of your application.
And this the exact syntax to create a new theme.
The theme can be called-- can have any name you want.
Here I chose the name "Theme.NoBackground."
And we inherit from the default theme in Android
And the only item that we have here
is a style for the default window background.
And we use the special syntax @null to indicate
that we don't want any background on our view--
on our window.
Once you have your theme defined in XML, in your resources,
you can simply apply it to your activity
with the simple attribute android:Theme,
and then the syntax is @style--
and actually, there is a typo in my slide.
It's no--it's not NoBackgroundTheme.
So the name is Theme.NoBackground,
and here the theme should be Theme.NoBackground.
And by doing that you will effectively get rid
of the background on your window.
And you will get a better frame rate.
So here we have the version of the application
with the background.
So we have about 43, 44 frames per second.
And without the background,
we get up to 50-something frames per second.
So it will highly depend on the device you're running on
'cause it's mostly bound by the memory bus.
But you can be-- you're guaranteed that
you're gonna get a few frames per second back.
So if you're writing a game, especially,
or a maps application or GPS application,
something that will refresh the entire screen very often,
remember to use that trick.
Okay, and some good news.
I just told you that the framework is really stupid
because it draws that window background
even though it doesn't need to.
As of three weeks ago,
the framework is not doing that anymore.
It's finally a little smarter.
And that would be part of the Donut release.
So in the next version of Android,
you won't have to worry about that.
users are still running Android 1.1
and they're starting to get 1.5 on their devices.
So please apply that tip.
And also if you keep using that trick
in Android-- on Donut, it will--
your application will still run pretty fast.
It will actually even--
it will be even better than what the framework does
because you won't keep the background in memory
and you will save a little memory.
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.