זיהוי ואופטימיזציה של תרחישים לדוגמה לשימוש ב-wake lock

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

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

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

AlarmManager

‫AlarmManager מקבלת חסימות מצב שינה ומקצה אותן לאפליקציה שקוראת לה. AlarmManager מקבלת את חסימת מצב השינה כשהמשימה המתוזמנת מופעלת, ומשחררת את החסימה כשהשידור של המשימה המתוזמנת, onReceive(), מסתיים.

שמות של חסימות מצב שינה

‫AlarmManager יוצרת חסימות מצב שינה עם השם *alarm*. (הכוכביות הן חלק מהשם של חסימת מצב שינה, הן לא מייצגות תווים כלליים לחיפוש).

המלצה

כדי לבצע אופטימיזציה של התנהגות האזעקה, מומלץ לפעול לפי השיטות המומלצות הבאות:

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

אודיו ומדיה

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

שמות של חסימות מצב שינה

ממשקי Media API מקבלים חסימות מצב שינה עם שמות שונים שמתחילים ב-Audio:

  • ‫AudioBitPerfect: משמש להפעלה של אודיו ב-USB ללא אובדן נתונים.
  • ‫AudioDirectOut: משמש להפעלת אודיו ללא אובדן נתונים בטלוויזיה או במכשיר מיוחד.
  • ‫AudioDup: משמש להפעלת התראות כשמחוברים באמצעות Bluetooth או USB.
  • ‫AudioIn: משמש להקלטת אודיו במצב מצלמת וידאו כשהמיקרופון פעיל.
  • ‫AudioMix: משמש להפעלת אודיו במכשיר נפוץ.
  • ‫AudioOffload: משמש להפעלה ארוכת טווח של מוזיקה בלבד, באפליקציות שתומכות במצב הזה.
  • ‫AudioSpatial: משמש להפעלה של אודיו רב-ערוצי של סרט או מוזיקה במכשירים שתומכים באודיו מרחבי.
  • ‫AudioUnknown: משתמשים בערך הזה כששאר המצבים לא רלוונטיים.
  • ‫MmapCapture: משמש להקלטת אודיו עם השהיה נמוכה.
  • ‫MmapPlayback: משמש להפעלה עם השהיה נמוכה, למשל במשחקים או באפליקציות אודיו מקצועיות.

המלצה

אנחנו ממליצים לפעול לפי השיטות המומלצות הבאות:

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

Bluetooth

ממשקי ה-API של Bluetooth בפלטפורמה מחזיקים בעיקר נעילות השכמה של ליבת המערכת בזמן שמתבצעות פעולות Bluetooth, שלא משויכות לאפליקציה.

המלצה

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

חיישני המכשיר

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

ב-Wear OS, אפשר להשתמש ב-Wear Health Services כדי לאסוף נתונים מהמכשיר, כמו גובה, דופק ומרחק.

אם הנתונים נאספים על ידי אפליקציות אחרות, אפשר להשתמש ב-Health Connect בשילוב עם WorkManager כדי לאחזר את הנתונים באופן תקופתי.

בתרחישים כמו מעקב אחרי שינוי במספר הצעדים או המרחק שעברתם, אתם יכולים להשתמש ב-Recording API בנייד בשילוב עם WorkManager כדי לאחזר את הנתונים באופן תקופתי. כדי לגשת לנתונים היסטוריים של צעדים (כמו מספר הצעדים היומי הכולל או מספר הצעדים ב-6 השעות האחרונות), Health Connect תומכת גם במעקב צעדים במכשיר במכשירים עם Android 14 ומעלה.

במצבים מסוימים, יכול להיות שיהיה צורך במעקב מותאם אישית אחרי חיישני המכשיר באמצעות SensorManager. ‫SensorManager לא מקבלת חסימות של מצב השינה בשם האפליקציה, אלא אם החיישן הוא חיישן התעוררות, שאפשר לזהות אותו באמצעות API‏ isWakeUpSensor.

המלצה

