أصبح بإمكانك الآن فرض معايير الجودة الفنية المتعلقة بالبطارية: كيفية تحسين حالات الاستخدام الشائعة لعمليات قفل التنشيط

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

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

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

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

استخدام خدمة تعمل في المقدّمة مقابل أقفال التنشيط الجزئية

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

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

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

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

المكتبات الخارجية التي تحصل على عمليات قفل التنشيط

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

• التحقّق من "مؤشرات Android الحيوية": ابحث عن الاسم الدقيق لقفل التنشيط الذي يتسبّب في المشكلة في لوحة بيانات أقفال التنشيط الجزئية المفرطة. يمكنك الرجوع إلى هذا الاسم ومقارنته بالإرشادات الواردة في مقالة تحديد عمليات قفل التنشيط التي أنشأتها واجهات برمجة تطبيقات أخرى لمعرفة ما إذا كان قد تم إنشاؤه بواسطة إحدى واجهات برمجة التطبيقات المعروفة في النظام أو مكتبة Jetpack. إذا كان الأمر كذلك، قد تحتاج إلى تحسين استخدامك لواجهة برمجة التطبيقات ويمكنك الرجوع إلى الإرشادات المقترَحة.
• تسجيل عملية تتبُّع الأداء على مستوى النظام: إذا تعذّر تحديد قفل التنشيط بسهولة، أعِد إنشاء مشكلة قفل التنشيط محليًا باستخدام عملية تتبُّع الأداء على مستوى النظام وافحصها باستخدام واجهة مستخدم Perfetto. يمكنك الاطّلاع على مزيد من المعلومات حول كيفية إجراء ذلك في قسم تصحيح أخطاء أنواع أخرى من عمليات قفل التنشيط المفرطة في منشور المدوّنة هذا.
• تقييم البدائل: إذا كانت إحدى المكتبات غير الفعّالة التابعة لجهات خارجية هي المسؤولة عن المشكلة ولا يمكن ضبطها للحفاظ على عمر البطارية، ننصحك بالتواصل مع مالكي حزمة تطوير البرامج (SDK) لإبلاغهم بالمشكلة أو البحث عن حزمة تطوير برامج (SDK) بديلة أو إنشاء الوظيفة داخليًا.

سيناريوهات شائعة لعمليات قفل التنشيط

في ما يلي تفصيل لبعض حالات الاستخدام المحدّدة التي راجعناها، بالإضافة إلى المسار المقترَح لتحسين تنفيذ قفل التنشيط.

التحميل أو التنزيل الذي يبدأه المستخدم

أمثلة على حالات الاستخدام: 

• تطبيقات بث الفيديو التي يطلب فيها المستخدم تنزيل ملف كبير للوصول إليه بلا إنترنت
• تطبيقات الاحتفاظ بنسخة احتياطية من الوسائط حيث يبدأ المستخدم في تحميل صوره الحديثة من خلال طلب إذن في الإشعار

كيفية الحدّ من عمليات قفل التنشيط: 

• لا تحصل على قفل تنشيط يدوي. يمكنك بدلاً من ذلك استخدام User-Initiated Data Transfer (UIDT) API. هذا هو المسار المخصّص لمهام نقل البيانات الطويلة الأمد التي يبدأها المستخدم، وهو معفى من احتساب عمليات قفل التنشيط المفرطة.

عمليات المزامنة في الخلفية لمرة واحدة أو بشكل دوري

أمثلة على حالات الاستخدام: 

• يُجري التطبيق عمليات مزامنة دورية في الخلفية لجلب البيانات التي يمكن الوصول إليها بلا إنترنت. 
• تطبيقات عدّاد الخطوات التي تجلب عدد الخطوات بشكل دوري

كيفية الحدّ من عمليات قفل التنشيط: 

• لا تحصل على قفل تنشيط يدوي. استخدِم WorkManager الذي تم إعداده لتنفيذ مهام لمرة واحدة أو بشكل دوري. تحترم WorkManager حالة النظام من خلال تجميع المهام، ولها حد أدنى للفاصل الزمني الدوري (15 دقيقة)، وهو ما يكفي بشكل عام لإجراء التحديثات في الخلفية. 
• إذا رصدت عمليات قفل تنشيط أنشأها WorkManager أو JobScheduler مع ارتفاع معدّل استخدام عمليات قفل التنشيط، قد يكون ذلك بسبب إعدادات المنفِّذ غير الصحيحة التي تمنعه من إكمال العمل في سيناريوهات معيّنة. ننصحك بتحليل أسباب توقّف المنفِّذ، خاصةً إذا لاحظت تكرارًا كبيرًا للخطأ STOP_REASON_TIMEOUT. 

