Mobil Uygulamada Pil Tüketimi: Ölçüm ve Optimizasyon

Mobil uygulamanda pil tüketimini ölçmeden optimize etmeye çalışmak, karanlıkta ok atmaktır. Bu rehberde mobil uygulama pil tüketimi optimizasyonunu hem iOS hem Android tarafında, resmi Apple ve Google dokümantasyonuna dayanarak; ölçüm araçlarından ağ ve konum optimizasyonlarına, gerçek cihazda A/B testine ve pil regresyonunu CI'da yakalamaya kadar adım adım ele alıyoruz.

💡 Pro Tip: Optimizasyona başlamadan önce Xcode Organizer'daki Battery Usage panelini veya Android'in profil araçlarını aç — hangi kategori (ağ, konum, CPU, ekran) en çok tükettiğini görmeden yaptığın her değişiklik tahmine dayalı kalır.

İçindekiler

• Pil Tüketiminin Dört Kaynağı: CPU, Ağ, Konum, Ekran
• CPU ve İşleme
• Ağ (Networking)
• Konum (Location)
• Ekran (Display)
• iOS'ta Ölçüm: Energy Log, MetricKit ve Organizer Verisi
• Organizer'da Battery Usage
• Energy Impact Gauge (Debug Navigator)
• MetricKit ile Üretim Verisi
• Android'de Ölçüm: System Tracing, Macrobenchmark ve Power Profiler
• Güncel Araçlar: System Tracing, Macrobenchmark Power Metric ve Power Profiler
• Battery Historian ile Log Okuma (Eski Ama Hâlâ İşe Yarayan)
• Sık Görülen Pil Anti-Pattern'leri
• Ağ İsteklerini Toplulaştırma ve Arka Plan İş Planlama
• Konum Doğruluğunu İhtiyaca Göre Düşürmek
• Ekran ve İşleme Maliyetini Azaltma
• Gerçek Cihazda A/B Ölçüm Protokolü
• Regresyonu CI'da Yakalamak
• SSS
• Uygulamamın pil tüketimini nasıl ölçerim?
• Arka plan işleri pili neden hızlı bitiriyor?
• Konum ve ağ kullanımında pil dostu desenler neler?
• Wake lock ne zaman gerçekten gerekli?
• Pil regresyonunu yayın öncesi nasıl yakalarım?
• Ekranın pil tüketimine etkisi ne kadar büyük?
• Güncelleme (Eylül 2026)
• Sonuç
• Kaynaklar

Pil Tüketiminin Dört Kaynağı: CPU, Ağ, Konum, Ekran

Apple'ın Xcode dokümantasyonu, bir uygulamanın enerji kullanımını kategorilere ayırır: Ses, Ağ, İşleme (CPU/GPU), Ekran, Bluetooth, Konum, Kamera, Torch, NFC ve Diğer. Bu kategori ayrımı hem Xcode Organizer'daki raporlarda hem Debug Navigator'daki Energy Impact göstergesinde aynı şekilde karşına çıkar. Android tarafında resmi terminoloji biraz farklı olsa da temel fizik aynıdır: radyo donanımları (hücresel/Wi-Fi/GPS), ekran paneli ve CPU/GPU en büyük üç tüketici olarak öne çıkar.

Pratikte optimizasyon çalışmasına başlamadan önce bu dört kaynaktan hangisinin baskın olduğunu bilmek gerekir; aksi halde CPU'da haftalarca zaman harcayıp asıl sorun olan ağ isteklerini gözden kaçırabilirsin.

CPU ve İşleme

CPU-yoğun kod, hem doğrudan işlemci enerjisi tüketir hem de cihazı daha yüksek frekans/termal duruma iterek dolaylı pil kaybına yol açar. Ana thread'de yapılan gereksiz layout hesaplamaları veya sık tetiklenen zamanlayıcılar bu kategoride en sık görülen anti-pattern'lerdir.

Ağ (Networking)

