Mobil Uygulama Boyutunda Pragmatik Optimizasyon: 3 Yanılgı

Mobil Uygulama Boyutunda Pragmatik Optimizasyonun Önemi

Mobil uygulama geliştirme dünyasında, kullanıcının uygulamayı indirme kararında boyutun kritik bir rol oynadığını sıkça görürüm. Özellikle veri paketlerinin sınırlı olduğu veya internet hızının düşük olduğu coğrafyalarda, birkaç megabaytlık fark bile indirme oranlarını doğrudan etkileyebilir. Bu durum, geliştiricileri sürekli olarak uygulama boyutunu küçültmeye iterken, bazen yanlış stratejilere yönlendirebilir.

Yirmi yıla yakın süredir sistemler ve yazılımlarla uğraşan biri olarak, mobil tarafta da çeşitli projelerde bulundum. Kendi Android spam uygulamamda veya bir müşteri projesinin Flutter tabanlı mobil uygulamasında, boyut optimizasyonu her zaman gündeme gelen, ancak çoğu zaman tek boyutlu yaklaşımlarla ele alınan bir konu oldu. Bu yazıda, mobil uygulama boyutunu optimize ederken sıkça düşülen üç temel yanılgıyı ve bu yanılgılardan edindiğim dersleri paylaşacağım.

Yanılgı 1: Uygulama Boyutunda Sadece Kod Yığınına Odaklanmak

Mobil uygulama boyutunu küçültme denince akla ilk gelen genellikle derlenmiş kodun boyutu oluyor. Geliştiriciler hemen Proguard/R8 (Android için) veya bitcode optimizasyonları (iOS için) gibi araçlara sarılıyorlar. Evet, bu araçlar gerçekten de kullanılmayan kodu eleyerek ve kodu optimize ederek önemli küçülmeler sağlayabilir, ancak genellikle resmin sadece bir parçasıdırlar. Benim deneyimimde, uygulamanın asıl şişmanlama sebepleri çoğunlukla başka yerlerde gizli kalır.

Özellikle Flutter gibi cross-platform framework’lerle geliştirme yaparken veya native C++ kütüphaneleri kullanan Android/iOS projelerinde, uygulamanın toplam boyutunun büyük bir kısmını asset’ler (resimler, videolar, ses dosyaları, yazı tipleri) ve native kütüphaneler (ABI’ye özel .so veya .dylib dosyaları) oluşturabilir. Örneğin, bir mobil uygulamamda birden fazla ABI (ARMv7, ARM64, x86) için derlenmiş native kütüphaneleri manuel olarak kontrol etmeyi unuttuğumda, uygulamanın boyutu gereksiz yere belirgin biçimde artmıştı. Modern Android App Bundle (AAB) formatı bu sorunu büyük ölçüde çözse de, eski APK dağıtımlarında veya manuel yapılandırmalarda bu tür detaylar gözden kaçabiliyor.

Bir diğer büyük etken ise yüksek çözünürlüklü veya optimize edilmemiş görsel varlıklar. Bir ERP projesi için geliştirdiğim operatör ekranlarında, kullanıcı arayüzü elementleri için kullanılan simgeler ve arka plan görselleri, başlangıçta PNG formatında ve gereğinden yüksek çözünürlükteydi. Bu durum, uygulamanın toplam boyutunun kayda değer bir bölümünü görsellerin oluşturmasına neden oldu. Basit bir WebP dönüşümü ve çözünürlük optimizasyonu ile bu boyutu belirgin ölçüde küçültmeyi başardık.

# Bir Android APK dosyasının içeriğini analiz etmek için örnek komut
# Bu, APK içindeki dosya tiplerine ve boyutlarına genel bir bakış sağlar.
# 'assets/' ve 'lib/' dizinleri genellikle en büyük şişkinlik kaynaklarıdır.
# apk-analyzer veya Android Studio'nun APK Analyzer aracı daha detaylı bilgi verir.

# APK'yı bir dizine açmak için (sadece bir örnek, gerçek araçlar farklı olabilir)
# unzip -l my_app.apk | awk '{print $NF, $1}' | sort -rh | head -n 10

# APK Analyzer çıktısı boyutu bileşenlere ayırır; tipik bir uygulamada
# en büyük paylar genellikle 'lib/' (native kütüphaneler, ABI başına .so)
# ve 'assets/' (resim, font, medya) dizinlerine aittir. 'classes.dex' (kod)
# ve 'res/' çoğu zaman daha küçük bir paya sahiptir.

