数か月間、Android用のゲームを開発するためにAndEngineフレームワークを使用してスキルをテストしてきました。
今、私は紛らわしい問題に直面しています。私たちのプロジェクトでは、このアクティビティの静的HashMapにアクティビティのすべてのTextureAtlas（つまりテクスチャ）を保持しています。これにより、メモリリークの問題や、そのような不快な問題が発生する可能性がありますか？Androidで静的変数の矛盾することをたくさん聞いたので、それについてどう考えるかわかりません。
画面の回転がブロックされているため、トラップが少なくとも1つ少なくなっていることに注意してください。
前もって感謝します ！
これにより、メモリリークの問題やそのような不快なものが発生する可能性がありますか?
Java の静的データ メンバーは、定義上、メモリ リークです。これらのオブジェクト、およびそれらが参照するものは、少なくともそれらへの静的参照が削除されるまで、ガベージ コレクションできません。
これが問題かどうかは別問題です。たとえば、4 バイト整数のリークは問題になりません。DDMS を使用してヒープ ダンプを生成し、MAT を使用してそれを調べて、静的なメモリの量を「実際に」確認できHashMapますTextureAtlas。
のような静的コレクションのHashMap場合、重要なのは、不要になったエントリを確実に削除することです。コレクションに何かを追加し続け、何も削除しないため、コレクションがどんどん大きくなっていくと、メモリ リークが問題になります。状況によっては、WeakHashMap(キーが弱く保持されているため、他にキーが使用されていないときにマップ エントリが消えてしまう) がより良い解決策になる場合があります。
Activityインスタンスへの逆参照がある場合、静的変数は不適切です。これは、アプリの使用のライフサイクルの中でアクティビティが数回再現されたためです（たとえば、スマートフォンを切り替えたとき）。
たとえば、次のコードは安全です。
private static Long mMyLong;
しかし、これは安全ではありません：
private static Context mContext;
時々注意してください、いくつかの明白でない後方参照があります。
この種の問題を回避するには、静的HashMapをアプリケーションクラスに保存する必要があります（アプリケーションクラスの作成に関する他の投稿https://stackoverflow.com/a/13994622/1789730をここで見つけることができます）。したがって、アクティビティのライフサイクルに関係なく、ハッシュマップは1回作成されます。その上、あなたはパフォーマンスを向上させるでしょう。参照を保持しないようにするために、YourActivity.onDestroy（）でハッシュマップとそのコンテンツをnullに設定し、YourActivity.onCreate（）で再作成することができます。
ハッシュマップが死亡の参照を保持している場合は、次の経験をシュールにすることができます。上記のように、ハッシュマップをアプリケーションクラスに配置します。スマートフォンをポートレート/ランドスケープに切り替えて、アクティビティを再現します。したがって、ハッシュマップオブジェクトを使用してアクティビティがクラッシュした場合、それはアクティビティへの参照を保持することを意味します。