L'importance croissante de l'optimisation de la taille de l'application iOS

Chaque mégaoctet d'une application iOS a du poids au-delà de l'utilisation du disque. Une application gonflée a des répercussions sur les taux de conversion sur l'App Store, augmente le temps de lancement et peut pousser les utilisateurs à désinstaller lorsque le stockage des appareils fonctionne à faible. Apple a resserré la limite de téléchargement en direct à 200 Mo, et même avec l'App Thinning, le binaire non compressé influence toujours la perception du client.

Catalogues d'actifs : La Fondation de la gestion efficace des ressources

Les catalogues d'actifs sont la façon standard d'organiser des images, des icônes et d'autres ressources visuelles depuis Xcode 5. Ils fournissent un seul fichier structuré ([) que Xcode utilise pour générer une sortie optimisée pour chaque périphérique cible. Au lieu de diffuser des fichiers PNG libres dans votre projet, vous les regroupez dans un catalogue où chaque ensemble d'images peut contenir plusieurs variantes pour différentes échelles d'écran (1x, 2x, 3x), idiomes de périphérique (iPhone, iPad, Mac, TV) et instructions de rendu (modèle original, original).

Comment les catalogues d'actifs réduisent votre binaire

  • Sélection de résolution automatique – Seule l'image la plus haute résolution nécessaire pour un appareil est incluse dans le binaire final. Une application universelle fonctionnant sur un iPhone XR (2x) ne téléchargera pas la version 3x de la même image.
  • Le support des actifs des vecteurs – Les images vectoriels PDF ou SVG peuvent être utilisées comme actifs à résolution unique. Xcode les rastérise au moment de la construction à l'échelle requise, éliminant ainsi le besoin de plusieurs copies PNG.
  • Slice remove – Lorsque vous utilisez le slice de l'actif, vous pouvez supprimer des parties invisibles d'une image, réduisant la taille du fichier.
  • Stockage compact – Les catalogues d'actifs sont stockés dans un fichier () dans le paquet d'applications, qui utilise un format de compression propriétaire d'Apple plus efficace que le stockage de PNG individuels.

Pour maximiser ces avantages, chaque jeu d'images doit inclure uniquement les échelles nécessaires. Évitez d'inclure une image 1x si vous ciblez uniquement des appareils avec des écrans Retina ou Retina HD. De même, si votre application ne supporte pas iPad, vous pouvez omettre les variantes spécifiques à l'idiome.

Configuration des catalogues d'actifs pour la compression optimale

  1. Créer un catalogue d'actifs – Xcode génère automatiquement un dossier . Vous pouvez ajouter des catalogues supplémentaires pour les bibliothèques modulaires de composants.
  2. Utilisez l'inspecteur des attributs – Pour chaque jeu d'images, spécifiez le Gamut correct (sRGB ou Display P3) et la compression (automatique, sans perte ou perte). Pour les photographies, la compression perdue avec un réglage de qualité peut réduire considérablement la taille.
  3. Activer "Préserver les données vectorielles" – Pour les icônes universelles ou les éléments d'interface utilisateur qui s'échellent, conserver les données vectorielles PDF et laisser iOS raster au moment de l'exécution.
  4. Stallation de l'actif de levier[ – Pour les boutons et les images extensibles, définir les insets de la capsule et le slice de sorte que les zones de bord inutilisées soient éliminées.

Apples La documentation du catalogue Asset offre un guide exhaustif pour chaque option. Regardez également les sessions WWDC sur l'optimisation de la taille des applications pour les études de cas du monde réel.

Compression d'image : où la plupart des octets sont enregistrés

Les images représentent souvent 40 à 60 % de la taille totale d'une application. Même avec les catalogues d'actifs, les fichiers d'images bruts restent la cible principale de compression. Le choix du format et du flux de compression déterminent directement la taille finale de l'application.

