אופטימיזציה של המיקום לצריכת הסוללה

מיקום הרקע מגבלותנוספות מערכת Android 8.0 (רמת API 26) החזירה מיקוד חדש לנושא השימוש בשירותי מיקום משפיע על התרוקנות הסוללה. הדף הזה מתייחס למיקומים מסוימים שיטות מומלצות לשימוש בשירותים ומה אפשר לעשות עכשיו כדי להגביר את צריכת הסוללה של האפליקציות יעיל. יישום השיטות המומלצות האלה יתרום לאפליקציה בגרסת הפלטפורמה שבה היא פועלת.

מגבלות המיקום ברקע ב-Android 8.0 כללו את השינויים הבאים:

• יש ויסות נתונים (throttle) לאיסוף מיקום ברקע ומתבצע חישוב של המיקום, וכן ונשלחים רק כמה פעמים בשעה.
• סריקות Wi-Fi שמרניות יותר, ועדכוני מיקום לא מחושבים כאשר המכשיר נשאר מחובר לאותה נקודת גישה סטטית.
• הרספונסיביות של גבולות וירטואליים משתנה מעשרות שניות לכשתיים דקות. השינוי הזה משפר באופן משמעותי את ביצועי הסוללה – עד 10 פעמים טובים יותר במכשירים מסוימים.

דף זה מניח שאתה משתמש בשירותי המיקום של Google ממשקי API, שמספקים רמת דיוק גבוהה יותר ליצור נטל סוללה קל יותר מאשר מיקום המסגרת ממשקי API. לחשבון באופן ספציפי, דף זה מתבסס על ההנחה שאתם מכירים את ספק המיקום המשולב API, שמשלבת אותות מ-GPS, מ-Wi-Fi ומרשתות סלולריות, וגם מד תאוצה, ג'ירוסקופ, מגנטומטר וחיישנים אחרים. אתם צריכים גם להיות להכיר את גבולות הפריים, את ה-API שלה, בנוסף לממשק ה-API של ספק המיקום המשולב, והוא מותאם לצריכת סוללה או של ביצועים.

הסבר על התרוקנות הסוללה

איסוף מיקום וניצול הסוללה קשורים ישירות לנושאים הבאים היבטים:

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

דיוק

ניתן לציין את דיוק המיקום באמצעות setPriority() ומעבירים אחד מהערכים הבאים כארגומנט:

• PRIORITY_HIGH_ACCURACY מספק את המיקום המדויק ביותר האפשרי, שמחושב באמצעות קלטים רבים לפי הצורך (הוא מפעיל GPS, Wi-Fi וחיבור סלולרי, ומשתמש מגוון של חיישנים), ועלולים לגרום התרוקנות משמעותית של הסוללה.
• PRIORITY_BALANCED_POWER_ACCURACY מספק מיקום מדויק בעת ביצוע אופטימיזציה לצריכת חשמל. משתמשת לעיתים רחוקות מאוד GPS. בדרך כלל משתמש בשילוב של רשת Wi-Fi ומידע סלולרי כדי לחשב מיקום המכשיר.
• PRIORITY_LOW_POWER מסתמכת בעיקר על מגדלי תקשורת ומונעת כניסות GPS ו-Wi-Fi, דיוק משוער (ברמת העיר) עם התרוקנות מינימלית של הסוללה.
• PRIORITY_NO_POWER מקבל מיקומים באופן פסיבי מאפליקציות אחרות שעבורן מיקום כבר חושב.

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

תדירות

ניתן לציין תדירות מיקום באמצעות שתי שיטות:

• משתמשים ב setinterval() שתציינו את מרווח הזמן שבו מחושב מיקום האפליקציה שלכם.
• משתמשים ב setFastestInterval() כדי לציין את מרווח הזמן שבו המיקום מחושב עבור אפליקציות אחרות ישירות לאפליקציה.

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

איטית

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

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

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

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

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

עדכונים גלויים למשתמש או עדכונים בחזית

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

משתמשים ב setPriority() עם ערך של PRIORITY_HIGH_ACCURACY או PRIORITY_BALANCED_POWER_ACCURACY.

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

מידע על מיקום המכשיר

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

