Omówienie pomiaru skuteczności aplikacji

Ten dokument pomoże Ci zidentyfikować i rozwiązać kluczowe problemy z wydajnością aplikacji.

Najważniejsze problemy z wydajnością

Na słabą skuteczność aplikacji może wpływać wiele problemów, ale oto kilka typowych, na które warto zwrócić uwagę:

Opóźnienie uruchomienia

Opóźnienie uruchomienia to czas, który upływa od kliknięcia ikony aplikacji, powiadomienia lub innego punktu wejścia do momentu, gdy na ekranie pojawią się dane użytkownika.

W przypadku aplikacji staraj się osiągnąć te cele:

• Uruchomienie „na zimno” w mniej niż 500 ms. Uruchomienie „na zimno” następuje, gdy uruchamiana aplikacja nie jest obecna w pamięci systemu. Dzieje się tak, gdy aplikacja jest uruchamiana po raz pierwszy od ponownego uruchomienia urządzenia lub od momentu, w którym proces aplikacji został zatrzymany przez użytkownika lub system. Uruchomienie „na zimno” wymaga najwięcej pracy ze strony systemu, ponieważ musi on wczytać wszystko z pamięci i zainicjować aplikację. Staraj się, aby uruchomienie „na zimno” trwało nie dłużej niż 500 ms.
• Uruchamianie częściowo z pamięci w mniej niż 200 ms, a uruchamianie z pamięci w mniej niż 150 ms. Ciepły start ma miejsce, gdy proces aplikacji jest już uruchomiony w tle, ale system musi ponownie zainicjować interfejs lub przywrócić aktywność na pierwszy plan, np. gdy użytkownik zamknie aplikację i wkrótce ją ponownie otworzy. Uruchamianie z pamięci jest jeszcze szybsze, ponieważ aktywność aplikacji jest już zapisana w pamięci podręcznej i wystarczy ją przenieść na pierwszy plan bez konieczności ponownego tworzenia hierarchii widoków. Staraj się, aby czas trwania zimnych startów nie przekraczał 200 ms, a gorących – 150 ms.
• Czasy oczekiwania P95 i P99 są bardzo zbliżone do mediany czasu oczekiwania. P95 i P99 to 95 i 99 percentyl czasu uruchamiania, a mediana to 50 percentyl. Jeśli aplikacja uruchamia się długo, może to negatywnie wpłynąć na wrażenia użytkowników. Komunikacja międzyprocesowa (IPC) i niepotrzebne operacje wejścia/wyjścia na ścieżce krytycznej uruchamiania aplikacji mogą powodować spory o blokady i wprowadzać niespójności.

Zacinanie się przewijania

Zacięcie to termin opisujący wizualne zakłócenie, które występuje, gdy system nie jest w stanie utworzyć i dostarczyć klatek na czas, aby wyświetlić je na ekranie z wymaganą częstotliwością 60 Hz lub wyższą. Problem ten jest najbardziej widoczny podczas przewijania, gdy zamiast płynnej animacji pojawiają się zacięcia. Zacinanie się występuje, gdy ruch zatrzymuje się na 1 lub więcej klatek, ponieważ renderowanie treści przez aplikację trwa dłużej niż czas trwania klatki w systemie.

Dąż do częstotliwości odświeżania 90 Hz w aplikacjach. Standardowa częstotliwość odświeżania to 60 Hz, ale wiele nowszych urządzeń działa w trybie 90 Hz podczas interakcji użytkownika, np. podczas przewijania. Niektóre urządzenia obsługują jeszcze wyższe częstotliwości odświeżania, nawet do 120 Hz.

Aby sprawdzić, jaka częstotliwość odświeżania jest używana na urządzeniu w danym momencie, włącz nakładkę, korzystając z opcji Opcje programisty > Pokaż częstotliwość odświeżania w sekcji Debugowanie.

Niepłynne przejścia

Jest to widoczne podczas interakcji, takich jak przełączanie kart lub wczytywanie nowej aktywności. Tego typu przejścia muszą być płynnymi animacjami i nie mogą zawierać opóźnień ani migotania obrazu.

Niska efektywność zasilania

Praca zmniejsza poziom naładowania baterii, a w konsekwencji jej żywotność.

Alokacje pamięci, które powstają podczas tworzenia nowych obiektów w kodzie, powodują obciążenie systemu. Samo przydzielanie pamięci wymaga wysiłku ze strony środowiska wykonawczego Androida (ART), a późniejsze zwalnianie tych obiektów (odśmiecanie) również wymaga czasu i wysiłku.

