دليل التحسين

يستعرض هذا الدليل العديد من الاستراتيجيات لتحسين واجهات برمجة التطبيقات لخرائط Google الاستخدام من حيث الأمان والأداء والاستهلاك.

الأمان

مراجعة أفضل ممارسات الأمان

مفاتيح واجهة برمجة التطبيقات هي بيانات اعتماد تركّز على المشروع وتستحق نفس التدابير كمعرّفات المستخدمين وكلمات المرور. مراجعة أفضل ممارسات أمان واجهة برمجة التطبيقات لتأمين مفاتيحك من الاستخدام غير المقصود الذي قد يؤدي إلى استخدام حصة غير مبررة وتحصيل رسوم غير متوقعة إلى حسابك.

استخدام مفاتيح واجهة برمجة التطبيقات للوصول إلى واجهات برمجة تطبيقات الخرائط

مفاتيح واجهة برمجة التطبيقات هي طريقة المصادقة المفضّلة للوصول إلى واجهات برمجة التطبيقات لخرائط Google. واجهات برمجة التطبيقات. على الرغم من أنّ استخدام معرِّفات العملاء لا يزال متاحًا حاليًا، فإنّ مفاتيح واجهة برمجة التطبيقات عناصر تحكم أكثر دقة في الأمان ويمكن ضبطها للعمل مع عناوين الويب، وعناوين IP، وحزم SDK للأجهزة الجوّالة (Android وiOS). للحصول على معلومات حول إنشاء مفتاح واجهة برمجة تطبيقات وتأمينه، انتقل إلى قسم "استخدام مفتاح واجهة برمجة التطبيقات" لكل صفحة واجهة برمجة التطبيقات أو حزمة تطوير البرامج (SDK). (على سبيل المثال، بالنسبة إلى واجهة برمجة تطبيقات JavaScript للخرائط، انتقل إلى صفحته حول استخدام مفتاح واجهة برمجة التطبيقات).

الأداء

استخدام خوارزمية الرقود الأسي لمعالجة الأخطاء

إذا واجهت تطبيقاتك أخطاءً بسبب المحاولات الزائدة للاتصال بواجهة برمجة تطبيقات خلال فترة زمنية قصيرة، مثل أخطاء QPS، ننصحك باستخدام exponential backoff (رقود أسي) للسماح بمعالجة الطلبات.

يُعد الرقود الأسي مفيدًا للغاية للأخطاء التي حدثت في القرن السادس عشر. لمزيد من المعلومات راجع التعامل مع رموز حالة إرجاع HTTP.

على وجه التحديد، اضبط وتيرة طلبات البحث. في التعليمة البرمجية، أضف فترة انتظار مدتها S ثانية بين طلبات البحث. إذا كان الاستعلام لا يزال يعرض النتائج في خطأ QPS، فقم بمضاعفة فترة الانتظار ثم أرسل استعلامًا آخر. متابعة ضبط فترة الانتظار حتى يتم إرجاع الاستعلام دون خطأ.

إرسال طلبات التفاعل مع المستخدم عند الطلب

يجب إرسال الطلبات إلى واجهات برمجة التطبيقات التي تتضمّن تفاعلاً مع المستخدم عند الطلب فقط. يعني ذلك انتظار المستخدم النهائي لتنفيذ إجراء (مثل on-click). بدء طلب واجهة برمجة التطبيقات، ثم استخدام النتائج لتحميل خريطة، أو الوجهة أو عرض المعلومات المناسبة. استخدام نهج عند الطلب تتجنب الطلبات غير الضرورية لواجهات برمجة التطبيقات، مما يقلل استهلاك واجهة برمجة التطبيقات.

تجنُّب عرض محتوى مركّب أثناء تحرك الخريطة

