ऑप्टिमाइज़ेशन गाइड

इस गाइड में सुरक्षा, परफ़ॉर्मेंस, और इस्तेमाल के मामलों में Google Maps API के इस्तेमाल को ऑप्टिमाइज़ करने की कई रणनीतियों के बारे में बताया गया है.

सुरक्षा

सुरक्षा के सबसे सही तरीकों की समीक्षा करना

एपीआई पासकोड, प्रोजेक्ट पर आधारित क्रेडेंशियल होते हैं. इनके लिए, यूज़र आईडी और पासवर्ड जैसी ही सावधानियां बरतनी चाहिए. एपीआई की सुरक्षा के सबसे सही तरीके देखें. इससे आपकी कुंजियों को अनचाहे इस्तेमाल से बचाने में मदद मिलेगी. ऐसा होने पर, आपके खाते में कोटा का गलत इस्तेमाल हो सकता है और आपसे अनचाहे शुल्क लग सकते हैं.

Maps API को ऐक्सेस करने के लिए एपीआई कुंजियों का इस्तेमाल करना

Google Maps API के एपीआई ऐक्सेस करने के लिए, पुष्टि करने का सबसे पसंदीदा तरीका, एपीआई पासकोड है. फ़िलहाल, Client-ID का इस्तेमाल किया जा सकता है. हालांकि, एपीआई पासकोड पर बेहतर सुरक्षा कंट्रोल काम करते हैं. साथ ही, इन्हें चुनिंदा वेब पतों, आईपी पतों, और मोबाइल SDK टूल (Android और iOS) के साथ काम करने के लिए ट्यून किया जा सकता है. एपीआई पासकोड बनाने और उसे सुरक्षित करने के बारे में जानकारी के लिए, हर एपीआई या SDK टूल के "एपीआई पासकोड का इस्तेमाल करना" पेज पर जाएं. (उदाहरण के लिए, Maps JavaScript API के लिए, एपीआई पासकोड का इस्तेमाल करना पेज पर जाएं.)

परफ़ॉर्मेंस

गड़बड़ियों को हैंडल करने के लिए एक्स्पोनेंशियल बैकऑफ़ का इस्तेमाल करना

अगर एपीआई को बहुत कम समय में कॉल करने (जैसे कि क्यूपीएस में गड़बड़ी) की वजह से, आपके ऐप्लिकेशन में गड़बड़ियां होती हैं, तो अनुरोधों को प्रोसेस होने देने के लिए, एक्सपोनेन्शियल बैकऑफ़ का इस्तेमाल करें.

एक्स्पोनेंशियल बैकऑफ़, 500 के दशक की गड़बड़ियों के लिए सबसे ज़्यादा फ़ायदेमंद है. ज़्यादा जानकारी के लिए, प्रॉडक्ट लौटाने के एचटीटीपी स्टेटस कोड मैनेज करना देखें.

खास तौर पर, अपनी क्वेरी की रफ़्तार को घटाएं या बढ़ाएं. अपने कोड में, अलग-अलग क्वेरी के बीच S सेकंड का इंतज़ार करें. अगर क्वेरी के नतीजे में अब भी क्यूपीएस की गड़बड़ी मिलती है, तो इंतज़ार का समय दोगुना करें. इसके बाद, दूसरी क्वेरी भेजें. इंतज़ार में लगने वाले समय में तब तक बदलाव करते रहें, जब तक बिना किसी गड़बड़ी के क्वेरी वापस नहीं मिल जाती.

मांग पर उपयोगकर्ता-इंटरैक्शन के अनुरोध भेजना

ऐसे एपीआई के अनुरोध जिनमें उपयोगकर्ता इंटरैक्शन शामिल हो, सिर्फ़ मांग पर भेजे जाने चाहिए. इसका मतलब है कि एपीआई अनुरोध शुरू करने के लिए, असली उपयोगकर्ता को कोई कार्रवाई (जैसे कि on-click) करने का इंतज़ार करना और उसके बाद मैप लोड करने, डेस्टिनेशन सेट करने या सही जानकारी दिखाने के लिए, नतीजों का इस्तेमाल करना. मांग पर उपलब्ध तरीका इस्तेमाल करने से, एपीआई को किए जाने वाले ग़ैर-ज़रूरी अनुरोधों से बचा जा सकता है. इससे एपीआई की ज़रूरत में कमी आती है.

