内存泄露的一些坑

大大大大大先生

发布于 2018-09-04 07:27:07

1.8K00

代码可运行

文章被收录于专栏：移动开发的那些事儿移动开发的那些事儿

运行总次数：0

代码可运行

Activity内部类泄漏

Activity如果存在内部类，无论是匿名内部类，或者是声明的内部类，都有可能造成Activity内存泄漏，因为内部类默认是直接持有这个activity的引用，如果内部类的生命周期比activity的生命周期要长，那么在activity销毁的时候内部类仍然存在并且持有activity的引用，那么activity自然无法被gc，造成内存泄漏

Activity内部Handler

class MyHandler extends Handler {
        
        MyHandler() {
            
        }

        @Override
        public void handleMessage(Message msg) {
            // to do your job
        }
    }
MyHandler myHandler = new MyHandler();

如上，在Activity内部如果声明一个这样的Handler，那么myHandler就默认持有Activity引用，假设Activity退出了，但是可能这时候才有myHandler的任务post，那么Activity是无法被回收的，可以采用以下方式解决：

static class MyHandler extends Handler {
        WeakReference<Activity> mActivityReference;

        MyHandler(Activity activity) {
            mActivityReference = new WeakReference<Activity>(activity);
        }

        @Override
        public void handleMessage(Message msg) {
            final Activity activity = mActivityReference.get();
            if (activity != null) {
                if (msg.what == 1 && isJumpToHomePage) {
                    Intent intent = new Intent(activity, HomePageActivity.class);
//                    intent.putExtra("themeType", themeType);
//                    LogUtil.d("themeType == " + themeType);
                    activity.startActivity(intent);
                    activity.finish();
                }
            }
        }
    }

这里面是把MyHandler是一个内部静态类，静态类在java虚拟机加载的时候就是独立加载到内存中的，不会依赖于任何其他类，而且这里面是把activity以弱引用的方式传到MyHandler中，即便是静态MyHandler类对象一直存在，但是由于它持有的是activity弱引用，在gc回收的时候activity对象是可以被回收的，另外注意一点，对于Handler的使用如果有sendEmptyMessageDelayed()来延迟任务执行的话最好在Activity的onDestroy里面把Handler的任务都移除（removeCallbacks(null)），activity在退出后，就是应该在onDestroy方法里面把一些任务取消掉，做一些清理的操作

Activity内部线程

在Activity里面有时候为了实现异步操作会单独开一个线程来执行任务，或者是异步的网络请求也是单独开线程来执行的，那么就会存在一个问题，如果内部线程的生命周期比Activity的生命周期要长，那么内部线程任然默认持有Activity的引用，导致Activity对象无法被回收，但是当这个线程执行完了之后，Activity对象就能被成功的回收了，这会造成一个崩溃风险，可能在线程里面有调用到一些Activity的内部对象，但是在Activity退出后这些对象有可能有些已经被回收了，就变成null了，这时候要是不进行null的判断就会报空指针异常，如果这个线程是一直跑的，那就会造成Activity对象一直不会被回收了，因此，在activity退出后一定要做相关的清理操作，中断线程，取消网络请求等等

Activity内部类回调监听

在编码中常常会定义各种接口回调，类似有点击时间监听OnClickListener，这些回调监听有时候就定义在Activity内部，或者直接用Activity对象去实现这个接口，到时候设置监听的时候直接调用setListener(innerListener)或者setListener(this)，innerListener是Activity内部定义的，this就是Activity对象，那么问题来了，回调监听并不一定马上返回，只有在触发条件满足的时候才会回调，这个时间是无法确定的，因此在Activity退出的时候应该显示的把回调监听都移除掉setListener(null)，既释放了回调监听对象占用的内存，也避免回调监听继续持有activity引用；对与内部类还有一种解决方式，和内部Handler相似，定义成static内部类，然后把Activity对象的弱引用传递进去，这样也就万无一失，举个项目中遇到的实际场景：

private static class RecorderTimeListener implements TimeCallback {

        WeakReference<ChatActivity> target;

        RecorderTimeListener(ChatActivity activity) {
            target = new WeakReference<>(activity);
        }

        @Override
        public void onCountDown(final int time) {
            if (target == null || target.get() == null) {
                return;
            }
            final ChatActivity activity = target.get();
            activity.runOnUiThread(new Runnable() {

                @Override
                public void run() {
                    activity.volumeView.setResetTime(time);
                }
            });
        }

