Mobil Uygulamada Pil Tüketimini Artıran 6 Sessiz Hata

Pil tüketimi, mobil uygulamalarda en geç fark edilen ama en sert cezalandırılan performans sorunudur. Kullanıcı yavaş bir ekrana katlanır, ama telefonunun öğlen yarılanmasına katlanmaz — ve modern işletim sistemleri, pili çok tüketen uygulamayı doğrudan kullanıcıya raporlar. Bu yazıda sahada en sık karşılaştığımız altı sessiz hatayı ve her birinin nasıl ölçüleceğini ele alıyoruz.

Önce doğru zihin modeli: neyin pahalı olduğu

Optimizasyona başlamadan önce maliyet sıralamasını bilmek gerekir. Bir mobil cihazda enerji tüketiminin büyük kısmı işlemciden değil, radyolardan ve ekrandan gelir. Hücresel veri bağlantısı, uyku hâlinden çıkıp veri gönderdikten sonra bir süre daha yüksek güç durumunda kalır. Bu yüzden 10 KB'lık tek bir istek ile 1 KB'lık on ayrı istek arasındaki enerji farkı, veri boyutu farkıyla değil, radyoyu kaç kez uyandırdığınızla ilgilidir. GPS ise ayrı bir kategoridedir: yüksek hassasiyetli konum, gözle görülür bir tüketim kalemidir.

1. Gereğinden hassas konum takibi

En yaygın hata, uygulamanın ihtiyacı olmadığı hâlde en yüksek hassasiyette ve en sık aralıkta konum istemesidir. Kullanıcının hangi şehirde olduğunu bilmek istiyorsanız, metre hassasiyetinde GPS'e ihtiyacınız yoktur; ağ tabanlı düşük hassasiyetli konum yeterlidir ve enerji maliyeti kat kat düşüktür. Ayrıca konum güncellemelerini ekran kapandığında veya uygulama arka plana alındığında durdurmak, tek satırlık bir değişiklikle büyük kazanç sağlar.

2. Sık uyanma: küçük zamanlayıcıların toplamı

"Her 30 saniyede bir kontrol et" gibi bir zamanlayıcı, tek başına zararsız görünür. Ancak cihazı derin uyku durumundan çıkarmak sabit bir maliyet doğurur ve bu maliyet çağrı başına ödenir. Doğru yaklaşım, işleri toplu ve esnek hâle getirmektir: "şu iş bir saat içinde bir kere yapılsın, sistem uygun bulduğu anda çalıştırsın" demek, sisteme farklı uygulamaların işlerini aynı uyanmada birleştirme fırsatı verir. Android'de WorkManager, iOS'ta arka plan görev API'leri tam olarak bunun içindir.

3. Toplanmamış ağ istekleri

Ekran açıldığında sırayla atılan yedi ayrı istek, hem gecikme hem enerji açısından pahalıdır. Bu istekleri tek bir uçta birleştirmek veya en azından paralel gönderip radyonun tek uyanmasını kullanmak gerekir. Ayrıca acil olmayan telemetri ve analitik verilerini anında göndermek yerine biriktirip cihaz şarjdayken veya Wi-Fi'a bağlıyken göndermek yaygın ve etkili bir pratiktir.

API tarafında da uçların bu ihtiyaca uygun tasarlanması gerekir; tek istekte gereken veriyi döndüren uçlar için REST API tasarım rehberimize, yanıt sürelerini düşürmenin sunucu tarafı yöntemleri için API hızlandırma yazımıza bakabilirsiniz.

4. Çevrimdışı senaryonun düşünülmemesi

Bağlantı zayıfken yapılan istekler, başarısız olup tekrar denendiğinde enerji açısından en pahalı durumu yaratır: radyo sürekli uyanır, veri gitmez. Üstel geri çekilme (exponential backoff) ile yeniden deneme aralığını artırmak ve bağlantı yokken hiç denememek şarttır. Bu, aynı zamanda bir mimari tercihtir; çevrimdışı öncelikli tasarımın gözden kaçan ayrıntıları için offline-first yazımıza göz atın.

5. Bitmeyen arka plan işleri ve wake lock

Bir wake lock alıp serbest bırakmayı unutmak, cihazın hiç uyumaması demektir — ve bu, pil tüketiminin en dramatik biçimidir. Benzer şekilde, iş bittiği hâlde sonlandırılmayan servisler ve iptal edilmeyen abonelikler sessizce çalışmaya devam eder. Kural basittir: her wake lock için bir finally bloğu, her abonelik için yaşam döngüsüne bağlı bir iptal.

6. Ekran açıkken sürekli yeniden çizim

Duran bir ekranda saniyede 60 kez yeniden çizilen bir arayüz, hem GPU'yu hem ekranı meşgul eder. Gereksiz yeniden çizimlerin en sık sebebi, durum yönetiminde çok geniş kapsamlı güncellemelerdir: küçük bir değerin değişmesi tüm ağacın yeniden oluşturulmasına yol açar. Sonsuz döngüde çalışan dekoratif animasyonlar da özellikle liste ekranlarında ciddi maliyet üretir.

Nasıl ölçülür?

Tahminle optimizasyon yapmak burada da işe yaramaz. Somut araçlar mevcuttur:

• Android: Battery Historian ve adb shell dumpsys batterystats, hangi uygulamanın kaç kez uyandığını ve radyoyu ne kadar meşgul ettiğini gösterir.
• iOS: Xcode Instruments'ın Energy Log şablonu, konum ve ağ kullanımını zaman çizelgesi üzerinde işaretler.
• Her iki platform: Cihaz ayarlarındaki pil kullanım ekranı, kullanıcının gördüğü gerçeği gösterdiği için son doğrulama adımı olarak kullanılmalıdır.

Ölçüm disiplininin genel mantığı web tarafındakiyle aynıdır: önce ölçüp sonra müdahale etmek; bu yaklaşımın ayrıntıları için ölçerek başlama yazımıza bakabilirsiniz. Platform tarafındaki resmî rehber ise Android güç tüketimi dokümantasyonudur.

Sonuç

Pil tüketimi, kod kalitesinden çok mimari kararların sonucudur: ne sıklıkla uyandığınız, radyoyu kaç kez açtığınız ve arka planda ne kadar süre yaşadığınız. İyi haber şu ki bu altı hatanın çoğu, büyük bir yeniden yazım gerektirmeden düzeltilebilir — konum hassasiyetini düşürmek, istekleri toplamak ve arka plan işlerini esnek zamanlamaya taşımak çoğu uygulamada kazancın büyük kısmını getirir. Bir sonraki sürümden önce uygulamanızı bir saat boyunca arka planda bırakıp pil raporuna bakın; oradaki sayı, kullanıcınızın göreceği sayıdır.