Sélection du bon format d'image

  • HEIC (Conteneur de fichiers d'images à haute efficacité)[ – Format de présentation iOS qui offre environ 50% plus petite taille de fichier que JPEG avec une qualité comparable. Utilisez pour les photos et les couleurs riches. Xcode peut convertir PNGs en HEIC au moment de la construction si le périphérique cible le supporte (iOS 11+).
  • JPEG – Toujours approprié pour les images photographiques complexes. Utilisez le niveau de qualité 60-85% pour un bon compromis. Ne jamais utiliser 100% sauf si absolument nécessaire.
  • PNG – Meilleur pour les éléments d'interface utilisateur avec transparence, mais évitez d'utiliser PNG pour les photos. Optez pour PNG 8 bits (256 couleurs) pour des icônes simples plutôt que 24 bits.
  • WebP – Non pas nativement supporté sur iOS, mais les bibliothèques tierces peuvent le décoder. Peser le coût de la bibliothèque en fonction des économies d'espace.

Outils de compression pour intégrer votre flux de travail

La compression manuelle avant d'ajouter des catalogues d'actifs est une erreur courante. Automatisez plutôt le processus avec ces outils :

  • ImageOptim – Compression sans perte et sans perte pour PNG, JPEG et GIF. Il déforme les métadonnées et applique une quantification optimale. Exécutez-le sur l'ensemble de votre dossier d'actifs avant d'ajouter au catalogue.
  • TinyPNG / TinyJPG – Service Web qui utilise une compression intelligente et lossy pour PNG et JPEG. L'API peut être intégrée dans un script pré-construire.
  • SVGO (SVG Optimizer)[ – Pour les actifs vectoriels, supprimer les données de viewport inutiles, les groupes redondants et les ID inutilisés.
  • Apple outil en ligne de commande – Peut convertir des images en HEIC et ajuster les paramètres de compression directement à partir d'un script de phase de construction.

Pour une solution automatisée, créez une phase de script d'exécution dans Xcode qui compresse toutes les images nouvellement ajoutées en utilisant ImageOptim ou un script personnalisé. Plus de détails sur ImageOptim=s site officiel.

Utilisation du détartrage et du budget de résolution

Les concepteurs fournissent souvent des actifs à des résolutions excessives. Implémenter un budget de résolution: par exemple, la plus grande image d'un iPhone 15 Pro Max (1290 x 2796 pixels d'affichage) a 1290 points de large à 3x – soit 3870 pixels. Toute image plus large que ce qui est gaspillé. De même, envisager de réduire l'échantillonnage des images de fond en plein écran à la dimension maximale réelle nécessaire.

Au-delà des images : compression de code et d'actif

La taille de l'application comprend les binaires compilés, les cadres, les polices, les fichiers audio, vidéo et de données.

Optimisation de la taille du code

  • Activer le découplage de code mort – Paramètres de construction de Xcode : et . Cela supprime les fonctions et les méthodes qui ne sont jamais appelées.
  • Supprimer les cadres inutilisés – Source très courante de ballonnement. Utilisez ou Xcode=s pour trouver des bibliothèques statiques et des cadres liés mais jamais utilisés.
  • Swift Protocol and Generic Specialization – Le compilateur Swift génère du code pour chaque type de béton. Évitez l'utilisation générique extrême et préférez sur des fonctions rarement appelées pour empêcher la duplication de code.
  • Minimisez les catégories Objective-C et les modèles C++ – Les deux peuvent gonfler le binaire parce qu'ils peuvent être inactualisés à plusieurs reprises. Passez en revue votre utilisation.

Compresser les audio, les vidéos et les polices

  • Audio – Utilisez AAC (Advanced Audio Coding) au lieu de WAV ou AIFF. Pour de courts effets sonores, considérez Apple=S CAF format avec compression IMA4. Convertir à partir de sources à haut débit en utilisant .
  • Vidéo – HEVC (H.265) est supporté sur les appareils Apple A9 ou plus tard. Encodez tous les actifs vidéo en utilisant HEVC et accordez pour le streaming (non diffusé) pour réduire la taille du fichier. Si vous ciblez des appareils plus anciens, fournissez un retour H.264 mais limitez son débit.
  • Fonts – Utilisez les polices système lorsque possible. Pour les polices personnalisées, sous-ensemblez-les pour inclure uniquement les caractères que votre application utilise réellement. Des outils comme (à partir de fonttools) ou FontSquirrel="s web font generator peuvent produire des fichiers de police minimaux.
  • Fichier de données (JSON, PLIST, SQLite) – Supprimer l'espace blanc et les commentaires de JSON pendant la construction. Utilisez des listes binaires au lieu de XML. Compressez les bases de données SQLite avec et envisagez d'utiliser le mode WAL avec des pages plus petites.

Techniques avancées : App Thinning, Ressources sur demande et Bitcode

Apple , le service de finissage d'application crée automatiquement des paquets d'installation de variantes adaptés à chaque appareil. En tant que développeur, vous activez App Thinning en configurant le slice et le bitcode dans Xcode. Le résultat: les utilisateurs ne téléchargent que les ressources dont ils ont réellement besoin.

Sciure

Lorsque vous activez App Thinning dans Xcode, l'App Store génère plusieurs variantes de votre paquet d'applications :

  • Variante de périphérique – comprend uniquement les actifs du catalogue d'actifs pour l'idiome de périphérique (iPhone, iPad).
  • Variante GPU – si vous utilisez des shaders Metal ou OpenGL, seule la version appropriée est incluse.
  • Variante de résolution – seuls les facteurs d'échelle (2x ou 3x) sont présents.

Le scintillement fonctionne automatiquement lorsque votre catalogue d'actifs est configuré correctement avec toutes les variantes. Sans un catalogue correctement configuré, le scendage ne peut pas supprimer les ressources inutilisées. Assurez-vous que vous n'avez pas placé de fichiers d'images libres en dehors du catalogue d'actifs – ceux-ci ne sont jamais tranchés.

Ressources sur demande (ODR)

ODR vous permet d'héberger des niveaux de jeu, des images de tutoriels ou des audios rarement utilisés sur les serveurs Apple. Les utilisateurs téléchargent ces ressources sur le premier accès, puis iOS peut les purger lorsque le stockage est faible. Cela réduit considérablement la taille de l'installation initiale. Étiquetez vos actifs dans le catalogue d'actifs avec différentes balises (par exemple, "Level1", "Tutorial") et utilisez pour les demander. Les dépendances ODR peuvent également être automatiquement retirées du paquet d'applications principal lorsqu'elles sont étiquetées de façon appropriée.

Bitcode et sa pertinence

Bitcode est une représentation intermédiaire de votre application compilée. L'App Store peut ré-optimiser le binaire pour les architectures de processeur futures. L'activation du bitcode () ne réduit pas directement la taille de votre application, mais permet à Apple d'appliquer des optimisations non disponibles pour le développeur. Dans la pratique, le bitcode peut conduire à des variantes légèrement plus petites pour les nouvelles familles d'appareils. Cependant, à partir de Xcode 14, le bitcode n'est plus nécessaire pour les applications iOS, et certaines applications voient une augmentation de la taille binaire. Évaluer son impact sur votre projet avant de l'activer.

Mesure et surveillance de la taille de l'application

L'optimisation sans mesure conduit à la conjecture. Intégrer le suivi de la taille de l'application tôt et souvent.

Rapports Xcode et analyse des archives

  • Produit → Archive – Après avoir construit une archive, ouvrez la fenêtre Organisateur et sélectionnez votre build. Xcode affiche la taille totale non compressée et la taille de téléchargement.
  • Rapport de taille de l'application – Dans l'organisateur, cliquez sur «Exporter» et choisissez «Rapport de taille de l'application». Cela génère un CSV qui décompose la taille de chaque variante, y compris les balises ODR.
  • Lien Map File – Générer un fichier map en définissant . Ceci montre la taille de chaque fichier objet et symbole. Identifier les grands segments de code et les cadres.

Outils d'analyse de tiers

  • AppCode="S Size Inspector (JetBrains) – Fournit une ventilation de la taille visuelle par catégorie (images, code, ressources).
  • Mesure dans l'application – Utilisez pour enregistrer les répertoires de documents et de caches de votre application. Cela aide à détecter le bloat d'exécution à partir du contenu téléchargé.
  • Fastlane – Automatiser la génération d'archive et exécuter un script personnalisé qui analyse le rapport de taille. Échec de la construction si la taille dépasse un seuil.

Meilleures pratiques pour un flux de travail simplifié

Relier les techniques décrites ci-dessus en pipelines répétables. Voici une approche recommandée :

  1. Design handoff standards[ – Exiger des concepteurs qu'ils fournissent des actifs vectoriels (SVG ou PDF) à moins que raster ne soit inévitable.
  2. Pré-construire l'étape de compression – Utilisez une phase de script d'exécution pour compresser toutes les images entrantes avec ou .Cela peut être intégré avec TinyPNG=s developer API[ pour PNG/JPEG.
  3. Code audit chaque sprint – Examiner les cadres liés, supprimer les classes obsolètes et activer les optimisations du compilateur. Supprimer tout code de débogue seulement des builds de la version.
  4. Activer l'application Thinning et ODR – Utilisez l'ODR pour de gros contenus secondaires tels que des passe-partout, des tutoriels et des vidéos promotionnelles.
  5. – Dans votre pipeline CI, comparez la nouvelle taille de construction avec la précédente. Alertez l'équipe si le binaire non compressé dépasse un budget (par exemple, 50 Mo pour l'application de base).
  6. Test final centré sur l'utilisateur[ – Testez l'expérience de téléchargement sur un réseau lent (p. ex., throttling 3G) et sur un appareil avec seulement 16 Go de stockage. Mesurez le temps de l'écran au premier écran et la rétention de l'utilisateur.

Conclusion : Optimisation de la taille comme processus continu

Réduire la taille de l'application iOS n'est pas une tâche ponctuelle mais une discipline permanente qui touche chaque membre de l'équipe, du concepteur à l'ingénieur de backend. Les catalogues d'actifs fournissent la fondation structurelle, les techniques de compression réduisent les fichiers individuels, et l'application Thinning combinée avec les ressources On-Demand personnalise la livraison par appareil. En mesurant la taille régulièrement et en appliquant les budgets, vous empêchez le ballonnement de s'accumuler. Le paiement est tangible : téléchargements plus rapides, taux de conversion plus élevés et moins d'utilisateurs abandonnent votre application en raison de préoccupations de stockage.