• 博客园
  • 首页
  • 新随笔
  • 联系
  • 管理
  • 订阅
随笔- 137  文章- 6  评论- 145 

关于Android 的内存泄露及分析

一、 Android的内存机制
Android的程序由Java语言编写,所以Android的内存管理与Java的内存管理相似。程序员通过new为对象分配内存,所有对象在java堆内分配空间;然而对象的释放是由垃圾回收器来完成的.
那么GC怎么能够确认某一个对象是不是已经被废弃了呢?Java采用了有向图的原理。Java将引用关系考虑为图的有向边,有向边从引用者指向引用对象。线程对象可以作为有向图的起始顶点,该图就是从起始顶点开始的一棵树,根顶点可以到达的对象都是有效对象,GC不会回收这些对象。如果某个对象 (连通子图)与这个根顶点不可达(注意,该图为有向图),那么我们认为这个(这些)对象不再被引用,可以被GC回收。

二、Android的内存溢出

1、内存泄露导致

由于我们程序的失误,长期保持某些资源(如Context)的引用,造成内存泄露,资源造成得不到释放。

Android 中常见就是Activity 被引用没有在调用finish之后却没有释放,第二次打开activity 又重新创建,这样的内存泄露则会导致内存的溢出。
2、占用内存较多的对象

保存了多个耗用内存过大的对象(如Bitmap)或加载单个超大的图片,造成内存超出限制。

三、常见的内存泄漏
1.万恶的static
  static是Java中的一个关键字,当用它来修饰成员变量时,那么该变量就属于该类,而不是该类的实例。

private static Activity mContext;       //省略

如何才能有效的避免这种引用的发生呢?

第一,应该尽量避免static成员变量引用资源耗费过多的实例,比如Context。

第二、Context尽量使用Application Context,因为Application的Context的生命周期比较长,引用它不会出现内存泄露的问题。

第三、使用WeakReference代替强引用。比如可以使用WeakReference<Context> mContextRef;

2.线程惹的祸
线程也是造成内存泄露的一个重要的源头。线程产生内存泄露的主要原因在于线程生命周期的不可控。我们来考虑下面一段代码。

 1 public class MyActivity extends Activity {
 2 @Override
 3 public void onCreate(Bundle savedInstanceState) {
 4   super.onCreate(savedInstanceState);
 5   setContentView(R.layout.main);
 6   new MyThread().start();
 7 }
 8 private class MyThread extends Thread{
 9 @Override
10   public void run() {
11   super.run();
12   //do somthing
13 }
14 }
15 }  

我们思考一个问题:假设MyThread的run函数是一个很费时的操作,当调用finish的时候Activity 会销毁掉吗?

事实上由于我们的线程是Activity的内部类,所以MyThread中保存了Activity的一个引用,当MyThread的run函数没有结束时,MyThread是不会被销毁的,因此它所引用的老的Activity也不会被销毁,因此就出现了内存泄露的问题。

解决方案

第一、将线程的内部类,改为静态内部类。

第二、如果需要引用Acitivity,使用弱引用。
    
    另外在使用handler 的时候, 尤其用到循环调用的时候,在Activity 退出的时候注意移除。否则也会导致泄露

 1 public class ThreadDemo extends Activity {
 2     private static final String TAG = "ThreadDemo";
 3     private int count = 0;
 4     private Handler mHandler =  new Handler();
 5
 6     private Runnable mRunnable = new Runnable() {
 7
 8         public void run() {
 9             //为了方便 查看,我们用Log打印出来
10             Log.e(TAG, Thread.currentThread().getName() + " " +count);
11             //每2秒执行一次
12             mHandler.postDelayed(mRunnable, 2000);
13         }
14     };
15     @Override
16     public void onCreate(Bundle savedInstanceState) {
17         super.onCreate(savedInstanceState);
18         setContentView(R.layout.main);
19         //通过Handler启动线程
20         mHandler.post(mRunnable);
21     }
22
23 }
24 //所以我们在应用退出时,要将线程销毁,我们只要在Activity中的,onDestory()方法处理一下就OK了,如下代码所示:
25 @Override
26   protected void onDestroy() {
27     mHandler.removeCallbacks(mRunnable);
28     super.onDestroy();
29   }
30  

