InputMethodManager引起的内存泄漏问题分析与解决

最新推荐文章于 2022-05-27 15:08:28 发布

专注移动开发技术

最新推荐文章于 2022-05-27 15:08:28 发布

阅读量2.7k

点赞数 1

分类专栏：性能优化文章标签：内存泄漏性能优化

本文链接：https://blog.csdn.net/qq_33275597/article/details/76889940

版权

本文详细分析了由于InputMethodManager导致的内存泄漏问题，并探讨了常见解决方案的不足。通过研究源码，找到mCurRootView和mServedView/mNextServedView作为突破口，利用Java Reflection将它们置空，从而解决内存泄漏。然而，这种方法可能导致输入法无法显示。最后，通过改进方法，在确保不干扰其他界面的情况下，成功修复内存泄漏问题。

摘要由CSDN通过智能技术生成

问题重现：

static InputMethodManager.sInstance

references InputMethodManager.mCurRootView(excluded)

references PhoneWindow$DecorView.mContext

leaks Activity.instance

网上的解决方案：

@Override
public void onDestory() {
//Fix memory leak: http://code.google.com/p/android/issues/detail?id=34731
InputMethodManager imm = (InputMethodManager) getSystemService(Context.INPUT_METHOD_SERVICE);
imm.windowDismissed(this.getWindow().getDecorView().getWindowToken()); // hide method
imm.startGettingWindowFocus(null); // hide method
super.onDestory();
}

这样解决仍然出现下面的问题：

但在实践中使用后,没有真正解决,Activity仍存在,但path to gc指向为unknown.如下图:

图3. Unknownpath

搜索来的代码不管用,就再想办法.

要想让Activity释放掉,思路就是将path togc这个链路剪断就可以.在这个bug中这个链路上有两个节点mContext(DecorView)和mCurRootView(InputMethodManager)可供考虑.下面思路就是从这两个节点中选择一个入手剪断path to gc即可.

阅读源码可知, DecorView继承自FrameLayout,mContext是其上下文环境,牵涉太多,不适合操作入手.mCurRootView在InputMehtodManager中的使用就简单得多了,在被赋值初始化后,被使用的场景只有一次判断及一次日志打印.所以这里选中mCurRootView为突破口.剪断其path to gc的操作为通过Java Reflection方法将mCurRootView置空即可(见文后代码).

编码实现后,再测,发现仍有泄露,但泄露情况有所变化,如下图:

图4. Leak path

新的泄露点为mServedView/mNextServedView,可以通过同样的JavaReflection将其置空,剪断path to gc.但这里有个问题得小心,这里强制置空后,会不会引起InputMethodManager的NullPointerException呢?会不会引起系统内部逻辑崩溃?再次查阅源码,发现mServedView及mNextServedView在代码逻辑中一直有判空逻辑,所以这时就可以放心的强制置空来解决问题了.

图5. 判空逻辑