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 klas rozruchowych. Android Runtime (ART) wykorzystuje te informacje do przeprowadzania optymalizacji całego systemu, z których niektóre mają kluczowe znaczenie dla wydajności Androida i wpływają na wykonanie całego kodu nienatywnego (na poziomie systemu lub aplikacji). W niektórych przypadkach profile obrazu rozruchowego mogą mieć dwucyfrowy wpływ na wydajność wykonywania i zużycie pamięci.
Uzyskaj informacje o profilu rozruchowym
Profile obrazu rozruchowego pochodzą z profili aplikacji uruchamianych podczas krytycznych podróży użytkowników (CUJ). W konkretnej konfiguracji urządzenia ART przechwytuje (jako część profili JIT) metody i klasy ścieżki rozruchowej używane przez aplikacje, a następnie zapisuje te informacje w profilu aplikacji (na przykład /data/misc/profiles/cur/0/com.android.chrome/primary.prof
), gdzie jest indeksowany przez plik ścieżki klasy rozruchowej Dalvik EXecutable (DEX) (patrz format profilu ART ).
Przejrzyj profile aplikacji zarejestrowane podczas CUJ, aby określić, która część ścieżki klas rozruchowych jest najczęściej używana i najważniejsza do optymalizacji (na przykład zobacz Format profilu ART ). Włączenie wszystkich metod lub klas negatywnie wpływa na wydajność, dlatego skup się na najczęściej używanych ścieżkach kodu. Na przykład, jeśli pojedyncza aplikacja używa metody ze ścieżki klas rozruchowych, nie powinna ona być częścią profili rozruchowych. Każde urządzenie powinno skonfigurować wybór metody/klasy w oparciu o wybór CUJ i ilość danych uzyskanych w wyniku testów.
Aby zagregować informacje o ścieżce klasy rozruchowej ze wszystkich indywidualnych profili aplikacji na urządzeniu, uruchom polecenie adb shell cmd package snapshot-profile android
. Zagregowane informacje można wykorzystać jako podstawę do przetwarzania i wyboru metody/klasy bez ręcznego agregowania poszczególnych profili (chociaż można to zrobić w razie potrzeby).
Rysunek 1. Proces uzyskiwania profili obrazu rozruchowego
Dane profilu obrazu rozruchowego
Profile obrazu rozruchowego obejmują następujące 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 zostaną zoptymalizowane, która klasa zostanie uwzględniona w obrazie startowym.art
i w jaki sposób rozmieszczone będą odpowiednie pliki DEX.Lista wstępnie załadowanych klas . Określa, które klasy są wstępnie załadowane w Zygote.
Profil komponentów serwera systemowego (
frameworks/base/services/art-profile
). Określa, które metody z serwera systemowego zostaną zoptymalizowane/kompilowane, która klasa zostanie uwzględniona w obrazie rozruchowym.art
i w jaki sposób rozmieszczone będą odpowiednie pliki DEX.
Format profilu ART
Profil ART przechwytuje informacje z każdego z załadowanych plików DEX, w tym informacje o metodach wartych optymalizacji i klasach używanych podczas uruchamiania. Gdy włączone jest profilowanie obrazu rozruchowego, ART uwzględnia także ścieżkę klasy rozruchowej i pliki JAR serwera systemowego w profilu i opatruje każdy plik DEX nazwą pakietu, który go używa.
Na przykład zrzuć surowy profil obrazu rozruchowego za pomocą następującego polecenia:
adb shell profman --dump-only --profile-file=/data/misc/profman/android.prof
Daje to wynik podobny do:
=== 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:
core-oj.jar
jest używany przezcom.google.android.ext.services
icom.android.systemui
. Każdy wpis zawiera listę dwóch pakietów używanych zcore-oj.jar
.Obydwa procesy używają metody z indeksem DEX 520, ale tylko proces
systemui
używa metody z indeksem DEX 521. To samo uzasadnienie dotyczy innych sekcji profilu (na przykład klas startowych).
Podczas przetwarzania danych filtruj metody/klasy w oparciu o użycie, nadając priorytet procesom na poziomie systemu (na przykład serwer systemowy lub systemui
) lub metodom, które mogą nie być powszechnie używane, ale nadal są ważne (na przykład metody używane przez aplikacja aparatu).
Format profilu wewnętrznie opisuje każdą metodę wieloma flagami (uruchamianie, po uruchomieniu, gorąco, abi), czyli więcej niż jest wyświetlane w formacie tylko zrzutu. Aby wykorzystać wszystkie sygnały zmodyfikuj dostępne skrypty.
Zalecenia
Aby uzyskać najlepsze rezultaty, zastosuj się do poniższych wskazówek.
Wdróż konfigurację generowania profili obrazu rozruchowego na kilku urządzeniach testowych i zagreguj wyniki przed wygenerowaniem ostatecznego profilu obrazu rozruchowego. Narzędzie
profman
obsługuje agregowanie i wybieranie wielu profili obrazu startowego, ale działa tylko z tą samą wersją obrazu startowego (ta sama ścieżka klas startowych).Nadaj priorytet wyborowi metodom/klasom używanym przez procesy systemowe. Te metody/klasy mogą używać kodu, który nie jest często używany przez inne aplikacje, ale jego optymalizacja nadal ma kluczowe znaczenie.
Kształt danych pochodzących z pojedynczego urządzenia wygląda zupełnie inaczej w porównaniu z urządzeniami testowymi, które wykonują CUJ w świecie rzeczywistym. 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 opisano poniżej).
Skonfiguruj urządzenia
Aby włączyć konfigurację profilu rozruchowego za pomocą właściwości systemu, użyj jednej z następujących metod.
Opcja 1: Ręcznie skonfiguruj rekwizyty (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 pliku
local.prop
(efekt trwały do momentu usunięcia pliku). Aby to zrobić:Utwórz plik
local.prop
z zawartością:dalvik.vm.profilebootclasspath=true dalvik.vm.profilesystemserver=true
Uruchom następujące polecenia:
adb push local.prop /data/
adb shell chmod 0750 /data/local.prop
adb reboot
Opcja 3: Użyj konfiguracji urządzenia, aby ustawić następujące właściwości po stronie serwera:
persist.device_config.runtime_native_boot.profilesystemserver persist.device_config.runtime_native_boot.profilebootclasspath`
Wygeneruj profile obrazu rozruchowego
Skorzystaj z poniższych instrukcji, aby wygenerować podstawowy profil obrazu rozruchowego za pomocą testów na jednym urządzeniu.
Skonfiguruj urządzenie.
Skonfiguruj urządzenie zgodnie z opisem w rozdziale Konfigurowanie urządzeń .
(Opcjonalnie) Oczyszczenie i zastąpienie pozostałych profili nowego formatu profilu zajmuje trochę czasu. 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.
Przechwyć profil za pomocą następującego polecenia:
adb shell cmd package snapshot-profile android
Wyodrębnij profil za pomocą następującego polecenia:
adb pull /data/misc/profman/android.prof
Przejdź do plików JAR ścieżki klas rozruchowych, używając następujących poleceń:
m dist
ls $ANDROID_PRODUCT_OUT/boot.zip
Wygeneruj profil obrazu rozruchowego za pomocą następującego polecenia
profman
.profman --generate-boot-image-profile --profile-file=android.prof --out-profile-path=... --out-preloaded-classes-path=...
Korzystając z danych, dostosuj polecenie
profman
, korzystając z dostępnych flag progów wyboru.-
--method-threshold
-
--class-threshold
-
--clean-class-threshold
-
--preloaded-class-threshold
-
--upgrade-startup-to-hot
-
--special-package
Aby zobaczyć pełną listę, odwołaj się do strony pomocy
profman
lub kodu źródłowego.-