Ocena skuteczności

Używaj Simpleperf, oceniać wydajność urządzenia. Simpleperf to natywne narzędzie do profilowania dla aplikacji i procesów natywnych na Androidzie. Używaj Program profilujący procesora , aby sprawdzać wykorzystanie procesora przez aplikacje i aktywność wątków w czasie rzeczywistym.

Są 2 wskaźniki skuteczności widoczne dla użytkowników:

  • Przewidywalna, zauważalna skuteczność. Czy użytkownik pomijania klatek lub stałe renderowanie z szybkością 60 kl./s. Czy jest odtwarzany dźwięk? bez artefaktów i wyskakujących elementów? Ile czasu musi upłynąć, zanim użytkownik dotknie ekranu i jaki efekt pojawiają się na ekranie?
  • Ilość czasu wymagana w przypadku dłuższych operacji (np. podczas otwierania aplikacji).

Pierwsza jest bardziej zauważalna niż druga. Użytkownicy zwykle zauważają zacinanie ale nie będą w stanie określić 500 ms i 600 ms czasu uruchamiania aplikacji, chyba że patrzą na 2 urządzenia obok siebie. Opóźnienie dotknięcia jest natychmiastowe jest zauważalna i w znacznym stopniu wpływa na postrzeganie urządzenia.

W rezultacie na szybkich urządzeniach potok UI jest najważniejszą rzeczą system poza zakresem niezbędnym do utrzymania sprawności potoku UI. Ten oznacza, że potok UI powinien zastępować wszelkie inne prace, które nie są niezbędne płynnego interfejsu. Aby zachować płynny interfejs, synchronizację w tle, dostarczanie powiadomień i podobne zadania muszą być opóźnione, jeśli można uruchomić interfejs użytkownika. Jest akceptowalne są wydajność dłuższych operacji (czas działania HDR+, uruchamianie aplikacji itp.), aby zachować płynny interfejs.

Pojemność a zakłócenia

Uwzględniając wydajność urządzenia, pojemność i zakłócenia To dwa ważne wskaźniki.

Pojemność

Pojemność to całkowita ilość jakiegoś zasobu, w którego znajduje się urządzenie jakiś czas. Mogą to być zasoby procesora, zasobów GPU, zasoby wejścia-wyjścia, zasobów sieciowych, przepustowości pamięci lub innych podobnych wskaźników. Podczas sprawdzania wydajności całego systemu, może pomóc wyodrębnianie jego poszczególnych jego elementów i zakładać jeden wskaźnik określający skuteczność (zwłaszcza przy dostrajaniu na nowym urządzeniu, bo zadania uruchamiane na nim są prawdopodobnie naprawione).

Wydajność systemu zależy od zasobów obliczeniowych online. Zmiana częstotliwości CPU/GPU jest głównym sposobem zmiany wydajności, ale są inne, na przykład zmiana liczby rdzeni procesora online. W związku z tym pojemność systemu odpowiada zużyciu energii; zmienny zawsze przekłada się na podobną zmianę zużycia energii.

Zdolność wymagana w danym czasie jest w ogromnym stopniu określana przez uruchomioną aplikację. W efekcie platforma może niewiele zrobić, aby dostosować możliwości wykonania danego zadania, a środki do tego są ograniczone do ulepszenia środowiska wykonawczego (platforma Android, ART, Bionic, kompilator/sterowniki GPU, jądro).

Zakłócenia

Wymagana pojemność zadania jest dobrze widoczna, ale zakłócenia są bardziej mgławiczej koncepcji. Dobre wprowadzenie do zakłóceń, które ograniczają szybkość systemów, zapoznaj się z artykułem PRZYPAD NISKUJĄCEJ SKUTECZNOŚCI SUPERKOMPUTERA: UZYSKANIE OPTYMALIZACJI SKUTECZNOŚCI 8192 TWÓRCÓW PRZETWARZAJĄCYCH ASCl Q. (Chcemy dowiedzieć się, dlaczego ASCI Superkomputer Q nie osiągnął oczekiwanej wydajności i jest świetnym optymalizacji dużych systemów).