تجنَّب استخدام Draw() لعرض محتوى تراكب مخصّص على خريطة باستخدام الخوارزمية نفسها. الوقت الذي قد يحرّك فيه المستخدم الخريطة. بما أنّه تتم إعادة رسم الخريطة في كل مرة يقوم المستخدم بتحريك الخريطة، مما يؤدي إلى وضع محتوى تراكب على الخريطة في نفس الوقت يمكن أن حدوث تأخُّر أو تقطُّع بصري. يمكنك فقط إضافة محتوى متراكب أو إزالته من بمجرد توقف المستخدم عن الدوران أو التكبير.

تجنُّب العمليات المكثّفة في Draw طريقة

كقاعدة عامة، من الممارسات الجيدة تجنُّب التكاليف التي تستهلك قدرًا كبيرًا من الأداء عمليات غير رسمية بطريقة Draw(). على سبيل المثال، تجنب ما يلي في رمز طريقة Draw():

  • طلبات البحث التي تعرض قدرًا كبيرًا من المحتوى
  • تغييرات عديدة على البيانات التي يتم عرضها.
  • معالجة العديد من عناصر نموذج كائن المستند (DOM)

يمكن أن تؤدي هذه العمليات إلى إبطاء الأداء وعرض حدوث تأخُّر في الأداء أو تقطُّع بصري. عند عرض الخريطة.

استخدام الصور النقطية للعلامات

استخدام الصور النقطية، مثل الصور بتنسيق PNG .أو JPG.، عند الإضافة محدّدات لتحديد الموقع على الخريطة. تجنب استخدام المتجهات القابلة للتوسع صور رسومات موجّهة يمكن تغيير حجمها (SVG)، نظرًا لأن عرض صور SVG قد يؤدي إلى حدوث تأخير عند تمت إعادة رسم الخريطة.

تحسين العلامات

يؤدي التحسين إلى تحسين الأداء من خلال عرض العديد من العلامات كعلامة ثابتة واحدة العنصر. ويكون ذلك مفيدًا في الحالات التي تكون فيها الحاجة إلى عدد كبير من العلامات. بشكل تلقائي، ستحدد واجهة برمجة تطبيقات JavaScript للخرائط ما إذا كانت علامة فسيتم تحسينه. عندما يكون هناك عدد كبير من العلامات، ستحاول واجهة برمجة تطبيقات JavaScript للخرائط عرض علامات مع التحسين. لا يمكن تحسين كل العلامات؛ في بعض الحالات، قد تحتاج واجهة برمجة تطبيقات JavaScript للخرائط إلى عرض العلامات بدون التحسين. إيقاف العرض المحسَّن لملفات GIF أو PNG المتحركة، أو في حال يجب عرض كل علامة كعنصر DOM منفصل.

إنشاء مجموعات لإدارة عرض العلامات

للمساعدة في إدارة عرض العلامات لتحديد المواقع على الخريطة، لإنشاء مجموعة علامات باستخدام Marker Clusterer. تتضمن مكتبة "Marker Clusterer" خيارات من أجل:

  • حجم الشبكة: لتحديد عدد العلامات التي سيتم تجميعها معًا في مجموعة عنقودية واحدة.
  • الحد الأقصى للتكبير، لتحديد أقصى مستوى للتكبير/التصغير الذي لعرض المجموعة العنقودية.
  • مسارات الصور، لاستخدام صور الرسومات كرموز علامات.

مشاهدة المحتوى

