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

इस गाइड में ऐसी कई रणनीतियों के बारे में बताया गया है जिनकी मदद से, सुरक्षा, परफ़ॉर्मेंस, और इस्तेमाल के मामले में, 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 के लिए ऑप्टिमाइज़ की गई रेंडरिंग बंद करें या जब हर मार्कर को एक अलग डीओएम एलिमेंट के तौर पर रेंडर करना ज़रूरी हो.

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

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

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

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

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

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

Maps में उपभोग मैनेज करना

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

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

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

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

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

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

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

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

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

निर्देश एपीआई वेपॉइंट सीमित करना

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

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

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

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

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

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

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

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

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

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

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

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

Places में उपभोग का प्रबंधन करना

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

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

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

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

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

जगह की जानकारी और जगह की जानकारी खोजने के अनुरोधों में मौजूद खास फ़ील्ड का डेटा

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

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

जियोकोडिंग एपीआई का इस्तेमाल करके लागत कम करना

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

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

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

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

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

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

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

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