Mobil pil için API tasarımı: konuşkanlığı azaltın

Neden konuşkan (chatty) API'lar mobilde pili tüketir

“Konuşkan” bir API, tek bir ekranı oluşturmak için uygulamanın çok sayıda küçük isteği ateşlemesine neden olur. Her istek kağıt üzerinde ucuz görünebilir, ama telefonda bunlar hızla toplanır.

En büyük pil etkisi genellikle ağ radyosundan gelir. Hücresel ve Wi‑Fi çipleri veri göndermek/alamak için yüksek güçlü modlara geçer. Bir uygulama birçok isteği birbirine yakın zamanda gönderdiğinde, radyo sürekli uyanır ve daha uzun süre aktif kalır. Her yanıt küçük olsa bile, tekrarlayan uyanmalar gerçek enerji maliyeti getirir.

CPU işi de vardır. Her istek başlık oluşturma, TLS işi, JSON ayrıştırma, önbellek güncelleme ve sonuçları birleştirmek için uygulama kodu çalıştırma demektir. Bağlantılar düşerse, kurulum işi tekrarlanır.

Konuşkanlık ayrıca UI'nin daha yavaş hissetmesine neden olur. Bir öngörülebilir yükleme yerine ekran bir dizi çağrıyı bekler. Daha uzun spinner'lar, parçalı render'lar ve zayıf ağda daha fazla zaman aşımı görürsünüz. Arka plan yenilemeleri de aynı şekilde kötüleşir: daha fazla yeniden deneme, daha fazla uyanma, daha fazla pil tüketimi.

"Mobil pil için API tasarımı"nı pratikçe düşünmenin yolu basittir: aynı UI'ı daha az round trip, daha az byte ve daha az arka plan işiyle gösterin.

Başarıyı birkaç somut değişiklikle takip edebilirsiniz:

• Ekran yüklemesi başına daha az API çağrısı
• Ekran başına indirilen daha az byte
• Hücreselde daha iyi medyan ve en kötü durum etkileşim süresi
• Aynı sonuç için daha az arka plan getirisi ve yeniden deneme

Bunlar iyileştiğinde, genellikle cevap hızı ve pil kullanımı birlikte iyileşir.

Her şeye dokunmadan önce ne ölçmelisiniz

İstekleri toplamak veya önbelleği ayarlamak gibi şeyleri değiştirmeden önce, uygulamanın bugün gerçekte ne yaptığını net olarak görün. En hızlı kazanımlar genellikle birkaç tekrar eden suçluyu düzeltmekten gelir, ama bunları bulmak için gerçek ekranları ve akışları ölçmelisiniz (sadece tek bir mutlu yol testi değil).

Yüksek trafikli birkaç ekran için temelleri kaydedin: bir yüklemede kaç istek oluyor, hangi endpoint'ler çağrılıyor, gönderilen ve alınan byte'lar (başlıklar artı gövde), yeniden deneme ve zaman aşımı oranları ve UI'nin kullanılabilir hissetmesine kadar geçen süre. Mümkünse hata oranlarını ağ türüne göre ayırın (Wi‑Fi vs hücresel). Bu ayrımlar kararlı bağlantıda kaçıracağınız sorunları ortaya çıkarır.

Ön plan trafiğini arka plan trafiğinden ayırın. Bir ekran sessiz görünebilir ama telefon arka planda yenileme, push tetikli senkronizasyon, analiz yüklemeleri veya "tedbir amaçlı" ön getirme çağrılarıyla meşgul olabilir. Bunları ayrı izleyin ki yanlış şeyi optimize etmeyesiniz.

Sıkıntı noktaları genellikle birkaç ana an etrafında toplanır: uygulama başlatma, ana/akış ekranı, birden fazla çağrıya yayılan detay ekranları ve pull‑to‑refresh. Bunlardan birini seçip uçtan uca ölçün.