للتخطيط لميزانيتك والتحكم في تكاليفك، عليك إجراء ما يلي:

  • إعداد تنبيه بشأن الميزانية لتتبّع كيفية نمو التكاليف نحو مبلغ معين. وضع الميزانية لا تفرض قيودًا على استخدام واجهة برمجة التطبيقات - بل تنبهك فقط عندما تقترب تكاليفك من المبلغ المحدد.
  • تحديد الاستخدام اليومي لواجهة برمجة التطبيقات لإدارة تكاليف واجهات برمجة التطبيقات القابلة للفوترة. من خلال وضع حدود قصوى للطلبات لكل يوم، يمكنك الحد من تكاليفك. استخدِم معادلة بسيطة لتحديد جدول مواعيدك اعتمادًا على المبلغ الذي تريد إنفاقه: (شهريًا) التكلفة/السعر لكل )/30 = عدد الطلبات في اليوم (لواجهة برمجة تطبيقات واحدة). قد تؤدي عملية التنفيذ المحدَّدة واستخدام واجهات برمجة تطبيقات متعددة قابلة للفوترة، لذا اضبط المعادلة حسب الحاجة. حاسمة رصيد بقيمة 200 دولار أمريكي (أو ما يعادله بالعملة المحلية) من Google Maps API كل شهر، لذا ضع ذلك في الاعتبار في حساباتك.
  • استخدِم عدة مشاريع لعزل بيانات الاستخدام وتحديد أولوياتها وتتبُّعها. على سبيل المثال، لنفترض أنّك تستخدم واجهات برمجة التطبيقات في Google Maps Platform بشكل منتظم في الاختبار. عن طريق إنشاء مشروع منفصل للاختبار - بحصصه مفاتيح واجهة برمجة التطبيقات: يمكنك اختبارها بشكل دقيق مع الحماية من المفاجآت الإفراط في الإنفاق.

إدارة الاستهلاك في "خرائط Google"

يُعد استخدام خريطة واحدة لكل صفحة طريقة جيدة لتحسين عرض الخرائط، نظرًا يتفاعل المستخدمون بشكل عام مع خريطة واحدة فقط في كل مرة. يمكن لتطبيقك معالجة البيانات. الخريطة لعرض مجموعات بيانات مختلفة، اعتمادًا على تفاعل العملاء واحتياجاته.

استخدام الصور الثابتة

تكلفة الطلبات التي تستخدم الصور الديناميكية (الخرائط الديناميكية والتجوّل الافتراضي الديناميكي) أكثر من خرائط Google الثابتة والتجوّل الافتراضي الثابت. إذا كنت لا تتوقع أن يكون المستخدم التفاعل مع الخريطة أو التجوّل الافتراضي (التكبير أو التصغير)، استخدم العنصر الثابت بإصدارات واجهات برمجة التطبيقات هذه.

الصور المصغرة - الخرائط والصور الصغيرة جدًا - هي استخدام جيد آخر للصور الثابتة "خرائط Google" و"التجوّل الافتراضي" الثابت يتم إصدار فواتير هذه العناصر بسعر أقل وبعد تفاعل المستخدم (عند النقر)، ويمكن أن ينقل المستخدمين إلى نسخة ديناميكية للحصول على تجربة "خرائط Google".

استخدام واجهة برمجة التطبيقات لتضمين الخرائط

يمكنك استخدام Maps Embed API لإضافة خريطة باستخدام أو علامة واحدة أو خريطة ديناميكية بدون أي تكلفة. يمكنك استخدام واجهة برمجة تطبيقات تضمين الخرائط للتطبيقات حيث يمكن محدد ولا يلزم تخصيص الخريطة. طلبات واجهة برمجة التطبيقات لتضمين الخرائط باستخدام وضع الاتجاهات أو وضع العرض، أو وضع البحث (يُرجى الاطّلاع على جدول الأسعار للحصول على التفاصيل).

استخدام حزم SDK لخرائط الجوّال لتطبيقات الأجهزة الجوّالة

استخدام حزمة تطوير البرامج بالاستناد إلى بيانات "خرائط Google" لتطبيقات الأجهزة الجوّالة لنظام التشغيل Android أو حزمة تطوير البرامج بالاستناد إلى بيانات "خرائط Google" لتطبيقات iOS عند عرض الخريطة استخدام واجهة برمجة التطبيقات الثابتة للخرائط أو Maps JavaScript API عند استبعاد المتطلبات باستخدام حزم SDK للجوّال.

إدارة الاستهلاك في المسارات

الحدّ من نقاط الطرق في واجهة برمجة التطبيقات Directions API

