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. Jest tylko jeden wyjątek: wszystkie pliki wpuszczane bez żadnych modyfikacji, takich jak kod, może zostać wyzerowana z pamięci RAM, jeśli system chce ją wykorzystać w innym miejscu.

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

Usuwanie odpadów

zarządzane środowisko pamięci, takie jak maszyna wirtualna ART lub Dalvik, śledzi każdą alokację pamięci. Po określeniu że część pamięci nie jest już używana przez program, i uwalnia je z powrotem do sterty, bez interwencji programisty. Mechanizm odzyskiwania nieużywanej pamięci w zarządzanym środowisku pamięci to funkcja odśmiecania. Czyszczenie pamięci ma 2 cele: znajdować w programie obiekty danych, do których nie będzie można uzyskać dostępu w przyszłości; oraz aby odzyskać zasoby używane 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. Gdy obiekt pozostaje aktywny wystarczająco długo, można go awansować do starszego pokolenia, a następnie na stałe.

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. Jeśli kryteria są spełnione, system przestanie wykonywać proces i rozpocznie czyszczenie pamięci. 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 rozwidla proces Zygote, wczytuje i uruchamia kod aplikacji w nowym procesie. To podejście dopuszcza większość stron RAM przydzielonych dla kod platformy i zasoby, które będą współdzielone przez wszystkie procesy aplikacji.
• Większość danych statycznych jest wplatana w proces. Ta metoda umożliwia udostępnianie danych między procesami i pozwala na podział na strony. 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 pojedynczy zakres 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.

Logiczny rozmiar sterty nie jest taki sam jak ilość pamięci fizycznej wykorzystywanej przez stertę. Podczas sprawdzania stosu aplikacji Android oblicza wartość nazywana proporcjonalnym rozmiarem zestawu (PSS), uwzględniające zarówno brudne, jak i czyste strony. które są udostępniane innym procesom, ale tylko w ramach proporcjonalna do liczby udostępnionych aplikacji. tę pamięć 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.

Ogranicz pamięć 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ągnęła sterty i próbuje przydzielić więcej może otrzymać 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. Gdy na przykład użytkownik po raz pierwszy uruchomi aplikację, tworzony jest dla niej proces, ale gdy użytkownik wyjdzie z aplikacji, proces nie zostanie zakończony. 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ększa szansa, że nie zginiemy i szybko wznowimy 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

Stresowny test aplikacji (stressapptest) to test interfejsu pamięci, który pomaga tworzyć realistyczne sytuacje wymagające dużego obciążenia w celu przetestowania różnych pamięci i ograniczeniami sprzętowymi Twojej aplikacji. Dzięki możliwości określenia ograniczeń czasowych i pamięci umożliwia pisanie narzędzi do weryfikowania rzeczywistych spotkań z dużą ilością pamięci. Na przykład za pomocą tego zestawu poleceń możesz przekazać bibliotekę statyczną do systemu plików danych: Spraw, aby plik był wykonywalny, i przeprowadź test wytrzymałościowy przez 20 sekund z użyciem 990 MB:

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

  

Zobacz stressapptest dokumentacji, w której znajdziesz więcej informacji na temat instalowania narzędzia, typowych argumentów i obsługi błędów i informacjami o nich.

Obserwacje dotyczące stresu Apptest

Za pomocą narzędzi takich jak stressapptest można żądać przydziałów pamięci większych niż swobodna i dostępności informacji. Żądanie tego typu może wiązać się z różnymi alertami, o których należy wiedzieć jako programistów. Oto 3 główne alerty, które mogą wystąpić z powodu małej dostępności pamięci:

• 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.