أخبار المنتجات

تحسين أداء بطارية تطبيقك باستخدام مقياس قفل التنشيط في "مؤشرات Android الحيوية"

مدّة القراءة: 7 دقائق
عرض ملف "أليس يوان" الشخصي
Alice Yuan مهندس علاقات المطوّرين، Android

يُعدّ عمر البطارية جانبًا مهمًا في تجربة المستخدم، وتؤدي أقفال التنشيط دورًا رئيسيًا في ذلك. هل تستخدمها بشكل مفرط؟ في منشور المدوّنة هذا، سنستكشف ما هي أقفال التنشيط، وما هي بعض أفضل الممارسات لاستخدامها، وكيف يمكنك فهم سلوك تطبيقك بشكل أفضل من خلال مقياس Play Console.

الاستخدام المفرط لقفل التنشيط الجزئي في "مؤشرات Android الحيوية"

تراقب Play Console الآن استنزاف البطارية، مع التركيز على الاستخدام المفرط لقفل التنشيط الجزئي، كمؤشر أداء رئيسي.

تُبرز هذه الميزة أهمية كفاءة البطارية إلى جانب مؤشرات ثبات المقاييس الأساسية الحالية: الأعطال التي لاحظها المستخدم وأخطاء ANR الزائدة عن الحد. لقد حدّدنا معيارًا لتحديد الأداء السيئ لعمليات قفل التنشيط الزائدة عن الحد. اعتبارًا من 1 مارس 2026، إذا لم يستوفِ عنوانك حدّ الجودة هذا، قد نستبعده من مساحات العرض البارزة للاستكشاف، مثل الاقتراحات. في بعض الحالات، قد نعرض تحذيرًا في بطاقة بيانات المتجر لإعلام المستخدمين بأنّ تطبيقك قد يتسبب في استنزاف البطارية بشكل مفرط.

warning.png

التحذير من عمليات قفل التنشيط الزائدة عن الحد في نظرة عامة على مؤشرات Android الحيوية.

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

  • يتم الاحتفاظ بأقفال التنشيط لمدة ساعتَين على الأقل خلال فترة 24 ساعة.
  • تؤثّر هذه المشكلة في أكثر من% 5 من جلسات تطبيقك، وذلك في المتوسط على مدار 28 يومًا.

يتم استثناء أقفال التنشيط التي تم إنشاؤها بواسطة واجهات برمجة التطبيقات التي بدأها المستخدم من خلال الصوت والموقع الجغرافي وJobScheduler من عملية احتساب قفل التنشيط.

فهم أقفال التنشيط

قفل التنشيط هو آلية تتيح للتطبيق إبقاء وحدة المعالجة المركزية (CPU) في الجهاز قيد التشغيل حتى عندما لا يتفاعل المستخدم معه بشكل نشط. 

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

هناك طريقتان للحصول على أقفال التنشيط الجزئية:

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

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

أفضل الممارسات لاستخدام قفل التنشيط

قبل أن نوضّح كيفية تصحيح أخطاء الاستخدام المفرط لأقفال التنشيط، تأكَّد من اتّباع أفضل الممارسات المتعلّقة بأقفال التنشيط. 

في ما يلي أربعة أسئلة مهمة يجب طرحها.


‫1. هل فكّرت في خيارات بديلة لقفل التنشيط؟

قبل التفكير في الحصول على قفل تنشيط جزئي يدوي، اتّبِع المخطط الانسيابي التالي لاتخاذ القرار:

wakelock.png

