11

私は、多くの割り当て (400 万の double と 100 万のクラス) を処理するアプリに取り組んでいます。ガベージ コレクターのログを調べていたところ、さまざまなデバイスでさまざまな量のメモリが解放されていることがわかりました。

たとえば、私は Moto X (2014) を持っていて、最終的に 312 MB 強を解放します。また、同じデータに対して同じコードを実行する Droid Bionic を使用して、平均で 616 MB を解放しています。両方のデバイスのヒープ サイズは約 50 MB になります。

Bionic の GC によって、Moto X よりもはるかに多くのメモリが解放されるのはなぜですか? それぞれ同じ量のガベージを生成する必要があります。ガベージ コレクターの舞台裏で何が起こっているのでしょうか。Moto X は Android 5.1 で、Bionic は 4.1.2 です。

編集: 約 300 MB の RAM を解放している 4 つのデバイスがあります: Moto X (2014)、Nexus 7 2013、Nexus 7 2012、および Razr i。これらの 4 つすべてが ART を使用します。Bionic は Dalvik ランタイムを実行しています。これが解放が少ない理由ですか？GC_FOR_ALLOC は ART では発生しませんが、Dalvik では常に呼び出されていることに気付きました。

4

1 に答える 1

1

この投稿からの引用：

次に、ART チームはガベージ コレクター (GC) の最適化に取り組みました。Dalvik では GC ごとに合計約 10 ミリ秒かかる 2 つの一時停止の代わりに、通常は 2 ミリ秒未満の 1 つの一時停止だけが表示されます。また、GC 実行の一部を並列化し、収集戦略を最適化して、デバイスの状態を認識できるようにしました。たとえば、完全な GC は、電話がロックされていて、ユーザー操作の応答性が重要でなくなった場合にのみ実行されます。これは、フレーム落ちに敏感なアプリケーションにとって大きな改善です。

著者がここで述べていることは、GC が「無駄にする」時間と実行時に解放されるメモリの量の両方に関して、ART 搭載デバイスは GC のコンテキストではるかに効率的であるということです。

メモリ使用量の削減への追加の貢献は、これに起因する可能性があります (これは単なる推測です)。

おそらく最も重要な改善点として、ART は、ユーザーのデバイスにインストールされたときに、アプリケーションをネイティブ マシン コードにコンパイルするようになりました。コンパイラは特定のアーキテクチャ (ARM、x86、MIPS など) に合わせて調整されているため、事前コンパイルと呼ばれ、パフォーマンスが大幅に向上することが期待できます。これにより、アプリケーションを実行するたびにジャストインタイムでコンパイルする必要がなくなります。したがって、アプリケーションのインストールには少し時間がかかりますが、クラスやメソッドの検証など、Dalvik VM で実行時に実行される多くのタスクが既に実行されているため、起動時の起動は速くなります。

ART は事前にアプリをコンパイルするため、コンパイル時間を延長できるため、コンパイラはコードを最適化するより良い仕事を実行できます。

于 2015-08-07T20:24:48.077 に答える