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

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

सुरक्षा

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

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

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

Google Maps API को ऐक्सेस करने के लिए, पुष्टि करने का सबसे पसंदीदा तरीका एपीआई पासकोड है. फ़िलहाल, क्लाइंट आईडी का इस्तेमाल किया जा सकता है. हालांकि, एपीआई पासकोड की मदद से, सुरक्षा से जुड़े बेहतर कंट्रोल किए जा सकते हैं. साथ ही, इन्हें खास वेब पते, आईपी पते, और मोबाइल 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 के एपीआई का नियमित तौर पर इस्तेमाल किया है. टेस्टिंग के लिए अलग से एक प्रोजेक्ट बनाकर, अपने कोटे और एपीआई पासकोड का इस्तेमाल किया जा सकता है. इससे, अचानक ज़्यादा खर्च होने से बचा जा सकता है.

Maps में डेटा खर्च को मैनेज करना

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

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

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

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

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

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

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

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

Routes में डेटा खर्च को मैनेज करना

Directions API के वे रास्ते सीमित करना जिन पर रुकना है

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

सबसे सही रास्ता तय करने के लिए, Directions API के ऑप्टिमाइज़ेशन का इस्तेमाल करना

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

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

Directions API और Distance Matrix API में, रीयल-टाइम ट्रैफ़िक मॉडल का इस्तेमाल करना

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

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

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

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

स्पीड लिमिट वाली जगहों के सैंपल, 5 से 15 मिनट के अंतराल पर लेने की सुविधा

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

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

Places में डेटा खर्च को मैनेज करना

किसी जगह के शुरुआती अक्षर लिखने पर पूरा नाम सुझाने की सुविधा को ऑप्टिमाइज़ करना

किसी जगह के शुरुआती अक्षर लिखने पर पूरा नाम सुझाने की सुविधा के इस्तेमाल की लागत को ऑप्टिमाइज़ करने के लिए:

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

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

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

जगह की जानकारी और जगह खोजने के अनुरोधों में, चुनिंदा फ़ील्ड के लिए डेटा दिखाना

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

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

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

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

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

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

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

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

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