Omówienie zarządzania pamięcią

używanie środowiska wykonawczego Androida (ART) i maszyny wirtualnej Dalvik. stronicowanie i mapowanie pamięci (mmapping) w celu zarządzania pamięcią. Oznacza to, że każda pamięć aplikacji modyfikuje—przez przydzielanie nowe obiekty lub dotykają zmapowanych stron—jest przechowywany w pamięci RAM nie można przekazać na inną stronę. Jedynym sposobem na zwolnienie pamięci z aplikacji jest wydanie odwołania do obiektów są przechowywane przez aplikację, udostępniając pamięć śmieciarek. Z jednym wyjątkiem: wszystkie pliki zamapowane bez modyfikacji, takie jak kod, mogą zostać wyrzucone z pamięci RAM, jeśli system chce użyć tej pamięci gdzie indziej.

Na tej stronie wyjaśniamy, jak Android zarządza procesami i pamięcią aplikacji przydziału danych. Więcej informacji o wydajniejszym zarządzaniu pamięcią w aplikacji, zobacz Zarządzanie pamięcią aplikacji

Czyszczenie pamięci

zarządzane środowisko pamięci, takie jak maszyna wirtualna ART lub Dalvik, śledzi każdą alokację pamięci. Gdy stwierdzi, że program nie używa już danego fragmentu pamięci, zwalnia go z powrotem do stosu bez ingerencji programisty. Mechanizm odzyskiwania niewykorzystanej pamięci w ramach zarządzanego środowiska pamięci jest znany jako zbiórnik odpadów. Główne cele zbierania pamięci podręcznej to: znajdowanie w programie obiektów danych, do których nie będzie można uzyskać dostępu w przyszłości; odzyskiwanie zasobów używanych przez te obiekty.

Stos pamięci Androida jest generacją, co oznacza, że różnych zasobników alokacji, które śledzi, na podstawie oczekiwanego czasu życia i rozmiaru przydzielanego obiektu. Na przykład ostatnio przydzielone obiekty należą do młodego pokolenia. Jeśli obiekt pozostaje aktywny przez odpowiednio długi czas, może zostać przeniesiony do starszej generacji, a następnie do generacji stałej.

Każda generacja sterty ma własny specjalny górny limit kwoty jaką pamięć mogą zajmować obiekty. Za każdym razem, gdy rozpocznie się pokolenie aby je zapełnić, system wykonuje czyszczenie pamięci wydarzenia, aby zwolnić pamięć. Czas trwania czyszczenia pamięci zależy od generacji zbieranych obiektów i liczbę aktywnych obiektów w poszczególnych pokoleniach.

Czyszczenie pamięci może być dość szybkie, ale może na wydajność aplikacji. Zwykle nie masz kontroli gdy zdarzenie czyszczenia pamięci występuje w kodzie. System ma aktywny zestaw kryteriów, który określa, kiedy należy czyszczenia pamięci. Gdy kryteria zostaną spełnione, system przerywa wykonywanie procesu i rozpoczyna zbieranie elementów zbędących. Jeśli usuwanie czyszczenia pamięci odbywa się w trakcie intensywnej pętli przetwarzania takich jak animacja czy odtwarzanie muzyki, może to wydłużyć czas przetwarzania. Ten wzrost może spowodować wymuszenie wykonania kodu w aplikacji poza zalecany próg 16 ms na potrzeby wydajnego i płynnego renderowania klatek.

Poza tym przepływ kodu może wykonywać działania, wymuszanie występowania zdarzeń czyszczenia pamięci lub wydłużać czas oglądania. Jeśli na przykład przydzielisz wiele obiektów w najbardziej wewnętrzna część pętli for w trakcie każdej klatki alfa mieszania animacji, możesz zanieczyścić stertę pamięci wiele obiektów. W takiej sytuacji moduł czyszczenia pamięci wykonuje wiele operacji czyszczenia zdarzenia zbierania danych i mogą pogorszyć wydajność aplikacji.

