内存泄露的一些坑
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 删除
评论
登录后参与评论
推荐阅读
目录
相关产品与服务
对象存储
对象存储（Cloud Object Storage，COS）是由腾讯云推出的无目录层次结构、无数据格式限制，可容纳海量数据且支持 HTTP/HTTPS 协议访问的分布式存储服务。腾讯云 COS 的存储桶空间无容量上限，无需分区管理，适用于 CDN 数据分发、数据万象处理或大数据计算与分析的数据湖等多种场景。