Zarówno alokacja pamięci, jak i odśmiecanie pamięci stały się znacznie szybsze i wydajniejsze, zwłaszcza w przypadku obiektów tymczasowych. Chociaż kiedyś zalecaliśmy unikanie przydzielania obiektów, gdy tylko jest to możliwe, teraz rekomendujemy, aby robić to, co ma największy sens w przypadku Twojej aplikacji i architektury. Oszczędzanie na alokacjach kosztem kodu, którego nie da się utrzymać, nie jest najlepszym rozwiązaniem, biorąc pod uwagę możliwości ART.

Jednak alokacje wymagają wysiłku, więc pamiętaj, że mogą one przyczyniać się do problemów z wydajnością, jeśli w pętli wewnętrznej alokujesz wiele obiektów.

Identyfikowanie problemów

Aby rozwiązać problemy z wydajnością, zidentyfikuj i sprawdź te kluczowe ścieżki użytkownika:

• Typowe procesy uruchamiania, w tym z launchera i powiadomienia.
• Ekran, na którym użytkownik przewija dane.
• Przejścia między ekranami.
• Długotrwałe procesy, takie jak nawigacja czy odtwarzanie muzyki.

W przypadku każdego z tych procesów sprawdź, co się dzieje, za pomocą tych narzędzi do debugowania:

• Perfetto: umożliwia sprawdzenie, co dzieje się na całym urządzeniu, dzięki precyzyjnym danym o czasie.
• Memory Profiler: umożliwia sprawdzenie, jakie alokacje pamięci są wykonywane na stercie.
• Simpleperf: pokazuje wykres płomieniowy wywołań funkcji, które w określonym czasie wykorzystują najwięcej procesora. Jeśli w Systrace zauważysz coś, co zajmuje dużo czasu, ale nie wiesz dlaczego, Simpleperf może dostarczyć dodatkowych informacji.

Aby zrozumieć i rozwiązać te problemy z wydajnością, musisz ręcznie debugować poszczególne przebiegi testów. Nie możesz zastąpić poprzednich kroków analizą danych zbiorczych. Aby jednak dowiedzieć się, co widzą użytkownicy, i określić, kiedy mogą wystąpić regresje, ważne jest skonfigurowanie zbierania danych w testach automatycznych i w terenie:

• Automatyzacje dla startupów
  • Dane z terenu: czas uruchamiania Konsoli Play
  • Testy laboratoryjne: testowanie uruchamiania za pomocą Macrobenchmark
• Jank
  • Zgromadzone dane
    • Dane o klatkach w Konsoli Play: w Konsoli Play nie możesz zawęzić danych do konkretnej ścieżki użytkownika. Raportuje tylko ogólne zacięcia w całej aplikacji.
    • Pomiar niestandardowy za pomocą FrameMetricsAggregator: możesz użyć FrameMetricsAggregator, aby rejestrować dane dotyczące zacięć podczas określonego przepływu pracy.
  • Testy laboratoryjne
    • Przewijanie za pomocą Macrobenchmark
    • Makrobenchmark zbiera dane o czasie trwania klatek za pomocą dumpsys gfxinfopoleceń, które obejmują pojedynczą ścieżkę użytkownika. W ten sposób możesz poznać różnice w wartościach jank w ramach konkretnej ścieżki użytkownika. Wskaźniki RenderTime, które pokazują, jak długo trwa rysowanie klatek, są ważniejsze niż liczba niestabilnych klatek w przypadku identyfikowania regresji lub ulepszeń.

Problemy z weryfikacją linków aplikacji

Linki aplikacji to precyzyjne linki oparte na adresie URL witryny, które zostały zweryfikowane jako przynależne do Twojej witryny. Weryfikacja linków aplikacji może się nie powieść z tych powodów:

• Nieprawidłowe zakresy filtrów intencji: dodawaj tylko autoVerify do filtrów intencji w przypadku adresów URL, na które Twoja aplikacja może odpowiadać.
• Niezweryfikowane przełączanie protokołów: niezweryfikowane przekierowania po stronie serwera i przekierowania do subdomeny są uznawane za zagrożenie dla bezpieczeństwa i nie przechodzą weryfikacji. Powodują one, że wszystkie linki autoVerify przestają działać. Na przykład przekierowanie linków z HTTP na HTTPS, np. z example.com na www.example.com, bez weryfikacji linków HTTPS może spowodować niepowodzenie weryfikacji. Sprawdź linki do aplikacji, dodając filtry intencji.
• Linków, których nie można zweryfikować: dodawanie linków, których nie można zweryfikować, na potrzeby testowania może spowodować, że system nie zweryfikuje linków aplikacji.
• Niezawodne serwery: sprawdź, czy serwery mogą łączyć się z aplikacjami klienckimi.

