Android性能优化之内存泄漏分析

Android性能优化之内存泄漏分析

一、简述

对于C++来说,内存泄漏就是new出来的对象没有delete,俗称野指针。对于Java来说,就是new出来的Object放在堆Heap上无法被GC回收。

二、Java中得到内存分配

  • 方法区(静态存储区): 编译时分配好了,在程序整个运行时期都存在,主要存放静态数据和常量。

  • 栈区(虚拟机栈、本地方法栈): 当方法执行时,会在栈区内存中创建栈帧,每个栈帧中保存在局部变量、操作数栈、方法出口等信息,每个方法的执行到结束都对应一个栈帧从栈区入栈和出栈.

  • 堆区(Heap区,分为新生代(Eden、from-Surivior, to-Surivior: 8:1:1)、老年代),几乎所有new对象实例都是存放在堆区,由Java垃圾回收器回收。

三、四种引用的介绍

  • 强引用(StrongReference): JVM中宁可抛出OOM,也不会让GC回收具有强引用的对象,一般直接通过new创建都是强引用。

  • 软引用(SoftReference): 只有在内存不足的时候,才会被回收的对象引用

  • 弱引用(WeakReference): 在GC时,一旦发现只要具有弱引用的对象,不管当前内存空间足够与否,都会回收它的内存。

  • 虚引用(PhantomReference): 任何时候都可以被GC回收,当垃圾回收器准备回收一个对象时,如果发现它还有虚引用,就会在回收对象的内存之前,把这个虚引用加入到与之关联的引用队列中。程序可以通过判断引用队列中是否存在该对象的虚引用,来了解这个对象是否将要被回收。可以用来作为GC回收Object的标志。

内存泄漏是指new出来的Object无法被GC回收,即为强引用

内存泄漏发生时的主要表现为内存抖动,可用内存慢慢变少

四、Android内存泄漏分析工具MAT

MAT(Memory Analyzer Tools) 是一个 Eclipse 插件,它是一个快速、功能丰富的JAVA heap分析工具,它可以帮助我们查找内存泄漏和减少内存消耗。

1、内存泄漏的排查方法

  • 观察 Heap

    · 运行程序,然后进入 DDMS管理界面,如下:

    PS : 点击工具栏上的 来更新统计信息

    点击右侧的 Cause GC 按钮或工具栏上的 即可查看当前的堆情况,如下:

    主要关注两项数据:

    o Heap Size 堆的大小,当资源增加,当前堆的空余空间不够时,系统会增加堆的大小,若超过上限 (例如64M,视平台和具体机型而定)则会被杀掉

    o Allocated 堆中已分配的大小,这是应用程序实际占用的内存大小,资源回收后,此项数据会变小

    · 查看操作前后的堆数据,看是否有内存泄漏
    对单一操作(比如添加页,删除页)进行反复操作,如果堆的大小一直增加,则有内存泄漏的隐患。

  • 利用MAT分析内存堆

    DDMS 可以将当前的内存 Dump成一个 hprof格式的文件,MAT 读取这个文件后会给出方便阅读的信息,配合它的查找,对比功能,就可以定位内存泄漏的原因。

    ·获取 hprof文件
    点击工具栏上的 按钮,将内存信息保存成文件。 如果是用 MAT Eclipse 插件获取的 Dump文件,则不需要经过转换,Adt会自动进行转换然后打开。

    · 转换 hprof文件
    DDMS Dump 出的文件要经过转换才能被 MAT识别,Android SDK提供了这个工具 hprof-conv (位于 sdk/tools下)

    · ./hprof-conv xxx-a.hprof xxx-b.hprof

    · 用 MAT打开转换后的 hprof文件

  • Histogram 查询

    用的最多的功能是 Histogram,点击 Actions下的 Histogram项将得到 Histogram结果:

它按类名将所有的实例对象列出来,可以点击表头进行排序,在表的第一行可以输入正则表达式来匹配结果 :

在某一项上右键打开菜单选择 list objects ->with incoming refs 将列出该类的实例:

