Redux/Flux全局单Store/State在Android中的实现及最佳实践咨询

Great question—translating Redux/Flux principles to Android requires balancing the pattern's core rules with the platform's lifecycle quirks. Let’s tackle your concerns one by one:

1. How to Implement a Single Global Store/State in Android #

The key here is to create a thread-safe, globally accessible store that holds your immutable app state, while integrating with Android's lifecycle-aware components for UI updates:

• Use Dependency Injection for the Store: Avoid manual singletons (they’re hard to test and maintain). Instead, use Dagger/Hilt to provide a single instance of your AppStore across the app. This ensures consistency and makes testing easier (you can mock the store in unit tests).
• Immutable State & Reducer Logic: Follow Redux’s rule of immutable state—every action returns a new AppState instance instead of modifying the existing one. Your store should expose a dispatch(Action action) method that passes the action to a reducer function, which updates the state.
• Lifecycle-Aware State Observability: Use LiveData or Flow (Jetpack’s preferred reactive stream) to let UI components subscribe to state changes. For example:

  class AppStore @Inject constructor() {
      private val _state = MutableLiveData<AppState>(AppState.initial())
      val state: LiveData<AppState> = _state
  
      fun dispatch(action: Action) {
          val newState = reducer(_state.value ?: AppState.initial(), action)
          _state.postValue(newState)
      }
  
      private fun reducer(currentState: AppState, action: Action): AppState {
          // Handle actions and return new state
          return when (action) {
              is UpdateUserAction -> currentState.copy(user = action.user)
              is ToggleThemeAction -> currentState.copy(isDarkMode = action.isDarkMode)
              else -> currentState
          }
      }
  }
  

2. Handling Configuration Changes (Screen Rotation) & System Memory Cleanup #

Your idea to use ViewModel is spot-on—it’s designed to survive configuration changes. But we need to extend this to handle system-initiated process kills too:

a. ViewModel as the UI-Store Mediator #

• Have your ViewModel inject the AppStore and observe its state. The ViewModel acts as a middle layer, converting raw app state into UI-specific state that your Activity/Fragment can use:

  class MainViewModel @Inject constructor(private val appStore: AppStore) : ViewModel() {
      val userUiState: LiveData<UserUiState> = appStore.state.map { appState ->
          UserUiState(
              userName = appState.user.name,
              isLoggedIn = appState.user.isLoggedIn,
              isDarkMode = appState.isDarkMode
          )
      }
  
      fun updateUser(name: String) {
          appStore.dispatch(UpdateUserAction(User(name, isLoggedIn = true)))
      }
  }
  

• Since ViewModels survive screen rotations, your UI will automatically re-subscribe to the existing state without needing to re-fetch or reinitialize anything.

b. Persisting State for System Memory Kills #

When Android kills your app to free memory, even ViewModels are destroyed. To recover state, you need to persist the global state to disk:

• Serialize State to Disk: When your app moves to the background (use ProcessLifecycleOwner to listen for app lifecycle events), serialize the AppState (using Gson, Moshi, or Kotlin Serialization) and save it to SharedPreferences, Room, or a local file.
• Restore State on App Launch: When the app starts again (or when the Store is initialized), read the serialized state from disk and set it as the initial state of the Store.
• Avoid Serializing Non-Serializable Objects: Ensure your AppState only contains primitive types, data classes, or other serializable objects. Don’t hold references to Context, views, or other platform-specific objects—keep those out of the state.

c. Best Practices Summary #

• Use ViewModel to bridge the Store and UI, handling configuration changes seamlessly.
• Persist the full global state to disk when the app enters the background (avoid persisting on every action to save performance).
• Validate the restored state on app launch (e.g., check for corruption) and fall back to the initial state if needed.
• For large states, consider using Room instead of SharedPreferences for more efficient storage and retrieval.

Final Thoughts #

Combining a global Redux-style Store with ViewModel and disk persistence gives you the best of both worlds: a single source of truth for your app state, plus robust handling of Android’s lifecycle edge cases. Start small, test the state persistence flow thoroughly, and adjust based on your app’s specific needs.

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