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

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