3.Bitmap
可以说出现OutOfMemory问题的绝大多数人,都是因为Bitmap的问题。因为Bitmap占用的内存实在是太多了,特别是分辨率大的图片,如果要显示多张那问题就更显著了。

解决方案:

第一、及时的销毁。

虽然,系统能够确认Bitmap分配的内存最终会被销毁,但是由于它占用的内存过多,所以很可能会超过java堆的限制。因此,在用完Bitmap时,要及时的recycle掉。recycle并不能确定立即就会将Bitmap释放掉,但是会给虚拟机一个暗示:“该图片可以释放了”。

第二、设置一定的采样率。

有时候,我们要显示的区域很小,没有必要将整个图片都加载出来,而只需要记载一个缩小过的图片,这时候可以设置一定的采样率,那么就可以大大减小占用的内存。如下面的代码:

private ImageView preview;

BitmapFactory.Options options = new BitmapFactory.Options();

options.inSampleSize = 2;//图片宽高都为原来的二分之一,即图片为原来的四分之一

Bitmap bitmap = BitmapFactory.decodeStream(cr.openInputStream(uri), null, options);  preview.setImageBitmap(bitmap);

第三、巧妙的运用软引用(SoftRefrence)

有些时候,我们使用Bitmap后没有保留对它的引用,因此就无法调用Recycle函数。这时候巧妙的运用软引用,可以使Bitmap在内存快不足时得到有效的释放。

4.行踪诡异的Cursor

Cursor是Android查询数据后得到的一个管理数据集合的类,正常情况下,如果查询得到的数据量较小时不会有内存问题,而且虚拟机能够保证Cusor最终会被释放掉。

然而如果Cursor的数据量特表大,特别是如果里面有Blob信息时,应该保证Cursor占用的内存被及时的释放掉,而不是等待GC来处理。并且Android明显是倾向于编程者手动的将Cursor close掉

而且android数据库中对Cursor资源的是又限制个数的,如果不及时close掉,会导致别的地方无法获得
    
5.构造Adapter时,没有使用缓存的 convertView 
  以构造ListView的BaseAdapter为例,在BaseAdapter中提高了方法:
   public View getView(int position, View convertView, ViewGroup parent)

AdapterView 在使用View会有一个循环的View队列的,把不显示的View重新投入使用,所以在convertView不为空的时候,不要直接创建新的View

小结:

static:引用了大对象如context

线程:切屏时Activity因为线程引用而没有如期被销毁;handler有关,Activity意外终止但线程还在

Bitmap:要及时recycle,降低采样率

Cursor:要及时关闭

Adapter:没有使用缓存的convertView

四、内存泄漏调试:
(1).内存监测工具 DDMS --> Heap
 用 Heap监测应用进程使用内存情况的步骤如下:
      1. 切换到DDMS透视图,并确认Devices视图、Heap视图都是打开的;
      2. 正常与手机链接成功后,在DDMS的Devices视图中将会显示手机设备的序列号,以及设备中正在运行的部分进程信息;
      3. 点击选中想要监测的进程
      4. 点击选中Devices视图界面中最上方一排图标中的“Update Heap”图标;
      5. 点击Heap视图中的“Cause GC”按钮;
      6. 此时在Heap视图中就会看到当前选中的进程的内存使用量的详细情况。
   Heap视图界面会定时刷新,在对应用的不断的操作过程中就可以看到内存使用的变化;
  如何才能知道我们的程序是否有内存泄漏的可能性呢。这里需要注意一个值:Heap视图中部有一个Type叫做data object,即数据对象,也就是我们的程序中大量存在的类类型的对象。在data object一行中有一列是“Total Size”,其值就是当前进程中所有Java数据对象的内存总量,一般情况下,这个值的大小决定了是否会有内存泄漏。可以这样判断:
   a) 不断的操作当前应用,同时注意观察data object的Total Size值;
   b) 正常情况下Total Size值都会稳定在一个有限的范围内,也就是说由于程序中的的代码良好,没有造成对象不被垃圾回收的情况,所以说  虽然我们不断的操作会不断的生成很多对象,而在虚拟机不断的进行GC的过程中,这些对象都被回收了,内存占用量会会落到一个稳定的水平;
    c) 反之如果代码中存在没有释放对象引用的情况,则data object的Total Size值在每次GC后不会有明显的回落,随着操作次数的增多Total Size的值会越来越大,

