במדריך הזה מתוארות כמה אסטרטגיות לאופטימיזציה של ממשקי ה-API של מפות Google בשימוש במונחים של אבטחה, ביצועים וצריכה.
אבטחה
בדיקת שיטות מומלצות לאבטחה
מפתחות API הם פרטי כניסה ממוקדי-פרויקט, עם אותם אמצעי זהירות כמזהי משתמשים ולסיסמאות. כדאי לקרוא את שיטות מומלצות לאבטחת API כדי לאבטח את המפתחות שימוש לא מכוון שעלול להוביל לשימוש מיותר במכסה ולחיובים לא צפויים לחשבון שלך.
שימוש במפתחות API לגישה לממשקי API של מפות Google
מפתחות API הם שיטת האימות המועדפת לגישה לממשקי ה-API של מפות Google ממשקי API. בזמן השימוש במזהי הלקוח עדיין יש תמיכה, אבל מפתחות API תמיכה באמצעי בקרת אבטחה מפורטים יותר ואפשר לכוונן אותה לעבודה עם כתובות אינטרנט, כתובות IP וערכות SDK לנייד (Android ו-iOS). למידע בנושא יצירה ואבטחה של מפתח API, עוברים לקטע 'שימוש במפתח API' דף לכל API או SDK. (לדוגמה, כדי לגשת אל Maps JavaScript API, צריך להיכנס אל הדף שלו בקטע שימוש במפתח API).
ביצועים
שימוש בהשהיה מעריכית לפני ניסיון חוזר (exponential backoff) כדי לטפל בשגיאות
אם באפליקציות שלכם נתקלת בשגיאות שנגרמות מניסיונות מוגזמים לקרוא ל-API לפרק זמן קצר, כגון שגיאות QPS, כדאי להשתמש השהיה מעריכית לפני ניסיון חוזר (exponential backoff) כדי לאפשר לבקשות לעבד.
השהיה מעריכית לפני ניסיון חוזר (exponential backoff) היא שימושית ביותר לשגיאות במאות ה-500. לקבלת מידע נוסף, למידע נוסף, ראו טיפול בקודי סטטוס החזרה של HTTP.
ספציפית, כדאי להתאים את קצב השאילתות. בקוד, מוסיפים
תקופת המתנה של S שניות בין שאילתות. אם השאילתה עדיין בתוצאות
בשגיאת QPS, להכפיל את תקופת ההמתנה ואז לשלוח שאילתה נוספת. כן, אני רוצה
להתאים את תקופת ההמתנה עד שהשאילתה תוחזר ללא שגיאה.
שליחת בקשות לאינטראקציה של משתמשים על פי דרישה
יש לשלוח בקשות לממשקי API שכוללות אינטראקציה עם משתמשים רק על פי דרישה.
כלומר, צריך להמתין שמשתמש הקצה יבצע פעולה (למשל on-click)
להתחיל את בקשת ה-API, ולאחר מכן להשתמש בתוצאות כדי לטעון מפה, להגדיר
היעד, או להציג את המידע המתאים. שימוש בגישה על פי דרישה
להימנע מבקשות מיותרות לממשקי ה-API, וכך לצמצם את צריכת ממשקי ה-API.
הימנעות מהצגת תוכן שכבת-על כשהמפה זזה
נמנעים משימוש ב-Draw() כדי להציג תוכן שכבת-על מותאם אישית במפה באותו זמן
הזמן שבו משתמש יזיז את המפה. מאחר שהמפה משורטטת מחדש בכל פעם
משתמש מזיז את המפה, הצבת תוכן שכבת-על במפה בו זמנית יכולה
ליצור עיכובים או שיבושים חזותיים. הוסף או הסר תוכן שכבת-על רק
במפה ברגע שהמשתמש מפסיק להזיז את התצוגה או לשנות את מרחק התצוגה.
הימנעות מפעולות אינטנסיביות בשיטות של Draw
באופן כללי, מומלץ להימנע מביצועים אינטנסיביים
פעולות שאינן שרטוט בשיטת Draw(). לדוגמה, עדיף להימנע
את הקוד הבא בקוד ה-method Draw():
- שאילתות שמחזירות כמות גדולה של תוכן.
- שינויים רבים בנתונים המוצגים.
- מניפולציה של רכיבים רבים של מודל אובייקטי מסמך (DOM).
הפעולות האלה עלולות להאט את הביצועים וליצור עיכובים או שיבושים חזותיים בעת עיבוד המפה.
שימוש בתמונות רשת נקודות לסמנים
כשמוסיפים תמונות לרשת נקודות, למשל תמונות בפורמט PNG. או JPG כדי לזהות מיקום במפה. הימנעות משימוש ב-Scalable Vector תמונות גרפיקה (SVG), מאחר שרינדור תמונות SVG עשוי ליצור עיכוב במקרים שבהם המפה משורטטת מחדש.
אופטימיזציה של סמנים
האופטימיזציה משפרת את הביצועים על ידי הצגת סמנים רבים כנתון סטטי יחיד לרכיב מסוים. האפשרות הזו שימושית במקרים שבהם נדרש מספר גדול של סמנים. כברירת מחדל, Maps JavaScript API יחליט אם סמן יעברו אופטימיזציה. כשיש מספר גדול של סמנים, JavaScript API של מפות Google ינסה לעבד סמנים עם אופטימיזציה שלו. לא ניתן לבצע אופטימיזציה של כל הסמנים. במצבים מסוימים, ייתכן שיהיה צורך לעבד סמנים ללא JavaScript API של מפות Google אופטימיזציה שלו. השבתת עיבוד האופטימיזציה של קובצי GIF או PNG מונפשים, או כאשר יש לעבד כל סמן כרכיב DOM נפרד.
יצירת אשכולות לניהול תצוגת הסמנים
כדי לנהל את התצוגה של הסמנים לזיהוי מיקומים במפה, ליצור אשכול סמנים באמצעות הספרייה Marker Clusterer הספרייה 'מאשכול סמנים' כוללת אפשרויות עבור:
- גודל הרשת, כדי לציין את מספר הסמנים לקיבוץ באשכול.
- זום מקסימלי, כדי לציין את רמת הזום המקסימלית שבה כדי להציג את האשכול.
- נתיבי תמונות, לשימוש בתמונות הגרפיקה כסמלים של סמנים.
צריכה
כדי לתכנן את התקציב ולשלוט בעלויות, מבצעים את הפעולות הבאות:
- הגדרה של התראת תקציב
לעקוב אחרי האופן שבו העלויות שלכם מתפתחות לסכום מסוים. הגדרת תקציב
אינה מגבילה את השימוש ב-API - היא מתריעה רק כאשר העלויות מתקרבות
בסכום שצוין.
- הגבלת השימוש היומי ב-API כדי לנהל את העלויות של ממשקי API שניתנים לחיוב. על ידי הגדרת מכסות לבקשות לכל יום, תוכלו להגביל את העלויות. משתמשים במשוואה פשוטה כדי לקבוע מכסה, בהתאם לסכום שרוצים להוציא: (מדי חודש עלות/מחיר לכל )/30 = מכסה ליום (לממשק API אחד). היישום הספציפי שלך עשוי משתמשים בכמה ממשקי API שניתנים לחיוב, לכן משנים את המשוואה לפי הצורך. א' קרדיט בסך 200 דולר ארה"ב לממשקי Google Maps API היא זמינה בכל חודש, לכן מביאים אותה בחשבון בחישובים.
- ניתן להשתמש בפרויקטים מרובים כדי לבודד את השימוש, לתעדף אותו ולעקוב אחריו. לדוגמה, נניח שאתם משתמשים באופן קבוע בממשקי ה-API של הפלטפורמה של מפות Google בדיקות. על ידי יצירת פרויקט נפרד לבדיקה – עם מכסות ומכסות משלו מפתחות API – ניתן לבדוק ביסודיות תוך הגנה מפני הפתעה הוצאות יתר.
ניהול הצריכה במפות Google
מפה אחת בכל דף היא דרך טובה לבצע אופטימיזציה של תצוגת מפות, מכיוון משתמשים בדרך כלל יוצרים אינטראקציה עם מפה אחת בלבד בכל פעם. האפליקציה שלך יכולה לבצע שינויים המפה להצגת קבוצות נתונים שונות, בהתאם לאינטראקציה של הלקוח וצרכים.
שימוש בתמונות סטטיות
העלות של בקשות שמשתמשות בתמונות דינמיות (מפות דינמיות ו-Street View דינמי) יותר מאשר 'מפות סטטיות' ו-Street View סטטי. אם אתם לא צופים מראש אינטראקציה עם 'מפה' או עם Street View (שינוי מרחק התצוגה או הזזה), משתמשים ברכיב הסטטי של ממשקי ה-API האלה.
תמונות ממוזערות - מפות ותמונות קטנות מאוד - הן שימוש טוב נוסף עבור Static מפות ו-Street View סטטי. פריטים אלה מחויבים בתעריף נמוך יותר לאינטראקציה עם משתמשים (בלחיצה), ויכול להעביר את המשתמשים לגרסה דינמית חוויית השימוש במפות Google.
שימוש בממשק ה-API של מפות Google להטמעה
אפשר להשתמש ב-Maps Embed API כדי להוסיף מפה עם סמן יחיד או מפה דינמית, בחינם. משתמשים ב Maps Embed API לאפליקציות שכוללות אין צורך בהתאמה אישית של הסמן ואין צורך בהתאמה אישית של המפה. בקשות להטמעת API של מפות Google באמצעות מצב 'מסלול', במצב תצוגה או במצב חיפוש יחויבו (יש לעיין בקטע טבלת תמחור לקבלת פרטים נוספים).
שימוש בערכות SDK של מפות לנייד עבור אפליקציות לנייד
עבור אפליקציות לנייד, השתמשו ב-SDK של מפות ל-Android או SDK של מפות ל-iOS בזמן הצגת מפה. שימוש ב-API הסטטי של מפות Google או ממשק JavaScript API של מפות Google כאשר הדרישות לא כפופות באמצעות ערכות ה-SDK לנייד.
ניהול הצריכה במסלולים
הגבלת נקודות הציון של ה-API של המסלול
כשאפשר, הגבילו את על רשומות המשתמשים בשאילתה לעד 10 ציוני דרך. בקשות שכוללות יותר מ-10 ציוני דרך יחויבו בתעריף גבוה יותר.
שימוש באופטימיזציה של Directions API לניתוב אופטימלי
בקשות שמשתמשות בארגומנט האופטימיזציה של ציון הדרך יחויבו בשיעור גבוה יותר. מידע נוסף זמין במאמר אופטימיזציה של ציוני דרך.
ארגומנט האופטימיזציה ממיין ציוני דרך כדי להבטיח ניתוב אופטימלי, כלומר, נסיעה מ-A ל-E מאפשרת חוויה טובה יותר כאשר מבצעים אופטימיזציה (A-B-C-D-E) לעומת הרצף האקראי של נתיב שאינו מותאם (למשל: A-D-B-C-E).
שימוש במודלים של תנועה בזמן אמת ב-Directions API וב-Destination Matrix API
Directions API ו-Destination Matrix API
בקשות שכוללות מודלים של תנועה בזמן אמת יחויבו בתעריף גבוה יותר.
כדי להפעיל מודלים של תנועה בזמן אמת, צריך להגדיר את שעת היציאה ל-now.
אם מודלים של תנועה לא נכללים בבקשה, התוצאות יתבססו על רק על סמך גורמים פיזיים: כבישים, מרחק ומגבלות מהירות.
שימוש במסלול שעברת וב- הדרך הקרובה ביותר כשנתוני ה-GPS לא מדויקים
התכונות של Maps Roads API, 'מסלולים שעוברים' ו הכביש הקרוב ביותר, כלולים במסלול המתקדם ומחויבים בסכום גבוה יותר מחיר. השתמשו בתכונות אלה כאשר נתוני ה-GPS לא מדויקים הכלי Roads API יכול לעזור לקבוע את הדרך הנכונה. להדפסה מהירה מגבלות, תכונה נוספת של Roads API, זמין רק ללקוחות של מעקב אחר נכסים.
מגבלת מהירות הדגימה במיקומים של 5 עד 15 דקות
כדי לצמצם את כמות הקריאות ל-Maps Roads API שירות מגבלת מהירות, דוגמים את מיקומי הנכסים תוך 5 עד 15 דקות במרווחים. הערך המדויק תלוי במהירות שבה הנכס מטיילות. אם נכס נשאר נייח, דגימת מיקום יחידה מספיק. אין צורך לבצע מספר שיחות.
כדי למזער את זמן האחזור הכולל, יש להפעיל את שירות 'מגבלת מהירות' לאחר שצברו נתונים מסוימים במקום לקרוא ל-API בכל פעם התקבל מיקום של נכס לנייד.
ניהול הצריכה במקומות
אופטימיזציה של הטמעות השלמה אוטומטית לגבי מקומות
כדי לייעל את עלות השימוש בהשלמה האוטומטית של המקום:
להשתמש במסכות של שדות בווידג'טים של השלמה אוטומטית ב-JavaScript, ב-Android וב-iOS כדי להחזיר רק את השדות של נתוני המקום הנחוצים.
אפשרויות החיוב שתבחרו תלויות בתרחיש לדוגמה שלכם. בהתאם לאופן שבו ההטמעה שלכם משתמשת בסשנים של Autcomplete או לא, תחויבו במק"טים של השלמה אוטומטית – לפי בקשה או השלמה אוטומטית – לכל סשן.
לקבלת מידע נוסף והדרכה לבחירת האפשרות המתאימה לתרחיש שלכם לדוגמה, ראו שיטות מומלצות לאופטימיזציה של עלויות באמצעות השלמה אוטומטית.
החזרת נתונים עבור שדות ספציפיים ב'פרטי מקום' ובבקשות ל'חיפוש מקום'
ניתן להתאים אישית בקשות מסוג 'פרטי מקום' ו'חיפוש מקום' כדי להחזיר נתונים לשדות ספציפיים שמשמשים את האפליקציה. השדות האלה מחולקים קטגוריות: בסיסי, יצירת קשר ואטמוספרה. בקשות שלא לציין שדות כלשהם שיקבלו נתונים עבור כל השדות.
החיוב של בקשות מסוג 'פרטי מקום' מבוסס על הסוגים והסכומים של הנתונים המבוקשים. בקשות שלא צוינו בהן שדות כלשהם יחויבו במחיר מלא. למידע נוסף, ראה פרטי מקום וחיפוש מקום.
הוזלת עלויות באמצעות Geocoding API
אם האפליקציה שלכם מטפלת בכתובות מסוג משתמש, הכתובות לפעמים לא חד-משמעית (חסרה, באיות שגוי או שהפורמט שלה שגוי). הבחנה בין כתובות באמצעות השלמה אוטומטית, ולאחר מכן שימוש במזהי המקומות כדי לקבל את מיקומי המקום.
עם זאת, אם יש לך כתובת מדויקת (או קרובה אליה), תוכל לצמצם את על ידי שימוש בקידוד גיאוגרפי במקום בהשלמה אוטומטית. לפרטים נוספים, ראו שיטות מומלצות ליצירת כתובות לקידוד גיאוגרפי.
איך פועלות המכסות בפלטפורמה של מפות Google
בכל ממשקי ה-API שלנו יש מגבלות על מספר הקריאות שכל לקוח יכול לבצע. האלה המכסות מוגדרות לפי דקה. אחרי שמגיעים למכסת השיחות ב-API נתון בעוד דקה, קריאות עתידיות לא יאושרו עד לדקה הבאה.
רק בקשות שבוצעו בהצלחה ובקשות שגורמות לשגיאות שרת נספרות במכסה. בקשות שנכשלו באימות לא נכללות במכסה.
בחלק מממשקי ה-API של מפות Google יש אכיפה לשנייה בנוסף למכסה לדקה לאכיפה. אכיפה זו לשנייה אינה מבטיחה שימוש אחיד את כל הדקה, והיא לא תמנע מכם להגיע למכסת השימוש בדקה הזאת. זה מונע מכם לנצל את כל המכסה שנייה או שתיים מתוך כל דקה נתונה, ומגינה עליך מפני שיבושים בשירות במקרה של עלייה פתאומית בשימוש. כדי להתמודד עם ההבדלים האלה באכיפה, לתכנן את השימוש במכסות ואת הדרישות באמצעות חישוב ממוצע של השימוש ב-QPM בכל ה-QPS.
ממשקי ה-API של GMP שבהם חלה האכיפה הזו לשנייה הם Directions API, Distance Matrix API, liftion API, Geocoding API, Places API ו-Roads API.