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

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

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

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

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

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

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

لمعرفة من أين يبدأ، لجأ الفريق أولاً إلى "مؤشرات Android الحيوية" للحصول على مزيد من الإحصاءات حول أقفال التنشيط التي تؤثر في المقياس. من خلال الاطّلاع على لوحة بيانات عمليات قفل التنشيط الجزئية الزائدة في "مؤشرات Android الحيوية"، تمكّن الفريق من تحديد أكبر مساهم في عمليات قفل التنشيط الجزئية الزائدة، وهو أحد عمال 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 (دوري أو لمرة واحدة) الذي يساهم بشكل أكبر في الجلسات التي تتضمّن أقفال تنشيط جزئية مفرطة. ومع ذلك، تفاجأ الفريق عندما كشفت البيانات أن أيًا من المتغيرين لم يساهم أكثر من الآخر.

قال "مانميت توتيجا"، مهندس 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 الحيوية، ومراجعة مستندات عمليات قفل التنشيط للحصول على المزيد من أفضل الممارسات واستراتيجيات تصحيح الأخطاء.