私は他の数人の開発者と一緒に Android プロジェクトに取り組んでおり、ガベージ コレクションでインスタンスの状態が保持されないというバグが発生しました。
実際に報告されたバグ:
アプリには、多数のフラグメントを含む 1 つのアクティビティがあります。開発者向けオプションで「アクティビティを保持しない」がチェックされている場合、ユーザーが表示されるフラグメントを変更するボタンをクリックし、アプリから離れてから戻ると、アプリを最後の状態ではなく元の状態に再起動します.
プロジェクトの別の開発者は、次の懸念を提起しました。
「インスタンスを保存すると、アプリのメモリ サイズが肥大化します。すでに、ドローアブルの量が原因で、アプリのメモリ サイズが大きすぎます。
ユーザーがしばらく使用しなかった後にアプリが再起動すれば問題ありません。」
私の理解では、savedInstance バンドルは実際には物理メモリに書き込まれるということでしたが、それは正しくありませんか? 上記の引用は有効な懸念事項ですか?
私の理解では、savedInstance バンドルは実際には物理メモリに書き込まれるということでしたが、それは正しくありませんか?
「物理メモリへの書き込み」を「ファイルシステム上のファイルへの書き込み」(別名「永続化」) と解釈しています。
インスタンスの状態Bundleは保持されません。Android 5.0 以降PersistableBundleでは、永続化されるため、再起動後も存続する別のフックが提供されます。
ただし、インスタンスの状態Bundleはプロセス境界を越えてコア OS プロセスに渡されます。そのデータは、プロセスが終了した場合に使用できますが、ユーザーはタスクがまだ残っている間にアプリに戻ります (たとえば、最近のタスク リストを介して)。
上記の引用は有効な懸念事項ですか?
SOの人々が合理的に評価できる唯一の引用は次のとおりです。
インスタンスを保存すると、アプリのメモリ サイズが肥大化します。
に 1 バイトを保存するBundleと、 に 0 バイトを保存するよりも多くのメモリが消費されますBundle。したがって、数学的には、見積もりは正確です。Bundle重要なのは、小さく保つことです。いずれにしても、他の理由で大きくなりすぎることはありません (IPC 呼び出しの 1MB 制限)。スモール インスタンスの状態Bundlesは問題になりません。
正しくコーディングされた saveinstance 状態は、一度に数週間バックグラウンドで存続し、最悪の場合、数 k の RAM で数バイトしか必要としません。
あなたの他の開発者には、学習曲線の問題があります。
InstanceState は、アプリが現在ユーザーに見える方法を再作成するために必要なものを保存します。三目並べの類推を使用しましょう。あなたには9つのポジションがあります。各位置は xo またはブランクです。誰の番かを保存します。ここに 10 文字の文字列がありますが、これはロケット サイエンスではありません。
画面に 10 個のドローアブルがあるアプリの InstanceState。ドローアブルを jpg または bmp として外部ストレージに保存します。次に、ドローアブルの名前を instanceState に保存します。インスタンス状態の 1000 文字の膨張はありません。これは、非常に複雑なアプリを再起動するためのコンピューター サイエンス 1k です。
SaveinstanceState はブロート ウェアではなく、すばらしいアプリです。