内存泄露

最新推荐文章于 2024-05-26 12:09:57 发布

置顶 LvLuffy

最新推荐文章于 2024-05-26 12:09:57 发布

阅读量346

点赞数

分类专栏： Android常见问题文章标签： android 内存泄漏

本文链接：https://blog.csdn.net/LvLuffy/article/details/103602248

版权

Android常见问题专栏收录该内容

9 篇文章 0 订阅

订阅专栏

1. 内存泄露原因

当一个对象不再被使用，在回收时另一个正在使用的对象持有它的引用导致本该被回收的对象不能被回收而留在堆内存中，就产生了内存泄露。
说白了，该对象无法被回收的原因就是被一个生命周期更长的对象引用了。

其实内存泄露就是一句话，生命周期较长的对象持有生命周期较短的引用。

2. 内存泄露影响

1>：Android系统给每个应用程序分配内存有限，如果app超过系统分配给它的内存，造成OOM内存溢出；

2>：大量的内存泄露，引起Crash，可能会频繁GC（频繁的垃圾回收）；

3>：GC都是耗时的操作，导致app非常卡顿、手机卡顿。

3. GC的垃圾回收问题

3-1：概述

在c、c++中，只要你new开辟了内存，就一定要记得手动free释放，如果不及时的释放，那么越到后边就会发现内存越用越少，直至项目崩溃为止。c、c++可以申请比java大的内存空间，但是需要手动释放内存，而java不需要手动。

3-2：问题

在java中：

1>：如果该对象没有被使用（即就是没有被引用），就会被回收。

2>：可以手动调用System.gc()回收，如果内存足够的时候，它并不会马上去回收，一旦当内存不足的时候，就肯定会触发System.gc()去回收。

3>：gc()是多线程，是一个异步的，调用它的时候，会停止正在运行的其他线程，在调用gc的时候界面会很卡，就是因为它在回收的时候会把其他线程都停掉，等回收完一个线程后再去执行另一个线程。很多时候界面卡顿，就是由于gc正在回收。

4>：内存泄露往往就是对象后面不会用到了，但是另外某个对象还持有该对象的引用。

3-3：解决的套路

一般就关心Activity、Service、View，主要关心这几个是否可以被回收：

1>：比如连续跳转多个Activity，就去关注Activity有没有被回收，如果Activity没有被回收，可能就是因为某个对象持有该Activity的引用，可能是单例持有Activity的引用，就是因为我们在单例中传递的是this，不要传递this，传递context.getApplicationContext()；

2>：然后点击back返回键回退到MainActivity，按理来讲，应该就只有一个activity的实例了，如果你发现还有多个activity实例，代表activity还没有被回收。

4. 常见引起内存泄露

4-1：单例造成的内存泄露

原因如下：

因为单例与app生命周期一样，且单例对象持有该Activity的引用，导致Activity退出时无法回收该Activity，造成内存泄露；

解决方案：

1>：对于context，需要使用 getApplicationContext()，而不是 getContext()；

2>：写法需要使用双重校验锁。

4-2：Handler

相关知识
在这里插入图片描述
1>：如上图，在app启动时，frameworks会在主线程中创建一个Looper对象，其生命周期与app一样长，作用就是专门处理消息队列中的消息对象，而消息对象可以是任何页面中需要处理的消息，如Activity的生命周期的方法、按钮点击事件、延迟消息等，凡是某个具体类中所涉及到需要处理的事件都是消息对象；

2>：当在主线程中初始化handler对象时，handler就会与looper的消息队列发生关系，当消息被发送到looper的消息队列时，会持有handler的引用，目的是可以调用 handler.handleMessage(Message msg)处理消息；

3>：在java中，非静态内部类和匿名内部类都会隐式持有外部类引用，即就是所在的Activity，静态内部类不持有外部类引用。

下边第二段代码意思：

