today I'm going to talk to you about memory

management for Android.

So I'm really happy to see so many people here who care

about memory management, especially near

the end of the day.

So let's get started.

So I'm sure you all remember this device.

This is the T-Mobile G1.

Hugo talked about it in the keynote yesterday.

It was released about two and a half years ago.

So, is there anybody here who actually developed on the G1?

All right, impressive.

That's about maybe 40% of the room.

So you may remember that the G1 came with 192

megabytes of RAM.

And in fact, most of that was used up by the system.

There wasn't a whole lot left over for apps.

Fast forward a few years later, we have the Motorola

Zoom released just a couple of months ago.

The Zoom comes with a gigabyte of RAM.

Now some people might hear this and think, OK, my

troubles are over.

I never have to worry about memory management again.

And of course, given that we have a whole room here, you

guys are all smart people and you realize

that that's not true.

And there are a couple of reasons for this.

First of all, the Zoom has six and a half times the

resolution that the G1 had.

So you've got six and a half times as

many pixels on screen.

That means you're probably going to

need to use more memory.

You got more bitmaps for example.

The other thing is that on tablets, you really want to

create a new kind of application.

You know, the rich, immersive applications, like this

YouTube app, for example.

These are going to take a lot of memory.

There's tons of bitmaps in here.

Those use up a lot of memory.

Also, the Zoom we're talking about a pretty new device.

This is basically bleeding edge hardware.

Most your customers are not going to be using something

that's only two months old.

So of course, you want to support people who are using

older hardware as well.

Finally, maybe you're all familiar with Parkinson's Law,

which says that work always take as much time as you have.

And really, it's kind of the same for software.

So, no matter how much memory you have, you're going to find

a way to use it and wish you had just a little bit more.

What I want to talk about today are basically two

different things.

First of all, I want to cover some of the changes that we've

made in Gingerbread and Honeycomb that affect how your

app uses memory.

That's your cameo.

All right, so as I was saying, there are two different things

I want to cover today.

So first of all, I want to talk about some of the changes

we've made in Gingerbread and Honeycomb that affect how your

apps use memory.

And basically, memory management in general.

In the second half of the talk I want to talk about some

tools you can use to better understand how your app is

using memory.

And if you have memory leaks, how you can figure out where

those memory leaks are.

So just to set expectations for this talk, I'm going to

make them some assumptions about the stuff you've done

and it'll really help you get the most out of this if you're

familiar with these concepts.

So I'm hoping that you've all written Android apps before.

And it looked like about half the room had developed on the

G1, so that's probably true.

I hope that most of you have heard of the Dalvik heap.

You have a basic idea of what I'm talking about when I talk

about heap memory.

I'm sure you're familiar with the garbage collector.

You have a basic idea hopefully of what garbage

collection is and how it works.

And probably, most of you have seen an OutOfMememoryError

before and you have a basic idea of why you get it and

what you can do to deal with it.

So first, let's talk about heap size.

So you may know that in Android, there's a hard limit

on your application's heap size.

And there's a couple reasons for this.

So first of all, one of the great features of Android is

that it has full multitasking.

So you actually have multiple programs running at once.

And so obviously, each one can't use all of

your devices memory.

We also don't want a runaway app to just start getting

bigger and bigger and bloating the entire system.

You always want your dialer to work, your launcher t work,

that sort of thing.

So there's this hard limit on heap size and if your

application needs to allocate more memory and you've gone up

to that heap size limit already, then you're basically

going to get an out of memory error.

So this heap size limit is device dependent.

It's changed a lot over the years.

On the G1 it was 16 megabytes.

On the Zoom it's now 48 megabytes.

So it's a little bit bigger.

If you're writing an app and you want to know, OK, how much

heap space do I have available?

You know, maybe you want to decide how much stuff to keep

in a cache for example.

There's a method you can use in ActivityManager,

getMemoryClass that will return an integer value in

megabytes, which is your heap size.

Now these limits were designed assuming that you know almost

any app that you would want to build on Android should be

able to fit under these limits.

Of course, there are some apps that are

really memory intensive.

And as I said, on the tablet, we really want to build almost

a new class of application.

