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

מילות מפתח: wearos, ‏ power, ‏ battery, ‏ performance

יעילות צריכת האנרגיה חשובה במיוחד ב-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. כמות החשמל שנצרכת בפועל משתנה בין מכשירים.

מקצרים את זמן הפעלת המסך

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Power Profiler

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

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

Perfetto

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

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

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

משימות מתוזמנות באמצעות 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) או במשימות מתוזמנות בצורה מתאימה. חשוב להימנע משיעור עדכונים מהיר, שעלול לגרום למערכת לתזמן עבודה חוזרת בקצב מהיר יותר מהקצב שבו המשתמש או הפלטפורמה יכולים לגשת לנתונים הנדרשים לביצוע העבודה.
• אל תתזמנו משימות לכרטיס המידע או לתכונת הנוספה כשהמשתמש לא יוצר איתם אינטראקציה.
• שימוש בגישות שמתמקדות בעבודה אופליין.
• שיתוף מסד נתונים יחיד בין האפליקציה הראשית, המשבצות והתכונות המותאמות אישית. כך גם הנתונים יהיו עקביים בממשקי המשתמש השונים.