שימוש בחיישנים לצורך הקלטה בקצב דגימה גבוה עלול לגרום להתרוקנות משמעותית של הסוללה. הנה כמה המלצות לצמצום התרוקנות הסוללה והשימוש בחסימות מצב שינה:

  • אם אתם עוקבים אחרי מספר הצעדים או המרחק שעברתם, כדאי להשתמש ב-Recording API כדי לתעד את הנתונים בלי לצרוך הרבה חשמל. במכשירים עם Android מגרסה 14 ואילך, אפשר להשתמש ב-Health Connect כדי לגשת לנתונים היסטוריים של המכשיר ולספירת צעדים מצטברת.
  • כדי להשתמש במעקב פסיבי של חיישנים ב-Wear OS, צריך להשתמש ב-Wear Health Services כדי לייעל את השימוש בסוללה.
  • כשרושמים חיישן באמצעות SensorManager, צריך להגדיר maxReportLatencyUs של יותר מ-30 שניות כדי להשתמש בלוגיקה של אצווה חיישנים ולצמצם את מספר ההפרעות שהאפליקציה מקבלת. כשהמכשיר מופעל בהמשך על ידי טריגר אחר, כמו אינטראקציה של משתמש, אחזור מיקום או משימה מתוזמנת, המערכת תשלח מיד את נתוני החיישן שנשמרו במטמון.
  • אם האפליקציה דורשת גם נתוני מיקום וגם נתוני חיישנים, צריך לסנכרן את השליפה והעיבוד של האירועים. על ידי איגוד של קריאות חיישנים לחסימת מצב שינה קצרה שהמערכת מחזיקה לעדכוני מיקום, אתם נמנעים מהצורך בחסימת מצב שינה כדי לשמור על מעבד פעיל. כדי לטפל בהעלאה ובעיבוד של הנתונים המשולבים האלה, צריך להשתמש ב-worker או ב-חסימת מצב שינה לפרק זמן קצר.

הודעה בענן ב-Firebase‏ (FCM)

חסימת מצב שינה מופעלת בזמן העברת שידור של העברת הודעות בענן ב-Firebase ‏ (FCM) לאפליקציה. חסימת מצב שינה מושבתת אחרי שהשידור של ה-FCM onMessageReceived() מסתיים.

שמות של חסימות מצב שינה

כשמתקבלת במכשיר הודעה מ-FCM, מופעלת חסימת מצב שינה קצרה עם השם GOOGLE_C2DM. ב-Android מגרסה 16 ואילך, השם של חסימת מצב שינה הוא GCM_MESSAGE.

המלצה

כדי לבצע אופטימיזציה של התנהגות FCM, מומלץ לפעול לפי השיטות המומלצות הבאות:

  • אופטימיזציה של תדירות השליחה ב-FCM.
  • אל תשתמשו ב-FCM בעדיפות גבוהה אלא אם ההודעה באמת צריכה להישלח באופן מיידי.
  • השיטה onMessageReceived() תסתיים כמה שיותר מהר, או תתזמן עובד שימשיך את המשימה אם נדרש עיבוד נוסף. מידע נוסף זמין בהנחיות לגבי Firebase.

JobScheduler

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

שמות של חסימות מצב שינה

השמות של חסימות מצב שינה שמתקבלות על ידי JobScheduler תלויים בגרסה של מערכת Android שבה הן פועלות ובמטרה של העבודה.

הפריטים שמוקפים בסוגריים זוויתיים הם משתנים. לדוגמה, "<package_name>" הוא שם החבילה של האפליקציה, ולא הטקסט המילולי <package name>. עם זאת, *job* הוא רצף התווים *job* עם כוכביות, והכוכביות לא משמשות כתווים כלליים לחיפוש.

‫Android מגרסה 15 ומטה

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

*job*u/@<name_space>@/<package_name>/<classname>

דוגמאות נוספות לשימוש בדפוס הזה:

*job*/@<name_space>@/<package_name>/<classname>
‫Android 16 QPR2 ואילך

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

*job*u/@<name_space>@/#<trace_tag>#/<package_name>/<classname>

