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

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

सुरक्षा

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

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

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

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

परफ़ॉर्मेंस

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

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

एक्स्पोनेंशियल बैकऑफ़, 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 में ऊर्जा के इस्तेमाल को मैनेज करना

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

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

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

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

Maps एंबेड एपीआई का इस्तेमाल करना

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

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

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

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

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

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

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

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

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

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

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

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

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

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

सैंपल लेने की स्पीड की सीमा, 5 से 15 मिनट के अंतराल पर रखें

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

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

जगहों के लिए डेटा का इस्तेमाल मैनेज करना

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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