在 Android 上恢復狀態

當用戶執行移動應用然後選擇另一個應用執行時，第一個應用會被移到後臺，或稱為“後臺化”。作業系統（iOS 和 Android）可能會終止後臺應用以釋放記憶體並提高前臺應用的效能。

當用戶再次選擇該應用，將其帶回前臺時，作業系統會重新啟動它。但是，除非您設定了在應用被終止前儲存應用狀態的方法，否則您將丟失狀態，應用將從頭開始。使用者將失去他們期望的連續性，這顯然不是理想的。（想象一下，在填寫一個冗長的表單後，在點選 **提交** *之前* 接到了一個電話。）

那麼，如何恢復應用的狀態，使其看起來與後臺化之前一樣呢？

Flutter 在 services 庫中提供了 RestorationManager（及相關類）來解決這個問題。透過 RestorationManager，Flutter 框架會在狀態改變時將狀態資料提供給引擎，以便在作業系統發出即將終止應用的訊號時，應用已準備就緒，只給應用幾秒鐘的準備時間。

只需幾個步驟即可啟用狀態恢復

1. 為所有支援的 widget（如 TextField 和 ScrollView）定義一個 restorationId 或 restorationScopeId。這會自動為這些 widget 啟用內建的狀態恢復。

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

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

其他注意事項

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

• restorationId 和 restorationScopeId 之間的區別： 接受 restorationScopeID 的 widget 會建立一個新的 restorationScope（一個新的 RestorationBucket），所有子項都將其狀態儲存在此作用域中。restorationId 表示 widget（及其子項）將資料儲存在周圍的 bucket 中。

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

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

VeggieSeasons 示例（在下面的“其他資源”下列出）使用 go_router 包實現導航。restorationId 值的設定發生在 lib/screens 類中。

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

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

• 有關實現狀態恢復的示例，請檢視 VeggieSeasons，這是一個為 iOS 編寫的示例應用，使用了 Cupertino widgets。iOS 應用在 Xcode 中需要一些額外的設定，但恢復類在 iOS 和 Android 上使用方式基本相同。
  以下列表連結到 VeggieSeasons 示例的相關部分

  • 將 RestorablePropery 定義為例項屬性
  • 註冊屬性
  • 更新屬性值
  • 在 build 中使用屬性值
    

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

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

• 有關導航和 go_router 包的更多資訊，請參閱 導航和路由。