【编者按】本文作者为来自南非约翰内斯堡的女程序员 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 Context (上下文) 对象。
每个 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、查看这么多对象或许会让人摸不到头脑。其实,你可以根据类名进行过滤,因此笔者建议你在类名过滤器中输入类名。
根据类名在 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);
不过,并非所有的内存泄露都这么容易找到,也有一些非常难找。但是,希望本文能使你开始寻找问题根源,并避免潜在的内存泄露问题。此外,还有许多有助于寻找内存泄露问题的工具,点击 此处 进行查看。
参考链接:
内存分析器
堆内存查看器介绍
内存监控器
在 Android 中避免内存泄露
OneAPM Mobile Insight 以真实用户体验为度量标准进行Crash 分析,监控网络请求及网络错误,提升用户留存。访问OneAPM 官方网站感受更多应用性能优化体验,想阅读更多技术文章,请访问OneAPM 官方技术博客。
原文地址: http://riggaroo.co.za/fixing-memory-leaks-in-android-outofmemoryerror/