Google'ın resmi rehberi, ağ isteklerinin büyük bir pil tüketim nedeni olduğunu açıkça belirtir çünkü hücresel ve Wi-Fi radyoları sürekli açık tutmayı gerektirir. Radyo, bir istekten sonra hemen uykuya geçmez; bu yüzden seyrek ama büyük isteklerin toplamı, sık ama küçük isteklerden genelde daha ucuzdur.

Konum (Location)

Sürekli yüksek doğruluklu GPS kilidi, tek başına bir uygulamanın günlük pil bütçesinin büyük bölümünü tüketebilir. Google'ın rehberi, sürekli GPS kilidi tutmayı tipik pil tüketim desenlerinden biri olarak sayar; bunu system tracing veya Macrobenchmark power metric ile tespit edebilirsin.

Ekran (Display)

Ekran, özellikle OLED panellerde parlaklık ve renk paletine bağlı olarak değişken ama her zaman önemli bir tüketicidir. Bu makale ölçüm ve arka plan/ağ/konum optimizasyonuna odaklandığı için ekran tarafında derinlemesine renk/parlaklık mühendisliğine girmiyoruz; asıl mesaj, ekranın da Xcode Organizer ve Android profil araçlarında ayrı bir kategori olarak izlenmesi gerektiğidir.

iOS'ta Ölçüm: Energy Log, MetricKit ve Organizer Verisi

iOS tarafında pil ölçümü üç katmanda ilerler: geliştirme sırasında Instruments/Debug Navigator, TestFlight/App Store sürümlerinde Xcode Organizer, ve üretimde gerçek kullanıcı cihazlarından toplanan MetricKit verisi.

Organizer'da Battery Usage

Xcode Organizer'daki Battery Usage paneli, uygulamanın ön plan ve arka plan güç kullanımını sürüm bazında kırılımlı şekilde gösterir. Bu, "yeni sürümde pil tüketimi arttı mı?" sorusuna en somut cevabı veren yerdir — A/B karşılaştırması için ideal bir referans noktasıdır. Ayrıca uygulama 24 saatlik bir pencerede önemli miktarda enerji kullanırsa sistem otomatik olarak bir "energy exception report" üretir; bu raporlar gerçek kullanıcı cihazlarından, senin hiçbir ek enstrümantasyon eklemene gerek kalmadan gelir.

Energy Impact Gauge (Debug Navigator)

Geliştirme sırasında, Xcode'un Debug Navigator'ındaki Energy Impact göstergesi çalışan uygulamanın anlık enerji kullanımını pasta grafiği şeklinde kategori bazında gösterir. Bir özelliği geliştirirken bu gösterge canlı geri bildirim verir: örneğin bir liste ekranını açtığında Networking diliminin aniden büyümesi, gereksiz bir tekrar-fetch olduğunun ilk işaretidir.

MetricKit ile Üretim Verisi

MetricKit, gerçek kullanıcı cihazlarından günde en fazla bir kez, önceki 24 saate ait metrik raporlarını uygulamana teslim eder. Bu, laboratuvar ölçümünün yakalayamadığı gerçek dünya kullanım desenlerini (farklı ağ koşulları, farklı cihaz modelleri, farklı arka plan davranışı) görmenin tek güvenilir yoludur. Bu makalenin kapsamında MetricKit'in tam API yüzeyine girmiyoruz; kritik olan, üretim pil verisini toplamanın laboratuvar ölçümüne bir alternatif değil, tamamlayıcısı olduğudur.

Android'de Ölçüm: System Tracing, Macrobenchmark ve Power Profiler

Güncel Araçlar: System Tracing, Macrobenchmark Power Metric ve Power Profiler