        @Override
        public void onMaxTime() {
            if (target == null || target.get() == null) {
                return;
            }
            final ChatActivity activity = target.get();
            activity.runOnUiThread(new Runnable() {
                @Override
                public void run() {
                    activity.isMaxTime = true;
                    activity.stopRecord();
                }
            });
        }
    }

private class StartRecorderListener implements StartCallback {


        @Override
        public boolean onWait() {
            cancelRecord();
            return true;
        }

        @Override
        public void onStarted() {
            if (playerManager.isPlaying()) {
                playerManager.stop();
            }
            recordWaveView.setVisibility(View.VISIBLE);
            animation = (AnimationDrawable) recordWaveView.getBackground();
            animation.start();

            volumeView.showMoveCancelView();
            volumeDialog.show();

            viewHandler.postDelayed(volumeRunnable, 100);
        }

        @Override
        public void onFailed(int errorCode) {
            if (errorCode == RecorderManager.ERROR_START_FAIL) {
                showHintDialog(R.string.chat_permission_dialog_title, R.string.chat_permission_dialog_message);
            }
        }
    }

private void startRecord() {
        SystemDateUtil.init(this);
        LogUtil.i(ChatKey.TAG_INFO, "--------------------------录音开始--------------------------");
        final long startSendTime = SystemDateUtil.getCurrentDate().getTime();
        sliceSender = dialogMsgService.createSliceSender(
                AccountUtil.getCurrentFamilyChatDialogId(),
                AccountUtil.getCurrentImAccountId(), new DialogMsgService.OnSendVoiceMsgListener() {
                    @Override
                    public void onSuccess() {
                        LogUtil.d(TAG, "录音上传成功");
                        sendBigData(sliceSender.getGroupId(), ChatMsgBeh.MsgType.EMOJI,
                                SystemDateUtil.getCurrentDate().getTime() - startSendTime, SendMsgEvent.CODE_SEND_SUCCESS);
                    }

                    @Override
                    public void onFailure() {
                        sendBigData(sliceSender.getGroupId(), ChatMsgBeh.MsgType.EMOJI,
                                SystemDateUtil.getCurrentDate().getTime() - startSendTime, SendMsgEvent.CODE_SEND_FAILURE);
                        LogUtil.d(TAG, "录音上传失败");
                    }
                });
        RecorderManager.getInstance(this).startRecorder(sliceSender, new StartRecorderListener(), new RecorderTimeListener(this));
        LogUtil.i(ChatKey.TAG_INFO, "groupId:" + sliceSender.getGroupId());
    }

如上StartRecorderListener是内部类，RecorderTimeListener是静态内部类并传入Activity弱引用，如果把StartRecorderListener的实现改成RecorderTimeListener的实现，那么Activity内存泄漏就不存在了

动画导致内存泄漏

进入Activity界面后如果有一些和控件绑定在一起的属性动画在运行，退出的时候要记得cancel掉这些动画

自定义控件ImageButton中：
public void start(float startAngle, float endAngle) {
        setStop(false);

        final AnimatorSet as = new AnimatorSet();
        final ObjectAnimator oa = ObjectAnimator.ofFloat(this, "progress",
                startAngle, endAngle);
        oa.setDuration(duration);
        oa.setInterpolator(new DecelerateInterpolator(1.1f));
        oa.setRepeatCount(count);
//      oa.setRepeatMode(ObjectAnimator.INFINITE);
        oa.addUpdateListener(new AnimatorUpdateListener() {

            @Override
            public void onAnimationUpdate(ValueAnimator animator) {
                if (stop && as.isRunning()) {
                    as.cancel();
//                    oa.removeAllListeners();
                } else {
                    float p = (float) animator.getAnimatedValue();
                    setProgress(p);
                }
            }
        });
        as.addListener(new AnimatorListenerAdapter() {
            @Override
            public void onAnimationEnd(Animator animation) {
            }
        });
        as.play(oa);
        as.start();
    }
    
    public void cancel() {
        setStop(true);
    }

    public void setStop(boolean stop) {
        this.stop = stop;
        if (stop) {
            setProgress(0.0f);
        }
    }

