内存泄露（五）-- 如何找到项目中存在的内存泄露的这些地方呢？

如何找到项目中存在的内存泄露的这些地方呢？

1. 确定是否存在内存泄露

1. Android Monitors的内存分析
     最直观的看内存增长情况，知道该动作是否发生内存泄露。
     动作发生之前：GC完后内存1.4M; 动作发生之后：GC完后内存1.6M
2. 使用MAT内存分析工具
     MAT分析heap的总内存占用大小来初步判断是否存在泄露。
     Heap视图中有一个Type叫做data object，即数据对象，也就是我们的程序中大量存在的类类型的对象。
     在data object一行中有一列是“Total Size”，其值就是当前进程中所有Java数据对象的内存总量，
     一般情况下，这个值的大小决定了是否会有内存泄漏。
     我们反复执行某一个操作并同时执行GC排除可以回收掉的内存，注意观察data object的Total Size值，
     正常情况下Total Size值都会稳定在一个有限的范围内，也就是说由于程序中的的代码良好，没有造成对象不被垃圾回收的情况。
     反之如果代码中存在没有释放对象引用的情况，随着操作次数的增多Total Size的值会越来越大。

  那么这里就已经初步判断这个操作导致了内存泄露的情况。

2.先找怀疑对象(哪些对象属于泄露的)
  MAT对比操作前后的hprof来定位内存泄露是泄露了什么数据对象。（这样做可以排除一些对象，不用后面去查看所有被引用的对象是否是嫌疑）
  快速定位到操作前后所持有的对象哪些是增加了(GC后还是比之前多出来的对象就可能是泄露对象嫌疑犯)
  技巧：Histogram中还可以对对象进行Group，比如选择Group By Package更方便查看自己Package中的对象信息。

3. MAT分析hprof来定位内存泄露的原因所在。(哪个对象持有了上面怀疑出来的发生泄露的对象)

1. Dump出内存泄露“当时”的内存镜像hprof，分析怀疑泄露的类；
2. 把上面2得出的这些嫌疑犯一个一个排查个遍。步骤：
   (1) 进入Histogram，过滤出某一个嫌疑对象类
   (2) 然后分析持有此类对象引用的外部对象（在该类上面点击右键List Objects—>with incoming references）
   (3) 再过滤掉一些弱引用、软引用、虚引用，因为它们迟早可以被GC干掉不属于内存泄露
   (在类上面点击右键Merge Shortest Paths to GC Roots—>exclude all phantom/weak/soft etc.references)
   (4) 逐个分析每个对象的GC路径是否正常
   此时就要进入代码分析此时这个对象的引用持有是否合理，这就要考经验和体力了！

new出来对象，用完后把它 = null;这样算不算优化？ 假如：方法里面定义的对象，要去管吗？一般不需要管。
自己=null，要自己去控制所有对象的生命周期 判断各种空指针，有点麻烦。 但是在很多时候去想到主动将对象置为null是很好的习惯。

---

判断一个应用里面内存泄露避免得很好，怎么看？
  当app退出的时候，这个进程里面所有的对象应该就都被回收了，尤其是很容易被泄露的（View，Activity）是否还内存当中。
  可以让app退出以后，查看系统该进程里面的所有的View、Activity对象是否为0.
  工具：使用AndroidStudio–AndroidMonitor–System Information–Memory Usage查看Objects里面的views和Activity的数量是否为0.
命令行模式：

=内存泄露经常出现的例子===
内存泄露(Memory Leak)：
  进程中某些对象已经没有使用价值了，但是他们却还可以直接或者间接地被引用到GC Root导致无法回收。
  当内存泄露过多的时候，再加上应用本身占用的内存，日积月累最终就会导致内存溢出OOM.

内存溢出（OOM）：
  当应用占用的heap资源超过了Dalvik虚拟机分配的内存就会内存溢出。比如：加载大图片。

1.静态变量引起的内存泄露
当调用getInstance时，如果传入的context是Activity的context。只要这个单利没有被释放，那么这个
Activity也不会被释放一直到进程退出才会释放。

public class CommUtil {
    private static CommUtil instance;
    private Context context;
    private CommUtil(Context context){
	this.context = context;
    }

    public static CommUtil getInstance(Context mcontext){
		if(instance == null){
	    	instance = new CommUtil(mcontext);
		}
//        else{
//            instance.setContext(mcontext);
//        }
		return instance;
    }

2.非静态内部类引起内存泄露
(包括匿名内部类)
错误的示范：

public void loadData(){   //隐士持有MainActivity实例。MainActivity.this.a
	new Thread(new Runnable() {
	   	 @Override
    	public void run() {
			while(true){
	  	  		try {
					//int b=a;
					Thread.sleep(1000);
	    		} catch (InterruptedException e) {
					e.printStackTrace();
		   		}
			}
    	}
	}).start();
}

解决方案：
将非静态内部类修改为静态内部类。
（静态内部类不会隐士持有外部类）

  当使用软引用或者弱引用的时候，MainActivity难道很容易或者可以被GC回收吗？》
  GC回收的机制是什么？当MainActivity不被任何的对象引用。
  虽然Handler里面用的是软引用/弱引用，但是并不意味着不存在其他的对象引用该MainActivity。
我连MainActivity都被回收了，那他里面的Handler还玩个屁。

3.不需要用的监听未移除会发生内存泄露
例子1：

//        tv.setOnClickListener();//监听执行完回收对象
        //add监听，放到集合里面
        tv.getViewTreeObserver().addOnWindowFocusChangeListener(new ViewTreeObserver.OnWindowFocusChangeListener() {
            @Override
            public void onWindowFocusChanged(boolean b) {
                //监听view的加载，view加载出来的时候，计算他的宽高等。

                //计算完后，一定要移除这个监听
                tv.getViewTreeObserver().removeOnWindowFocusChangeListener(this);
            }
        });

例子2：

 SensorManager sensorManager = getSystemService(SENSOR_SERVICE);
    Sensor sensor = sensorManager.getDefaultSensor(Sensor.TYPE_ALL);
    sensorManager.registerListener(this,sensor,SensorManager.SENSOR_DELAY_FASTEST);
    //不需要用的时候记得移除监听
    sensorManager.unregisterListener(listener);

4.资源未关闭引起的内存泄露情况
  比如：BroadCastReceiver、Cursor、Bitmap、IO流、自定义属性attribute、attr.recycle()回收。
  当不需要使用的时候，要记得及时释放资源。否则就会内存泄露。

5.无限循环动画
  没有在onDestroy中停止动画，否则Activity就会变成泄露对象。
  比如：轮播图效果。