美文网首页Android
内存泄露系列文章(三) - 内存泄露解决方案

内存泄露系列文章(三) - 内存泄露解决方案

作者: 世道无情 | 来源:发表于2018-03-30 08:33 被阅读261次

    前言

    内存泄露系列文章
    内存泄露系列文章(一) - 内存泄露原因及影响
    内存泄露系列文章(二) - 内存泄露监测及分析
    内存泄露系列文章(三) - 内存泄露解决方案

    1. 常见引起内存泄露


    1.1 单例造成的内存泄露

    原因如下:

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

    解决方案:

    1>:对于context,需要使用 getApplicationContext(),而不是 getContext();
    2>:写法需要使用双重校验锁;

    标准单例如下:

    public class SingleTon3 {
    
        // 只有在使用的时候,才会去 new 对象,比较高效
        // 但是会有问题? 多线程并发的问题,如果多线程调用还是会存在多个实例的
    
        // 加上 volatile 好处是什么?
        // 1.防止重新排序
        private static volatile SingleTon3 mInstance ;
    
       /* private SingleTon3(){
        }*/
    
    //    private SingleTon3(Context context){
    //        this.context = context ;
    //    }
    
        private SingleTon3(Context context){
            this.context = context.getApplicationContext() ;
        }
    
        /**
         * 双重校验加同步锁 synchronized:
         *      既保证线程安全,同时也保证效率比较高
         *      但是可能还会有问题,
         */
        public static SingleTon3 getInstance(){
            if (mInstance == null){
                synchronized (SingleTon3.class){    // 这个if只能进来一次,第二次就不会进来了
                    if (mInstance == null){
                        mInstance = new SingleTon3() ;
                    }
                }
            }
            return mInstance ;
        }
    }
    

    1.2 Handler

    相关知识:
    looper对象.png

    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使用非静态内部类导致的,需要注意的是:只要有生命周期长的持有生命周期短的引用,可能会导致内存泄露,

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

    1.4 WebView

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

    如下两种情况:


    图片.png
    图片.png

    分析:
    第一张图是: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条件成立,就不会执行后边的 反注册,这个就是导致内存泄露的原因;

    解决方案如下:

    只要在onDestroy()中先把 webview 从父控件中移除,然后再调用 destroy()方法即可,代码如下:

        @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 判断条件,所以会执行 反注册,就不会内存泄露;

    1.5 ListView、GridView的优化

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

    1.6 拼接字符串

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

    1.7 线程

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

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

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

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

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

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

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

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

    解决方法有两种:
    方法1:去掉 static , 把静态对象改为非静态即可;
    方法2:都用静态内部类,因为静态内部类不会持有所在 Activity的 引用,不会造成内存泄露;

    2. 总结


    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 集合中移除对应的数据,就好了;

    相关文章

      网友评论

        本文标题:内存泄露系列文章(三) - 内存泄露解决方案

        本文链接:https://www.haomeiwen.com/subject/xvgcqftx.html