它展示了对象间的引用关系,比如展开后的第一个子项表示这个 HomePage(0x420ca5b0)被HomePageContainer(0x420c9e40)中的 mHomePage属性所引用.

快速找出某个实例没被释放的原因,可以右健 Path to GC Roots–>exclue all phantom/weak/soft etc. reference :

得到的结果是:

从表中可以看出 PreferenceManager -> … ->HomePage这条线路就引用着这个 HomePage实例。用这个方法可以快速找到某个对象的 GC Root,一个存在 GC Root的对象是不会被 GC回收掉的.

  • Histogram 对比

为查找内存泄漏,通常需要两个 Dump结果作对比,打开 Navigator History面板,将两个表的 Histogram结果都添加到 Compare Basket中去 :

添加好后,打开 Compare Basket面板,得到结果:

点击右上角的 ! 按钮,将得到比对结果:

注意,上面这个对比结果不利于查找差异,可以调整对比选项:

再把对比的结果排序,就可得到直观的对比结果:

也可以对比两个对象集合,方法与此类似,都是将两个 Dump结果中的对象集合添加到Compare Basket中去对比。找出差异后用 Histogram查询的方法找出 GC Root,定位到具体的某个对象上.

五、常见的内存泄漏场景

1、单例造成内存泄漏

单例静态特性导致其生命周期同应用一样长

解决方案:

  1. 将该属性的引用方式改为弱引用;

  2. 如果传入Context,使用ApplicationContext;

code:

private static ScrollHelper mInstance;    
private ScrollHelper() {
}    
public static ScrollHelper getInstance() {        
    if (mInstance == null) {           
       synchronized (ScrollHelper.class) {                
            if (mInstance == null) {
                mInstance = new ScrollHelper();
            }
        }
    }        

    return mInstance;
}    
/**
 * 被点击的view
 */
private View mScrolledView = null;    
public void setScrolledView(View scrolledView) {
    mScrolledView = scrolledView;
}


//修改后的,使用WeakReference
private static ScrollHelper mInstance;    
private ScrollHelper() {
}    
public static ScrollHelper getInstance() {        
    if (mInstance == null) {            
        synchronized (ScrollHelper.class) {                
            if (mInstance == null) {
                mInstance = new ScrollHelper();
            }
        }
    }        

    return mInstance;
}    
/**
 * 被点击的view
 */
private WeakReference<View> mScrolledViewWeakRef = null;    
public void setScrolledView(View scrolledView) {
    mScrolledViewWeakRef = new WeakReference<View>(scrolledView);
}

2、InnerClass匿名内部类

在Java中,非静态内部类和匿名类 都会潜在的引用它们所属的外部类,但是,静态内部类却不会。如果这个非静态内部类实例做了一些耗时的操作,就会造成外部对象不会被回收,从而导致内存泄漏。

解决方案:

  1. 将内部类变成静态内部类;

  2. 如果有强引用Activity中的属性,则将该属性的引用方式改为弱引用;

  3. 在业务允许的情况下,当Activity执行onDestory时,结束这些耗时任务;

public class LeakAct extends Activity {  
    @Override
    protected void onCreate(Bundle savedInstanceState) {    
        super.onCreate(savedInstanceState);
        setContentView(R.layout.aty_leak);
        test();
    } 
    //这儿发生泄漏    
    public void test() {    
        new Thread(new Runnable() {      
            @Override
            public void run() {        
                while (true) {          
                    try {
                        Thread.sleep(1000);
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                }
            }
        }).start();
    }
}

//加上static,变成静态匿名内部类
public class LeakAct extends Activity {  
    @Override
    protected void onCreate(Bundle savedInstanceState) {    
        super.onCreate(savedInstanceState);
        setContentView(R.layout.aty_leak);
        test();
    }  
    //加上static,变成静态匿名内部类
    public static void test() {    
        new Thread(new Runnable() {     
            @Override
            public void run() {        
                while (true) {          
                    try {
                        Thread.sleep(1000);
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                }
            }
        }).start();
    }
}

3、Activity Context不正确的使用

在Android应用程序中通常可以使用两种Context对象:Activity和Application。当类或方法需要Context对象的时候常见的做法是使用第一个作为Context参数。这样就意味着View对象对整个Activity保持引用,因此也就保持对Activty的所有的引用

假设一个场景,当应用程序有个比较大的Bitmap类型的图片,每次旋转是都重新加载图片所用的时间较多。为了提高屏幕旋转是Activity的创建速度,最简单的方法时将这个Bitmap对象使用Static修饰。 当一个Drawable绑定在View上,实际上这个View对象就会成为这份Drawable的一个Callback成员变量。而静态变量的生命周期要长于Activity。 导致了当旋转屏幕时,Activity无法被回收,而造成内存泄露。

解决方案:

  1. 使用ApplicationContext代替ActivityContext,因为ApplicationContext会随着应用程序的存在而存在,而不依赖于activity的生命周期;

  2. 对Context的引用不要超过它本身的生命周期,慎重的对Context使用“static”关键字。Context里如果有线程,一定要在onDestroy()里及时停掉。

private static Drawable sBackground;
@Override
protected void onCreate(Bundle state) {  
    super.onCreate(state);
    TextView label = new TextView(this);
    label.setText("Leaks are bad");  
    if (sBackground == null) {
        sBackground = getDrawable(R.drawable.large_bitmap);
    }
    label.setBackgroundDrawable(sBackground);
    setContentView(label);
}

private static Drawable sBackground;
@Override
protected void onCreate(Bundle state) {  
    super.onCreate(state);
    TextView label = new TextView(this);
    label.setText("Leaks are bad");  
    if (sBackground == null) {
        sBackground = getApplicationContext().getDrawable(R.drawable.large_bitmap);
    }
    label.setBackgroundDrawable(sBackground);
    setContentView(label);
}

4、Handler引起的内存泄漏

当Handler中有延迟的的任务或是等待执行的任务队列过长,由于消息持有对Handler的引用,而Handler又持有对其外部类的潜在引用,这条引用关系会一直保持到消息得到处理,而导致了Activity无法被垃圾回收器回收,而导致了内存泄露。

解决方案:

  1. 可以把Handler类放在单独的类文件中,或者使用静态内部类便可以避免泄露;

  2. 如果想在Handler内部去调用所在的Activity,那么可以在handler内部使用弱引用的方式去指向所在Activity.使用Static + WeakReference的方式来达到断开Handler与Activity之间存在引用关系的目的。

@Override
protected void doOnDestroy() {        
    super.doOnDestroy();        
    if (mHandler != null) {
        mHandler.removeCallbacksAndMessages(null);
    }
    mHandler = null;
    mRenderCallback = null;
}

5、注册监听器的泄漏

系统服务可以通过Context.getSystemService 获取,它们负责执行某些后台任务,或者为硬件访问提供接口。如果Context 对象想要在服务内部的事件发生时被通知,那就需要把自己注册到服务的监听器中。然而,这会让服务持有Activity 的引用,如果在Activity onDestory时没有释放掉引用就会内存泄漏。

解决方案:

  1. 让服务注册的引用使用ApplicationContext代替ActivityContext;