Google'ın resmi rehberi, Android'de pil performansını incelemek için artık şu üç aracı öneriyor: system tracing, Macrobenchmark kütüphanesindeki power metric ve Android Studio'daki Power Profiler. System tracing, CPU/GPU/disk/ağ aktivitesini zaman çizelgesinde birlikte gösterir; Macrobenchmark'ın power metric'i güç tüketimini otomatik testlerle ölçüp CI'a bağlamana izin verir; Power Profiler ise Android Studio içinde canlı enerji kullanımını izlemeni sağlar.

Battery Historian ile Log Okuma (Eski Ama Hâlâ İşe Yarayan)

Battery Historian, sistem günlüklerindeki güçle ilişkili olayları zaman çizelgesi halinde HTML görünümünde görselleştiren bir araçtır ve cihazın pil geçmişini bir bütün olarak inceleyip hangi bileşenin ne zaman aktif olduğunu görmeni sağlar. Ancak aracın resmi belgesi şu uyarıyı taşıyor (bu uyarı makalenin 2025-01-15 yayın tarihinde de sayfada mevcuttu): "Battery Historian is no longer actively maintained; if possible, consider using system tracing, the Macrobenchmark power metric, or the Power Profiler to get insights into battery performance." Bu yüzden Battery Historian'ı yeni bir ölçüm hattının merkezine koymak yerine, elindeki eski log dosyalarını okurken kullanmayı düşünebilirsin.

Sık Görülen Pil Anti-Pattern'leri

Bakımı artık sürdürülmeyen bu araç olsa da, Google'ın resmi rehberi Battery Historian'ın tipik olarak şu davranışları tespit ettiğini belirtir: wakeup alarmlarının aşırı sık tetiklenmesi (10 saniyede bir veya daha sık), sürekli GPS kilidi tutulması ve işlerin 30 saniyede bir gibi çok sık aralıklarla zamanlanması. Bu üçü de, kod incelemesinde ilk bakılması gereken kalıplardır — günümüzde bunları system tracing veya Macrobenchmark power metric ile de tespit edebilirsin.

Önemli bir pratik detay: WorkManager, JobScheduler veya DownloadManager kullandığında, wake lock'u sistem veya kütüphane senin adına alır — bunu manuel yönetmen gerekmez. Bu, doğrudan PowerManager.WakeLock kullanmaktan daha güvenli bir varsayılan tercih olmasının nedenidir; eğer yine de manuel wake lock kullanman gerekiyorsa genel kural, mümkün olan en hafif yaklaşımı seçmek ve wake lock'u sistem kaynaklarına etkisini en aza indirecek şekilde en kısa sürede serbest bırakmaktır.

Arka plan görev planlamasının Android tarafındaki daha geniş resmini WorkManager 2.10 Coroutines rehberimizde bulabilirsin; iOS tarafındaki karşılığı için iOS Background Processing yazımıza bakabilirsin.

Ağ İsteklerini Toplulaştırma ve Arka Plan İş Planlama

