يوضّح هذا الدليل العديد من الاستراتيجيات لتحسين استخدام واجهات برمجة التطبيقات في "خرائط Google" من حيث الأمان والأداء والاستهلاك.
الأمان
مراجعة أفضل ممارسات الأمان
مفاتيح واجهة برمجة التطبيقات هي بيانات اعتماد تركّز على المشروع وتستحق الاحتياطات نفسها مثل أرقام تعريف المستخدمين وكلمات المرور. راجِع أفضل الممارسات المتعلقة بأمان واجهة برمجة التطبيقات لتأمين مفاتيحك من الاستخدام غير المقصود الذي قد يؤدي إلى استخدام حصة غير مستحقة وفرض رسوم غير متوقّعة على حسابك.
استخدام مفاتيح واجهة برمجة التطبيقات للوصول إلى واجهات برمجة تطبيقات "خرائط Google"
مفاتيح واجهة برمجة التطبيقات هي طريقة المصادقة المفضّلة للوصول إلى واجهات برمجة تطبيقات "خرائط Google". على الرغم من أنّ استخدام معرّفات العملاء لا يزال متاحًا حاليًا، فإنّ مفاتيح واجهة برمجة التطبيقات تتيح عناصر تحكّم أكثر دقة في الأمان ويمكن ضبطها للعمل مع عناوين ويب وعناوين IP ومجموعات تطوير البرامج (SDK) للأجهزة الجوّالة (Android وiOS) محدّدة. للحصول على معلومات عن إنشاء مفتاح واجهة برمجة التطبيقات وتأمينه، انتقِل إلى صفحة "استخدام مفتاح واجهة برمجة التطبيقات" لكل واجهة برمجة تطبيقات أو حزمة تطوير برامج. (على سبيل المثال، بالنسبة إلى واجهة برمجة التطبيقات JavaScript لخرائط Google، يُرجى الانتقال إلى صفحتها حول استخدام مفتاح واجهة برمجة التطبيقات).
الأداء
استخدام خوارزمية الرقود الأسي الثنائي للتعامل مع الأخطاء
إذا واجهت تطبيقاتك أخطاءً بسبب المحاولات المفرطة للاتصال بواجهة برمجة التطبيقات خلال فترة زمنية قصيرة، مثل أخطاء الحصة، ننصحك باستخدام الوقت المتزايد للانتظار للسماح بمعالجة الطلبات.
يكون التوقّف التدرّجي بين عمليات إعادة المحاولة مفيدًا بشكلٍ كبير في حال حدوث أخطاء من الفئة 500. لمزيد من المعلومات، راجِع مقالة معالجة رموز حالة HTTP.
وعلى وجه التحديد، عليك تعديل وتيرة طلبات البحث. في الرمز، أضِف
فترة انتظار تبلغ S ثانية بين طلبات البحث. إذا استمرّ طلب البحث في ناتج
بخطأ في الحصة، ضاعِف فترة الانتظار ثم أرسِل طلب بحث آخر. واصِل تعديل فترة الانتظار إلى أن يظهر الاستعلام بدون خطأ.
إرسال طلبات التفاعل مع المستخدمين عند الطلب
يجب عدم إرسال طلبات إلى واجهات برمجة التطبيقات التي تتضمّن تفاعل المستخدمين إلا عند الطلب.
ويعني ذلك الانتظار إلى أن ينفِّذ المستخدم النهائي إجراءً (مثل on-click)
لبدء طلب واجهة برمجة التطبيقات، ثم استخدام النتائج لتحميل خريطة أو ضبط
وجهة أو عرض المعلومات المناسبة. باستخدام نهج عند الطلب،
يمكن تجنُّب الطلبات غير الضرورية إلى واجهات برمجة التطبيقات، ما يقلل من معدّل استخدامها.
تجنُّب عرض المحتوى المتراكب عند تحريك الخريطة
تجنَّب استخدام Draw() لعرض محتوى تراكب مخصّص على خريطة في الوقت نفسه الذي قد يتحرّك فيه المستخدم على الخريطة. بما أنّه تتم إعادة رسم الخريطة في كل مرة
يحرك فيها المستخدم الخريطة، يمكن أن يؤدي وضع محتوى مركّب على الخريطة في الوقت نفسه إلى
تأخُّر التحميل أو الظهور بشكل متقطّع. لا تُضِف أو تُزِل المحتوى المتراكب من ملف تضاريس إلا بعد أن يتوقف المستخدم عن التمرير أو التصغير/التكبير.
تجنُّب العمليات المكثّفة في طرق Draw
كقاعدة عامة، من الممارسات الجيدة تجنُّب العمليات التي تتطلّب أداءً مرتفعًا
وغير المتعلّقة بالرسم في طريقة Draw(). على سبيل المثال، تجنَّب
ما يلي في رمز طريقة Draw():
- الاستعلامات التي تعرض قدرًا كبيرًا من المحتوى
- تم إجراء العديد من التغييرات على البيانات المعروضة.
- التلاعب بالعديد من عناصر نموذج تمثيل المستندات (DOM)
يمكن أن تؤدي هذه العمليات إلى إبطاء الأداء وظهور تأخير أو تقطُّع في المحتوى المرئي عند عرض الخريطة.
استخدام الصور النقطية للعلامات
استخدِم الصور المركّبة، مثل الصور بتنسيق .PNG أو .JPG، عند إضافة محدّدات مواقع لتحديد موقع جغرافي على الخريطة. تجنَّب استخدام صور رسومات SVG، لأنّ عرض صور SVG قد يؤدي إلى حدوث تأخير عند إعادة رسم المخطّط.
تحسين العلامات
يُحسِّن التحسين الأداء من خلال عرض العديد من العلامات كعنصر static واحد. ويُعدّ ذلك مفيدًا في الحالات التي يلزم فيها استخدام عدد كبير من العلامات. ستتّخذ واجهة برمجة تطبيقات JavaScript لـ "خرائط Google" قرارًا تلقائيًا بشأن ما إذا كان سيتم تحسين علامة. عند توفّر عدد كبير من العلامات، ستحاول واجهة برمجة التطبيقات Maps JavaScript API عرض العلامات مع تحسين الأداء. لا يمكن تحسين جميع العلامات، ففي بعض الحالات، قد تحتاج واجهة برمجة التطبيقات Maps JavaScript API إلى عرض العلامات بدون تحسين. أوقِف العرض المحسّن لصور GIF أو PNG المتحركة، أو عندما يجب عرض كل علامة كعنصر DOM منفصل.
إنشاء مجموعات لإدارة عرض العلامات
للمساعدة في إدارة عرض العلامات لتحديد المواقع الجغرافية على الخريطة، أنشئ مجموعة علامات باستخدام مكتبة Marker Clusterer. تتضمّن مكتبة أداة تجميع محدّدات المواقع خيارات لما يلي:
- حجم الشبكة، لتحديد عدد العلامات التي سيتم تجميعها معًا في مجموعة
- الحد الأقصى للتكبير، لتحديد الحد الأقصى لمستوى التكبير الذي يتم فيه عرض المجموعة
- مسارات الصور، لاستخدامها كرموز علامات في صور الرسومات
مشاهدة المحتوى
لوضع ميزانيتك والتحكّم في تكاليفك، اتّبِع الخطوات التالية:
- ضبط تنبيه بشأن الميزانية
لتتبُّع معدّل زيادة تكاليفك إلى مبلغ معيّن لا يؤدي ضبط ميزانية
إلى وضع حدّ أقصى لاستخدام واجهة برمجة التطبيقات، بل يُرسِل إليك تنبيهًا فقط عندما تقترب تكاليفك من المبلغ
الذي حدّدته.
- حدِّد الحد الأقصى لاستخدامك اليومي لواجهات برمجة التطبيقات لإدارة تكاليف واجهات برمجة التطبيقات القابلة للفوترة. يمكنك الحدّ من تكاليفك من خلال ضبط حدود الطلبات في اليوم. استخدِم معادلة بسيطة لتحديد الحدّ الأقصى للطلبات اليومية، استنادًا إلى المبلغ الذي تريد إنفاقه: (تكلفة الشهرية/السعر لكل طلب )/30 = الحدّ الأقصى للطلبات في اليوم (لواجهة برمجة تطبيقات واحدة). قد يستخدم التنفيذ المحدّد واجهات برمجة تطبيقات متعددة خاضعة للفوترة، لذا عليك تعديل المعادلة حسب الحاجة. يتوفّر رصيد بقيمة 200 دولار أمريكي في Google Maps API كل شهر، لذا ضَع ذلك في اعتبارك عند إجراء عمليات الحساب.
- يمكنك استخدام مشاريع متعددة لتحديد استخدامك وتحديد أولوياته وتتبّعه. على سبيل المثال، لنفترض أنّك تستخدِم واجهات برمجة تطبيقات Google Maps Platform بانتظام في اختباراتك. من خلال إنشاء مشروع منفصل للاختبار - مع حصص ومقاييس خاصة به ومفاتيح واجهة برمجة التطبيقات - يمكنك إجراء اختبار شامل مع تجنُّب الزيادة المفاجئة في الإنفاق.
إدارة الاستهلاك في "خرائط Google"
يُعدّ استخدام خريطة واحدة لكل صفحة طريقة جيدة لتحسين عرض الخرائط، لأنّه يتفاعل المستخدمون بشكل عام مع خريطة واحدة فقط في كل مرة. يمكن لتطبيقك تعديل الخريطة لعرض مجموعات بيانات مختلفة، استنادًا إلى تفاعل العميل واحتياجاته.
استخدام الصور الثابتة
إنّ الطلبات التي تستخدِم صورًا ديناميكية ("الخرائط الديناميكية" و"التجوّل الافتراضي الديناميكي") تُكلّف أكثر من "الخرائط الثابتة" و"التجوّل الافتراضي الثابت". إذا لم تكن تتوقّع تفاعل المستخدِم مع "خرائط Google" أو "التجوّل الافتراضي" (التكبير أو التصغير أو التمرير)، استخدِم الإصدارات الثابتة من واجهات برمجة التطبيقات هذه.
الصور المصغّرة، وهي خرائط وصور صغيرة جدًا، هي استخدام آخر جيد لميزة "خرائط Google" الثابتة وميزة "التجوّل الافتراضي" الثابت. ويتم تحصيل رسوم هذه العناصر بسعر أقل وعند تعامل العميل (عند النقر)، ويمكن أن تنقل المستخدمين إلى إصدار ديناميكي للحصول على تجربة كاملة في "خرائط Google".
استخدام Maps Embed API
يمكنك استخدام واجهة برمجة التطبيقات Maps Embed API لإضافة خريطة تحتوي على علامة واحدة أو خريطة ديناميكية مجانًا. استخدِم واجهة برمجة التطبيقات Maps Embed API للتطبيقات التي لا تتطلّب سوى علامة واحدة ولا تتطلّب تخصيص الخريطة. سيتم تحصيل رسوم من طلبات Maps Embed API التي تستخدِم وضع "الاتجاهات" أو وضع "العرض" أو وضع "البحث" (اطّلِع على جدول الأسعار للاطّلاع على التفاصيل).
استخدام حِزم تطوير البرامج (SDK) للخرائط على الأجهزة الجوّالة في التطبيقات المتوافقة معها
بالنسبة إلى التطبيقات المتوافقة مع الأجهزة الجوّالة، استخدِم حزمة تطوير البرامج بالاستناد إلى بيانات "خرائط Google" لنظام التشغيل Android أو حزمة تطوير البرامج بالاستناد إلى بيانات "خرائط Google" لنظام التشغيل iOS عند عرض خريطة. استخدِم Maps Static API أو Maps JavaScript API عندما تستبعد المتطلبات استخدام حِزم تطوير البرامج (SDK) للأجهزة الجوّالة.
إدارة الاستهلاك في "المسارات"
الحدّ من نقاط الالتفاف في Directions API
حدِّد 10 نقاط طريق كحد أقصى لإدخالات المستخدمين في طلب البحث كلما أمكن. يتم تحصيل رسوم أعلى مقابل الطلبات التي تحتوي على أكثر من 10 نقاط طريق.
استخدام تحسين Directions API لتحديد المسار الأمثل
يتمّ تحصيل رسوم أعلى مقابل الطلبات التي تستخدِم مَعلمة تحسين نقاط التوقف. لمزيد من المعلومات، يُرجى الاطّلاع على تحسين نقاط التوقف.
يرتّب مَعلمة التحسين نقاط الالتقاء لضمان المسار الأمثل، ما يعني أنّ السفر من أ إلى هـ هو تجربة أفضل عند تحسينه (أ-ب-ج-د-هـ) مقارنةً بالتسلسل العشوائي لمسار غير محسَّن (مثل أ-د-ب-ج-هـ).
استخدام نماذج حركة المرور في الوقت الفعلي في Directions API وDistance Matrix API
يتم تحصيل رسوم أعلى مقابل طلبات واجهتَي برمجة التطبيقات Directions API وDistance Matrix API
التي تتضمّن نماذج حركة المرور في الوقت الفعلي.
يتم تفعيل نماذج حركة المرور في الوقت الفعلي من خلال ضبط وقت المغادرة على now.
في حال حذف نماذج حركة المرور من طلب معيّن، تستند النتائج فقط إلى العوامل المادية: الطرق والمسافات والحدود القصوى للسرعة.
استخدام "المسار الذي تم سلوكه" و"أقرب طريق" عندما تكون بيانات نظام تحديد المواقع العالمي (GPS) غير دقيقة
إنّ ميزتَي Maps Roads API، وهما Route Traveled و Nearest Road، مضمّنتَان في الفئة المتقدّمة ويتم تحصيل رسومهما بسعرٍ أعلى. استخدِم هذه الميزات عندما تكون بيانات نظام تحديد المواقع العالمي (GPS) غير دقيقة ويمكن أن تساعد واجهة برمجة التطبيقات Roads API في تحديد الطريق الصحيح. حدود السرعة هي ميزة أخرى لواجهة برمجة التطبيقات Roads API، ولا تتوفّر إلا لعملاء "تتبُّع مواد العرض".
أخذ عيّنات من المواقع الجغرافية للسرعة القصوى على فترات تتراوح بين 5 و15 دقيقة
لتقليل عدد طلبات البيانات إلى خدمة "حدود السرعة" في واجهة برمجة التطبيقات Maps Roads API، يمكنك أخذ عيّنات من مواقع مواد العرض الخاصة بك على فترات تتراوح بين 5 و15 دقيقة. تعتمد القيمة الدقيقة على سرعة انتقال مادة العرض. إذا كانت مادة العرض ثابتة، يكفي استخدام نموذج موقع جغرافي واحد. ما مِن حاجة إلى إجراء مكالمات متعددة.
للحدّ من وقت الاستجابة الإجمالي، يمكنك الاتصال بخدمة Speed Limit بعد جمع بعض البيانات بدلاً من الاتصال بواجهة برمجة التطبيقات في كل مرة يتم فيها تلقّي الموقع الجغرافي لمادة عرض جوّالة.
إدارة الاستهلاك في "الأماكن"
تحسين عمليات تنفيذ ميزة "الإكمال التلقائي للأماكن"
لتحسين تكلفة استخدام ميزة "الإكمال التلقائي للأماكن"، اتّبِع الخطوات التالية:
استخدام أقنعة الحقول في التطبيقات المصغّرة للإكمال التلقائي في JavaScript وAndroid وiOS لعرض حقول بيانات الأماكن التي تحتاج إليها فقط
تعتمد خيارات الفوترة المحدّدة على حالة الاستخدام. استنادًا إلى ما إذا كان التنفيذ يستخدِم جلسات الإكمال التلقائي أم لا، سيتم تحصيل رسوم منك مقابل رموز التخزين التعريفية الإكمال التلقائي - لكل طلب أو الإكمال التلقائي - لكل جلسة.
لمزيد من المعلومات والإرشادات حول اختيار الخيار المناسب لحالة الاستخدام، اطّلِع على أفضل الممارسات لتحسين تكلفة ميزة "الإكمال التلقائي للأماكن".
عرض بيانات لحقول محدّدة في طلبات "تفاصيل المكان" وطلبات "البحث عن مكان"
يمكنك تخصيص طلبات "تفاصيل الأماكن" و"بحث الأماكن" لعرض بيانات لحقول معيّنة مستخدَمة في تطبيقك. يتم تقسيم هذه الحقول إلى فئات: أساسي وجهة الاتصال والجو. إنّ الطلبات التي لا تحدد أي حقول ستتلقّى بيانات لجميع الحقول.
تستند الفوترة لطلبات تفاصيل الأماكن إلى أنواع البيانات المطلوبة ومقدارها. سيتم تحصيل الرسوم بالسعر الكامل مقابل الطلبات التي لا تحدّد أي حقول. لمزيد من المعلومات، يُرجى الاطّلاع على تفاصيل الأماكن وبحث الأماكن.
تقليل التكاليف باستخدام واجهة برمجة التطبيقات Geocoding API
إذا كان تطبيقك يعالج العناوين التي يكتبها المستخدمون، قد تكون العناوين غير واضحة في بعض الأحيان (غير مكتملة أو بها أخطاء إملائية أو تنسيقها سيئ). يمكنك إزالة الغموض عن العناوين باستخدام ميزة "الإكمال التلقائي"، ثم استخدام أرقام تعريف الأماكن للحصول على مواقعها الجغرافية.
ومع ذلك، إذا كان لديك عنوان دقيق (أو قريب منه)، يمكنك خفض التكاليف باستخدام الترميز الجغرافي بدلاً من الإكمال التلقائي. لمزيد من التفاصيل، اطّلِع على أفضل الممارسات المتعلّقة بترميز العناوين الجغرافية.
آلية عمل الحصص في "منصة خرائط Google"
تفرض جميع واجهات برمجة التطبيقات قيودًا على عدد طلبات البيانات التي يمكن لكل عميل إجراؤها. يتم ضبط هذه الخطط المخصّصة للعملاء على أساس كل دقيقة. بعد بلوغ الحصة المخصّصة للطلبات المتعلّقة بواجهة برمجة تطبيقات معيّنة في دقيقة واحدة، لن يتم قبول الطلبات المستقبلية إلى أن تبدأ الدقيقة التالية.
لا يتم احتساب سوى الطلبات الناجحة والطلبات التي تؤدي إلى أخطاء في الخادم ضمن الحصة. لا يتم احتساب الطلبات التي يتعذّر فيها إثبات الهوية ضمن الحصة.
تقدير تكاليف أي منتج من منتجات واجهة برمجة التطبيقات GMP API استنادًا إلى إجمالي عدد الطلبات