2016-04-04 15 views
3

TMXタイルマップを使用するAndroidゲームを開発しています。マップがロードされている間、アプリケーションのメモリ使用量は100MB以上になります。各マップがロードされた後、私はガベージコレクタが(System.gc()を使用して)実行されることを示唆しており、意外にも使用中のメモリの量はまったく減少しません。 System.gc()メソッドを呼び出すとガベージコレクタが確実に実行されるわけではありませんが、デバイスの最大VMヒープサイズは約130MB(他の古いデバイスの場合は16-20MB)と考えています。予想どおり、この後に別のマップがロードされると、アプリケーションはメモリー不足のエラーをスローし、クラッシュします。Androidでメモリが非常に少ないにもかかわらずガベージコレクタが実行されない

しかし、EclipseでDDMSヒープタブ(「原因GC」ボタン)を使用してGCを強制的に実行したときに、アプリケーションのメモリ使用量が元に戻ってしまうように、自分のコードにメモリリークや未解放のリソースがないことを保証できます。約15-16MB。

地図を読み込む際に100MBを超える過剰なメモリ使用量が残っている可能性があります。

答えて

1

イメージの読み込みをどのように扱っているのが実際には分かります。

私はあなたがそれらを扱うためにBitmapクラスを使用していると仮定します。あなたは、このクラスはボンネットの中でもう少し特別であることに気づく必要があります。実際には、ビットマップをバイト配列として表現するネイティブ実装をラップしています。ガベージコレクションはこのケースでは役に立ちません(特定の時点でGCが実行されていることに頼るのは悪い習慣です)。 Bitmapクラスのrecycle()メソッドを詳しく見てください。ビットマップインスタンスが占有するネイティブオブジェクトを解放します。

Javadocでは、高度な呼び出しであり、通常はBitmapインスタンスへの参照はなく、Androidでの画像の経験ではGCがこれを行うため、手動では起動しないようにしていますゲーム開発)、時にはこの種の状況であなたを助けます。

私があなたに与えることができるもう1つのアドバイスは、アプリのヒープを大きくプロファイルすることです。地図が唯一の犯人ではないかもしれません。私はDDMSのメモリ割り当てをトレースし、そこに潜在的な赤旗がないかチェックします。

+0

アドバイスをいただきありがとうございます。私はメモリリークのための私のアプリケーションの別の場所を見て、アンドロイドのビットマップの実装についてさらに読んでいくつもりです。 – rodit

関連する問題