从Activity返回时如何触发Jetpack Compose屏幕Recompose刷新数据

Compose的重组是状态驱动的，不存在符合官方规范的手动强制重组方式，你只需要在页面从其他Activity回到前台的时机，更新被Compose追踪的状态，页面就会自动触发重组完成数据刷新。以下是两种可直接落地的实现方案：

• 方案1：使用rememberLauncherForActivityResult处理跳转（最推荐，符合Activity Result API规范）
  跳转其他Activity不要直接调用startActivity，用官方Activity Result API注册跳转协定，返回回调本身就在Compose的重组作用域内，直接更新状态即可触发刷新。

  // 在你的Composable屏幕内注册启动器
  val targetPageLauncher = rememberLauncherForActivityResult(
      contract = ActivityResultContracts.StartActivityForResult()
  ) {
      // 从目标Activity返回时必然走到这个回调，无需对方主动setResult
      // 直接调用页面数据刷新逻辑即可
      viewModel.refreshPageData()
  }
  
  // 触发跳转的位置直接调用launch
  Button(onClick = {
      val jumpIntent = Intent(currentContext, TargetActivity::class.java)
      targetPageLauncher.launch(jumpIntent)
  }) {
      Text("跳转至其他页面")
  }
  

  只要refreshPageData()内更新的是Compose可追踪的状态（比如mutableStateOf持有值、StateFlow/LiveData暴露的状态），状态更新后依赖该状态的UI会自动重组，不需要额外操作。

• 方案2：监听Compose页面生命周期（适配已有直接调用startActivity的旧代码场景）
  如果项目中已经存在大量直接调用startActivity的跳转逻辑不想重构，可以给当前Composable绑定生命周期监听，每次页面进入ON_RESUME状态（从其他Activity返回必然触发该状态）时执行刷新逻辑即可。

  @Composable
  fun YourTabScreen(viewModel: YourPageViewModel = viewModel()) {
      val lifecycleOwner = LocalLifecycleOwner.current
      DisposableEffect(lifecycleOwner) {
          val observer = LifecycleEventObserver { _, event ->
              if (event == Lifecycle.Event.ON_RESUME) {
                  // 标记位判断：避免首次进入、切后台返回时误触发刷新
                  if (viewModel.needRefreshAfterBack.value) {
                      viewModel.refreshPageData()
                      viewModel.needRefreshAfterBack.value = false
                  }
              }
          }
          lifecycleOwner.lifecycle.addObserver(observer)
          onDispose {
              lifecycleOwner.lifecycle.removeObserver(observer)
          }
      }
  
      // 绑定页面状态写UI即可，状态变更自动重组
      val pageData by viewModel.pageData.collectAsStateWithLifecycle()
  }
  

  跳转目标Activity前，把viewModel.needRefreshAfterBack的值设为true，就能保证只有从指定Activity返回时才触发刷新。

注意事项 #

• 不要尝试使用手动强制重组的黑科技，这类方案违背Compose状态驱动的设计原则，很容易引发性能问题、状态错乱。
• 页面数据状态尽量存在ViewModel中，不要直接在Composable内用普通变量存储，否则转屏等配置变更场景下数据会丢失，也无法被Compose追踪触发重组。
• 如果是配合Navigation Compose实现的bottom navigation，每个tab页获取ViewModel时要绑定对应tab的导航回退栈条目作为ViewModelStoreOwner，避免多个tab共用同一个ViewModel导致状态串扰，上述刷新逻辑只会生效在当前返回的tab页，不会影响其他tab的状态。

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