Android Studio中API成功响应后跨Activity刷新列表的实现方法

针对这个A→B→C的经典跳转场景，更新后同步刷新B页面的可行方案主要有三种，都是实际开发里常用的落地路径：

• 方案1：用官方推荐的Activity Result API做跨页面数据回传（侵入性最低，最适配现有跳转逻辑）
  因为C页本来就是B页直接启动的，完全不需要引入全局状态。只需要在B页注册启动C的回调接口，启动C的时候把当前点击的列表项位置、选中的经理原始数据传过去；等C页API更新成功后，把更新后的经理数据、之前记录的列表项位置通过结果回传接口带回来，B页收到回调后直接替换Adapter里对应位置的数据做局部刷新即可。
  关键实现代码：

  // B页注册启动C的结果回调
  private val launchCForUpdate = registerForActivityResult(ActivityResultContracts.StartActivityForResult()) { result ->
      if (result.resultCode == RESULT_OK) {
          val updatedManager = result.data?.getParcelableExtra("new_manager") as? Manager
          val updatePos = result.data?.getIntExtra("list_pos", -1) ?: -1
          if (updatedManager != null && updatePos != -1) {
              managerAdapter.updateItem(updatePos, updatedManager)
          }
      }
  }
  
  // B页列表点击事件
  listView.onItemClickListener = { _, _, pos, _ ->
      val intent = Intent(this, ActivityC::class.java).apply {
          putExtra("ori_manager", managerList[pos])
          putExtra("list_pos", pos)
      }
      launchCForUpdate.launch(intent)
  }
  

  // C页更新接口成功后的处理
  val backIntent = Intent().apply {
      putExtra("new_manager", refreshedManagerData)
      putExtra("list_pos", intent.getIntExtra("list_pos", -1))
  }
  setResult(RESULT_OK, backIntent)
  finish()
  

  这个方案的优势是数据流完全在B和C两个关联页面之间流转，不需要维护全局状态，没有额外的内存泄漏风险，刷新不需要重新拉取整份经理列表接口，性能最好。

• 方案2：基于全局数据缓存的onResume刷新（适合已有统一数据层的项目）
  把经理列表的数据源从B页的本地内存，抽离到应用级的单例Repository或者全局ViewModel（绑定Application上下文）中存储：

  1. B页拿到接口返回的部门经理列表后，按部门ID为key存入全局缓存
  2. C页调用更新接口成功后，直接修改全局缓存中对应经理的字段值
  3. B页重写onResume生命周期方法，每次页面回到前台时，从全局缓存读取当前部门对应的最新列表数据，同步给Adapter完成刷新
     这个方案的优势是解耦了B和C的直接依赖，后续如果有其他入口直接跳转到C页修改经理信息，回到B页时也能自动完成同步刷新，不需要额外适配回传逻辑。注意要给缓存加合理的过期策略，避免长期存储导致的脏数据问题。

• 方案3：基于粘性事件的跨页面通知（适合复杂多跳转链路的场景）
  可以用绑定了全局ViewModel的SharedFlow或者LiveData作为事件总线，C页更新接口成功后，发送一条携带更新后经理信息的粘性事件；B页通过绑定自身生命周期的观察者监听事件，收到后定位列表中对应的经理项做局部刷新即可。
  实现时要避免使用已经废弃的LocalBroadcastManager，同时保证观察者是随页面生命周期激活的，防止页面在后台不可见时收到无效通知触发UI操作。

注意：如果直接用传统的startActivityForResult逻辑，需要注意Android新版本里这个API已经被标记废弃，优先替换成官方的Activity Result API写法更稳定。

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