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

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

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

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

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

شناسایی مسئله

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

اگرچه تیم از این موضوع آگاه بود که WorkManager هنگام اجرای وظایف در پس‌زمینه، قفل بیداری (wake lock) می‌گیرد ، اما پیش از معرفی معیار قفل بیداری جزئی بیش از حد در داده‌های حیاتی اندروید، از نحوه توزیع تمام کارهای پس‌زمینه خود (به جز WorkManager) اطلاعی نداشتند.

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

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

WHOOP از قبل زیرساخت داخلی برای نظارت بر معیارهای WorkManager راه‌اندازی کرده بود. آنها به صورت دوره‌ای موارد زیر را رصد می‌کنند:

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

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

معیارهای داخلی، میانگین زمان اجرای بالا را برای تعداد کمی از کارگران منتخب نشان دادند و به آنها امکان دادند تا تحقیقات را حتی بیشتر محدود کنند.

علاوه بر معیارهای داخلی خود، این تیم همچنین از ابزار Background Task Inspector اندروید استودیو برای بررسی و اشکال‌زدایی Workerهای مورد نظر، با تمرکز ویژه بر wake lockهای مرتبط، استفاده کرد تا با معیار مشخص‌شده در Android Vitals همسو شود.

تحقیق: تمایز قائل شدن بین انواع کارگران

WHOOP برای برخی از کارگران از هر دو روش برنامه‌ریزی یک‌باره و دوره‌ای استفاده می‌کند. این به برنامه اجازه می‌دهد تا از منطق کارگر یکسان برای وظایف یکسان با معیارهای موفقیت یکسان، که فقط در زمان‌بندی متفاوت هستند، دوباره استفاده کند.

استفاده از معیارهای داخلی آنها این امکان را فراهم کرد که جستجوی خود را به یک worker خاص محدود کنند، اما آنها نمی‌توانستند تشخیص دهند که آیا این اشکال زمانی رخ داده است که worker یک‌باره، دوره‌ای یا هر دو بوده است. بنابراین، آنها یک به‌روزرسانی ارائه دادند تا از متد setTraceTag در WorkManager برای تمایز بین انواع یک‌باره و دوره‌ای یک worker استفاده کنند.

این جزئیات اضافی به آنها اجازه می‌دهد تا به طور قطعی مشخص کنند که کدام نوع Worker (دوره‌ای یا یکباره) بیشترین سهم را در جلسات با قفل‌های بیداری جزئی بیش از حد دارد. با این حال، تیم وقتی داده‌ها نشان داد که به نظر نمی‌رسد هیچ یک از این دو نوع بیشتر از دیگری نقش داشته باشند، شگفت‌زده شد.

منمیت توتجا، مهندس اندروید دوم در WHOOP، گفت: «این جدایی همچنین به ما کمک کرد تا تأیید کنیم که مشکل در هر دو نوع وجود داشته است، که این موضوع از پیکربندی زمان‌بندی به سمت یک مشکل منطق کسب‌وکار مشترک در پیاده‌سازی worker اشاره داشت.»

بررسی عمیق‌تر رفتار کارگران و ریشه‌یابی علت آن

با علم به اینکه باید منطق درونی کارگر را بررسی کنند، تیم رفتار کارگر را برای کارگرانی که در طول تحقیقاتشان علامت‌گذاری شده بودند، دوباره بررسی کرد. به طور خاص، آنها به دنبال مواردی بودند که ممکن است کار گیر کرده و تکمیل نشده باشد.

همه اینها در یافتن علت اصلی قفل‌های بیداری بیش از حد به اوج خود رسید:

یک CoroutineWorker که طوری طراحی شده بود که قبل از ادامه، منتظر اتصال به حسگر WHOOP بماند.

اگر کار بدون اتصال سنسور شروع می‌شد، whoopSensorFlow - که نشان می‌دهد سنسور متصل است یا خیر - null بود. SensorWorker این را به عنوان یک وضعیت خروج زودهنگام در نظر نگرفت و به اجرا ادامه داد و عملاً به طور نامحدود منتظر اتصال ماند. در نتیجه، WorkManager قفل بیداری جزئی را تا زمان اتمام زمان کار نگه داشت که منجر به استفاده زیاد از قفل بیداری در پس‌زمینه و تغییر زمان‌بندی مکرر و ناخواسته SensorWorker شد.

برای رسیدگی به این مشکل، تیم WHOOP منطق worker را به‌روزرسانی کرد تا قبل از تلاش برای اجرای منطق اصلی کسب‌وکار، وضعیت اتصال را بررسی کند.

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

  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 Vitals ادامه داد تا تأثیر تغییرات را تأیید کند.

در نهایت، شرکت WHOOP تنها پس از 30 روز شاهد کاهش درصد قفل بیداری جزئی بیش از حد خود از 15٪ به کمتر از 1٪ بود.   پس از اعمال تغییرات در Worker خود.

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

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

شروع کنید

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