App Size Optimization در توسعه اپلیکیشن موبایل: مبانی، روش‌ها و شیوه‌ها

App Size Optimization چیست

App Size Optimization — رشته‌ای در توسعه اپلیکیشن موبایل با هدف کمینه‌سازی اندازه بسته نصب اپلیکیشن. شامل حذف کد و منابع مرده, فشرده‌سازی تصاویر, بهینه‌سازی کتابخانه‌ها, قطعه‌بندی کامپایل برای معماری‌های مختلف و استفاده از فناوری‌های تحویل بر اساس تقاضا می‌شود.

اندازه اپلیکیشن به طور نابرابر بر بخش‌های مختلف کاربران تأثیر می‌گذارد. در مناطق با زیرساخت موبایل پیشرفته (آمریکا, اروپا, ژاپن) تفاوت بین ۵۰ و ۱۰۰ مگابایت ممکن است نامحسوس باشد. در مناطق در حال توسعه (هند, اندونزی, برزیل) هر مگابایت اضافی به دلیل محدودیت تعرفه‌ها و سرعت اینترنت موبایل نرخ تبدیل نصب را کاهش می‌دهد. Google Play اندازه APK را به ۲۰۰ مگابایت محدود می‌کند, اما توصیه می‌کند اندازه را زیر ۱۰۰ مگابایت نگه دارید.

برای iOS App Store حداکثر اندازه دانلود از طریق شبکه سلولی ۲۰۰ مگابایت است (تا سال ۲۰۲۳, ۱۵۰ مگابایت بود). اگر IPA از این حد تجاوز کند, کاربر فقط می‌تواند اپلیکیشن را از طریق Wi-Fi نصب کند. Apple همچنین از App Thinning پشتیبانی می‌کند که شامل Slicing, Bitcode و On-Demand Resources — فناوری‌هایی که به طور خودکار اندازه نصب را در یک دستگاه خاص بدون دخالت توسعه‌دهنده کاهش می‌دهند.

چرا اندازه اپلیکیشن حیاتی است

اندازه اپلیکیشن نه تنها بر نرخ تبدیل نصب, بلکه بر retention, دفعات به‌روزرسانی و سرعت اولین راه‌اندازی تأثیر می‌گذارد. هر مگابایت اضافی یک مانع بین کاربر و استفاده از محصول شما است.

تأثیر بر نرخ تبدیل نصب

بر اساس داده‌های Google I/O ۲۰۲۴, کاهش ۱۰ مگابایتی APK نرخ تبدیل نصب را به طور میانگین ۳.۵% افزایش می‌دهد. برای اپلیکیشن‌های با اندازه ۱۵۰+ مگابایت, نرخ تبدیل ممکن است ۲۰–۳۰% کمتر از اپلیکیشن‌های همان کلاس با اندازه ۵۰ مگابایت باشد. این اثر به ویژه در Google Play مشهود است, جایی که کاربر اندازه را قبل از نصب می‌بیند. در App Store اندازه در صفحه اپلیکیشن نشان داده می‌شود و کاربران با تعرفه محدود نصب را به تعویق می‌اندازند تا Wi-Fi, پس از آن اغلب اپلیکیشن را فراموش می‌کنند.

دفعات به‌روزرسانی و به‌روزرسانی از طریق هوا

اپلیکیشن بزرگ کمتر از طریق هوا به‌روزرسانی می‌شود — کاربران دانلود وصله‌ها را به Wi-Fi موکول می‌کنند و اصلاحیه‌های امنیتی بحرانی را از دست می‌دهند. Google Play امکان استفاده از Incremental Updates (وصله‌های تا ۱۰ مگابایت) را فراهم می‌کند, اما نصب مجدد کامل همچنان کل APK یا AAB را دانلود می‌کند. Apple App Store از Delta Updates استفاده می‌کند و فقط فایل‌های تغییر یافته را ارسال می‌کند, اما حتی دلتا نیز می‌تواند در هنگام تغییر منابع قابل توجه باشد.

اولین راه‌اندازی و باز کردن بسته

