Mobil ilova ishlab chiqishda App Size Optimization: asoslar, usullar va amaliyotlar

App Size Optimization nima

App Size Optimization — ilovaning o'rnatish paketi hajmini minimallashtirishga qaratilgan mobil ilova ishlab chiqish intizomi. O'lik kod va resurslarni olib tashlash, tasvirlarni siqish, kutubxonalarni optimallashtirish, turli arxitekturalar uchun kompilyatsiyani fragmentatsiyalash va talab bo'yicha yetkazib berish texnologiyalaridan foydalanishni o'z ichiga oladi.

Ilova hajmi notekis ta'sir qiladi turli foydalanuvchi segmentlariga. Rivojlangan mobil infratuzilmali hududlarda (AQSh, Yevropa, Yaponiya) 50 va 100 MB o'rtasidagi farq sezilmas bo'lishi mumkin. Rivojlanayotgan hududlarda (Hindiston, Indoneziya, Braziliya) har bir qo'shimcha megabayt tarif cheklovlari va mobil internet tezligi sababli o'rnatish konversiyasini kamaytiradi. Google Play APK hajmini 200 MB bilan cheklaydi, lekin hajmni 100 MB dan past ushlab turishni tavsiya qiladi.

iOS App Store uchun mobil tarmoq orqali yuklashning maksimal hajmi 200 MB (2023 yilgacha 150 MB edi). IPA bu chegaradan oshsa, foydalanuvchi ilovani faqat Wi-Fi orqali o'rnatishi mumkin. Apple shuningdek App Thinning-ni qo'llab-quvvatlaydi, unga Slicing, Bitcode va On-Demand Resources kiradi — dasturchi ishtirokisiz ma'lum qurilmada o'rnatish hajmini avtomatik kamaytiradigan texnologiyalar.

Ilova hajmi nima uchun muhim

Ilova hajmi nafaqat o'rnatish konversiyasiga, balki retention-ga, yangilanish chastotasiga va birinchi ishga tushirish tezligiga ta'sir qiladi. Har bir qo'shimcha megabayt foydalanuvchi bilan mahsulotingiz o'rtasidagi to'siqdir.

O'rnatish konversiyasiga ta'siri

Google I/O 2024 ma'lumotlariga ko'ra, APK ni 10 MB kamaytirish o'rnatish konversiyasini o'rtacha 3,5% oshiradi. 150+ MB hajmdagi ilovalar uchun konversiya 50 MB hajmdagi bir sinf ilovalariga nisbatan 20–30% past bo'lishi mumkin. Effekt ayniqsa Google Play-da sezilarli, bu yerda foydalanuvchi o'rnatishdan oldin hajmni ko'radi. App Store-da hajm ilova sahifasida ko'rsatiladi va cheklangan tarifli foydalanuvchilar o'rnatishni kechiktiradilar Wi-Fi gacha, keyin esa ko'pincha ilovani unutadilar.

Yangilanish chastotasi va havo orqali yangilanish

Katta ilova havo orqali kamroq yangilanadi — foydalanuvchilar yamalarni yuklashni Wi-Fi gacha kechiktiradilar, muhim xavfsizlik tuzatishlarini o'tkazib yuboradilar. Google Play Incremental Updates (10 MB gacha yamalar) dan foydalanishga imkon beradi, ammo to'liq qayta o'rnatish baribir butun APK yoki AAB ni yuklaydi. Apple App Store Delta Updates dan foydalanadi, faqat o'zgartirilgan fayllarni uzatadi, lekin hatto delta resurslar o'zgarganda sezilarli bo'lishi mumkin.

Birinchi ishga tushirish va ochish

Hajm to'g'ridan-to'g'ri birinchi ishga tushirish vaqtiga ta'sir qiladi: ilova resurslarni ochishi, kodni kompilyatsiya qilishi (Android) yoki keshni imzolashi kerak (iOS). 200 MB hajmdagi ilova o'rtacha qurilmada 50 MB hajmdagi ilovadan 10–15 soniya kechroq ishga tushishi mumkin. Bu Onboarding Experience ni yomonlashtiradi — foydalanuvchi yuklanishni kutmasdan ilovani yopishi mumkin.