Na tej stronie używamy terminu „zakłócenia” w opisie dokumentów ASCI Q. szumy. Zakłócenia to losowe zachowanie systemu, które zapobiega dostrzegalności przed uruchomieniem. Często jest to zadanie, które musi zostać uruchomione, ale może nie mieć rygorystycznego wymogom w zakresie czasu, które powodują, że jego uruchomienie w danym momencie odbywa się w dowolnym momencie. Ponieważ losowego, bardzo trudno jest zaprzeczać istnieniu zakłóceń w działaniu danego zadania. Niezwykle trudno jest też udowodnić, że znane źródło były przyczyną konkretnego problemu z wydajnością. Najczęściej używane do diagnozowania przyczyn zakłóceń (takich jak śledzenie czy logowanie) może ich własnych zakłóceń.

Źródła zakłóceń występujących w rzeczywistych implementacjach Androida uwzględnij:

  • Opóźnienie algorytmu szeregowania
  • Moduły obsługi przerywania
  • Kod sterownika uruchomiony zbyt długo z wyłączonym przerywaniem lub przerwami
  • Działające od lat
  • Rywalizacja o blokadę (aplikacja, platforma, sterownik jądra, blokada powiązania, mmap) zamka)
  • Rywalizacja z deskryptorami plików, w której wątek o niskim priorytecie blokuje blokadę na zapobiega uruchamianiu wątku o wysokim priorytecie
  • uruchamianie kodu o krytycznym znaczeniu dla interfejsu użytkownika w kolejkach roboczych, w których może wystąpić opóźnienie.
  • Przejścia związane z bezczynnością procesora
  • Logowanie
  • Opóźnienia wejścia-wyjścia
  • niepotrzebnych procesów (np. CONNECTIVITY_CHANGE transmisji),
  • Efekt thrashingu strony w pamięci podręcznej spowodowany niewystarczającą ilością wolnej pamięci

Wymagany czas w przypadku danego okresu zakłóceń zmniejszać się wraz ze zwiększaniem pojemności. Na przykład jeśli kierowca będzie ignorować tryb Nie przeszkadzać wyłączone w oczekiwaniu na odczyt z magistrali i2c, zajmie to czas niezależnie od tego, czy procesor ma 384 MHz czy 2 GHz. Rosnący nie jest wystarczającym rozwiązaniem, które pozwalałoby poprawić wydajność, gdy zakłócenia zaangażowane. W rezultacie szybsze procesory zwykle nie poprawiają wydajności. i wydajność w sytuacjach ograniczonych do zakłóceń.

W przeciwieństwie do wydajności działania zakłóceń powodowanych przez dostawcy systemu.

Wykorzystanie pamięci

Tradycyjnie przyczyną słabej wydajności jest wykorzystanie pamięci. Choć samo konsumpcja nie jest problemem z wydajnością, może powodować zakłócenia, niskie wymagania, ponowne uruchomienia usługi i thrashing strony w pamięci podręcznej. Malejąca wykorzystanie pamięci może uniknąć bezpośrednich przyczyn niskiej wydajności, ale mogą być też inne ukierunkowane ulepszenia, które pozwolą uniknąć tych przyczyn (np. przypięcie platformy, aby zapobiec jej przesunięciu na strony. wkrótce potem).

Analizowanie początkowej wydajności urządzenia

Zacząć od działającego, ale mało wydajnego systemu i próbować naprawić problem zachowanie systemu na podstawie poszczególnych przypadków chaosu, które są widoczne dla użytkowników. skuteczność kanału nie jest dobrą strategią. Ponieważ niska skuteczność są zwykle trudne do odtworzenia (tj. z powodu zakłóceń) lub problemu z aplikacją wiele zmiennych w całym systemie uniemożliwia skuteczność tej strategii. Jako bardzo łatwo jest błędnie zidentyfikować przyczyny i wprowadzić drobne ulepszenia, brakuje systemowych możliwości poprawy skuteczności w całym systemie.

