Fragment中持有Activity实例是否会引发内存泄漏？两种方案是否有效？

嘿，这个问题问得特别实在——很多Android开发者在处理Fragment与Activity交互时，都会碰到这个内存泄漏的困惑，我来给你详细拆解：

首先得明确：直接把Activity赋值给Fragment的成员变量MyActivity act，确实存在内存泄漏风险。因为如果Fragment被某个异步任务（比如后台线程、RxJava订阅）持有强引用，而Fragment又持有Activity的强引用，那么当Activity该被销毁时，GC无法回收它，就会造成内存泄漏。

接下来分析你提到的两种方案：

方案1：在onDestroy()中将act置为null #

• 有效性：在大多数常规场景下是有效的。当Fragment执行onDestroy()时，把成员变量置为null，切断了Fragment对Activity的强引用，这样GC就能正常回收Activity了。
• 合理性：这种方式比较简单，但依赖严格的生命周期管理。如果你有未取消的异步任务还持有Fragment的引用，或者在其他地方不小心保留了act的引用，那么即使在onDestroy()置null，依然会存在泄漏风险。而且如果后续新增了异步逻辑，很容易忘记同步处理这个置null操作，容错性偏低。

方案2：使用WeakReference包裹Activity #

• 有效性：这是更可靠的方案。WeakReference属于弱引用，不会阻止GC回收被引用的对象。当Activity该被销毁时，哪怕Fragment还持有这个WeakReference，GC也能正常回收Activity，从根源上避免了强引用导致的泄漏。
• 合理性：非常合理，也是Android官方推荐的避免此类泄漏的方式之一。不过使用时要注意两点：
  1. 每次调用aMethod()前，必须先通过get()获取Activity实例，并判断是否为null：

     MyActivity activity = act.get();
     if (activity != null) {
         activity.aMethod();
     }
     

  2. 如果调用aMethod()后有异步操作，要确保在Fragment生命周期结束前取消这些操作，避免出现刚判断完非null，Activity就被回收的情况（虽然概率不高，但能提升稳定性）。

额外小建议 #

如果aMethod()是某个业务逻辑的抽象，不妨定义一个接口（比如MyActivityCallback），让Activity实现这个接口，然后Fragment持有该接口的WeakReference。这样不仅能避免内存泄漏，还能降低Fragment与具体Activity的耦合度，代码扩展性更好。

内容的提问来源于stack exchange，提问作者Héctor Valls