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

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

אבטחה

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

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

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

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

ביצועים

שימוש בהשהיה מעריכית לפני ניסיון חוזר (exponential backoff) לטיפול בשגיאות

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

השהיה מעריכית לפני ניסיון חוזר (exponential backoff) שימושית במיוחד לשגיאות בטווח 500. למידע נוסף, קראו את המאמר טיפול בקודי סטטוס חזרה של HTTP.

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

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

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

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

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

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

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

• שאילתות שמחזירות כמות גדולה של תוכן.
• שינויים רבים בנתונים המוצגים.
• מניפולציה של רכיבי Document Object Model (DOM) רבים.

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

שימוש בתמונות רסטר לסימונים

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

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

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

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

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

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

צריכה

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