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

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

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

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

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

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

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

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

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

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

adb shell dumpsys batterystats

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

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

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

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

צמצום זמן המסך הפעיל

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

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

צמצום השימוש במעבד (CPU)

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

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

צמצום השימוש ב-wakelocks

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

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

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

כדי לנפות באגים בחסימות של מצב השינה באופן מקומי, אפשר להשתמש בכלי לבדיקת משימות ברקע, במעקב אחר המערכת או ב-adb shell dumpsys batterystats ב-Android Studio כדי לבדוק מקרים ספציפיים של חסימות ארוכות של מצב השינה, וגם סיכומים של המספר הכולל ומשך הזמן של חסימות מצב השינה. השוו בין המספר ומשך הזמן של נעילות ה-wakelock שהאפליקציה שלכם מחזיקה לבין דפוסי השימוש האינטראקטיביים של האפליקציה:

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

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

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

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

• האפליקציה נסגרת בהחלקה.

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

Power Profiler

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

1. בודקים את מעקב המערכת בזמן שהמסך נכבה והמכשיר עובר למצב רגיש לסביבה.
2. בודקים אם יש פעולות שממשיכות להתבצע ואת רמת השימוש במעבד (CPU) של המכשיר.

Perfetto

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

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

אפשר גם להשתמש ב-Android CLI כדי להתקין את הסקיל android-profiler (android skills add android-profiler), שמאפשרת לסוכני AI להקליט עקבות המערכת של Perfetto משורת הפקודה ולנתח מסילות חשמליות, חסימות מצב שינה ומצבי השעיה של המכשיר.

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

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

משתמשים ב-Background Task Inspector של Android Studio (View > חלונות של הכלים > App Inspection) או מריצים את adb shell dumpsys jobscheduler ו-adb shell dumpsys batterystats כדי לבדוק את ההרצה של משימות מתוזמנות ו-workers. בודקים את תדירות ההפעלה ואת משך הזמן הכולל:

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

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

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

חיישנים

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

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

adb shell dumpsys sensorservice

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

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

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

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

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

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

שכבת נתונים

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

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

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

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

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

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

adb shell dumpsys activity service WearableService

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

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

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

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

• ב-ExerciseClient, צריך להשתמש בעקבות המערכת, ב-Perfetto או ב-adb shell dumpsys batterystats כדי לוודא שההתנהגות במצב רגיש לסביבה תקינה. חשוב לוודא שהאפליקציה לא מתעוררת בתדירות גבוהה יותר מפעם בדקה או שתיים כדי לקבל נתוני ExerciseUpdate.
• כדי לעקוב אחרי הבריאות הכללית לאורך כל היום, אפשר להשתמש ב-PassiveMonitoringClient, כמו שמתואר במדריך בנושא מעקב אחרי נתוני בריאות ונתונים של אימוני כושר ברקע.

משבצות ותצוגות שעון

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

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