Wykorzystanie pamięci (anonimowy RSS + przestrzeń wymiany)

Wykorzystanie pamięci (anonimowa pamięć RSS i przestrzeń wymiany) to wskaźnik, który odzwierciedla wykorzystanie pamięci przez aplikację.

Anonimowa pamięć to pamięć, która nie jest obsługiwana przez plik w pamięci masowej, np. alokacje sterty i pamięć przydzielona za pomocą funkcji mmap. Obejmuje to dynamiczne alokacje pamięci aplikacji, w tym stertę Java lub Kotlin, niezarządzane alokacje sterty natywnej (w której znajdują się dane pikseli bitmapy na Androidzie 8.0 (poziom API 26) i nowszych) oraz stosy wykonywania wątków. System operacyjny może w razie potrzeby zwolnić pamięć powiązaną z plikami, ale nie może zwolnić pamięci anonimowej.

Rozmiar zestawu rezydentnego (RSS) to łączna liczba stron pamięci (zarówno współdzielonych, jak i niewspółdzielonych) używanych przez proces, które są przechowywane w fizycznej pamięci RAM. Strona jest uznawana za „udostępnioną”, jeśli ma do niej dostęp więcej niż 1 proces (np. aplikacje, które korzystają z tej samej biblioteki).

W przypadku pamięci anonimowej system może zapisywać strony w przestrzeni wymiany (lub w zRAM na Androidzie), gdy pamięć jest obciążona. W razie potrzeby system może odczytać te strony z pamięci wymiany.

Łączne wykorzystanie pamięci (anonimowy RSS + przestrzeń wymiany) to miara łącznej liczby stron pamięci aplikacji, które nie są obsługiwane przez plik w pamięci masowej, w tym pamięci, która jest również przechowywana przez system w przestrzeni wymiany. Śledzenie anonimowego rozmiaru zbioru roboczego i pamięci wymiany zapewnia wgląd w rzeczywiste, nieusuwalne wykorzystanie pamięci aplikacji.

Jeśli wykorzystanie pamięci przez aplikację jest wysokie, zbadaj problem i go rozwiąż, korzystając z informacji na tej stronie.

Zasoby

Lokalne diagnozowanie nadmiernego wykorzystania pamięci

Aby rozpocząć diagnozowanie źródła nadmiernego wykorzystania pamięci, możesz zarejestrować zrzut stosu za pomocą opcji Zarejestruj zrzut sterty w ustawieniach programisty, Androidzie Studio lub Perfetto. Zalecamy rozpoczęcie od lokalnego zrzutu pamięci po przetestowaniu podstawowych ścieżek użytkownika w aplikacji.

Zalecamy przetestowanie zwłaszcza tych ścieżek użytkownika:

  • Wyświetlenia witryn i sesje przeglądania w aplikacji
  • Nieskończone przewijanie z dużą ilością multimediów
  • Procesy tworzenia i edytowania komponentów

Aby zbadać potencjalne wycieki pamięci, uruchom odpowiednie ścieżki użytkownika lokalnie i zbierz zrzuty sterty w różnych stanach procesu (widoczny, usługa na pierwszym planie i w pamięci podręcznej), aby sprawdzić, czy aplikacja zwalnia pamięć po przejściu w tło. Aby dowiedzieć się, jak te stany procesu są powiązane z wywołaniami zwrotnymi onTrimMemory, zapoznaj się z wskazówkami dotyczącymi zwalniania pamięci w odpowiedzi na zdarzenia.

Jeśli debugujesz problemy z pamięcią za pomocą profilera Androida Studio, możesz też użyć integracji z LeakCanary, aby usprawnić wykrywanie wycieków pamięci i zduplikowanych bitmap oraz zoptymalizować wykorzystanie obrazów.

Po zebraniu zrzutu sterty zalecamy użycie profilera Androida do analizy zrzutu sterty i zidentyfikowania potencjalnych źródeł wysokiego zużycia pamięci.

Oto przykład odpowiedzi, jakiej może udzielić AI:

I have completed the analysis of memory leaks and bitmap issues for [app] using the provided Perfetto trace.
  Summary of Findings
  The investigation identified a critical memory pressure issue caused by massive bitmap retention within the app process.
...
Recommendations for [app]
   1. [Library] Image Cache Optimization:
       * Review the [Library] caching strategy. Ensure that bitmaps
         loaded for animations are released or downsampled when the animation is
         not in the foreground.
   2. Asset Resolution Audit:
       * The 14.7 MB average size suggests full-screen or extremely high-density assets. Audit the [library] files in the native_home component to ensure they are not using unnecessarily large source images.
   3. View Lifecycle Management:
       * Investigate why 21 [LibraryImage] instances are alive simultaneously. Ensure that views in the bottom
      tab are properly detached or their animations are cleared when switching between tabs.
   4. Fix Surface Leaks:
       * Address the Surface.release failures observed in the logs, as these can lead to both memory leaks and
         native resource exhaustion.

Dodatkowe materiały dotyczące interpretowania zrzutów sterty

Więcej informacji o interpretowaniu zrzutów sterty i debugowaniu wykorzystania pamięci znajdziesz w tych materiałach:

Poprawienie wykorzystania pamięci

Więcej informacji o zmniejszaniu wykorzystania pamięci przez aplikację znajdziesz w tych sekcjach:

Szczegółowe wskazówki dotyczące rozwiązywania problemów z pamięcią znajdziesz w przewodniku Zarządzanie pamięcią aplikacji.