(2)内存分析工具 MAT(Memory Analyzer Tool)
  这里介绍一个极好的内存分析工具 -- Memory Analyzer Tool(MAT)。
  MAT是一个Eclipse插件,同时也有单独的RCP客户端。官方下载地址、MAT介绍和详细的使用教程请参见:www.eclipse.org/mat,在此不进行说明了。另外在MAT安装后的帮助文档里也有完备的使用教程。在此仅举例说明其使用方法。我自己使用的是MAT的eclipse插件,使用插件要比RCP稍微方便一些。插件安装成功后,分析步骤(安装方法有多重,大家随便)
 
   (a) 生成.hprof文件
  
      1. 打开eclipse并切换到DDMS
      2. 点击选中想要分析的应用的进程,在Devices视图上方的一行图标按钮中,选中“Update Heap”。
      3. 当内存你感觉异常的时候,按下“Dump HPROF file”按钮,这个时候会提示设置hprof文件的保存路径。
(二) 使用MAT导入.hprof文件
     1. 通过/ANDROID_SDK/tools目录下的hprof-conv.exe工具(使用命令同adb),输入命令hprof-conv xxx.hprof yyy.hprof,其中xxx.hprof为原始文件,yyy.hprof为转换过后的文件。
    2. 在Eclipse中点击Windows->Open Perspective->Other->Memory Analysis perspective界面。在MAT中点击File->Open File,浏览并导入刚刚 转换而得到的.hprof文件。
(三) 使用MAT的视图工具分析内存
  导入.hprof文件以后,MAT会自动解析并生成报告,报告中会列出使用内存过多或者初始化的实例过多的类。

点击Dominator Tree,并按Package分组,选择报告中提到的可疑实例的类,在弹出菜单中选择List objects->With incoming references。这时会列出所有可疑类,右键点击某一项,并选择Path to GC Roots -> exclude weak/soft references,会进一步筛选出跟程序相关的所有有内存泄露的类。据此,可以追踪到代码中的某一个产生泄露的类。
   主要是看可疑类的引用是因为什么代码的引用而导致无法释放的
  总之使用MAT分析内存查找内存泄漏的根本思路,就是找到哪个类的对象的引用没有被释放,找到没有被释放的原因,也就可以很容易定位代码中的哪些片段的逻辑有问题了。

转自:http://blog.csdn.net/cs_epo/article/details/7843766

本文转自天天_byconan博客园博客,原文链接:http://www.cnblogs.com/tiantianbyconan/p/3679875.html,如需转载请自行联系原作者