اندازه به طور مستقیم بر زمان اولین راه‌اندازی تأثیر می‌گذارد: اپلیکیشن باید منابع را باز کند, کد را کامپایل کند (Android) یا کش را امضا کند (iOS). اپلیکیشن با اندازه ۲۰۰ مگابایت ممکن است ۱۰–۱۵ ثانیه دیرتر از اپلیکیشن ۵۰ مگابایتی در یک دستگاه متوسط راه‌اندازی شود. این تجربه ورود را بدتر می‌کند — کاربر ممکن است بدون منتظر ماندن برای بارگذاری, اپلیکیشن را ببندد.

بهینه‌سازی منابع و دارایی‌ها

منابع — تصاویر, فونت‌ها, صداها, ویدئو — ۶۰–۸۰% اندازه یک اپلیکیشن موبایل معمولی را تشکیل می‌دهند. بهینه‌سازی منابع با حداقل تلاش بیشترین سود را می‌دهد. جهت‌های اصلی: فشرده‌سازی, حذف موارد تکراری و دارایی‌های استفاده نشده, انتخاب فرمت‌های مناسب.

بهینه‌سازی تصاویر

WebP — فرمت تصویر از Google که ۲۵–۳۵% فشرده‌سازی بهتر از PNG و ۱۵–۲۰% بهتر از JPEG با همان کیفیت بصری ارائه می‌دهد. Android از WebP به صورت بومی از API ۱۸ پشتیبانی می‌کند. برای iOS, WebP از طریق کتابخانه SDWebImage یا Kingfisher پشتیبانی می‌شود و از iOS ۱۷ پشتیبانی بومی اضافه شد. AVIF — فرمت مدرن‌تر که ۱۰–۱۵% صرفه‌جویی اضافی نسبت به WebP دارد, اما با رمزگشایی کندتر.

حذف منابع استفاده نشده — ساده‌ترین راه برای کاهش اندازه. در Android از بازسازی با Android Studio استفاده کنید: Analyze → Run Inspection → Unused Resources. در iOS — Build Settings → Remove Unused Resources. اغلب در پروژه‌ها اسپرایت‌هایی از نسخه‌های قبلی, آیکون‌های قدیمی, تصاویر صفحه راه‌اندازی استفاده نشده باقی می‌مانند که حجم را افزایش می‌دهند بدون هیچ بار عملکردی.

بهینه‌سازی فونت‌ها و صداها

فونت‌های سفارشی ممکن است ۵–۱۵ مگابایت اشغال کنند, به خصوص اگر کل خانواده متصل باشد (همه سبک‌ها: Regular, Bold, Italic, BoldItalic). فقط از سبک‌های ضروری و زیرمجموعه‌های کاراکتر از طریق subsetting استفاده کنید — حذف گلیف‌ها برای زبان‌هایی که توسط اپلیکیشن پشتیبانی نمی‌شوند. خدماتی مانند Google Fonts و Transfonter امکان ایجاد حداقل مجموعه کاراکتر را فراهم می‌کنند. برای صداها از AAC/HE-AAC به جای WAV و فرمت‌های فشرده نشده استفاده کنید — صرفه‌جویی تا ۹۰% بدون افت کیفیت.

بهینه‌سازی کد و کتابخانه‌ها

کد ۲۰–۴۰% از اندازه اپلیکیشن را تشکیل می‌دهد, اما بهینه‌سازی آن پیچیده‌تر از منابع است زیرا نیاز به تحلیل وابستگی‌ها, مبهم‌سازی و حذف کد مرده بدون خطر شکستن عملکرد دارد.

ProGuard و R8 برای Android

ProGuard — ابزاری برای Android که مبهم‌سازی, کوچک‌سازی و بهینه‌سازی کد را انجام می‌دهد. R8 — جانشین آن, تعبیه شده در Android Gradle Plugin, سریع‌تر و کارآمدتر کار می‌کند. R8 کلاس‌ها و متدهای استفاده نشده را حذف می‌کند, نام متغیرها را کوتاه می‌کند و کد را برای کاهش تعداد دستورالعمل‌ها بازنویسی می‌کند. کاهش معمول اندازه فایل‌های DEX با R8 ۳۰–۵۰% است.

// build.gradle — پیکربندی R8 برای کوچک‌سازی
android {
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile(
                'proguard-android-optimize.txt')
            shrinkResources true
        }
    }
}

