记一次内存优化的经历

最新推荐文章于 2025-01-14 18:00:00 发布

firtzXu

最新推荐文章于 2025-01-14 18:00:00 发布

阅读量498

点赞数

CC 4.0 BY-SA版权

分类专栏： Android 文章标签：性能优化

本文链接：https://blog.youkuaiyun.com/f409031mn/article/details/80142337

Android 专栏收录该内容

44 篇文章

订阅专栏

本文记录了作者在Android应用中进行内存优化的过程，重点讨论了RecyclerView、TextWatcher和InputMethodManager可能导致的内存泄露问题及其解决方案。针对RecyclerView，可以通过解除Adapter与View之间的引用来修复；TextWatcher内存泄露可以通过设置其active属性避免；InputMethodManager的内存泄露可通过反射、跳转透明Activity或手动删除监听器来解决。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

这几天在使用开源项目 Leakcanary 对 App 的内存泄露进行检测和改善，效果是明显的，这里总结一些让我印象深刻的内存泄露情况。

RecyclerView 引发的内存泄露

这里写图片描述

会发生这种情况的内存泄露，往往都是因为 RecyclerView 的 Adapter 活的比 RecyclerView 要长导致的，解决方法很简单，在 Activity 或 Fragment 的销毁方法里面调用下面的代码:

recyclerView.setAdapter(null);

这样子手动解除RecyclerView 和 Adapter 之间的引用即可修复这次的内存泄露，也看通过继承 RecyclerView ，重写它的 onDetachedFromWindow 方法:

@Override 
protected void onDetachedFromWindow() {
    super.onDetachedFromWindow();
    if (getAdapter() != null) {
        setAdapter(null);
    }
}

TextWatcher 监听引发的内存泄露

这个内存泄露是我第一次遇到的：

这里写图片描述

这个是在公司的三星手机上面收集到的，通过在 Stack Overflow 上面查询，得知这个内存泄露貌似也是只会发生在某些低版本三星设备上面(公司的三星手机是 4.3 版本)，不过上面也给出了解决方法:

给 TextView/EditText 设置 hint 属性，这样子就不会发生内存泄露
解决 TextWatcher 的监听

InputMethodManager 引发的内存泄露

这个是遇到次数最多的内存泄露情况了，这个是这是 Android 输入法的一个 bug，在 15<=API<=23 中都存在，而且比较神奇的话，RecyclerView 偶尔也可以触发这个 bug 。

不过网上关于这个的解决方案也是蛮多的，这里总结一下：

1.通过反射去修复

根据这篇文章的结论，因为是 InputMethodManager 中的 mNextServedView 引用了 Activity，所以最简单的就是通过反射机制将 mNextServedView 置空，也就是赋值为 null，切断了外部的 Activity 引用，从而使 Activity 进行内存回收。

处理方法如下:

public class CleanLeakUtils {

    /**
    * 防止InputMethodManager内存泄漏
    */
    public static void fixInputMethodManagerLeak(Context destContext) {
        if (destContext == null) {
            return;
        }

        InputMethodManager inputMethodManager = (InputMethodManager) destContext.getSystemService(Context.INPUT_METHOD_SERVICE);
        if (inputMethodManager == null) {
            return;
        }

        String [] viewArray = new String[]{"mCurRootView", "mServedView", "mNextServedView"};
        Field filed;
        Object filedObject;

        for (String view:viewArray) {
            try{
                filed = inputMethodManager.getClass().getDeclaredField(view);
                if (!filed.isAccessible()) {
                    filed.setAccessible(true);
                }
                filedObject = filed.get(inputMethodManager);
                if (filedObject != null && filedObject instanceof View) {
                    View fileView = (View) filedObject;
                    //被InputMethodManager持有引用的context是想要目标销毁的
                    if (fileView.getContext() == destContext) { 
                        //置空,破坏掉path to gc节点
                        filed.set(inputMethodManager, null); 
                    } else {
                        //不是想要目标销毁的,即为又进了另一层界面了,不要处理
                        //避免影响原逻辑,也就不用继续for循环了
                        break;
                    }
                }
            }catch(Throwable t){
                t.printStackTrace();
            }
        }
    }
}

创建了一个清除内存泄漏的工具类，然后在 Activity 中 onDestroy 退出时调用上述方法就可以了：

@Override
public void onDestroy(){
  CleanLeakUtils.fixInputMethodManagerLeak(MainActivity.this);
  super.onDestroy();
}

2.跳转到一个透明的 Activity

这个是在 Google 搜索时发现的一个老外写的文章，文章链接如下，需要科学上网:

https://medium.com/@amitshekhar/android-memory-leaks-inputmethodmanager-solved-a6f2fe1d1348

老外的解决方式就是通过在 Activity 执行 finish() 方法之前时跳转一个新的透明 Activity ，然后在透明 Activity 中通过 Handler 发布一个 delay 延迟的消息来 finish 自身，具体原理老外也不清楚，只是通过测试发现这么做就不会再触发这个内存泄露。

创建一个新的 Activity :

public class CleanLeakActivity extends AppCompatActivity{

    private Handler mHandler = new Handler();

    @Override
    public void onCreate(Bundle savedInstanceState){
        super.onCreate(savedInstanceState);
        mHandler.postDelayed(new Runnable() {
            @Override
            public void run() {
                finish();
            }
        },500);
    }

    @Override
    public void onDestroy(){
        mHandler.removeCallbacksAndMessages(null);
        super.onDestroy();
    }
}

然后在 styles.xml 弄一个透明的主题:


    <style name="AppTheme.Transparent" parent="Theme.AppCompat.Light.NoActionBar">
        <item name="android:windowIsTranslucent">true</item>
        <item name="android:windowBackground">@android:color/transparent</item>
        <item name="android:windowContentOverlay">@null</item>
        <item name="windowNoTitle">true</item>
        <item name="android:windowIsFloating">true</item>
        <item name="android:backgroundDimEnabled">false</item>
    </style>

在清单文件给新的 Activity 设置透明主题：

<activity android:name="activity.CleanLeakActivity"
            android:theme="@style/AppTheme.Transparent"
            android:screenOrientation="portrait">
</activity>

那么只要在 Activity 调用 finish() 之前进行跳转即可:

    @Override
    public void onBackPressed() {
        super.onBackPressed();
        startActivity(new Intent(this, CleanLeakActivity.class));
        finish();
    }

由于 CleanLeakActivity 是透明，并且是悬浮窗口样式的，并且会在500毫秒内结束，所以用户察觉不到CleanLeakActivity 的存在。那么它能否真的解决这个内存泄露呢？答案是部分手机可以，小米魅族三星可以解决，但是华为手机的话，下面是我的测试结果：

这里写图片描述

3.手动删除

因为触发这个内存泄露的 View 不是 RecyclerView 就是 EditText，那么我们在页面销毁是手动将这些 View 在页面中 remove 掉，那么是不是也可以解决这个问题呢？

 @Override
 protected void onDestroy() {
   super.onDestroy();
   if (mRecyclerView.getParent() != null && mRecyclerView.getParent() instanceof ViewParent) {
           ((ViewParent) mRecyclerView.getParent()).removeView(mRecyclerView);
   }
}

通过在公司的全部测试手机上面进行检测，发现这么做确实没有再发生 InputMethodManager 的内存泄露了。如果不喜欢使用反射的方法去处理这个内存泄露，那么就使用这个手动把 View 删除的方法吧。