在 Android 上恢復狀態

當用戶執行一個移動應用，然後切換到另一個應用時，第一個應用會被轉入後臺，或者稱為“進入後臺”。作業系統（iOS 和 Android）可能會為了釋放記憶體並提高前臺執行應用的效能而關閉後臺應用。

當用戶再次選中該應用並將其切回前臺時，作業系統會重新啟動它。但是，除非您設定了在應用被關閉前儲存其狀態的方法，否則之前的狀態就會丟失，應用將從頭開始。這會破壞使用者所預期的連續性，顯然是不理想的。（想象一下，在填寫一份冗長的表單時，在點選提交之前被一個電話打斷。）

那麼，如何恢復應用的狀態，使其看起來就像被髮送到後臺之前一樣呢？

Flutter 透過 RestorationManager（以及相關類）在 services 庫中提供了一個解決方案。利用 RestorationManager，Flutter 框架會在狀態發生變化時將狀態資料提供給引擎，以便在作業系統發出即將關閉應用的訊號時，應用能準備好（通常只有極短的時間）。

只需幾個任務即可啟用狀態恢復：

1. 為 CupertinoApp、MaterialApp 或 WidgetsApp 等類定義 restorationScopeId。

2. 為支援該功能的微件定義 restorationId，例如 TextField 和 ScrollView。這會自動為這些微件啟用內建的狀態恢復功能。

3. 對於自定義微件，您必須決定要恢復哪些狀態，並將該狀態儲存在 RestorableProperty 中。（Flutter API 為不同的資料型別提供了各種子類。）在使用了 RestorationMixin 的 State 類中定義這些 RestorableProperty 微件，並在 restoreState 方法中向 mixin 註冊這些微件。

4. 如果您使用了任何 Navigator API（如 push、pushNamed 等），請遷移到名稱中帶有 "restorable" 的 API（restorablePush、restorablePushNamed 等），以恢復導航堆疊。

其他注意事項

• 為 MaterialApp、CupertinoApp 或 WidgetsApp 提供 restorationScopeId 會透過注入 RootRestorationScope 自動啟用狀態恢復。如果您需要在應用類之上恢復狀態，請手動注入 RootRestorationScope。

• restorationId 和 restorationScopeId 之間的區別： 使用 restorationScopeId 的微件會建立一個新的 restorationScope（一個新的 RestorationBucket），所有子微件都會將它們的狀態儲存在其中。而 restorationId 則意味著該微件（及其子微件）會將資料儲存在周圍的 bucket 中。

如果您希望應用返回到使用者最近瀏覽的特定路由（例如購物車），那麼您還必須為導航實現恢復狀態。

如果您直接使用 Navigator API，請將標準方法遷移到可恢復方法（名稱中帶有 "restorable" 的方法）。例如，用 restorablePush 替換 push。

要測試狀態恢復，請設定您的移動裝置，使其在應用進入後臺時不儲存狀態。要了解如何針對 iOS 和 Android 執行此操作，請檢視 RestorationManager 頁面上的 測試狀態恢復。

有關狀態恢復的更多資訊，請查閱以下資源。

• 要了解有關短期和長期狀態的更多資訊，請檢視 區分臨時狀態與應用狀態。

• 您可能想看看 pub.dev 上執行狀態恢復的軟體包，例如 statePersistence。

• 有關導航和 go_router 軟體包的更多資訊，請檢視 導航和路由 以及 pub.dev 上的 狀態恢復 (State restoration) 主題。