0

私は問題に対してひどいアプローチをしているかもしれないので、背景を説明します-自己学習.

私はアンドロイド用のアプリを書いており、デフォルトの AVD でテストしています。これは、512 の「デバイス RAM サイズ」と 240 の「抽象 LCD 密度」で WVGA800 に設定されています。

いくつかの画像があり、それらを drawable-hdpi に入れました。そのフォルダーには 458 KB (MB ではない) 相当の画像があります。すべての画像は PNG 形式です。

問題は、最大の画像 (背景に使用) を読み込もうとすると、次のようにスローされることです: java.lang.OutOfMemoryError This is the call to load the image:

BitmapFactory.decodeResource(status.getResources(), R.drawable.background);

これは、残りの画像 (合計 33 個) を読み込む方法と同じです。

最大の画像でメモリが不足することは理にかなっていますが、フォルダーの合計サイズは 458 KB であるため、デバイスに設定されている 512 MB の RAM が不足することはないと思います。

画像をアンロードすることはありません。ロードしたままにして、必要に応じて使用します。以前に別のアプリを作成しました。画像の合計サイズは 563 KB で、合計 82 個の画像がありましたが、この問題はありませんでした (同じ AVD を使用)。実際、以前のアプリでは、各画像を裏返して複数のコピーを作成していましたが、スペースが不足することはありませんでした。現在のアプリは初期ロードで失敗しています - 多くのことが起こる前に。

誰かが問題が何であるかを教えてもらえますか? そして、どうすればそれを解決できるか、または私のアプローチが間違っているかどうかについて言及することもできます (例から独学しています)

4

3 に答える 3

2

どうすればその問題を軽減することができるかについて、いくつかのヒントを提供します

  • すべてのデバイスをサポートする予定の場合は、すべてのリソースを xhdpi フォルダーに配置します。特に背景
  • ファイルサイズ!=メモリサイズ
于 2012-10-15T09:44:39.887 に答える
1

ええ、これはかなり一般的な問題です。そのため、Android OS の古いバージョンでは、ビットマップは JVM ではなくネイティブ メモリに読み込まれていました。ガベージ コレクション プロセスには、実際には 2 つのサイクルがあります。1 つは JVM のメモリをクリアし、もう 1 つはネイティブ メモリ (ビットマップの場合) のメモリをクリアします。古いデバイスで作業したい場合は、ビットマップをリサイクルするかBitmap.recycle()、System.gc()

発生する可能性のある問題が 2 つあります。 1. リサイクルされていない他のビットマップがあります。2. 1 つの画像が大きすぎるため、本当にメモリが不足しています。(他のイメージが正しく再利用または gc されていることを確認して、メモリ フットプリントを増やさないようにしてください)。この場合、できることはあまりありません。

また、mehmetが示唆したように、これを読むことができます

于 2012-10-14T23:28:58.100 に答える
1

次の点に注意してください。

  • アプリケーションにはメモリ制限があります (これは Android のバージョンによって異なります)。すべてのデバイス メモリを取得するわけではありません。最初の Android バージョンには 16 MB のメモリ制限があると思います。
  • ファイルのサイズは、メモリ内のビットマップのサイズを表していません。たとえば、32 ビットの ARGB ビットマップはビットを32*width*height使用します。
  • 大きな画像を扱っている場合は、最初にそれらをスケーリングします。必要なサイズを計算し (これはおそらく のサイズになりますImageView)、サイズ変更されたビットマップのコピーをロードします。これを使用して行うことができますBitmapFactory.Options
于 2012-10-14T23:31:04.223 に答える