最近、Android アクティビティのライフ サイクルが少し頭を悩ませています。
アプリがバックグラウンドに入る前に、最後に表示されたアクティビティを保存して、ユーザーがアプリを復元したときに正しい状態を復元できるようにします。問題は、アプリがバックグラウンドになった理由には複数の可能性があり、すべてが同じアクションを実行するとは限らないことです。
わかりやすくするために、3 つのアクティビティがあると仮定します。A-1、A-2、A-3 (A-2 は A-3 へのエントリ)。A-2 と A-3 は通常のアクティビティですが、A-1 は一種のディスパッチャです。SharedPreferenceこれはマニフェスト ファイル内のランチャー アクティビティであり、それが行う唯一の機能は、基本的に最後のアクティビティが何であったかを示す他の 2 つのメソッドで設定されたを読み取り、そのonPause()アクティビティをアクティブにしてから を呼び出すことthis.finish()です。まっすぐに。
シナリオは次のとおりです (これらすべての後、ユーザーはバックグラウンド プロセス リストまたはランチャーからアプリを再起動します)。
- A-3 では、ユーザーは「戻る」ボタンをタップしてホーム画面に移動します。これは を実行
onPause()し、次にonDestroy()A-3 を実行します。 - A-3 では、ユーザーは「ホーム」ボタンをタップしてホーム画面に移動します。これが実行され
onPause()、次にonSavedInstanceState()A-3 が実行されます。 - ユーザーは上記の 2 つのいずれかを実行してから、バックグラウンド プロセスのリストを表示し、アプリを強制終了します。コードは実行されません。
- OS はメモリを解放する必要があることを検出するため、最初に (2 つのうち) バックグラウンド プロセスを強制終了し、それが不十分な場合は現在アクティブなプロセスを強制終了します。
これで、各シナリオで次のことが起こります。
- A-1 が起動され、設定された環境設定が読み込まれ、
onPause()A-3 が起動されます。設計どおりに動作します (ただし、最善の方法ではない可能性があります)。 - A-1 が起動し、上記と同じことを行います。
- 今、物事はトリッキーになります。アプリが再起動されると、アプリが終了したという兆候がないため、A-1 は設定を読み取り、A-2 を起動する必要があるときに A-3 を起動します。これは望ましくなく、アプリを壊します。
- 3番に似ています。
私の質問は、このような状況でアプリケーションの状態を管理する最善の方法は?
バンドルonSavedInstanceStateはアプリの実行中にのみライブに渡されるので、「セッション」中にのみこの種の情報を保存する最良の方法でしょうか?