Giyilebilir cihazlar için Android uygulaması geliştirirken ekran kapandığında asıl iş başlar. WHOOP, üyelerin vücutlarının antrenman, toparlanma, 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 (önerilen %5 eşiğini aşarak) bu durum, "ekibe Android verimliliğini artırma fırsatı sundu".

Ekip, Android vitals metriğini arka planda yapılan çalışmanı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 kilidine en büyük katkıyı sağlayan öğenin WorkManager çalışanlarından biri (kontrol panelinde androidx.work.impl.background.systemjob.SystemJobService olarak tanımlanır) olduğunu belirlediler. Uygulama, WHOOP'un "her zaman açık deneyimini" desteklemek için periyodik senkronizasyon ve giyilebilir cihaza yinelenen güncellemeler sunma gibi arka plan görevlerinde WorkManager'ı kullanıyor. 

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 temel 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ı zaten kurmuştu. Aşağıdaki öğeler düzenli olarak izlenir:

1. Ortalama Çalışma Süresi: Çalışan ne kadar süre çalışır?
2. Zaman aşımları: Çalışan, tamamlamak yerine ne sıklıkta zaman aşımına uğruyor?
3. Yeniden denemeler: İşin zaman aşımına uğraması veya başarısız olması durumunda ç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ğlar.

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 Studio'nun Background Task Inspector'ını kullanarak ilgilendikleri çalışanları denetledi ve hatalarını ayıkladı. Android vitals'da işaretlenen metriğe uygun şekilde, ilişkili uyanık kalma kilitlerine özellikle odaklandı.

İnceleme: İşçi 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 zamanlaması farklı olan ve aynı başarı ölçütlerine sahip olan aynı görevler için aynı Worker mantığını yeniden kullanabilir.

Şirket, kendi dahili metriklerini kullanarak aramayı belirli bir çalışana daraltabildi ancak hatanın, çalışan bir kerelik, düzenli veya her ikisi de çalışırken mi oluştuğunu belirleyemedi. Bu nedenle, aynı Worker'ın tek seferlik ve periyodik varyantları arasında ayrım yapmak 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, iki varyantın da diğerinden daha fazla katkıda bulunmadığını gösterdiğinde 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ıyla ilgili olmadığını, çalışan uygulamasında ortak bir iş mantığı sorunu olduğunu gösteriyordu." 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 olarak gösterilir. 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ş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ş 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 çalışan, 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ümanını inceleyin.