关于Android 的内存泄露及分析

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

2、Android的内存溢出

一、内存泄露致使

因为咱们程序的失误，长期保持某些资源（如Context）的引用，形成内存泄露，资源形成得不到释放。 

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

 保存了多个耗用内存过大的对象（如Bitmap）或加载单个超大的图片，形成内存超出限制。

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

    private static Activity mContext;       //省略 

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

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

    第2、Context尽可能使用Application Context，由于Application的Context的生命周期比较长，引用它不会出现内存泄露的问题。

    第3、使用WeakReference代替强引用。好比可使用WeakReference<Context> mContextRef;

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

 public class MyActivity extends Activity {
 @Override
 public void onCreate(Bundle savedInstanceState) {
   super.onCreate(savedInstanceState);
   setContentView(R.layout.main);
   new MyThread().start();
 }
 private class MyThread extends Thread{
 @Override
   public void run() {
   super.run();
   //do somthing
 }
 }
 }

   咱们思考一个问题：假设MyThread的run函数是一个很费时的操做，当调用finish的时候Activity 会销毁掉吗？

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

 

解决方案

    第1、将线程的内部类，改成静态内部类。

    第2、若是须要引用Acitivity，使用弱引用。
    
    另外在使用handler 的时候， 尤为用到循环调用的时候，在Activity 退出的时候注意移除。不然也会致使泄露

   

 public class ThreadDemo extends Activity {
     private static final String TAG = "ThreadDemo";
     private int count = 0;
     private Handler mHandler =  new Handler();

     private Runnable mRunnable = new Runnable() {

         public void run() {
             //为了方便 查看，咱们用Log打印出来
             Log.e(TAG, Thread.currentThread().getName() + " " +count);
             //每2秒执行一次
             mHandler.postDelayed(mRunnable, 2000);
         }
     };
     @Override
     public void onCreate(Bundle savedInstanceState) {
         super.onCreate(savedInstanceState);
         setContentView(R.layout.main);
         //经过Handler启动线程
         mHandler.post(mRunnable);
     }

 }
 //因此咱们在应用退出时，要将线程销毁，咱们只要在Activity中的，onDestory()方法处理一下就OK了，以下代码所示:
 @Override
   protected void onDestroy() {
     mHandler.removeCallbacks(mRunnable);
     super.onDestroy();
   }

3.Bitmap
能够说出现OutOfMemory问题的绝大多数人，都是由于Bitmap的问题。由于Bitmap占用的内存实在是太多了，特别是分辨率大的图片，若是要显示多张那问题就更显著了。

    解决方案：

    第1、及时的销毁。

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

    第2、设置必定的采样率。

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

private ImageView preview;  

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

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

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

第3、巧妙的运用软引用（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

 

4、内存泄漏调试:
(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分析内存查找内存泄漏的根本思路，就是找到哪一个类的对象的引用没有被释放，找到没有被释放的缘由，也就能够很容易定位代码中的哪些片断的逻辑有问题了。