Android 11 lub nowszy obsługuje generowanie profili obrazu rozruchowego, które zawierają informacje o kodzie różnych komponentów na poziomie systemu, takich jak serwer systemowy i ścieżka klasy rozruchowej. Środowisko wykonawcze Androida (ART) używa tych informacji do przeprowadzania optymalizacji w całym systemie, z których niektóre mają kluczowe znaczenie dla wydajności Androida i wpływają na wykonywanie całego kodu innego niż natywny (na poziomie systemu lub aplikacji). W niektórych przypadkach profile obrazu rozruchowego mogą wpływać na wydajność wykonywania i zużycie pamięci w zakresie dwucyfrowych wartości procentowych.
Pobieranie informacji o profilu rozruchu
Profile obrazów rozruchowych są tworzone na podstawie profili aplikacji uruchamianych podczas najważniejszych działań użytkownika. W określonej konfiguracji urządzenia ART rejestruje (w ramach profili JIT) metody i klasy ścieżki klas rozruchu używane przez aplikacje, a następnie zapisuje te informacje w profilu aplikacji (np. /data/misc/profiles/cur/0/com.android.chrome/primary.prof
), gdzie są one indeksowane przez plik DEX ścieżki klas rozruchu (patrz format profilu ART).
Przejrzyj profile aplikacji zarejestrowane podczas CUJ, aby określić, która część ścieżki klasy rozruchowej jest najczęściej używana i najważniejsza do optymalizacji (przykład znajdziesz w sekcji Format profilu ART). Uwzględnianie wszystkich metod lub klas negatywnie wpływa na wydajność, dlatego skup się na najczęściej używanych ścieżkach kodu. Jeśli na przykład metoda ze ścieżki klasy rozruchowej jest używana przez jedną aplikację, nie powinna być częścią profili rozruchowych. Każde urządzenie powinno skonfigurować wybór metody lub klasy na podstawie wybranego CUJ i ilości danych wygenerowanych podczas testowania.
Aby zebrać informacje o ścieżce klas rozruchowych ze wszystkich profili poszczególnych aplikacji na urządzeniu, uruchom polecenie adb shell cmd package snapshot-profile android
. Możesz używać informacji zbiorczych jako podstawy przetwarzania i wyboru metody lub klasy bez ręcznego agregowania poszczególnych profili (chociaż możesz to zrobić, jeśli chcesz).
Rysunek 1. Proces uzyskiwania profili obrazów rozruchowych
Dane profilu obrazu rozruchowego
Profile obrazu rozruchowego zawierają te pliki i dane:
Profil ścieżki klas rozruchowych (
frameworks/base/config/boot-image-profile.txt
). Określa, które metody ze ścieżki klas rozruchowych są optymalizowane i która klasa jest uwzględniana w obrazie rozruchowym.art
.Lista wstępnie załadowanych klas. Określa, które klasy są wstępnie wczytywane w Zygote.
Profil komponentów serwera systemowego (
frameworks/base/services/art-profile
). Określa, które metody z serwera systemowego są optymalizowane lub kompilowane, która klasa jest uwzględniana w obrazie rozruchowym.art
oraz jak są rozmieszczone odpowiednie pliki DEX.
Format profilu ART
Profil ART zawiera informacje z każdego wczytanego pliku DEX, w tym informacje o metodach, które warto zoptymalizować, oraz o klasach używanych podczas uruchamiania. Gdy profilowanie obrazu rozruchowego jest włączone, ART uwzględnia w profilu ścieżkę klasy rozruchowej i pliki JAR serwera systemowego oraz opatruje każdy plik DEX nazwą pakietu, który go używa.
Na przykład zrzuć profil surowego obrazu rozruchowego za pomocą tego polecenia:
adb shell profman --dump-only --profile-file=/data/misc/profman/android.prof
Dane wyjściowe będą podobne do tych:
=== Dex files ===
=== profile ===
ProfileInfo [012]
core-oj.jar:com.google.android.ext.services [index=0] [checksum=e4e3979a]
hot methods: 520[], 611[] …
startup methods: …
classes: …
...
core-oj.jar:com.android.systemui [index=94] [checksum=e4e3979a]
hot methods: 520[], 521[]…
startup methods: …
classes: …
W powyższym przykładzie:
Ze strategii
core-oj.jar
korzysta kampaniacom.google.android.ext.services
icom.android.systemui
. Każdy wpis zawiera listę 2 pakietów używanych wcore-oj.jar
.Oba procesy korzystają z metody z indeksem DEX 520, ale tylko proces
systemui
korzysta z metody z indeksem DEX 521. To samo uzasadnienie dotyczy pozostałych sekcji profilu (np. klas startupów).
Podczas przetwarzania danych filtruj metody/klasy na podstawie użycia, przyznając priorytet procesom na poziomie systemu (np. serwerowi systemowemu lub systemui
) lub metodom, które mogą nie być powszechnie używane, ale są nadal ważne (np. metody używane przez aplikację aparatu).
Format profilu wewnętrznie opatruje każdą metodę wieloma flagami (startup, post-startup, hotness, abi), co jest większą liczbą niż w formacie dump-only. Aby korzystać ze wszystkich sygnałów, zmodyfikuj dostępne skrypty.
Rekomendacje
Aby uzyskać najlepsze wyniki, postępuj zgodnie z tymi wskazówkami.
Wdróż konfigurację generowania profili obrazów rozruchowych na kilku urządzeniach testowych i zbierz wyniki przed wygenerowaniem końcowego profilu obrazu rozruchowego. Narzędzie
profman
obsługuje agregowanie i wybieranie wielu profili obrazu rozruchowego, ale działa tylko z tą samą wersją obrazu rozruchowego (tą samą ścieżką klasy rozruchowej).Nadaj priorytet metodom/klasom używanym przez procesy systemowe. Te metody lub klasy mogą używać kodu, który nie jest często używany przez inne aplikacje, ale jest kluczowy dla optymalizacji.
Kształt danych z jednego urządzenia bardzo różni się od kształtu danych z urządzeń testowych, które wykonują rzeczywiste CUJ. Jeśli nie masz dużej floty urządzeń testowych, użyj tego samego urządzenia do uruchomienia kilku CUJ, aby zwiększyć pewność, że optymalizacje profilu obrazu rozruchowego będą dobrze działać w środowisku produkcyjnym (ten scenariusz opisujemy poniżej).
Konfigurowanie urządzeń
Aby włączyć konfigurację profilu rozruchowego za pomocą właściwości systemu, użyj jednej z tych metod.
Opcja 1. Ręczne ustawianie właściwości (działa do ponownego uruchomienia):
adb root
adb shell stop
adb shell setprop dalvik.vm.profilebootclasspath true
adb shell setprop dalvik.vm.profilesystemserver true
adb shell start
Opcja 2. Użyj
local.prop
(trwały efekt do momentu usunięcia pliku). Aby to zrobić:Utwórz plik
local.prop
z tą zawartością:dalvik.vm.profilebootclasspath=true dalvik.vm.profilesystemserver=true
Uruchom te polecenia:
adb push local.prop /data/
adb shell chmod 0750 /data/local.prop
adb reboot
Opcja 3. Użyj konfiguracji urządzenia, aby ustawić te właściwości po stronie serwera:
adb shell device_config put runtime_native_boot profilebootclasspath true adb shell device_config put runtime_native_boot profilesystemserver true
Generowanie profili obrazów rozruchowych
Aby wygenerować podstawowy profil obrazu rozruchowego za pomocą testów na jednym urządzeniu, postępuj zgodnie z tymi instrukcjami.
Skonfiguruj urządzenie.
Skonfiguruj urządzenie zgodnie z opisem w sekcji Konfigurowanie urządzeń.
(Opcjonalnie) Wyczyść i zastąp inne profile nowym formatem profilu. Aby przyspieszyć zbieranie profili, zresetuj wszystkie profile na urządzeniu.
adb shell stop
adb shell find "/data/misc/profiles -name *.prof -exec truncate -s 0 {} \;"
adb shell start
Uruchom CUJ na urządzeniu.
Zapisz profil za pomocą tego polecenia:
adb shell cmd package snapshot-profile android
Wyodrębnij profil za pomocą tego polecenia:
adb pull /data/misc/profman/android.prof
Przejdź do plików JAR ścieżki klas rozruchu za pomocą tych poleceń:
m dist
ls $ANDROID_PRODUCT_OUT/boot.zip
Wygeneruj profil obrazu rozruchowego za pomocą tego polecenia
profman
.profman --generate-boot-image-profile --profile-file=android.prof --out-profile-path=... --out-preloaded-classes-path=...
Na podstawie danych dostosuj polecenie
profman
za pomocą dostępnych flag progowych wyboru.--method-threshold
--class-threshold
--clean-class-threshold
--preloaded-class-threshold
--upgrade-startup-to-hot
--special-package
Pełną listę znajdziesz na
profman
stronie pomocy lub w kodzie źródłowym.