发布日期: 2017-12-03

简介

在Android里，程序内存被分为2部分：native和dalvik，dalvik就是我们普通的Java使用内存，我们创建的对象是在这里面分配的，
对于内存的限制是 native+dalvik 不能超过最大限制。android程序内存一般限制在16M，也有的是24M（早期的Android系统G1，就是只有16M）。具体看定制系统的设置，如果
在有限的内存里面发生了内存泄漏，程序运行的越久，也就会越卡

什么是内存泄露：内存不在GC掌控之内了。
当一个对象已经不需要再使用了，本该被回收时，而有另外一个正在使用的对象持有它的引用从而就导致
对象不能被回收。这种导致了本该被回收的对象不能被回收而停留在堆内存中，就产生了内存泄漏

相比于c/c++，java的内存分配是不用自己处理的，由专门的垃圾回收来处理，如果java的Gc回收发现了一个对象没有被引用的时候，就会在内存达到一定的程度的话时候，就会触发
垃圾回收机制，比如 Student A = new Student();,A持有new Student()在堆上分配的句柄，如果此时 A = B;那本身被A持有的句柄就会没有被引用，gc回收机制就会回收这个在堆上分配的内存
gc的垃圾回收机制是在内存达到一定的程度的时候发会触发，如果出现了内存泄露，而且泄漏越来越多，那么就会频繁的触发垃圾回收机制，而垃圾回收机制却不能处理这种内存泄漏的情况，这个时候
gc的垃圾回收机制就会有本来是一个好的机制，变成了一个拖性能的机制

java的GC内存回收机制：某对象不再有任何的引用的时候才会进行回收。

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

1.利用Android Monitors的内存分析

最直观的看内存增长情况，知道该动作是否发生内存泄露。
动作发生之前：GC完后内存1.4M; 动作发生之后：GC完后内存1.6M,那么这个动作就是有内存泄露的情况,我们的gc操作可以多触发几次

2.使用AndroidStudio 某个时机点生成的prof文件，快速的排查是否有内存泄漏的地方
我们在上一个操作步骤一中由于某一个动作导致内存的增多，这个时候如果我们怀疑有内存泄漏的时候，就可以利用Android studio 中的dump java heap 文件来查看
结果显示
我们可以在红线部分选择 package tree view，可以清除得到我们当前包名下面的类的情况

HPROF文件查看工具

这个工具显示了如下信息：
名称    描述
 ● Class name    类名
 ● Total Count    该类的实例总数
 ● Heap Count    所选择的堆中该类的实例的数量
 ● Sizeof    单个实例所占空间大小（如果每个实例所占空间大小不一样则显示0）
 ● Shallow Size    堆里所有实例大小总和（Heap Count * Sizeof）
 ● Retained Size    该类所有实例所支配的内存大小
 ● Instance    具体的实例
 ● Reference Tree    所选实例的引用，以及指向该引用的引用。
 ● Depth    GC根节点到所选实例的最短路径的深度
 ● Shallow Size    所选实例的大小
 ● Dominating Size    所选实例所支配的内存大小

 经过查看可以发现我们的MainActivity有俩个实例对象存在

结果显示

3.可以使用第二步骤生成的hprof文件，android studio中的Analyzer Task来自动的帮我们分析内存泄漏的情况
结果显示

4.我们可以根据Android Studio生成的hprof文件，导出标准的hprof文件，利用独立的分析工具，mat来分析
结果显示

. MAT分析hprof来定位内存泄露的原因所在。(哪个对象持有了上面怀疑出来的发生泄露的对象)
(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路径是否正常此时就要进入代码分析此时这个对象的引用持有是否合理，这就要考经验和体力了！
（比如上课的例子中：旋转屏幕后MainActivity有两个，肯定MainActivity发生泄露了，
那谁导致他泄露的呢？原来是我们的CommonUtils类持有了旋转之前的那个MainActivity他，
那是否合理？结合逻辑判断当然不合理，由此找到内存泄露根源是CommonUtils类持有了该MainActivity实例造成的。
怎么解决？罪魁祸首找到了，怎么解决应该不难了，不同情况解决办法不一样，要靠你的智慧了。）

最终找到泄露的地方，跟实体
结果显示

判断一个应用里面内存泄露避免得很好，怎么看?

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

当正常的情况下,即CommonUtils.getInstatnce(getApplicationContext())
结果显示

当正常的情况下,即CommonUtils.getInstatnce(this),这里就是泄漏了MainActivity
结果显示

内存泄露经常出现的例子

内存泄露(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就会变成泄露对象。
比如：轮播图效果。