3

大きなビットマップを処理するなど、メモリを大量に消費するアプリケーションがあります。このようなビットマップを処理するためのよく知られた手法を使用してアプリケーションを調整しました（回答のチュートリアルへのリンクはありません...）。OutOfMemoryError例外なく正常に動作するようにしましたが、HC および ICS を実行しているデバイスでのみ、同じアプリケーションが Jelly Bean でメモリ消費量が約 80% 増加し、ユーザー エクスペリエンスが低下し、アプリの動作が遅くなり、動作が遅くなります。

簡単なテストを用意しました。Eclipse のテンプレートを使用して最も単純な Android アプリケーションを作成しました。アプリには、バックグラウンド ビットマップ (1280 x 800) を持つアクティビティが 1 つだけあります。Android 3.1 (Asus A500) を搭載したデバイスでは、以下が割り当てられます。

01-23 12:28:02.402: D/dalvikvm(31706): GC_FOR_ALLOC freed 65K, 4% free 6559K/6787K, paused 17ms
01-23 12:28:02.402: I/dalvikvm-heap(31706): Grow heap (frag case) to 10.355MB for 4096016-byte allocation
01-23 12:28:02.432: D/dalvikvm(31706): GC_CONCURRENT freed 1K, 3% free 10558K/10823K, paused 1ms+2ms

JellyBean 4.2.1 を搭載した Nexus 7 では、以下を割り当てます。

01-23 12:13:49.740: D/dalvikvm(23815): GC_FOR_ALLOC freed 84K, 4% free 7464K/7700K, paused 18ms, total 18ms
01-23 12:13:49.750: I/dalvikvm-heap(23815): Grow heap (frag case) to 11.338MB for 4096016-byte allocation
01-23 12:13:49.770: D/dalvikvm(23815): GC_FOR_ALLOC freed 1K, 3% free 11463K/11704K, paused 23ms, total 23ms
01-23 12:13:49.800: D/dalvikvm(23815): GC_CONCURRENT freed <1K, 3% free 11463K/11704K, paused 2ms+2ms, total 23ms
01-23 12:13:49.900: D/dalvikvm(23815): GC_FOR_ALLOC freed <1K, 3% free 11463K/11704K, paused 12ms, total 13ms
01-23 12:13:49.920: I/dalvikvm-heap(23815): Grow heap (frag case) to 18.259MB for 7259056-byte allocation
01-23 12:13:49.940: D/dalvikvm(23815): GC_FOR_ALLOC freed 0K, 2% free 18552K/18796K, paused 16ms, total 16ms
01-23 12:13:49.960: D/dalvikvm(23815): GC_CONCURRENT freed <1K, 2% free 18552K/18796K, paused 3ms+2ms, total 17ms

だから私は2つの質問があります：

1、メイン アクティビティのバックグラウンドでビットマップを 1 つだけ使用すると、アプリケーションが大量のメモリを消費するのはなぜですか?

2、同じアプリケーションを実行すると、JellyBean を搭載したデバイスのメモリ消費量が約 80% 増加するのはなぜですか?

EDIT1：

すべてのデバイスの画面解像度は同じです: 1280 x 800 px

4

1 に答える 1

1

私は同じことに遭遇しています-残念ながら、Androidの最新バージョンが3dアクセラレータを可能な限り使用しようとするという事実が原因であると思われます-彼らはあなたのイメージのコピーを取り、それを3dアクセラレータに渡しますwhen は、ユーザーが見る実際のピクセルをレンダリングするために使用されます。これが、より高いメモリ消費が見られる理由です。

それについて何ができるかについては、残念ながらあまりありません。このより高いメモリ使用量により、全体的にはるかにスムーズな UI が得られます (これは、android 4.1 で導入されたプロジェクト バターです)。ビットマップを効率的に表示するグーグルなどのさまざまなチュートリアルをすでに調べている場合は、マニフェストのアプリケーション要素でlargeHeapをオンにしてみることをお勧めします。

さらに、アプリの動作方法によっては、ビットマップをリサイクルできる場合があります。 この Google の DevBytes ビデオでは、その方法が説明されています。

于 2013-02-03T07:28:07.507 に答える