משתמשים ב getLastLocation() שמחזירה את המיקום הזמין העדכני ביותר (במקרים נדירים ייתכן שמספר המקרים יהיה null) . השיטה הזו מספקת דרך פשוטה לקבל מיקום לא כרוכים בעלויות שקשורות לבקשה פעילה לקבלת עדכוני מיקום. כדאי להשתמש בשילוב עם isLocationAvailable() , שתחזיר את הערך true כשהמיקום המוחזר getLastLocation() עדכני במידה סבירה.

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

דוגמה: בקשת עדכונים כאשר משתמש נמצא במרחק מסוים מ- העבודה, הבית או מיקום אחר.

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

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

העדכונים מופעלים על סמך מצב הפעילות של המשתמש

דוגמה: בקשת עדכונים רק כאשר המשתמש נוהג או נוסע אופניים.

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

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

עדכונים ברקע במשך זמן רב שקשורים לאזורים גיאוגרפיים

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

זהו תרחיש לדוגמה מצוין לגבולות וירטואליים. בגלל שהתרחיש לדוגמה כמעט חייבת להיות קשורה למיקום ברקע, להשתמש addGeofences(GeofencingRequest, PendingIntent) .

אתם צריכים להגדיר את אפשרויות ההגדרה הבאות:

• אם אתם עוקבים אחרי מעברי תושבות, השתמשו setLoiteringDelay() שנקבעת בערך של כחמש דקות לכל היותר.

• משתמשים ב setNotificationResponsiveness() להעביר ערך של כחמש דקות. אבל כדאי להשתמש בערך כעשר דקות אם האפליקציה שלכם תוכל להתמודד עם העיכוב הנוסף רספונסיביות.

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

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

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

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

משתמשים ב setPriority() עם PRIORITY_NO_POWER אם הדבר אפשרי, מכיוון שהסוללה כמעט לא מתרוקנת. אם משתמשים אי אפשר להשתמש ב-PRIORITY_NO_POWER, צריך להשתמש PRIORITY_BALANCED_POWER_ACCURACY או PRIORITY_LOW_POWER, אבל להימנע משימוש PRIORITY_HIGH_ACCURACY לעבודה ברקע לאורך זמן, כי האפשרות הזו מתרוקנת באופן משמעותי סוללה.

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

שנה את התדירות על ידי הוספת זמן אחזור מסוים, באמצעות הפונקציה setMaxWaitTime() . לדוגמה, אם משתמשים בשיטה setinterval() עם ערך של כ-10 דקות, כדאי להתקשר אל setMaxWaitTime() עם ערך בין 30 ל-60 דקות. על סמך האפשרויות האלה, המיקום מחושב אפליקציה בערך כל 10 דקות, אבל האפליקציה לא במצב שינה כל 30 עד 60 דקות, כשנתוני מיקום מסוימים זמינים כעדכון בכמות גדולה. הזה גישה זו מחליפה את זמן האחזור לקבלת יותר נתונים זמינים וסוללה טובה יותר או של ביצועים.

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

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

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

שיטות מומלצות לעבודה עם מיקום

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

הסרת עדכוני מיקום

אחד הסיבות הנפוצות להתרוקנות מיותרת של הסוללה הוא כשל בהסרת המיקום מעודכנים כשהם לא נחוצים יותר. יכול לקרות, לדוגמה, כאשר onStart() של הפעילות או מחזור חיים onResume() השיטות כוללות קריאה ל- requestlocationUpdates() ללא קריאה תואמת אל removeLocationUpdates() בonPause() או onStop() שיטות במחזור החיים.

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

הגדרת זמנים קצובים לתפוגה

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

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

כדי להוסיף זמן קצוב לבקשת מיקום בגבולות וירטואליים, קוראים setExpirationDuration() .

בקשות אצווה

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

Kotlin

val request = LocationRequest()
request.setInterval(10 * 60 * 1000)
request.setMaxWaitTime(60 * 60 * 1000)

Java

LocationRequest request = new LocationRequest();
request.setInterval(10 * 60 * 1000);
request.setMaxWaitTime(60 * 60 * 1000);

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

שימוש בעדכונים פסיביים של מיקום

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

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

Kotlin

val request = LocationRequest()
request.setInterval(15 * 60 * 1000)
request.setFastestInterval(2 * 60 * 1000)

Java

LocationRequest request = new LocationRequest();
request.setInterval(15 * 60 * 1000);
request.setFastestInterval(2 * 60 * 1000);

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

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

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