מדריך אופטימיזציה

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

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

אבטחה

סקירת שיטות מומלצות לאבטחה

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

שימוש במפתחות API כדי לגשת לממשקי ה-API של מפות Google

מפתחות API הם שיטת האימות המועדפת לגישה אל ממשקי API של מפות Google. בשלב זה עדיין יש תמיכה במזהי לקוחות, אבל מפתחות API תומכים באמצעי בקרה מדויקים יותר, ואפשר להתאים אותם לכתובות IP ספציפיות, לכתובות IP ולערכות SDK לנייד (Android ו-iOS). למידע על יצירה ואבטחת מפתח API, היכנסו לדף "שימוש במפתח API&quot: לכל API או SDK. (לדוגמה, כדי להיכנס ל-API של מפות Google, היכנסו לדף בנושא שימוש במפתח API).

ביצועים

שימוש בהשהיה מעריכית כדי לטפל בשגיאות

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

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

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

יש לשלוח בקשות לממשקי API הכוללים אינטראקציה של משתמש רק על פי דרישה. כלומר, משתמשי הקצה צריכים לבצע פעולה (למשל, on-click) כדי לשלוח את הבקשה ל-API, ואז להשתמש בתוצאות לטעינה של מפה, להגדיר יעד או להציג מידע מתאים. שימוש בגישה על פי דרישה מונע בקשות לא נחוצות לממשקי ה-API, ומפחית את צריכת ה-API.

הימנעות מהצגת תוכן של שכבת-על כשמפה זזה

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

הימנעות מפעולות אינטנסיביות ב-Draw שיטות

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

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

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

שימוש בתמונות של רשת נקודות עבור סמנים

תוכלו להשתמש בתמונות רסטר, כמו תמונות בפורמט PNG או JPG. כשתוסיפו סמנים כדי לזהות מיקום במפה. הימנעו משימוש בתמונות גרפיות (SVG) מסוג Scalable Vector, מפני שרינדור תמונות SVG יכול לגרום לעיכוב בהצגת המפה.

אופטימיזציה של סמנים

אופטימיזציה משפרת את הביצועים על ידי עיבוד של סמנים רבים כרכיב סטטי אחד. האפשרות הזו שימושית במקרים שבהם יש צורך במספר גדול של סמנים. כברירת מחדל, ה-API של מפות Google יקבע אם תתבצע אופטימיזציה של סמן כלשהו. כאשר יש מספר גדול של סמנים, Maps JavaScript API ינסה לעבד סמנים עם אופטימיזציה. לא ניתן לבצע אופטימיזציה של כל הסמנים. במצבים מסוימים, ייתכן שה-API של מפות Google יצטרך לעבד סמנים ללא אופטימיזציה. השבתת עיבוד אופטימלי של קובצי GIF מונפשים או קובצי PNG, או כשצריך לעבד כל סמן כרכיב DOM נפרד.

יצירת אשכולות לניהול תצוגת הסמן

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

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

צריכה

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

  • הגדר התראת תקציב כדי לעקוב אחר הגדלת העלויות לקראת סכום מסוים. הגדרת תקציב אינה מגבילה את השימוש ב-API – היא מתריעה רק כשהעלויות שלכם מגיעות לסכום שציינתם.
  • הקצו את השימוש היומי ב-API כדי לנהל את העלויות של ממשקי API לחיוב. כשמגדירים תקרות לבקשות ליום, אפשר להגביל את העלויות. משתמשים במשוואה פשוטה כדי לקבוע את המכסה היומית, בהתאם לסכום שרוצים להוציא: (עלות חודשית/מחיר לכל אחד )/30 = בקשות ליום (לפי ממשק API אחד). היישום הספציפי שלך עשוי להשתמש במספר ממשקי API לחיוב, לכן עליך לשנות את המשוואה לפי הצורך. קרדיט בסך 200 דולר ארה"ב למפות Google זמין מדי חודש, לכן רצוי לחשב אותו.
  • אפשר להשתמש בכמה פרויקטים כדי לבודד, לתעדף ולעקוב אחר השימוש. לדוגמה, נניח שאתם משתמשים ב-API של הפלטפורמה של מפות Google באופן קבוע בבדיקות שלכם. יצירת פרויקט נפרד לבדיקה, עם מכסות משלו ומפתחות API, מאפשרת לכם לבצע בדיקה יסודית תוך שמירה על רמה גבוהה של הפתעה.

ניהול הצריכה במפות

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

שימוש בתמונות סטטיות

בקשות שמשתמשות בתמונות דינמיות (מפות דינמיות ו-Street View דינמי) עולות יותר מאשר מפות סטטיות ו-Street View סטטי. אם אתם לא צופים את האינטראקציה של המשתמשים עם המפה או Street View (זום או הזזת התצוגה), השתמשו בגרסאות הסטטיות של ממשקי ה-API האלה.

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

שימוש ב-API של מפות Google

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

שימוש בערכות SDK של מפות לנייד עבור אפליקציות לנייד

עבור אפליקציות לנייד, השתמשו ב-Maps SDK ל-Android או ב-SDK ל-iOS בעת הצגת מפה. השתמשו ב-Maps Static API או ב-Maps JavaScript API כאשר הדרישות מבוטלות באמצעות ערכות ה-SDK לנייד.

ניהול הצריכה בנתיבים

הגבלת ציוני דרך ב-DIRECTION API

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

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

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

ארגומנט האופטימיזציה ממיין את ציוני הדרך כדי להבטיח ניתוב אופטימלי, כלומר הנסיעה מ-A ל-E היא חוויה טובה יותר בעת ביצוע אופטימיזציה (A-B-C-D-E) לעומת הרצף האקראי של מסלול שאינו אופטימלי (כגון A-D-B-C-E).

שימוש במודלים של תנועה בזמן אמת ב-DIRECTION API וב- חוק מטריצת המרחקים

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

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

שימוש בנתיב שנסע בו; הכביש הקרוב ביותר כאשר נתוני ה-GPS לא מדויקים

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

מיקומים של מגבלת מהירות לדגימה במרווחי זמן של 5-15 דקות

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

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

ניהול הצריכה ב'מקומות'

אופטימיזציה של הטמעות השלמה אוטומטית של מקומות

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

  • משתמשים במסכות שדות בווידג'טים של ההשלמה האוטומטית של JavaScript, Android ו-iOS כדי להחזיר רק את שדות הנתונים של המקומות הדרושים.

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

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

נתונים חוזרים לשדות ספציפיים ב'פרטי מקום' ובבקשות 'חיפוש מקום'

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

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

הפחתת עלויות באמצעות ממשק ה-API של Geocoding

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

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

איך פועלות המכסות של הפלטפורמה של מפות Google

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

רק בקשות מוצלחות ובקשות שמובילות לשגיאות בחיבור לשרת נלקחות בחשבון במסגרת המכסה. בקשות שנכשלו באימות לא נספרות כחלק מהמכסה.

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

ממשקי ה-API של GMP שכוללים את האכיפה הזו לשנייה הם: API API, מרחק מטריצת API, Elevation API, geocoding API, APIs של מקומות ו-דרכים.

הערכת העלויות של כל מוצר ב-GMP API, על סמך נפח הבקשות הכולל.