Android应用程序限制使用的堆内存是16M(注:堆内存与设备的性能也有一定关系,性能高的设备可用堆内存可能是24M或者更高),其中电话功能会占用一部分,而开发者能够使用的则非常有限。如果你不打算用完所有内存,那么你的应用就应该尽可能少用内存,从而使其他的程序在运行时不致于被杀掉。Android系统在内存中能够持有的应用程序越多,用户在程序间进行切换时就越快。作为工作的一部分,我研究Android应用中的内存泄露问题,结果发现多数情况是同一个问题引起的:对Context持有一个过长的引用。 在Android中,Context被用在许多操作中,但多数是为了加载或访问资源。这就是为什么所有的Widget组件都会在构造器中接收一个Context参数的原因所在。对于一般的Android应用,通常有两种Context,即Activity和Application。开发者通常需要context在类或方法间传递时会选择Activity。 这表明Views对整个Activity有一个引用,因此你的Activity中任何东西都会被(Views)持有,一般被持有的是视图层级和它对应的资源。因此,如果你泄露了Context(泄露:即你持有一个Context引用,结果阻止GC对其进行回收),你就泄露了一些内存。如果你不细心,泄露一个Activity就会变得非常容易。 当屏幕方向改变,系统默认会保存它的状态,销毁当前Activity并重新创建一个。为了做到这一点,Android会从资源中重新加载应用程序的UI。现在假设你开发一个应用,包含了大量位图(Bitmap),你不想每次屏幕切换时都去加载位图。那么最简单的方法是利用static静态域。 上面的代码非常简洁,但也容易出错:第一次屏幕方向改变时,最初创建的Activity(每次屏幕改变都会重新创建Activity)就会出现内存泄漏。当一个Drawable对象被附着到View中,View就会在这个Drawable上被设定作为回调callback。上面的代码片段表明drawable对TextView有一个引用,而TextView本身又对Activity(即Context)持有引用,反过来,Activity又对许多东西持有引用(这取决于你的代码)。 上面的例子是泄露Context最简单的一种情况,你能在Home screen的源代码(查找unbindDrawables()方法)中看到我们是怎么解决它的:当Activity被销毁时,设置被存储的drawable的回调为null。有趣的是,你创建一系列内存泄露的Context会出现许多情况,并且它们都是糟糕的。它们很快使你在运行过程时出现内存溢出。 有两种简单的方式去避免Context相关的内存泄露。最明显的一种就是避免Context超出它的范围。上面的例子展现了静态引用的情况:内部类以及对外部类的间接引用是很危险的。第二种方案是用Application。这种Context不依赖于Activity的生命周期,而是与你的应用程序同生共死。如果你打算持有一个长期活动并且需要Context引用的对象,记得使用Application对象。你可以通过调用Context.getApplicationContext() 或者 Activity.getApplication()方法得到它。 总的来说,要避免Context相关的内存泄露,铭记以下几条: •不要对Activity(Activity继承自Context)作长期的引用(一个指向Activity的引用与Activity本身有相同的生命周期); •试着用Application代替Activity; •如果你不能控制内部类的生命周期,避免使用非静态内部类,应该用静态内部类,并且对里面的Activity作弱引用。该问题的解决方法是:对于外部类,用WeakReference构造静态内部类,同时要在视图根完成,并且它的WeakReference内部类要有一个实例(WeakReference)。 •垃圾回收不是防止内存泄露的保险方式. 转自:http://blog.csdn.net/snow4dev/article/details/7555130 原文链接:Avoiding memory leaks 博客推荐文章 守护进程内存泄露检测方法 (2012-01-16 14:00:48) Javascript内存泄露 (2012-05-08 15:46:53) OpenCV内存泄露的检测 (2012-04-09 09:19:19) android内存泄露优化总结 (2012-03-25 19:40:08) JNI内存泄露 (2012-05-20 00:52:22)