Takımın neyin "iyi" olduğunu kabul edebilmesi için bir temel bütçe belirleyin. Örneğin: “Sipariş takip ekranının soğuk yüklemesi, durumu göstermeden önce en fazla 6 istek yapmalı ve 250 KB'den fazla indirmemeli.”

Basit bir KPI çiftiyle başlamak isterseniz, (1) ekran yüklemesi başına istek sayısı ve (2) yeniden deneme oranını kullanın. Yeniden denemeleri azaltmak genellikle beklenenden daha fazla pil tasarrufu sağlar, çünkü tekrarlayan yeniden denemeler radyonun daha uzun süre aktif kalmasına neden olur.

Adım adım: istekleri batching ile azaltma

Konuşkan API'lar kazara kolayca ortaya çıkar. Her bileşen "kendi" verisini yükler ve bir ekran düzine küçük çağrı tetikleyebilir. Çözüm genelde karmaşık değildir: birlikte her zaman yüklenenleri belirleyin ve daha az çağrıda dönün.

Önce yüksek trafikli bir ekranı (ana ekran, gelen kutusu, sipariş listesi) eşleştirin. Katman altında görünenleri yazın, sonra her UI öğesinin hangi isteğe dayandığını izleyin. Genellikle tekrar edenler (aynı kullanıcı profili iki kez çekilmesi) ve birlikte her zaman giden çağrılar (profil + izinler + okunmamış sayısı) bulursunuz.

Sonra güvenilir şekilde birlikte giden çağrıları gruplayın. Genelde iki seçeneğiniz vardır:

• O ekran için amaç‑odaklı bir endpoint oluşturun (çoğunlukla en kararlı seçim)
• Küçük, öngörülebilir bir kaynak listesi kabul eden bir batch endpoint ekleyin

Batch'leri ekran bazlı ve sınırlı tutun ki cachelemek, izlemek ve hata ayıklamak kolay olsun.

Toplama işinin kontrolsüz hale gelmesini önleyecek birkaç kural:

• Ekranın şu an ihtiyaç duyduğu kadarını döndürün, “olur ya” diye tam nesneler göndermeyin.
• Bazı parçalar isteğe bağlıysa bunu açık yapın ki UI önemli kısımları hızlı render edebilsin.
• Yanıtı öyle tasarlayın ki kısmi hatalar tüm yeniden denemeyi zorunlu kılmasın. Başarısız olan parçayı yeniden denemek, tüm paketi yeniden göndermekten çok daha ucuzdur.

Pil tasarrufu sağlayan caching başlıkları (sadece bant genişliği için değil)

Caching bir pil özelliğidir. Her istek radyoyu uyandırır, CPU'yu meşgul eder ve ayrıştırma ile uygulama mantığını tetikler. İyi cache başlıkları birçok yenilemeyi hafif kontrollere dönüştürür.

En büyük kazanım koşullu isteklere geçmektir. Aynı veriyi yeniden indirmek yerine, istemci “Bu değişti mi?” diye sorar. Değişmediyse sunucu küçük bir 304 Not Modified ile cevap verir.

Kaynakların bir versiyonunu temsil eden yanıtlarda ETag kullanın ve istemcinin sonraki alımda If-None-Match göndermesini sağlayın. ETag üretmek zorsa, basit “güncellenme zamanı” kaynakları için Last-Modified ve If-Modified-Since iyi çalışır.

Nadiren değişen veriler için cache kararını açık yapın. Cache-Control gerçeğe uymalı. Kullanıcı profilleri için kısa bir max-age uygun olabilirken, uygulama konfigürasyonu, referans listeleri ve feature flag'ler genelde daha uzun tutulabilir.

Uygulama tarafında 304'ü hızlı yol olarak değerlendirin. JSON ayrıştırmayın (yoktur), modelleri yeniden kurmayın ve UI'ı titretmeyin. Ekranda olanı muhafaza edip sadece göstergeleri güncelleyin.

