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.