将Activity、Fragment或View传入静态方法是否会引发内存问题？

咱们先看这两个静态方法示例：

public static void doSomething(Activity aActivity){ 
    // do Something With The Activity 
}

public static void doSomething(View aView){ 
    // do Something With The View 
}

针对你提出的三个内存相关疑问，我来逐一拆解：

1. 从内存使用层面考量，将Activity或Fragment传入静态方法是否属于不良实践？该做法是否会使相关引用在应用生命周期内持续存活？ #

其实核心问题不是把Activity/Fragment传入静态方法这个动作本身，而是要看静态方法内部怎么处理这个引用：

• 如果只是在方法执行期间临时使用这个对象，方法执行完毕后没有把它赋值给任何静态成员变量或者长生命周期的对象，那完全没问题——方法执行完，这个临时引用就会被回收，不会让Activity/Fragment一直存活。
• 但如果在静态方法里把Activity/Fragment赋值给了一个静态变量，那麻烦就来了：静态变量属于类本身，生命周期和整个应用进程一致，哪怕Activity/Fragment已经被销毁，静态变量还拽着它的引用，导致GC无法回收，直接造成内存泄漏。所以这种持有才是不良实践，和“传入静态方法”无关。

2. 上述接收View的静态方法是否会导致View的引用在应用生命周期内一直存活？ #

和上面的逻辑一样，关键看静态方法内部的操作：

• 要是只是在方法里临时用一下View，执行完就没其他地方持有它的引用，那View会在它本该被回收的时候（比如所在Activity销毁、View从布局中移除）正常被GC处理，不会一直存活。
• 但如果静态方法把View存到了静态变量里，那View会被长期持有，而且View本身会引用它所在的Context（通常是Activity），连带Activity也没法被回收，最终造成连锁的内存泄漏。

3. 若频繁使用这两个示例中的方法，是否会引发内存泄漏或OOM（内存不足）问题？ #

这还是取决于方法的实现逻辑：

• 如果方法只是临时使用传入的对象，没有长期持有引用，那哪怕频繁调用也不会有问题——每次调用都是临时创建的引用，方法执行完就释放，GC会正常清理这些对象，不会积累内存占用。
• 但如果方法内部存在不当的引用持有（比如存静态变量），那每调用一次可能就会多一个无法被回收的对象，随着调用次数增加，泄漏的内存会越来越多，最终导致内存泄漏，严重时就会触发OOM。

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