在Fragment中显示Toast：使用getActivity()还是缓存mActivity引用更优？

嘿，这个问题问得挺细致的！咱们来拆解一下两种写法的差异和优劣：

1. 性能层面：差异可以忽略不计 #

首先得说，getActivity()本身是个非常轻量的方法——它只是从Fragment内部维护的宿主引用中直接返回Activity实例，没有复杂的计算或者IO操作。所以哪怕你每次调用Toast都用getActivity()，额外的开销几乎感知不到，和缓存到mActivity的性能差异完全可以忽略。毕竟Toast的创建、布局加载和显示流程本身的开销，比这几次方法调用大得多。

2. 安全与生命周期层面：直接调用更稳妥 #

这才是核心差异！Fragment的生命周期是完全依附于Activity的：当Fragment被销毁、和Activity解除关联（比如屏幕旋转导致Activity重建、App进入后台被系统回收）时，getActivity()会返回null。

如果你直接缓存mActivity却不做生命周期管理，很容易出现两个问题：

• 内存泄漏：持有一个已经被销毁的Activity实例引用，导致系统无法回收它，浪费内存。
• 空指针异常：当Fragment已经和Activity解除关联时，mActivity还是旧的引用（或者已经变成null），调用Toast.makeText(mActivity...)会直接崩溃。

而每次调用getActivity()，系统会实时返回当前Fragment关联的有效Activity实例（如果存在的话），反而能避免这些风险。

3. 要是真想缓存，得配合生命周期管理 #

如果出于代码习惯或者某些特殊场景想缓存Activity引用，一定要在Fragment的生命周期方法里正确维护这个变量：

private Activity mActivity;

@Override
public void onAttach(@NonNull Activity activity) {
    super.onAttach(activity);
    // 关联时赋值
    mActivity = activity;
}

@Override
public void onDetach() {
    super.onDetach();
    // 解除关联时置空，避免内存泄漏
    mActivity = null;
}

但即使这样做，性能上的提升依然微乎其微，主要是为了代码整洁。如果只是Toast这种简单场景，完全没必要多这一步。

总结 #

对于Toast这种场景，直接用getActivity()更安全、更省心，没有性能上的顾虑。缓存mActivity不仅没有明显收益，还可能带来内存泄漏或空指针的风险——除非你能严格按照Fragment生命周期来维护这个引用。

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