Resurslar va aktivlarni optimallashtirish

Resurslar — tasvirlar, shriftlar, tovushlar, video — odatdagi mobil ilova hajmining 60–80% ini tashkil qiladi. Resurslarni optimallashtirish minimal mehnat bilan eng katta foyda beradi. Asosiy yo'nalishlar: siqish, dublikatlar va foydalanilmayotgan aktivlarni olib tashlash, to'g'ri formatlarni tanlash.

Tasvirlarni optimallashtirish

WebP — Google-dan tasvir formati, bir xil vizual sifatda PNG dan 25–35% va JPEG dan 15–20% yaxshiroq siqishni ta'minlaydi. Android WebP ni API 18 dan boshlab mahalliy qo'llab-quvvatlaydi. iOS uchun WebP SDWebImage yoki Kingfisher kutubxonasi orqali qo'llab-quvvatlanadi va iOS 17 dan mahalliy qo'llab-quvvatlash paydo bo'ldi. AVIF — zamonaviyroq format, WebP ga nisbatan qo'shimcha 10–15% tejash beradi, lekin sekinroq dekodlash bilan.

Foydalanilmayotgan resurslarni olib tashlash — hajmni kamaytirishning eng oddiy usuli. Android da Android Studio bilan refaktoringdan foydalaning: Analyze → Run Inspection → Unused Resources. iOS da — Build Settings → Remove Unused Resources. Ko'pincha loyihalarda oldingi versiyalardan qolgan spritelar, eski ikonkalar, foydalanilmayotgan boshlang'ich ekran tasvirlari qoladi, ular shishiradi hajmni hech qanday funksional yuklamasiz.

Shriftlar va tovushlarni optimallashtirish

Maxsus shriftlar 5–15 MB egallashi mumkin, ayniqsa butun oila ulangan bo'lsa (barcha uslublar: Regular, Bold, Italic, BoldItalic). Faqat kerakli uslublar va belgilar kichik to'plamlaridan subsetting orqali foydalaning — ilova tomonidan qo'llab-quvvatlanmaydigan tillar uchun gliflarni olib tashlash. Google Fonts va Transfonter kabi xizmatlar minimal belgilar to'plamini yaratishga imkon beradi. Tovushlar uchun WAV va siqilmagan formatlar o'rniga AAC/HE-AAC dan foydalaning — sifat yo'qotmasdan 90% gacha tejash.

Kod va kutubxonalarni optimallashtirish

Kod ilova hajmining 20–40% ini tashkil qiladi, lekin uni optimallashtirish resurslardan qiyinroq, chunki bog'liqliklarni tahlil qilish, obfuskatsiya va funksionallikni buzish xavfisiz o'lik kodni olib tashlashni talab qiladi.

Android uchun ProGuard va R8

ProGuard — Android uchun kod obfuskatsiyasi, minifikatsiyasi va optimallashtirishni amalga oshiradigan vosita. R8 — uning vorisi, Android Gradle Plugin tarkibida, tezroq va samaraliroq ishlaydi. R8 foydalanilmayotgan sinflar va metodlarni olib tashlaydi, o'zgaruvchi nomlarini qisqartiradi va ko'rsatmalar sonini kamaytirish uchun kodni qayta yozadi. R8 bilan DEX fayllarining odatdagi hajm kamayishi 30–50% ni tashkil qiladi.

// build.gradle — R8 ni minifikatsiya uchun sozlash
android {
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile(
                'proguard-android-optimize.txt')
            shrinkResources true
        }
    }
}

Kutubxonalar va bog'liqliklarni optimallashtirish