关于Android 的内存泄露及分析相关推荐

  1. Android使用Handler造成内存泄露的分析及解决方法

    Android使用Handler造成内存泄露的分析及解决方法 参考文章: (1)Android使用Handler造成内存泄露的分析及解决方法 (2)https://www.cnblogs.com/xu ...

  2. android手机内存使用情况分析

    android手机内存使用情况分析         通常客户经常纠结手机内存的使用率不合理,占有的内存太大,可用内存很少,客户往往需要给出解决方案或在给出原因,那么你首先需要知道手机的内存都被什么应用 ...

  3. Android studio内存泄露分析工具

    使用 Android Studio 检测内存泄漏与解决内存泄漏问题 本文在腾讯技术推文上 修改 发布. http://wetest.qq.com/lab/view/63.html?from=ads_t ...

  4. Android之内存泄露、内存溢出、内存抖动分析

      内存 JAVA是在JVM所虚拟出的内存环境中运行的,内存分为三个区:堆.栈和方法区. 栈(stack):是简单的数据结构,程序运行时系统自动分配,使用完毕后自动释放.优点:速度快. 堆(heap) ...

  5. Android Handler的内存泄露场景分析

    在前面一篇博客<Android全面解析Handler>一文中,我们认识了Handler的异步通信机制,同时也提到过Handler如果使用不慎将会导致内存泄露.今天主要来讲述一下Handle ...

  6. Android中使用Handler(消息机制)造成内存泄露的分析和解决

    问题描述: Handler 内部类持有 外部类Activity的引用,如果Activity退出而Handler还有延迟处理的消息没有处理完,会导致Activity不能回收,反复如此会导致内存泄露. 解 ...

  7. Android App内存泄露测试方法总结

    和你一起终身学习,这里是程序员Android 经典好文推荐,通过阅读本文,您将收获以下知识点: 一.内存泄露 二. Android的GC机制 三.为什么会内存泄露 四. 系统级别的内存管理 五.内存抖 ...

  8. 【Android】内存泄露 使用 LeakCanary 应当如何应对?最全的解决

    目录 1.LeakCanary简介 2.入手指南 3.基础使用 3.1介绍 3.1.1什么是内存泄漏 3.1.2内存泄漏的常见原因 3.1.3为什么我应该使用LeakCanary 3.2.LeakCa ...

  9. android inputmethodmanager内存泄露,InputMethodManager内存泄露现象及解决

    [Android][Memory Leak] InputMethodManager内存泄露现象及解决 现象: 在特定的机型天语k_touch_v9机型上,某个界面上出现InputMethodManag ...

最新文章

  1. SAP 金属行业实施项目的GAP之Metall Balance
  2. Android Fragment 真正的完全解析(下)
  3. HLSL的一些常见渲染特效的实现
  4. python抓取页面数据实例
  5. wordpress绿色小清新运营笔记博客主题模板
  6. vue多个根节点上的属性继承
  7. CCF201712-3 Crontab(100分)【模拟+文本处理】
  8. ios 打印 详细错误日志_iOS打印Debug日志的方式
  9. anaconda python命令_怎么用anaconda命令行?
  10. python基于Suprise模块构建推荐算法模型,实现电影、书籍等资源的推荐
  11. 360搜索核心算法,被K后如何恢复?
  12. 全国省市区(县)数据以及位置坐标 包含SQL脚本
  13. PB调用WebService
  14. 说说“安规”的那些事儿
  15. 屏蔽非微信客户端和支付宝登陆登录操作
  16. mysql宠物店java_javajdbc宠物商店-Mysql数据库
  17. php绑定银行卡实现,php网站如何绑定银行卡
  18. vue高德地图JS API 实现海量点标记展示
  19. 20230308-二维数组的长度
  20. Docker 安装和使用日常命令全覆盖

热门文章

  1. 想做C++软件开发工程师,我该如何去学习?
  2. 002-软件质量模型
  3. C#中==操作符存在的缺陷
  4. 开源大数据周刊-第50期
  5. oracle11g-R2静默安装报错[INS-32013]解决方案
  6. 数据驱动型企业如何炼成?只需五步!
  7. Java线程池—ThreadPool简介
  8. 解决问题:Appium WebView 跳转页面后无法定位元素
  9. 内存区划分、内存分配、常量存储区、堆、栈、自由存储区、全局区[C++][内存管理][转载]...
  10. spring+hibernate:在applicationCOntext.XML中配置C3P0参数说明