Wysyłanie zapytań do profili ProfilingManager

Wysyłanie zapytań do ProfilingManager profili jest podobne do wysyłania zapytań do zwykłych profili Perfetto. Dlatego zapoznaj się z artykułem Pierwsze kroki z PerfettoSQL, aby dowiedzieć się, jak wysyłać zapytania do profili.

Istotną różnicą między zwykłymi śladami Perfetto a śladami ProfilingManager jest to, że te ostatnie przechodzą przez redaktor śladów.ProfilingManager Ten redaktor usuwa informacje o innych procesach niezwiązanych z Twoją aplikacją ze względu na ochronę prywatności.

Niektóre zapytania ze standardowej biblioteki Perfetto nie działają w przypadku zanonimizowanych śladów. Dzieje się tak, ponieważ ProfilingManager zbiera dane profilowania tylko w przypadku Twojej aplikacji, a nie innych procesów. W rezultacie zapytania, których możesz używać w przypadku ProfilingManager, stanowią mniejszy zbiór niż zapytania dotyczące pełnych profili systemowych rejestrowanych za pomocą lokalnego narzędzia Perfetto.

Mimo że przestrzeń zapytań jest mniejsza, nadal możesz używać wielu zapytań i tabel PerfettoSQL z standardowej biblioteki Perfetto w niezmienionej postaci, więc zachęcamy do ich wypróbowania.

Zalecamy też zapoznanie się z artykułem Analizowanie śladów Androida, aby znaleźć gotowe zapytania, które bez modyfikacji dostarczają przydatnych danych o wydajności.

Przykładowe zapytania ProfilingManager

Aby ułatwić Ci tworzenie zapytań, w tej sekcji znajdziesz listę zapytań, które działają w przypadku ProfilingManager. Możesz używać tych zapytań bezpośrednio lub jako przykładów do tworzenia innych zapytań.

Znajdowanie najbardziej zduplikowanych wycinków

To zapytanie wyszukuje powtarzające się wycinki w śladzie i sortuje je według częstotliwości występowania, wyświetlając najpierw te, które się najczęściej powtarzają.

Wyszukiwanie zduplikowanej pracy to powszechny sposób na znalezienie w śladzie niepotrzebnych działań.

Uwaga: to zapytanie definiuje funkcję Perfetto, która umożliwia używanie dowolnego wzorca GLOB do znajdowania duplikatów, co ułatwia ponowne użycie. Więcej informacji o funkcjach znajdziesz w dokumentacji składni SQL Perfetto.

-- You only need to call this once in the session to create the function
DROP TABLE IF EXISTS find_duplicates;
CREATE PERFETTO FUNCTION find_duplicates(pattern STRING) RETURNS
TABLE(name STRING, count_slice LONG) AS SELECT name, COUNT(dur) as count_slice FROM slice WHERE name GLOB $pattern GROUP BY name HAVING COUNT(name) >= 2 ORDER BY count_slice DESC;

-- Subsequent calls can just use the function to find dupes
SELECT * FROM find_duplicates('*Text*')

Zapytania dotyczące zacięć

Wyszukiwanie spowolnionych klatek

To zapytanie wyszukuje klatki, w przypadku których aplikacja zbyt długo generuje klatkę, przy założeniu oczekiwanej liczby klatek na sekundę wynoszącej 60 Hz (16,6 ms). Wartość dur wynosi 16 660 000, ponieważ czas trwania wycinków w tabelach Perfetto jest przechowywany w nanosekundach.

INCLUDE PERFETTO module android.frames.timeline;
SELECT * FROM android_frames WHERE dur > 16660000;

Znajdowanie klatek powodujących zacinanie

INCLUDE PERFETTO module android.frames.timeline;
SELECT * FROM actual_frame_timeline_slice WHERE jank_type = 'App Deadline Missed';

To zapytanie przydaje się do znajdowania w śladzie miejsc, w których występuje zacinanie, ponieważ aplikacja zbyt długo generuje klatkę. Oznacza to, że wątek interfejsu nie zdołał wygenerować ramki. W ekstremalnych okolicznościach może to poprzedzać błąd ANR.

Uwaga: wykrywanie zacięć w tym zapytaniu zależy od częstotliwości odświeżania urządzenia. Wyższa częstotliwość odświeżania oznacza mniejszą tolerancję na zacinanie się.

Znajdowanie najbardziej zduplikowanych obiektów

Możesz też wysyłać zapytania dotyczące profili związanych z pamięcią, np. zrzutów sterty, aby przeprowadzać bardziej złożone analizy pamięci.

INCLUDE PERFETTO MODULE android.memory.heap_graph.heap_graph_class_aggregation;

SELECT * FROM android_heap_graph_class_aggregation WHERE obj_count >= 2
ORDER BY obj_count DESC LIMIT 100

To zapytanie zwraca 100 najczęściej duplikowanych obiektów. Może to pomóc w znalezieniu obiektów, które są tworzone wiele razy, co może ujawnić możliwości ich buforowania lub zidentyfikować niezamierzone duplikaty.

Opóźnienie uruchomienia „na zimno”

Możesz też wyszukiwać startupy. W tej sekcji znajdziesz bardziej złożone zapytanie, które pozwala oszacować czas uruchamiania „na zimno” w logu czasu.

-- This function finds slices that match the given GLOB $pattern
CREATE OR REPLACE FUNCTION find_slices(pattern STRING) RETURNS
TABLE (name STRING, ts LONG, dur LONG) AS
SELECT name,ts,dur FROM slice WHERE name GLOB $pattern;

-- This function generates a slice that starts at $startSlicePattern and finishes at the slice matched by $endSlicePattern. If $inclusive is true, then the end slice dur will be added, otherwise, the end slice start time will be used.
CREATE OR REPLACE PERFETTO FUNCTION generate_start_to_end_slices(startSlicePattern STRING, endSlicePattern STRING, inclusive BOOL) RETURNS
TABLE(name STRING, ts LONG, dur LONG) AS
SELECT name, ts, MIN(startToEndDur) as dur
FROM
  (SELECT S.name as name, S.ts as ts, E.ts + IIF($inclusive, E.dur, 0) - S.ts as startToEndDur
  FROM find_slices($startSlicePattern) as S CROSS JOIN find_slices($endSlicePattern) as E
  WHERE startToEndDur > 0)
GROUP BY name, ts;

-- Using these functions we can estimate cold startup time by generating a slice between bindApplication and first frame.
SELECT * from generate_start_to_end_slices('bindApplication','*Choreographer#doFrame [0-9]*', true)

To zapytanie generuje wycinek, który reprezentuje czas między 2 wycinkami określającymi czas uruchamiania: bindApplication (zwykle występuje na początku zimnego uruchamiania aplikacji) i pierwszym wycinkiem Choreographer#doFrame (pierwsza wygenerowana klatka). Ten wskaźnik skutecznie szacuje czas uruchomienia „na zimno” TTFF (czas do pierwszej klatki).