عندما يكون ذلك ممكنًا، قم بتقييد إدخالات المستخدم في استعلام إلى 10 نقاط مسار كحد أقصى. أما الطلبات التي تحتوي على أكثر من 10 نقاط مسار، يتم إصدار فواتيرها بمعدّل أعلى.

استخدام تحسين واجهة برمجة تطبيقات الاتجاهات للتوجيه الأمثل

تُحصَّل فواتير الطلبات التي تستخدم وسيطة تحسين النقاط الوسيطة بمعدل أعلى. لمزيد من المعلومات، يُرجى الاطّلاع على تحسين نقاط الطرق.

تقوم وسيطة التحسين بفرز نقاط الطريق لضمان التوجيه الأمثل، مما يعني أن الانتقال من الألف إلى الياء يُمثل تجربة أفضل عند تحسينه (A-B-C-D-E) مقابل التسلسل العشوائي لمسار غير محسّن (مثل A-D-B-C-E).

استخدام نماذج الزيارات في الوقت الفعلي في واجهة برمجة تطبيقات الاتجاهات وواجهة برمجة تطبيقات مصفوفة المسافة

واجهة برمجة التطبيقات للاتجاهات وواجهة برمجة التطبيقات لمصفوفة المسافة يتم تحصيل فواتير الطلبات التي تتضمّن نماذج للزيارات في الوقت الفعلي بمعدل أعلى. يتم تفعيل نماذج حركة المرور في الوقت الفعلي من خلال ضبط وقت المغادرة على now.

إذا تم حذف نماذج الزيارات من أحد الطلبات، يتم تحديد النتائج فقط على عوامل فعلية: الطرق والمسافة وحدود السرعة.

استخدام المسار الذي تم السفر إليه أقرب طريق عندما تكون بيانات نظام تحديد المواقع العالمي غير دقيقة

ميزات واجهة برمجة التطبيقات لطرق الخرائط و Route Traveled الطريق الأقرب، مضمّنة في الفئة المتقدمة ويتم تحصيل الرسوم من خلال المعدل. استخدم هذه الميزات عندما تكون بيانات نظام تحديد المواقع العالمي غير دقيقة يمكن أن تساعد واجهة برمجة تطبيقات الطرق في تحديد الطريق الصحيح. السرعة الحدود، وهي ميزة أخرى في واجهة برمجة تطبيقات الطرق، متاحة فقط لعملاء تتبع الأصول.

مواقع حدود سرعة أخذ العينات على فترات زمنية تتراوح من 5 إلى 15 دقيقة

لتقليل حجم الطلبات الموجّهة إلى Maps Roads API خدمة تحديد السرعة، يمكنك استخدام عينات من مواقع مواد العرض خلال مدة تتراوح بين 5 و15 دقيقة. الفترات. تعتمد القيمة الدقيقة على سرعة مادة العرض السفر. إذا كانت مادة العرض ثابتة، فيتم تحديد عينة من موقع واحد كافية. وليست هناك حاجة لإجراء مكالمات متعددة.

لتقليل وقت الاستجابة الإجمالي، اتصل بخدمة "حد السرعة" بعد بعض البيانات بدلاً من طلب البيانات من واجهة برمجة التطبيقات في كل مرة الموقع الذي تم الحصول عليه من مادة عرض الجوّال.

إدارة الاستهلاك في الأماكن

تحسين عمليات تنفيذ الإكمال التلقائي للأماكن

لتحسين تكلفة استخدام ميزة "الإكمال التلقائي" للأماكن:

  • استخدام أقنعة الحقول في أدوات الإكمال التلقائي في JavaScript وAndroid وiOS لعرض حقول بيانات المكان التي تحتاجها فقط.

  • يعتمد تحديد خيارات الفوترة على حالة استخدامك. استنادًا إلى ما إذا كانت عملية التنفيذ تستخدِم جلسات الإكمال التلقائي أم لا، سيتمّ تحصيل رسوم منك مقابل رموز التخزين التعريفية الإكمال التلقائي - لكلّ طلب أو الإكمال التلقائي - لكلّ جلسة.