Konfigurowanie aplikacji pod kątem analizy wydajności

Aby uzyskać dokładne, powtarzalne i przydatne w praktyce wyniki testów porównawczych aplikacji, musisz prawidłowo skonfigurować środowisko testowe. Testuj na systemie jak najbardziej zbliżonym do środowiska produkcyjnego, eliminując jednocześnie źródła zakłóceń. W sekcjach poniżej znajdziesz kilka kroków związanych z APK i systemem, które możesz wykonać, aby przygotować konfigurację testową. Niektóre z nich są specyficzne dla danego przypadku użycia.

Punkty śledzenia

Aplikacje mogą instrumentować swój kod za pomocą niestandardowych zdarzeń śledzenia.

Podczas rejestrowania śladów śledzenie powoduje niewielki narzut wynoszący około 5 μs na sekcję, więc nie umieszczaj go w każdej metodzie. Śledzenie większych fragmentów pracy, >0,1 ms, może dostarczyć istotnych informacji o wąskich gardłach.

Uwagi dotyczące pliku APK

Wersje debugowania mogą być przydatne podczas rozwiązywania problemów i symbolizowania próbek stosu, ale mają duży wpływ na wydajność. Urządzenia z Androidem 10 (poziom interfejsu API 29) i nowszym mogą używać elementu profileable android:shell="true" w pliku manifestu, aby włączyć profilowanie w wersjach produkcyjnych.

Użyj konfiguracji zmniejszania rozmiaru kodu w wersji produkcyjnej. W zależności od zasobów używanych przez aplikację może to mieć znaczący wpływ na wydajność. Niektóre konfiguracje ProGuard usuwają punkty śledzenia, więc rozważ usunięcie tych reguł z konfiguracji, na której przeprowadzane są testy.

Kompilacja

Skompiluj aplikację na urządzeniu do znanego stanu – zwykle speed dla uproszczenia lub speed-profile, aby dokładniej dopasować wydajność do wersji produkcyjnej (wymaga to jednak rozgrzania aplikacji i zrzucenia profili lub skompilowania profili bazowych aplikacji).

Zarówno speed, jak i speed-profile zmniejszają ilość kodu wykonywanego w trybie interpretowanym z pliku DEX, a co za tym idzie, ilość kompilacji JIT w tle, która może powodować znaczne zakłócenia. Tylko speed-profilezmniejsza wpływ wczytywania klas w czasie działania z pliku DEX.

To polecenie kompiluje aplikację w trybie speed:

adb shell cmd package compile -m speed -f com.example.packagename

Tryb kompilacji speed kompiluje metody aplikacji w całości. Tryb speed-profile kompiluje metody i klasy aplikacji zgodnie z profilem wykorzystywanych ścieżek kodu, który jest zbierany podczas korzystania z aplikacji. Konsekwentne i prawidłowe zbieranie profili może być trudne, więc jeśli zdecydujesz się ich używać, sprawdź, czy zbierają one to, czego oczekujesz. Profile znajdują się w tej lokalizacji:

/data/misc/profiles/ref/[package-name]/primary.prof

Wymagania systemowe

Aby uzyskać pomiary o niskim poziomie i wysokiej wierności, skalibruj urządzenia. Przeprowadzanie porównań A/B na tym samym urządzeniu i w tej samej wersji systemu operacyjnego. Skuteczność może się znacznie różnić nawet w przypadku tego samego typu urządzenia.

Na urządzeniach z dostępem do roota możesz użyć lockClocksskryptu do testów porównawczych. Te skrypty wykonują m.in. te czynności:

• Ustaw stałą częstotliwość procesorów.
• Wyłącz małe rdzenie i skonfiguruj procesor graficzny.
• Wyłącz ograniczanie termiczne.

Nie zalecamy używania skryptu lockClocks w przypadku testów skupionych na wrażeniach użytkowników, takich jak testowanie uruchamiania aplikacji, testowanie liczby sesji dziennie i testowanie zacinania się, ale może on być niezbędny do zmniejszenia szumu w testach mikroporównawczych.

