0

ウェブからダウンロードした写真を壁紙として使用するライブ壁紙アプリがあります。

メモリ マネージャーは、私のアプリが 90MB から 120MB を使用していることを示しています (これは 1GB の RAM を搭載したデバイスです)。それはたくさんあります。壁紙サービスは頻繁に強制終了され、システムがデフォルトの静的壁紙に戻ることさえあります。

メモリ リークを徹底的にチェックし、HPROF ダンプ分析では、現在使用されている大きなオブジェクトが 2 つしかないことが示されています。 12MB)、HPROF 概要画面で報告されている合計 32MB。

dumpsys meminfo はこれを示します:

** MEMINFO in pid 1354 [com.myapp.lwp] **
                     Shared  Private     Heap     Heap     Heap
               Pss    Dirty    Dirty     Size    Alloc     Free
            ------   ------   ------   ------   ------   ------
   Native       16       16       16   112304     5274      993
   Dalvik    41947    19316    41428    74572    53120    21452
   Cursor        0        0        0
   Ashmem        0        0        0
Other dev    20170    33176     3460
 .so mmap     5690     2620     1504
 .jar mmap        0        0        0
 .apk mmap       64        0        0
 .ttf mmap        6        0        0
 .dex mmap      604        0        4
Other mmap     1035      300      272
  Unknown     5127      472     5116
    TOTAL    74659    55900    51800   186876    58394    22445

Objects
           Views:       27         ViewRootImpl:        0
     AppContexts:        4           Activities:        1
          Assets:        3        AssetManagers:        3
   Local Binders:       16        Proxy Binders:       23
Death Recipients:        0
 OpenSSL Sockets:        1

私はこれを読みました: Android でアプリケーションのメモリ使用量を確認するにはどうすればよいですか? しかし、それは私が何かを結論付けるのに役立ちません...

私も使用しました：

    cat /proc/1354/statm
    139422 29326 11550 2 0 10330 0

それもあまり役に立ちません。

DDMS は 63MB のヒープ サイズを示します。

私の質問は？2 倍の画面サイズの画像を扱うアプリは正常であり、期待されるものですか? そうでない場合、残りの 60 ～ 90MB には何がありますか? (HPROF から合計 30MB を差し引いています)。アプリで大量のメモリを使用するために何が間違っている可能性がありますか? 実際に行うアプリ:

1) Download list of photos (max 100) as JSON string and parse that string to get ids and urls for these photos.
2) Download first photo and save it to cache folder
3) Decode photo and if necessary resize it to fit 2Width*Height of screen (photos are actualy smaller that my Full HD screen).
4) Draw it on wallpaper canvas (and draw repeatedly while user is scrolling)
5) If on WIFI download next 10 photos to cache folder (without decoding, just saving)

より多くの写真を同時に使用するより複雑な他のモードがありますが、上記のメモリ使用量は最も単純なシナリオ用です。

これは継続的な使用の問題ではありません。メモリは最初の起動後に説明されているとおりです。サービスを強制終了すると、再起動後に 90MB が使用されます。オプション画面を最初に開いた後 (いくつかのオプションを選択できる小さなアクティビティ/ダイアログ - バックグラウンドのドローアブル以外のグラフィックはありません)、メモリ使用量が 124MB に跳ね上がり、画面を閉じると 112MB に戻ります。壁紙の写真を最初に変更した後、130+ にジャンプし、120+ に戻ります。おそらく、ビットマップのデコード中にヒープサイズが増加し、その後はそのままになるためです。

私は何をすべきか？アプリのメモリ使用量を減らす方法 (可能な場合) はありますか? 他にどこを見る？すぐに解決できるとは思いませんが、さらに詳しいガイダンスがあれば役立ちます...

4

1 に答える 1

1

アプリケーションの作業中に同じ問題が発生しました。DUMP と GC (Logcat から) はどちらも、GC が異なる時間に実行されているため、上下に変動する約 30 ～ 50 MB のメモリを使用していることを示していました。

ただし、何らかの理由で、特に実行中のサービスがある場合は、プロセスの RAM 使用量が増えて解放されていないようです。私のプロセスでは、RAM が 300 MB を超えていることがわかったので、それがリリースされていない (既に GC されている) だけなのか、それともリークされているのかわかりませんでした。

私が確認したことは、アプリケーションを閉じてからしばらく放置したところ、数時間で、サービスが 3 MB の RAM しか使用していないことが示されました。また、多くのアプリケーションを開きました (Android に GC を強制的に実行させるため) ）そして再び、サービスを停止せずに 300 MB から 3 MB に戻ったので、GC せずに構築し続けたので、リークされなかったと思います。

これはまだ十分な保険ではありませんが、何もないよりはましです。私はそれについてもっと調べようと取り組んでいます。

その問題の解決策を見つけたら、親切に教えてください。ありがとう。

于 2014-02-03T20:58:57.433 に答える