开发者社区> 玄学酱> 正文

Android内存泄漏产生的6大原因

简介:
+关注继续查看

1.资源对象没关闭造成的内存泄漏

描述:

资源性对象比如(Cursor,File文件等)往往都用了一些缓冲,我们在不使用的时候,应该及时关闭它们,以便它们的缓冲及时回收内存。它们的缓冲不仅存在于 java虚拟机内,还存在于java虚拟机外。如果我们仅仅是把它的引用设置为null,而不关闭它们,往往会造成内存泄漏。因为有些资源性对象,比如 SQLiteCursor(在析构函数finalize(),如果我们没有关闭它,它自己会调close()关闭),如果我们没有关闭它,系统在回收它时也会关闭它,但是这样的效率太低了。因此对于资源性对象在不使用的时候,应该调用它的close()函数,将其关闭掉,然后才置为null.在我们的程序退出时一定要确保我们的资源性对象已经关闭。

程序中经常会进行查询数据库的操作,但是经常会有使用完毕Cursor后没有关闭的情况。如果我们的查询结果集比较小,对内存的消耗不容易被发现,只有在常时间大量操作的情况下才会复现内存问题,这样就会给以后的测试和问题排查带来困难和风险。

示例代码:


  1. Cursor cursor = getContentResolver().query(uri...);  
  2.  
  3. if (cursor.moveToNext()) {  
  4.  
  5. ... ...  
  6.  
  7.  

修正示例代码:


  1. Cursor cursor = null;  
  2.  
  3. try {  
  4.  
  5. cursor = getContentResolver().query(uri...);  
  6.  
  7. if (cursor != null &&cursor.moveToNext()) {  
  8.  
  9. ... ...  
  10.  
  11. }  
  12.  
  13. } finally {  
  14.  
  15. if (cursor != null) {  
  16.  
  17. try {  
  18.  
  19. cursor.close();  
  20.  
  21. } catch (Exception e) {  
  22.  
  23. //ignore this  
  24.  
  25. }  
  26.  
  27. }  
  28.  
  29.  

2.构造Adapter时,没有使用缓存的convertView

描述:

以构造ListView的BaseAdapter为例,在BaseAdapter中提供了方法:

public View getView(int position, ViewconvertView, ViewGroup parent)

来向ListView提供每一个item所需要的view对象。初始时ListView会从BaseAdapter中根据当前的屏幕布局实例化一定数量的 view对象,同时ListView会将这些view对象缓存起来。当向上滚动ListView时,原先位于最上面的list item的view对象会被回收,然后被用来构造新出现的最下面的list item。这个构造过程就是由getView()方法完成的,getView()的第二个形参View convertView就是被缓存起来的list item的view对象(初始化时缓存中没有view对象则convertView是null)。由此可以看出,如果我们不去使用 convertView,而是每次都在getView()中重新实例化一个View对象的话,即浪费资源也浪费时间,也会使得内存占用越来越大。 ListView回收list item的view对象的过程可以查看:

android.widget.AbsListView.java –> voidaddScrapView(View scrap) 方法。

示例代码:


  1. public View getView(int position, ViewconvertView, ViewGroup parent) {  
  2.  
  3. View view = new Xxx(...);  
  4.  
  5. ... ...  
  6.  
  7. return view;  
  8.  
  9.  

修正示例代码:


  1. public View getView(int position, ViewconvertView, ViewGroup parent) {  
  2.  
  3. View view = null;  
  4.  
  5. if (convertView != null) {  
  6.  
  7. view = convertView;  
  8.  
  9. populate(view, getItem(position));  
  10.  
  11. ...  
  12.  
  13. else {  
  14.  
  15. view = new Xxx(...);  
  16.  
  17. ...  
  18.  
  19. }  
  20.  
  21. return view;  
  22.  
  23.  

3.Bitmap对象不在使用时调用recycle()释放内存

描述:

有时我们会手工的操作Bitmap对象,如果一个Bitmap对象比较占内存,当它不在被使用的时候,可以调用Bitmap.recycle()方法回收此对象的像素所占用的内存,但这不是必须的,视情况而定。可以看一下代码中的注释:


  1. /**  
  2.  
  3. Free up the memory associated with thisbitmap's pixels, and mark the  
  4.  
  5. •bitmap as "dead", meaning itwill throw an exception if getPixels() or  
  6.  
  7. •setPixels() is called, and will drawnothing. This operation cannot be  
  8.  
  9. •reversed, so it should only be called ifyou are sure there are no  
  10.  
  11. •further uses for the bitmap. This is anadvanced call, and normally need  
  12.  
  13. not be called, since the normal GCprocess will free up this memory when  
  14.  
  15. •there are no more references to thisbitmap.  
  16.  
  17. */  

4.试着使用关于application的context来替代和activity相关的context

这是一个很隐晦的内存泄漏的情况。有一种简单的方法来避免context相关的内存泄漏。最显著地一个是避免context逃出他自己的范围之外。使用Application context。这个context的生存周期和你的应用的生存周期一样长,而不是取决于activity的生存周期。如果你想保持一个长期生存的对象,并且这个对象需要一个context,记得使用application对象。你可以通过调用 Context.getApplicationContext() or Activity.getApplication()来获得。更多的请看这篇文章如何避免

5.注册没取消造成的内存泄漏

一些Android程序可能引用我们的Anroid程序的对象(比如注册机制)。即使我们的Android程序已经结束了,但是别的引用程序仍然还有对我们的Android程序的某个对象的引用,泄漏的内存依然不能被垃圾回收。调用registerReceiver后未调用unregisterReceiver。

比如:假设我们希望在锁屏界面(LockScreen)中,监听系统中的电话服务以获取一些信息(如信号强度等),则可以在LockScreen中定义一个 PhoneStateListener的对象,同时将它注册到TelephonyManager服务中。对于LockScreen对象,当需要显示锁屏界面的时候就会创建一个LockScreen对象,而当锁屏界面消失的时候LockScreen对象就会被释放掉。

但是如果在释放 LockScreen对象的时候忘记取消我们之前注册的PhoneStateListener对象,则会导致LockScreen无法被垃圾回收。如果不断的使锁屏界面显示和消失,则最终会由于大量的LockScreen对象没有办法被回收而引起OutOfMemory,使得system_process 进程挂掉。

虽然有些系统程序,它本身好像是可以自动取消注册的(当然不及时),但是我们还是应该在我们的程序中明确的取消注册,程序结束时应该把所有的注册都取消掉。

6.集合中对象没清理造成的内存泄漏

我们通常把一些对象的引用加入到了集合中,当我们不需要该对象时,并没有把它的引用从集合中清理掉,这样这个集合就会越来越大。如果这个集合是static的话,那情况就更严重了。





本文作者:佚名
来源:51CTO

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
UWP开发入门(十六)——常见的内存泄漏的原因
原文:UWP开发入门(十六)——常见的内存泄漏的原因   本篇借鉴了同事翔哥的劳动成果,在巨人的肩膀上把稿子又念了一遍。   内存泄漏的概念我这里就不说了,之前《UWP开发入门(十三)——用Diagnostic Tool检查内存泄漏》中提到过,即使有垃圾回收机制,写C#还是有可能发生内存泄漏。
1214 0
android bitmap的内存分配和优化
首先Bitmap在Android虚拟机中的内存分配,在Google的网站上给出了下面的一段话  大致的意思也就是说,在Android3.0之前,Bitmap的内存分配分为两部分,一部分是分配在Dalvik的VM堆中,而像素数据的内存是分配在Native堆中,而到了Android3.0之后,Bitmap的内存则已经全部分配在VM堆上,这两种分配方式的区别在于,Native堆的内存不受Dal
1596 0
使用新版Android Studio检测内存泄露和性能
内存泄露,是Android开发者最头疼的事。可能一处小小的内存泄露,都可能是毁于千里之堤的蚁穴。 怎么才能检测内存泄露呢?网上教程非常多,不过很多都是使用Eclipse检测的, 其实1.3版本以后的Android Studio 检测内存非常方便, 如果结合上MAT工具,LeakCanary插件,一切就变得so easy了。 熟悉Android Studio界面 工欲
1307 0
mqc
专项:Android 内存泄露实践分析
内存泄漏也称作“存储渗漏”,用动态存储分配函数动态开辟的空间,在使用完毕后未释放,结果导致一直占据该内存单元。直到程序结束。(其实说白了就是该内存空间使用完毕之后未回收)即所谓内存泄漏。   内存泄漏形象的比喻是“操作系统可提供给所有进程的存储空间正在被某个进程榨干”,最终结果是程序运行时间越长,占用存储空间越来越多,最终用尽全部存储空间,整个系统崩溃。
4651 0
react-native run-android报错的原因,license问题
react-native run-android报错的原因,license问题
15 0
只需4个步骤,分析解决在生产环境下JVM内存泄露问题
只需4个步骤,分析解决在生产环境下JVM内存泄露问题
4874 0
+关注
玄学酱
这个时候,玄酱是不是应该说点什么...
20709
文章
438
问答
文章排行榜
最热
最新
相关电子书
更多
OceanBase 入门到实战教程
立即下载
阿里云图数据库GDB,加速开启“图智”未来.ppt
立即下载
实时数仓Hologres技术实战一本通2.0版(下)
立即下载