W miarę możliwości używaj platformy testowej, np. Macrobenchmark, która może zmniejszyć szum w pomiarach i zapobiec niedokładności pomiarów.

Powolne uruchamianie aplikacji: niepotrzebna aktywność trampoliny

Aktywność trampoliny może niepotrzebnie wydłużać czas uruchamiania aplikacji, dlatego warto wiedzieć, czy Twoja aplikacja to robi. Jak widać na poniższym przykładzie śladu, jeden znak activityStart jest natychmiast poprzedzony przez kolejny znak activityStart bez rysowania klatek przez pierwszą aktywność.

Rysunek 1. Ślad pokazujący aktywność na trampolinie.

Może to nastąpić zarówno w przypadku punktu wejścia powiadomienia, jak i zwykłego punktu wejścia uruchamiania aplikacji. Często można to rozwiązać, refaktoryzując kod. Jeśli na przykład używasz tego działania do przeprowadzenia konfiguracji przed uruchomieniem innego działania, wyodrębnij ten kod do komponentu lub biblioteki, których można używać wielokrotnie.

Niepotrzebne przydziały powodujące częste odśmiecanie pamięci

W raporcie Systrace możesz zauważyć, że odzyskiwanie pamięci (GC) odbywa się częściej, niż oczekujesz.

W przykładzie poniżej odśmiecanie pamięci co 10 sekund podczas długo trwającej operacji wskazuje, że aplikacja może niepotrzebnie, ale konsekwentnie przydzielać pamięć w czasie:

Rysunek 2. Ślad pokazujący odstęp między zdarzeniami GC.

W narzędziu Memory Profiler możesz też zauważyć, że większość alokacji jest wykonywana przez określony stos wywołań. Nie musisz agresywnie eliminować wszystkich alokacji, ponieważ może to utrudnić utrzymanie kodu. Zamiast tego zacznij od obszarów o największej liczbie przydziałów.

Nierówne klatki

Potok graficzny jest dość skomplikowany i może być trudno określić, czy użytkownik ostatecznie zobaczy pominiętą klatkę. W niektórych przypadkach platforma może „uratować” klatkę, korzystając z buforowania. Większość tych niuansów możesz jednak zignorować, aby z perspektywy aplikacji zidentyfikować problematyczne klatki.

Gdy klatki są rysowane przy niewielkim nakładzie pracy ze strony aplikacji, punkty śledzeniaChoreographer.doFrame() występują co 16,7 ms na urządzeniu o częstotliwości odświeżania 60 klatek na sekundę:

Rysunek 3. Ślad pokazujący częste szybkie klatki.

Jeśli oddalisz widok i przesuniesz ślad, zobaczysz, że czasami ukończenie klatek zajmuje nieco więcej czasu, ale nie więcej niż przydzielone 16,7 ms. Te klatki są w porządku:

Rysunek 4. Ślad pokazujący częste szybkie klatki z okresowymi seriami pracy.

Gdy zauważysz zakłócenie tej regularności, oznacza to, że klatka jest niestabilna, jak pokazano na rysunkach 5 i 6:

Rysunek 5. Ślad pokazujący niestabilną klatkę.

Rysunek 6. Ślad pokazujący więcej niestabilnych klatek.

W niektórych przypadkach musisz powiększyć punkt śledzenia, aby uzyskać więcej informacji o tym, które komponenty interfejsu są aktualizowane przez Compose lub, jak na rysunku 6, co robi LazyColumn. Podczas diagnozowania tych wąskich gardeł interfejsu standardowe śledzenie systemu może nie pokazywać, które komponenty są główną przyczyną problemu. W takich przypadkach użyj śledzenia kompozycji Jetpack Compose, które wyświetla dokładne funkcje kompozycyjne bezpośrednio w śladzie, co ułatwia wskazanie nieoczekiwanych ponownych kompozycji. Na ilustracjach 5 i 6 przedstawiono wyniki śledzenia kompozycji.

Więcej informacji o optymalizacji wydajności Compose znajdziesz w artykule Jetpack Compose – wydajność. Więcej informacji o identyfikowaniu niestabilnych klatek i usuwaniu przyczyn ich powstawania znajdziesz w artykule Wolne renderowanie.

Typowe błędy związane z leniwym układem