Örnek: bir sipariş takip ekranı her 15 saniyede bir sipariş durumunu sorguluyor. Yanıt bir ETag içeriyorsa çoğu kontrol 304 ile dönebilir. Uygulama son durumu saklar ve gerçek iş yalnızca durum değiştiğinde yapılır (ör. “Paketlendi”den “Gönderildi”ye).

Hassas verilerle kasıtlı olun. Cache otomatik olarak güvensiz değildir, ama net kurallar gerektirir. Kişisel detaylar veya token içeren yanıtları ürün gereksinimleri izin vermedikçe cachelemeyin. Kullanıcıya özel veriler için kısa ömürler kullanın ve paylaşılan cache'lerin özel yanıtları saklamasını engelleyin (Cache-Control: private gerektiğinde).

Daha akıllı payload'lar: daha az gönder, daha az ayrıştır

Her ekstra byte mobilde sadece bant genişliğinden daha fazlasına mal olur. Radyoyu daha uzun süre uyanık tutar ve uygulamanın JSON'u çözmek ve modelleri güncellemek için CPU harcamasına neden olur. API konuşkanlığını azaltmak istiyorsanız, payload'ları kısaltmak genellikle en hızlı kazanımdır.

Ekran başına payload'ları denetleyerek başlayın. Bir ekran seçin (ör. ana akış), yanıt boyutlarını kaydedin ve alan alan gezinin: istemci bunu render ediyor mu yoksa sadece ne göstereceğine karar vermek için mi kullanıyor? Değilse, o alanı endpoint'ten kaldırın.

Listeler için küçük bir “özet” şekli genellikle yeterlidir. Bir liste satırı genelde bir id, başlık, durum ve zaman damgası ister. Tam açıklamalara, uzun notlara veya derin iç içe nesnelere ihtiyaç yoktur. Ayrıntılar yalnızca kullanıcı öğeyi açtığında çekilsin.

Hızlıca payload'ları azaltan birkaç değişiklik:

• Tekrarlanan uzun stringler yerine id'ler veya kısa enum kodları tercih edin
• İstemcinin güvenle varsayabileceği bariz varsayılanları yeniden göndermeyin
• Her liste öğesinde aynı iç içe nesneyi tekrar etmekten kaçının
• Alan adlarını ve tiplerini stabil tutun ki istemci daha az dallanma ve yeniden ayrıştırma yapsın

Sıkışma (compression) yardımcı olabilir, özellikle yavaş ağlarda, ama gerçek cihazlarda CPU takasını test edin. Gzip veya Brotli genelde transfer boyutunu çok azaltır, ama eski telefonlar çok büyük yanıtları açarken belirgin süre harcayabilir. En iyi kazanım hâlâ başlangıçta daha az veri göndermektir.

Yanıt şekillerini bir sözleşme gibi görün. Alan adları ve tipler tutarlı kaldığında, uygulama daha az yedekleme kodu çalıştırır ve daha az savunmacı mantık yazar; bu da UI'nin daha akıcı kalmasına ve pil kullaniminin azalmasına yardımcı olur.

Kötü ağlar ve daha az yeniden deneme için tasarla

Bir mobil uygulama yalnızca istek gönderirken pil yakmaz; ayrıca başarısız olduğunda yeniden dener, radyoyu tekrar uyandırır ve işi tekrarlar. Bir API mükemmel Wi‑Fi varsayarsa, gerçek kullanıcılar kesintili 4G üzerinde bunun bedelini öder.

Daha az veri istemeyi kolaylaştırın. İstemci tarafında filtrelemek yerine sunucu tarafı filtreleri ve paginasyonu tercih edin. Eğer bir ekran tek bir kullanıcı için son 20 olaya ihtiyaç duyuyorsa, tam olarak o sorguyu destekleyin ki uygulama yüzlerce satırı indirip çoğunu atmasın.