Yukarıdaki analiz mantığında da görüldüğü gibi, lib/ ve assets/ dizinleri çoğu zaman toplam boyutun büyük bir kısmını oluşturur. Bu, sadece kod optimizasyonuna odaklanmanın ne kadar yetersiz kalabileceğini açıkça gösteriyor. Gerçek bir optimizasyon çabası, tüm bu bileşenleri kapsayan bütünsel bir yaklaşım gerektirir.

Yanılgı 2: Her Şeyi Manuel Sıkıştırmak Her Zaman En İyisidir

Uygulama boyutunu küçültmek için “her şeyi sıkıştıralım” mantığıyla hareket etmek de sıkça düşülen bir yanılgı. Özellikle görseller veya diğer medya dosyaları için her geliştirici kendince bir sıkıştırma aracı bulup kullanmaya meyillidir. Ancak bu manuel sıkıştırma süreçleri, hem zaman kaybına yol açabilir hem de bazı durumlarda beklenen faydayı sağlamayabilir, hatta performansı olumsuz etkileyebilir.

Modern build sistemleri ve dağıtım platformları (örneğin Google Play Store’un AAB formatı), uygulamanızın dağıtım boyutunu optimize etmek için zaten gelişmiş mekanizmalar sunuyor. AAB, cihazın diline, ekran yoğunluğuna ve ABI’sine göre optimize edilmiş kaynakları indirerek kullanıcıya yalnızca ihtiyacı olanı sunar. Bu, geliştiricinin manuel olarak farklı asset setleri oluşturma veya karmaşık sıkıştırma algoritmalarıyla uğraşma ihtiyacını azaltır. Benim deneyimimde, AAB’ye geçiş yaptığımızda, standart APK boyutuna kıyasla kayda değer bir küçülme otomatik olarak sağlandı.

Görsel sıkıştırma konusunda, PNG veya JPEG yerine WebP gibi modern formatlara geçmek genellikle iyi bir adımdır. WebP, aynı görsel kalitesini çok daha küçük dosya boyutlarıyla sunabilir. Ancak burada da bir denge gözetmek gerekir. Örneğin, çok küçük boyutlu simgeleri WebP’ye dönüştürmek, dosya boyutunda milimetrik farklar yaratırken, dekompresyon için ek CPU döngüleri harcanmasına neden olabilir. Daha önce bir müşteri projesinde, her simgeyi WebP’ye çevirip “boyutu küçülttük” diye sevinirken, aslında uygulamanın açılış süresinde mikro düzeyde bir artış olduğunu fark etmiştik. Bunun nedeni, yüzlerce küçük WebP dosyasının dekompresyonunun toplamda önemli bir ek yük oluşturmasıydı.

// Android için build.gradle (app seviyesi) dosyasında resConfigs ile gereksiz dil ve yoğunluk kaynaklarını elemek
// Bu, AAB kullanmıyorsanız veya ek optimizasyon istiyorsanız faydalı olabilir.
android {
    defaultConfig {
        // ...
        // Sadece İngilizce ve Türkçe kaynaklarını dahil et
        resConfigs "en", "tr"
        // Sadece xhdpi ve xxhdpi yoğunluklarını dahil et
        // Geri kalanlar Play Store tarafından otomatik olarak dağıtılır veya daha düşük cihazlarda kullanılmaz.
        resConfigs "en", "tr", "xhdpi", "xxhdpi"
    }

    buildTypes {
        release {
            minifyEnabled true // Kod sıkıştırmayı etkinleştir
            shrinkResources true // Kullanılmayan kaynakları temizle
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
        }
    }
}

Yukarıdaki build.gradle yapılandırması, manuel müdahaleye gerek kalmadan bazı kaynak optimizasyonlarını nasıl otomatik olarak yapabileceğimize dair bir örnek sunuyor. resConfigs ile hangi dil ve ekran yoğunluğu kaynaklarının APK’ya dahil edileceğini belirleyebiliriz. Bu tür otomatik optimizasyonları kullanmak, manuel çabalardan çok daha verimli ve hatasız sonuçlar verebilir. Önemli olan, build sisteminin yeteneklerini iyi anlamak ve bunları doğru şekilde yapılandırmaktır.

Yanılgı 3: Küçük Uygulama Boyutu Eşittir Yüksek Performans Algısı

