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

[java]  view plain copy
  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 退出的时候注意移除。否则也会导致泄露

   

[java]  view plain copy
  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分析内存查找内存泄漏的根本思路,就是找到哪个类的对象的引用没有被释放,找到没有被释放的原因,也就可以很容易定位代码中的哪些片段的逻辑有问题了。


你可能感兴趣的:(关于Android 的内存泄露及分析)