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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• אם אתם עוקבים אחרי מעברים של זמן שהייה, השתמשו בשיטה setLoiteringDelay() עם ערך של כ-5 דקות או פחות.

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

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

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

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

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