چگونه WHOOP جلسه‌های تکرار مفرط قفل بیداری جزئی را بیش‌از ۹۰٪ کاهش داد

ساختن برنامه Android برای دستگاه پوشیدنی یعنی کار واقعی زمانی شروع می‌شود که صفحه‌نمایش خاموش می‌شود. WHOOP به اعضا کمک می‌کند بفهمند بدنشان چگونه به تمرین، ریکاوری، خواب، و استرس پاسخ می‌دهد، و برای بسیاری از اعضای WHOOP در Android، همگام‌سازی و اتصال‌پذیری مطمئن در پس‌زمینه همان چیزی است که این اطلاعات آماری را ممکن می‌سازد.

اوایل امسال، Google Play سنجه جدیدی را در «معیارهای کلیدی Android» منتشر کرد: قفل‌های بیداری جزئی بیش‌ازحد. این سنجه درصد جلسه‌های کاربر را که در آن استفاده تجمعی و غیرمعاف از قفل بیداری از ۲ ساعت در یک دوره ۲۴ ساعته فراتر می‌رود اندازه‌گیری می‌کند. هدف این سنجه کمک به شما در شناسایی و رفع منابع احتمالی تخلیه باتری است که برای ارائه تجربه کاربری عالی بسیار مهم است.

از ۱ مارس ۲۰۲۶، برنامه‌هایی که همچنان آستانه کیفیت را برآورده نکنند ممکن است از سطوح کاوش Google Play حذف شوند. همچنین ممکن است هشداری در فهرستگان «فروشگاه Google Play» قرار داده شود که نشان می‌دهد برنامه ممکن است بیش‌از حد انتظار باتری مصرف کند.

به‌گفته مایانک ساینی، مهندس ارشد Android در WHOOP، این موضوع «فرصتی را برای تیم فراهم کرد تا سطح کارایی Android را ارتقا دهند»، پس‌از اینکه «معیارهای کلیدی Android» درصد قفل بیداری جزئی بیش‌ازحد برنامه را ۱۵٪ نشان داد که از آستانه توصیه‌شده ۵٪ فراتر رفته بود.

تیم سنجه «معیارهای کلیدی Android» را به‌عنوان نشانه‌ای واضح از اینکه کار پس‌زمینه آن‌ها واحد پردازش مرکزی را بیشتر از حد لازم بیدار نگه می‌دارد درنظر گرفت. حل این مشکل به آن‌ها اجازه می‌دهد تا همچنان تجربه کاربری عالی ارائه دهند و درعین‌حال زمان تلف‌شده در پس‌زمینه را کاهش دهند و اتصال و همگام‌سازی بلوتوث قابل‌اعتماد و به‌موقع را حفظ کنند.

شناسایی مشکل

برای اینکه تیم متوجه شود از کجا باید شروع کند، ابتدا به «معیارهای کلیدی Android» مراجعه کرد تا اطلاعات آماری بیشتری درباره اینکه کدام قفل‌های بیداری بر سنجه تأثیر می‌گذارند به‌دست آورد. با مراجعه به داشبورد قفل‌های بیداری جزئی بیش‌ازحد معیارهای کلیدی Android، آن‌ها توانستند بزرگ‌ترین عامل قفل‌های بیداری جزئی بیش‌ازحد را به‌عنوان یکی از کارگران WorkManager خود (که در داشبورد به‌عنوان androidx.work.impl.background.systemjob.SystemJobService شناسایی شده است) شناسایی کنند. برای پشتیبانی از «تجربه همیشه روشن» WHOOP، برنامه از WorkManager برای کارهای پس‌زمینه مانند همگام‌سازی دوره‌ای و ارائه به‌روزرسانی‌های مکرر به دستگاه پوشیدنی استفاده می‌کند. 

درحالی‌که تیم می‌دانست که WorkManager قفل بیداری را هنگام اجرای تکالیف در پس‌زمینه به‌دست می‌آورد، قبلاً تا قبل‌از معرفی سنجه قفل‌های بیداری جزئی بیش‌ازحد در معیارهای کلیدی Android، دیدی نسبت به نحوه توزیع همه کارهای پس‌زمینه خود (فراتر از WorkManager) نداشتند.

با شناسایی WorkManager به‌عنوان عامل اصلی در داشبورد، تیم توانست تلاش‌های خود را بر شناسایی کدام از کارگران خود که بیشترین سهم را داشتند متمرکز کند و برای حل مشکل تلاش کند.

استفاده از سنجه‌ها و داده‌های داخلی برای محدود کردن بهتر علت

WHOOP ازقبل زیرساخت داخلی را برای نظارت بر سنجه‌های WorkManager راه‌اندازی کرده بود. آن‌ها به‌طور دوره‌ای موارد زیر را پایش می‌کنند:

1. میانگین زمان اجرا: کارگر برای چه مدت اجرا می‌شود؟
2. زمان‌های اتمام: چند وقت یک‌بار کارگر به‌جای تکمیل کردن، زمانش تمام می‌شود؟
3. تلاش‌های مجدد: اگر زمان کار تمام شود یا کار ناموفق باشد، کارگر چند وقت یک‌بار دوباره تلاش می‌کند؟
4. لغوها: چندبار کار لغو شده است؟

ردیابی چیزی فراتر از موفقیت‌ها و شکست‌های کارگر به تیم امکان می‌دهد کارایی کارشان را ببینند.

سنجه‌های داخلی زمان اجرای میانگین بالا را برای چند کارگر منتخب پرچم‌گذاری کردند و به آن‌ها امکان دادند تا تحقیقات را بیشتر محدود کنند. 

تیم علاوه‌بر سنجه‌های داخلی خود، از بازرس وظایف پس‌زمینه Android Studio نیز برای بازرسی و اشکال‌زدایی کارگران موردنظر استفاده کرد، با تمرکز ویژه بر قفل‌های بیداری مرتبط، تا با سنجه پرچم‌گذاری‌شده در معیارهای کلیدی 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()
            }
}

کاهش ۹۰ درصدی در جلسه‌های دارای قفل‌های بیداری جزئی بیش‌ازحد

پس‌از عرضه اصلاحیه، تیم به نظارت بر داشبورد «معیارهای کلیدی Android» ادامه داد تا تأثیر تغییرات را تأیید کند. 

درنهایت، WHOOP شاهد بود که درصد قفل بیداری جزئی بیش‌ازحد آن‌ها از ۱۵٪ به کمتر از ۱٪ کاهش یافت، آن هم فقط ۳۰ روز پس‌از اعمال تغییرات در Worker. 

درنتیجه این تغییرات، تیم شاهد موارد کمتری از اتمام زمان کار بدون تکمیل شدن بوده است که منجر به کاهش میانگین زمان اجرا شده است. 

توصیه تیم WHOOP به توسعه‌دهندگان دیگری که می‌خواهند کارایی کار پس‌زمینه خود را بهبود بخشند:

شروع به کار

اگر می‌خواهید قفل‌های بیداری جزئی بیش‌ازحد برنامه‌تان را کاهش دهید یا کارایی کارگر را بهبود ببخشید، سنجه قفل‌های بیداری جزئی بیش‌ازحد برنامه‌تان را در معیارهای کلیدی Android مشاهده کنید و برای روال‌های مطلوب و استراتژی‌های اشکال‌زدایی بیشتر، اسناد قفل‌های بیداری را مرور کنید.