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

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

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

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

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

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

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

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

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

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

كان لدى WHOOP بالفعل بنية تحتية داخلية تم إعدادها لمراقبة مقاييس WorkManager. يقومون بمراقبة دورية:

1. متوسط ​​وقت التشغيل: ما هي مدة تشغيل العامل؟

2. المهلات: ما هو عدد المرات التي يقضي فيها العامل مهلة العمل بدلاً من إكمالها؟

3. إعادة المحاولة: كم مرة يقوم العامل بإعادة المحاولة إذا انتهت مهلة العمل أو فشل؟

4. الإلغاءات: كم مرة تم إلغاء العمل؟

إن تتبع أكثر من مجرد نجاحات وإخفاقات العمال يمنح الفريق رؤية واضحة لكفاءة عملهم.

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

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

التحقيق: التمييز بين متغيرات العامل

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

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

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

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

الغوص بشكل أعمق في سلوك العمال وإصلاح السبب الجذري

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

كل هذا بلغ ذروته في العثور على السبب الجذري لأقفال التنشيط المفرطة:

CoroutineWorker تم تصميمه لانتظار الاتصال بمستشعر WHOOP قبل المتابعة.

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

لمعالجة هذه المشكلة، قام فريق 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 يومًا فقط بعد تنفيذ التغييرات على عاملهم.