Delta senkronizasyonunu destekleyin ki istemci "son kontrolümden beri ne değişti?" diye sorabilsin. Bu, bir zaman damgası veya artan bir versiyon numarası döndürmek kadar basit olabilir; sonra istemci yalnızca o noktadan beri olan güncellemeleri ve silmeleri isteyebilir.

Yeniden denemeler kaçınılmazdır, bu yüzden güncellemeleri idempotent yapın. Bir yeniden deneme iki kat ücretlendirme, çift gönderim veya çoğaltma yaratmamalı. Oluşturma işlemleri için idempotency anahtarları ve durumu belirleyen ("bir ekle" yerine "durumu ayarla") güncelleme semantiği çok yardımcı olur.

Yeniden denemeler olduğunda, yeniden deneme fırtınalarını önleyin. Binlerce cihazın sunucularınıza aynı anda çarpmasını ve telefonun her saniye uyanmasını engellemek için jitter'lı üssel geri çekilme kullanın.

Uygulamanın ne yapacağına karar vermesine yardımcı olacak net hata kodları döndürün. 401 yeniden kimlik doğrulamayı tetikle, 404 genelde yeniden denemeyi durdurmalı, 409 durum yenilemesi gerektirebilir ve 429 veya 503 backoff gerektirmelidir.

İstemci davranışları: API maliyetlerini katlayanlar

İyi tasarlanmış bir API olsa bile, istemci ağ işini sessizce çoğaltabilir. Mobilde bu ekstra uyanmalar ve radyo süresi genellikle byte'ların kendisinden daha fazla pil maliyeti doğurur.

Nadiren değişen verileri cacheleyin. Profil fotoğrafları, feature flag'ler ve referans verileri (ülkeler, durumlar, kategoriler) her ekranda çekilmemeli. Mantıklı ömürler verin, diske kaydedin ve yalnızca gerektiğinde yenileyin. API doğrulama (ETag veya Last-Modified) destekliyorsa, hızlı bir yeniden kontrol genelde tam indirmeden çok daha ucuzdur.

Yolda olan duplicate in‑flight istekleri kontrol edin. Uygulamanın iki farklı parçası aynı kaynağı aynı anda istiyorsa (ör. bir başlık ve ayarlar ekranı profil isteği yapıyorsa), koalescence olmadan iki çağrı gönderilir, iki yanıt ayrıştırılır ve durum iki kez güncellenir. Bir ağ çağrısını tek gerçek kaynak olarak ele alın ve birden fazla tüketici onun sonucunu beklesin.

Arka plan yenilemesi kasıtlı olmalı. Kullanıcı yakında göreceği şeyi değiştirmiyorsa veya bildirim tetiklemeyecekse genelde bekleyebilir. Her uygulama dönüşünde yenileme mantığını çalıştırmaktan kaçının. Kısa bir soğuma (cooldown) ekleyin ve verinin en son ne zaman güncellendiğini kontrol edin.

Eğer AppMaster ile backend'ler inşa ediyorsanız, endpoint'leri ekran çevresinde şekillendirerek, yanıt şemalarını tutarlı tutarak ve kontrollü şekilde cache başlıkları ekleyerek istemcilerin çoğunlukla sessiz kalmasını kolaylaştırabilirsiniz.

Batching, caching ve payload'larla yapılan yaygın hatalar

Hedef daha az radyo uyanması, daha az CPU işi ve daha az yeniden denemedir. Birkaç desen tasarrufları iptal edebilir ve hatta ekranları daha yavaş hissettirebilir.

Ne zaman batching işleri daha kötü yapar

Batching yardımcı olur taşıncaya kadar; batch "her şeyi ver" çağrısına dönüştüğünde server çok sayıda join yapıp ağır izin kontrolleri çalıştırmak zorunda kalır ve devasa bir yanıt oluşturur; bu tek bir yavaş istek, uygulamayı bekletir, ağı aktif tutar ve zaman aşımı riskini artırır.