Ağ isteklerini pil dostu hale getirmenin iki temel yolu var: isteklerin sayısını ve sıklığını azaltmak, ve bu istekleri cihazın zaten uygun bir durumda olduğu (şarjda, Wi-Fi'da) zaman dilimlerine kaydırmak.

Android'in resmi rehberi bu ikinci yaklaşımı doğrudan öneriyor: arka plan işlerini, cihaz şarjdayken veya Wi-Fi bağlantısındayken gibi belirli koşullar altında çalışacak şekilde planlamak. JobScheduler ve onun üzerine kurulu WorkManager, bu koşulları bildirimsel olarak tanımlamana izin verir.

1val constraints = Constraints.Builder()
2    .setRequiredNetworkType(NetworkType.UNMETERED) // Wi-Fi tercih
3    .setRequiresCharging(true)
4    .setRequiresBatteryNotLow(true)
5    .build()
6 
7val syncRequest = OneTimeWorkRequestBuilder<SyncWorker>()
8    .setConstraints(constraints)
9    .build()
10 
11WorkManager.getInstance(context).enqueue(syncRequest)

Ağ katmanının kendisini pil dostu hale getirmenin daha derin bir mühendislik konusu olduğunu düşünüyorsan, Network Layer Optimization rehberimiz istek toplulaştırma, retry stratejisi ve önbellekleme başlıklarını ayrıntılı ele alıyor.

Konum Doğruluğunu İhtiyaca Göre Düşürmek

Konum servisleri, özellikle sürekli yüksek doğrulukla çalıştırıldığında pil bütçesinin en agresif tüketicilerinden biridir. Hem iOS'ta CLLocationManager hem Android'de FusedLocationProviderClient, doğruluk seviyesini ihtiyaca göre ayarlamana izin veren API'ler sunar; gerçek zamanlı navigasyon dışındaki çoğu senaryoda (örneğin "yakınındaki mağazaları göster" gibi) en yüksek doğruluk seviyesi gereksizdir ve gereksiz yere pil tüketir.

1val locationRequest = LocationRequest.Builder(
2    Priority.PRIORITY_BALANCED_POWER_ACCURACY,
3    /* intervalMillis = */ 60_000L
4).build()
5 
6fusedLocationClient.requestLocationUpdates(
7    locationRequest,
8    locationCallback,
9    Looper.getMainLooper()
10)

Google'ın resmi rehberi ayrıca iki somut alışkanlığı öneriyor: konum güncellemelerini artık ihtiyaç duyulmadığında kaldırmak (tipik hata, onStart()/onResume()'da requestLocationUpdates() çağırıp karşılığında onPause()/onStop()'ta removeLocationUpdates() çağırmamaktır) ve foreground dışı senaryolarda istekleri toplu teslim etmek — setIntervalMillis() konumun ne sıklıkla hesaplanacağını, setMaxUpdateDelayMillis() ise ne sıklıkla cihaza teslim edileceğini belirler; örneğin konumu 10 dakikada bir hesaplayıp setMaxUpdateDelayMillis() ile saatte bir toplu teslim etmek, cihazın daha az uyanmasını sağlar.

Pratik kural basittir: konum ihtiyacını "her an, her yerde yüksek doğruluk" yerine "ne zaman, ne kadar doğruluk" sorusuyla tasarla. Harita tabanlı özellikler geliştiriyorsan MapKit ve Location Services rehberimizde konum güncellemelerini UI ile nasıl senkronize edeceğini bulabilirsin.

Ekran ve İşleme Maliyetini Azaltma

Ekran ve CPU tarafında en yüksek getiriyi genelde şu üç değişiklik sağlar: gereksiz yeniden çizimleri (redraw) önlemek, animasyonları düşük öncelikli işlerle çakıştırmamak ve liste/tablo gibi bileşenlerde görünür alan dışındaki içeriği render etmemek (lazy loading). Bu konudaki render performansı optimizasyonlarının çoğu, SwiftUI Performance Optimizasyonu yazımızda ayrıntılı işlendi — orada anlatılan tekniklerin büyük kısmı doğrudan pil tüketimine de yansır, çünkü daha az CPU/GPU döngüsü daha az enerji demektir.

Pratikte şu üç kontrolü kod incelemesine ekleyebilirsin:

• Gereksiz redraw: Bir liste hücresi veya kart bileşeni, veri değişmediği halde her scroll'da yeniden çiziliyor mu? Değişmeyen alt görünümleri memoize etmek hem render süresini hem CPU/GPU enerjisini azaltır.
• Çakışan animasyonlar: Aynı anda birden fazla sürekli animasyon (spinner, parallax, canlı grafik) çalışıyor mu? Ekran açıkken bu animasyonlar CPU'yu sürekli meşgul tutar; kullanıcı etkileşimde değilken animasyonu durdurmak basit ama etkili bir kazançtır.
• Görünmeyen içerik render'ı: Liste/tablo bileşenlerinde ekran dışındaki hücreler hâlâ hesaplanıyor mu? Lazy loading, hem bellek hem CPU/GPU tarafında kazanç sağlar; dolaylı olarak pil tüketimini de düşürür.

Bu üç kontrolün ortak noktası, hiçbirinin özel bir "pil optimizasyonu" API'si gerektirmemesidir — zaten iyi bir render/performans disiplininin doğal bir sonucu olarak pil tüketimi de düşer.

Gerçek Cihazda A/B Ölçüm Protokolü

Simülatörde veya laboratuvar cihazında alınan ölçümler gerçek kullanıcı davranışını yansıtmaz; bu yüzden pil optimizasyonunun son doğrulaması her zaman gerçek cihazda ve mümkünse gerçek kullanıcı verisiyle yapılmalıdır. Önerilen protokol şu şekilde işler:

1. Değişiklik öncesi sürümü yayınla, Organizer'daki Battery Usage panelinde bir temel çizgi (baseline) oluştur.
2. Değişikliği içeren sürümü yayınla ve aynı panelde sürüm bazlı kırılımı karşılaştır.
3. 24 saatlik pencerede energy exception report sayısındaki artış/azalışı izle.
4. Eğer bir kod parçasının CPU-yoğun aktivite yoluyla genel enerji kullanımına önemli katkı yaptığını tespit edersen, o kod için ayrı bir performans testi yaz ve bu testi CI'a bağla.

Bu son adım, bir sonraki bölümün konusu.

Regresyonu CI'da Yakalamak

Pil regresyonlarının çoğu, "bir önceki sürümde iyiydi, bu sürümde kötüleşti" şeklinde fark edilir — ki bu da onları CI'da yakalamanın mümkün olduğu anlamına gelir. XCTest, XCTCPUMetric ile CPU kullanımını doğrudan ölçen performans testleri yazmana izin verir; CPU-yoğun bir kod parçasının uygulamanın genel enerji kullanımına önemli katkı yaptığını tespit ettiğinde, o kodun CPU kullanımını ölçen bir performans testi oluşturman önerilir.

1import XCTest
2 
3final class FeedProcessingPerformanceTests: XCTestCase {
4    func testFeedDecodingCPUUsage() {
5        let payload = loadFixture("large-feed.json")
6 
7        measure(metrics: [XCTCPUMetric()]) {
8            _ = try? FeedDecoder().decode(payload)
9        }
10    }
11}

1#!/usr/bin/env bash
2# CI adımı: performans test planını çalıştır, sonucu artifact olarak sakla.
3set -euo pipefail
4 
5xcodebuild test \
6  -scheme "App-PerformanceTests" \
7  -destination "platform=iOS Simulator,name=iPhone 15" \
8  -testPlan "PerformanceTests" \
9  -resultBundlePath "PerformanceResults.xcresult"
10 
11xcrun xcresulttool get --legacy --path PerformanceResults.xcresult --format json \
12  > performance-summary.json

Not: Simülatörde ölçülen XCTCPUMetric değeri mutlak bir enerji tüketimi rakamı değildir; CI'da bunu sürümler arası göreli bir regresyon sinyali olarak oku, gerçek pil etkisini yalnızca Organizer'daki Battery Usage paneliyle (gerçek cihaz verisiyle) doğrula.

Bu iki parçayı bir araya getirdiğinde: geliştirme sırasında Debug Navigator, sürüm karşılaştırmasında Organizer, üretimde MetricKit ve regresyon önlemede CI performans testleri — pil tüketimini tahminden çıkarıp ölçülebilir bir mühendislik disiplinine dönüştürmüş olursun.

Android tarafında karşılığı, Macrobenchmark gibi ölçüm kütüphaneleriyle CPU/başlatma süresi regresyonlarını CI'a bağlamaktır; JobScheduler kısıtlarını (şarj, ağ tipi) kod incelemesinde zorunlu bir kontrol maddesi haline getirmek, aynı disiplinin Android karşılığıdır. Her iki platformda da amaç aynı: pil regresyonunu bir kullanıcı şikâyeti olarak değil, bir CI kontrolü olarak yakalamak.

SSS

Uygulamamın pil tüketimini nasıl ölçerim?

iOS'ta üç katmanlı bir yaklaşım kullan: geliştirme sırasında Debug Navigator'daki Energy Impact göstergesi, sürüm karşılaştırması için Xcode Organizer'daki Battery Usage paneli, ve üretimde gerçek kullanıcı verisi için MetricKit'in günlük metrik raporları. Android'de system tracing, Macrobenchmark power metric veya Power Profiler ile pil kullanımını incele; eski log dosyalarını okumak için bakımı sürdürülmeyen Battery Historian'ı da kullanabilirsin.

Arka plan işleri pili neden hızlı bitiriyor?

Çünkü çoğu arka plan işi radyoyu (ağ) veya GPS'i aktif tutar ve bu bileşenler uykuya geçmeden önce belirli bir süre açık kalır. Sık tetiklenen wakeup alarmları (10 saniyede bir veya daha sık), sürekli GPS kilidi ve çok sık zamanlanan işler (30 saniyede bir gibi) Google'ın resmi rehberinin tipik olarak işaret ettiği anti-pattern'lerdir (bakımı sürdürülmeyen Battery Historian'ın yanı sıra system tracing ve Macrobenchmark power metric ile de tespit edilebilir).