मैप के मूव होने पर ओवरले कॉन्टेंट दिखाने से बचना

मैप पर कस्टम ओवरले कॉन्टेंट को उस समय दिखाने के लिए Draw() का इस्तेमाल करने से बचें जब उपयोगकर्ता मैप को मूव कर रहा हो. हर बार जब कोई उपयोगकर्ता मैप को मूव करता है, तो मैप को फिर से ड्रॉ किया जाता है. इस वजह से, मैप पर ओवरले कॉन्टेंट को एक ही समय पर डालने से लैग या विज़ुअल रुकावट पैदा हो सकती है. उपयोगकर्ता के पैन या ज़ूम करना बंद करने के बाद ही मैप में ओवरले कॉन्टेंट जोड़ें या हटाएं.

Draw तरीकों में बहुत ज़्यादा कामों से बचना

सामान्य नियम के तौर पर, Draw() तरीके में परफ़ॉर्मेंस पर ज़्यादा असर डालने वाली नॉन-ड्रॉइंग कार्रवाइयों से बचना बेहतर है. उदाहरण के लिए, अपने Draw() वाले कोड में इन चीज़ों से बचें:

• ऐसी क्वेरी जिन पर ज़्यादा कॉन्टेंट दिखता है.
• डेटा में कई बदलाव दिख रहे हैं.
• कई डॉक्यूमेंट ऑब्जेक्ट मॉडल (DOM) एलिमेंट में बदलाव करना.

इन कार्रवाइयों से परफ़ॉर्मेंस धीमी हो सकती है. साथ ही, मैप रेंडर होने के बाद, विज़ुअल में रुकावट या रुकावट पैदा हो सकती है.

मार्कर के लिए रास्टर इमेज का इस्तेमाल करना

मैप पर किसी जगह की पहचान करने के लिए मार्कर जोड़ते समय, रास्टर इमेज का इस्तेमाल करें, जैसे कि .PNG या .JPG फ़ॉर्मैट की इमेज. स्केलेबल वेक्टर ग्राफ़िक (SVG) इमेज का इस्तेमाल करने से बचें, क्योंकि SVG इमेज को रेंडर करने में देरी हो सकती है. जब मैप को फिर से बनाया जाता है, तब ऐसा होता है.

मार्कर ऑप्टिमाइज़ करना

ऑप्टिमाइज़ेशन, कई मार्कर को सिंगल स्टैटिक एलिमेंट के तौर पर रेंडर करके, परफ़ॉर्मेंस को बेहतर बनाता है. यह ऐसे मामलों में उपयोगी होता है जहां बहुत सारे मार्कर की ज़रूरत होती है. डिफ़ॉल्ट रूप से, Maps JavaScript API यह तय करेगा कि मार्कर को ऑप्टिमाइज़ किया जाएगा या नहीं. मार्कर की संख्या ज़्यादा होने पर, Maps JavaScript API, ऑप्टिमाइज़ेशन के साथ मार्कर रेंडर करने की कोशिश करेगा. सभी मार्कर ऑप्टिमाइज़ नहीं किए जा सकते. कुछ मामलों में, हो सकता है कि Maps JavaScript API को ऑप्टिमाइज़ किए बिना मार्कर रेंडर करने की ज़रूरत पड़े. ऐनिमेट किए गए GIF या PNG के लिए या जब हर मार्कर को एक अलग DOM एलिमेंट के रूप में रेंडर किया जाना ज़रूरी हो, तब ऑप्टिमाइज़ की गई रेंडरिंग को बंद करें.