Ogólne informacje o odśmiecaniu znajdziesz w artykule Odbiór śmieci.

Udostępnij wspomnienie

Aby zmieścić wszystko, czego potrzeba w pamięci RAM, Android próbuje współdzielić strony dotyczące pamięci RAM między procesami. it może to zrobić na kilka sposobów:

• Każdy proces aplikacji jest rozwidlony na podstawie istniejącego procesu o nazwie Zygote. Proces Zygote rozpoczyna się po uruchomieniu systemu i wczytaniu typowych kod platformy i zasoby (np. tematy aktywności). Aby rozpocząć nowy proces aplikacji, system tworzy proces Zygote, a następnie wczytuje i uruchamia kod aplikacji w nowym procesie. Dzięki temu większość stron pamięci RAM przydzielonej do kodu i zasobów platformy może być współużytkowana przez wszystkie procesy aplikacji.
• Większość danych statycznych jest wplatana w proces. Ta technika umożliwia udostępnianie danych między procesami, a także ich wymianę w ramach stron w razie potrzeby. Przykładowe dane statyczne: Kod Dalvik (umieszczając go we wstępnie połączonym kodzie .odex plik do bezpośredniego mmappingu), zasoby aplikacji (projektując tabelę zasobów jako strukturę który można ukryć, a pozycje pakietu APK) oraz tradycyjnego projektu takie jak kod natywny w plikach .so.
• W wielu miejscach Android ma tę samą Pamięć RAM między procesami z wykorzystaniem jawnie przydzielonej pamięci regiony współdzielonej pamięci (Ashmem lub Gralloc). Na przykład powierzchnie okien korzystają z udostępnianych pamięć między aplikacją a kompozytorem ekranu, bufory kursorów używają pamięci współdzielonej między dostawcą treści i klientem.

Ze względu na duże wykorzystanie pamięci współdzielonej określanie ile pamięci używa aplikacja; opiekę. Techniki prawidłowego określania wykorzystanie pamięci jest omawiane w Badanie wykorzystania pamięci RAM

Przydzielanie i odzyskiwanie pamięci aplikacji

Stos Dalvik jest ograniczony do jednego zakresu pamięci wirtualnej dla każdego procesu aplikacji. Definiuje to rozmiar stosu logicznego, który może rosnąć w miarę potrzeb ale tylko w granicach określonych przez system dla każdej aplikacji.

Rozmiar logiczny stosu nie jest taki sam jak ilość fizycznej pamięci używanej przez stos. Podczas sprawdzania stosu aplikacji Android oblicza wartość zwaną proporcjonalnym rozmiarem zbioru (PSS), która uwzględnia zarówno brudne, jak i czyste strony udostępniane innym procesom, ale tylko w stosunku do liczby aplikacji, które korzystają z tej pamięci RAM. Ta suma (PSS) odpowiada temu, traktuje swoje zużycie pamięci fizycznej. Więcej informacji o PSS znajdziesz w Badanie wykorzystania pamięci RAM Google.

Stos Dalvik nie kompaktuje funkcji logicznej rozmiaru stosu, co oznacza, że Android przeprowadzić defragmentację stosu, aby zmniejszyć przestrzeń. Android, zmniejszać rozmiar stosu logicznego tylko wtedy, to nieużywane miejsce na końcu sterty. Pamiętaj jednak: system może nadal ograniczać pamięć fizyczną używaną przez stertę. Po odśmiecaniu Dalvik przemierza stertę i znajduje nieużywane strony, a następnie zwraca i przekaże te strony do jądra. Dlatego sparowano alokacje i przydziały dużych fragmenty powinny skutkować odzyskaniem wszystkich (lub prawie wszystkich) wykorzystywanej pamięci fizycznej. Pamiętaj jednak: odzyskanie pamięci z niewielkich alokacji może być jest mniej skuteczne, ponieważ strona wykorzystała w przypadku małego przydziału mogą być nadal udostępniane czegoś innego, co nie zostało jeszcze uwolnione.

Ograniczanie pamięci aplikacji

