Android中从Activity2向Activity1同步更新List的高效方案咨询

Nice question! The Intent-based approach you're using works, but static lists can be a pain—they're prone to memory leaks, can get out of sync during configuration changes, and just don't feel very clean. Let's go through some better alternatives that avoid static state entirely:

1. Jetpack ViewModel + LiveData/Flow (Recommended) #

This is the modern, Google-recommended approach for sharing data between components without static state. The ViewModel survives configuration changes (like screen rotations) and acts as a single source of truth for your list.

• How to implement:
  • Create a shared ViewModel class that holds your list in a MutableLiveData (or MutableStateFlow for Kotlin coroutines):

    class SharedListViewModel : ViewModel() {
        private val _itemList = MutableLiveData<List<YourObject>>(emptyList())
        val itemList: LiveData<List<YourObject>> = _itemList
    
        fun updateItem(position: Int, updatedItem: YourObject) {
            val currentList = _itemList.value?.toMutableList() ?: return
            currentList[position] = updatedItem
            _itemList.postValue(currentList)
        }
    
        fun deleteItem(position: Int) {
            val currentList = _itemList.value?.toMutableList() ?: return
            currentList.removeAt(position)
            _itemList.postValue(currentList)
        }
    }
    

  • In Activity1, retrieve the ViewModel and observe the itemList to update your RecyclerView adapter:

    val viewModel = ViewModelProvider(this)[SharedListViewModel::class.java]
    viewModel.itemList.observe(this) { newList ->
        yourAdapter.submitList(newList)
    }
    

  • In Activity2, retrieve the same ViewModel (using the parent Activity's ViewModelStoreOwner):

    val viewModel = ViewModelProvider(requireActivity())[SharedListViewModel::class.java]
    // When editing:
    viewModel.updateItem(selectedPosition, editedItem)
    // When deleting:
    viewModel.deleteItem(selectedPosition)
    finish()
    

• Pros: No static state, survives configuration changes, clean separation of concerns.
• Cons: Requires setting up Jetpack components (worth it though!).

2. Room Local Database #

If your list data needs to be persisted (survives app restarts), using Room is a great choice. It turns your list into a persistent data source, and you can observe changes automatically.

• How to implement:
  • Define an Entity for your object, a Dao with update/delete methods, and a Repository to handle data operations.
  • In Activity2, call the repository's update/delete methods to modify the database.
  • In Activity1, observe a LiveData<List<YourEntity>> from the repository—Room automatically emits updates when the database changes, so your adapter will refresh automatically.
• Pros: Persistent data, no memory leaks, built-in observation.
• Cons: Overkill if your data doesn't need to be saved between app sessions.

3. Activity Result API (For One-Time Updates) #

If you don't need a persistent data source and just want to pass the updated data back cleanly, the AndroidX Activity Result API replaces the old startActivityForResult with a more type-safe approach.

• How to implement:
  • In Activity1, define a contract for your result:

    data class ListUpdateResult(
        val operationType: String, // "EDIT" or "DELETE"
        val position: Int,
        val updatedItem: YourObject?
    )
    
    val updateListLauncher = registerForActivityResult(ActivityResultContracts.StartActivityForResult()) { result ->
        if (result.resultCode == RESULT_OK) {
            val updateResult = result.data?.getParcelableExtra<ListUpdateResult>("UPDATE_RESULT")
            updateResult?.let {
                val currentList = yourAdapter.currentList.toMutableList()
                when (it.operationType) {
                    "EDIT" -> it.updatedItem?.let { item -> currentList[it.position] = item }
                    "DELETE" -> currentList.removeAt(it.position)
                }
                yourAdapter.submitList(currentList)
            }
        }
    }
    

  • Launch Activity2 with this launcher:

    val intent = Intent(this, Activity2::class.java).apply {
        putExtra("POSITION", selectedPosition)
        putExtra("ITEM", selectedItem)
    }
    updateListLauncher.launch(intent)
    

  • In Activity2, send the result back when done:

    val result = ListUpdateResult("EDIT", position, editedItem) // or "DELETE"
    val intent = Intent().apply {
        putExtra("UPDATE_RESULT", result)
    }
    setResult(RESULT_OK, intent)
    finish()
    

• Pros: No static state, type-safe, simple for one-way data passes.
• Cons: Doesn't handle configuration changes automatically (you'd need to save the list state in Activity1 if needed).

4. EventBus (GreenRobot EventBus) #

While not the most modern approach, EventBus is a popular way to decouple components by sending events.

• How to implement:
  • Define an event class:

    data class ListUpdatedEvent(
        val operationType: String,
        val position: Int,
        val updatedItem: YourObject?
    )
    

  • In Activity1, register and subscribe to events:

    override fun onStart() {
        super.onStart()
        EventBus.getDefault().register(this)
    }
    
    @Subscribe(threadMode = ThreadMode.MAIN)
    fun onListUpdated(event: ListUpdatedEvent) {
        // Update your adapter here, same as the Activity Result API example
    }
    
    override fun onStop() {
        super.onStop()
        EventBus.getDefault().unregister(this)
    }
    

  • In Activity2, post the event when done:

    EventBus.getDefault().post(ListUpdatedEvent("EDIT", position, editedItem))
    finish()
    

• Pros: Decouples components, easy to implement.
• Cons: Can make code harder to debug (implicit dependencies), risk of memory leaks if not unregistered properly.

If you're building a modern Android app, go with ViewModel + LiveData/Flow—it aligns with Google's architecture guidelines, avoids static state, and handles configuration changes seamlessly. If your data needs persistence, add Room on top of that. The Activity Result API is great for simple one-off updates, while EventBus is a fallback if you need quick decoupling without Jetpack components.

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