在Android应用开发中，Fragment与Activity之间的通信是组件化架构里绕不开的话题。Fragment虽然可以独立承载UI，但很多业务动作需要通知宿主Activity执行，例如更新标题栏、切换页面或者发起网络请求。反过来，Activity也可能需要主动向Fragment传递数据或指令。由于Fragment生命周期比Activity更复杂，选择不合适的通信方式容易引发空指针、内存泄漏或数据丢失。下面梳理五种常见且实用的通信方案，并结合代码说明各自的适用场景与取舍。
一、直接获取宿主Activity实例
这是最直观的一种做法。在Fragment内部通过getActivity()拿到宿主Activity引用，强制转换成具体的Activity类型后调用其公共方法。getActivity()返回的是Activity基类对象，如果宿主Activity是MainActivity，就需要用instanceof判断再强转。这种方案实现成本极低，不需要任何额外接口或组件，适合临时调试或小型项目里快速打通逻辑。
但它的缺点也很突出。Fragment与具体的Activity类型形成了强耦合，Fragment无法在其他Activity中复用；一旦getActivity()在Fragment生命周期早期或销毁后返回null，直接使用就会抛出空指针异常。为了规避这个问题，通常会在onAttach()中保存Activity引用，并在onDetach()中置空。即便如此，这种写法依然不推荐作为长期维护方案，因为它违背了组件解耦原则，后期修改Activity类名或重构结构时容易引入隐藏风险。
public class MyFragment extends Fragment {
public void updateActivityTitle(String title) {
Activity activity = getActivity();
if (activity instanceof MainActivity) {
((MainActivity) activity).setTitle(title);
}
}
}
可以看到，代码里需要明确知道宿主Activity是MainActivity类型，并且调用其setTitle()方法。如果项目里只有一处这样调用还能接受，一旦多个Fragment都依赖同一宿主Activity的多个方法，维护成本会迅速上升。因此这种方法只适合非常简单的场景或作为临时代码，不值得在正式架构中铺开使用。
二、接口回调：经典解耦方案
接口回调是Android官方早期推荐的解耦方式。思路是在Fragment中定义一个回调接口，宿主Activity实现这个接口。Fragment在onAttach()回调中通过context参数将宿主Activity转换为接口类型并保存。这样Fragment只依赖接口，不依赖具体Activity类，实现了面向接口编程，提高了复用性和可测试性。
使用接口回调时要注意两个细节。第一，在onAttach()中判断context是否实现了接口，如果没有实现，最好主动抛出异常，这样能在开发阶段尽早发现问题。第二，必须在onDetach()中将接口引用置空，避免Fragment销毁后仍然持有Activity引用导致内存泄漏。接口回调非常适合一对一的通信关系，比如Fragment点击按钮后通知Activity跳转页面或更新工具栏。
public class MyFragment extends Fragment {
public interface OnFragmentInteractionListener {
void onMessageFromFragment(String message);
}
private OnFragmentInteractionListener listener;
@Override
public void onAttach(@NonNull Context context) {
super.onAttach(context);
if (context instanceof OnFragmentInteractionListener) {
listener = (OnFragmentInteractionListener) context;
} else {
throw new RuntimeException(context.toString() + " must implement OnFragmentInteractionListener");
}
}
private void sendMessage() {
if (listener != null) {
listener.onMessageFromFragment("来自Fragment的消息");
}
}
@Override
public void onDetach() {
super.onDetach();
listener = null;
}
}
宿主Activity实现接口后，重写onMessageFromFragment()即可接收消息。这种写法清晰易懂，但接口数量增多后会让Activity实现很多接口，代码会变得繁琐。如果Fragment和Activity之间需要传递的数据很复杂或者存在多个Fragment共享数据，接口回调就显得力不从心，此时可以考虑ViewModel方案。
三、共享ViewModel
ViewModel是Android Jetpack的核心组件之一，利用ViewModelProvider可以在Fragment和Activity之间共享同一个ViewModel实例。具体做法是在Fragment中使用requireActivity()作为ViewModelStoreOwner去获取ViewModel，这样拿到的ViewModel和Activity获取到的是同一个对象。ViewModel内部持有LiveData或MutableLiveData，Fragment和Activity分别观察数据变化，实现数据驱动通信。
共享ViewModel最大的优势是生命周期安全。ViewModel独立于界面控制器，当设备旋转导致Activity重建时，ViewModel不会被销毁，数据得以保留。同时，使用LiveData观察数据时，观察者会在生命周期活跃状态下收到更新，有效避免空指针和内存泄漏。这种方案非常适合MVVM架构，也是目前Android官方推荐的主流做法。
public class SharedViewModel extends ViewModel {
private final MutableLiveData<String> selectedItem = new MutableLiveData<>();
public void setSelectedItem(String item) {
selectedItem.setValue(item);
}
public LiveData<String> getSelectedItem() {
return selectedItem;
}
}
在Fragment中获取共享ViewModel并观察数据只需要两行核心代码。调用viewModel.setSelectedItem()时，观察者就能在回调中收到更新。由于ViewModel的作用域绑定在Activity上，只要Activity存在，ViewModel中的数据就能被所有关联Fragment访问。这种方案彻底摆脱了接口依赖，但需要引入Jetpack依赖，项目结构也要向MVVM方向靠拢，如果是传统MVC项目改造起来可能有一定成本。
四、Fragment Result API
Fragment Result API是AndroidX Fragment 1.3.0引入的官方推荐方式，专门用于在Fragment之间或Fragment与Activity之间传递一次性结果。它的设计类似startActivityForResult()，但避免了手动管理请求码和引用。发送方调用setFragmentResult()，接收方提前注册setFragmentResultListener()，通过唯一的requestKey进行匹配。
这套API的优势在于生命周期安全，监听器在Fragment或Activity的生命周期结束时会自动清理，不需要手动反注册。而且发送方和接收方完全不需要持有对方引用，解耦程度很高。当需要从Fragment向Activity回传数据时，可以在Activity中通过getSupportFragmentManager()注册监听器，接收Fragment使用同一个FragmentManager设置结果。这种方案适合一次性事件，比如弹窗选择日期后返回结果、列表项点击后回传详情等。
public class SenderFragment extends Fragment {
@Override
public View onCreateView(LayoutInflater inflater, ViewGroup container,
Bundle savedInstanceState) {
View view = inflater.inflate(R.layout.fragment_sender, container, false);
view.findViewById(R.id.send_button).setOnClickListener(v -> {
Bundle result = new Bundle();
result.putString("result_key", "result_value");
getParentFragmentManager().setFragmentResult("requestKey", result);
});
return view;
}
}
接收方在Activity中的注册示例如下。需要注意的是，如果发送方和接收方使用同一个FragmentManager，requestKey才能正确匹配。在Activity中监听Fragment结果时，必须使用getSupportFragmentManager()，而Fragment内部使用getParentFragmentManager()可以保证作用域一致。这个API非常适合处理一次性结果传递，如果数据需要持续同步，还是应该优先选择ViewModel。
public class MainActivity extends AppCompatActivity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
getSupportFragmentManager().setFragmentResultListener("requestKey", this, (requestKey, bundle) -> {
String value = bundle.getString("result_key");
// 处理结果
});
}
}
五、事件总线
事件总线是一种基于发布/订阅模式的通信机制，常见实现有EventBus、RxBus等。Activity和Fragment都可以作为订阅者注册监听，也可以作为发布者发送事件。这种方案的最大优势是彻底解耦，发布者不需要知道订阅者是谁，订阅者也不需要持有发布者引用。在组件层级较深、事件流向复杂的大型项目中，事件总线可以大幅降低模块之间的耦合度。
但事件总线也不是银弹。事件在全局范围内流通，很容易造成事件满天飞、逻辑难以追踪的问题。如果订阅关系管理不当，忘记在销毁时注销，就会导致内存泄漏。事件总线的调试成本也较高，出现问题时不容易快速定位事件发送方和接收方。因此，事件总线更适合跨模块通信或者事件需要多个接收者同时响应的场景，普通的一对一通信应优先选择接口回调或ViewModel。
public class MessageEvent {
public final String message;
public MessageEvent(String message) {
this.message = message;
}
}
public class MainActivity extends AppCompatActivity {
@Override
public void onStart() {
super.onStart();
EventBus.getDefault().register(this);
}
@Override
public void onStop() {
EventBus.getDefault().unregister(this);
super.onStop();
}
@Subscribe(threadMode = ThreadMode.MAIN)
public void onMessageEvent(MessageEvent event) {
// 处理事件
}
}
Fragment发送事件时只需要一行代码：EventBus.getDefault().post(new MessageEvent("来自Fragment的消息"))。使用事件总线时必须严格遵守注册和注销的配对原则，通常放在onStart()和onStop()中。此外，事件类应该尽量设计得精简，避免携带过大对象造成性能损耗。对于Android项目来说，EventBus虽然有效，但也要警惕其带来的隐性复杂度，不能为了解耦而滥用。
总结与选型建议
五种通信方式各有侧重。直接获取Activity实例适合一次性快速实现，但不适合长期维护；接口回调解耦程度适中，是一对一通信的经典选择；共享ViewModel生命周期安全且数据不丢失，是目前最值得推荐的方案；Fragment Result API专为一次性结果设计，官方支持、使用安全；事件总线解耦最彻底，但也带来了追踪难度和泄漏风险。开发时可以根据业务复杂度、团队架构习惯以及是否需要跨页面持续同步数据来选择最合适的方式。通常情况下，能在ViewModel和Fragment Result API之间解决的需求，就不必引入事件总线，保持代码可读性和可维护性才是长期发展的关键。
Fragment通信ActivityViewModel修改时间：2026-09-26 19:06:36