משימות בעדיפות גבוהה משתמשות בתבנית הזו:

*job*e/@<name_space>@/#<trace_tag>#/<package_name>/<classname>

משימות רגילות פועלות לפי הדפוס הזה:

*job*r/@<name_space>@/#<trace_tag>#/<package_name>/<classname>
דוגמה

נניח שיש משימה בעדיפות גבוהה עם מרחב השמות backup ותג המעקב started. שם החבילה הוא com.example.app, והמחלקה שיצרה את העבודה היא com.backup.BackupFileService.

במכשירים עם Android בגרסה 15 או גרסאות מוקדמות יותר, חסימת מצב השינה נקראת:

*job*/@backup@/com.example.app/com.backup.BackupFileService

במכשירים שפועלת בהם מערכת Android 16 QPR2 ואילך, חסימת מצב השינה תיקרא:

*job*e/@backup@/#started#/com.example.app/com.backup.BackupFileService

המלצה

  • אין לרכוש חסימת מצב שינה ידנית עבור תרחישי שימוש בהורדה/ העלאה שיזם המשתמש. במקום זאת, אפשר להשתמש ב-API של העברת נתונים שהפעילו משתמשים (UIDT). זהו הנתיב המיועד למשימות ארוכות של העברת נתונים שהמשתמש יזם.
  • אם אתם מזהים חסימות מצב שינה שנוצרו על ידי JobScheduler עם שימוש גבוה בחסימות מצב שינה, יכול להיות שהגדרתם את העבודה בצורה לא נכונה כך שהיא לא תושלם בתרחישים מסוימים. כדאי לנתח את הסיבות להפסקת העבודה, במיוחד אם אתם רואים מקרים רבים של STOP_REASON_TIMEOUT.
  • ביצוע ביקורת על השימוש במשימות JobScheduler. בפרט, מומלץ לפעול לפי ההנחיות שלנו בנושא אופטימיזציה של השימוש בסוללה בממשקי API לתזמון משימות.

מיקום

‫LocationManager ו-FusedLocationProviderClient משתמשים ב-wake locks כדי לקבל את מיקום המכשיר ולספק אותו. החסימות של מצב השינה משויכות לאפליקציה שקראה לממשקי ה-API האלה.

שמות של חסימות מצב שינה

שירותי המיקום משתמשים בשמות הבאים:

  • CollectionLib-SigCollector
  • NetworkLocationLocator
  • NetworkLocationScanner
  • NlpCollectorWakeLock
  • NlpWakeLock
  • *location*

המלצה

  • כדאי לעיין בהנחיות שלנו בנושא אופטימיזציה של השימוש במיקומים. כדאי להטמיע פסק זמן, להשתמש באפשרות של שליחת בקשות למיקום בקבוצות או להשתמש בעדכונים פסיביים של המיקום.
  • לא מומלץ להשיג חסימת מצב שינה נפרדת ורציפה כדי לשמור במטמון נתוני מיקום, כי זה מיותר וצריך להסיר את זה. כשמבקשים עדכונים לגבי מיקום באמצעות ממשקי ה-API‏ FusedLocationProvider או LocationManager, המערכת מפעילה אוטומטית את המכשיר במהלך הקריאה החוזרת של אירוע המיקום. במקום זאת, כדאי לאחסן את אירועי המיקום בזיכרון או באחסון, ולעבד את אירועי המיקום מעת לעת באמצעות WorkManager.

העברת הודעות מרחוק

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

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

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

המלצה

  • אם אפשר לעבד את אירועי הרשת בצד השרת, צריך להשתמש ב-FCM כדי לקבל מידע על הלקוח. אם נדרש עיבוד נוסף של נתוני FCM, אפשר לתזמן תהליך מהיר.
  • אם צריך לעבד אירועים בצד הלקוח באמצעות חיבור socket, לא צריך חסימת מצב שינה כדי להאזין להפרעות באירועים. כשמנות נתונים מגיעות לרדיו Wi-Fi או לרדיו סלולרי, חומרת הרדיו מפעילה הפרעה בצורה של חסימת מצב שינה של ליבת המערכת. אחרי כן, תוכלו לתזמן worker או להשיג חסימת מצב שינה כדי לעבד את הנתונים.
  • לדוגמה, אם אתם משתמשים ב-ktor-network כדי להאזין לחבילות נתונים בשקע רשת, כדאי להפעיל את חסימת מצב שינה רק כשחבילות נמסרות ללקוח.