当MainActivity被finish()时，延迟任务在主线程中存在10分钟，且这个消息中包含handler引用，而handler是一个内部类，会持有外部类MainActivity引用，所以会在gc垃圾回收器回收垃圾时MainActivity不能及时回收，导致内存泄露。

Handler mHandler = new Handler() {
    @Override
    public void handleMessage(Message msg) {
        mImageView.setImageBitmap(mBitmap);
    }
}

 public class MainActivity extends AppCompatActivity {

        private Handler mLeakHandler = new Handler(){
        @Override
        public void handleMessage(Message msg) {

        }
    };

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        //发送延时消息
        mLeakHandler.postDelayed(new Runnable() {
            @Override
            public void run() {

            }
        }, 1000 *60 *10);
        finish();
        }
    }

解决方案如下：

1>：把handler对象创建成静态内部类，因为静态内部类不持有外部类MainActivity的引用，因此这个MainActivity就不会出现内存泄露问题；

2>：如果有Runnable，同样可以把Runnable设置成静态内部类，因为静态内部类不会出现内存泄露问题；

3>：如果handler内部需要调用外部类MainActivity的方法，可以让handler持有外部类MainActivity的WeakReference 弱引用，就不会出现内存泄露问题了；

4>：如果使用handler发送循环消息，可以在 onDestroy()中调用 handler.removeCallbacksAndMessages(null)；

弱引用（WeakReference）：

public class SplashActivity extends AppCompatActivity {
    MyHandler myHandler;
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_splash);

        myHandler = new MyHandler(this);
        myHandler.postDelayed(new Runnable() {
            @Override
            public void run() {
                initJump();
            }
        }, 2000);
    }

    private void initJump() {
        ...
    }

    static class MyHandler extends Handler {
        private final WeakReference<SplashActivity> mActivty;

        public MyHandler(SplashActivity activity){
            mActivty =new WeakReference<SplashActivity>(activity);
        }

        @Override
        public void handleMessage(Message msg) {
            SampleActivity activity = mActivity.get();
            if (activity != null) {
               //to Something
            }
        }
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        if(myHandler != null){
            myHandler.removeCallbacksAndMessages(null);
            myHandler = null;
        }
    }
}

静态的：

//定义成static的，因为静态内部类不会持有外部类的引用
  private final MyHandler mHandler = new MyHandler(this);
  private static final Runnable sRunnable = new Runnable() {
      @Override
      public void run() {//to something}
  };

  @Override
  protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    mHandler.postDelayed(sRunnable, 1000 * 60 * 10);
    finish();
  }
}

其实Android中出现大部分内存泄露都是Activity使用非静态内部类导致的，需要注意的是：

只要有生命周期长的持有生命周期短的引用，可能会导致内存泄露。

4.3 BannerView或者ViewPager

在某个页面显示 BannerView 或者 ViewPager 时，需要复用View，并且在轮播图页面显示轮播图，在关闭轮播图页面时让其停止轮播，这样做可以避免内存泄露。

解决方案如下：

可以在开始轮播onResume时候调用 bannerView.onResume让其开始轮播，在停止轮播onPause时候调用 bannerView.onPause让其停止轮播。

    @Override
    public void onPause() {
        super.onPause();
        if (banner != null) {
            banner.pause();
        }
    }


    @Override
    public void onResume() {
        super.onResume();
        if (banner != null) {
            banner.resume();
        }
    }

4.4 WebView

对于WebView页面，多次进入，多次退出，内存占用会比较大，gc频繁，使用LeakCanary可以检测；

如下两种情况：
在这里插入图片描述

分析：

第一张图是：mAccessibilityStateChangeListeners 导致 activity 不能被回收。

第二张图是：mComponentCallbacks 导致 activity 不能被回收。

1>：首先看 mAccessibilityStateChangeListeners是什么时候注册的？在 AccessibilityManager类中有两个方法：

AccessibilityManager源码中：

