現在、Androidアプリでガベージコレクションの問題を調査していますが、GC_FOR_ALLOCがGC_CONCURRENTなどの他のGCメッセージよりも大きな問題を示しているかどうかを知りたいです。
私の理解では、GC_CONCURRENTはガベージコレクターが行うべきことを実行しています。ヒープが特定の制限に達しました。メモリをクリーンアップすることをお勧めします。
GC_FOR_ALLOCは、オブジェクトを作成しようとしていて、それを実行するためのメモリが残っていない場合に、より深刻なことが起こっていることを示唆しています。
GCメッセージの優先度または「重大度」レベルはありますか？
ある意味でGC_FOR_ALLOCは、より深刻ですGC_CONCURRENT。これGC_FOR_ALLOCは、割り当て要求を満たすのに十分な空きメモリがなかったため、ガベージコレクションが必要だったのに対しGC_CONCURRENT、GCが実行されているように感じたことを意味します。これは、通常、空きメモリの量が割り当て後の特定のしきい値。
ただし、 AGC_FOR_ALLOC自体はアプリケーションの問題の兆候ではありません。
GC_FOR_ALLOCヒープのサイズを大きくする前に実行されます。この場合GC_FOR_ALLOC、完全に正常です。GC_FOR_ALLOCは避けられません。また、並行GCがメモリを解放できるよりも速くメモリを割り当てることには、本質的に問題はありません。Androidでのより深刻なタイプのGCはGC_BEFORE_OOM、です。これは、割り当て要求が失敗した後GC_FOR_ALLOCでも、アプリケーションヒープが許可されている範囲まで大きくなったときに実行されます。これが発生すると、最後の手段として、Dalvikはメモリの割り当てを最後に試行する前にSoftReferencesも解放しようとします。それが失敗した場合は、OutOfMemory例外をスローします。
このロジックのコードを知りたい場合はtryMalloc()、dalvik.git / vm / alloc/Heap.cppにあります。
とにかく、気にしないのであれば、logcatの出力を確認することが、ガベージコレクションの問題をデバッグするための最も効率的な方法であるとは思えません。発生している具体的な問題はわかりませんが、DDMSのAllocation Trackerなどのツールを調べて、ツールを使用してヒープダンプを分析しましたhprof-convか？（開始するには、たとえばhttp://android-developers.blogspot.se/2011/03/memory-analysis-for-android.htmlを参照してください。）