私のアプリは (同じタスク内で) アクティビティのスタックをナビゲートします
A -> B -> C
先に進むことは問題ありませんが、B (C から) または A (B から) に戻った後、そのアクティビティのすべての CLR オブジェクトが null であることに気付きました。これには、ローカル フィールドとイベント ハンドラが含まれます。
私の推測では、Android は Activity スタックを内部的にシリアル化し (CLR フィールドを無視)、CLR GC がそれらの Activity のオブジェクトを収集するようになっていると思います。これは明らかに望ましくないことであり、これを防ぐ方法が必ずあるはずです。
アクティビティがバックグラウンドに入ってから再開された後、アクティビティの CLR オブジェクトを保持できた人はいますか?
あなたは正しいです。アクティビティ C を実行している場合、A と B は両方とも「停止」状態にあるため、クリーンアップの対象となります (「破棄」状態に移行してから、ガベージ コレクションが行われます)。ドキュメントの関連記事は次のとおりです。
http://developer.android.com/training/basics/activity-lifecycle/recreating.html
非常に基本的な考え方: オーバーライドonSaveInstanceStateすると、必要に応じて Android がそれを呼び出します。onCreate()その後、アクティビティが再作成されたときに復元できるように、メソッドに渡されます。
編集：もちろん、代替手段があります。上記のメソッドは状態を (非) シリアル化するため、状態情報がかさばる場合は特に代替手段を検討する必要があります。これにはコストがかかる可能性があります。
onCreate()個人的には、必要な情報をデータベースに保存し、で確認する傾向がありますonStart()(他のアクティビティで影響を受けた変更に対応する必要がある場合は、このアクティビティがまだメモリ内にあるときに発生する可能性があります)。必要な情報をファイルやその他の永続ストレージに保存することもできます。違いは、いつ状態を復元する必要があるか、いつ新たに開始する必要があるかを知る責任があることです。
状態を静的変数に保存してもうまくいかないことに注意してください。静的変数は、アクティビティのインスタンス変数よりも永続的である傾向がありますが、電話がかかってきたときなどに予告なしに消去される可能性があります。