Proponując nowy typ treści, zastosuj następujące ogólne podejście urządzenie:

  1. Uruchamianie systemu w interfejsie wraz ze wszystkimi uruchomionymi sterownikami i podstawowymi ustawieniami regulatora częstotliwości (jeśli zmienisz te ustawienia, powtórz wszystkie poniższe kroki).
  2. Sprawdź, czy jądro obsługuje punkt śledzenia sched_blocked_reason a także inne punkty śledzenia w potoku wyświetlania, które wskazują, kiedy klatka jest wyświetlana na ekranie.
  3. Rejestruj długie ślady całego potoku UI (od odbierania danych wejściowych przez IRQ) do ostatniego skanowania) przy uruchamianiu lekkiego i spójnego zbioru zadań (np. UiBench lub test piłek w ramach funkcji TouchLatency).
  4. Korygowanie opadów w ramce wykrytych w ramach lekkiej i stabilnej wersji zadań.
  5. Powtarzaj kroki 3–4, aż będzie można biegać przez ponad 20 sekund z zerową liczbą utraconych klatek za jednym razem.
  6. Przejdź do innych źródeł zakłóceń widocznych dla użytkowników.

Inne proste rzeczy, które możesz zrobić na wczesnym etapie wyświetlenia urządzenia, to m.in.:

  • Upewnij się, że jądro ma planowany_przyczyna_zablokowania_przyczyny śledzenie punktu. Ten punkt śledzenia jest włączony z kategorią logu czasu zaplanowanego w systrace i zapewnia funkcję odpowiedzialną za sen, gdy przechodzi w nieprzerwany tryb uśpienia. Ma kluczowe znaczenie dla analizy skuteczności. ponieważ nieprzerwany sen jest bardzo częstym wskaźnikiem zakłóceń.
  • Sprawdź, czy masz wystarczające śledzenie dla potoków GPU i displayowych. Wł. ostatnie punkty SOC Qualcomm, punkty śledzenia są włączone za pomocą:
    • adb shell "echo 1 > /d/tracing/events/kgsl/enable"
adb shell "echo 1 > /d/tracing/events/mdss/enable"

    Te zdarzenia pozostają włączone po uruchomieniu systrace, dzięki czemu możesz zobaczyć dodatkowe informacje w logu czasu dotyczące potoku wyświetlania (MDSS) w mdss_fb0. W Qualcomm SOC nie są wyświetlane żadne dodatkowe informacje o GPU w standardowym widoku systrace, ale wyniki są w samym logu czasu (aby dowiedzieć się więcej, zobacz Zrozumienie systrace).

    To, czego oczekujesz od tego rodzaju śledzenia wyświetleń, to pojedyncze zdarzenie, wskazuje, że klatka została wyświetlona na wyświetlaczu. Następnie możesz może wykryć, czy udało się uzyskać limit czasu renderowania klatki, jeśli zdarzenie Xn następuje mniej niż 16,7 ms po zdarzeniu Xn-1 (przy założeniu, że wyświetlacz ma częstotliwość 60 Hz); to wiesz, że nie zacięło się. Jeśli SOC nie dostarcza takich sygnałów, z dostawcą usług. Debugowanie zakłóceń jest niezwykle trudne bez to wyraźny sygnał, że użytkownik zakończył klatkę w całości.

Używanie syntetycznych testów porównawczych

Syntetyczne testy porównawcze są przydatne do zapewnienia podstawowych funkcji urządzenia . Jednak potraktowanie testów porównawczych jako pośredników dla postrzeganego urządzenia nie jest przydatna.

Na podstawie doświadczeń z SOC, różnice w testach porównawczych syntetycznych wydajność między SOC nie jest skorelowana z podobną różnicą zauważalna wydajność interfejsu (liczba utraconych klatek, 99. percentyl, klatka) czas itp.). Syntetyczne testy porównawcze to tylko testy porównawcze; zakłócenia zmierzoną skuteczność tych testów porównawczych tylko przez uwolnienie czasu od danych zbiorczych. testu porównawczego. W rezultacie wyniki syntetycznych testów porównawczych to głównie nieistotne jako wskaźnik wydajności widocznej dla użytkowników.

