App Size Optimization في تطوير التطبيقات المحمولة: الأساسيات والطرق والممارسات

ما هو App Size Optimization

App Size Optimization هو مجال في تطوير التطبيقات المحمولة يهدف إلى تقليل حجم حزمة تثبيت التطبيق. يشمل إزالة الكود والموارد الميتة، ضغط الصور، تحسين المكتبات، تجزئة البناء لمعماريات مختلفة واستخدام تقنيات التوصيل عند الطلب.

حجم التطبيق يؤثر بشكل غير متساوٍ على شرائح مختلفة من المستخدمين. في المناطق ذات البنية التحتية المتطورة للجوال (الولايات المتحدة، أوروبا، اليابان) قد يكون الفرق بين 50 و 100 ميغابايت غير ملحوظ. في المناطق النامية (الهند، إندونيسيا، البرازيل) كل ميغابايت إضافي يقلل من تحويل التثبيت بسبب حدود خطط البيانات وسرعة الإنترنت المحمول. Google Play يحدد حجم APK بـ 200 ميغابايت، لكنه يوصي بالحفاظ عليه أقل من 100 ميغابايت.

بالنسبة لمتجر تطبيقات iOS، الحد الأقصى لحجم التحميل عبر الشبكة الخلوية هو 200 ميغابايت (كان 150 ميغابايت قبل عام 2023). إذا تجاوز IPA هذا الحد، يمكن للمستخدم تثبيت التطبيق فقط عبر Wi-Fi. تدعم Apple أيضًا App Thinning، الذي يتضمن Slicing و Bitcode و On-Demand Resources — تقنيات تقلل تلقائيًا حجم التثبيت على جهاز معين دون تدخل المطور.

لماذا حجم التطبيق مهم

حجم التطبيق لا يؤثر فقط على تحويل التثبيت، بل أيضًا على الاحتفاظ بالمستخدمين، وتكرار التحديثات، وسرعة التشغيل الأولى. كل ميغابايت إضافي هو حاجز بين المستخدم واستخدام منتجك.

التأثير على تحويل التثبيت

وفقًا لبيانات Google I/O 2024، تقليل APK بمقدار 10 ميغابايت يزيد من تحويل التثبيت بمتوسط 3.5%. بالنسبة للتطبيقات التي يبلغ حجمها 150+ ميغابايت، يمكن أن يكون التحويل أقل بنسبة 20–30% مقارنة بالتطبيقات من نفس الفئة بحجم 50 ميغابايت. يكون التأثير واضحًا بشكل خاص في Google Play، حيث يرى المستخدم الحجم قبل التثبيت. في App Store، يظهر الحجم على صفحة التطبيق، والمستخدمون ذوو خطط البيانات المحدودة يؤجلون التثبيت إلى Wi-Fi، وبعد ذلك غالبًا ما ينسون التطبيق.

تكرار التحديثات والتحديث عبر الهواء

يتم تحديث التطبيقات الكبيرة عبر الهواء بشكل أقل — يؤجل المستخدمون تحميل التصحيحات إلى Wi-Fi، مما يفوتهم التصحيحات الأمنية الحرجة. يسمح Google Play باستخدام Incremental Updates (تصحيحات يصل حجمها إلى 10 ميغابايت)، لكن إعادة التثبيت الكاملة لا تزال تحمل APK أو AAB بالكامل. يستخدم متجر تطبيقات Apple تحديثات Delta، حيث ينقل فقط الملفات المُغيرة، ولكن حتى الفرق يمكن أن يكون كبيرًا عند تغيير الموارد.

التشغيل الأول وفك الضغط

يؤثر الحجم مباشرة على وقت التشغيل الأول: يجب على التطبيق فك ضغط الموارد، وتجميع الكود (Android) أو توقيع الذاكرة المخبأة (iOS). تطبيق بحجم 200 ميغابايت قد يبدأ تشغيله أبطأ بـ 10–15 ثانية من تطبيق بحجم 50 ميغابايت على جهاز متوسط. هذا يضعف تجربة الإعداد — قد يغلق المستخدم التطبيق دون انتظار تحميله.

تحسين الموارد والأصول

الموارد — الصور، الخطوط، الأصوات، الفيديو — تشكل 60–80% من حجم التطبيق المحمول النموذجي. يعطي تحسين الموارد أكبر ربح بأقل جهد. الاتجاهات الرئيسية هي: الضغط، إزالة التكرارات والأصول غير المستخدمة، اختيار التنسيقات الصحيحة.

تحسين الصور

