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

संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

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

सुरक्षा

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

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

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 एपीआई का इस्तेमाल करते हैं. जांच के लिए एक अलग प्रोजेक्ट बनाकर, इसके कोटा और एपीआई कुंजियों की मदद से, आप अचानक होने वाले खर्चों से खुद को बचाते हुए पूरी तरह से टेस्ट कर सकते हैं.

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

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

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

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

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

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

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

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

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

रास्तों में खर्च को मैनेज करना

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

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

बेहतर रूटिंग के लिए Directions API ऑप्टिमाइज़ेशन का इस्तेमाल करना

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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