मार्कर डिसप्ले को मैनेज करने के लिए क्लस्टर बनाए जा रहे हैं

मैप पर जगहों को पहचानने के लिए मार्कर के डिसप्ले मैनेज करने में मदद पाने के लिए, मार्कर क्लस्टर लाइब्रेरी का इस्तेमाल करके मार्कर क्लस्टर बनाएं. मार्कर क्लस्टर लाइब्रेरी में ये विकल्प शामिल हैं:

• क्लस्टर में एक साथ ग्रुप करने के लिए, मार्कर की संख्या तय करने के लिए ग्रिड का साइज़.
• क्लस्टर को दिखाने के लिए, ज़्यादा से ज़्यादा ज़ूम लेवल तय करने के लिए, ज़्यादा से ज़्यादा ज़ूम.
• इमेज के पाथ, ग्राफ़िक इमेज को मार्कर आइकॉन के तौर पर इस्तेमाल करने के लिए.

संगीत का आनंद लेना

अपने बजट की योजना बनाने और अपनी लागतों को कंट्रोल करने के लिए, ये काम करें:

• यह ट्रैक करने के लिए कि आपकी लागतें किसी तय रकम के लिए कैसे बढ़ रही हैं, बजट अलर्ट सेट करें. बजट सेट करने से एपीआई के इस्तेमाल पर कोई असर नहीं पड़ता. यह आपको सिर्फ़ तब सूचना देता है, जब आपकी लागत, तय की गई रकम के आस-पास हो.
• बिल करने लायक एपीआई की लागत मैनेज करने के लिए, अपने हर दिन के एपीआई के इस्तेमाल की सीमा तय करें. हर दिन मिलने वाले अनुरोधों की सीमा तय करके, अपनी लागत को सीमित किया जा सकता है. आपको जो खर्च करना है उसके हिसाब से, हर दिन की बजट सीमा तय करने के लिए, एक आसान समीकरण का इस्तेमाल करें: (हर महीने की लागत/हर एक की कीमत )/30 = हर दिन की सीमा के लिए अनुरोध (एक एपीआई के लिए). आपके लागू किए गए तरीके में, बिल करने लायक कई एपीआई का इस्तेमाल हो सकता है. इसलिए, इक्वेशन में ज़रूरत के मुताबिक बदलाव करें. आपको हर महीने 200 डॉलर का Google Maps API क्रेडिट मिलेगा. इसलिए, इसका हिसाब लगाते समय इस बात का ध्यान रखें.
• अलग-अलग प्रोजेक्ट का इस्तेमाल करें, ताकि डेटा को अलग-अलग रखने, प्राथमिकता देने, और अपने इस्तेमाल को ट्रैक करने में मदद मिल सके. उदाहरण के लिए, मान लें कि आप अपने टेस्ट में Google Maps Platform API का नियमित तौर पर इस्तेमाल करते हैं. टेस्टिंग के लिए एक अलग प्रोजेक्ट बनाकर - उसके कोटा और एपीआई पासकोड की मदद से - अच्छी तरह से टेस्ट किया जा सकता है. इससे आपको अनचाहे खर्च से बचा जा सकता है.

Maps में इस्तेमाल की जानकारी मैनेज करना

मैप के डिसप्ले को ऑप्टिमाइज़ करने के लिए हर पेज में एक ही मैप का इस्तेमाल करना अच्छा तरीका है, क्योंकि उपयोगकर्ता आम तौर पर एक समय में सिर्फ़ एक मैप से इंटरैक्ट करते हैं. आपका ऐप्लिकेशन अलग-अलग डेटा सेट दिखाने के लिए मैप में हेर-फेर कर सकता है. ऐसा, ग्राहक के इंटरैक्शन और ज़रूरतों के हिसाब से किया जाता है.

स्टैटिक इमेज का इस्तेमाल करना

