问题背景

在开发的一个电商App中，我遇到了一个极其隐蔽的内存泄漏问题。这个Bug导致用户在使用商品详情页多次后，应用内存持续增长，最终引发OOM崩溃，但只在特定厂商设备(特别是华为和OPPO的部分机型)上出现。

问题现象

• 用户浏览5-10个商品详情页后，应用明显变卡顿
• 在华为P30 Pro上，连续操作约15分钟后必现OOM崩溃
• LeakCanary检测不到明显的泄漏点
• 问题在Android 9及以上系统更频繁

排查过程

第一阶段：常规检查

1. 使用Profiler初步分析：发现Activity实例没有正常释放，但无法确定具体引用链
2. 检查常见泄漏点：确认没有静态持有Activity、Handler、匿名内部类等问题
3. 检查第三方库：排除了Glide、RxJava等库的常见问题

第二阶段：深入分析

1. 使用Android Studio的Heap Dump：发现大量DecorView未被释放
2. 分析引用链：发现这些DecorView被InputMethodManager的mNextServedView持有
3. 重现路径：
   • 用户在商品页点击搜索框弹出键盘
   • 快速滑动到其他商品页(触发页面跳转)
   • 键盘动画还未完成时页面已销毁

问题根源

在部分厂商的ROM中，InputMethodManager对输入视图的引用释放存在延迟，当快速切换页面时：

1. 键盘关闭动画尚未完成
2. 新Activity已经创建
3. 系统未正确清除上一个Activity的DecorView引用
4. 导致整个View层级树泄漏

解决方案

临时方案：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

@Override
protected void onDestroy() {
    // 在Activity销毁时强制隐藏键盘
    InputMethodManager imm = (InputMethodManager) getSystemService(Context.INPUT_METHOD_SERVICE);
    View focusView = getCurrentFocus();
    if (focusView != null) {
        imm.hideSoftInputFromWindow(focusView.getWindowToken(), 0);
        focusView.clearFocus();
    }
    super.onDestroy();
}

最终方案：

1. 自定义EditText：重写onDetachedFromWindow方法

1
2
3
4
5
6
7

@Override
protected void onDetachedFromWindow() {
    super.onDetachedFromWindow();
    InputMethodManager imm = (InputMethodManager) context.getSystemService(Context.INPUT_METHOD_SERVICE);
    imm.windowDismissed(getWindowToken());
    clearFocus();
}

2. 添加全局监控：在Application中注册Activity生命周期回调，检测DecorView泄漏

1
2
3
4
5
6
7

registerActivityLifecycleCallbacks(new ActivityLifecycleCallbacks() {
    @Override
    public void onActivityDestroyed(Activity activity) {
        // 使用反射检查InputMethodManager的引用
        checkInputMethodLeak(activity);
    }
});

3. 厂商适配：针对华为/OPPO设备添加特殊处理逻辑

经验总结

1. 厂商差异：不同Android厂商的实现细节可能有重大差异
2. 动画隐患：涉及系统服务的动画操作需要特别小心生命周期
3. 工具组合：单一工具可能无法发现问题，需要结合多种分析手段
4. 防御性编程：对系统服务交互要添加保护性逻辑

这个Bug的解决过程让我深刻理解了Android系统服务的内部工作机制，也学会了如何分析复杂的跨厂商兼容性问题。此后，我在处理任何与输入法相关的UI交互时都会格外注意生命周期管理和内存泄漏防护。