workManager.getWorkInfoByIdFlow(syncWorker.id)
  .collect { workInfo ->
      if (workInfo != null) {
        val stopReason = workInfo.stopReason
        logStopReason(syncWorker.id, stopReason)
      }
  }

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

الاتصال عبر البلوتوث

أمثلة على حالات الاستخدام: 

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

كيفية الحدّ من عمليات قفل التنشيط: 

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

تتبع المواقع

أمثلة على حالات الاستخدام: 

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

كيفية الحدّ من عمليات قفل التنشيط: 

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

override fun onCreate(savedInstanceState: Bundle?) {
    locationCallback = object : LocationCallback() {
        override fun onLocationResult(locationResult: LocationResult?) {
            locationResult ?: return
            // System wakes up CPU for short duration
            for (location in locationResult.locations){
                // Store data in memory to process at another time
            }
        }
    }
}

مراقبة المستشعرات ذات التردد العالي

أمثلة على حالات الاستخدام: 

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

كيفية الحدّ من عمليات قفل التنشيط: 

• في حال استخدام SensorManager، يجب تقليل الاستخدام إلى فواصل زمنية دورية وعندما يمنح المستخدم الإذن بالوصول بشكل صريح من خلال تفاعل مع واجهة المستخدم فقط. يمكن أن يؤدي رصد بيانات أجهزة الاستشعار بمعدّل تكرار عالٍ إلى استنزاف البطارية بشكل كبير بسبب عدد عمليات تنشيط وحدة المعالجة المركزية والمعالجة التي تحدث.
• إذا كنت تتتبّع عدد الخطوات أو المسافة المقطوعة، بدلاً من استخدام SensorManager، يمكنك الاستفادة من Recording API أو استخدام Health Connect للوصول إلى عدد الخطوات السابقة والمجمّعة على الجهاز من أجل تسجيل البيانات بطريقة موفّرة لشحن البطارية.
• إذا كنت تسجّل مستشعرًا باستخدام SensorManager، حدِّد قيمة maxReportLatencyUs تبلغ 30 ثانية أو أكثر للاستفادة من تجميع بيانات المستشعر من أجل تقليل معدّل تكرار مقاطعات وحدة المعالجة المركزية. عندما يتم تنشيط الجهاز لاحقًا من خلال مشغّل آخر، مثل تفاعل المستخدم أو استرداد الموقع الجغرافي أو مهمة مجدوَلة، سيرسل النظام على الفور بيانات جهاز الاستشعار المخزَّنة مؤقتًا.

val accelerometer = sensorManager.getDefaultSensor(Sensor.TYPE_ACCELEROMETER)

sensorManager.registerListener(this,
                 accelerometer,
                 samplingPeriodUs, // How often to sample data
                 maxReportLatencyUs // Key for sensor batching 
              )

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

المراسلة عن بُعد

أمثلة على حالات الاستخدام: 

• تطبيقات مصاحبة لمراقبة الفيديو أو الصوت تحتاج إلى مراقبة الأحداث التي تحدث على جهاز خارجي متصل باستخدام شبكة محلية
• تطبيقات المراسلة التي تحافظ على اتصال مقبس الشبكة مع إصدار سطح المكتب

كيفية الحدّ من عمليات قفل التنشيط: 

• إذا كان من الممكن معالجة أحداث الشبكة من جهة الخادم، استخدِم FCM لتلقّي المعلومات على الجهاز. يمكنك اختيار جدولة عامل سريع إذا كانت هناك حاجة إلى معالجة إضافية لبيانات FCM. 
• إذا كان يجب معالجة الأحداث من جهة العميل من خلال اتصال socket، لن يكون قفل التنشيط مطلوبًا للاستماع إلى مقاطعات الأحداث. عند وصول حِزم البيانات إلى راديو Wi-Fi أو شبكة الجوّال، يؤدي جهاز الراديو إلى إطلاق مقاطعة للأجهزة في شكل قفل التنشيط.يمكنك بعد ذلك اختيار جدولة منفِّذ أو الحصول على قفل التنشيط لمعالجة البيانات.
• على سبيل المثال، إذا كنت تستخدم ktor-network لتتبّع حِزم البيانات على مقبس شبكة، يجب ألا تحصل على قفل التنشيط إلا عند تسليم الحِزم إلى العميل والحاجة إلى معالجتها.

val readChannel = socket.openReadChannel()
while (!readChannel.isClosedForRead) {
    // CPU can safely sleep here while waiting for the next packet
    val packet = readChannel.readRemaining(1024) 
    if (!packet.isEmpty) {
         // Data Arrived: The system woke the CPU and we should keep it awake via manual wake lock (urgent) or scheduling a worker (non-urgent)
         performWorkWithWakeLock { 
              val data = packet.readBytes()
              // Additional logic to process data packets
         }
    }
}

ملخّص

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