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