Flutter：如何全局监听NotificationCubit实现通知全局处理？

现有实现背景 #

已经通过get_it完成NotificationCubit的依赖注入，在应用根节点通过MultiBlocProvider完成了Cubit的全局注册，根节点代码如下：

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MultiBlocProvider(
      providers: [
        // 其他全局Bloc注册...
        BlocProvider<NotificationCubit>(
          create: (context) => sl<NotificationCubit>(),
        )
      ],
      child: MaterialApp(
        home: const Splash(),
        onGenerateRoute: Routes.sailor.generator(),
        navigatorKey: Routes.sailor.navigatorKey,
      ),
    );
  }
}

之前在首页页面嵌套BlocBuilder<NotificationCubit, NotificationState>时，能正常捕获新通知对应的状态，触发逻辑完全正常。
当前目标是实现通知的全局处理，不需要在每个页面单独写监听逻辑，于是尝试在BlocProvider创建Cubit的链式调用中直接添加状态监听，编写的代码如下，但实际运行时逻辑完全不生效：

BlocProvider<NotificationCubit>(
  create: (context) => sl<NotificationCubit>()..listen((state) {
    if (state is NotificationReceived) {
      print("Notification received");
    }
  }),
)

写法失效的核心原因 #

• Cubit内置的状态流属于单订阅模式，同一时间只允许一个活跃监听器。BlocProvider在向子组件树传递Cubit实例时，会在内部自动对Cubit的状态流添加自己的订阅，用来驱动BlocBuilder、BlocListener等组件的状态更新。在create方法里提前调用listen添加的监听器，会和BlocProvider内部的默认订阅产生冲突，最终要么被静默覆盖，要么直接触发单订阅流的异常报错。
• 这种写法没有配套的生命周期管理，监听器没有绑定对应的销毁逻辑，即使偶尔能收到状态，也会在组件树重建、BlocProvider被移除时造成内存泄漏。

可落地的正确实现方案 #

方案1：在MaterialApp外层挂载全局BlocListener #

这是Bloc生态原生支持的全局处理方案，不需要手动管理订阅销毁逻辑，也是最稳妥的实现方式：

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MultiBlocProvider(
      providers: [
        // 其他全局Bloc注册...
        BlocProvider<NotificationCubit>(
          create: (context) => sl<NotificationCubit>(),
        )
      ],
      // 全局监听器和MaterialApp平级，覆盖全应用路由范围
      child: BlocListener<NotificationCubit, NotificationState>(
        listener: (context, state) {
          if (state is NotificationReceived) {
            // 全局通知处理逻辑：弹出全局通知横幅、跳转通知对应页面
            print("Notification received");
            // 直接使用已配置的全局navigatorKey跳转，不依赖具体页面的context
            Routes.sailor.navigate(state.targetRoute);
          }
        },
        child: MaterialApp(
          home: const Splash(),
          onGenerateRoute: Routes.sailor.generator(),
          navigatorKey: Routes.sailor.navigatorKey,
        ),
      ),
    );
  }
}

这种实现的优势：

• 监听器位置处于全局路由树顶层，不会受页面切换、路由栈变化的影响，能稳定收到所有通知状态
• 可以直接访问全局的路由实例，不需要依赖具体页面的BuildContext完成跳转操作
• BlocListener会自动处理订阅的绑定和销毁，不会出现内存泄漏问题

方案2：将全局处理逻辑下沉到Cubit内部 #

如果希望UI层完全和通知处理逻辑解耦，可以把全局通知处理的逻辑放到NotificationCubit内部，配合全局依赖注入的通知服务完成处理：

class NotificationCubit extends Cubit<NotificationState> {
  // 通过get_it注入的全局通知处理器
  final GlobalNotificationHandler globalHandler;

  NotificationCubit(this.globalHandler) : super(NotificationInitial());

  /// 收到新推送时触发的方法
  void onReceivePush(NotificationPayload payload) {
    // 先执行全局通知处理，再向UI层发送状态
    globalHandler.process(payload);
    emit(NotificationReceived(payload));
  }
}

这种实现的优势是完全不需要在UI层编写多余的监听代码，全局处理逻辑的内聚性更强。

注意：永远不要在BlocProvider的create方法里用..listen的方式直接订阅Cubit状态，这是单订阅流的典型使用误区，除了前面提到的订阅冲突问题，还会因为监听器没有cancel逻辑，在应用运行过程中造成不可预期的内存泄漏。

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