Avoid memory leaks on Android

Android applications are, at least on the T-Mobile G1, limited to 16 MB of heap. It’s both a lot of memory for a phone and yet very little for what some developers want to achieve. Even if you do not plan on using all of this memory, you should use as little as possible to let other applications run without getting them killed. The more applications Android can keep in memory, the faster it will be for the user to switch between his apps. As part of my job, I ran into memory leaks issues in Android applications and they are most of the time due to the same mistake: keeping a long-lived reference to a Context.

On Android, a Context is used for many operations but mostly to load and access resources. This is why all the widgets receive a Context parameter in their constructor. In a regular Android application, you usually have two kinds of ContextActivity and Application. It’s usually the first one that the developer passes to classes and methods that need a Context:

@Override
protected void onCreate(Bundle state) {
  super.onCreate(state);

  TextView label = new TextView(this);
  label.setText("Leaks are bad");

  setContentView(label);
}

This means that views have a reference to the entire activity and therefore to anything your activity is holding onto; usually the entire View hierarchy and all its resources. Therefore, if you leak the Context (“leak” meaning you keep a reference to it thus preventing the GC from collecting it), you leak a lot of memory. Leaking an entire activity can be really easy if you’re not careful.

When the screen orientation changes the system will, by default, destroy the current activity and create a new one while preserving its state. In doing so, Android will reload the application’s UI from the resources. Now imagine you wrote an application with a large bitmap that you don’t want to load on every rotation. The easiest way to keep it around and not having to reload it on every rotation is to keep in a static field:

private static Drawable sBackground;

@Override
protected void onCreate(Bundle state) {
  super.onCreate(state);

  TextView label = new TextView(this);
  label.setText("Leaks are bad");

  if (sBackground == null) {
    sBackground = getDrawable(R.drawable.large_bitmap);
  }
  label.setBackgroundDrawable(sBackground);

  setContentView(label);
}

This code is very fast and also very wrong; it leaks the first activity created upon the first screen orientation change. When a Drawable is attached to a view, the view is set as a callback on the drawable. In the code snippet above, this means the drawable has a reference to the TextView which itself has a reference to the activity (the Context) which in turns has references to pretty much anything (depending on your code.)

This example is one of the simplest cases of leaking the Context and you can see how we worked around it in theHome screen’s source code (look for the unbindDrawables() method) by setting the stored drawables’ callbacks to null when the activity is destroyed. Interestingly enough, there are cases where you can create a chain of leaked contexts. I can’t remember an exact case right now, but I have fixed a couple of those, and they are bad. They make you run out of memory rather quickly.

There are two easy ways to avoid context-related memory leaks. The most obvious one is to avoid escaping the context outside of its own scope. The example above showed the case of a static reference but inner classes and their implicit reference to the outer class can be equally dangerous. The second solution is to use the Applicationcontext. This context will live as long as your application is alive and does not depend on the activities life cycle. If you plan on keeping long-lived objects that need a context, remember the application object. You can obtain it easily by calling Context.getApplicationContext() or Activity.getApplication().

In summary, to avoid context-related memory leaks, remember the following:

  • Do not keep long-lived references to a context-activity (a reference to an activity should have the same life cycle as the activity itself)
  • Try using the context-application instead of a context-activity
  • Avoid non-static inner classes in an activity if you don’t control their life cycle, use a static inner class and make a weak reference to the activity inside

And remember that a garbage collector is not an insurance against memory leaks. Last but not least, we try to make such leaks harder to make happen whenever we can.

原文地址:http://www.curious-creature.com/2008/12/18/avoid-memory-leaks-on-android/comment-page-1/

时间: 2024-11-10 11:18:46

Avoid memory leaks on Android的相关文章

On Memory Leaks in Java and in Android.

from:http://chaosinmotion.com/blog/?p=696 Just because it's a garbage collected language doesn't mean you can't leak memory or run out of it. Especially on Android where you get so little to begin with. Now of course sometimes the answer is that you

How to detect and avoid memory and resources leaks in .NET applications

Despite what a lot of people believe, it's easy to introduce memory and resources leaks in .NET applications. The Garbage Collector, or GC for close friends, is not a magician who would completely relieve you from taking care of your memory and resou

Android性能优化之被忽视的Memory Leaks

起因 写博客就像讲故事,得有起因,经过,结果,人物,地点和时间.今天就容我给大家讲一个故事.人物呢,肯定是我了.故事则发生在最近的这两天,地点在coder君上班的公司.那天无意中我发现了一个奇怪的现象,随着我点开我们App的页面,Memory Monitor中显示占用的内存越来越多(前面的页面已经finish掉了).咦?什么鬼? 经过 有了问题就解决嘛,俗话说的好,有bug要上,没有bug写个bug也要上.那到底是是什么问题会引起这个现象呢? Android中内存相关的问题无非就是这么几点: M

内存泄露 Memory Leaks 内存优化【总结】

什么是内存泄露 内存管理一直是Java 所鼓吹的强大优点.开发者只需要简单地创建对象,而Java的垃圾收集器将会自动管理内存空间的分配和释放. 但在很多情况下,事情并不那么简单,在 Java程序中总是会频繁地发生内存泄露(Memory Leaks). 内存泄漏就是:当某些对象不再被应用程序所使用,但是由于仍然被引用而导致垃圾收集器不能释放他们. 或者说是:我们对某一内存空间使用完成后没有释放. 用白话来说就是:该回收的内存没被回收. 要理解这个定义,我们需要理解内存中的对象状态.下图展示了什么是

[转]Activitys, Threads, & Memory Leaks

转自:http://www.androiddesignpatterns.com/2013/04/activitys-threads-memory-leaks.html http://www.cnblogs.com/kissazi2/p/4125356.html A common difficulty in Android programming is coordinating long-running tasks over the Activity lifecycle and avoiding

Identify Memory Leaks in Visual CPP Applications(VLD内存泄漏检测工具)

原文地址:http://www.codeproject.com/Articles/1045847/Identify-Memory-Leaks-in-Visual-CPP-Applications 基于CPOL License Identify Memory Leaks in Visual CPP Applications Visual Leak Detector (VLD) is an easy to use memory leak detection system. The installat

解决:Detected memory leaks

最近在一个项目中,程序退出后都出现内存泄漏: Detected memory leaks!Dumping objects ->{171} normal block at 0x05785AD0, 12 bytes long.Data: << N       N x 7 > 3C AC 4E 10 00 00 00 00 BC A4 4E 10 78 B6 37 00Object dump complete. 解决方法: 1.在程序中的尽可能靠近启动代码的地方(足够前的地方,只要在泄漏

xcode里面使用Memory Leaks和Instruments检测内存泄漏

教程截图: Leaks和Instruments教程[检测内存泄露]" src="http://pic002.cnblogs.com/images/2011/283130/2011080816513182.jpg"> 作为一名无证程序员,无论你多么精通Objective-C的内存管理,随着时间的推移,你也不可避免的犯内存相关的错误.但通常因为代码量太大,以至于你不可能一行一行的去排除(等你解决完,你设计的动车早相撞了!) 幸运的是,苹果已经提供了一些好的方式来帮助你找到应

[C++] How to prevent memory leaks

How to prevent memory leaks ? overload new/delete