SoftReference监听器被GC回收后如何正确处理？

这问题我之前在Android项目里踩过类似的坑——SoftReference在系统内存吃紧（尤其是后台跑重活时）确实会被GC无情回收，导致你错过关键事件。下面是几个经过实践验证的解决思路，你可以根据自己的场景选：

1. 生命周期回调中检查并重新注册监听器 #

这是最直接的兜底方案，利用Activity的生命周期（比如onResume）来定期校验监听器是否存活：

• 每次Activity回到前台时，调用SoftReference.get()检查监听器是否为null
• 如果已经被回收，就重新创建监听器实例并注册到类库
• 注意要避免重复注册，如果类库支持移除操作，注册前先移除旧的引用

示例代码：

private SoftReference<MyCustomListener> mListenerRef;

@Override
protected void onResume() {
    super.onResume();
    MyCustomListener activeListener = mListenerRef != null ? mListenerRef.get() : null;
    
    if (activeListener == null) {
        // 重新创建监听器
        activeListener = new MyCustomListener() {
            @Override
            public void onEventTriggered(EventData data) {
                // 处理你的事件逻辑
                handleEvent(data);
            }
        };
        mListenerRef = new SoftReference<>(activeListener);
        // 注册到类库
        ThirdPartyLibrary.registerListener(activeListener);
    }
}

// 别忘了在销毁时移除监听器，避免内存泄漏
@Override
protected void onDestroy() {
    super.onDestroy();
    MyCustomListener listener = mListenerRef.get();
    if (listener != null) {
        ThirdPartyLibrary.unregisterListener(listener);
    }
}

2. 改用强引用（需权衡内存泄漏风险） #

如果类库允许的话，直接用强引用持有监听器，从根源上避免被GC回收。但一定要注意：

• 必须在Activity销毁时主动调用类库的unregister方法，否则会导致Activity实例被类库持有，引发内存泄漏
• 这种方案适合监听器和Activity生命周期强绑定的场景

示例代码：

private MyCustomListener mPersistentListener;

@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    mPersistentListener = new MyCustomListener() {
        @Override
        public void onEventTriggered(EventData data) {
            handleEvent(data);
        }
    };
    ThirdPartyLibrary.registerListener(mPersistentListener);
}

@Override
protected void onDestroy() {
    super.onDestroy();
    // 必须执行移除操作！
    ThirdPartyLibrary.unregisterListener(mPersistentListener);
}

3. 迁移到Application级别的全局监听器 #

如果监听的事件是全局无关Activity生命周期的，可以把监听器放到Application类中，用强引用持有：

• 监听器在Application启动时注册，一直存活到进程结束
• 当事件触发时，通过LiveData、EventBus或者本地广播通知当前活跃的Activity处理
• 这种方案彻底解决了GC回收问题，还能解耦监听器和Activity

4. 优化后台繁重任务 #

从根源上降低GC触发的概率：

• 把大任务拆分成多个小任务，用WorkManager或合理的线程池调度，避免长时间占用大量内存
• 降低后台任务的优先级，减少对系统内存的消耗
• 及时释放任务中不再需要的对象，减少内存压力

最后提醒一句：SoftReference的回收时机是完全由GC决定的，所以永远不要假设它不会被回收，必须有可靠的兜底逻辑。

内容的提问来源于stack exchange，提问作者remedy.