性能优化03_常见内存泄露分析

Android性能优化汇总
前面的文章在分析内存泄漏之前我们知道了已经发生泄漏,并且明确知道那个Activity泄漏,通过查找更多侧重于对工具的熟练使用。在实际开发中,我们不知道应用是否发生泄漏,那里发生泄漏,这个时候如何快速定位问题呢?

一 如何定位内存泄漏发生点

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

Android Monitors的内存分析
最直观的看内存增长情况,知道该动作是否发生内存泄露。
例如:动作发生之前,GC完后内存1.4M; 动作发生之后:GC完后内存1.6M,内存明显增长了。
在这里插入图片描述

2 先找怀疑对象(哪些对象属于泄露的)

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

3 MAT分析hprof来定位内存泄露的原因所在。

-哪个对象持有了上面怀疑出来的发生泄露的对象

1)Dump出内存泄露“当时”的内存镜像hprof,分析怀疑泄露的类;

2)把上面得出的这些怀疑对象一个一个排查个遍。步骤:(lsn2已详细写过)

  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路径是否正常
    此时就要进入代码分析此时这个对象的引用持有是否合理,这就要考经验和体力了!
    例如:Lsn01中旋转屏幕后MainActivity有两个,肯定MainActivity发生泄露了, 那谁导致他泄露的呢?原来是我们的CommonUtils类持有了旋转之前的那个MainActivity他,那是否合理?结合逻辑判断当然不合理,由此找到内存泄露根源是CommonUtils类持有了该MainActivity实例造成的。罪魁祸首找到了,怎么解决应该不难了

**有一个笨办法:**new出来对象,用完后把它 = 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 非静态内部类引起内存泄露(包括匿名内部类)

错误的示范:
		
	//1 Thread 引起:隐式持有MainActivity实例。MainActivity.this.a
    private  void loadData() {
     /*   new Thread(new Runnable() {
            @Override
            public void run() {
                while (true){
                    try {
                       int b = a;
                        Thread.sleep(1000);
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                }
            }
        }).start();*/
        // 解决方法:加上static,里面的匿名内部类就变成了静态匿名内部类
    }

Timer泄漏:

  //2 Timer
    private void schedule() {
        new Timer().schedule(new TimerTask() {
            @Override
            public void run() {
                try {
                    int b = a;
                    Thread.sleep(1000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }, 20000);//延迟执行导致泄漏
        // 解决方法:activity onDestroy把timer.cancel掉然后赋空
    }

Handler泄漏

//3 mHandler是匿名内部类的实例,会引用外部对象MainActivity.this。如果Handler在Activity退出的时候,它可能还活着,这时候就会一直持有Activity。
//    private Handler mHandler = new Handler(){
////        @Override
////        public void handleMessage(Message msg) {
////            super.handleMessage(msg);
////            switch (msg.what){
////                case 0:
////                    //加载数据
//////                    break;
////            }
////        }
////    };
////    private void handle(){
//////        mHandler.sendMessageAtTime(msg,10000);//atTime
////    }
    //解决方案: 软引用+静态防止泄漏并实现功能

    private static class MyHandler extends Handler{

        //        private MainActivity mainActivity;//直接持有了一个外部类的强引用,会内存泄露
        private WeakReference<CommonLeakageCaseActivity> mainActivity;//设置软引用保存,当内存一发生GC的时候就会回收。

        public MyHandler(CommonLeakageCaseActivity mainActivity) {
            this.mainActivity = new WeakReference<>(mainActivity);
        }

        @Override
        public void handleMessage(Message msg) {
            super.handleMessage(msg);
            CommonLeakageCaseActivity main =  mainActivity.get();
            if(main==null||main.isFinishing()){
                return;
            }
            switch (msg.what){
                case 0:
                    //加载数据
//                    MainActivity.this.a;//有时候确实会有这样的需求:需要引用外部类的资源。怎么办?
                    int b = main.a;
                    break;

            }
        }

    }

解决方案:
将非静态内部类修改为静态内部类。
(静态内部类不会隐士持有外部类)
当使用软引用或者弱引用的时候,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就会变成泄露对象。
比如:轮播图效果。

上述代码的Demo:CommonLeakageCaseActivity

发布了211 篇原创文章 · 获赞 63 · 访问量 14万+

猜你喜欢

转载自blog.csdn.net/baopengjian/article/details/103929737