Konum ve ağ kullanımında pil dostu desenler neler?

Konumda: doğruluk seviyesini gerçek ihtiyaca göre seçmek (her zaman en yüksek doğruluk yerine dengeli doğruluk) ve güncelleme sıklığını azaltmak. Ağda: istekleri toplulaştırmak, sık poll yerine event-driven güncelleme kullanmak ve büyük/kritik olmayan işleri WorkManager/JobScheduler ile şarj veya Wi-Fi koşuluna bağlamak.

Wake lock ne zaman gerçekten gerekli?

Yalnızca başka bir seçenek olmadığında. WorkManager, JobScheduler veya DownloadManager kullanıyorsan wake lock'u sistem senin adına yönetir; manuel PowerManager.WakeLock kullanman gerekiyorsa en hafif yaklaşımı seç ve kilidi mümkün olan en kısa sürede serbest bırak.

Pil regresyonunu yayın öncesi nasıl yakalarım?

CPU-yoğun kod parçaları için XCTest'te XCTCPUMetric kullanan performans testleri yaz ve bu testleri CI pipeline'ına bağla. Böylece bir kod değişikliği CPU kullanımını önemli ölçüde artırdığında, bunu üretime gitmeden önce fark edersin.

Ekranın pil tüketimine etkisi ne kadar büyük?

