تحسين الموقع الجغرافي للبطارية

إنّ حدود الموقع الجغرافي في الخلفية التي تم طرحها في الإصدار Android 8.0 (المستوى 26 من واجهة برمجة التطبيقات) أعادت التركيز على مسألة كيفية تأثير استخدام خدمات الموقع الجغرافي في استهلاك البطارية. تتناول هذه الصفحة بعض أفضل الممارسات لخدمات الموقع الجغرافي وما يمكنك فعله الآن لجعل تطبيقاتك أكثر استخدامًا للبطارية. يفيد تطبيق أفضل الممارسات هذه تطبيقك بغض النظر عن إصدار النظام الأساسي الذي يعمل عليه.

أدّت حدود رصد الموقع الجغرافي في الخلفية في Android 8.0 إلى التغييرات التالية:

  • ويتم تقييد عملية جمع المواقع الجغرافية في الخلفية واحتساب الموقع الجغرافي، ويتم تنفيذه بضع مرات فقط كل ساعة.
  • عمليات البحث عن شبكات Wi-Fi أكثر تحفُّظًا، ولا يتم احتساب تحديثات الموقع الجغرافي عندما يظل الجهاز متصلاً بنقطة الوصول الثابتة نفسها.
  • تتغير استجابة حدود الموقع الجغرافي من عشرات الثواني إلى دقيقتين تقريبًا. يؤدي هذا التغيير إلى تحسين أداء البطارية بشكل ملحوظ، وذلك بشكل أفضل 10 مرات على بعض الأجهزة.

تفترض هذه الصفحة أنّك تستخدم واجهات برمجة التطبيقات في Google Location Services، التي توفر دقة أعلى وتفرض عبئًا أخف على البطارية مقارنةً بواجهات برمجة التطبيقات لموقع إطار العمل. وعلى وجه التحديد، تفترض هذه الصفحة الإلمام بواجهة برمجة التطبيقات المدمجة لموفر الموقع، والتي تجمع بين الإشارات من نظام تحديد المواقع العالمي (GPS) وشبكة Wi-Fi وشبكات الجوّال، فضلاً عن مقياس التسارع والجيروسكوب ومقياس المغناطيسية وأجهزة الاستشعار الأخرى. يجب أيضًا أن تكون على دراية بواجهة برمجة التطبيقات الجيولوجية، التي صُممت فوق واجهة برمجة تطبيقات مزوّد خدمة الموقع المدمجة، والتي تم تحسينها لأداء البطارية.

التعرّف على استنزاف البطارية

يرتبط جمع الموقع واستنزاف البطارية مباشرة بالجوانب التالية:

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

الدقة

يمكنك تحديد دقة الموقع الجغرافي باستخدام الطريقة setPriority()، من خلال تمرير إحدى القيم التالية كوسيطة:

  • PRIORITY_HIGH_ACCURACY يوفّر الموقع الجغرافي الأكثر دقة، ويتم احتسابه باستخدام أكبر عدد ممكن من الإدخالات حسب الضرورة (يفعّل نظام تحديد المواقع العالمي (GPS) وWi-Fi والخلية ويستخدم مجموعة متنوعة من أجهزة الاستشعار)، وقد يتسبّب ذلك في استنزاف كبير للبطارية.
  • توفّر حزمة PRIORITY_BALANCED_POWER_ACCURACY موقعًا جغرافيًّا دقيقًا أثناء تحسين الأداء للحصول على الطاقة. ونادرًا ما يستخدم نظام تحديد المواقع العالمي (GPS). عادةً ما يستخدم مزيجًا من شبكة Wi-Fi ومعلومات الخلية لحساب موقع الجهاز.
  • PRIORITY_LOW_POWER يعتمد بشكل كبير على أبراج الاتصالات، وهو يتجنّب مدخلات نظام تحديد المواقع العالمي (GPS) وشبكة Wi-Fi، ما يؤدي إلى توفير دقة تقريبية (على مستوى المدينة) مع الحدّ من استنزاف البطارية.
  • يتلقّى النطاق PRIORITY_NO_POWER المواقع الجغرافية بشكل سلبي من التطبيقات الأخرى التي سبق أن تم احتساب الموقع الجغرافي لها.

يمكن تلبية احتياجات الموقع لمعظم التطبيقات باستخدام خيارات الطاقة المتوازنة أو خيارات الطاقة المنخفضة. يجب ضبط الدقة العالية للتطبيقات التي تعمل في المقدمة وتتطلب تحديثات للموقع الجغرافي في الوقت الفعلي (على سبيل المثال، تطبيق ربط).

التردد

يمكنك تحديد معدّل تكرار المواقع الجغرافية باستخدام طريقتَين:

  • استخدِم طريقة setinterval() لتحديد الفاصل الزمني الذي يتم فيه احتساب الموقع الجغرافي لتطبيقك.
  • استخدِم setFastestInterval() لتحديد الفاصل الزمني الذي يتم خلاله تسليم الموقع الجغرافي المحسوب للتطبيقات الأخرى إلى تطبيقك.

ويجب إدخال أكبر قيمة ممكنة عند استخدام setInterval(). هذا صحيح بشكل خاص فيما يتعلق بجمع بيانات الموقع في الخلفية، والذي غالبًا ما يكون مصدرًا لاستنفاد البطارية بشكل غير مرحب به. يجب حجز استخدام فترات زمنية من بضع ثوان لحالات الاستخدام التي تعمل في المقدمة. وحدود رصد الموقع الجغرافي في الخلفية التي تم إدخالها في الإصدار Android 8.0 تفرض هذه الاستراتيجيات، ولكن يجب أن تسعى تطبيقك إلى فرضها على الأجهزة التي تعمل بالإصدار 7.0 من نظام التشغيل Android أو الإصدارات الأقدم.

