字幕列表 影片播放 列印英文字幕 PATRICK DUBROY: Hi everybody, my name's Patrick Dubroy and 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.