App Size Optimization dans le développement mobile : fondamentaux, méthodes et pratiques

Qu'est-ce qu'App Size Optimization

App Size Optimization est une discipline du développement mobile visant à minimiser la taille du paquet d'installation de l'application. Cela comprend la suppression du code mort et des ressources, la compression des images, l'optimisation des bibliothèques, la fragmentation de la compilation pour différentes architectures et l'utilisation de technologies de livraison à la demande.

La taille de l'application affecte inégalement différents segments d'utilisateurs. Dans les régions avec une infrastructure mobile développée (États-Unis, Europe, Japon), la différence entre 50 et 100 Mo peut être imperceptible. Dans les régions en développement (Inde, Indonésie, Brésil), chaque mégaoctet supplémentaire réduit le taux de conversion des installations en raison des limites des forfaits de données et de la vitesse de l'internet mobile. Google Play limite la taille de l'APK à 200 Mo, mais recommande de la maintenir en dessous de 100 Mo.

Pour l'App Store d'iOS, la taille maximale de téléchargement sur le réseau cellulaire est de 200 Mo (elle était de 150 Mo avant 2023). Si l'IPA dépasse cette limite, l'utilisateur ne peut installer l'application que via Wi-Fi. Apple prend également en charge App Thinning, qui inclut Slicing, Bitcode et On-Demand Resources — des technologies qui réduisent automatiquement la taille de l'installation sur un appareil spécifique sans intervention du développeur.

Pourquoi la taille de l'application est cruciale

La taille de l'application affecte non seulement le taux de conversion des installations, mais aussi la rétention, la fréquence des mises à jour et la vitesse du premier lancement. Chaque mégaoctet supplémentaire constitue une barrière entre l'utilisateur et l'utilisation de votre produit.

Impact sur le taux de conversion des installations

Selon les données de Google I/O 2024, réduire l'APK de 10 Mo augmente le taux de conversion des installations de 3,5 % en moyenne. Pour les applications de 150+ Mo, le taux de conversion peut être de 20–30% inférieur à celui d'applications de la même classe de 50 Mo. L'effet est particulièrement marqué sur Google Play, où l'utilisateur voit la taille avant l'installation. Dans l'App Store, la taille est affichée sur la page de l'application, et les utilisateurs avec des forfaits de données limités reportent l'installation sur Wi-Fi, après quoi ils oublient souvent l'application.

Fréquence des mises à jour et mises à jour over-the-air

Les grandes applications sont mises à jour over-the-air moins fréquemment — les utilisateurs reportent le téléchargement des correctifs sur Wi-Fi, manquant ainsi des correctifs de sécurité critiques. Google Play permet les Incremental Updates (correctifs jusqu'à 10 Mo), mais une réinstallation complète télécharge toujours l'APK ou l'AAB complet. L'App Store d'Apple utilise les Delta Updates, ne transférant que les fichiers modifiés, mais même le delta peut être significatif lorsque les ressources changent.

Premier lancement et décompression

La taille affecte directement le temps du premier lancement : l'application doit décompresser les ressources, compiler le code (Android) ou signer le cache (iOS). Une application de 200 Mo peut démarrer 10–15 secondes plus lentement qu'une application de 50 Mo sur un appareil moyen. Cela détériore l'Expérience d'intégration — l'utilisateur peut fermer l'application sans attendre le chargement.

Optimisation des ressources et assets

Les ressources — images, polices, sons, vidéos — constituent 60–80% de la taille d'une application mobile typique. L'optimisation des ressources offre le plus grand gain avec un minimum d'effort. Les principales directions sont : la compression, la suppression des doublons et des assets inutilisés, le choix des bons formats.

Optimisation des images

WebP — un format d'image de Google offrant une compression 25–35% meilleure que le PNG et 15–20% meilleure que le JPEG à qualité visuelle égale. Android prend en charge WebP nativement depuis l'API 18. Pour iOS, WebP est pris en charge via les bibliothèques SDWebImage ou Kingfisher, et avec iOS 17, un support natif est apparu. AVIF — un format plus moderne offrant une économie supplémentaire de 10–15% par rapport au WebP, mais avec un décodage plus lent.

Suppression des ressources inutilisées — le moyen le plus simple de réduire la taille. Sous Android, utilisez le refactoring avec Android Studio : Analyze → Run Inspection → Unused Resources. Sous iOS — Build Settings → Remove Unused Resources. Souvent, les projets conservent des sprites de versions antérieures, des icônes obsolètes, des images d'écran de démarrage inutilisées qui gonflent la taille sans aucune charge fonctionnelle.

Optimisation des polices et des sons

Les polices personnalisées peuvent occuper 5–15 Mo, surtout si la police entière est incluse (tous les styles : Regular, Bold, Italic, BoldItalic). Utilisez uniquement les styles nécessaires et les sous-ensembles de caractères via le subsetting — suppression des glyphes pour les langues non supportées par l'application. Des services comme Google Fonts et Transfonter permettent de créer un ensemble de caractères minimal. Pour l'audio, utilisez AAC/HE-AAC au lieu du WAV et des formats non compressés — économie jusqu'à 90% sans perte de qualité.

Optimisation du code et des bibliothèques

Le code constitue 20–40% de la taille de l'application, mais son optimisation est plus complexe que celle des ressources car elle nécessite une analyse des dépendances, de l'obfuscation et la suppression du code mort sans risque de casser les fonctionnalités.

ProGuard et R8 pour Android

ProGuard est un outil pour Android qui effectue l'obfuscation, la minification et l'optimisation du code. R8 — son successeur, intégré dans Android Gradle Plugin, fonctionne plus rapidement et plus efficacement. R8 supprime les classes et méthodes inutilisées, raccourcit les noms de variables et réécrit le code pour réduire le nombre d'instructions. La réduction typique de la taille des fichiers DEX avec R8 est de 30–50%.

// build.gradle — configuration de R8 pour la minification
android {
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile(
                'proguard-android-optimize.txt')
            shrinkResources true
        }
    }
}