WorkManager

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

שמות של חסימות מצב שינה

השמות של חסימות מצב שינה שמתקבלות על ידי WorkManager תלויים בגרסה של מערכת Android שבה הן פועלות.

‫Android מגרסה 15 ומטה

משימות של WorkManager יוצרות חסימות מצב שינה עם שמות שפועלים לפי התבנית הבאה:

*job*/<package_name>/androidx.work.impl.background.systemjob.SystemJobService
‫Android 16 QPR2 ואילך

משימות מואצות יוצרות נעילות השכמה עם שמות שמתאימים לתבנית הבאה:

*job*e/#<trace_tag>#/<package_name>/androidx.work.impl.background.systemjob.SystemJobService

משימות רגילות פועלות לפי הדפוס הבא:

*job*r/#<trace_tag>#/<package_name>/androidx.work.impl.background.systemjob.SystemJobService

כברירת מחדל, שם העובד הוא <trace_tag>.

דוגמה

נניח שיש עובד מזורז בשם BackupFileWorker. שם החבילה הוא com.example.app.

במכשירים עם Android בגרסה 15 או גרסאות מוקדמות יותר, חסימת מצב השינה נקראת:

*job*/com.example.app/androidx.work.impl.background.systemjob.SystemJobService

במכשירים שמותקנת בהם גרסת Android 16 QPR2 ומעלה ומשתמשים ב-WorkManager 2.10.0+, ה-wake lock ייקרא:

*job*e/#BackupFileWorker#/com.example.app/androidx.work.impl.background.systemjob.SystemJobService

המלצה

  • כדי שהתגים של חסימת מצב שינה יהיו מפורטים יותר ב-Android 16 QPR2 ואילך, צריך לשדרג את הגרסה של WorkManager לגרסה היציבה האחרונה.
  • ביצוע ביקורת על השימוש ב-WorkManager workers. חשוב במיוחד לוודא שהאפליקציה פועלת בהתאם להנחיות שלנו בנושא אופטימיזציה של השימוש בסוללה בממשקי API לתזמון משימות. כדי להפוך את תגי חסימת מצב שינה למפורטים יותר ב-Android 16 QPR2 ואילך, משתמשים בשיטה setTraceTag ב-worker כדי להוסיף עוד מידע על תוצאות ניפוי הבאגים, כמו המחלקה שתזמנה את ה-worker.
  • אם אתם מזהים חסימות מצב שינה שנוצרו על ידי WorkManager עם שימוש גבוה בחסימות מצב שינה, יכול להיות שהגדרתם את ה-worker בצורה שגויה כך שהוא לא יושלם בתרחישים מסוימים. כדאי לנתח את הסיבות להפסקת העובד, במיוחד אם אתם רואים מקרים רבים של STOP_REASON_TIMEOUT.
  • בנוסף לרישום הסיבות להפסקת העבודה, כדאי לעיין במסמכי התיעוד שלנו בנושא ניפוי באגים בעובדים. כדאי גם לאסוף ולנתח עקבות מערכת כדי להבין מתי נרכשים ומשוחררים נעילות השכמה.

_UNKNOWN

אם כלי הניפוי באגים מזהים ששם של חסימת מצב שינה מכיל פרטים אישיים מזהים (PII), הם לא מציגים את השם האמיתי של חסימת מצב שינה. במקום זאת, הם מסמנים את חסימת מצב השינה בתווית _UNKNOWN. לדוגמה, כלים עשויים לעשות זאת אם שם ה-wake lock מכיל כתובת אימייל.

המלצה

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