【编者按】本文作者为来自南非约翰内斯堡的女程序员 Rebecca Franks，Rebecca 热衷于安卓开发，拥有4年安卓应用开发经验。有点完美主义者，喜爱美食。
本文系国内ITOM管理平台 OneAPM 编译呈现，以下为正文。
Android 程序中很容易出现内存泄露问题。毫无戒心的开发者可能每天都会造成一些内存泄露，却不自知。你可能从未注意过这类错误，或者甚至都不知道它们的存在。直到你遇到下面这样的异常：
java.lang.OutOfMemoryError: Failed to allocate a 4308492 byte allocation with 467872 free bytes and 456KB until OOM
at dalvik.system.VMRuntime.newNonMovableArray(Native Method)
at android.graphics.BitmapFactory.nativeDecodeAsset(Native Method)
at android.graphics.BitmapFactory.decodeStream(BitmapFactory.java:609)
at android.graphics.BitmapFactory.decodeResourceStream(BitmapFactory.java:444)
at android.graphics.drawable.Drawable.createFromResourceStream(Drawable.java:988)
at android.content.res.Resources.loadDrawableForCookie(Resources.java:2580)
at android.content.res.Resources.loadDrawable(Resources.java:2487)
at android.content.res.Resources.getDrawable(Resources.java:814)
at android.content.res.Resources.getDrawable(Resources.java:767)
at com.nostra13.universalimageloader.core.DisplayImageOptions.getImageOnLoading(DisplayImageOptions.java:134)
啥？这是什么意思？是说我的位图(bitmap)太大了吗？
不幸的是，这种堆栈跟踪往往带点迷惑性。通常，如果遇到 OutOfMemoryError 错误，十有八九是因为内存泄露。当笔者第一次遇到这种堆栈跟踪时，也感到迷惑不解，想着是不是位图太大了……实际上，我那会儿真是大错特错。
什么是内存泄露？
内存泄露是指程序释放废弃内存失败，导致性能受损或出现中断。
Android 程序中的内存泄露是如何产生的？
Android 程序中的内存泄露很容易产生，这也是问题的一部分。然而，最大的问题在于 Android [Context]6 对象。
每个 app 都有一个全局的应用上下文对象( getApplicationContext())。每个 Activity (活动)都是 Context 的子类，存储着与当前活动相关的信息。通常，内存泄露都与已泄露的活动(leaked activtiy)相关。
通常，一般的开发者会把上下文对象(context object)传给需要的线程。创建一些静态的 TextViews 以存储指向活动的引用。但是，你懂的，这样可行吗？
在此情况下，如果使用内存监视器就会发现，app 的内存使用率不断增加，正如下面的 Android 内存监控器所示：
存在内存泄露问题的 app 在运行时，Android 内存监控器的情况
解决内存泄露问题后，Android 内存监控器的情况
如你所见，在第一张图中，app 永远都无法回收一部分已经使用的内存。在 OutOfMemoryError 错误出现之前，它一度使用了300MB的内存。而第二张图则显示，app 能顺利进行垃圾回收，重得一部分内存，从而保持相当稳定的内存使用量。
如何避免内存泄露？
- 避免在 activity 或 fragment 之外传递 Context 对象。
- 永远永远不要创建静态的 Context 或 View 对象，或者将二者存储于静态变量中。这是内存泄露的首要标志。
private static TextView textView; //DO NOT DO THIS
private static Context context; //DO NOT DO THIS - 总是记得在 onPause() 或 onDestroy() 方法中的取消注册监听器(listeners)。这包括 Android
监听器，以及位置服务、显示管理器服务，还有自定义的一些监听器。 - 不要在 AsyncTasks(异步任务)或后台线程中存储指向 activities 的强引用。Activity 可能会关闭，但是
AsyncTask 会继续执行，一直保存着对该 activity 的引用。 - 如果可以，使用 Context-application (getApplicationContext())，而不是某个 activity
的 Context 对象。 - 尽力避免使用非静态的内部类。将引用存储至某个 Activity 或 View 内部会导致内存泄露。如果不得不存储引用，请使用
WeakReference。
如何修复内存泄露问题？
修复内存泄露问题需要许多实践，不断尝试、试错，才能取得成功。通常，内存泄露并不容易定位。值得庆幸的是，有许多现成的工具可以帮你找出潜在的泄露问题。
1、打开 Android Studio，打开 Android Monitor(监控器)选项。
2、运行你的应用，从可选应用中进行选择你的应用，并运行之。
3、在 app 中进行一些操作，以达到类似的效果。譬如笔者，打开了一个新视频，播放了50次。（为此，笔者写了一个测试程序。）
4、此处的关键，是在出现 OutOfMemoryException 异常之前捕获应用的问题。
5、点击 Android 监控器中的内存选项。
6、你会看到一张动态绘制的图表。准备好之后，点击“启动垃圾回收(Initiate GC)“（红色的垃圾卡车图标）。
7、点击“倾倒 Java 堆内存(Dump Java Heap)”，之后等待数秒。（卡车图标下面带有绿色箭头的图标）。这会生成一个 .hprof 文件，你可以用来分析内存使用率。
8、不幸的是，Android Studio Hprof 文件查看器不具备 Eclipse 内存分析器的所有小工具。因此，你需要安装 MAT。
9、运行下面的指令，将 Android 的 .hprof 文件转换为 MAT 能够理解的格式。（hprof-conv 工具位于 sdk 的平台工具文件夹下）
./hprof-conv path/file.hprof exitPath/heap-converted.hprof
10、转换完成后，在 MAT 中打开该文件。选择“泄露疑点报告(Leak Suspects Report)”，之后点击完成。 
打开 Eclipse 内存分析器 —— 选择泄露疑点报告
11、点击顶部的三个蓝色柱形图标，“为任意对象集合创建一个直方图”。你会看到占用内存的一列对象。 
Eclipse 内存分析器 — 直方图
12、查看这么多对象或许会让人摸不到头脑。其实，你可以根据类名进行过滤，因此笔者建议你在类名过滤器中输入类名。
查找并修复Android中的内存泄露—OutOfMemoryError 技术分享 第6张根据类名在 Eclipse 内存分析器中过滤对象
13、现在，我们看到 VideoDetailActivity 存在9个实例。这显然是不对的，因为我们其实只需要一个。进一步查看谁保存着 VideoDetailActivity 的引用，右键点击该项目，选择“合并垃圾回收根的最短路径(Merge Paths to Shortest GC Root)”，然后点击“排除所有虚/弱/软引用(exclude all phantom/weak/soft etc. references)。” 
Eclipse 内存分析器——合并垃圾回收根的最短路径
现在，保存着引用的线程就会显示出来。之后，你可以追根溯源，找到存储该 activity 引用的具体实例。
14、根据下面的信息，显然，有一个 DisplayListener 对象在登记之后从未注销过。 
Eclipse 内存分析器 — 内存泄露识别
因此，对这个此前登记的显示监听器(display listener)调用注销方法，就能解决此内存泄露问题。
DisplayManager displayManager = (DisplayManager) mContext.getSystemService(Context.DISPLAY_SERVICE);displayManager.unregisterDisplayListener(listener);
不过，并非所有的内存泄露都这么容易找到，也有一些非常难找。但是，希望本文能使你开始寻找问题根源，并避免潜在的内存泄露问题。此外，还有许多有助于寻找内存泄露问题的工具，点击此处进行查看。
参考链接：
本文转自 OneAPM 官方博客
原文地址：http://riggaroo.co.za/fixing-memory-leaks-in-android-outofmemoryerror/
