Android 内存泄漏

最新推荐文章于 2021-05-28 21:52:38 发布

NineDays66

最新推荐文章于 2021-05-28 21:52:38 发布

阅读量343

点赞数

分类专栏： android 文章标签： android 内存泄露 jvm heap

本文链接：https://blog.csdn.net/u011808673/article/details/78511226

版权

android 专栏收录该内容

12 篇文章 0 订阅

订阅专栏

Android 内存泄漏分析

前言

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

本文通过QQ和Qzone中内存泄漏实例来讲android中内存泄漏分析解法和编写代码应注意的事项。

Java 中的内存分配

静态储存区：编译时就分配好，在程序整个运行期间都存在。它主要存放静态数据和常量；
栈区：当方法执行时，会在栈区内存中创建方法体内部的局部变量，方法结束后自动释放内存；
堆区：通常存放 new 出来的对象。由 Java 垃圾回收器回收。

四种引用类型的介绍

强引用(StrongReference)：JVM 宁可抛出 OOM ，也不会让 GC 回收具有强引用的对象；
软引用(SoftReference)：只有在内存空间不足时，才会被回的对象；
弱引用(WeakReference)：在 GC 时，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存；
虚引用(PhantomReference)：任何时候都可以被GC回收，当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会在回收对象的内存之前，把这个虚引用加入到与之关联的引用队列中。程序可以通过判断引用队列中是否存在该对象的虚引用，来了解这个对象是否将要被回收。可以用来作为GC回收Object的标志。

我们常说的内存泄漏是指new出来的Object无法被GC回收，即为强引用：

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

Andriod中分析内存泄漏的工具MAT

MAT（Memory Analyzer Tools）是一个 Eclipse 插件，它是一个快速、功能丰富的JAVA heap分析工具，它可以帮助我们查找内存泄漏和减少内存消耗。
MAT 插件的下载地址： www.eclipse.org/mat
MAT 使用方法介绍： http://www.cnblogs.com/larack/p/6071209.html

常见的内存泄漏案例

单例造成的内存泄露

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

解决方案：

将该属性的引用方式改为弱引用;
如果传入Context，使用ApplicationContext;

example：

泄漏代码片段

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;

}

Solution：使用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);

}

InnerClass匿名内部类

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

解决方案：

将内部类变成静态内部类;
如果有强引用Activity中的属性，则将该属性的引用方式改为弱引用;
在业务允许的情况下，当Activity执行onDestory时，结束这些耗时任务;

example：

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();    } }

Solution：

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();    } }

Activity Context 的不正确使用

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

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

解决方案：

使用ApplicationContext代替ActivityContext，因为ApplicationContext会随着应用程序的存在而存在，而不依赖于activity的生命周期；
对Context的引用不要超过它本身的生命周期，慎重的对Context使用“static”关键字。Context里如果有线程，一定要在onDestroy()里及时停掉。

example：

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); }

Solution：

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); }

Handler引起的内存泄漏

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

解决方案：

可以把Handler类放在单独的类文件中，或者使用静态内部类便可以避免泄露;
如果想在Handler内部去调用所在的Activity,那么可以在handler内部使用弱引用的方式去指向所在Activity.使用Static + WeakReference的方式来达到断开Handler与Activity之间存在引用关系的目的。

Solution

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

注册监听器的泄漏

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

解决方案：

使用ApplicationContext代替ActivityContext;
在Activity执行onDestory时，调用反注册;

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

Solution：

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

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

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

Solution：

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(); }

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();    } }

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

我们通常把一些对象的引用加入到了集合容器（比如ArrayList）中，当我们不需要该对象时，并没有把它的引用从集合中清理掉，这样这个集合就会越来越大。如果这个集合是static的话，那情况就更严重了。

所以要在退出程序之前，将集合里的东西clear，然后置为null，再退出程序。

解决方案：

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

Solution

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

WebView造成的泄露

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

解决方案：

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

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

初始时ListView会从Adapter中根据当前的屏幕布局实例化一定数量的View对象，同时ListView会将这些View对象缓存起来。

当向上滚动ListView时，原先位于最上面的List Item的View对象会被回收，然后被用来构造新出现的最下面的List Item。

这个构造过程就是由getView()方法完成的，getView()的第二个形参View ConvertView就是被缓存起来的 List Item 的View对象(初始化时缓存中没有View对象则 ConvertView 是null)。

