0

私は奇妙な問題に遭遇しました-私はAndroidゲームを作成していて、数秒ごとにラグに気づき、ガベージコレクターが50〜150ミリ秒ごとに数秒ごとに呼び出されていることに気付いたときにログを確認しました。

1 つの背景画像 (150kb) を使用して、タイトル画面のアクティビティを起動するときに、この問題を画像に落とし込みました。メッセージは次のとおりです。

4% フリー (8009k/8259k) GROW HEAP から 9.012MB GC_CONCURRENT 1kb を解放 (9178k/9479k)

これは、画像と 3 つのボタンのための大量のヒープ スペースです。画像を削除しても、警告やメッセージは表示されません (ヒープ領域に出力を強制する方法はわかりませんが、正常なレベルであることを願っています)

アクティビティ イメージのコードは、単なるタイトル画面であるため、それほどエキサイティングではありませんが、次のようになります。

    <ImageView
    android:id="@+id/backgroundImage1"
    android:contentDescription="Image"
    android:src="@drawable/openingscreen" 
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:layout_gravity="top"
    />

実際のゲームを起動すると、ヒープ サイズが再び増加します (数 MB だけ)。奇妙なことに、タイトル画面がなかったとき、メイン ゲームのヒープ スペースはまだ 12 MB 程度だったので、たぶん、画像は他のすべてへの参照を保持していると思います. サイズが 1 ピクセルの背景画像を使用してみましたが、問題は発生しませんでした。

次に、gameThread 内の画像のコード:

mPlayer = Bitmap.createScaledBitmap(mPlayer, mCanvasWidth / 15, mCanvasHeight / 8, true);

canvas.drawBitmap(mPlayer, xPosition, yPosition, null);

ビットマップをスケーリングするとメモリの問題が発生する可能性があるとどこかで聞いたことがありますが、それは実際には他のすべてとは一致しません。

4

3 に答える 3

1

はい、開発中の多くの開発者がこの状況に直面しています。

私があなたにお願いしたいのは、このヒープが正確に何であるか、ガベージコレクターがそれをどのように処理するか、ビットマップを効率的に使用またはスケーリングする方法を徹底的に調査することです。

あなたは最初にこのビデオGoogleAndroidメモリ管理を通過することから始めることができます

次のAndroid開発者サイトでは、 ビットマップを効率的に表示する方法について詳しく説明します。

最後に最後に、MAT（メモリアナライザーツール）を使用する習慣を始めます。チュートリアルがあり、その使用方法と、アプリがメモリを奪われている場所と理由を見つけるためのブログがたくさんあります。

于 2012-08-20T12:10:09.603 に答える
0

更新するだけで、コードの主な問題を発見し、スムーズに実行することができました。他の誰かが同じ間違いを犯すほど愚かではないと思いますが、念のために私の解決策を投稿します!

ゲームの反復ごとに画像のサイズを変更していましたが、そこにコードを入れたことに気づかず、最初にサイズを変更するように変更しました。それだけです。しかし、この解決策が誰にも役立つとは思えませんが、いつかは役立つでしょう!

ケビン。

于 2012-08-21T11:18:33.990 に答える
0

次のフォーミュラーは、画像が占めるヒープスペースの量を示します: 幅 x 高さ x 8 バイト。そのため、すべてが白でサイズが大きいイメージは、依然として多くのヒープ スペースを必要とします。

于 2012-08-20T11:04:26.537 に答える