Flutter中多Async/Await调用Firestore获取数据耗时过长优化求助

原流程的问题 #

你当前的处理逻辑完全不合理——循环里逐个await三个Firestore请求，相当于每个用户的三个查询是串行执行，用户多的话总耗时是「单用户3次请求耗时之和 × 用户数量」，这必然会导致整体耗时飙升。React里更快大概率是因为做了并行请求或者批量查询的优化，而你这边的串行逻辑把时间线拉得太长了。

具体优化方案 #

1. 单用户内的三个查询并行执行 #

不要逐个await三个方法，而是让这三个请求同时发起，等全部完成后再更新用户的score。比如用Future.wait（Dart）或Promise.all（JS）包裹三个请求：

// Dart示例：单个用户的三个请求并行处理
Future<void> updateSingleUserScores(UserModel user) async {
  // 先启动所有请求，不等待
  final stepScoreFuture = rankingRepo.getStepScore(user.userId);
  final diaryScoreFuture = rankingRepo.getDiaryScore(user.userId);
  final commentScoreFuture = rankingRepo.getCommentScore(user.userId);

  // 等待三个请求全部完成
  final results = await Future.wait([stepScoreFuture, diaryScoreFuture, commentScoreFuture]);
  
  user.stepScore = results[0];
  user.diaryScore = results[1];
  user.commentScore = results[2];
  user.totalScore = results[0] + results[1] + results[2];
}

这样单个用户的耗时会从「A+B+C」变成「max(A,B,C)」，直接缩短单用户处理时间。

2. 批量查询多个用户的同类型Score #

不要给每个用户单独发查询请求，而是一次性批量获取所有用户的同类型score：

• 用Firestore的whereIn查询（注意单次最多支持50个元素，超过则分批次），一次查询出所有目标userId的stepScore文档，再映射到用户列表。
• 同理处理diaryScore和commentScore，总请求次数从「3×用户数」变成「3次（或分批次的少量请求）」，大幅减少网络开销。

示例伪代码：

Future<void> batchUpdateScores(List<UserModel> users) async {
  final userIds = users.map((u) => u.userId).toList();
  
  // 并行发起三个批量查询
  final batchResults = await Future.wait([
    rankingRepo.getBatchStepScores(userIds),
    rankingRepo.getBatchDiaryScores(userIds),
    rankingRepo.getBatchCommentScores(userIds),
  ]);

  final stepScores = batchResults[0];
  final diaryScores = batchResults[1];
  final commentScores = batchResults[2];
  
  // 映射到用户列表
  for (var user in users) {
    user.stepScore = stepScores[user.userId] ?? 0;
    user.diaryScore = diaryScores[user.userId] ?? 0;
    user.commentScore = commentScores[user.userId] ?? 0;
    user.totalScore = user.stepScore + user.diaryScore + user.commentScore;
  }
}

3. 重构数据结构，避免额外查询 #

最彻底的优化是把stepScore、diaryScore、commentScore直接存在User文档中：

• 当用户的step/diary/comment数据更新时，通过Firestore触发器（或业务逻辑）同步更新User文档的对应score字段。
• 这样获取用户列表时，直接就能拿到三个score值，不需要后续再发起任何查询，彻底消除这部分耗时。

4. 缓存策略优化 #

如果score数据不需要实时强一致，可以在本地缓存已获取的score：

• 用内存缓存（比如一个Map存储userId到score的映射），短时间内重复调用updateScore时直接读缓存，避免重复请求。
• 也可以用本地存储（如SharedPreferences、Hive）持久化缓存，减少冷启动时的请求次数。

5. 分页处理用户列表 #

如果用户列表数量很大，不要一次性处理所有用户：

• 分页加载用户列表，每次只处理当前页的用户，减少单次请求的数据量和处理时间。
• 滚动到下一页时再加载对应用户并更新score，提升用户体验。

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