OK! Very Good
And finally, memory allocation.
So I think the title of this slide says it all.
Like, just don't use memory.
Sometimes it's difficult to reduce your allocations.
And we have a couple of-- of nice tools to, uh,
to help you, you know,
remove allocation from your application.
And the reason why I'm saying this:
it's because our current garbage collector
is, uh, I would say done.
Uh, but it works.
It's still good.
The problem is whenever the garbage collector kicks in,
it will stop all your threads.
It will interrupt your UI while it's garbage collecting.
And garbage collection can take
between about 100 milliseconds to 500 milliseconds.
That's a lot of time during which
your UI cannot do anything.
That's a lot of time during which
the user cannot do anything.
So if you ever wrote a list view
and you're allocating, uh, memory in the getView method,
you may have noticed that when you scroll through the list,
sometimes you see these little stutters.
And that's because the garbage collector is kicking in.
Uh, you can allocate memory in some places.
Those are the methods when you write UIs
where you don't want to allocate memory.
Or as little as you can.
So when you're doing measurements, layout,
whenever you're drawing something,
like, do not create a new paint
every time you draw a view.
Like, just create a paint once and reuse it.
Uh, event--events handling,
uh, those are ver-- can be very expensive,
and you really, really want to avoid allocating memory.
To give you an idea, the framework can send you
up to, like, 80 or 90 TouchEvents per second.
So if you start allocating memory,
the garbage collector will kick in really fast.
And the adapters.
So when you-- when you scroll the list view,
you really don't want the garbage collector
to do its job.
So one of the tools that we have to help you
remove allocations from your application
is a-- is a cool API in the class
You can set the limit of the numbers
of allocation-- of allocations that you want
to have in the specific piece of code.
So let's say you decided that you want to have--
you were writing a game, and you want
to have zero allocation in your drawing code.
What you can do is put that code in your application,
and if--if there are allocations
that exceed the limit that you specified,
in that case zero,
then an exception will be thrown
and, uh, you will fail fast.
You will get the next stack trace
that shows you where the, uh, the allocation happened.
Another cool tool you can use--
uh, I don't think it shows up
in the Eclipse version of DDMS--
but in the SDK, you can launch the application
And in that application, there is a tab
called "allocation tracker."
So you click on that tab.
You click on the--on the process you want to inspect.
For instance, the home screen.
Uh--oops, forgot one step.
So the home screen, you click "stop tracking."
You go back to your device, or your emulator--emulator.
And you start doing stuff.
Uh, so I'm using the application.
Uh, then I go back to DDMS.
I click "get allocation."
Then I get a list of all the allocations
that the application did, uh, during that time frame.
So I can see that, uh,
residents have been allocated.
We created, for some reason, a text view,
'cause apparently we created dialogue.
So you really can see every single allocation.
Even better, if you find an allocation
that seems suspicious, you can click on it
and it will give you the full stack trace
for that allocation.
So you can see what caused the allocation.
That's a very, very nice tool.
And I used it recently, for instance, in Donut.
I discovered that-- I think it's in Cupcake--
if you, uh, long-press an empty screen on the home screen,
it allocates 600 rectangles.
There's a good--there's actually a good reason for that,
but, uh, I optimized it.
So it's--it's-- it is an awesome tool.
And you should definitely use it.
Uh, finally, uh, be better at managing your memory.
So how many of you are aware of what those things are?
There are some good Java developers in the room.
So I'll be really quick,
'cause we don't have much time left.
But SoftReferences are a special type of reference
in Java that can be collected
by the garbage collector when the only reference--okay.
Let's start over again.
A soft reference is a wrapper for an object.
If all the references to that object
are soft references,
and if the garbage collector needs more memory,
it will first collect the soft references.
So soft references are awesome to create a cache.
Let's say I want to keep a lot of bitmaps and memory
but I don't want to run out of memory
because I keep those bitmaps in memory.
I can put all those bitmaps in soft references,
and whenever the system needs memory,
I know that those bitmaps will go away first.
That means that those objects can disappear at any time.
And I'll show you how you can handle that.
WeakReferences are-- are very different.
So they're still wrappers for objects.
And if all the references to an object
are weak references, then the object
will automatically be garbage collected.
I have--I wrote an article on the Android blog about it.
So I will refer you to that.
It's an awesome way to avoid memory leaks.
So here is, for instance, how you would write
a simple memory cache using soft references.
So you can put objects in the cache.
Each object is identified by a key.
And so we have a HashMap of strings
to soft references.
So in the PUT method,
when we put something in the HashMap,
we just wrap the value that we're given
with a soft reference.
And then when we want to get value out of the cache,
we retrieve the soft reference from the HashMap.
And we have to check the--
we have to call the method "get" on the--on the reference.
"Get" will get you the value
that you put in the soft reference.
But that value can be null.
It can become null at any time
because the garbage collector needed memory.
So you have to do that extra check.
You have to verify whether or not
your object is stealing memory.
If it is, you can just use it.
If it's not, you have to put it back in the cache.
We have several examples of that in various applications.
So you should go to
We have a bunch of open source applications that we wrote,
and I think at least a couple of them
use soft references for memory caches.
You can--and those are, you know,
standard Java classes.
So there are tons of articles on the web
about soft references and weak references.
So go to google.com and find articles.
And we don't have time to talk about this.
So here are some pointers if you want to learn more
about everything I've talked about today.
Go to d.android.com.
It's the developer website where you'll have access
to the SDK, the blog, the documentation.
source.android.com if you want to know how
to get the source code of Android.
It's very interesting to look at our source code.
See how we do things.
And if you want to learn how to use RelativeLayout,
go read the source code.
And the last two links are pointers
to an open source project that we wrote
that show how to write good UI code.
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.