今天在用mat工具检测项目的内存泄漏问题时,检测结果提示有2个内存泄漏,如下图:
CommonUtil是我自己的程序的问题,已修复,但另外一个InputMethodManager的内存泄漏问题着实让我摸不着头脑,因为我在Activity中压根就没用到这个输入法管理器,
那mat怎么会提示有内存泄漏呢?
查了一些资料说:InputMethodManager.mServedView 持有一个最后聚焦View的引用,直到另外的一个View聚焦后才会释放当前的View。当发生GC时mServedView(GCRoot)持有的View的引用不会被回收,导致了内存泄漏。因为这个问题出现的频率比较高,LeakCanary上经常有这个泄漏的弹窗。
解决方案如下:
public static void fixInputMethodManagerLeak(Context destContext) { if (SDK_INT < KITKAT || SDK_INT > 22) { return; } if (destContext == null) { return; } InputMethodManager imm = (InputMethodManager) destContext.getSystemService(Context.INPUT_METHOD_SERVICE); if (imm == null) { return; } String[] arr = new String[]{"mCurRootView", "mServedView", "mNextServedView"}; Field f; Object obj_get; for (int i = 0; i < arr.length; i++) { String param = arr[i]; try { f = imm.getClass().getDeclaredField(param); if (f == null) { return; } f.setAccessible(true); obj_get = f.get(imm); if (obj_get != null && obj_get instanceof View) { View v_get = (View) obj_get; if (v_get.getContext() == destContext) { // 被InputMethodManager持有引用的context是想要目标销毁的 f.set(imm, null); // 置空,破坏掉path to gc节点 } else { // 不是想要目标销毁的,即为又进了另一层界面了,不要处理,避免影响原逻辑,也就不用继续for循环了 break; } } } catch (Throwable t) { t.printStackTrace(); } } }
方案很暴力,使用反射得到InputMethodManager的成员变量(”mCurRootView”, “mServedView”, “mNextServedView”),在将这些Field置空,断掉View与GCRoot的链接。
在MainActivity的onDestroy中使用这个方法后果然解决了InputMethodManager内存泄漏的问题。