Daha sağlıklı batch, ekran‑şeklinde olmalıdır: bir görünümün ihtiyaç duyduğu kadar, net limitlerle. Yanıtı bir cümleyle tanımlayamıyorsanız, endpoint muhtemelen çok geniştir.

Eski (stale) ekranlar yaratan caching

Net invalidasyon olmadan cache kullanmak kötü bir döngü yaratır: kullanıcı eski veri görür, pull‑to‑refresh yapar ve uygulama ekstra tam yeniden yüklemeler yapar. Cache-Control başlıklarını veriyi neyin güncelleyeceği (oluşturma/güncelleme aksiyonları, sunucu olayları veya kısa tazelik pencereleri) ile eşleştirin ki istemci cached yanıtlara güvenebilsin.

Polling başka bir pil tuzağıdır. Sıkı 5 saniyelik bir zamanlayıcı, hiçbir şey değişmese bile cihazı meşgul eder. Mümkünse sunucu‑itmeli (server‑driven) güncellemelere geçin veya agresif olarak geri çekilin (boş poll'lerden sonra aralıkları uzatın, arka planda duraklatın).

Aşırı büyük payload'lar sessiz maliyettir. "Kolaylık için" devasa iç içe nesneler döndürmek daha fazla byte, daha fazla JSON ayrıştırma ve daha fazla bellek kullanımı anlamına gelir. Ekranın ihtiyaç duyduğu kadar gönderin ve ayrıntıları isteğe bağlı yükleyin.

Son olarak, bir batch içindeki kısmi hataları görmezden gelmeyin. Bir alt sonuç başarısız olup tüm batch'i yeniden denerseniz trafiği çoğaltırsınız. Yanıtları istemcinin yalnızca başarısız parçaları yeniden denemesine izin verecek şekilde tasarlayın.

Kısa bir zihinsel kontrol listesi: batch'leri sınırlı tutun, cache tazeliğini önceden tanımlayın, sıkı polling'den kaçının, payload'ları kırpın ve kısmi başarıyı destekleyin.

Yayın öncesi hızlı kontrol listesi

Yayınlamadan önce yalnızca ağ davranışına odaklanan bir tur yapın. Çoğu pil kazanımı sürprizleri ortadan kaldırmaktan gelir: daha az uyanma, daha az ayrıştırma ve arka planda daha az yeniden deneme.

Üst üç ekranınızda bunu çalıştırın:

• Soğuk yüklemeler küçük, öngörülebilir sayıda istekle bitsin (satır başına öğe‑özgü takip çağrıları gibi gizli takip çağrılarına dikkat edin).
• Yanıtlar uygun cache kuralları içersin (ETag veya Last-Modified uygun olduğu yerlere) ve bir şey değişmediğinde 304 Not Modified döndürsün.
• Liste endpoint'leri sınırlı olsun: stabil sıralama, paginasyon ve varsayılan olarak kullanılmayan alan yok.
• Yeniden deneme mantığı jitter'lı geri çekilme kullansın ve kendi kendine düzelmeyecek hatalarda denemeyi durdursun; toplam yeniden deneme süresi sınırlandırılsın.
• Arka plan güncellemeleri gerekçelendirilmiş olsun; ekran kullanıcıya açık değilse sürekli polling'den kaçının.

Basit bir gerçek kontrolü: bir ekranı bir kez yükleyin, uçak modunu açın, sonra yeniden açın. Eğer hâlâ kullanışlı bir şey gösteriyorsa (cache'lenmiş içerik, son bilinen durum, dostça yer tutucular), muhtemelen gereksiz çağrıları azaltmış ve algılanan hızı da iyileştirmişsinizdir.

Örnek: bir sipariş takip ekranını daha ucuz hale getirmek

Bir kullanıcı mobil veride %20 pil ile bir sipariş takip uygulamasını açıyor. Tek istedikleri: “Paketim şimdi nerede?” Ekran basit görünebilir ama arkadaki API trafiği şaşırtıcı derecede maliyetli olabilir.

Önce, uygulama ekranı bir dizi istekle yüklüyor. UI bekliyor, radyo tekrar tekrar uyanıyor ve zayıf bağlantıda birkaç çağrı zaman aşımına uğruyor.

Tipik "önce" deseni şöyle görünür:

• GET /orders/{id} sipariş özeti için
• GET /orders/{id}/items kalemler için
• GET /orders/{id}/history durum olayları için
• GET /me kullanıcı profili ve tercihleri için
• GET /settings görüntü kuralları (para birimi, tarih formatı) için

Şimdi UI'ı değiştirmeyen üç değişikliği uygulayın.

Birincisi, görünümün ihtiyaç duyduğu kadarını tek turda döndüren bir ekran endpoint'i ekleyin: sipariş özeti, en son durum, yakın geçmiş ve kalem başlıkları. İkincisi, profili cacheleyin: GET /me ETag ve Cache-Control: private, max-age=86400 döndürsün, böylece çoğu açılış hızlı 304 veya hiç istek olmadan sonuçlanır. Üçüncüsü, payload'ı inceltin: kalem listesi yalnızca id, name, qty ve thumbnail_url göndersin; tam ürün açıklamaları veya kullanılmayan metadata olmasın.

Sonuç: daha az round trip, daha az byte ve ağ dalgalandığında daha az yeniden deneme. Telefonun radyosu daha sık uykuya geçer; gerçek pil tasarrufu burada olur.

Kullanıcı için yeni bir şey görünmez. Ekran aynı kalır ama daha hızlı yüklenir, daha duyarlı hisseder ve bağlantı kötü olsa bile çalışmaya devam eder.

Sonraki adımlar: pratik bir uygulama planı (ve AppMaster nerede yardımcı olabilir)

Hızlı kazanımlar istiyorsanız, küçük başlayın ve etkiyi kanıtlayın. Pil tasarrufları genellikle büyük bir yeniden yazımdan değil, daha az radyo uyanması ve daha az ayrıştırma işinden gelir.

Güvenli, ölçülebilir ve kolay geri alınabilir üç değişiklik:

• Bir ekranı uçtan uca ölçün (istek sayısı, toplam byte, etkileşim süresine kadar geçen süre, hata ve yeniden deneme oranı)
• O ekranın isteklerini bir veya iki çağrıya toplayın (geriye dönük uyumluluk için eski endpoint'leri tutun)
• En yüksek trafikli GET endpoint'lerinize ETag desteği ekleyin ki istemciler If-None-Match kullanıp 304 Not Modified alabilsin

Sürekli kullanılan bir özelliği seçin, örneğin bir sipariş listesi veya mesaj gelen kutusu. Sunucu tarafı bir flag ile gönderin, sonra birkaç gün boyunca eski ve yeni yolu kıyaslayın. Oturum başına daha az istek, daha az yeniden deneme ve aktif kullanıcı başına daha az indirilen byte arayın.

API ve uygulama sürümlerini koordine edin ki eski istemciler bozulmasın. Pratik bir kural: yeni davranışı önce ekleyin, istemcileri ikinci aşamada taşıyın, eski davranışı son olarak kaldırın. Cache davranışını değiştiriyorsanız, kişiselleştirilmiş verilerde dikkatli olun ve paylaşılan cache'lerin kullanıcıları karıştırmadığından emin olun.

Backend değişikliklerini prototipleyip daha hızlı göndermek isterseniz, AppMaster (appmaster.io) veri modellemesini görsel yapmanızı, sürükle‑bırak editörle iş mantığı kurmanızı ve gereksinimler değiştikçe üretime hazır kaynak kodu yeniden oluşturmanızı sağlar.

Önce bir batched endpoint ve bir yüksek trafikli ekran için ETag desteğiyle başlayın. Sayılar iyileşirse, hangi mühendislik yatırımlarına devam edeceğinizi net olarak bilirsiniz.