WHOOP, aşırı sayıda kısmi uyanık kalma kilidi oturumlarını %90'dan fazla nasıl azalttı?

Giyilebilir cihazlar için Android uygulaması geliştirirken asıl iş, ekran kapandığında başlar. WHOOP, üyelerin vücutlarının antrenman, dinlenme, uyku ve strese nasıl tepki verdiğini anlamalarına yardımcı olur. Android'deki birçok WHOOP üyesi için bu analizleri mümkün kılan şey, güvenilir arka plan senkronizasyonu ve bağlantıdır.

Google Play, bu yılın başlarında Android vitals'da yeni bir metrik yayınladı: Aşırı sayıda kısmi uyanık kalma kilitleri. Bu metrik, 24 saatlik bir dönemde kümülatif, muaf olmayan uyanık kalma kilidi kullanımının 2 saati aştığı kullanıcı oturumlarının yüzdesini ölçer. Bu metriğin amacı, pil tüketiminin olası kaynaklarını belirleyip gidermenize yardımcı olmaktır. Bu, mükemmel bir kullanıcı deneyimi sunmak için çok önemlidir.

1 Mart 2026'dan itibaren, kalite eşiğini karşılamamaya devam eden uygulamalar Google Play keşif yüzeylerinden hariç tutulabilir. Ayrıca Google Play Store girişine, uygulamanın beklenenden daha fazla pil kullanabileceğini belirten bir uyarı yerleştirilebilir.

WHOOP'un Kıdemli Android Mühendisi Mayank Saini'ye göre, Android vitals'ın uygulamanın aşırı sayıda kısmi uyanık kalma kilidi yüzdesini %15 olarak işaretlemesi (önerilen %5 eşiğini aşması) "ekibe Android verimliliğini artırma fırsatı sundu".

Ekip, Android vitals metriğini, arka plan çalışmalarının CPU'yu gereğinden uzun süre uyanık tuttuğuna dair net bir sinyal olarak değerlendirdi. Bu sorunun çözülmesi, uygulamanın arka planda harcadığı süreyi azaltırken ve güvenilir, zamanında Bluetooth bağlantısı ve senkronizasyonu sağlarken mükemmel bir kullanıcı deneyimi sunmaya devam etmesine olanak tanır.

Sorunu belirleme

Ekip, nereden başlayacağını belirlemek için öncelikle Android vitals'a başvurarak metriği hangi uyanık kalma kilitlerinin etkilediği hakkında daha fazla bilgi edindi. Android vitals aşırı kısmi uyanık kalma kilitleri kontrol panelini inceleyerek aşırı kısmi uyanık kalma kilitlerine en çok katkıda bulunan unsurun WorkManager çalışanlarından biri olduğunu (kontrol panelinde androidx.work.impl.background.systemjob.SystemJobService olarak tanımlanır) tespit ettiler. WHOOP "her zaman açık deneyimini" desteklemek için uygulama, periyodik senkronizasyon ve giyilebilir cihaza yinelenen güncellemeler gönderme gibi arka plan görevleri için WorkManager'ı kullanır. 