It's quite a different than the kind of things you were

building on phones.

So we thought, if someone wants to build an image

editor, for example, on the Zoom, they should

be able to do that.

But an image editor's a really memory intensive application.

It's unlikely that you could build a good one that used

less than 48 megabytes of heap.

So in Honeycomb we've added a new option that allows

applications like this to get a larger heap size.

Basically, , you can put something in your

AndroidManifest, largeHeap equals true.

And that will allow your application to use more heap.

And similarly, there's a method you can use to

determine how much memory you have available to you.

The ActivityManager getLargeMemoryClass method

again, will return an integer value of this large heap size.

Now before we go any further, I want to give

a big warning here.

You know, this is not something you should be doing

just because you got an out of memory error, or you think

that your app deserves a bigger heap.

You're not going to be doing yourself any favors because

your app is going to perform more poorly because bigger

heap means you're going to spend more time at garbage

collection.

Also, your users are probably going to notice because all

their other apps are getting kicked out of memory.

It's really something you want to reserve for when you really

understand OK, I'm using tons of memory and I know exactly

why I'm using that memory, and I really

need to use that memory.

That's the only time that you should be using this large

heap option.

So I mentioned garbage collection.

And that it takes longer when you have a bigger heap.

Let's talk a little bit about garbage collection.

So I just want to go through a quick explanation here of what

[INAUDIBLE]

garbage collection is doing.

So basically, you have a set of objects.

First of all, let's say these blue objects here, these are

the objects in your heap.

And they form a kind of graph.

They've got references to each other.

Some of those objects are alive, some of them are not

used anymore.

So what the GC does is it starts from a set of objects

that we call the roots.

These are the objects that the GC knows is alive.

For example, variables that are alive on a thread stack, J

and I global references, we treat objects in the zygote as

heap, or as roots as well.

So basically, the GC starts with those objects and starts

visiting the other objects.

And basically, traversing through the whole graph to

find out which objects are referenced directly or

indirectly from the GC roots.

At the end of this process, you've got some objects left

over, which the GC never visited.

Those are your garbage.

They can be collected.

So it's a pretty simple concept.

And you can see why when I said that you have bigger

heaps you're going to have larger pause times.

Because the garbage collector basically has to traverse your

entire live set of objects.

If you're using say the large heap option and you've got 256

megs of heap, well, that's a lot of memory for the garbage

collector to walk over.

You're going to see longer pause times with that.

We have some good news though.

In Gingerbread, there have been some great changes to the

garbage collector that make things a lot better.

So in Gingerbre--

sorry, pre-Gingerbread, the state of the garbage collector

was that we had to stop the world collector.

So what this means is that basically, when a garbage

collection is in progress, your application is stopped.

All your application threads are completely stopped while

the collection is proceeding.

This is a pretty standard things.

These pauses generally tend to be pretty short.

What we found was that pause times as heaps were getting

bigger, these were getting to be a little bit too long.

So we were seeing stuff up 50 to 100 milliseconds.

And if you're trying to build a really responsive app that

kind of pause time is not really acceptable.

So in Gingerbread, we now have a

concurrent garbage collector.

It does most of its work concurrently, which means that

your application is not stopped for the duration of

the garbage collection.

Basically, we have another thread that's running at the

same time as your application that can perform garbage

collection work.

You'll see basically two short pauses.

One at the beginning of a collection and

one near the end.

But these pause times are going to be much, much lower.

Usually you'll see two, three, four, or five milliseconds for

your pause time.

So that's a significant improvement.

Pause times about 10% of what they used to be.

So that's a really good change that we have in Gingerbread.

Now if you're building memory heavy apps, there's a good

chance you're using a lot of bitmaps.

We found that in a lot of apps you have maybe 50 or 75% of

your heap is taken up by bitmaps.

And in Honeycomb because you're going to be developing

on tablets, this gets even worse.

Because your images are bigger to fill the screen.

So before Honeycomb, the way we managed bitmaps was this.

So the blue area up here is the Dalvik heap and this

yellow object is a bitmap object.

Now bitmap objects are always the same size in the heap no

matter what their resolution is.

The backing memory for the bitmap is actually stored in

another object.