Niepotrzebne unieważnianie całego stanu podtrzymującego leniwy układ może prowadzić do nadmiernej liczby ponownych kompozycji, długiego czasu renderowania klatek i zacinania się animacji. Aby zminimalizować liczbę elementów listy, które wymagają aktualizacji, używaj kluczy elementów i zmieniaj tylko te elementy stanu, które ulegają zmianie.

Więcej informacji o tym, jak uniknąć kosztownych ponownych alokacji pełnej listy, które powodują aktualizację treści zamiast ich całkowitego zastąpienia, znajdziesz w artykule Używanie kluczy układu leniwego.

Nieprawidłowa implementacja zagnieżdżonych list przewijanych może spowodować spadek wydajności. Unikaj zagnieżdżania układu z leniwym przewijaniem w innym kontenerze przewijania bez wyraźnych ograniczeń. Więcej informacji znajdziesz w artykule Unikaj zagnieżdżania komponentów, które można przewijać w tym samym kierunku.

Jeśli nie pobierzesz wstępnie wystarczającej ilości danych lub nie zrobisz tego w odpowiednim czasie, dotarcie do końca listy przewijanej może być dla użytkownika nieprzyjemne, ponieważ będzie musiał czekać na więcej danych z serwera. Nie jest to co prawda zacinanie się, ponieważ nie są przekraczane terminy renderowania klatek, ale możesz znacznie poprawić UX, modyfikując czas i ilość wstępnego pobierania, aby użytkownik nie musiał czekać na dane.

Debugowanie aplikacji

Poniżej znajdziesz metody debugowania skuteczności aplikacji.

Debugowanie uruchamiania aplikacji za pomocą narzędzia Systrace

Więcej informacji o procesie uruchamiania aplikacji znajdziesz w artykule Czas uruchamiania aplikacji. W tym filmie znajdziesz omówienie śledzenia systemu i korzystania z profilera Androida Studio.

Typy startupów możesz rozróżniać na tych etapach:

• Uruchomienie „na zimno”: rozpoczyna się od utworzenia nowego procesu bez zapisanego stanu.
• Uruchomienie częściowo z pamięci: odtwarza Activity, ponownie wykorzystując proces, lub odtwarza proces z zapisanym stanem.
• Uruchomienie z pamięci: ponownie uruchamia Activity i rozpoczyna od rozszerzania.

Zalecamy rejestrowanie śladów systemowych za pomocą aplikacji Śledzenie systemu na urządzeniu. W przypadku Androida 10 i nowszych wersji używaj Perfetto. W przypadku Androida 9 i starszych wersji użyj Systrace. Zalecamy też wyświetlanie plików śledzenia za pomocą internetowego narzędzia do wyświetlania śladów Perfetto. Więcej informacji znajdziesz w artykule Omówienie śledzenia systemu.

Oto kilka rzeczy, na które warto zwrócić uwagę:

• Monitorowanie rywalizacji: rywalizacja o zasoby chronione przez monitor może znacznie opóźnić uruchomienie aplikacji.

• Synchroniczne transakcje w binderze: poszukaj niepotrzebnych transakcji na ścieżce krytycznej aplikacji. Jeśli niezbędna transakcja jest kosztowna, rozważ współpracę z zespołem platformy, aby wprowadzić ulepszenia.

• Równoczesne odśmiecanie pamięci: jest to powszechne i ma stosunkowo niewielki wpływ na wydajność, ale jeśli zdarza się często, warto sprawdzić to za pomocą profilera pamięci w Android Studio.

• Operacje wejścia/wyjścia: sprawdź operacje wejścia/wyjścia wykonywane podczas uruchamiania i poszukaj długich przestojów.

• Znaczna aktywność w innych wątkach: może ona zakłócać działanie wątku UI, dlatego podczas uruchamiania aplikacji należy uważać na pracę w tle.

Aby uzyskać lepsze raportowanie danych o uruchamianiu aplikacji, zalecamy wywoływanie funkcji reportFullyDrawn po zakończeniu uruchamiania z perspektywy aplikacji. Więcej informacji o używaniu reportFullyDrawn znajdziesz w sekcji Czas do pełnego wyświetlenia. Zdefiniowane przez RFD czasy rozpoczęcia możesz wyodrębnić za pomocą procesora śladów Perfetto. Wyemitowane zostanie widoczne dla użytkownika zdarzenie śledzenia.

Korzystanie z funkcji śledzenia systemu na urządzeniu