स्टैटिक मैप और स्टैटिक स्ट्रीट व्यू की तुलना में डाइनैमिक इमेज (डाइनैमिक मैप और डाइनैमिक स्ट्रीट व्यू) का इस्तेमाल करने वाले अनुरोधों की लागत ज़्यादा होती है. अगर आपको मैप या स्ट्रीट व्यू के साथ उपयोगकर्ता इंटरैक्शन (ज़ूम या पैन करना) नहीं लगता है, तो इन एपीआई के स्टैटिक वर्शन का इस्तेमाल करें.

थंबनेल - बहुत छोटे मैप और फ़ोटो - स्टैटिक मैप और स्टैटिक Street View के लिए दूसरे अच्छे इस्तेमाल के लिए हैं. इन आइटम का बिल कम दर पर और उपयोगकर्ता के इंटरैक्शन (क्लिक करने पर) पर लिया जाता है. ये उपयोगकर्ताओं को Google Maps के डाइनैमिक वर्शन पर ले जा सकते हैं.

Maps Embed API का इस्तेमाल करना

सिंगल मार्कर या डाइनैमिक मैप के साथ मैप जोड़ने के लिए, Maps Embed API का इस्तेमाल किया जा सकता है. इसके लिए, कोई शुल्क नहीं लिया जाता. उन ऐप्लिकेशन के लिए Maps Embed API का इस्तेमाल करें जहां एक मार्कर और मैप को पसंद के मुताबिक बनाने की ज़रूरत नहीं होती. निर्देश मोड, व्यू मोड या सर्च मोड का इस्तेमाल करने वाले Maps Embed API के अनुरोधों का बिल भेजा जाएगा (ज़्यादा जानकारी के लिए कीमत दिखाने वाली टेबल देखें).

मोबाइल ऐप्लिकेशन के लिए, मोबाइल मैप SDK टूल इस्तेमाल करना

मोबाइल ऐप्लिकेशन के लिए, मैप दिखाते समय Android के लिए Maps SDK या iOS के लिए Maps SDK का इस्तेमाल करें. जब ज़रूरी शर्तें पूरी हो, तो Maps स्टैटिक एपीआई या Maps JavaScript API का इस्तेमाल करें.

रूट में इस्तेमाल को मैनेज करना

दिशा-निर्देश API वेपॉइंट सीमित करना

जब संभव हो, तब किसी क्वेरी में उपयोगकर्ता की एंट्री को ज़्यादा से ज़्यादा 10 वेपॉइंट तक सीमित करें. 10 से ज़्यादा वेपॉइंट वाले अनुरोधों का बिल ज़्यादा दर पर भेजा जाता है.

बेहतर रूटिंग के लिए, निर्देश एपीआई ऑप्टिमाइज़ेशन का इस्तेमाल करना

वेपॉइंट ऑप्टिमाइज़ेशन तर्क का इस्तेमाल करने वाले अनुरोधों को ज़्यादा दर पर बिल किया जाता है. ज़्यादा जानकारी के लिए, वेपॉइंट ऑप्टिमाइज़ करें लेख पढ़ें.

ऑप्टिमाइज़ेशन आर्ग्युमेंट, बेहतर रास्ता पक्का करने के लिए वेपॉइंट को क्रम से लगाता है. इसका मतलब है कि ऑप्टिमाइज़ न किए गए रास्ते (जैसे कि A-D-B-C-E) के रैंडम क्रम के बजाय, ऑप्टिमाइज़ किए जाने (A-B-C-D-E) पर A से E तक की यात्रा करना एक बेहतर अनुभव है.

दिशा-निर्देश एपीआई और दूरी मैट्रिक्स एपीआई में रीयल-टाइम ट्रैफ़िक मॉडल का इस्तेमाल करना

रास्तों के लिए एपीआई और डिस्टेंस मैट्रिक्स एपीआई के जिन अनुरोधों में रीयल-टाइम ट्रैफ़िक मॉडल शामिल होते हैं उन्हें ज़्यादा दर पर बिल भेजा जाता है. जाने का समय now पर सेट करके, रीयल-टाइम ट्रैफ़िक मॉडल चालू किए जाते हैं.

