Interroger les profils ProfilingManager

L'interrogation des profils ProfilingManager est semblable à celle des profils Perfetto standards. Par conséquent, consultez Premiers pas avec PerfettoSQL pour obtenir un guide sur la façon d'interroger les profils.

Une distinction importante entre les traces Perfetto standards et les traces ProfilingManager est que les traces ProfilingManager passent par un outil de masquage des traces. Ce rédacteur supprime les informations sur les autres processus sans rapport avec votre application pour des raisons de confidentialité.

Certaines requêtes de la bibliothèque standard Perfetto ne sont pas utilisables sur les traces expurgées. En effet, ProfilingManager ne collecte que les données de profilage de votre application, et non celles d'autres processus. Par conséquent, les requêtes que vous pouvez utiliser avec ProfilingManager sont moins nombreuses que celles pour les profils système complets enregistrés à l'aide de Perfetto local.

Même si l'espace de requête est réduit, vous pouvez toujours utiliser de nombreuses requêtes et tables PerfettoSQL de la bibliothèque standard Perfetto telles quelles. Nous vous encourageons donc à les essayer.

Nous vous recommandons également de consulter Analyser les traces Android pour trouver des requêtes prêtes à l'emploi qui fournissent des données de performances utiles sans modification.

Exemples de requêtes ProfilingManager

Pour simplifier le processus de requête, cette section fournit une liste de requêtes qui fonctionnent avec ProfilingManager. Vous pouvez utiliser ces requêtes directement ou comme exemples pour créer d'autres requêtes.

Identifier les tranches les plus dupliquées

Cette requête recherche les tranches répétées dans une trace et les trie par fréquence d'apparition, en affichant d'abord celles qui sont le plus souvent dupliquées.

La recherche de tâches en double est un moyen courant d'identifier les tâches inutiles dans une trace.

Remarque : Cette requête définit une fonction Perfetto qui vous permet d'utiliser n'importe quel modèle GLOB pour trouver les doublons, ce qui facilite la réutilisation. Pour en savoir plus sur les fonctions, consultez la documentation sur la syntaxe SQL de 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*')

Requêtes sur les à-coups

Identifier les frames lents

Cette requête recherche les frames pour lesquels votre application met trop de temps à générer un frame, en supposant une fréquence d'images attendue de 60 Hz (16,6 ms). La valeur dur est définie sur 16 660 000, car les durées des tranches dans les tables Perfetto sont stockées en nanosecondes.

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

Identifier les frames à l'origine des à-coups

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

Cette requête est utile pour trouver les emplacements où des à-coups se produisent dans la trace, car l'application met trop de temps à générer un frame. Cela signifie que le thread d'UI n'a pas réussi à générer un frame. Dans des cas extrêmes, cela peut précéder une ANR.

Remarque : La détection des saccades dans cette requête dépend de la fréquence d'actualisation de l'appareil. Plus la fréquence d'actualisation est élevée, moins la tolérance au jank est importante.

Trouver les objets les plus dupliqués

Vous pouvez également interroger des profils liés à la mémoire, tels que les vidages du tas, pour effectuer des analyses de mémoire plus complexes.

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

Cette requête renvoie les 100 objets en double les plus fréquents. Cela peut vous aider à trouver les objets instanciés plusieurs fois, ce qui peut révéler des opportunités de mise en cache ou identifier des doublons involontaires.

Latence de démarrage à froid

Vous pouvez également rechercher des start-ups. Cette section fournit une requête plus élaborée pour estimer le temps de démarrage à froid dans une trace.

-- 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)

Cette requête génère un segment qui représente le temps écoulé entre deux segments définissant le temps de démarrage : bindApplication (généralement situé au début du lancement à froid d'une application) et le premier segment Choreographer#doFrame (le premier frame généré). Cette métrique estime efficacement le TTFF (time to first frame, temps avant le premier frame) au démarrage à froid.