  2. 在Activity执行onDestory时,调用反注册;

mSensorManager = (SensorManager) this.getSystemService(Context.SENSOR_SERVICE);

//解决办法
mSensorManager = (SensorManager) getApplicationContext().getSystemService(Context.SENSOR_SERVICE);

下面是容易造成内存泄漏的系统服务:

InputMethodManager imm = (InputMethodManager) context.getApplicationContext().getSystemService(Context.INPUT_METHOD_SERVICE);

//解决办法
protected void onDetachedFromWindow() {        
    if (this.mActionShell != null) {
        this.mActionShell.setOnClickListener((OnAreaClickListener)null);
    }        
    if (this.mButtonShell != null) { 
        this.mButtonShell.setOnClickListener((OnAreaClickListener)null);
    }        
    if (this.mCountShell != this.mCountShell) {
        this.mCountShell.setOnClickListener((OnAreaClickListener)null);
    }        
    super.onDetachedFromWindow();
}

6、Cursor,Stream没有close,View没有recyle

资源性对象比如(Cursor,File文件等)往往都用了一些缓冲,我们在不使用的时候,应该及时关闭它们,以便它们的缓冲及时回收内存。它们的缓冲不仅存在于 java虚拟机内,还存在于java虚拟机外。如果我们仅仅是把它的引用设置为null,而不关闭它们,往往会造成内存泄漏。因为有些资源性对象,比如SQLiteCursor(在析构函数finalize(),如果我们没有关闭它,它自己会调close()关闭),如果我们没有关闭它,系统在回收它时也会关闭它,但是这样的效率太低了。因此对于资源性对象在不使用的时候,应该调用它的close()函数,将其关闭掉,然后才置为null. 在我们的程序退出时一定要确保我们的资源性对象已经关闭。

Solution:

调用onRecycled()

@Override
public void onRecycled() {
    reset();
    mSinglePicArea.onRecycled();
}

在View中调用reset()

public void reset() {
    if (mHasRecyled) {            
        return;
    }
...
    SubAreaShell.recycle(mActionBtnShell);
    mActionBtnShell = null;
...
    mIsDoingAvatartRedPocketAnim = false;        
    if (mAvatarArea != null) {
            mAvatarArea.reset();
    }        
    if (mNickNameArea != null) {
        mNickNameArea.reset();
    }
}

7、集合中对象没清理造成的内存泄漏

我们通常把一些对象的引用加入到了集合容器(比如ArrayList)中,当我们不需要该对象时,并没有把它的引用从集合中清理掉,这样这个集合就会越来越大。如果这个集合是static的话,那情况就更严重了。
所以要在退出程序之前,将集合里的东西clear,然后置为null,再退出程序。

解决方案:

在Activity退出之前,将集合里的东西clear,然后置为null,再退出程序。

private List<EmotionPanelInfo> data;    
public void onDestory() {        
    if (data != null) {
        data.clear();
        data = null;
    }
}

8、webview造成的内存泄漏

当我们不要使用WebView对象时,应该调用它的destory()函数来销毁它,并释放其占用的内存,否则其占用的内存长期也不能被回收,从而造成内存泄露。

解决方案:

为webView开启另外一个进程,通过AIDL与主线程进行通信,WebView所在的进程可以根据业务的需要选择合适的时机进行销毁,从而达到内存的完整释放。

9. 构造Adapter时,没有使用缓存的ConvertView

初始时ListView会从Adapter中根据当前的屏幕布局实例化一定数量的View对象,同时ListView会将这些View对象 缓存起来。
当向上滚动ListView时,原先位于最上面的List Item的View对象会被回收,然后被用来构造新出现的最下面的List Item。
这个构造过程就是由getView()方法完成的,getView()的第二个形参View ConvertView就是被缓存起来的List Item的View对象(初始化时缓存中没有View对象则ConvertView是null)。


   转载规则


《Android性能优化之内存泄漏分析》 mikyou 采用 知识共享署名 4.0 国际许可协议 进行许可。
 上一篇
Android性能优化之内存优化 Android性能优化之内存优化
Android性能优化之内存优化一、内存泄漏(Memory Leak) 对于Java来说new出来的Object在Heap堆上无法被GC回收(内存中存在无法回收的对象);内存泄漏时主要表现为内存抖动,可用内存慢慢变少。 1、内存泄漏检测工
2020-01-01
下一篇 
设计模式之代理模式 设计模式之代理模式
设计模式之代理模式一、介绍代理模式(Proxy Pattern),又称委托模式,顾名思义就是一个对象的实现委托给另一个代理对象来实现供外部调用。 二、定义为其他对象提供一种代理方式来控制对某个对象的访问,从而更好地保证了该对象对外使用的透明
2019-12-31