3

データベースから約 3000 レコード (@ 約 100 バイト) をメモリBrowseActivityにロードし、ListView. AVD でロードするのに約 3 ～ 6 秒かかりますが、これは問題ありません。

this 内から新しいアクティビティを開始したいときに問題が発生しますBrowseActivity。最も些細なアクティビティを開くだけでも、約 30 秒かかります。Dalvik VM は、不明な理由で多くのガベージ コレクションを行っているようです。logcat以下の出力を確認してください。

01-30 02:06:27.025: D/dalvikvm(553): GC_FOR_MALLOC freed 3889 objects / 221200 bytes in 45ms
01-30 02:06:28.234: D/dalvikvm(553): GC_FOR_MALLOC freed 2784 objects / 76864 bytes in 48ms
01-30 02:06:29.614: D/dalvikvm(553): GC_FOR_MALLOC freed 2665 objects / 70088 bytes in 64ms
01-30 02:06:30.915: D/BrowseActivity(553): Low memory status: false
01-30 02:06:30.915: D/BrowseActivity(553): Low memory threshold (KB): 16384
01-30 02:06:30.915: D/BrowseActivity(553): Memory available (KB): 451348
01-30 02:06:31.095: D/dalvikvm(553): GC_EXTERNAL_ALLOC freed 2711 objects / 85904 bytes in 62ms
01-30 02:06:49.705: D/dalvikvm(553): GC_FOR_MALLOC freed 8894 objects / 600272 bytes in 89ms
01-30 02:06:50.414: D/dalvikvm(553): GC_FOR_MALLOC freed 10757 objects / 730720 bytes in 68ms
01-30 02:06:51.105: D/dalvikvm(553): GC_FOR_MALLOC freed 10251 objects / 694864 bytes in 67ms
... and about 30 more garbage collection messages

1 と 300 というより少ないレコード数で既に実験しました。その結果、ガベージ コレクション メッセージが大幅に少なくなり (それぞれ 1 秒と 7 秒)、アクティビティの読み込みが大幅に高速化されました (それぞれ 1 秒と 6 秒)。ただし、メモリの可用性の違いは次のとおりです。非常に些細なこと:

01-30 02:03:35.295: D/BrowseActivity(491): Low memory status: false
01-30 02:03:35.295: D/BrowseActivity(491): Low memory threshold (KB): 16384
01-30 02:03:35.295: D/BrowseActivity(491): Memory available (KB): 453184

01-30 02:04:53.494: D/BrowseActivity(522): Low memory status: false
01-30 02:04:53.494: D/BrowseActivity(522): Low memory threshold (KB): 16384
01-30 02:04:53.494: D/BrowseActivity(522): Memory available (KB): 453152

アクティビティの読み込み時間が遅いのは、GC のオーバーヘッドが原因のようです。私の質問は、Dalvik VM が多くの GC を実行するのはなぜですか? 3000 のレコードがあっても、メモリ内の上位 500 KB しか使用しないと思います。GC のオーバーヘッドが原因でない場合、アクティビティの負荷が遅い原因として他に考えられるものは何ですか?

記録のために、組み込みクラスActivityManager.MemoryInfoによって提供される情報を使用して、メモリの可用性を記録しました。

4

1 に答える 1

1

3000 レコードを含むアクティビティへの参照がないと思います。アクティビティを変更すると、GC がアクティブになります。

MVC タイプのパターンを使用し、各アクティビティへの参照を持つコントローラーがある場合、GC がそれらのレコードをクリーンアップするとは思わない。メモリのセクションが存在するが、それへの既知の参照がない場合、GC が開始されます。アクティビティを切り替えると、アクティビティへの参照とそのすべての関数およびメンバー変数が使用されなくなるため、クリーンアップする必要があります。

GC の動作はハードウェアにも依存する場合があります。つまり、システムに利用可能なメモリが大量にある場合、ない場合とは異なる動作をする可能性があります。

3000 を超えるレコードがロードされたアプリがあり、コントローラーには各アクティビティへの参照があるため、リスト ビューのアダプター内のデータはクリーンアップされません。

オーバーヘッドに関しては、これは必ずしも GC ではありませんが、オーバーヘッドの一因となっているようです。その他の唯一の要因は、コンポーネントを画面にレンダリングするのにかかる時間などです。

それが役立つことを願っています!

〜ダン

于 2013-01-30T03:24:29.873 に答える