अगर ट्रैफ़िक मॉडल को किसी अनुरोध में शामिल नहीं किया जाता है, तो नतीजे सिर्फ़ मुख्य चीज़ों के आधार पर दिखाए जाते हैं. जैसे, सड़कें, दूरी, और रफ़्तार की सीमाएं.

जीपीएस डेटा सटीक न होने पर, सबसे नज़दीकी सड़क और तय किए गए रास्ते का इस्तेमाल करना

Maps Roads API की सुविधाएं, तय किया गया रास्ता और सबसे नज़दीकी सड़क, बेहतर टियर में शामिल हैं. इनके लिए आपसे ज़्यादा शुल्क लिया जाता है. इन सुविधाओं का इस्तेमाल उन जगहों पर करें जहां जीपीएस डेटा सटीक नहीं है और Roads API सही सड़क का पता लगाने में आपकी मदद कर सकता है. रोड एपीआई की एक और सुविधा, स्पीड की सीमाएं सिर्फ़ ऐसेट ट्रैकिंग के ग्राहकों के लिए उपलब्ध है.

जगहों के सैंपल 5 से 15 मिनट के अंतराल में लिए जा सकते हैं

Maps Roads API की स्पीड लिमिट सेवा को मिलने वाले कॉल की संख्या कम करने के लिए, 5 से 15 मिनट के इंटरवल में अपनी ऐसेट की जगह की जानकारी का सैंपल लें. सटीक वैल्यू इस बात पर निर्भर करती है कि कोई ऐसेट कितनी तेज़ी से यात्रा कर रही है. अगर कोई ऐसेट स्थिर है, तो एक लोकेशन सैंपल काफ़ी होता है. कई बार कॉल करने की ज़रूरत नहीं है.

इंतज़ार का समय कम करने के लिए, मोबाइल ऐसेट की जगह की जानकारी मिलने पर हर बार एपीआई को कॉल करने के बजाय, कुछ डेटा इकट्ठा करने के बाद स्पीड लिमिट सेवा को कॉल करें.

'जगहें' में इस्तेमाल को मैनेज करना

स्थान ऑटोकंप्लीट लागू करने की सुविधा को ऑप्टिमाइज़ करना

स्थान ऑटोकंप्लीट का उपयोग करने की लागत को ऑप्टिमाइज़ करने के लिए:

• JavaScript, Android, और iOS ऑटोकंप्लीट विजेट में फ़ील्ड मास्क का इस्तेमाल करें. इससे आपको सिर्फ़ अपनी ज़रूरत के मुताबिक जगह के डेटा फ़ील्ड दिखाने में मदद मिलती है.

• बिलिंग विकल्प चुनें, यह आपके इस्तेमाल के उदाहरण पर निर्भर करता है. आपने जो लागू किया है उसके आधार पर, ऑटोकंप्लीट सेशन का इस्तेमाल किया जाता है या नहीं, आपसे शुल्क लिया जाएगा. जैसे- ऑटोकंप्लीट की सुविधा - हर अनुरोध के लिए या ऑटोकंप्लीट की सुविधा - हर सेशन के हिसाब से SKU के लिए.

अपने इस्तेमाल के हिसाब से सही विकल्प चुनने के बारे में ज़्यादा जानकारी और दिशा-निर्देश पाने के लिए, डेटा को अपने-आप पूरा करने की लागत को ऑप्टिमाइज़ करने के सबसे सही तरीके देखें.

स्थान विवरण और स्थान खोज अनुरोधों में विशिष्ट फ़ील्ड के लिए डेटा लौटाना

आप अपने ऐप्स में उपयोग किए गए विशिष्ट फ़ील्ड के लिए डेटा लौटाने के लिए स्थान विवरण और स्थान खोज अनुरोधों को कस्टमाइज़ कर सकते हैं. इन फ़ील्ड को कैटगरी में बांटा जाता है: बुनियादी, संपर्क, और वायुमंडल. जिन अनुरोधों में किसी फ़ील्ड के बारे में जानकारी नहीं दी जाती है उन्हें सभी फ़ील्ड का डेटा मिलेगा.

