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

Wykorzystanie pamięci (anonimowy RSS + przestrzeń wymiany) to wskaźnik w Android Vitals, który odzwierciedla wykorzystanie pamięci przez Twoją aplikację.

Pamięć anonimowa to pamięć, która nie jest obsługiwana przez plik na urządzeniu pamięci masowej, np. przydzielanie sterty i pamięć przydzielona za pomocą funkcji mmap. Rejestruje dynamiczne alokacje pamięci aplikacji, w tym stertę Javy lub Kotlina, niezarządzane alokacje sterty natywnej (w której znajdują się dane pikseli bitmapy na Androidzie 8.0 (poziom API 26) i nowszych) oraz stosy wykonawcze wątków. System operacyjny może zwolnić pamięć z pliku, gdy jest pod presją, ale nie może zwolnić pamięci anonimowej.

Rozmiar zestawu rezydentnego (RSS) to łączna liczba stron pamięci (współdzielonych i niewspółdzielonych) używanych przez proces, które są przechowywane w fizycznej pamięci RAM. Strona jest uznawana za „współdzieloną”, 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 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 RSS + swap zapewnia, że widzisz rzeczywiste, nieusuwalne wykorzystanie pamięci aplikacji.

Jeśli aplikacja zużywa dużo pamięci, zbadaj problem i go rozwiąż, korzystając z informacji na tej stronie.

Określanie wysokiego wykorzystania pamięci

Android Vitals

Android Vitals udostępnia dane o wykorzystaniu pamięci przez aplikację podzielone według tych stanów procesu:

  • Na pierwszym planie: proces aplikacji jest widoczny. Wysoki poziom P99 często wpływa na wydajność odczuwaną przez użytkownika (zacinanie się lub awarie z powodu braku pamięci) i jest w dużej mierze spowodowany przez nieusunięte komponenty lub aktywności interfejsu.
  • Usługa na pierwszym planie: aplikacja uruchamia usługę na pierwszym planie. Ponieważ te usługi są przeznaczone do długotrwałych zadań, są one idealnymi kandydatami do kumulatywnych wycieków cyklu życia, które z czasem agresywnie zwiększają ogon P99.
  • Tło: aplikacja uruchamia usługę w tle lub niedawno została przeniesiona w tło, ale nie została jeszcze zapisana w pamięci podręcznej. W tym miejscu dochodzi do wycieku przetwarzania w tle.
  • W pamięci podręcznej: aplikacja jest w stanie pamięci podręcznej. Ten stan jest bardzo wrażliwy na wykorzystanie pamięci systemowej, np. na LMK. Ponieważ system operacyjny może w dowolnym momencie usunąć ten stan procesu, jest on udostępniany tylko do celów debugowania.

Aby dowiedzieć się, jak te stany procesu są powiązane z onTrimMemory wywołaniami zwrotnymi, zapoznaj się z wskazówkami dotyczącymi zwalniania pamięci w odpowiedzi na zdarzenia.

Android Vitals dzieli też wykorzystanie pamięci przez aplikację na przedziały pamięci RAM. Dane o wykorzystaniu pamięci są wyświetlane jako oś czasu z dziennymi wartościami percentyli oraz najnowszymi dziennymi wartościami 50. i 90. percentyla.

Gdy określisz poziom bazowy pamięci, postępuj zgodnie z instrukcjami, aby zdiagnozowaćpoprawić nadmierne wykorzystanie pamięci.

Identyfikowanie wycieków pamięci za pomocą odchylenia ogona

Aby wykryć wycieki pamięci, w Android Vitals poszukaj rozbieżności między typowymi (P50) a końcowymi (P90) użytkownikami. Ogólne zwiększenie rozmiaru zasobów powoduje równomierne zwiększenie pamięci we wszystkich percentylach, natomiast wycieki pamięci narastają z czasem, co powoduje duże odchylenia w danych na końcu zakresu.

Wartości P90 i P99 należy porównać z wartością P50 dla każdego procesu. Jeśli stosunek wartości P90 do P50 przekracza 3,5, oznacza to prawdopodobny wyciek pamięci podczas dłuższych sesji. W niektórych przypadkach użycia podwyższony współczynnik nie zawsze wskazuje na wyciek pamięci, ale należy ocenić konkretny przepływ pracy, aby określić, czy zwiększone wykorzystanie pamięci jest oczekiwanym zachowaniem.

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 stosu w ustawieniach programisty, Android Studio lub Perfetto. Zalecamy rozpoczęcie od lokalnego przechwycenia zrzutu sterty po przetestowaniu podstawowych ścieżek użytkownika w aplikacji.

Szczególnie zalecamy przetestowanie tych ścieżek użytkownika:

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

Aby zbadać potencjalne wycieki pamięci, najpierw zidentyfikuj procesy, które zużywają najwięcej pamięci, korzystając z tabeli Nazwa procesu na panelu Wykorzystanie pamięci w Android Vitals. Następnie uruchom odpowiednie ścieżki użytkownika lokalnie i zbierz zrzuty pamięci 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.

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

Po zebraniu zrzutu stosu zalecamy użycie umiejętności AI Perfetto do przeanalizowania zrzutu stosu i zidentyfikowania potencjalnych źródeł wysokiego wykorzystania pamięci.

Oto przykład odpowiedzi, jakich mogą udzielić umiejętności 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.