如上如果不cancel掉属性动画就会一直运行并且一直去执行控件的onDraw方法，那么ImageButton持有了Activity对象，而属性动画ObjectAnimator持有了ImageButton，ObjectAnimator一直在运行，那么Activity对象也就不能被释放了

属性动画的对象尽量不要用static修饰，static修饰和，这个对象一旦被创建那么就一直存在了，属性动画一旦start之后，那么就一直运行，这时候就算退出activity的时候cancel掉动画也仍然会持有activity引用，就像下面这个例子：

private static ValueAnimator valueAnimator;

private void startValueAnimator() {
        int displayTime2Show = displayTime - 1;
        if (displayTime2Show > 1) {
            valueAnimator = ValueAnimator.ofInt(displayTime2Show, 1);
            valueAnimator.setDuration(displayTime2Show * 1000);
            valueAnimator.addUpdateListener(new ValueAnimator.AnimatorUpdateListener() {
                @Override
                public void onAnimationUpdate(ValueAnimator animation) {
                    tvStartPageTime.setText(animation.getAnimatedValue().toString());
                }
            });
            valueAnimator.start();
        }

    }

protected void onPause() {
        if (valueAnimator != null && valueAnimator.isRunning()) {
            valueAnimator.cancel();
            valueAnimator = null;
        }
        super.onPause();
    }

即便是在activity退出后cancel掉动画，activity依然无法被释放，为什么？因为valueAnimator是静态的，而且添加了动画属性改变的监听addUpdateListener，在监听回调里面有tvStartPageTime（TextView）控件，默认持有Activity对象，因此即便Activity退出，动画cancel掉也无法释放持有的引用，修改方法有两种，一种是把valueAnimator的static修饰去掉，另一中国是：

protected void onPause() {
valueAnimator.removeAllUpdateListeners();
        if (valueAnimator != null && valueAnimator.isRunning()) {
            valueAnimator.cancel();
            valueAnimator = null;
        }
        super.onPause();
    }

加一句监听器的移除代码removeAllUpdateListeners()

传Context参数的时候使用Activity对象造成内存泄漏

在android中常常会用到Context环境变量，Activity继承了Context，所以在传入Context的时候常常直接在Activity中传入this即Activity本对象，这是比较不好的习惯，在没有规定一定要传Activity对象的时候尽量采用全局的Context对象，即ApplicationContext来作为参数传递进去，因为ApplicationContext只要app在运行那么它就一直存在，因此即便有一个对象长期引用它，生命周期也不会比ApplicationContext长，所以不会造成ApplicationContext的内存泄漏，因为ApplicationContext只要App在运行就不允许被回收
在Android程序中要慎用单例，如果单例需要传Context对象，那么就需要谨慎了因为在单例中如果把Context保存起来，那么这个单例一旦被创建，就一直存在了，如果传入的是Activity对象，那将一直持有Activity对象引用导致内存泄漏，解决版本是传入ApplicationContext对象，或者在Activity退出的时候销毁这个单例对象，单例在什么时候时候使用，如果一个对象并不会被频繁的调用，那就没必要用单例，对于可能会被频繁调用的对象方法可以采用单例，这样做可以避免反复创建对象和gc对象造成的内存抖动；对于需要保存的全局变量也可以用单例封装起来；单例只要创建了就一直有存在引用，所以是不会被gc的
使用静态变量来保存Activity对象，这是一个非常不好的编码习惯，static修饰的代码片段，变量或者类是在app加载的时候就已经加载到内存中了，所以和单例有点相似，static变量也会一直持有Activity对象直到APP被杀死或者显示的把static变量置空

在Android5.0以上的WebView泄漏

如果Activity引用了WebView控件来加载一个网页或者加载一个本地的网页，在退出activity之后即便你调用了webView.destroy()方法，也无法释放webview对于activity持有的引用，原因和解决方案可参考Android5.1的WebView内存泄漏，如这篇文章所分析的解决方案确实有效，亲测可用！

子线程中不当的使用Looper.prepare()和Looper.loop()方法造成内存泄漏

Looper.loop()是一个无限循环的方法，它是反复的去MessageQueue里面去取出Message并分发给对应的Handler去执行，如果在子线程中调用了Looper.prepare()和Looper.loop()方法，Looper.loop()会导致这个线程一直不死，一直堵在这里，因此线程就无法结束运行，在Looper.prepare()和Looper.loop()之间的所有对象都没办法被释放，解决方案就是在不用的时候及时的把Looper给quit掉