مخطط انسيابي لتحديد وقت الحصول على قفل تنشيط يدويًا

  1. هل يجب أن تبقى الشاشة مفعّلة؟
  2. هل يشغّل التطبيق خدمة تعمل في المقدّمة؟
    • لا: لست بحاجة إلى الحصول على قفل تنشيط يدويًا.
  3. هل يؤثر تعليق الجهاز سلبًا في تجربة المستخدم؟
    • لا: على سبيل المثال، لا يتطلّب تعديل إشعار بعد تنشيط الجهاز قفل تنشيط.
    • نعم: إذا كان من الضروري منع الجهاز من التعليق، مثل التواصل المستمر مع جهاز خارجي، يمكنك المتابعة.
  4. هل هناك واجهة برمجة تطبيقات حالية تُبقي الجهاز في وضع النشاط نيابةً عنك؟
  5. إذا أجبت عن كل هذه الأسئلة وتبيّن لك عدم توفّر بديل، عليك المتابعة في الحصول على قفل تنشيط يدويًا.

2. هل تسمّي قفل التنشيط بشكل صحيح؟

عند الحصول على أقفال التنشيط يدويًا، من المهم تسميتها بشكل صحيح لتصحيح الأخطاء:

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

3. هل يتم دائمًا إلغاء قفل التنشيط الذي تم الحصول عليه؟

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

على سبيل المثال، إذا تم طرح استثناء لم يتم رصده أثناء processingWork()، قد لا يتم إجراء طلب release()‎ مطلقًا. بدلاً من ذلك، يمكنك استخدام مجموعة try-finally لضمان إلغاء قفل التنشيط، حتى في حال حدوث استثناء.

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

fun processingWork() {
    wakeLock.apply {
        try {
            acquire(60 * 10 * 1000) // timeout after 10 minutes
            doTheWork()
        } finally {
            release()
        }
    }
}

4. هل يمكنك تقليل معدّل تكرار التنشيط؟

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

  • WorkManager: يمكنك زيادة الفاصل الزمني الدوري في PeriodicWorkRequest.
  • SensorManager: يمكنك الاستفادة من ميزة تجميع البيانات من خلال تحديد maxReportLatencyMs عند تسجيل المستمع.
  • موفِّر الموقع المدمج:
    • يمكنك تقليل معدّل تكرار استرداد الموقع الجغرافي باستخدام getLastLocation للحصول على أحدث موقع جغرافي مخزَّن مؤقتًا.
    • استخدِم setPriority(PRIORITY_PASSIVE) للحصول على طريقة تحديث أقل استهلاكًا للبطارية.
    • يمكنك أيضًا الاستفادة من آلية تجميع المواقع الجغرافية من خلال ضبط حدّ أدنى للفاصل الزمني للتحديث باستخدام setMinUpdateIntervalMillis.

يمكنك الاطّلاع على مزيد من التفاصيل في مستند أفضل ممارسات قفل التنشيط.

تصحيح أخطاء الاستخدام الزائد عن الحدّ لقفل التنشيط

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

التعريف الأولي باستخدام Play Console

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

breakdowns2.png

لوحة بيانات عمليات قفل التنشيط الجزئي الزائدة عن الحد في "مؤشرات Android الحيوية" مع الانتقال للأسفل إلى قسم "التفاصيل" لعرض علامات قفل التنشيط الزائدة عن الحد

تصحيح أخطاء عمليات قفل التنشيط الزائدة عن الحد التي يحتفظ بها العمال/الوظائف

يمكنك تحديد أقفال التنشيط التي يحتفظ بها العامل باستخدام اسم قفل التنشيط التالي:

*job*/<package_name>/androidx.work.impl.background.systemjob.SystemJobService

تتوفّر القائمة الكاملة لأسماء قفل التنشيط التي يحتفظ بها العامل في المستندات. لتصحيح أخطاء عمليات قفل التنشيط هذه، يمكنك استخدام "أداة فحص المهام في الخلفية" لتصحيح الأخطاء محليًا، أو الاستفادة من getStopReason لتصحيح الأخطاء في الميدان. 

أداة فحص المهام في الخلفية في "استوديو Android"

taskinspector.png


لقطة شاشة لـ "أداة فحص المهام في الخلفية"، حيث تمكّنت من تحديد عامل "WeatherSyncWorker" الذي حاول بشكل متكرر وفشل.

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

