2

したがって、ハニカムの前は、ビットマップ オブジェクトは ( malloc を使用して) ネイティブ ヒープ メモリ空間の単なるポインターであり、.recycle() を呼び出してそのネイティブ メモリをクリーンアップできました。ハニカムの後、ビットマップのメモリがアプリ ヒープに割り当てられ、gc 呼び出しが取得されます。

私の質問は、私のアプリは 2.2+ をサポートする必要があるので、どうすればよいですか? バージョンを確認し、リサイクルを呼び出しますか? リサイクルをまったく呼び出さないでください。そのためのアドバイスは何ですか。私はいくつかの Bitmap インスタンスを保持する BitmapCache を持っており、それらをメモリに永久に保存したくないためです。

4

3 に答える 3

3

フロヨ、ジンジャーブレッド、ハニカムのいずれの Android バージョンでも。メモリ管理については、自分で確認する必要があります。はい、2.2 以降では、sdcard からアプリケーションを調整できますが、ビットマップをヒープ メモリに保持すると、どちらのバージョンを使用する場合でも常に問題が発生します。ビットマップを純粋に使用したい場合は、このリンクを試してみてください。ビットマップを効率的に管理するための多くの方法が提供されています。このリンクに従ってください: ビットマップを効率的に表示する

于 2012-04-21T03:41:19.387 に答える
0

まず、Android 2.2、または Android 3.0、または Android 3.0 以上の Android プラットフォーム バージョン、使用したくないビットマップ、呼び出しも必要です。bitmap.recycle()

ただしandroid >=3.0、ビットマップは dalvik ヒープに保存され、ネイティブ ヒープには保存されません。Javaヒープのように、オブジェクトを参照するための参照がいくつかある場合、オブジェクトはgcシステムによって存在できず、ビットマップメモリ​​は多くのメモリを消費する可能性があります。オブジェクト参照カウンターがゼロであることを確認しないと、大きな問題になります.

あなたが言ったビットマップキャッシュはビットマップを保存できるので、WeakReferenceまたはを使用SoftReferenceしてビットマップを保存し、またはを使用してWeakReference.get()ビットSoftReference.get()マップを返すと、bitmap参照はシステムの正しい制御下にあります。それ以外の場合は、自分で管理する必要があります。

于 2012-04-21T05:12:23.950 に答える
0

開発者ページで気づいたように、弱い参照は時代遅れの解決策であると彼らは言いました.私がここに残したリンクからすべてのビットマップ参照チュートリアルを確認し、スケールダウン(可能な場合)、キャッシュとAsyncTask、およびこの例からの遅延ビットマップロードを使用してみてください..

これらを組み合わせることで解決策になると確信しています..

ところで..私も現在このトピックに取り組んでいます.弱い参照は問題ありませんが、完璧な解決策ではないため、AndroidOSの将来のバージョンでアプリをラグプルーフにしたいと考えています..

リンクが多すぎないことを願っていますが、取得すると魅力的に機能します;)

乾杯

于 2012-04-24T15:05:24.690 に答える