Bu, belki de en sinsi yanılgılardan biri. Uygulamanın indirme boyutunun küçük olmasının, doğrudan uygulamanın runtime performansının da iyi olacağı anlamına geldiği düşünülür. Oysa bu iki metrik, birbiriyle ilişkili olsa da, her zaman doğru orantılı değildir ve bazen birini optimize etmek diğerinden ödün vermeyi gerektirebilir. Bir uygulamanın performansı, sadece dosya boyutuyla değil; başlangıç süresi, bellek kullanımı, CPU döngüleri, ağ isteklerinin sayısı ve boyutu gibi birçok faktörle belirlenir.

Bir bankanın iç platformu için geliştirdiğimiz mobil uygulamada, başlangıçta uygulamanın indirme boyutunu olabildiğince düşük tutmak için her türlü asset’i ve veriyi “lazy-load” etme stratejisi benimsemiştik. Uygulama boyutu gerçekten de çok düşüktü, ancak kullanıcılar her ekran geçişinde veya ilk açılışta uzun yükleme süreleriyle karşılaşıyorlardı. Bunun nedeni, her gerekli asset’in veya verinin ağ üzerinden anlık olarak çekilmesiydi. Bu durum, özellikle zayıf ağ koşullarında kullanıcı deneyimini ciddi şekilde düşürdü.

Bu problemi çözmek için, kritik asset’leri ve ilk açılışta gösterilecek verileri uygulama içine paketlemeyi veya önbelleğe almayı tercih ettik. Uygulama boyutu bir miktar arttı, ancak başlangıç süresi belirgin ölçüde kısaldı ve kullanıcılar arayüzde çok daha akıcı bir deneyim yaşadılar. Bu tecrübe bana, “küçük boyut” takıntısının bazen kullanıcı deneyimini göz ardı etmeye yol açabileceğini gösterdi. mobil uygulama performans optimizasyonu konusunda daha detaylı bir analiz yapmıştım.

// Android'de bellek kullanımını incelemek için adb komutu
// Bu komut, bir uygulamanın anlık bellek kullanımını detaylı bir şekilde gösterir.
// Özellikle "Native Heap", "Dalvik Heap" ve "ART Heap" kısımları önemlidir.
adb shell dumpsys meminfo com.example.myapp

# Çıktı; Total PSS (RAM) ile birlikte Dalvik Heap, Native Heap ve ART Heap gibi
# bölümleri ayrı ayrı listeler. Bu kesitler, uygulamanızın hangi bileşenlerinin
# ne kadar bellek tükettiğini anlamanıza yardımcı olur.
# Büyük görseller, bellek sızıntıları veya verimsiz veri yapıları native/dalvik heap'i şişirebilir.

Yukarıdaki adb dumpsys meminfo çıktısı, uygulamanın runtime bellek kullanımını izlemek için kritik bir araçtır. Bazen küçük bir indirme boyutuna sahip bir uygulama, runtime’da çok fazla bellek tüketebilir ve bu da cihazın yavaşlamasına veya uygulamanın kapanmasına neden olabilir. Bu yüzden optimizasyon kararları verirken, uygulamanın sadece indirme anındaki boyutuna değil, kullanım esnasındaki tüm kaynak tüketimine bakmak gerekir.

Pragmatik Çözümler ve Stratejiler

Bu yanılgılardan öğrendiğim derslerle, mobil uygulama boyut optimizasyonuna daha dengeli ve pragmatik bir yaklaşım geliştirdim. İşte benim uyguladığım bazı stratejiler:

1. Kapsamlı Boyut Analizi: İlk adım her zaman kapsamlı bir analiz olmalıdır. Android Studio’nun APK Analyzer’ı veya Xcode’un Build Report’ları gibi araçlar, uygulamanızın hangi bileşenlerinin ne kadar yer kapladığını net bir şekilde gösterir. Bu analizde sadece kod değil, asset’ler, native kütüphaneler ve resource’lar da incelenmelidir. Özellikle AAB kullanıyorsanız, Play Store’un kendi boyut raporlarını da incelemek faydalıdır.
2. Asset Optimizasyonu Otomatize Etme: Görsel ve medya varlıklarını optimize etmek için manuel süreçlerden kaçının. WebP, AVIF gibi modern formatları tercih edin ve bu dönüşümleri build sürecinize entegre edin. Örneğin, imagemin gibi araçları CI/CD pipeline’ınıza ekleyerek, her commit’te görsellerin otomatik olarak optimize edilmesini sağlayabilirsiniz. Bir yan ürünümün web sitesi için kullandığım görsel optimizasyon süreçlerini web sitesi görsel optimizasyonu yazısında detaylıca anlatmıştım.
3. Dinamik Özellik Modülleri (Dynamic Feature Modules): Android’de Dynamic Feature Modules, iOS’ta On-Demand Resources (ODR) gibi özellikler, uygulamanın bazı kısımlarını yalnızca ihtiyaç duyulduğunda indirme imkanı sunar. Bu, ilk indirme boyutunu önemli ölçüde küçülterek, kullanıcıların uygulamaya daha hızlı erişmesini sağlar. Bir müşteri projesinde, az kullanılan raporlama modüllerini dinamik hale getirerek ilk indirme boyutunu hatırı sayılır ölçüde düşürdük.
4. Native Kütüphane Yönetimi: Gereksiz ABI’leri elemek için abiFilters kullanın veya AAB’nin bu işi sizin yerinize yapmasına izin verin. Eğer kendi native kütüphanelerinizi geliştiriyorsanız, sadece gerçekten ihtiyaç duyulan fonksiyonları dahil edin ve derleme seçeneklerini optimize edin. Benim gördüğüm kadarıyla, çoğu zaman “her şey dahil” mantığıyla derlenen native kütüphaneler büyük boyutlara ulaşıyor.
5. Runtime Performans Metriklerini İzleme: Uygulama boyutunu küçültürken, aynı zamanda uygulamanın başlangıç süresi, bellek kullanımı ve CPU tüketimi gibi runtime performans metriklerini de sürekli olarak izleyin. Firebase Performance Monitoring veya benzeri araçlar bu konuda size değerli veriler sağlayacaktır. Unutmayın, nihai amaç kullanıcının akıcı ve keyifli bir deneyim yaşamasını sağlamaktır, sadece indirme boyutunu küçültmek değil.

Dersler ve Gelecek Adımlar

Mobil uygulama boyut optimizasyonu, tek seferlik bir işlem değil, uygulamanın yaşam döngüsü boyunca devam eden bir süreçtir. Tecrübemde, her zaman bir şeyleri yanlış yaptığımı, sonra dönüp düzelttiğimi gördüm. Önemli olan, bu yanılgılara düşmekten çekinmemek ve her hatadan bir ders çıkarmaktır. Örneğin, geçen ay bir Flutter projesinde, flutter build apk --split-per-abi komutunu kullanmayı unuttuğum için, tek bir APK’nın gereksiz yere şiştiğini fark ettim. Bu, basit bir komut olsa da, otomasyon eksikliği nedeniyle gözden kaçabiliyor.

Gelecek projelerimde, özellikle AI destekli operasyonlar ve üretim planlama gibi alanlarda mobil uygulamalar geliştirmeye devam edeceğim. Bu projelerde, model boyutları ve RAG (Retrieval-Augmented Generation) için gerekli veri setlerinin yönetimi, uygulama boyutunu daha da karmaşık hale getirecek. Bu yüzden, dynamic feature modules gibi yaklaşımları AI modellerini ve verilerini lazy-load etmek için daha aktif kullanmayı planlıyorum.

Mobil platformlardaki gelişmeler, optimizasyon yaklaşımlarımızı da sürekli olarak evrimleştirmemizi gerektiriyor. Yeni sıkıştırma algoritmaları, yeni dağıtım formatları ve cihazların artan işlem gücü, bize daha fazla seçenek sunuyor. Ancak bu seçenekler arasında doğru dengeyi bulmak, hala geliştiricinin deneyim ve analitik becerisine kalmış durumda.

Sonuç: Dengeli Bir Yaklaşım Şart

Mobil uygulama boyutunu optimize ederken, sadece derlenmiş kodun veya görsel varlıkların boyutuna takılıp kalmak, resmin tamamını görmemizi engeller. Ayrıca, her şeyi manuel olarak sıkıştırmaya çalışmak veya küçük bir boyutun her zaman en iyi performansı sağlayacağını düşünmek de bizi yanlış yönlendirebilir. Gerçek optimizasyon, uygulamanın tüm bileşenlerini kapsayan, build sistemlerinin yeteneklerini kullanan ve kullanıcı deneyimini merkeze alan dengeli bir yaklaşımla mümkündür.

Benim için önemli olan, bir optimizasyon kararının sadece bir metrik üzerindeki etkisini değil, diğer tüm metrikler üzerindeki potansiyel etkilerini de göz önünde bulundurmak. Uygulama boyutu bir başlangıç noktası olabilir, ancak nihai hedef her zaman hızlı, akıcı ve kullanıcı dostu bir uygulama sunmaktır. Bu dengenin peşinden koşmaya devam edeceğim.