على سبيل المثال، يمكن أن تكشف هذه المقاييس ما إذا كان العامل يفشل أو يعيد المحاولة بشكل متكرر بسبب بلوغ حدود النظام. 

يُرجى الاطّلاع على مستندات "أداة فحص المهام في الخلفية" لمزيد من التفاصيل.

WorkManager getStopReason

لتصحيح أخطاء العمال الذين لديهم أقفال تنشيط زائدة في الميدان، استخدِم WorkInfo.getStopReason() في الإصدار 2.9.0 من WorkManager أو الإصدارات الأحدث، أو استخدِم JobParameters.getStopReason() في الإصدار 31 من حزمة تطوير البرامج (SDK) أو الإصدارات الأحدث في JobScheduler. 

تساعد واجهة برمجة التطبيقات هذه في تسجيل سبب توقّف العامل (مثل STOP_REASON_TIMEOUT أو STOP_REASON_QUOTA)، وتحديد المشاكل مثل انتهاء المهلة بشكل متكرّر بسبب استنفاد مدة التشغيل.

backgroundScope.launch {
    WorkManager.getInstance(context)
        .getWorkInfoByIdFlow(workRequest.id)
        .collect { workInfo ->
            logStopReason(workRequest.id, workInfo?.stopReason)
        }
}

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

تصحيح أخطاء الأنواع الأخرى من عمليات قفل التنشيط الزائدة عن الحدّ

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

تجميع بيانات تتبُّع النظام

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

يمكنك تسجيل تتبُّع النظام باستخدام عدة طرق: 

powermgmt.png

فعِّل فئة Atrace‏ "power:PowerManagement" في واجهة مستخدم Perfetto ضمن علامة التبويب "تطبيقات Android وخدماته". 

بغض النظر عن الطريقة التي تختارها، من الضروري التأكّد من جمع فئة Atrace‏ "power:PowerManagement" لتفعيل عرض مسارات حالة الجهاز. 

فحص واجهة مستخدم Perfetto وتحليل SQL

يمكن فتح سجلّات تتبّع النظام وفحصها في واجهة مستخدم Perfetto. عند فتح التتبُّع، سيظهر لك عرض مرئي للعمليات المختلفة على مخطط زمني. سنركّز في هذا الدليل على المسارات ضمن "حالة الجهاز".

perfetto.png


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

وتعرض كل مجموعة اسم الحدث ووقت بدئه ووقت انتهائه. في Perfetto، يُطلق على ذلك اسم "شريحة".

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

في ما يلي مثال على طلب بحث يجمع كل علامات قفل التنشيط التي حدثت في تتبُّع النظام، مرتّبة حسب المدة الإجمالية:

SELECT slice.name as name, track.name as track_name,SUM(dur / 100000) as total_dur_ms
FROM slice
JOIN track ON slice.track_id = track.id
WHERE track.name = 'WakeLocks'GROUP BY slice.name, track.name
ORDER BY total_dur_ms DESC

استخدام ProfilingManager لجمع بيانات التتبُّع في الميدان

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

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

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

الخاتمة

إنّ مقياس عمليات قفل التنشيط الجزئي الزائدة عن الحد في "مؤشرات Android الحيوية" ليس سوى جزء صغير من التزامنا المستمر بمساعدة المطوّرين في تقليل استنزاف البطارية وتحسين جودة التطبيقات. 

من خلال فهم أقفال التنشيط وتنفيذها بشكل صحيح، يمكنك تحسين أداء بطارية تطبيقك بشكل كبير. لضمان نجاح تطبيقك على Google Play، من المهم الاستفادة من واجهات برمجة التطبيقات البديلة، واتّباع أفضل الممارسات المتعلّقة بقفل التنشيط، واستخدام أدوات تصحيح الأخطاء الفعّالة، مثل "أداة فحص المهام في الخلفية" وتتبُّع النظام وProfilingManager.

من كتابة:
متابعة القراءة