Załóżmy, że mamy 2 testy SOC korzystające z testu porównawczego X, który renderuje 1000 klatek interfejsu użytkownika. podaje łączny czas renderowania (niższy wynik oznacza lepszy).

  • SOC 1 renderuje każdą klatkę w analizie porównawczej X w czasie 10 ms i otrzymuje wynik 10 000.
  • SOC 2 renderuje 99% klatek w czasie 1 ms, ale 1% klatek trwających 100 ms i otrzymuje wyniki. 19 900, czyli znacznie lepszy wynik.

Jeśli wartość porównawcza wskazuje rzeczywistą wydajność interfejsu, SOC 2 będzie bezużyteczne. Zakładając, że częstotliwość odświeżania to 60 Hz, SOC 2 będzie wyświetlać niestabilną klatkę co 1,5 s. Tymczasem SOC 1 (wolniejszy według testu SOC X). byłoby całkowicie płynne.

Korzystaj z raportów o błędach

Raporty o błędach czasami przydają się do analizy skuteczności, ale dlatego, że są tak potężne, że rzadko są przydatne przy debugowaniu sporadycznych problemów. Mogą oni dać kilka wskazówek na temat tego, co system robił w danym momencie, zwłaszcza wtedy, gdy problem był związany z przejściem na inną aplikację (czyli po zalogowaniu się raport o błędzie). Raporty o błędach mogą też informować o ogólnych zakresach z systemem, który może zmniejszyć jego efektywność (np. ograniczanie przepustowości lub fragmentacja pamięci).

Używaj TouchLatency

Kilka przykładów niewłaściwego działania funkcji to TouchLatency, czyli funkcja preferowanego okresowego zadania używanego na urządzeniach Pixel i Pixel XL. Jest dostępny pod adresem frameworks/base/tests/TouchLatency i ma 2 tryby: opóźnienie dotknięcia i odbijająca się piłka (aby przełączyć tryb, kliknij przycisk w prawym górnym rogu w rogu ekranu).

Test odbijania piłki jest dokładnie taki, jak się wydaje: piłka odbija się od ziemi dookoła ekranu bez względu na dane wejściowe użytkownika. Zwykle jest też zdecydowanie najtrudniejszy test do wykonania, ale im bliżej działa bez utraty klatek, tym lepiej działa urządzenie. test odbijania piłki jest trudny, ponieważ jest banalny, lecz spójny zadanie, które działa z bardzo niskim zegarem (zakładamy, że urządzenie ma częstotliwość zarządca; jeśli urządzenie działa ze stałymi zegarami, zmniejsz wartość CPU/GPU prawie minimalny podczas pierwszego testu odbijającej się kulki). W miarę jak system się zmniejsza i zegary zbliżają się do bezczynności, wymagany CPU/GPU czas na klatkę. Możesz obserwować piłkę i zobaczyć, jak coś zacina się, a Ty wyświetlać utracone klatki w usłudze systrace.

Ponieważ zadania są tak spójne, możesz zidentyfikować większość źródeł znacznie łatwiej niż w przypadku większości zadań widocznych dla użytkownika, śledząc dokładnie działa w systemie w przypadku każdej brakującej klatki, a nie w interfejsie potoku. Niższe zegary pogłębiają skutki zakłóceń, sprawiając, jest bardziej prawdopodobne, że jakiekolwiek zakłócenia powodują usunięcie klatki. W rezultacie Jeśli wartość TouchLatency wynosi 60 kl./s, tym mniej prawdopodobne jest, że system będzie działał nieprawidłowo. zachowań, które powodują sporadyczne, trudne do odtworzenia zacinanie przy większych aplikacji.

Zakłócenia to często (ale nie zawsze) różnica w szybkości zegara, więc użyj testu, który działa przy bardzo niskich zegarach, aby diagnozować zakłócenia z następujących powodów:

  • Nie wszystkie zakłócenia są związane z niezmiennością szybkości zegara. wiele źródeł po prostu zużywa procesor obecnie się znajdujesz.
  • Gubernator powinien uzyskać średni czas renderowania klatki jak najbliżej terminu więc czas spędzany poza interfejsem może być wydłużony upuszczanie klatki.