private final CopyOnWriteArrayList<AccessibilityStateChangeListener>
            mAccessibilityStateChangeListeners = new CopyOnWriteArrayList<>();

   /**
     * Registers an {@link AccessibilityStateChangeListener} for changes in
     * the global accessibility state of the system.
     *
     * @param listener The listener.
     * @return True if successfully registered.
     */
    public boolean addAccessibilityStateChangeListener(
            @NonNull AccessibilityStateChangeListener listener) {
        // Final CopyOnWriteArrayList - no lock needed.
        return mAccessibilityStateChangeListeners.add(listener);
    }

    /**
     * Unregisters an {@link AccessibilityStateChangeListener}.
     *
     * @param listener The listener.
     * @return True if successfully unregistered.
     */
    public boolean removeAccessibilityStateChangeListener(
            @NonNull AccessibilityStateChangeListener listener) {
        // Final CopyOnWriteArrayList - no lock needed.
        return mAccessibilityStateChangeListeners.remove(listener);
    }

在 ViewRootImpl 的构造方法初始化时会调用 addAccessibilityStateChangeListener会 add 添加一个 listener，在调用 dispatchDetachedFromWindow 时会 remove 移除这个 listener，虽然会 remove 这个 listener，还是会导致内存泄露，原因看下边；

ViewRootImpl源码：

public ViewRootImpl(Context context, Display display) {
        mAccessibilityManager.addAccessibilityStateChangeListener(
                mAccessibilityInteractionConnectionManager);
    }
void dispatchDetachedFromWindow() {
        mAccessibilityManager.removeAccessibilityStateChangeListener(
                mAccessibilityInteractionConnectionManager);
    }

2>：然后看 mComponentCallbacks 在什么时候注册？

在Application源码中：

public void registerComponentCallbacks(ComponentCallbacks callback) {
        synchronized (mComponentCallbacks) {
            mComponentCallbacks.add(callback);
        }
    }

    public void unregisterComponentCallbacks(ComponentCallbacks callback) {
        synchronized (mComponentCallbacks) {
            mComponentCallbacks.remove(callback);
        }
    }

AwContents中注册：

        @Override
        public void onAttachedToWindow() {
            if (isDestroyed()) return;
            mContext.registerComponentCallbacks(mComponentCallbacks);
        }
        @Override
        public void onDetachedFromWindow() {
            if (isDestroyed()) return;
            if (mComponentCallbacks != null) {
                mContext.unregisterComponentCallbacks(mComponentCallbacks);
                mComponentCallbacks = null;
            }
        }

由上边代码可以看出：在 onAttachedToWindow()中注册，在 onDetachedFromWindow()中反注册，但是在 onDetachedFromWindow()中有一个前提条件，就是 if(isDestroyed()) return ，意思就是如果isDestroyed条件成立，就不会执行后边的反注册，这个就是导致内存泄露的原因。

解决方案如下：

    @SuppressLint("SetJavaScriptEnabled")
    @Override
    protected void onResume() {
        super.onResume();
        if (mWebView != null) {
            mWebView.getSettings().setJavaScriptEnabled(true);
        }
    }

    @Override
    protected void onStop() {
        super.onStop();
        if (mWebView != null) {
            mWebView.getSettings().setJavaScriptEnabled(false);
        }
    }

    @Override
    protected void onDestroy() {
        if (mWebView != null) {
            mWebView.clearHistory();
            ViewGroup parent = (ViewGroup) mWebView.getParent();
            if (parent != null) {
                parent.removeView(mWebView);
            }
            mWebView.removeAllViews();
            mWebView.destroy();
            mWebView = null;
        }
        super.onDestroy();
    }

对于5.1以下的机型，不会出现内存泄露，原因就是4.4的AwContents源码中onDetachedFromWindow()方法中没有 isDestroyed 这个 if 判断条件，所以会执行反注册，就不会内存泄露；

4.5 ListView、GridView的优化

需要写一个ViewHolder、复写convertView、分页加载；

4.6 拼接字符串

