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

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

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

من الأسباب الشائعة لاستنزاف البطارية بلا داعٍ عدم إزالة التعديلات على الموقع الجغرافي عندما لا تعود هناك حاجة إليها.

يمكن أن يحدث ذلك عندما تحتوي طريقتَا مراحل النشاط onStart() أو onResume() على استدعاء requestlocationUpdates() بدون استدعاء مطابق لـ removeLocationUpdates() في طريقتَي مراحل النشاط onPause() أو onStop().

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

ضبط مهلات

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

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

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

تجميع الطلبات في دفعة واحدة

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

Kotlin

val request = LocationRequest.Builder(Priority.PRIORITY_HIGH_ACCURACY, 10 * 60 * 1000)
.setMaxUpdateDelayMillis(60 * 60 * 1000)
.build()

Java

LocationRequest request = new LocationRequest.Builder(Priority.PRIORITY_HIGH_ACCURACY, 10 * 60 * 1000)
    .setMaxUpdateDelayMillis(60 * 60 * 1000)
    .build();

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

استخدام التعديلات على الموقع الجغرافي في وضع عدم النشاط

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

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

Kotlin

val request = LocationRequest.Builder(Priority.PRIORITY_HIGH_ACCURACY, 15 * 60 * 1000)
.setMinUpdateIntervalMillis(2 * 60 * 1000)
.build()

Java

LocationRequest request = new LocationRequest.Builder(Priority.PRIORITY_HIGH_ACCURACY, 15 * 60 * 1000)
    .setMinUpdateIntervalMillis(2 * 60 * 1000)
    .build();

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

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