EditText使用setTransformationMethod导致的内存泄漏

这个问题只有在4.0的android系统上才会存在，在5.0以上的系统已经不存在了，应该是属于Android的一个缺陷

这里写图片描述问题的根源应该就是这：

loginPasswdEt.setTransformationMethod(PasswordTransformationMethod.getInstance());
loginPasswdEt.setTransformationMethod(HideReturnsTransformationMethod.getInstance());

而PasswordTransformationMethod和HideReturnsTransformationMethod分别都是一个单例：

private static PasswordTransformationMethod sInstance;

private static HideReturnsTransformationMethod sInstance;

PasswordTransformationMethod

public CharSequence getTransformation(CharSequence source, View view) {
        if (source instanceof Spannable) {
            Spannable sp = (Spannable) source;

            /*
             * Remove any references to other views that may still be
             * attached.  This will happen when you flip the screen
             * while a password field is showing; there will still
             * be references to the old EditText in the text.
             */
            ViewReference[] vr = sp.getSpans(0, sp.length(),
                                             ViewReference.class);
            for (int i = 0; i < vr.length; i++) {
                sp.removeSpan(vr[i]);
            }

            removeVisibleSpans(sp);

            sp.setSpan(new ViewReference(view), 0, 0,
                       Spannable.SPAN_POINT_POINT);
        }

        return new PasswordCharSequence(source);
    }
    
private static class ViewReference extends WeakReference<View>
            implements NoCopySpan {
        public ViewReference(View v) {
            super(v);
        }
    }

上面是5.0系统的源码，里面已经用ViewReference来包装view设置到Spannable中了，所以是把view的弱引用传进去了，因此可以被gc回收，而在4.0android系统上，很可能就不是这么做的，所以4.0系统上面就是View对象被PasswordTransformationMethod和HideReturnsTransformationMethod单例长期持有，而View又持有Activity对象，所以针对4.0系统我们只需要释放这两个单例对象即可：

private void releaseMemoryLeak() {
        int sdk = Build.VERSION.SDK_INT;
        if (sdk >= Build.VERSION_CODES.LOLLIPOP) {
            return;
        }
        try {
            Field field1 = PasswordTransformationMethod.class.getDeclaredField("sInstance");
            if (field1 != null) {
                field1.setAccessible(true);
                field1.set(PasswordTransformationMethod.class, null);
            }
            Field field2 = HideReturnsTransformationMethod.class.getDeclaredField("sInstance");
            if (field2 != null) {
                field2.setAccessible(true);
                field2.set(HideReturnsTransformationMethod.class, null);
            }
        } catch (NoSuchFieldException e) {
            SyncLogUtil.e(e);
        } catch (IllegalAccessException e) {
            SyncLogUtil.e(e);
        }
    }

加上上述代码后验证发现内存不再泄漏，搞定。

控件的BackGround导致的内存泄漏（4.0android系统已经解决）

有时候为了避免图片反复的加载，就把第一次加载后的Bitmap或者Drawable用静态变量保存起来，但是要是把这种静态修饰的图片对象设置成控件的背景，那就呵呵了

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

因为在View的setBackgroundDrawable方法里面有一句：

public void setBackgroundDrawable(Drawable background) {
......省略很多代码
background.setCallback(this);
mBackground = background;
}

Drawable对象把View对象作为回调保存起来了，不过在4.0系统以后引入回调来保存View对象了，所以已经不会造成内存泄漏问题了：

public final void setCallback(Callback cb) {
        mCallback = new WeakReference<Callback>(cb);
    }

这里依然要举例子出来是想说明不恰当的使用static来修饰变量很有可能导致对象无法被回收

本文参与腾讯云自媒体同步曝光计划，分享自作者个人站点/博客。

原始发表：2017.09.08 ，如有侵权请联系 cloudcommunity@tencent.com 删除

存储

本文分享自作者个人站点/博客前往查看

如有侵权，请联系 cloudcommunity@tencent.com 删除。

本文参与腾讯云自媒体同步曝光计划，欢迎热爱写作的你一起参与！

存储

登录后参与评论

0 条评论

热度