Mobil geliştirmede App Size Optimization: temeller, yöntemler ve uygulamalar

App Size Optimization Nedir

App Size Optimization, uygulama kurulum paketinin boyutunu en aza indirmeyi amaçlayan bir mobil geliştirme disiplinidir. Ölü kodu ve kaynakları kaldırma, görüntüleri sıkıştırma, kütüphaneleri optimize etme, farklı mimariler için derleme bölümlemesi ve talep üzerine teslimat teknolojilerini kullanmayı içerir.

Uygulama boyutu, farklı kullanıcı segmentlerini eşitsiz şekilde etkiler. Gelişmiş mobil altyapıya sahip bölgelerde (ABD, Avrupa, Japonya) 50 ve 100 MB arasındaki fark fark edilmeyebilir. Gelişmekte olan bölgelerde (Hindistan, Endonezya, Brezilya) her ek megabayt, veri planı sınırlamaları ve mobil internet hızı nedeniyle yükleme dönüşümünü azaltır. Google Play, APK boyutunu 200 MB ile sınırlar ancak 100 MB'ın altında tutmayı önerir.

iOS App Store için hücresel ağ üzerinden maksimum indirme boyutu 200 MB'tır (2023'ten önce 150 MB idi). IPA bu sınırı aşarsa, kullanıcı uygulamayı yalnızca Wi-Fi üzerinden kurabilir. Apple ayrıca Slicing, Bitcode ve On-Demand Resources — geliştirici müdahalesi olmadan belirli bir cihazda kurulum boyutunu otomatik olarak azaltan teknolojiler — içeren App Thinning'i de destekler.

Uygulama Boyutu Neden Kritiktir

Uygulama boyutu yalnızca yükleme dönüşümünü değil, aynı zamanda kullanıcı tutmayı, güncelleme sıklığını ve ilk başlatma hızını da etkiler. Her ek megabayt, kullanıcı ile ürününüzü kullanma arasında bir engeldir.

Yükleme Dönüşümüne Etkisi

Google I/O 2024 verilerine göre, APK'yı 10 MB küçültmek yükleme dönüşümünü ortalama %3,5 artırır. 150+ MB boyutundaki uygulamalar için dönüşüm, aynı sınıftaki 50 MB uygulamalara göre %20–30 daha düşük olabilir. Etki, kullanıcının kurulumdan önce boyutu gördüğü Google Play'de belirgindir. App Store'da boyut uygulama sayfasında gösterilir ve sınırlı veri planına sahip kullanıcılar kurulumu Wi-Fi'ye erteler, ardından genellikle uygulamayı unuturlar.

Güncelleme Sıklığı ve OTA Güncellemeleri

Büyük uygulamalar OTA ile daha az sıklıkta güncellenir — kullanıcılar yama indirmelerini Wi-Fi'ye erteler ve kritik güvenlik düzeltmelerini kaçırır. Google Play, Incremental Updates'e (10 MB'a kadar yamalar) izin verir, ancak tam yeniden kurulum yine de tüm APK veya AAB'yi indirir. Apple App Store, yalnızca değiştirilen dosyaları aktaran Delta Updates kullanır, ancak kaynaklar değiştiğinde delta bile önemli olabilir.

İlk Başlatma ve Açma

Boyut, ilk başlatma süresini doğrudan etkiler: uygulama kaynakları açmalı, kodu derlemeli (Android) veya önbelleği imzalamalıdır (iOS). 200 MB'lık bir uygulama, ortalama bir cihazda 50 MB'lık bir uygulamadan 10–15 saniye daha yavaş başlayabilir. Bu, Karşılama Deneyimini kötüleştirir — kullanıcı yüklenmesini beklemeden uygulamayı kapatabilir.

Kaynakların ve Varlıkların Optimizasyonu

Kaynaklar — görüntüler, yazı tipleri, sesler, videolar — tipik bir mobil uygulama boyutunun %60–80'ini oluşturur. Kaynak optimizasyonu, minimum çabayla en büyük kazancı sağlar. Ana yönler şunlardır: sıkıştırma, yinelenenleri ve kullanılmayan varlıkları kaldırma, doğru biçimleri seçme.

Görüntü Optimizasyonu

WebP — Google'dan, aynı görsel kalitede PNG'den %25–35, JPEG'den %15–20 daha iyi sıkıştırma sağlayan bir görüntü biçimidir. Android, API 18'den itibaren WebP'yi yerel olarak destekler. iOS için WebP, SDWebImage veya Kingfisher kütüphaneleri aracılığıyla desteklenir ve iOS 17 ile yerel destek geldi. AVIF — WebP'ye göre ek %10–15 tasarruf sağlayan ancak daha yavaş kod çözümü olan daha modern bir biçim.

Kullanılmayan kaynakları kaldırma — boyutu küçültmenin en basit yoludur. Android'de, Android Studio ile yeniden düzenleme kullanın: Analyze → Run Inspection → Unused Resources. iOS'te — Build Settings → Remove Unused Resources. Projelerde genellikle önceki sürümlerden sprite'lar, eski simgeler, kullanılmayan başlatma ekranı görüntüleri kalır ve bunlar işlevsel bir yük olmadan boyutu şişirir.

Yazı Tipi ve Ses Optimizasyonu

Özel yazı tipleri, özellikle tüm yazı tipi ailesi dahil edilmişse (tüm stiller: Regular, Bold, Italic, BoldItalic) 5–15 MB yer kaplayabilir. Alt kümeleme — uygulama tarafından desteklenmeyen diller için glifleri kaldırma — yoluyla yalnızca gerekli stilleri ve karakter alt kümelerini kullanın. Google Fonts ve Transfonter gibi hizmetler minimum karakter seti oluşturmaya olanak tanır. Ses için, WAV ve sıkıştırılmamış biçimler yerine AAC/HE-AAC kullanın — kalite kaybı olmadan %90'a varan tasarruf.

Kod ve Kütüphanelerin Optimizasyonu

Kod, uygulama boyutunun %20–40'ını oluşturur, ancak optimizasyonu kaynaklardan daha karmaşıktır çünkü bağımlılık analizi, karıştırma ve işlevselliği bozma riski olmadan ölü kod kaldırma gerektirir.

Android için ProGuard ve R8

ProGuard, kod karıştırma, küçültme ve optimizasyon gerçekleştiren bir Android aracıdır. R8 — Android Gradle Plugin'e yerleşik halefi, daha hızlı ve daha verimli çalışır. R8, kullanılmayan sınıfları ve yöntemleri kaldırır, değişken adlarını kısaltır ve talimat sayısını azaltmak için kodu yeniden yazar. R8 ile DEX dosya boyutunda tipik azalma %30–50'dir.

// build.gradle — küçültme için R8 yapılandırması
android {
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile(
                'proguard-android-optimize.txt')
            shrinkResources true
        }
    }
}