Aby zachować funkcjonalne środowisko wielozadaniowości, Android ustawia stały limit rozmiaru sterty dla każdej aplikacji. Dokładny limit rozmiaru sterty różni się między urządzeniami w zależności od ilości pamięci RAM dostępnych ogólnie. Jeśli Twoja aplikacja osiągnie pojemność stosu i próbuje przydzielić więcej pamięci, może otrzymać błąd OutOfMemoryError.

W niektórych przypadkach możesz wysyłać zapytania systemu do dokładnego określania ilości wolnego miejsca które są dostępne na bieżącym urządzeniu – na przykład do jaka ilość danych można bezpiecznie przechowywać pamięci podręcznej. Możesz przesłać do systemu zapytanie dotyczące tego rysunku, wywołując getMemoryClass() Ta metoda zwraca liczbę całkowitą, która wskazuje liczbę megabajtów dostępnych dla stosu aplikacji.

Przełączanie aplikacji

Gdy użytkownicy przełączają się między aplikacjami, Android zapewnia aplikacje, które nie znajdują się na pierwszym planie, czyli nie są widoczne dla użytkownika ani nie mają uruchomionej usługi na pierwszym planie, jak odtwarzanie muzyki, w pamięci podręcznej. Na przykład gdy użytkownik uruchamia aplikację po raz pierwszy, zostaje utworzony proces, ale gdy użytkownik ją zamknie, proces ten nie zostanie zamknięty. System przechowuje proces w pamięci podręcznej. Jeśli użytkownik wraca później do aplikacji, system ponownie wykorzystuje proces, dzięki czemu co przyspieszy przechodzenie aplikacji.

Jeśli aplikacja ma proces w pamięci podręcznej i zachowuje zasoby których obecnie nie potrzebuje, nawet wtedy, gdy użytkownik z niej nie korzysta, wpływa na ogólną skuteczność. Gdy w systemie zaczyna brakować zasobów, takich jak pamięć, zabija procesy w pamięci podręcznej. System również obejmuje procesy o największej ilości pamięci i mogą je zamknąć, aby zwolnić pamięć RAM.

Uwaga: im mniej pamięci zużywa aplikacja w pamięci podręcznej, tym większe ma szanse na to, że nie zostanie zamknięta i będzie mogła szybko wznowić działanie. Jednak w zależności od natychmiastowych wymagań systemowych możliwe jest, że procesów, które mogą zostać zakończone w dowolnym momencie bez względu na wykorzystanie zasobów.

Więcej informacji o pamięci podręcznej procesów podczas które nie działają na pierwszym planie, i jak Android decyduje, które można zabić, zobacz Procesy i wątki Google.

Test wytrzymałości pamięci

Choć problemy z pamięcią rzadziej występują w nowoczesnych urządzeniach, mogą nadal powodować problemy dla użytkowników urządzeń z małą ilością pamięci RAM, np. z Androidem w wersji Go. Ważne jest, aby spróbować odtworzyć to środowisko obciążające pamięć, aby móc pisać testy instrumentacji w celu weryfikacji aplikacji działania aplikacji i zwiększanie wygody użytkowników korzystających z urządzeń z małą ilością pamięci.

Stresujący test aplikacji

    adb push stressapptest /data/local/tmp/
    adb shell chmod 777 /data/local/tmp/stressapptest
    adb shell /data/local/tmp/stressapptest -s 20 -M 990

  

Obserwacje dotyczące stresu Apptest

• SIGABRT: to krytyczna awaria natywnego procesu ze względu na żądania alokacji jest większy niż wolna pamięć, gdy system jest już zajęty.
• SIGQUIT: Powoduje wykonanie zrzutu pamięci podstawowej i zakończenie procesu, jeśli zostanie wykryty przez test instrumentacji.
• TRIM_MEMORY_EVENTS: Te wywołania zwrotne są dostępne w Androidzie 4.1 (poziom interfejsu API 16) i nowszych i dostarczają szczegółowe i alerty dotyczące pamięci w procesie.