Ekran, özellikle OLED panellerde parlaklık ve gösterilen renk paletine bağlı olarak değişir; kesin bir yüzde vermek cihaza ve içeriğe göre değişeceğinden yanıltıcı olur. Pratik kural: ekran da Xcode Organizer'da ve Android Studio Power Profiler'da CPU/ağ/konum ile aynı önemde ayrı bir kategori olarak izlenmeli; gereksiz redraw'ları ve çakışan animasyonları azaltmak, ekran kategorisindeki tüketimi dolaylı olarak düşürür.

Güncelleme (Eylül 2026)

Bu makalenin gövdesi 2025-01-15 tarihindeki araç ve API yüzeyini yansıtır. O tarihten bu yana iki platformda da ölçüm ve zamanlama tarafında önemli değişiklikler oldu:

iOS: Apple, iOS/iPadOS 26 ile Instruments'a cihaz bağlantısı gerekmeden trace toplayabilen yeni bir Power Profiler aracı ekledi; bu, makalenin gövdesinde anlattığımız Organizer/Debug Navigator akışının üzerine eklenen ek bir katmandır. Xcode Organizer'ın enerji istisna raporlarına da "Generate Recommendations" adlı, AI destekli bir triage özelliği geldi. Ayrıca MetricKit'in birincil arayüzü, iOS 27 ve sonrasında MetricManager üzerinden asenkron sekanslarla MetricReport/DiagnosticReport değerleri teslim eden yeni bir API'ye geçti — makalenin gövdesindeki "günde en fazla bir kez teslim" davranışı kavramsal olarak korunuyor, ancak API yüzeyi değişti.