注意事项

为了防止内存泄露，我们应该注意以下几点：

（1）不要让生命周期长的对象引用activity context，即保证引用activity的对象要与activity本身生命周期是一样的.

（2）对于生命周期长的对象，可以使用application context。

（3）避免非静态的内部类，尽量使用静态类，避免生命周期问题，注意内部类对外部对象引用导致的生命周期变化。

关于内存泄漏的调试

(1).内存监测工具 DDMS --> Heap

无论怎么小心，想完全避免bad code是不可能的，此时就需要一些工具来帮助我们检查代码中是否存在会造成内存泄漏的地方。Android tools中的DDMS就带有一个很不错的内存监测工具Heap(这里我使用eclipse的ADT插件，并以真机为例，在模拟器中的情况类似)。用 Heap监测应用进程使用内存情况的步骤如下：

1. 启动eclipse后，切换到DDMS透视图，并确认Devices视图、Heap视图都是打开的；

2. 将手机通过USB链接至电脑，链接时需要确认手机是处于“USB调试”模式，而不是作为“MassStorage”；

3. 链接成功后，在DDMS的Devices视图中将会显示手机设备的序列号，以及设备中正在运行的部分进程信息；

4. 点击选中想要监测的进程，比如system_process进程；

5. 点击选中Devices视图界面中最上方一排图标中的“Update Heap”图标；

6. 点击Heap视图中的“Cause GC”按钮；

7. 此时在Heap视图中就会看到当前选中的进程的内存使用量的详细情况。

说明：

a) 点击“Cause GC”按钮相当于向虚拟机请求了一次gc操作；

b) 当内存使用信息第一次显示以后，无须再不断的点击“CauseGC”，Heap视图界面会定时刷新，在对应用的不断的操作过程中就可以看到内存使用的变化；

c) 内存使用信息的各项参数根据名称即可知道其意思，在此不再赘述。

如何才能知道我们的程序是否有内存泄漏的可能性呢。这里需要注意一个值：Heap视图中部有一个Type叫做dataobject，即数据对象，也就是我们的程序中大量存在的类类型的对象。在data object一行中有一列是“Total Size”，其值就是当前进程中所有Java数据对象的内存总量，一般情况下，这个值的大小决定了是否会有内存泄漏。可以这样判断：

a) 不断的操作当前应用，同时注意观察data object的Total Size值；

b) 正常情况下Total Size值都会稳定在一个有限的范围内，也就是说由于程序中的的代码良好，没有造成对象不被垃圾回收的情况，所以说虽然我们不断的操作会不断的生成很多对象，而在虚拟机不断的进行GC的过程中，这些对象都被回收了，内存占用量会会落到一个稳定的水平；

c) 反之如果代码中存在没有释放对象引用的情况，则dataobject的Total Size值在每次GC后不会有明显的回落，随着操作次数的增多Total Size的值会越来越大，

直到到达一个上限后导致进程OOM被kill掉。

(2).内存分析工具 MAT(Memory Analyzer Tool)

并不是所有的内存泄漏都可以用观察heap size的方法检测出来，因为有的程序只是泄漏了几个对象，而且泄漏的对象个数不会随着程序的运行而增加，这种内存泄漏不会直接导致OOM，但是无用对象无法回收，无疑是对内存的浪费，会影响到程序的性能，我们需要使用MAT工具才能发现这种比较隐蔽的内存泄漏。

使用MAT之前有2个概念是要掌握的：Shallowheap和Retained heap。Shallow heap表示对象本身所占内存大小，一个内存大小100bytes的对象Shallow heap就是100bytes。Retained heap表示通过回收这一个对象总共能回收的内存，比方说一个100bytes的对象还直接或者间接地持有了另外3个100bytes的对象引用，回收这个对象的时候如果另外3个对象没有其他引用也能被回收掉的时候，Retained heap就是400bytes。

NineDays66

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
打赏
0
评论
Android 内存泄漏

Android 内存泄漏分析前言对于C++来说，内存泄漏就是new出来的对象没有delete，俗称野指针；对于Java来说，就是new出来的Object 放在Heap上无法被GC回收；本文通过QQ和Qzone中内存泄漏实例来讲android中内存泄漏分析解法和编写代码应注意的事项。Java 中的内存分配静态储存区：编译时就分配好，在程序整个运行期间都存在。它主要存放静态
复制链接

扫一扫