Firebase API回调架构如何适配Android Activity生命周期？

When working with Firebase Firestore's callback-based API in Android, a common pain point is ensuring that callbacks don't attempt to interact with an Activity that's already been destroyed (e.g., due to configuration changes like screen rotation, or the user navigating away). Let's break down how to adapt this callback architecture to play nicely with the Android Activity lifecycle.

1. Use ViewModel to Separate Data Logic from Activity #

The ViewModel class is designed to survive configuration changes, making it the perfect home for Firestore operations. By moving your Firestore calls into a ViewModel, you decouple the data logic from the Activity's lifecycle. You can then use LiveData to communicate results back to the Activity, which automatically cleans up observers when the Activity is destroyed.

Example code:

// CityViewModel.kt
class CityViewModel : ViewModel() {
    private val _deleteResult = MutableLiveData<Result<Unit>>()
    val deleteResult: LiveData<Result<Unit>> = _deleteResult

    fun deleteCity(cityId: String) {
        FirebaseFirestore.getInstance()
            .collection("cities")
            .document(cityId)
            .delete()
            .addOnSuccessListener {
                _deleteResult.postValue(Result.success(Unit))
            }
            .addOnFailureListener { exception ->
                _deleteResult.postValue(Result.failure(exception))
            }
    }
}

// In your Activity
class CitiesActivity : AppCompatActivity() {
    private lateinit var viewModel: CityViewModel

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        viewModel = ViewModelProvider(this)[CityViewModel::class.java]
        
        viewModel.deleteResult.observe(this) { result ->
            result.onSuccess {
                Log.d(TAG, "Document deleted successfully!")
                // Update UI safely here
            }.onFailure { exception ->
                Log.w(TAG, "Error deleting document", exception)
                // Handle error safely
            }
        }

        // Trigger delete when needed
        viewModel.deleteCity("DC")
    }
}

In this setup, if the Activity is destroyed and recreated (like during rotation), the ViewModel retains the Firestore task, and the new Activity instance will observe the LiveData to get the result once it's ready. No callbacks are left hanging on a dead Activity.

2. Cancel Firestore Tasks When the Activity is Stopped #

Firebase's Task objects (returned by operations like delete()) can be cancelled. You can store a reference to the task in your Activity, then cancel it in onStop() or onDestroy() to prevent callbacks from executing after the Activity is no longer active.

Example code:

// In your Activity
public class CitiesActivity extends AppCompatActivity {
    private static final String TAG = "CitiesActivity";
    private Task<Void> deleteTask;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        // ...
        deleteTask = FirebaseFirestore.getInstance()
                .collection("cities")
                .document("DC")
                .delete()
                .addOnSuccessListener(aVoid -> {
                    Log.d(TAG, "DocumentSnapshot successfully deleted!");
                    // Update UI
                })
                .addOnFailureListener(e -> {
                    Log.w(TAG, "Error deleting document", e);
                    // Handle error
                });
    }

    @Override
    protected void onStop() {
        super.onStop();
        if (deleteTask != null && !deleteTask.isComplete()) {
            deleteTask.cancel(true);
        }
    }
}

Cancelling the task will trigger the onFailureListener with a CancellationException, so you can add a check for that to avoid handling errors that are just due to lifecycle cleanup.

3. Validate Activity State in Callbacks #

If you prefer to keep Firestore calls in the Activity, you can add checks to ensure the Activity is still in a valid state before executing any UI-related logic in the callbacks.

Example code:

FirebaseFirestore.getInstance()
        .collection("cities")
        .document("DC")
        .delete()
        .addOnSuccessListener(aVoid -> {
            if (!isFinishing() && !isDestroyed()) {
                Log.d(TAG, "DocumentSnapshot successfully deleted!");
                // Update UI safely
            }
        })
        .addOnFailureListener(e -> {
            if (!isFinishing() && !isDestroyed()) {
                Log.w(TAG, "Error deleting document", e);
                // Handle error safely
            }
        });

This prevents the callback from trying to update a UI that's already gone, avoiding null pointer exceptions or crashes.

4. Use Kotlin Coroutines with Lifecycle Scope #

For Kotlin developers, converting Firebase callbacks to suspend functions using the kotlinx-coroutines-play-services library lets you leverage lifecycle-aware coroutines. Launching the coroutine in lifecycleScope ensures it's automatically cancelled when the Activity is destroyed.

Example code:

class CitiesActivity : AppCompatActivity() {
    private val TAG = "CitiesActivity"

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        // ...
        lifecycleScope.launch {
            try {
                FirebaseFirestore.getInstance()
                    .collection("cities")
                    .document("DC")
                    .delete()
                    .await() // Convert callback to suspend function
                Log.d(TAG, "DocumentSnapshot successfully deleted!")
                // Update UI safely
            } catch (e: Exception) {
                if (e is CancellationException) return@launch // Ignore cancellation due to lifecycle
                Log.w(TAG, "Error deleting document", e)
                // Handle error
            }
        }
    }
}

The lifecycleScope is tied to the Activity's lifecycle, so when the Activity is destroyed, the coroutine is cancelled, and any pending operations are stopped.

Key Takeaways #

Firebase's callback architecture doesn't automatically handle Android lifecycle events out of the box, but by combining it with Android's lifecycle components (ViewModel, LiveData, lifecycleScope) or using Firebase's task cancellation features, you can safely adapt it to avoid common pitfalls like memory leaks or crashes from callbacks executing on destroyed Activities.

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