بهینه‌سازی کتابخانه‌ها و وابستگی‌ها

کتابخانه‌ها — علت رایج اندازه متورم. یک کتابخانه می‌تواند وابستگی‌های گذرایی را به همراه داشته باشد که اندازه را ۵–۲۰ مگابایت بدون سود مستقیم برای اپلیکیشن افزایش می‌دهد. از Gradle Version Catalog برای Android و Swift Package Manager برای iOS با ذکر صریح وابستگی‌ها استفاده کنید. اندازه را با Build Analyzer در Android Studio یا Xcode Build Timeline تحلیل کنید. کتابخانه‌های سنگین را با جایگزین‌های سبک‌تر عوض کنید: مثلاً OkHttp (۳ مگابایت) به جای Apache HTTP (۱۵ مگابایت).

حذف کد استفاده نشده در iOS

Dead Code Stripping — حذف خودکار متدها و کلاس‌های استفاده نشده در مرحله لینک‌سازی در Xcode. از طریق Build Settings → Dead Code Stripping = YES فعال می‌شود. Bitcode — نمایش میانی که Apple می‌تواند آن را برای معماری‌های مختلف بازکامپایل کند و توابع استفاده نشده را حذف کند. اما از Xcode ۱۴, Bitcode اختیاری شده و سهم آن در کاهش اندازه ۵–۱۵% برای پروژه‌های Objective-C و کمتر برای Swift است.

App Thinning و تحویل بر اساس تقاضا

App Thinning — فناوری Apple که به طور خودکار اندازه اپلیکیشن نصب شده را با تحویل فقط منابع مورد نیاز یک دستگاه خاص کاهش می‌دهد. از سه مؤلفه تشکیل شده است: Slicing, On-Demand Resources و Bitcode. در Android معادل آن Android App Bundle (AAB) با Dynamic Delivery است.

Android App Bundle (AAB)

AAB — فرمت انتشار در Google Play, که در آن فروشگاه APK را برای هر دستگاه جداگانه تولید می‌کند و فقط منابع مربوط به معماری آن (armeabi-v7a, arm64-v8a), تراکم صفحه (mdpi, hdpi, xhdpi, xxhdpi, xxxhdpi) و زبان‌ها را شامل می‌شود. کاهش معمول اندازه نصب هنگام انتقال از APK جهانی به AAB ۲۰–۴۰% است. Play Feature Delivery امکان دانلود ماژول‌ها بر اساس تقاضا را فراهم می‌کند, در حالی که ماژول‌های Install-time در نصب پایه گنجانده می‌شوند.

// build.gradle — پیکربندی AAB و Dynamic Features
android {
    bundle {
        language {
            enableSplit = true
        }
        density {
            enableSplit = true
        }
        abi {
            enableSplit = true
        }
    }
}

On-Demand Resources در iOS

On-Demand Resources (ODR) — مکانیزم iOS که در آن منابع (سطوح بازی, تصاویر با وضوح بالا, ویدئو) از سرورهای Apple فقط زمانی دانلود می‌شوند که واقعاً توسط کاربر مورد نیاز باشند. اندازه نصب اولیه می‌تواند ۵۰–۸۰% کاهش یابد. منابع به سه دسته تقسیم می‌شوند: Initial Install Tags (در هنگام نصب دانلود می‌شوند), Prefetched Tag Order (پس از نصب در پس‌زمینه دانلود می‌شوند) و On-Demand (فقط در صورت درخواست دانلود می‌شوند). Apple توصیه می‌کند از ODR برای محتوایی استفاده کنید که در صفحه اول لازم نیست: سطوح بازی, محتوای اضافی, آموزش‌های ویدئویی.

SwiftUI از ODR از طریق ویژگی Bundle.module پشتیبانی می‌کند و UIKit از طریق NSBundleResourceRequest. برای بازی‌های Unity و Unreal Engine, ODR در سطح پوسته بومی یکپارچه می‌شود. محدودیت اصلی — منابع ODR توسط سیستم در صورت کمبود فضا حذف می‌شوند, بنابراین داده‌های حیاتی برای عملکرد باید در کامپایل اصلی گنجانده شوند.