WebP — تنسيق صور من Google يوفر ضغطًا أفضل بنسبة 25–35% من PNG و 15–20% أفضل من JPEG بنفس الجودة البصرية. يدعم Android WebP بشكل أصلي منذ API 18. بالنسبة لنظام iOS، يُدعم WebP عبر مكتبات SDWebImage أو Kingfisher، ومع iOS 17 ظهر الدعم الأصلي. AVIF — تنسيق أكثر حداثة يوفر توفيرًا إضافيًا بنسبة 10–15% مقارنة بـ WebP، لكن مع فك تشفير أبطأ.

إزالة الموارد غير المستخدمة — أبسط طريقة لتقليل الحجم. في Android، استخدم إعادة الهيكلة مع Android Studio: Analyze → Run Inspection → Unused Resources. في iOS — Build Settings → Remove Unused Resources. غالبًا ما تبقى في المشاريع صور من الإصدارات السابقة، أيقونات قديمة، صور شاشة بدء غير مستخدمة تضخم الحجم دون أي فائدة وظيفية.

تحسين الخطوط والأصوات

الخطوط المخصصة قد تشغل 5–15 ميغابايت، خاصة إذا تم تضمين مجموعة الخطوط بأكملها (جميع الأنماط: Regular, Bold, Italic, BoldItalic). استخدم فقط الأنماط الضرورية ومجموعات الأحرف الفرعية من خلال subsetting — إزالة الحروف الرسومية للغات غير المدعومة من التطبيق. تتيح خدمات مثل Google Fonts و Transfonter إنشاء مجموعة أحرف دنيا. للصوت، استخدم AAC/HE-AAC بدلاً من WAV والتنسيقات غير المضغوطة — توفير يصل إلى 90% دون فقدان الجودة.

تحسين الكود والمكتبات

الكود يشكل 20–40% من حجم التطبيق، لكن تحسينه أكثر تعقيدًا من الموارد لأنه يتطلب تحليل التبعيات، وإخفاء الكود، وإزالة الكود الميت دون خطر كسر الوظائف.

ProGuard و R8 لأندرويد

ProGuard — أداة لأندرويد تقوم بإخفاء الكود وتصغيره وتحسينه. R8 — خليفته، المدمج في Android Gradle Plugin، يعمل بشكل أسرع وأكثر كفاءة. يزيل R8 الفئات والطرق غير المستخدمة، ويختصر أسماء المتغيرات، ويعيد كتابة الكود لتقليل عدد التعليمات. التخفيض النموذجي لحجم ملفات DEX باستخدام R8 هو 30–50%.

// build.gradle — إعداد R8 للتصغير
android {
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile(
                'proguard-android-optimize.txt')
            shrinkResources true
        }
    }
}

تحسين المكتبات والتبعيات

المكتبات — سبب شائع للحجم المتضخم. قد تجلب مكتبة واحدة تبعيات غير مباشرة تزيد الحجم بمقدار 5–20 ميغابايت دون فائدة مباشرة للتطبيق. استخدم Gradle Version Catalog لأندرويد و Swift Package Manager لنظام iOS مع الإعلان الصريح عن التبعيات. حلل الحجم باستخدام Build Analyzer في Android Studio أو Xcode Build Timeline. استبدل المكتبات الثقيلة ببدائل أخف: على سبيل المثال، OkHttp (3 ميغابايت) بدلاً من Apache HTTP (15 ميغابايت).

إزالة الكود غير المستخدم في iOS

Dead Code Stripping — إزالة تلقائية للطرق والفئات غير المستخدمة في مرحلة الربط في Xcode. يتم التفعيل عبر Build Settings → Dead Code Stripping = YES. Bitcode — تمثيل وسيط يمكن لـ Apple إعادة ترجمته لمعماريات مختلفة، مع إزالة الوظائف غير المستخدمة. ومع ذلك، منذ Xcode 14، أصبح Bitcode اختياريًا، ومساهمته في تقليل الحجم هي 5–15% لمشاريع 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 هو 20–40%. 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 فقط عندما يحتاجها المستخدم فعليًا. يمكن تقليل حجم التثبيت الأولي بنسبة 50–80%. تنقسم الموارد إلى ثلاث فئات: Initial Install Tags (تُحمَّل أثناء التثبيت)، و Prefetched Tag Order (تُحمَّل في الخلفية بعد التثبيت)، و On-Demand (تُحمَّل فقط عند الطلب). توصي Apple باستخدام ODR لـ المحتوى غير المطلوب على الشاشة الأولى: مستويات اللعبة، محتوى إضافي، دروس فيديو.

SwiftUI يدعم ODR من خلال خاصية Bundle.module، بينما يستخدم UIKit NSBundleResourceRequest. للألعاب على Unity و Unreal Engine، يتم دمج ODR على مستوى الغلاف الأصلي. القيد الرئيسي هو أن موارد ODR تُحذف بواسطة النظام عند نقص المساحة، لذلك يجب تضمين البيانات الحرجة في البناء الرئيسي.