وقت الاستجابة

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

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

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

حالات استخدام الموقع الجغرافي

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

التحديثات المرئية أو التي تعمل في المقدّمة للمستخدم

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

استخدِم الإجراء setPriority() بالقيمة PRIORITY_HIGH_ACCURACY أو PRIORITY_BALANCED_POWER_ACCURACY.

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

معرفة موقع الجهاز

مثال: يريد تطبيق الطقس معرفة الموقع الجغرافي للجهاز.

استخدِم الطريقة getLastLocation() التي تعرض أحدث موقع جغرافي متاح (والذي قد يكون فارغًا في حالات نادرة) . توفر هذه الطريقة طريقة بسيطة للحصول على الموقع ولا تتكبد أي تكاليف مرتبطة بطلب تحديثات الموقع بشكل نشط. يُرجى استخدامها مع الطريقة isLocationAvailable() التي تعرض القيمة true عندما يكون الموقع الجغرافي الذي تم إرجاعه من خلال getLastLocation() مُحدّثًا بشكل معقول.

بدء التحديثات عندما يكون المستخدم في موقع جغرافي محدّد

مثال: طلب التحديثات عندما يكون المستخدم في نطاق مسافة معينة من العمل أو المنزل أو موقع جغرافي آخر.

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

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

بدء التحديثات استنادًا إلى حالة نشاط المستخدم

مثال: طلب التحديثات فقط عند قيادة المستخدم أو ركوب دراجة.

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

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

تحديثات الموقع الجغرافي في الخلفية التي تستغرق وقتًا طويلاً والمرتبطة بمناطق جغرافية

مثال: يريد المستخدم أن يتم إبلاغه عندما يكون الجهاز على مقربة من بائع تجزئة.

هذه حالة استخدام ممتازة لوضع حدود جغرافية. وبما أنّ حالة الاستخدام تشمل بالتأكيد تحديد الموقع الجغرافي في الخلفية، يمكنك استخدام طريقة addGeofences(GeofencingRequest, PendingIntent).

ويجب ضبط خيارات الضبط التالية:

  • إذا كنت تريد تتبُّع انتقالات الثبات، استخدِم طريقة setLoiteringDelay() لتمرير قيمة تبلغ حوالي خمس دقائق أو أقل.

  • استخدِم setNotificationResponsiveness() مع ضبط قيمة تبلغ حوالي خمس دقائق. ومع ذلك، ضع في اعتبارك استخدام قيمة تبلغ حوالي عشر دقائق إذا كان بإمكان تطبيقك إدارة التأخير الإضافي في الاستجابة.

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

يتم إجراء تحديثات الموقع الجغرافي في الخلفية لفترة طويلة بدون ظهور مكوّن تطبيق مرئي.

مثال: تطبيق يتتبّع الموقع الجغرافي بشكل سلبي

واستخدِم طريقة setPriority() مع خيار PRIORITY_NO_POWER إن أمكن لأنّها لا تسبب أي استنزاف للبطارية تقريبًا. في حال تعذّر استخدام PRIORITY_NO_POWER، استخدِم PRIORITY_BALANCED_POWER_ACCURACY أو PRIORITY_LOW_POWER، مع تجنُّب استخدام PRIORITY_HIGH_ACCURACY لمواصلة العمل في الخلفية لأنّ هذا الخيار يستنزف طاقة البطارية بشكل كبير.

إذا كنت بحاجة إلى المزيد من بيانات الموقع الجغرافي، استخدِم ميزة الموقع الجغرافي السلبي من خلال استدعاء طريقة setFastestInterval() لتمرير قيمة أصغر من القيمة التي تُدخِلها إلى setInterval(). وعند دمج الموقع الجغرافي السلبي مع خيار PRIORITY_NO_POWER، يمكن للموقع الجغرافي السلبي توفير موقع جغرافي تحتسبه تطبيقات أخرى بدون أي تكلفة إضافية.

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

يتم تكرار التحديثات العالية الدقة أثناء تفاعل المستخدم مع التطبيقات الأخرى.

مثال: تطبيق للتنقل أو اللياقة البدنية يستمر في العمل عندما يغلق المستخدم الشاشة أو يفتح تطبيقًا مختلفًا.

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

أفضل الممارسات المتعلّقة بالمواقع الجغرافية

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

إزالة تعديلات الموقع الجغرافي

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

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

ضبط المُهلات

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

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

لإضافة مهلة إلى طلب موقع الحدود الجغرافية، استدعِ الطريقة setExpirationDuration().

الطلبات المجمّعة

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

Kotlin

val request = LocationRequest()
request.setInterval(10 * 60 * 1000)
request.setMaxWaitTime(60 * 60 * 1000)

Java

LocationRequest request = new LocationRequest();
request.setInterval(10 * 60 * 1000);
request.setMaxWaitTime(60 * 60 * 1000);

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

استخدام تحديثات الموقع الجغرافي السلبي

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

من المرجَّح أنّه أثناء تشغيل تطبيقك في الخلفية، قد يطلب تطبيق آخر تحديثات الموقع الجغرافي بشكل متكرر في المقدّمة. توفّر خدمات الموقع الجغرافي هذه التحديثات لتطبيقك. ننصحك بطلب الموقع الجغرافي التالي، الذي يستهلك بيانات الموقع الجغرافي في أغلب الأحيان:

Kotlin

val request = LocationRequest()
request.setInterval(15 * 60 * 1000)
request.setFastestInterval(2 * 60 * 1000)

Java

LocationRequest request = new LocationRequest();
request.setInterval(15 * 60 * 1000);
request.setFastestInterval(2 * 60 * 1000);

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

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

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