פקודות לניפוי שגיאות בפרופיילינג מקומי

כשבודקים את השילוב של ProfilingManager באופן מקומי, יכול להיות שהבקשות יוגבלו על ידי הגבלת קצב של יצירת בקשות או שהמעקבים ברקע לא יהיו פעילים בזמן בדיקת הטריגרים. אתם יכולים להשתמש בפקודות adb שבדף הזה כדי להשבית את ויסות הנתונים, לשלוף פרופילים, לשמור מעקבים לא מצונזרים, להפעיל תיעודים ולבדוק את מצב השירות במכשיר בדיקה.

השבתת מגביל הקצב

כדי להשבית את מגבילי הקצב של תהליך האפליקציה והמערכת לבקשות requestProfiling במהלך בדיקה מקומית, מריצים את הפקודה הבאה של device_config:

adb shell device_config put profiling_testing rate_limiter.disabled true

כשמסיימים את הבדיקה, מאפסים את הדגל:

adb shell device_config delete profiling_testing rate_limiter.disabled

הערה: rate_limiter.disabled רלוונטי רק לשיחות requestProfiling שמופעלות על ידי אפליקציה. כשבודקים טריגרים באופן מקומי, צריך להגדיר את system_triggered_profiling.testing_package_name כדי לאלץ מעקב רציף ברקע ולעקוף את מגבלת הקצב ברמת המערכת, כמו שמוסבר בקטע אילוץ הפעלה של מעקבים ברקע לבדיקת טריגרים.

שליפת פרופילים באמצעות ADB

כדי לבדוק פרופיל מצונזר באופן מקומי במכשיר עם גישת root, מריצים את adb pull עם הנתיב שמוחזר על ידי getResultFilePath:

# Pull a profile
adb pull /data/user/0/<com.example.myapp>/files/profiling/<profile-file-name>

הערה: אם אין לכם גישת root, אתם יכולים להגדיר את ProfilingManager כך שישמור פרופילים ב-/data/misc/perfetto-traces/profiling/, שאפשר לגשת אליו באמצעות adb pull בכל סוגי ה-build ב-Android 16 (רמת API 36) ומעלה. שמירת תוצאות זמניות וללא צנזור

שמירת תוצאות זמניות וללא צנזור

כשבודקים את יצירת הפרופילים באופן מקומי, אפשר לשמור את התוצאות בספרייה הזמנית ב-/data/misc/perfetto-traces/profiling/. השוואה בין עקבות מערכת שלא צונזרו לבין עקבות מערכת שצונזרו עוזרת להבין אילו נתונים מושמטים במהלך הצנזור.

האופן שבו נשמרות תוצאות זמניות ולא מצונזרות תלוי בגרסת Android שפועלת במכשיר:

• ‫Android 16 (רמת API‏ 36) ומעלה: אתם יכולים לשמור גם את התוצאות הלא מצונזרות (אם רלוונטי) וגם את התוצאות המצונזרות בספרייה הזמנית, שהורחבה ב-Android 16 כך שתהיה נגישה באמצעות adb pull בכל סוגי ה-build ללא גישת root (בעוד שב-Android 15 נדרשת גישת root כדי לקרוא את /data/misc/perfetto-traces/profiling/). כדי למנוע מהמערכת למחוק תוצאות זמניות, מריצים את הפקודה הבאה:

  adb shell device_config put profiling_testing delete_temporary_results.disabled true
  

• ‫Android 15 (רמת API‏ 35): בספרייה הזמנית, אפשר לשמור רק את התוצאה הלא מצונזרת, שאפשר לגשת אליה דרך adb רק בגרסאות build עם גישת root. (האפליקציה עדיין מקבלת את הפרופיל המצונזר בספרייה /data/user/0/<app>/files/profiling/ שלה, וקוד האפליקציה יכול לקרוא או להעתיק אותו בכל גרסה, אבל כדי לשלוף ישירות מ-/data/user/0/... באמצעות adb pull נדרשת גישת בסיס, או adb shell run-as <app> בגרסה שניתן לבצע בה ניפוי באגים). כדי למנוע מהמערכת למחוק את המעקבים שלא צונזרו, מריצים את הפקודה הבאה:

  adb shell device_config put profiling_testing delete_unredacted_trace.disabled true
  

אחרי שיוצרים פרופיל, שולפים את הקובץ שנשמר מהספרייה הזמנית:

# Pull a retained redacted profile (Android 16 and higher)
adb pull /data/misc/perfetto-traces/profiling/<trace-name>.<profile-type-ext>

# Pull an unredacted system trace
adb pull /data/misc/perfetto-traces/profiling/<trace-name>.perfetto-trace-unredacted

בפקודות האלה, <trace-name> הוא שם הקובץ הבסיסי (ללא סיומת) מהנתיב שמוחזר על ידי ProfilingResult.getResultFilePath, והעותק של עקבות המערכת ללא צנזור מוסיף את -unredacted לסיומת .perfetto-trace. לפרטים על מבנה שם הקובץ ועל הערכים של <profile-type-ext>, קראו את המאמר מיקומי קבצים ופורמטים של שמות.

הערה: האפשרות לשמור תוצאות זמניות ולא מצונזרות מושבתת כברירת מחדל כדי לחסוך נפח האחסון במכשיר, והיא מיועדת רק לבדיקה מקומית. עקבות המערכת שלא צונזרו תופסות יותר נפח אחסון כי הן כוללות פעילות של תהליכים בכל המערכת. בסיום הבדיקה, מפעילים מחדש את המחיקה האוטומטית:

