1

あいまいな質問をしたくないので、できるだけ明確にするようにします（最善を尽くします）。

私は、ガベージ コレクションが非常に長い間、プログラミングの灰色の領域であったことを知っています。Androidやその他の携帯電話の場合はよくわかりません。

Androidのガベージコレクションについて私が知っていること:

  1. クラス系のクラスオブジェクトを集めています(回答から訂正して作成)。
  2. 編集*「GC は、アクティビティが破棄された場合にのみアクティビティ アイテムを収集します。アクティビティのライフサイクルは、マニフェスト内の属性と、それを起動したインテントのフラグによって決まります。」– セヴァ・アレクセーエフ コメンテーターが言ったように。
  3. 「System.gc()」を使用してガベージ コレクションを強制することもできますが、これは重要なクラス アイテムを削除する可能性があるためお勧めできません。

今、私はstackoverflowからこの情報を取得しました（ガベージコレクションの灰色の領域ではなくなったことを知っています）

私の質問に行きます：

  1. ガベージ コレクションに関するプロセスまたは一般的な情報 (本、インターネット記事など) に関するこの情報をどのように入手しますか?
  2. 質問 1 の答えがない場合、メモリを常に使用する必要があるアプリケーションを開発する際に、開発者が覚えておくべき他の方法は何ですか?
4

1 に答える 1

2

あなたの情報が正しいかどうかわかりません。

クラスシステムのクラスを集めています。

いいえ。どのシステム ルートからもアクセスできなくなったオブジェクトのインスタンスを収集します。システム ルートには、静的参照、スレッドのアクティブなスタック フレームからの参照、アクティブな同期モニター、およびネイティブ コード (グローバルまたはローカル) によって保持されるすべてのものが含まれます。オブジェクトから参照グラフを逆方向にたどるルートへのパスがある場合、オブジェクトはライブと見なされます (したがって、再利用できません)。ルートへのパスを持たないオブジェクトは、ガベージ コレクターによって再利用できます。クラスは ClassLoader によって参照され、再ロードされることはないため、その ClassLoader が収集され、それらのクラスのすべてのインスタンスが収集されない限り、システムによって再利用されません。したがって、ClassLoader が収集されないため、Android がクラス システム クラスを収集することはありません。

アクティビティが hasNoHistory または singleTop のいずれかであることが Android マニフェスト ファイルに記載されている場合にのみ、アクティビティからアイテムを収集します。

いいえ。アクティビティはオブジェクトのインスタンスにすぎません。そして、アクティビティへの参照がなくなると、他のルートがそのオブジェクトを指していない限り、それが指していたすべての参照も失われます。singleTop="true" を設定すると、このアクティビティの単一のインスタンスをインスタンス化するように Android に指示するだけで、送信されたすべてのインテントはその単一のインスタンスによって処理されます。 GC には影響しません。アクティビティがルートへのパスを失うと、そのアクティビティの設定に関係なく、再利用されます。

「System.gc()」を使用してガベージ コレクションを強制することもできますが、これは重要なクラス アイテムを削除する可能性があるためお勧めできません。

ガベージ コレクション アルゴリズムは、ライブ オブジェクトを削除しません。上記の定義では、使用していたオブジェクトをGCが収集できることを意味しますが、これは正しくありません。もしそうなら、それは大きなバグです。これは、ガベージを完全にクリーンアップすることが保証されているという点で、ガベージ コレクション アルゴリズムの優れた点でもあります。メモリが不足している場合は、プログラマが参照を削除するのを忘れているか、メモリの使用に不注意です。System.gc() を呼び出すことを想定していない理由は、メモリを再利用するのに最適な時期がいつなのか、あなた/あなたのプログラムには見当がつかないからです。ガベージ コレクターは、(プログラムの実行時間) と (ガベージ コレクションに費やす時間) の比率を最大化しようとします。非常に詳細な統計を保持し、ガベージ コレクションを実行するのに適した時期と、単純にメモリを割り当てるのに適した時期についての見積もりを作成します。

それはあなたの家を掃除するようなものです。汚れたままにしておく必要がある場合があるため、物事を行うのに時間がかかるため、常に掃除することはできません（料理のように）。ただし、家を掃除しないと、掃除に丸一日かかることがあります。そのため、タスクを実行するよりもクリーンアップに時間がかかる前に、どの程度汚れる可能性があるかというバランスを取る必要があります。

これが、プログラムで GC を計算/推測/強制するべきではない理由です。なぜなら、Android は既に GC を実装しており、あなたが望むよりも優れた仕事をするからです。

これは開発者にとって何を意味しますか?

  1. GC を実行するタイミングを Android に任せます。
  2. 参照をクリーンアップして、何かを回収できる時期を GC が認識できるようにします。静的参照には細心の注意を払い、静的がアクティビティやサービスなどへの参照を保持することを決して許可しないでください。
  3. 少量の短期間のメモリを大量に割り当てないでください。これにより、より多くの GC 時間がクリーンアップに強制されます。控えめにメモリを割り当てることにより、定義上、その比率を支援しています。

ほとんどの場合、GC は非常に手間がかかります。開発者が遭遇する唯一の問題は、長寿命オブジェクトと UI オブジェクトの境界を確立しないことです。存続期間の長いオブジェクトが UI への参照を持っている場合は、その場所を登録解除する必要があります。そうしないと、メモリ リークが発生します。UI が長寿命オブジェクトへの参照を保持することは問題ありませんが、その逆は問題ありません。

Android の本当の問題は、ガベージ コレクターをどれだけ機能させるかということです。使用しているメモリの量を小さくしておくと、ガベージ コレクターには大きな仕事がありません。これは、オブジェクトを再利用したり、オブジェクト プールを作成したりする必要があるという意味ではありません。ただし、どのステートメントがメモリを作成しているか、およびそれらのオブジェクトが存続する期間に注意する必要があります。

ガベージ コレクション全般、特に Java のコンカレント マーク アンド スイープ ガベージ コレクタに関する情報は数多くあります。Android のガベージ コレクターはパフォーマンスはそれほど高くありませんが、非常に優れています。ほとんどの場合、問題がない限り GC について心配することはありません。

また、ガベージ コレクションは灰色の領域ではありません。Java は非常によく理解されており、1994 年に Java が導入されて以来、業界はこの分野をかなり拡大してきました。

于 2012-06-14T15:47:10.953 に答える