2014-01-17 65 views
2

我正在申請看電影,它在網格,列表和水平滾動視圖中顯示類別和電影的圖像。 應用程序有幾個活動,並在他們每一個都顯示圖像。 Proglem是當用戶改變活動只是轉發,在一個點的應用程序與OutOfMemory異常崩潰。安卓應用內存問題

使用堆和MAT工具,我發現位圖在每個活動中都使用堆的巨大內存。在同樣的手機上,像三星Galaxy S4和阿爾卡特OneTouch偶像全高清顯示,應用程序崩潰只有2-3個活動。這是瘋狂:)

所以,我的問題是,我如何克服這個問題與內存? 我知道這是普通的Android問題,但我必須做些事情來解決這個問題。

每張圖片的位置都是最佳的(圖片尺寸在附加到圖片視圖之前會被精確測量)。 乾杯。

+0

發佈有關位圖的代碼。 – npace

+0

很抱歉,系統對於代碼發佈來說太大了。 :) 基本上,我不得不回收堆內存,並比用戶剛剛前進與acitivies。我需要一個人來解釋一下當視圖和它們的位圖和內存發生什麼時,當活動暫停並放在後臺並顯示其他活動時。 – Gaca

回答

1

做一些分析。

你沒有提供任何代碼或日誌。所以,會告訴你我遵循的基本方法。

開始你的第一個活動。連續運行adb shell dumpsys「PID」或「PackageName」。

在您重現活動時獲取信息。 執行adb shell " while true ; do dumpsys meminfo 22188 ; done ; " > dumpsysOfsmthn.txt

* MEMINFO in pid 22188 [com.sec.android.smthn] ** 

        Pss Private Private Swapped  Heap  Heap  Heap 

       Total Dirty Clean Dirty  Size Alloc  Free 

       ------ ------ ------ ------ ------ ------ ------ 

    Native Heap  44  44  0  0 11132 10455  184 

    Dalvik Heap 19189 18804  0  0 25660 19221  6439 

Dalvik Other  3891  3828  0  0       

     Stack  200  200  0  0       

     Ashmem  2  0  0  0       

    Other dev  8168  7844  4  0       

    .so mmap  1990  1032  508  0       

    .jar mmap  5  0  4  0       

    .apk mmap  315  0  124  0       

    .ttf mmap  21  0  4  0       

    .dex mmap  6553  248  5584  0       

    Other mmap  90  4  20  0       

     Unknown  5743  5740  0  0       

     TOTAL 46211 37744  6248  0 36792 29676  6623 



Objects 

       Views:  39   ViewRootImpl:  1 

     AppContexts:  4   Activities:  1 

       Assets:  3  AssetManagers:  3 

     Local Binders:  78  Proxy Binders:  42 

    Death Recipients:  2 

    OpenSSL Sockets:  0 



SQL 

     MEMORY_USED:  286 

    PAGECACHE_OVERFLOW:  53   MALLOC_SIZE:  62 



DATABASES 

     pgsz  dbsz Lookaside(b)   cache Dbname 

     4  24    53   2/17/3 /data/data/com.sec.android.smthn/databases/sns.db 

     4  32    55   1/13/2 /data/data/com.sec.android.smthn/databases/picasa.db 

     4  36    27  10/17/3 /data/data/com.sec.android.smthn/databases/local.db 

Applications Memory Usage (kB): 

Uptime: 31556347 Realtime: 96096816 

檢查哪個部分的一部分在不斷地增加。

它可能是ViewRootImpl或活動上下文或任何東西。

以上信息可能會引起您一些線索。

正如告訴採取堆轉儲分析與MAT或JHAT。 墊是awewome工具恕我直言。

you should look for memory leaks caused by: 

Long-lived references to an Activity, Context, View, Drawable, and other objects that may hold a reference to the container Activity or Context. 
Non-static inner classes (such as a Runnable, which can hold the Activity instance). 
Caches that hold objects longer than necessary. 

任何Object都可能導致泄漏。通常位圖很大。如果內存不足很容易發生,那麼您需要檢查像位圖這樣的重物。

對於MAT和泄漏理解Click this

而且this

除上述事項外,您還可以使用DDMS分配跟蹤器獲取更多線索>是的沒有什麼比MAT獲得更好的數據。

另請查看這篇文章。 Very informative