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

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

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

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

AlarmManager

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

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

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

המלצה

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

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

אודיו ומדיה

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

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

ממשקי 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 או ב-wake lock לפרק זמן קצר.

הודעה בענן ב-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.1 ואילך

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

*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.1 ואילך, נעילת ההשכמה תיקרא:

*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, אפשר לתזמן worker מזורז.
  • אם צריך לעבד אירועים בצד הלקוח באמצעות חיבור socket, לא צריך לחסום את מצב השינה כדי להאזין להפרעות באירועים. כשמנות נתונים מגיעות לרדיו Wi-Fi או לרדיו סלולרי, חומרת הרדיו מפעילה הפרעה בצורה של נעילת השכמה של ליבת המערכת. לאחר מכן, אפשר לתזמן worker או להשיג נעילת השהיה כדי לעבד את הנתונים.
  • לדוגמה, אם אתם משתמשים ב-ktor-network כדי להאזין לחבילות נתונים בשקע רשת, כדאי להפעיל את נעילת ההשכמה רק אחרי שהחבילות נמסרו ללקוח.

WorkManager

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

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

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

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

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

*job*/<package_name>/androidx.work.impl.background.systemjob.SystemJobService
‫Android מגרסה 16.1 ואילך

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

*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 ומעלה ומשתמשים ב-WorkManager 2.10.0+, השם של נעילת ההפעלה יהיה:

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

המלצה

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

_UNKNOWN

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

המלצה

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