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

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

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

وفقًا لمايانك سايني، كبير مهندسي Android في WHOOP،  "أتاحت هذه المشكلة للفريق فرصة تحسين كفاءة Android"، وذلك بعد أن رصدت "مؤشرات Android الحيوية" أنّ نسبة عمليات قفل التنشيط الجزئي الزائدة عن الحد في التطبيق تبلغ %15، وهو ما يتجاوز الحدّ الموصى به البالغ %5.

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

تحديد المشكلة

لمعرفة كيفية البدء، لجأ الفريق أولاً إلى "مؤشرات Android الحيوية" للحصول على مزيد من الإحصاءات حول عمليات قفل التنشيط التي تؤثّر في المقياس. من خلال الرجوع إلى لوحة بيانات عمليات الإغلاق الجزئية المفرطة في Android vitals، تمكّن الفريق من تحديد أنّ أكبر مساهم في عمليات الإغلاق الجزئية المفرطة هو أحد العاملين في WorkManager (المحدّد في لوحة البيانات باسم androidx.work.impl.background.systemjob.SystemJobService). ولدعم ميزة "التجربة الدائمة" في WHOOP، يستخدم التطبيق WorkManager لتنفيذ مهام في الخلفية، مثل المزامنة الدورية وتقديم التحديثات المتكررة للجهاز القابل للارتداء. 

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

بعد أن حدّدت لوحة البيانات أنّ WorkManager هو المساهم الرئيسي، تمكّن الفريق من تركيز جهوده على تحديد أي من العاملين يساهم بشكل أكبر والعمل على حلّ المشكلة.

الاستفادة من المقاييس والبيانات الداخلية لتحديد السبب بشكل أفضل

كانت شركة WHOOP قد أعدّت بنية أساسية داخلية لتتبُّع مقاييس WorkManager. تتم مراقبة ما يلي بشكل دوري:

1. متوسط مدة التشغيل: ما هي المدة التي يعمل فيها العامل؟
2. مهلة انتهاء الوقت: كم مرة تنتهي مهلة العامل بدلاً من إكمال المهمة؟
3. عمليات إعادة المحاولة: كم عدد المرات التي يعيد فيها العامل المحاولة إذا انتهت مهلة العمل أو تعذّر إكماله؟
4. عمليات الإلغاء: كم مرة تم إلغاء العمل؟

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

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

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

التحقيق: التمييز بين أشكال العاملين

تستخدم WHOOP كلاً من الجدولة لمرة واحدة والجدولة الدورية لبعض العاملين. يتيح ذلك للتطبيق إعادة استخدام منطق Worker نفسه للمهام المتطابقة التي تتضمّن معايير النجاح نفسها، مع اختلاف التوقيت فقط.

وقد أتاحت لهم مقاييسهم الداخلية تضييق نطاق البحث ليشمل عاملًا معيّنًا، ولكن لم يتمكّنوا من معرفة ما إذا حدث الخطأ عندما كان العامل يعمل لمرة واحدة أو بشكل دوري أو كليهما. لذلك، طرحوا تحديثًا لاستخدام طريقة setTraceTag في WorkManager للتمييز بين المتغيرات التي يتم تنفيذها لمرة واحدة والمتغيرات الدورية من Worker نفسه.

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

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

التعمّق في سلوك العاملين ومعالجة السبب الجذري

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

وقد أدّى كل ذلك إلى تحديد السبب الأساسي لعمليات قفل التنشيط الزائدة عن الحدّ، وهو:

‫CoroutineWorker مصمَّم لانتظار الاتصال بجهاز استشعار WHOOP قبل المتابعة. 

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

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

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

class SensorWorker(appContext: Context, params: WorkerParameters): CoroutineWorker(appContext, params) {
   override suspend fun doWork(): Result {
      ...
      // Check the sensor state and perform work or return failure
       return whoopSensorFlow.replayCache
            .firstOrNull()
            ?.let { cachedData ->
                processSensorData(cachedData)
                Result.success()
            } ?: run {
                Result.failure()
            }
}

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

بعد طرح الإصلاح، واصل الفريق مراقبة لوحة بيانات "مؤشرات Android الحيوية" للتأكّد من تأثير التغييرات. 

في النهاية، لاحظت WHOOP انخفاض النسبة المئوية لقفل التنشيط الجزئي المفرط من% 15 إلى أقل من%1 بعد 30 يومًا فقط من تطبيق التغييرات على Worker. 

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

إليك نصيحة فريق WHOOP للمطوّرين الآخرين الذين يريدون تحسين كفاءة العمل في الخلفية:

البدء

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