adb shell device_config delete profiling_testing delete_temporary_results.disabled
adb shell device_config delete profiling_testing delete_unredacted_trace.disabled

לחייב הפעלה של מעקבים ברקע לבדיקת טריגרים

מכיוון שמעקבי המערכת ברקע פועלים במרווחי זמן אקראיים בסביבת הייצור, יכול להיות שיהיה קשה לבדוק באופן מקומי את יצירת הפרופילים שמבוססת על טריגרים. כדי לאלץ את המערכת להריץ מעקב רציף ברקע ולעקוף את מגבלת הקצב ברמת המערכת של הטריגרים של האפליקציה, מגדירים את system_triggered_profiling.testing_package_name:

adb shell device_config put profiling_testing system_triggered_profiling.testing_package_name <com.example.myapp>

כל תקופת צינון לכל טריגר שהוגדרה באמצעות setRateLimitingPeriodHours עדיין חלה. מצב זה פועל ברציפות עד שמנקים אותו, לכן צריך להסיר את הדגל בסיום הבדיקה:

adb shell device_config delete profiling_testing system_triggered_profiling.testing_package_name

פקודות שימושיות לניפוי באגים

במכשירים עם Android 16 (רמת API‏ 36) ומעלה וגרסה עדכנית של המודול Profiling, אתם יכולים להשתמש בכלי cmd profiling_service דרך adb כדי להפעיל רישום מפורט ביומן, להפעיל איסוף פרופילים לפי דרישה ולבדוק טריגרים ישירות משורת הפקודה.

טיפ: יכול להיות שיש אפשרויות נוספות או שיתווספו אפשרויות נוספות עם הזמן. מריצים את הפקודה adb shell cmd profiling_service help כדי לראות את כל הפקודות, הדגלים ופרטי השימוש הזמינים לניפוי באגים.

הפעלת רישום מפורט של יומן ניפוי באגים

כדי להפעיל יומני ProfilingService מפורטים ב-logcat ולאבחן את הטיפול בבקשות ואת המסירה שלהן, מריצים את הפקודה הבאה:

adb shell cmd profiling_service enable-logs true

בקשה לאיסוף פרופילים מתי שנוח

כדי להתחיל תיעוד פרופיל מיידי של חבילה ספציפית משורת הפקודה, מריצים את הפקודה הבאה:

adb shell cmd profiling_service request-profiling <profiling_type> <com.example.myapp> [--user <user_id>] [--duration <duration_ms>] [--sources <sources>]

בפקודה הזו, <profiling_type> הוא הערך הקבוע של המספר השלם מ-ProfilingManager (1 לתמונת מצב של הזיכרון מ-Java,‏ 2 לתמונת מצב של ערימה, 3 לדגימת מחסנית או 4 לעקבות המערכת). תהליך אפליקציית היעד חייב לפעול בפרופילים של הזיכרון והמחסנית, הבקשה כפופה למגביל הקצב אלא אם הוא מושבת, וה-ProfilingResult שהושלם נשלח רק למאזינים גלובליים שרשומים ב-registerForAllProfilingResults.

רישום וסימולציה של טריגרים

כדי לרשום טריגר או להפעיל אירוע טריגר מדומה לחבילה, ולאמת את הטיפול בקריאה החוזרת (callback) של הטריגר, מריצים את הפקודות הבאות:

adb shell cmd profiling_service add-trigger <trigger_type> <com.example.myapp> [--user <user_id>]
adb shell cmd profiling_service trigger <trigger_type> <com.example.myapp> [--user <user_id>]

בפקודות האלה, <trigger_type> הוא ערך קבוע של מספר שלם מ-ProfilingTrigger (לדוגמה, 1 ל-TRIGGER_TYPE_APP_FULLY_DRAWN, 2 ל-TRIGGER_TYPE_ANR או 7 ל-TRIGGER_TYPE_OOM). הפעלת add-trigger רושמת את הטריגר עם תקופת צינון של 0 שעות, ומבטלת כל רישום קיים של סוג הטריגר הזה. כדי לדמות טריגרים ששומרים תמונת מצב של מעקב ברקע (כמו 1 או 2), צריך מעקב פעיל ברקע (ראו לחייב הפעלה של מעקבים ברקע לבדיקת טריגרים).

איסוף המצב הכללי של ProfilingManager

ב-Android 16 (רמת API‏ 36) ואילך עם גרסה עדכנית של מודול Profiling, אפשר להריץ את dumpsys מול profiling_service כדי לאבחן בעיות ולבדוק את המצב הנוכחי של ProfilingManager:

adb shell dumpsys profiling_service

הפלט של dumpsys profiling_service מיועד רק למטרות מידע וניפוי באגים, והפורמט שלו עשוי להשתנות. הוא מספק תמונת מצב של המצב הפנימי של השירות, כולל:

• סטטוס של הגבלת קצב פעילה ושל מגביל קצב.
• הגדרות מכשיר פעילות.
• טריגרים רשומים של אפליקציות ותקופות הצינון שלהם להגבלת קצב של יצירת בקשות.
• סשנים פעילים של יצירת פרופילים וסשנים שממתינים בתור.
• בקשות פרופיילינג, הפעלות של טריגרים ואירועים של שליחת תוצאות מהזמן האחרון.

טיפ: כדי לשמור היסטוריה ארוכה יותר של אירועים אחרונים בפלט של dumpsys במהלך סשנים ארוכים של ניפוי באגים, מריצים את הפקודה adb shell cmd profiling_service enable-long-dumpsys true.