دليل التحسين

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

الأمان

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

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

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

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

عروض أداء

استخدام التراجع الأسي للتعامل مع الأخطاء

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

يعد التراجع الأسي مفيدًا للغاية للأخطاء التي حدثت في الخمسينيات. لمزيد من المعلومات، يمكنك الاطّلاع على التعامل مع رموز حالة عرض HTTP.

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

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

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

تجنب عرض محتوى التراكب عندما تتحرك الخريطة

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

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

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

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

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

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

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

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

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

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

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

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

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

لتخطيط ميزانيتك والتحكم في تكاليفك، قم بما يلي:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

واجهات برمجة التطبيقات "منصة Google للتسويق" التي يتم فرض هذا الشرط في الثانية عليها هي واجهة برمجة التطبيقات Directions API وواجهة برمجة التطبيقات لمصفوفة المسافة وواجهة برمجة التطبيقات Elevation API وواجهة برمجة التطبيقات Geocode Geocode وواجهة برمجة التطبيقات "Places API" وواجهة برمجة التطبيقات للطرق.

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