Kütüphane ve Bağımlılık Optimizasyonu

Kütüphaneler — şişkin boyutun yaygın bir nedenidir. Bir kütüphane, uygulamaya doğrudan fayda sağlamadan boyutu 5–20 MB artıran geçişli bağımlılıkları beraberinde getirebilir. Açık bağımlılık bildirimi ile Android için Gradle Version Catalog ve iOS için Swift Package Manager kullanın. Android Studio'da Build Analyzer veya Xcode Build Timeline ile boyutu analiz edin. Ağır kütüphaneleri daha hafif alternatiflerle değiştirin: örneğin, Apache HTTP (15 MB) yerine OkHttp (3 MB).

iOS'te Kullanılmayan Kodu Kaldırma

Dead Code Stripping — Xcode'ta bağlama aşamasında kullanılmayan yöntemlerin ve sınıfların otomatik olarak kaldırılmasıdır. Build Settings → Dead Code Stripping = YES ile etkinleştirilir. Bitcode — Apple'ın farklı mimariler için yeniden derleyebileceği, kullanılmayan işlevleri kaldıran bir ara temsildir. Ancak Xcode 14'ten itibaren Bitcode isteğe bağlı hale gelmiştir ve boyut azaltmaya katkısı Objective-C projeleri için %5–15, Swift için daha azdır.

App Thinning ve Talep Üzerine Teslimat

App Thinning — yalnızca belirli bir cihaz için gerekli kaynakları sağlayarak yüklü uygulamanın boyutunu otomatik olarak azaltan Apple teknolojisidir. Slicing, On-Demand Resources ve Bitcode olmak üzere üç bileşenden oluşur. Android'de karşılığı, Dynamic Delivery ile Android App Bundle (AAB)'dır.

Android App Bundle (AAB)

AAB — Google Play'de bir yayınlama biçimidir ve mağaza her cihaz için ayrı ayrı APK oluşturur, yalnızca mimarisi (armeabi-v7a, arm64-v8a), ekran yoğunluğu (mdpi, hdpi, xhdpi, xxhdpi, xxxhdpi) ve dilleri için kaynakları dahil eder. Evrensel APK'dan AAB'ye geçişte tipik kurulum boyutu azalması %20–40'tır. Play Feature Delivery, talep üzerine modül yüklemeye izin verirken, Install-time modülleri temel kuruluma dahil edilir.

// build.gradle — AAB ve Dynamic Features yapılandırması
android {
    bundle {
        language {
            enableSplit = true
        }
        density {
            enableSplit = true
        }
        abi {
            enableSplit = true
        }
    }
}

iOS'te On-Demand Resources

On-Demand Resources (ODR) — kaynakların (oyun seviyeleri, yüksek çözünürlüklü görüntüler, videolar) yalnızca kullanıcının gerçekten ihtiyaç duyduğunda Apple sunucularından indirildiği bir iOS mekanizmasıdır. İlk kurulum boyutu %50–80 oranında azaltılabilir. Kaynaklar üç kategoriye ayrılır: Initial Install Tags (kurulum sırasında indirilir), Prefetched Tag Order (kurulumdan sonra arka planda indirilir) ve On-Demand (yalnızca talep üzerine indirilir). Apple, ilk ekranda gerekli olmayan içerik için ODR kullanılmasını önerir: oyun seviyeleri, ek içerik, video eğitimleri.

SwiftUI, Bundle.module özelliği aracılığıyla ODR'yi desteklerken UIKit, NSBundleResourceRequest kullanır. Unity ve Unreal Engine'deki oyunlar için ODR, yerel sarmalayıcı düzeyinde entegre edilir. Ana sınırlama, ODR kaynaklarının depolama alanı düşük olduğunda sistem tarafından silinmesidir, bu nedenle kritik veriler ana derlemeye dahil edilmelidir.