Możesz użyć aplikacji na poziomie systemu o nazwie Śledzenie systemu, aby zarejestrować ślad systemu na urządzeniu. Ta aplikacja umożliwia rejestrowanie śladów z urządzenia bez konieczności podłączania go do adb.

Korzystanie z Memory Profiler w Android Studio

Za pomocą Memory Profilera w Android Studio możesz sprawdzić obciążenie pamięci, które może być spowodowane wyciekami pamięci lub nieprawidłowymi wzorcami użycia. Umożliwia podgląd na żywo przydzielania obiektów.

Problemy z pamięcią w aplikacji możesz rozwiązać, używając narzędzia Memory Profiler do śledzenia, dlaczego i jak często występuje odśmiecanie pamięci.

Aby profilować pamięć aplikacji, wykonaj te czynności:

1. wykrywać problemy z pamięcią;

   Nagrywaj sesję profilowania pamięci ścieżki użytkownika, na której chcesz się skupić. Zwróć uwagę na rosnącą liczbę obiektów, jak pokazano na rysunku 7, która ostatecznie prowadzi do odzyskiwania pamięci, jak pokazano na rysunku 8.

   Rysunek 7. Zwiększanie liczby obiektów.

   Rysunek 8. Czyszczenie pamięci.

   Po zidentyfikowaniu ścieżki użytkownika, która powoduje obciążenie pamięci, przeanalizuj przyczyny źródłowe tego obciążenia.

2. diagnozować obszary o wysokim obciążeniu pamięci;

   Wybierz zakres na osi czasu, aby wizualizować zarówno przydziały, jak i płytki rozmiar, jak pokazano na rysunku 9.

   Rysunek 9. Wartości dla Allocations i Shallow Size.

   Dane te można sortować na wiele sposobów. Oto kilka przykładów, jak poszczególne widoki mogą pomóc w analizowaniu problemów.

   • Uporządkuj według klasy: przydatne, gdy chcesz znaleźć klasy, które generują obiekty, które w innych przypadkach są buforowane lub ponownie wykorzystywane z puli pamięci.

     Jeśli na przykład aplikacja tworzy 2000 obiektów określonej klasy co sekundę, zwiększa to liczbę przydziałów o 2000 co sekundę. Możesz to zobaczyć, sortując według klasy. Jeśli chcesz ponownie użyć tych obiektów, aby uniknąć generowania śmieci, zaimplementuj pulę pamięci.

   • Uporządkuj według stosu wywołań: przydatne, gdy chcesz znaleźć ścieżkę dostępu, w której przydzielana jest pamięć, np. w pętli lub w określonej funkcji wykonującej dużo pracy związanej z przydzielaniem pamięci.

   • Shallow Size (Rozmiar płytki): śledzi tylko pamięć samego obiektu. Jest to przydatne w przypadku śledzenia prostych klas składających się głównie z wartości pierwotnych.

   • Rozmiar przechowywany: pokazuje całkowitą ilość pamięci zajmowaną przez sam obiekt oraz wszystkie odwołania, do których odwołuje się tylko ten obiekt. Jest to przydatne do śledzenia obciążenia pamięci spowodowanego złożonymi obiektami. Aby uzyskać tę wartość, wykonaj pełny zrzut pamięci, jak pokazano na rysunku 10. Zwolnione miejsce zostanie dodane jako kolumna, jak pokazano na ilustracji 11.

     Rysunek 10. Pełny zrzut pamięci.

     

3. Mierzenie wpływu optymalizacji.

   GC są bardziej widoczne i łatwiej jest zmierzyć ich wpływ na optymalizacje pamięci. Gdy optymalizacja zmniejsza obciążenie pamięci, widzisz mniej odzyskiwania pamięci.

   Aby zmierzyć wpływ optymalizacji, na osi czasu profilera zmierz czas między odzyskiwaniem pamięci. Pozytywny wpływ wydłuża czas między odzyskiwaniem pamięci.

   Ostateczne efekty ulepszeń pamięci są następujące:

   • Jeśli aplikacja nie będzie stale wywierać presji na pamięć, prawdopodobieństwo wyłączenia z powodu braku pamięci będzie mniejsze.
   • Mniejsza liczba odzyskiwania pamięci poprawia dane dotyczące zacinania się, zwłaszcza w przypadku wartości P99. Dzieje się tak, ponieważ odśmiecanie pamięci powoduje rywalizację o procesor, co może prowadzić do odroczenia zadań renderowania podczas odśmiecania pamięci.