स्थान विवरण अनुरोधों के लिए बिलिंग, अनुरोध किए गए डेटा के प्रकार और मात्रा पर आधारित होती है. जिन अनुरोधों में किसी भी फ़ील्ड के बारे में नहीं बताया जाता, उनका बिल पूरी दर से भेजा जाएगा. ज़्यादा जानकारी के लिए, जगह की जानकारी और जगह की जानकारी खोजने की सुविधा देखें.

Geocoding API का इस्तेमाल करके लागत कम करना

अगर आपका ऐप्लिकेशन, उपयोगकर्ता के टाइप किए गए पतों को हैंडल करता है, तो कभी-कभी पते साफ़ तौर पर नहीं दिखते. जैसे, अधूरा, गलत स्पेलिंग या खराब फ़ॉर्मैट में. ऑटोकंप्लीट की सुविधा का इस्तेमाल करके, पतों को साफ़ करें. इसके बाद, जगह की जानकारी पाने के लिए जगह की जानकारी के आईडी का इस्तेमाल करें.

अगर आपका पता या उसके आस-पास का पता सटीक है, तो अपने-आप पूरा होने के बजाय जियोकोडिंग का इस्तेमाल करके लागत कम की जा सकती है. ज़्यादा जानकारी के लिए, जियोकोडिंग के पते इस्तेमाल करने के सबसे सही तरीके लेख पढ़ें.

Google Maps Platform कोटा कैसे काम करता है

हमारे सभी एपीआई ने एक सीमा तय की है कि हर ग्राहक कितने कॉल कर सकता है. इन कोटा को हर मिनट के हिसाब से कॉन्फ़िगर किया जाता है. एक मिनट में, दिए गए एपीआई पर कॉल की तय सीमा पूरी होने के बाद, अगले मिनट तक आने वाले कॉल स्वीकार नहीं किए जाएंगे.

कोटा में सिर्फ़ ऐसे अनुरोध और अनुरोध शामिल किए जाते हैं जिनकी वजह से सर्वर में गड़बड़ियां होती हैं. पुष्टि न कर पाने वाले अनुरोधों को कोटे में नहीं गिना जाता.

कई Maps API में हर मिनट के कोटा को लागू करने के अलावा, हर सेकंड के लिए नीति उल्लंघन ठीक करने का तरीका (एनफ़ोर्समेंट) भी मौजूद है. हर सेकंड के हिसाब से लागू होने वाली यह नीति, न तो पूरे एक मिनट में एक जैसे इस्तेमाल की गारंटी देती है और न ही आपको उस मिनट के लिए, डेटा इस्तेमाल करने का कोटा पूरा करने से रोकती है. यह आपको किसी भी दिए गए पहले एक या दो मिनट में आपके कोटा का पूरा इस्तेमाल करने से रोकता है और अचानक इस्तेमाल में अचानक बढ़ोतरी होने पर सेवा में रुकावट से आपकी सुरक्षा करता है. नीति उल्लंघन ठीक करने के तरीके (एनफ़ोर्समेंट) के इन अंतरों से निपटने के लिए, अपने कोटा के इस्तेमाल और उससे जुड़ी ज़रूरी शर्तों का प्लान बनाएं. इसके लिए, क्यूपीएस में अपने क्यूपीएम के इस्तेमाल का औसत निकालें.

हर सेकंड में नीति उल्लंघन ठीक करने के इस तरीके का इस्तेमाल करने वाले GMP एपीआई में दिशा-निर्देश एपीआई, दूरी मैट्रिक्स एपीआई, एलिवेशन एपीआई, जियोकोडिंग एपीआई, जगह एपीआई, और सड़कें एपीआई शामिल हैं.

अनुरोध की कुल संख्या के हिसाब से, GMP API वाले किसी भी प्रॉडक्ट की कीमत का अनुमान लगा सकता है.