Popraw wydajność swojej apki z Android Profilerem

Myślę, że każdy, kto ciężko pracował nad swoją aplikacją, zgodzi się ze stwierdzeniem, że słabo byłoby dostarczyć chłonący pamięć produkt, który zagotuje każdy telefon.

Istniało już trochę narzędzi do monitoringu i logowania przed Android Studio 3.0. 

Jednak przeglądanie przez programistów zalogowanych linijek i używanie starych narzędzi, nie było zbyt pomocne. Z pomocą na szczęście przyszedł Android Profiler, który pojawił się wraz z Android Studio 3.0.

Programiści mogą używać Profilera do monitorowania procesora, pamięci, zużycia baterii oraz śledzić żądania sieciowe aplikacji. Oczywiście, nadal można wypisywać logi poprzez Logcata.

Nigdy nie miałem czasu na zgłębienie Profilera, bo byłem zajęty nauką i eksperymentami z innymi nowinkami Androida. Wiedziałem, że coś takiego istnieje, ale zawsze odkładałem zapoznanie się z nim na później, pomimo tego, że jest to dosyć istotny aspekt rozwoju aplikacji Androida.  

Dzięki Profilerowi można wykryć kluczowe procesy i aktywności, które mogą być główną przyczyną problemów z wydajnością aplikacji.

Profiler

Potrzebujesz przynajmniej Android Studio 3.0 z urządzeniem (lub emulatorem) z SDK level 26.

Gdy odpalisz swoją apkę, kliknij w oknie Profilera na dole, które jest przy Logcat’cie. Zobaczysz wykres jak powyżej, który jest aktualizowany w czasie rzeczywistym. Zostanie pokazana ktywność, która działa na pierwszym planie.

Gdy klikniesz któryś z wykresów, ukaże się jej szczegółowy opis. Gdy zaczniesz używać aplikacji, wchodzić z nią w interakcję, otwierać wiele aktywności, czy wykonywać żądania sieciowe zaobserwujesz, że wykresy się aktualizują, co całkiem fajnie się ogląda.

Możesz nawet sprawdzić, które funkcje wymagają większych zasobów niż inne.

Kliknij gdziekolwiek na wykresie, aby zobaczyć szczegóły. Przesuń na niego kursor, aby zobaczyć szczegóły konsumpcji zasobów aplikacji.

To już sporo rzeczy, a dopiero zaczynamy. Kliknij ponownie, aby zobaczyć jeszcze więcej szczegółów. Możesz tutaj zobaczyć stos wywołań, wywołane klasy i użyte wątki, co może być w pewnych momentach przytłaczające. Jest to jednak świetne narzędzie, kiedy już się z nim oswoisz. 

To jeszcze nie koniec. Możesz nawet rejestrować metryki aplikacji w czasie jej działania. Po rejestracji Android Studio zaprezentuje dogłębną analizę i statystyki zużycia pamięci co do bajta. Niesamowite!

Pamiętaj jednak, żeby używać aplikacji w czasie rejestracji sesji, bo właśnie tak zbierzesz dane potrzebne do wygenerowania insightów. Kiedy zakończysz nagrywanie, dół ekranu wypełni się danymi. 

Call chart

Wykres ten pokazuje wszystkich callerów i ich wywołania od ogółu do szczegółu. Wywołania metod będą nazwane tak, aby z łatwością je zidentyfikować

Flame chart

Pokazuje to, które metody zabrały cenny czas procesorowi naszego urządzenia. Sumuje się to tak samo, jak stos wywołań, odwracając wykres z poprzedniego okna. 

Od ogółu do szczegółu

Pokazuje wywołania metod sposobem „od ogółu do szczegółu”.

Od podstawy

Jakie wnioski można wyciągnąć z tych wykresów

1. Możesz zaobserwować sytuację, w której zużycie pamięci będzie ciągle rosnąć. W pewnym momencie rzucony zostanie wyjątek OutOfMemory, bo pamięć, jaką może zaalokować system, jest skończona. Żeby zobaczyć to na własne oczy, stwórz nieskończenie rosnący list view. Następnie zastąp list view na recycler view, aby sprawdzić, czy jakaś ilość pamięci została zaoszczędzona przy użyciu tego drugiego. 
2. Jeśli Twój wykres dosyć mocno się waha, oznacza to, że Twoja pamięć jest konsumowana, a garbage collection często ją uwalnia, co będzie miało wpływ na UX aplikacji.

Wykresy powinny być tak równe, jak to możliwe, w możliwie jak najniższych odczytach. Nie utrzymuj ich na wysokim poziomie np. 800Mbs. 

Mój własny przykład oraz czego się spodziewać używając Android Profilera 

Pracując nad jednym z moich projektów, spojrzałem w Profilera i zobaczyłem spory wzrost zużycia pamięci w aplikacji, pomimo że apka na początku nic nie robiła, co było zaskakujące. 

Chciałem zatem porównać moją już istniejącą aplikację z inną, która nic nie robi. Stworzyłem zatem domyślny projekt My Application Android Studio i odpaliłem go na moim Oppo Realme 2 z Android Oreo.

Tak wygląda Profiler dla nowego domyślnego projektu:

Patrząc na pik zużycia pamięci, zobaczymy szczegóły jej użycia.

Następnie spróbowałem odpalić ten sam program na emulatorze Nexus 6 z działającym API 28 i oto rezultat:

Szczegóły:

Urządzenie Androida, którego używasz do odpalenia swojej aplikacji, ma zatem wpływ na działanie Twojego produktu!

Konsumpcja native memory w emulatorze wynosiła 42 MB, podczas gdy w Oppo Realme 2 wynosiła 283.5 MB. Wniosek nasuwa się sam: nie powinienem był używać mojego telefonu, aby sprawdzić wydajność apki w Profilerze. 

Mam nadzieję, że nauczyłeś się czegoś przydatnego dla siebie.

Oryginał tekstu w języku angielskim przeczytasz tutaj.