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

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

Bu yılın başlarında Google Play, Android vitals'da yeni bir metrik kullanıma sundu: 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ı, mükemmel bir kullanıcı deneyimi sunmak için çok önemli olan pilin hızlı tükenmesinin olası kaynaklarını belirlemenize ve gidermenize yardımcı olmaktır.

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

WHOOP'ta Kıdemli Android Mühendisi olan Mayank Saini'ye göre Android vitals, uygulamanın aşırı sayıda kısmi uyanık kalma kilidi yüzdesini %15 olarak işaretledikten sonra bu durum, "ekibe Android verimliliğini artırma fırsatı sundu". Bu değer, önerilen %5 eşiğini aşıyordu.

Ekip, Android vitals metriğini arka planda yapılan çalışmaların CPU'yu gereğinden uzun süre uyanık tuttuğuna dair net bir sinyal olarak değerlendirdi. Bu sorunun çözülmesi, kullanıcıların harika bir kullanıcı deneyimi sunmaya devam etmesini sağlarken aynı zamanda boşa harcanan arka plan süresini azaltır ve güvenilir, zamanında Bluetooth bağlantısı ve senkronizasyonu sağlar.

Sorunu belirleme

Nereden başlayacağını belirlemek için ekip öncelikle hangi uyandırma kilitlerinin metriği etkilediği hakkında daha fazla bilgi edinmek üzere Android vitals'a başvurdu. Android vitals aşırı sayıda kısmi uyanık kalma kilitleri kontrol paneline danışarak aşırı sayıda kısmi uyanık kalma kilitlerine en büyük katkıyı sağlayan faktörün WorkManager çalışanlarından biri (kontrol panelinde androidx.work.impl.background.systemjob.SystemJobService olarak tanımlanır) olduğunu belirlediler. WHOOP'un "her zaman açık deneyimini" desteklemek için uygulama, periyodik senkronizasyon ve giyilebilir cihaza yinelenen güncellemeler sunma gibi arka plan görevleri için WorkManager'ı kullanır. 

Ekip, görevleri arka planda yürütürken WorkManager'ın uyanık kalma kilidi aldığının farkında olsa da Android vitals'da aşırı sayıda kısmi uyanık kalma kilidi metriği kullanıma sunulana kadar tüm arka plan çalışmalarının (yalnızca WorkManager'ın değil) nasıl dağıtıldığı konusunda görünürlüğe sahip değildi.

Kontrol panelinde WorkManager'ın ana katkıda bulunan olarak tanımlanmasıyla ekip, çalışanlarından hangisinin en fazla katkıda bulunduğ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ı önceden ayarlamıştı. Aşağıdaki öğeler düzenli olarak izlenir:

1. Ortalama Çalışma Süresi: Çalışan ne kadar süreyle çalışır?
2. Zaman aşımları: Çalışan, tamamlamak yerine ne sıklıkta zaman aşımına uğruyor?
3. Yeniden denemeler: İşlem zaman aşımına uğrarsa veya başarısız olursa çalışan ne sıklıkta yeniden dener?
4. İptaller: İş ne sıklıkta iptal edildi?

Yalnızca çalışanların başarılarını ve hatalarını takip etmek yerine, ekibin çalışmalarının verimliliği hakkında bilgi edinmesini sağlayın.

Dahili metrikler, belirli birkaç çalışan için yüksek ortalama çalışma süresi olarak işaretlendi. Bu sayede, soruşturma kapsamı daha da daraltıldı. 

Ekip, dahili metriklerine ek olarak Android vitals'da işaretlenen metrikle uyumlu olmak için Android Studio'nun Arka Plan Görevi Denetleyicisi'ni kullanarak ilgilenilen çalışanları, özellikle de ilişkili uyandırma kilitlerine odaklanarak inceledi ve hatalarını ayıkladı.

Araştırma: İşçi varyantları arasında ayrım yapma

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

Şirket, dahili metriklerini kullanarak aramasını belirli bir çalışana daraltabildi ancak hatanın, çalışan bir kerelik, periyodik veya her ikisi de olduğunda mı oluştuğunu belirleyemedi. Bu nedenle, aynı Worker'ın tek seferlik ve periyodik varyantlarını ayırt etmek için WorkManager'ın setTraceTag yöntemini kullanacak bir güncelleme yayınladılar.

Bu ek ayrıntı, hangi Worker varyantının (periyodik veya tek seferlik) aşırı kısmi uyandırma kilitleri içeren oturumlara en çok katkıda bulunduğunu kesin olarak belirlemelerine olanak tanır. Ancak veriler, varyantlardan hiçbirinin diğerinden daha fazla katkıda bulunmadığını ortaya çıkardığında ekip ş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ı yerine çalışan uygulamasında ortak bir iş mantığı sorunu olduğunu gösterdi." dedi.

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

Ekip,  çalışanın içindeki mantığı incelemesi gerektiğini bildiğinden soruşturma 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 sonucunda aşırı sayıda uyanık kalma kilidinin temel nedeni bulundu:

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

Çalışma, sensör bağlı olmadan başlatıldıysa whoopSensorFlow (sensörün bağlı olup olmadığını gösterir) null idi. SensorWorker bunu erken çıkış koşulu olarak değerlendirmedi ve çalışmaya devam etti. Bu nedenle, bağlantı için süresiz olarak bekledi. Bu nedenle, WorkManager, işin zaman aşımına uğramasına kadar kısmi bir uyanık kalma kilidi tuttu. Bu durum, arka planda yüksek uyanık kalma kilidi kullanımına ve SensorWorker'nın sık sık ve istenmeyen şekilde yeniden planlanmasına neden oldu.

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

Sensör kullanılamıyorsa worker sınıfı, zaman aşımı senaryosunu önlemek ve uyanık kalma kilidini serbest bırakmak için çıkar. Çözüm aşağıdaki kod snippet'inde 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 sağlama

Düzeltmeyi kullanıma sunduktan sonra ekip, 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şiklikler sonucunda, ekibin tamamlanmadan zaman aşımına uğrayan iş örnekleri azaldı ve ortalama çalışma süreleri düştü. 

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

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 Android vitals'da uygulamanızın aşırı sayıda kısmi uyanık kalma kilidi metriğini görüntüleyin ve daha fazla en iyi uygulama ve hata ayıklama stratejisi için uyanık kalma kilitleri dokümanlarını inceleyin.