Optimisation des bibliothèques et dépendances

Les bibliothèques — une cause fréquente de taille gonflée. Une bibliothèque peut entraîner des dépendances transitives qui augmentent la taille de 5–20 Mo sans bénéfice direct pour l'application. Utilisez Gradle Version Catalog pour Android et Swift Package Manager pour iOS avec une déclaration explicite des dépendances. Analysez la taille avec l'Analyseur de compilation dans Android Studio ou la Xcode Build Timeline. Remplacez les bibliothèques lourdes par des alternatives plus légères : par exemple, OkHttp (3 Mo) au lieu d'Apache HTTP (15 Mo).

Suppression du code inutilisé dans iOS

Dead Code Stripping — suppression automatique des méthodes et classes inutilisées lors de l'étape de liaison dans Xcode. Activé via Build Settings → Dead Code Stripping = YES. Bitcode — une représentation intermédiaire qu'Apple peut recompiler pour différentes architectures, supprimant les fonctions inutilisées. Cependant, depuis Xcode 14, Bitcode est devenu optionnel, et sa contribution à la réduction de taille est de 5–15% pour les projets Objective-C et moindre pour Swift.

App Thinning et livraison à la demande

App Thinning — la technologie d'Apple qui réduit automatiquement la taille de l'application installée en ne fournissant que les ressources nécessaires à un appareil spécifique. Elle se compose de trois composants : Slicing, On-Demand Resources et Bitcode. Sous Android, l'équivalent est l'Android App Bundle (AAB) avec Dynamic Delivery.

Android App Bundle (AAB)

AAB — un format de publication sur Google Play où le magasin génère des APK pour chaque appareil séparément, n'incluant que les ressources pour son architecture (armeabi-v7a, arm64-v8a), sa densité d'écran (mdpi, hdpi, xhdpi, xxhdpi, xxxhdpi) et ses langues. La réduction typique de la taille d'installation lors du passage d'un APK universel à l'AAB est de 20–40%. Play Feature Delivery permet de charger des modules à la demande, tandis que les modules Install-time sont inclus dans l'installation de base.

// build.gradle — configuration de l'AAB et des Dynamic Features
android {
    bundle {
        language {
            enableSplit = true
        }
        density {
            enableSplit = true
        }
        abi {
            enableSplit = true
        }
    }
}

On-Demand Resources dans iOS

On-Demand Resources (ODR) — un mécanisme iOS où les ressources (niveaux de jeu, images haute résolution, vidéos) sont téléchargées depuis les serveurs d'Apple uniquement lorsque l'utilisateur en a réellement besoin. La taille de l'installation initiale peut être réduite de 50–80%. Les ressources sont divisées en trois catégories : Initial Install Tags (téléchargées lors de l'installation), Prefetched Tag Order (téléchargées en arrière-plan après l'installation) et On-Demand (téléchargées uniquement sur demande). Apple recommande d'utiliser ODR pour le contenu qui n'est pas nécessaire sur le premier écran : niveaux de jeu, contenu supplémentaire, tutoriels vidéo.

SwiftUI prend en charge ODR via l'attribut Bundle.module, tandis qu'UIKit utilise NSBundleResourceRequest. Pour les jeux sur Unity et Unreal Engine, ODR est intégré au niveau du wrapper natif. La principale limitation est que les ressources ODR sont supprimées par le système lorsque l'espace est insuffisant, donc les données critiques doivent être incluses dans la compilation principale.