במסמך הזה מתוארות שיטות מומלצות לאופטימיזציה של צריכת החשמל באפליקציית ניווט לנייד שאתם מפתחים באמצעות Navigation SDK. בנוסף, מוסבר במאמר על הפשרות שצריך להביא בחשבון כשמשתמשים בשיטות האלה. במסמך הזה מפורטים במיוחד הנושאים הבאים:
- מקורות של צריכת חשמל גבוהה, מדורגים מהגבוה לנמוך.
- אסטרטגיות לאופטימיזציה של צריכת החשמל, לפי סדר החשיבות, החל מרזולוציית המסגרת.
- שיטות למשתמשי קצה שיעזרו לכם ללמד את משתמשי האפליקציה איך לנהל את השימוש במכשיר בזמן הניווט.
למה כדאי לבצע אופטימיזציה של אפליקציית הניווט?
בהתאם למצב שלהם, משתמשי האפליקציה עשויים להפעיל הנחיות ניווט למשך פרקי זמן ארוכים. לדוגמה, נהגים וקוריירים יכולים לעבוד שעות ארוכות ולבצע משימות באזורים לא מוכרים. במקרים כאלה, הם מסתמכים במידה רבה על הנחיות מפורטות מפנייה לפנייה באפליקציה. כתוצאה מכך, נוצרות כמה בעיות טיפוסיות:
- דליפת אנרגיה מהסוללה וזמינות של מטענים. שימוש מוגזם בניווט עלול לגרום לכך שהסוללות של המכשירים יתדללו מהר יותר מהצפוי. משתמשים רבים יכולים לפתור את הבעיה הזו על ידי טעינה של המכשיר ברכב, אבל רוכבי כלי רכב דו-גלגליים לא יכולים לעשות זאת.
- האטת המכשיר בגלל התחממות. גם משתמשים שמטעינים את המכשיר באופן קבוע עלולים להיתקל בבעיות. צריכת חשמל גבוהה במשך פרקי זמן ארוכים עלולה לגרום להתחממות המכשיר, וכתוצאה מכך לוויסות תרמי ולירידה בביצועים.
אפליקציות ניווט עם מסלול מפורט מסתמכות על תכונות שצורכות הרבה חשמל, כמו מסך, GPS ותקשורת רדיו עם מגדלי סלולר. לכן מומלץ לבצע אופטימיזציה של צריכת החשמל באפליקציה לנייד. בנוסף, כדאי להביא בחשבון את הצרכים של קהל היעד לגבי צריכת חשמל, כדי שתוכלו למצוא את האיזון המתאים בין ביצועים לאופטימיזציה של צריכת החשמל.
מה צורך הכי הרבה חשמל?
בקטע הזה הפעילויות באפליקציה שמשויכות לצריכת חשמל גבוהה מחולקות לשתי קטגוריות:
- רינדור המסך
- עדכוני מיקום
רינדור המסך
בדרך כלל, העיבוד של המסך גורם לצריכת האנרגיה הגבוהה ביותר באפליקציות ניווט לנייד. בכל פעם שהמכשיר מצייר מפה ורכיבים אחרים בממשק המשתמש במסך, הוא מסתמך על עיבוד של GPU ו-CPU. באופן דומה, כשהמשתמש משאיר את המסך הזה פועל למשך זמן רב, גם הצריכה של האנרגיה עולה.
במידה מסוימת, אפשר לצפות לצריכת חשמל גבוהה אצל נהגים או נוסעים שמסתמכים על מפה גלויה כדי לנווט, במיוחד אם הם משתמשים באפליקציה ברציפות במשך שעות רבות. בתרחיש הזה, האפליקציה גם מבצעת קצב רינדור גבוה יותר במסך כי המפה מתעדכנת בזמן אמת. במקרים מסוימים, המסך יכול להציג מחדש את התמונה כמעט באופן רציף, במיוחד כשהמשתמש נוסע ממיקום אחד למיקום אחר בלי לעצור.
עדכוני מיקום
בנוסף לעיבוד המסך, שתי פעילויות ניווט אחרות צורכות אנרגיה במכשיר:
- שימוש באנטנה סלולרית וב-GPS
- עדכונים של מיקום ושיתוף מיקום, למשל כדי לספק זמן הגעה משוער או לדווח על המיקומים של כלי רכב בצי.
גם ה-GPS וגם התקשורת ברדיו הסלולרי מסתמכים על פעולות הפעלה צורכות-אנרגיה: ה-GPS צריך למצוא לוויינים, ורדיו הסלולרי צריך לנהל משא ומתן עם מגדלים ולבצע חיבור. לכן, הם פועלים באופן רציף במהלך הניווט, למרות שהרדיו הסלולרי נשאר פעיל למשך 20-30 שניות בניסיון לצמצם את עלויות ההפעלה. מערכת ההפעלה קובעת את ההגדרות האלה, ואי אפשר להגדיר אותן בקלות באפליקציה.
בעדכוני מיקום, צריכת החשמל משתנה בהתאם לגורמים בלתי צפויים. לדוגמה, המרחק בין המכשיר לתחנת הבסיס הסלולרית קובע את צריכת החשמל, כי המכשיר ישתמש באות המינימלי הנדרש כדי להמשיך את הניווט כדי להימנע מחילופי מגדלים. לכן, מכשיר שמנווט באזור עם קישוריות חלשה ישתמש באנרגיה יותר מאשר מכשיר שנמצא קרוב לתחנת בסיס. בנוסף, אפליקציות מסוימות עשויות לשתף עדכוני מיקום עם שירות מרכזי לניהול צי כלי רכב, ולכן הן יצטרכו לתקשר עם שרת כדי לעשות זאת.
אופטימיזציה של צריכת האנרגיה של האפליקציה
האתגר של אופטימיזציה של צריכת החשמל באפליקציות ניווט הוא שהאפליקציות האלה תלויות במידה רבה במשאבים שצורכים הרבה חשמל, מה שמגביל את האפשרויות שלכם לצמצם את ההשפעה בלי להתפשר, למשל על ידי הגבלת השימוש במסך. בקטע הזה מפורטת רשימה של שיטות שאפשר להשתמש בהן כשמבצעים אופטימיזציה לאפליקציה, לפי רמת ההשפעה שלהן (מהגבוהה ביותר ועד הנמוכה ביותר).
שינוי קצב הפריימים
המסך מעדכן את התצוגה בתדירות שנקראת קצב הפריימים. קצב הפריימים נמדד בדרך כלל בפריימים לשנייה (FPS). עיבוד המסך צורך הרבה מעבד או מעבד גרפי, ולכן אפשר להקטין את קצב הפריימים כדי לחסוך בצריכת החשמל.
החיסרון של הפחתת קצב הפריימים הוא שהעיבוד של המסך עשוי להיראות פחות חלק, במיוחד אם המפה מתעדכנת בתדירות גבוהה. המצב הזה עשוי להיות בולט במיוחד כשהמפה מוגדרת להגדלה גבוהה כדי להציג פרטים מפורטים, כשהמשתמש נוסע במהירות גבוהה או כשיש שינוי משמעותי במהירות או בכיוון.
במכשירי iOS, ה-SDK של מפות ל-iOS חושף את המאפיין preferredFrameRate כדי לשלוט בקצב הפריימים. בטבלה הבאה מפורטים ערכי המונהGMSFrameRate שאפשר לשנות:
|
כדאי להשתמש בקצב הפריימים המינימלי כדי לחסוך בצריכת הסוללה. |
|
שימוש בקצב מסגרות חציוני כדי לספק רינדור חלק יותר ולשמור על מחזורי עיבוד. |
|
להשתמש בקצב הפריימים המקסימלי של המכשיר. במכשירים ברמה נמוכה, קצב הפריימים הוא 30 FPS. במכשירים ברמה גבוהה, קצב הפריימים הוא 60 FPS. |
לקבלת מידע נוסף, אפשר לעיין במאמר GMSFrameRate במסמכי התיעוד של Google Navigation SDK ל-iOS.
ניווט בלי מפה
אתם לא יכולים לקבוע איך משתמש הקצה מגדיר את בהירות המסך של המכשיר או למשך כמה זמן הוא משאיר את המסך דלוק, אבל אתם יכולים לספק אפשרות לקבל הנחיות ניווט בלי מפה. כך משתמש הקצה יוכל לבחור באפשרות הזו כדי לחסוך בחשמל. לדוגמה, אם הנהגים עובדים באופן קבוע באותו שכונה, יכול להיות שהם לא יצטרכו הנחיות מבוססות-מפה בתדירות גבוהה. כדי להפעיל ניווט בלי מפה, צריך להגדיר יעד ולהתחיל הנחיה ב-Navigation SDK, בלי להציג מפה.
מוסיפים שורת קוד כדי להסתיר את GMSMapView:
mapView.isHidden = true
Navigation SDK ימשיך לעדכן את המיקומים של צילומי הכביש, זמן ההגעה המשוער ואת המרחק שנותר לנסיעה, והאפליקציה עדיין תוכל להירשם לכל האירועים שה-SDK יוצר בזמן שהנהג ממשיך בנסיעה. האפשרות הזו לא מתאימה לכל תרחיש שימוש, וכמובן לא מומלצת במקרים שבהם הנהג צריך לראות את המפה ולפעול לפי הנחיות חזותיות. צילומי המסך הבאים ממחישים השוואה בין תצוגות המפה במהלך ניווט פעיל.
|
|
שימוש בסגנון כהה של מפה
כדאי להשתמש בעיצוב של מפה עם נושא כהה כדי לצמצם את כמות האנרגיה שנדרשת לעיבוד המפה במסך.
ה-Navigation SDK מעבד את המפות שלו באמצעות Google Maps SDK ל-iOS, שמכיל אפשרויות לעיצוב תצוגות מפה באפליקציה שלא קשורות לניווט. תצוגת הניווט תומכת גם בהחלת מצב כהה בכפייה. יכול להיות שההגדרה הזו לא תשפיע על כל המכשירים באותה דרך בגלל הבדלים בסוג המסך, אבל היא מאפשרת לחסוך באנרגיה במקרים מסוימים. מחקר שנערך לאחרונה מצא שסכום החיסכון באנרגיה במצב כהה במסכים מסוימים תלוי במידת הבהירות של המסך מלכתחילה. לדוגמה, מצב כהה חוסך יותר חשמל במסכים שמוגדרים לבהירות מלאה מאשר במסכים שהבהירות שלהם כבר מותאמת ל-30-50% מהבהירות המקסימלית. חשוב להביא את הנושא הזה בחשבון כשמשתמשים במצב כהה באפליקציות, כי החיסכון באנרגיה יהיה יחסי להגדרת הבהירות של המסך של משתמש הקצה.
מידע נוסף על שינוי ממשק המשתמש של הניווט זמין במאמר שינוי ממשק המשתמש של הניווט.
כדי להשתמש בסגנון מפה מבוסס-ענן, נדרש מזהה מפה שמייצג הגדרת מפה בצד השרת שנוצרה בפרויקט שלכם במסוף Google. למידע נוסף על יצירת מזהה מפה, אפשר לעיין במסמכי העזרה למפתחים בנושא מזהי מפה. פרטים נוספים על תכנון ופריסה של סגנון מפה מבוסס-ענן זמינים במסמכי התיעוד למפתחים בנושא יצירה וניהול של סגנונות מפה מבוססי-ענן.
שינוי תדירות העדכון של מיקום ה-GPS
כשבודקים את צריכת האנרגיה של עדכוני המיקום שנשלחים מהמכשיר, כדאי להתמקד יותר בתדירות של עדכוני המיקום ולא בכמות הנתונים שנשלחים בהעברה.
אי אפשר לשלוט בזה באופן ישיר ב-Navigation SDK. אותה עצה רלוונטית גם לשימוש במקורות מיקום שאינם GPS (סלולר ו-Wi-Fi).
שליחת עדכונים שוטפים למשתמשים
יכול להיות שהמשתמשים באפליקציה שלכם ירצו לדעת איך לבצע אופטימיזציה של צריכת החשמל. כדי לעזור למשתמשים לצמצם את צריכת החשמל באפליקציות שלהם, מומלץ להמליץ להם לבצע את הפעולות הבאות:
- נעילת הטלפון
- העברת אפליקציית הניווט לרקע
- אם אפשר, להשתמש בניווט בלי מפה
- להפחית את הבהירות של המסך באמצעות מצב כהה במסכים מסוג OLED ו-AMOLED, או באמצעות הפעלת התאמה אוטומטית של הבהירות
- שמירה על טמפרטורה קרירה במכשיר
- מתחברים לרשת ה-Wi-Fi ברכב, אם יש כזו.
מדידת צריכת החשמל
אפשר להשתמש בכלים ברמה מקצועית כדי למדוד את צריכת החשמל, אבל לרוב קשה להשיג אותם או שהם יקרים. אפליקציות וכלים ליצירת פרופילים של סביבת הפיתוח המשולבת (IDE), כמו Power Profiler ב-Android Studio והחלונית Battery Usage ב-XCode Organizer, מודדים את צריכת החשמל, אבל יכול להיות שיהיה קשה להסיר את ההשפעה של תהליכים ברקע או להגדיר בסיס ביצועים להשוואה. במקרים מסוימים, הגבלות במכשיר עשויות למנוע גישה לנתונים הנדרשים.
אפשר להשתמש בחומרה ייעודית למעקב אחר צריכת החשמל ולשנות את הגדרות החיבור של הסוללה. יש גם מוצרים ושירותים מסחריים שיעזרו לכם לעשות זאת. חשוב לזכור ששינוי המכשירים באופן הזה עלול לבטל את האחריות עליהם.