W uproszczonej wersji mojej aplikacji mam dwie czynności, A i B. Actvity A uruchamia B, a po pewnej pracy B wywołuje wykończenie (). Używanie narzędzia Analizator pamięci na większości urządzeń (Galaxy Nexus z 4.2, Droid 4 z 4.0.4 i Droid 2 z 2.3.4) nie wykazuje śladu aktywności B, czego się spodziewałem.

Ale w Samsung S3 z systemem 4.1.1, MAT pokazuje aktywność obiektów B nadal wokół, ze względu na ścieżki do następujących korzeni GC (z wyjątkiem słabych / miękkich odniesień):

Class Name                                                        | Shallow Heap | Retained Heap
-------------------------------------------------------------------------------------------------
com.myCo.myApp.ActivityB  @ 0x42720818                            |          264 |         3,280
|- <Java Local> java.lang.Thread @ 0x4271cf60  Thread-21941 Thread|           80 |        52,264
|- mOuterContext android.app.ContextImpl @ 0x426adf68             |          104 |           784
    |  '- mContext android.media.AudioManager @ 0x428e49a0        |           48 |           152
-------------------------------------------------------------------------------------------------

Za każdym razem, gdy rozpoczynam i kończę działanie B, MAT pokazuje inny przykład działania pamięci B. I im więcej otwieram / zamykam aktywność B, tym większy jest zapis pamięci w logcat. Wymuszanie GC przez MAT nie usuwa odniesień do pamięci B aktywności.

Mam trzy pytania.

Dlaczego zachowanie pamięci / GC różni się na różnych urządzeniach?

Czy w systemie S3 system operacyjny w końcu powróci, a GC zablokuje obiekty B (innymi słowy, czy nie powinienem się tym martwić, ponieważ Android oczyści go przed awarią)?

Jeśli nie, skąd pochodzą odwołania do wątków i AudioManagera i jak je usunąć?

Dziękujemy wszystkim doświadczonym „łowcom wycieków”!