للحصول على مزيد من المعلومات والإرشادات حول تحديد الخيار المناسب لحالة استخدامك، يُرجى الاطّلاع على أفضل الممارسات لتحسين تكلفة الإكمال التلقائي.

عرض البيانات لحقول محددة في تفاصيل المكان وطلبات البحث عن الأماكن

يمكنك تخصيص تفاصيل الأماكن وطلبات البحث عن الأماكن لعرض البيانات. للحقول المحددة المستخدمة في طلبك. يتم تقسيم هذه الحقول إلى الفئات: الأساسية والاتصال والأجواء. الطلبات التي لا تتضمن تحديد أي حقول ستتلقى بيانات لكل الحقول.

تستند طريقة الفوترة لطلبات "تفاصيل المكان" إلى الأنواع والمبالغ. من البيانات المطلوبة. سيتم تحصيل فواتير الطلبات التي لا تتضمّن أي حقول. بأقصى سرعة. لمزيد من المعلومات، راجِع تفاصيل المكان والبحث عن الأماكن.

خفض التكاليف باستخدام واجهة برمجة التطبيقات Geocoding API

إذا كان تطبيقك يتعامل مع العناوين التي يكتبها المستخدم، فإن العناوين التالية هي غامضة أحيانًا (غير مكتملة أو بها خطأ إملائي أو تم تنسيقها بشكل رديء). عليك التفريق بين العناوين باستخدام ميزة "الإكمال التلقائي"، ثم استخدام أرقام تعريف الأماكن. لمعرفة المواقع الجغرافية للمكان.

إذا كان لديك عنوان دقيق (أو قريب منه)، يمكنك مع ذلك تقليل باستخدام الترميز الجغرافي بدلاً من الإكمال التلقائي. لمزيد من التفاصيل، راجِع أفضل ممارسات عناوين الترميز الجغرافي.

آلية عمل حصص "منصة خرائط Google"

تفرض جميع واجهات برمجة التطبيقات حدودًا على عدد المكالمات التي يمكن لكل عميل إجراؤها. هذه يتم ضبط الحصص على أساس كل دقيقة. بعد الوصول إلى حصة المكالمات على أي واجهة برمجة تطبيقات خلال دقيقة، لن يتم قبول أي مكالمات مستقبلية حتى الدقيقة التالية.

لا يتم احتساب سوى الطلبات والطلبات الناجحة التي تتسبب في حدوث أخطاء في الخادم الحصة. ولا يتم احتساب الطلبات التي لا تجتاز المصادقة ضمن الحصة.

يتم فرض إجراءات في العديد من واجهات برمجة تطبيقات "خرائط Google" في الثانية بالإضافة إلى الحصة في الدقيقة التنفيذ. لا يضمن تنفيذ هذا الإجراء في الثانية استخدامًا موحدًا على مدار الدقيقة بأكملها، ولن تمنعك من الوصول إلى حصة الاستخدام في تلك الدقيقة. يمنعك ذلك من استخدام كل حصتك في البداية ثانية أو ثانيتان من أي دقيقة معينة، ويحميك من انقطاع الخدمة في حال حدوث ارتفاع مفاجئ في معدّل الاستخدام للتعامل مع الاختلافات في إجراءات التنفيذ، تخطيط استخدام حصتك ومتطلباتها من خلال احتساب متوسط استخدام QPM عبر خدمة QPS.

واجهات برمجة التطبيقات في "منصة Google للتسويق" التي تتضمّن إجراءات التنفيذ هذه في الثانية واجهة برمجة تطبيقات الاتجاهات وواجهة برمجة تطبيقات مصفوفة المسافة Eliffation API وGeocoding API واجهة برمجة تطبيقات الأماكن وواجهة برمجة التطبيقات للطرق

تقدير تكاليف أي منتج من منتجات واجهة برمجة التطبيقات في "منصة Google للتسويق" استنادًا إلى إجمالي حجم الطلبات