Flutter Bloc不同事件传带流值消息 避免重复拉取用户Firebase数据流

现有实现的核心问题 #

当前代码将“实时用户数据拉取”和“业务操作提示”两个逻辑强绑定，每次触发业务事件都重建数据库流订阅，存在三类明显缺陷：

• 重复创建Stream订阅，额外消耗Firestore读配额，未做统一资源回收时容易造成订阅泄漏
• 每次操作都要等待新订阅的首次流推送才能返回状态，存在不必要的响应延迟
• 流推送与消息提示的硬编码绑定逻辑，容易出现提示消息和实际操作错位的问题

核心改造逻辑 #

将两个职责完全拆分，全程复用同一份用户数据订阅：

• 实时用户流订阅：在Bloc初始化时创建一次，常驻整个Bloc生命周期，只负责把最新的用户数据同步到Bloc内部私有缓存，不绑定任何业务提示消息
• 差异化提示消息：完全和对应的业务操作绑定，操作执行完成后，直接读取内部缓存的最新用户数据，搭配对应操作的专属提示消息生成最终状态，不需要依赖流的推送逻辑

具体实现代码 #

首先调整事件设计，把流同步的逻辑做成内部私有事件，外部业务事件只负责承载操作参数和对应的提示语义：

abstract class ProfileEvents {}
// 外部触发的初始化事件：负责启动全局用户流订阅
class ProfileInitialEvent extends ProfileEvents {}
// 外部触发的手机号更新事件：携带更新参数
class ProfileUpdateMobileEvent extends ProfileEvents {
  final String phoneNumber;
  ProfileUpdateMobileEvent(this.phoneNumber);
}
// 内部私有事件：仅用于流推送时同步最新用户数据到Bloc
class _UserStreamSyncedEvent extends ProfileEvents {
  final MakaniUser user;
  _UserStreamSyncedEvent(this.user);
}

对应的Bloc实现如下：

class ProfileBloc extends Bloc<ProfileEvents, ProfileStates> {
  final Firestore _database = Firestore();
  final FirebaseAuth _firebaseAuth = FirebaseAuth.instance;
  // 全局唯一的用户数据流订阅，全程复用
  StreamSubscription<MakaniUser>? _userDataSubscription;
  // 内部缓存最新的用户数据，所有状态生成都从这里取值
  MakaniUser? _cachedLatestUser;

  ProfileBloc() : super(ProfileAppStartState()) {
    // 绑定事件处理器
    on<ProfileInitialEvent>(_handleInitial);
    on<ProfileUpdateMobileEvent>(_handleMobileUpdate);
    on<_UserStreamSyncedEvent>(_handleStreamSync);
  }

  /// 初始化逻辑：只创建一次全局用户流订阅
  Future<void> _handleInitial(ProfileInitialEvent event, Emitter<ProfileStates> emit) async {
    // 先清理旧订阅，避免泄漏
    await _userDataSubscription?.cancel();
    final currentUser = _firebaseAuth.currentUser;
    if (currentUser == null) {
      emit(ProfileLoggedOutState());
      return;
    }
    // 建立常驻的实时用户数据流订阅
    _userDataSubscription = _database.getUserData(currentUser.uid).listen(
      (userData) => add(_UserStreamSyncedEvent(userData)),
      onError: (err) => emit(ProfileLoadFailedState(error: err.toString())),
    );
  }

  /// 流同步逻辑：只更新内部缓存，不硬编码提示消息
  void _handleStreamSync(_UserStreamSyncedEvent event, Emitter<ProfileStates> emit) {
    _cachedLatestUser = event.user;
    // 首次加载拿到数据时，使用默认的加载完成提示
    emit(ProfileDataReceivedState(
      user: event.user,
      message: 'Data Received'
    ));
  }

  /// 手机号更新逻辑：完全不需要重建订阅
  Future<void> _handleMobileUpdate(ProfileUpdateMobileEvent event, Emitter<ProfileStates> emit) async {
    if (_firebaseAuth.currentUser == null || _cachedLatestUser == null) return;
    // 直接执行数据库更新操作
    await _database.updateUserPhoneNumber(event.phoneNumber);
    // 全局流会自动捕获数据库变化、推送新数据到内部缓存
    // 这里直接基于业务操作的专属语义，搭配最新缓存数据生成状态
    emit(ProfileDataReceivedState(
      user: _cachedLatestUser!,
      message: 'mobile updated'
    ));
  }

  @override
  Future<void> close() {
    // Bloc销毁时统一取消全局订阅
    _userDataSubscription?.cancel();
    return super.close();
  }
}

方案优势 #

• 零重复订阅：不管触发多少次业务操作，都不会重复创建Firestore流订阅，大幅降低数据库读开销，从根源避免订阅泄漏
• 消息无错位：差异化提示消息和对应的业务操作强绑定，不会因为流的外部推送（比如其他客户端同步修改了用户数据）出现提示消息和操作不匹配的问题
• 更低状态延迟：常驻订阅会第一时间把最新数据同步到内部缓存，操作完成后不需要等新订阅的首次推送，直接可以返回状态，交互响应速度更快
• 数据一致性有保障：如果担心数据库更新后内部缓存存在同步延迟，可在数据库操作完成后等待流推送的下一次更新事件，再搭配对应操作的提示消息返回状态，全程依然不需要重建订阅，数据精度和原有实现完全一致

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