Kutubxonalar — shishgan hajmning keng tarqalgan sababi. Bitta kutubxona ilova uchun bevosita foydasiz hajmni 5–20 MB oshiradigan tranzitiv bog'liqliklarni tortib olishi mumkin. Android uchun Gradle Version Catalog va iOS uchun Swift Package Manager dan bog'liqliklarni aniq ko'rsatib foydalaning. Android Studio da Build Analyzer yoki Xcode Build Timeline bilan hajmni tahlil qiling. Og'ir kutubxonalarni engilroq alternativlar bilan almashtiring: masalan, OkHttp (3 MB) Apache HTTP (15 MB) o'rniga.

iOS da foydalanilmayotgan kodni olib tashlash

Dead Code Stripping — Xcode da bog'lash bosqichida foydalanilmayotgan metodlar va sinflarni avtomatik olib tashlash. Build Settings → Dead Code Stripping = YES orqali yoqiladi. Bitcode — Apple turli arxitekturalar uchun qayta kompilyatsiya qilishi mumkin bo'lgan, foydalanilmayotgan funksiyalarni olib tashlaydigan oraliq tasvir. Biroq Xcode 14 dan Bitcode ixtiyoriy bo'ldi va uning hajm kamayishiga qo'shgan hissasi Objective-C loyihalari uchun 5–15%, Swift uchun esa kamroq.

App Thinning va talab bo'yicha yetkazib berish

App Thinning — Apple-ning o'rnatilgan ilova hajmini faqat ma'lum qurilmaga kerakli resurslarni yetkazib berish orqali avtomatik kamaytiradigan texnologiyasi. Uch komponentdan iborat: Slicing, On-Demand Resources va Bitcode. Android da analog Dynamic Delivery bilan Android App Bundle (AAB) hisoblanadi.

Android App Bundle (AAB)

AAB — Google Play da nashr formati, bunda do'kon har bir qurilma uchun faqat uning arxitekturasi (armeabi-v7a, arm64-v8a), ekran zichligi (mdpi, hdpi, xhdpi, xxhdpi, xxxhdpi) va tillari uchun resurslarni kiritib APK yaratadi. Universal APK dan AAB ga o'tishda o'rnatish hajmining odatdagi kamayishi 20–40% ni tashkil qiladi. Play Feature Delivery modullarni talab bo'yicha yuklashga imkon beradi, Install-time modullari esa asosiy o'rnatishga kiritiladi.

// build.gradle — AAB va Dynamic Features sozlamasi
android {
    bundle {
        language {
            enableSplit = true
        }
        density {
            enableSplit = true
        }
        abi {
            enableSplit = true
        }
    }
}

iOS da On-Demand Resources

On-Demand Resources (ODR) — iOS mexanizmi, bunda resurslar (o'yin darajalari, yuqori aniqlikdagi tasvirlar, video) Apple serverlaridan faqat foydalanuvchiga haqiqatan kerak bo'lganda yuklanadi. Dastlabki o'rnatish hajmi 50–80% kamaytirilishi mumkin. Resurslar uch toifaga bo'linadi: Initial Install Tags (o'rnatish vaqtida yuklanadi), Prefetched Tag Order (o'rnatishdan keyin fonda yuklanadi) va On-Demand (faqat so'rov bo'yicha yuklanadi). Apple ODR dan tarkib uchun foydalanishni tavsiya qiladi, birinchi ekranda kerak bo'lmagan: o'yin darajalari, qo'shimcha tarkib, video ko'rsatmalar.

SwiftUI ODR ni Bundle.module atributi orqali, UIKit esa NSBundleResourceRequest orqali qo'llab-quvvatlaydi. Unity va Unreal Engine o'yinlari uchun ODR mahalliy darajada integratsiyalanadi. Asosiy cheklov — ODR resurslari joy yetishmasligida tizim tomonidan o'chiriladi, shuning uchun ish uchun muhim ma'lumotlar asosiy kompilyatsiyaga kiritilishi kerak.