对于拼接的字符串，用StringBuffer而不是String，因为String每赋值一次，就会重新分配一次内存，例如：String str = str1 + str2 + str3 + str4 + str5；每多一个 “+” ，就会多创建一个对象；

4.7 线程

不使用的时候及时关闭，不要开太多线程，推荐使用线程池；

4.8 注册、反注册未成对使用引起的内存泄露

比如广播接收器、EventBus，都需要有注册、反注册，如果少一个，可能导致内存泄露，一般是在onCreate()、onResume()方法中注册，onDestroy()、onPause()中反注册；

4.9 一些资源对象没有关闭或释放

比如Cursor、File、Bitmap，当我们确保不再使用这些资源时，在try…cache…finally…中的finally语句中调用cursor.close()、file.close()、bitmap.recycler()并且置为null；

4.10 集合中对象没有及时清理

比如：我们经常把一些对象添加到集合，在不使用的时候要记得清理集合，让相关对象不再被引用，如果集合是static的、又没有及时去清理集合，肯定会引起内存泄露；

4.11 非静态内部类或者匿名内部类造成的内存泄露

解决方法有两种：

1>：去掉 static ，把静态对象改为非静态即可。

2>：都用静态内部类，因为静态内部类不会持有所在 Activity的引用，不会造成内存泄露。

总结

1>：handler持有的引用最好使用弱引用，在Activity被清空的时候记得调用handler.removeCallbacksAndMessages(null);清空Message；

2>：对于单例设计模式，不要用getContext()，用 getApplicationContext()，并且使用双重校验锁；

3>：非静态内部类、非静态匿名内部类可以都用静态内部类，因为静态内部类不会持有所在 Activity 的引用，不会发生内存泄露；

4>：对于生命周期比Activity长的，不要使用Activity的context，可以去使用getApplicationContext()，比如Handler与Runnable生命周期比MainActivity长，其实可以在任意需要使用 getContext()的地方都使用getApplicationContext()，除过一些场景不能使用的，比如dialog中必须使用 getActivity()；

5>：对于广播接收器、EventBus的使用，必须是注册、反注册成对出现的；

6>：不再使用的资源对象，比如cursor、File、Bitmap对象，记得及时调用close()、recycler()方法关闭和释放；

@Override
    public void onDestroy() {
        super.onDestroy();
        if (guideBmp != null && !guideBmp.isRecycled()) {
            guideBmp.isRecycled();
            guideBmp = null;
        }
    }

7>：对于 List集合中添加的东西，就必须有相应的删除，这个使用场景是：
比如客户端需要在 activity 或者 fragment 中显示列表数据，而在请求服务器接口时，服务器返回的是list 集合，我们可能会自己在所在的类中自定义一个listDatas集合，把接口返回的 list 集合添加到 listDatas集合中，然后给列表显示数据，在某些特殊需求的时候，如果出现数据重复，可能原因就是你只是给 list集合中添加数据了，没有在页面销毁或者其他某些状态从list集合中移除数据，从集合中对应移除数据，可能列表数据就不会重复了。

千万注意：

1>：使用注册、反注册的必须成对出现；

2>：对于cursor、file、bitmap，必须在finally、onDestroy()中调用close()、recycler()方法关闭和释放；

3>：在使用 list 集合存储数据时，如果出现数据重复，绝大部分原因就是，你只是给 list 集合添加数据了，没有从list移除数据，可能需要你在某些状态下从 list 集合中移除对应的数据，就好了。

LvLuffy

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
内存泄露

1. 内存泄露原因当一个对象不再被使用，在回收时另一个正在使用的对象持有它的引用导致本该被回收的对象不能被回收而留在堆内存中，就产生了内存泄露。说白了，该对象无法被回收的原因就是被一个生命周期更长的对象引用了。其实内存泄露就是一句话，生命周期较长的对象持有生命周期较短的引用。2. 内存泄露影响1>：Android系统给每个应用程序分配内存有限，如果app超过系统分配给它的内存，造成...
复制链接

扫一扫

专栏目录