Android: Android 16'da JobScheduler kota mantığı genişledi: Google'ın Android 16 davranış değişiklikleri sayfasına göre, regular ve expedited job runtime kotası artık şu üç faktöre göre ayarlanıyor — uygulamanın hangi app standby bucket'ında olduğu (active bucket artık cömert bir kotayla uygulanmaya başlıyor), uygulama görünürken (top state) başlayıp arka plana geçtikten sonra süren işler, ve bir foreground service ile eşzamanlı koşan işler; bu üçü de makalede anlattığımız setRequiresCharging/setRequiredNetworkType kısıtlarını planlarken dikkate alınması gereken yeni bir sınırdır. Ayrıca yeni bir durdurma nedeni (STOP_REASON_TIMEOUT_ABANDONED) ve yeni bir hata ayıklama API'si (getPendingJobReasonsHistory()) eklendi; setImportantWhileForeground() artık dikkate alınmıyor (deprecated).

Sonuç

Mobil uygulamada pil tüketimi optimizasyonu, tahmine değil ölçüme dayanmalı: iOS'ta Organizer + Debug Navigator + MetricKit üçlüsü, Android'de system tracing + Macrobenchmark power metric + JobScheduler/WorkManager kısıtları bu ölçümün omurgasını oluşturur (eski log dosyaların için Battery Historian hâlâ kullanılabilir). Ağ isteklerini toplulaştırmak, konum doğruluğunu ihtiyaca göre düşürmek ve arka plan işlerini şarj/Wi-Fi koşuluna bağlamak en yüksek getiriyi sağlayan üç değişikliktir. Arka plan görev planlamasını derinleştirmek için WorkManager 2.10 Coroutines rehberimize ve iOS Background Processing yazımıza, ağ katmanını sertleştirmek için Network Layer Optimization rehberimize, konum tarafında MapKit ve Location Services yazımıza, render maliyetini azaltmak için SwiftUI Performance Optimizasyonu rehberimize göz atabilirsin.

Kaynaklar

• Apple — Analyzing your app's battery use — Xcode Organizer Battery Usage paneli, energy exception report ve Energy Impact gauge açıklaması.
• Apple — MetricKit — Günlük metrik raporu teslim davranışı ve genel MetricKit çerçevesi.
• Google — Optimize battery use (preserving-battery) — Ağ isteklerinin pil tüketimindeki rolü ve koşullu arka plan iş planlama önerisi.
• Google — Use wakelocks — Wake lock kullanım kuralları ve WorkManager/JobScheduler'ın otomatik wake lock yönetimi.
• Google — Battery Historian — Battery Historian aracının işlevi ve tespit ettiği tipik anti-pattern'ler (sayfa artık bakımı sürdürülmediğini ve system tracing/Macrobenchmark power metric/Power Profiler'ın tercih edilmesi gerektiğini belirtiyor).
• Google — Optimize location for battery — Konum güncellemelerini kaldırma, zaman aşımı ekleme ve istekleri toplu (batch) teslim etme önerileri.
• Google — Priority (Play services location) — PRIORITY_BALANCED_POWER_ACCURACY sabiti ve konum doğruluğu/pil dengesi tanımı.
• Google — Android 16 behavior changes — JobScheduler kota genişlemesi, yeni durdurma nedeni ve hata ayıklama API'si (Güncelleme bölümü kaynağı).
• Apple — Measuring your app's power use with Power Profiler — iOS/iPadOS 26 ile eklenen Power Profiler aracı (Güncelleme bölümü kaynağı).