Ekip, WorkManager'ın arka planda görevleri yürütürken uyanık kalma kilidi aldığını biliyordu. Ancak Android vitals'da aşırı kısmi uyanık kalma kilitleri metriği kullanıma sunulana kadar, arka plan çalışmalarının tamamının (WorkManager'ın ötesinde) nasıl dağıtıldığını göremiyordu.

Kontrol panelinde WorkManager'ın ana katkıda bulunan olarak tanımlanmasıyla ekip, çalışmalarını en çok katkıda bulunan çalışanlarının hangisi olduğunu belirlemeye ve sorunu çözmeye odaklanabildi.

Nedeni daha iyi belirlemek için dahili metriklerden ve verilerden yararlanma

WHOOP, WorkManager metriklerini izlemek için dahili altyapısını zaten oluşturmuştu. Periyodik olarak şunları izlerler:

1. Ortalama çalışma süresi: Çalışan ne kadar süre çalışıyor?
2. Zaman aşımları: Çalışan, görevi tamamlamak yerine ne sıklıkta zaman aşımına uğruyor?
3. Yeniden deneme sayısı: İş zaman aşımına uğradığında veya başarısız olduğunda çalışan ne sıklıkta yeniden dener?
4. İptaller: İş ne sıklıkta iptal edildi?

Çalışanların başarı ve başarısızlıklarından daha fazlasını takip etmek, ekibe çalışmalarının verimliliği hakkında görünürlük sağlar.

Dahili metrikler, seçilen birkaç çalışan için yüksek ortalama çalışma süresi olduğunu işaretleyerek araştırmayı daha da daraltmalarına olanak tanıdı. 

Ekip, dahili metriklerinin yanı sıra Android Studio'nun Background Task Inspector aracını kullanarak ilgili çalışanları inceleyip hatalarını ayıkladı. Bu süreçte, Android vitals'da işaretlenen metrikle uyumlu olması için özellikle ilişkili uyanık kalma kilitlerine odaklandı.

İnceleme: Çalışan varyantlarını ayırt etme

WHOOP, bazı çalışanlar için hem tek seferlik hem de periyodik planlama kullanır. Bu sayede uygulama, yalnızca zamanlama açısından farklılık gösteren aynı başarı ölçütlerine sahip aynı görevler için aynı Worker mantığını yeniden kullanabilir.

Dahili metriklerini kullanarak aramalarını belirli bir çalışanla daraltabildiler ancak hatanın çalışan tek seferlik, periyodik veya her ikisi olduğunda mı meydana geldiğini anlayamadılar. Bu nedenle, aynı Worker'ın tek seferlik ve periyodik varyantlarını ayırt etmek için WorkManager'ın setTraceTag yöntemini kullanan bir güncelleme yayınladılar.

Bu ek ayrıntı, aşırı kısmi uyanık kalma kilitleri içeren oturumlara en çok hangi Worker varyantının (periyodik veya tek seferlik) katkıda bulunduğunu kesin olarak belirlemelerini sağlar. Ancak ekip, verilerde iki varyantın da diğerinden daha fazla katkı sağlamadığını görünce şaşırdı.

WHOOP'ta Android Mühendisi II olarak çalışan Manmeet Tuteja, "Bu ayrım, sorunun her iki varyantta da yaşandığını doğrulamamıza yardımcı oldu. Bu da planlama yapılandırmasından ziyade çalışan uygulamasındaki ortak bir iş mantığı sorununa işaret ediyordu." dedi.

Çalışan davranışını daha ayrıntılı inceleme ve temel nedeni düzeltme

Ekip, çalışan içindeki mantığı incelemeleri gerektiğini bilerek, incelemeleri sırasında işaretlenen çalışanların davranışlarını yeniden inceledi. Özellikle, işlerin takılıp kalmış ve tamamlanmamış olabileceği durumları arıyorlardı.

Tüm bu çalışmaların sonucunda, aşırı sayıda uyanık kalma kilidinin temel nedeni bulundu:

Devam etmeden önce WHOOP sensörüne bağlantı kurulmasını bekleyecek şekilde tasarlanmış bir CoroutineWorker. 

Çalışma, bağlı sensör olmadan başladıysa sensörün bağlı olup olmadığını gösteren whoopSensorFlow, null değerini gösterir. SensorWorker bunu erken çıkış koşulu olarak değerlendirmedi ve çalışmaya devam ederek bağlantı için süresiz olarak bekledi. Sonuç olarak WorkManager, iş zaman aşımına uğrayana kadar kısmi bir uyanık kalma kilidi tuttu. Bu da arka planda uyanık kalma kilidinin yüksek düzeyde kullanılmasına ve SensorWorker uygulamasının sık sık, istenmeyen şekilde yeniden planlanmasına neden oldu.

WHOOP ekibi, bu sorunu çözmek için temel iş mantığını yürütmeye çalışmadan önce bağlantı durumunu kontrol edecek şekilde çalışan mantığını güncelledi.

Sensör kullanılamıyorsa çalışan, zaman aşımı senaryosunu önlemek ve uyanık kalma kilidini serbest bırakmak için çıkış yapar. Aşağıdaki kod snippet'inde çözüm gösterilmektedir:

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()
            }
}

Aşırı sayıda kısmi uyanık kalma kilidi içeren oturumlarda% 90 azalma elde etme

Ekip, düzeltmeyi kullanıma sunduktan sonra değişikliklerin etkisini doğrulamak için Android vitals kontrol panelini izlemeye devam etti. 

Sonuç olarak WHOOP, Worker'da değişiklikleri uyguladıktan sadece 30 gün sonra aşırı kısmi uyanık kalma kilidi yüzdesinin% 15'ten%1'in altına düştüğünü gördü. 

Değişikliklerin sonucunda ekip, işlerin tamamlanmadan zaman aşımına uğradığı durumların azaldığını ve ortalama çalışma sürelerinin kısaldığını gördü. 

WHOOP ekibinin, arka plan çalışmalarının verimliliğini artırmak isteyen diğer geliştiricilere tavsiyeleri:

Başlayın

Uygulamanızın aşırı sayıda kısmi uyanık kalma kilidini azaltmak veya çalışan verimliliğini artırmak istiyorsanız uygulamanızın aşırı sayıda kısmi uyanık kalma kilidi metriğini Android vitals'da görüntüleyin ve daha fazla en iyi uygulama ve hata ayıklama stratejisi için uyanık kalma kilitleri belgelerini inceleyin.