1.确定是否存在内存泄露 1)Android Monitors的内存分析 最直观的看内存增长情况，知道该动作是否发生内存泄露。 动作发生之前：GC完后内存1.4M; 动作发生之后：GC完后内存1.7M
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中的对象信息。
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就会变成泄露对象。 比如：轮播图效果。
新闻热点
疑难解答
