חיסכון בחשמל ובסוללה

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

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

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

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

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

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

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

מעקב אחר השימוש בסוללה לאורך זמן

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

adb shell dumpsys batterystats

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

אירועים שמשפיעים על חיי הסוללה

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

בטבלה הבאה מוצגת ההשפעה היחסית על חיי הסוללה של כמה אירועים נפוצים באפליקציות ל-Wear OS. כמות החשמל שנצרכת בפועל משתנה בין מכשירים.

אירוע ההשפעה על חיי הסוללה איך לצמצם את ההשפעה
גישה לרשת, כולל LTE ו-Wi-Fi גבוה מאוד דחיית גישה לא חיונית לרשת עד שהמכשיר נטען.
הפעלת המסך והפעלת המצב האינטראקטיבי רחב אין לעודד את המשתמש להשאיר את המסך פועל יותר זמן מהנדרש. צריך לספק חוויה שמשתמשת במצב פועל כל הזמן, שנקרא גם 'מצב רגישות לסביבה'.
גישה לחיישן ה-GPS רחב אם אפשר, כדאי להמתין עד שהמשתמש יבקש גישה ל-GPS.
שמירה על שימוש גבוה במעבד (CPU) רחב שימוש ב-Jetpack פיתוח נייטיב לצריכת תהליכים
גישה לחיישן קצב הלב בינוני משתמשים בזמן ההפעלה של המעבד כשמקבלים קריאות חזרה מ-Sensor API, למשל כשמשתמשים בשירותי Health ב-Wear OS.
גישה למכשיר אחר באמצעות Bluetooth בינוני חשוב שהסשנים יהיו קצרים.
שמירה של Wakelock בינוני כדאי להפחית את היצירה הידנית של Wakelocks ולהשתמש ב- WorkManager.

צמצום זמן המסך

באפליקציה ל-Wear OS, כדאי לפעול לפי עקרונות השימוש הבאים במסך:

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

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

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

צמצום השימוש במעבד

באפליקציית Wear OS, פועלים לפי עקרונות השימוש ב-CPU הבאים:

  • הקפידו על שימוש קצר.
  • כדאי לאסוף בקבוצה פעולות קשורות כדי למקסם את הזמן שבו התהליך של האפליקציה לא פעיל.

צמצום מספר ה-wakelocks

ברוב המקרים, כדאי להימנע מפעולות שמונעות מהאפליקציה לעבור למצב שינה, כמו wakelocks. לדוגמה, באפליקציות בריאות וכושר, באימוני כושר ממושכים אין צורך ב-Warelock. כדאי להשתמש בזמן ההפעלה של המעבד כשמקבלים קריאות חזרה מ-Sensor API, למשל כשמשתמשים ב-Health Services ב-Wear OS.

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

  • הפעלת מדיה ברקע.
  • נעשה שימוש ב-WorkManager או ב-JobScheduler. (המערכת מחזיקה בשבילכם את ה-wakelock כשאתם מריצים את המשימה ברקע).

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

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

איך בודקים איך האפליקציה מפסיקה להיות פעילה

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

  • המסך נכבה והמכשיר נכנס למצב אווירה.

  • האפליקציה נמחקת בתנועת החלקה.

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

Power Profiler

כדי לגשת ל-Power Profiler בתפריט של Android Studio, בוחרים באפשרות View (תצוגה) > Tool Windows (חלונות כלים) > Profiler (כלי לניתוחי ביצועים):

  1. בודקים את מעקב המערכת כשהמסך נכבה והמכשיר עובר למצב אווירה.
  2. מחפשים משימות שממשיכות לפעול ורמת השימוש ב-CPU של המכשיר.

Perfetto

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

מגדירים אירועים מותאמים אישית כדי לסמן את האירועים המשמעותיים של האפליקציה, כולל אירועים ספציפיים לדומיין. באפליקציית מדיה, משימות כאלה יכולות לכלול אחזור של פלייליסטים, הורדה של פריט מדיה ספציפי, הפעלת ההפעלה ועצירתה. כשמגדירים את האירועים האלה, אפשר לראות אותם ב-Perfetto ולהשוות את התזמון שלהם למעבד (CPU) ולצריכת החשמל של האפליקציה.

ניתוח המשימות המתוזמנות של האפליקציה

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

אפשר להשתמש ב-Battery Historian כדי לבדוק את הביצועים של משימות מתוזמנות, גם באופן כללי (נתונים סטטיסטיים של המערכת > נתונים סטטיסטיים של JobScheduler) וגם לפי אפליקציה (נתונים סטטיסטיים של אפליקציה > משימה מתוזמנת). בודקים את המספר הכולל ואת משך הזמן הכולל:

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

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

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

חיישנים

במכשירי Wear OS יש הרבה חיישנים שונים, כמו GPS. ברוב המקרים, מומלץ להשתמש בשירותי Health ב-Wear OS במקום לבצע אינטראקציה ישירה עם SensorManager. במקרים רבים, שירותי Health Services מקובצים את הנתונים בצורה חכמה כדי לשפר את ביצועי הסוללה.

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

adb shell dumpsys sensorservice

התוצאות של הפקודה הזו הן:

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

בדיקת ביטול הרישום מהחיישנים

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

  1. מחליקים כדי לסגור את האפליקציה.
  2. מקישים על המסך עם כף היד. הפעולה הזו תכבה את המסך או תעביר אותו למצב אווירה.

משתמשים בפקודת ה-ADB מהקטע הקודם כדי לבדוק אם החיישן מופיע כלא רשום.

שכבת נתונים

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

עוד כמה שיטות מומלצות לשימוש ב-Data Layer API:

  • צריך להמתין עד שהאפליקציה תהיה פעילה לפני שמגדירים מאזין באמצעות WearableListenerService.

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

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

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

adb shell dumpsys activity service WearableService

התוצאות של הפקודה הזו כוללות את הפרטים הבאים:

  • RpcService: מאפשר לכם לראות באיזו תדירות מתבצעות קריאות לנתיב מסוים באמצעות MessageClient.
  • DataService: מאפשר לכם לראות באיזו תדירות פריטי נתונים מוגדרים באמצעות DataClient.

אפליקציות בריאות וכושר

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

  • עבור ExerciseClient, משתמשים ב-Battery Historian כדי לוודא שההתנהגות נכונה במצב תאורת אווירה. חשוב לוודא שהאפליקציה לא מתעוררת בתדירות גבוהה יותר מכל דקה או שתיים כדי לקבל נתוני ExerciseUpdate.
  • כדי לעקוב אחרי נתוני הבריאות הכלליים לאורך היום, משתמשים ב-PassiveMonitoringClient, כפי שמתואר במדריך בנושא מעקב אחרי נתוני הבריאות והכושר ברקע.

אריחים ותכונות נוספות

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

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