Publié par
Il y a 12 mois · 10 minutes · iOS, Mobile

Optimiser le poids de son application iOS

optimiser poids applications IOSLorsque nous développons une application, nous mettons naturellement l’accent sur la qualité du code. Néanmoins, il est également important d’apporter une attention toute particulière au poids de celle-ci, surtout au moment de la fameuse soumission aux stores pour les raisons suivantes :

  1. une application qui dépasse les 100Mo ne pourra être téléchargée que par le biais d’un réseau WiFi (c’est également le cas pour une mise à jour). Donc un utilisateur loin de chez lui, sur son réseau cellulaire, devra attendre de trouver un réseau WiFi, au risque d’abandonner le téléchargement de l’application ;
  2. même sur un réseau WiFi qui pourrait être un peu lent, si le téléchargement pèse plusieurs centaines de mégas, l’utilisateur devra patienter de longues secondes (ou minutes) avant de pouvoir profiter de votre application, et là encore c’est un risque de perdre un client / utilisateur potentiel ;
  3. avec une application en-dessous des 100Mo, il est quand même intéressant de chercher à optimiser au maximum son poids car l’utilisateur consommera son forfait data et peut être dans des conditions très dégradées (3G faible ou Edge) ce qui augmentera d’autant plus son temps d’attente ;
  4. enfin, gardez en tête que l’iPhone est toujours proposé dans sa version 16Go… autant vous dire que ses utilisateurs seront très regardants quant aux poids des applications installées.

Nous allons donc voir ensemble quelles solutions s’offrent à nous pour donner une petite cure minceur à notre application.

Disséquer un .ipa

Première chose pour bien comprendre la suite de l’article, nous allons voir ensemble comment se décompose notre fichier ipa qui contient toute l’application.

Ce fichier n’est rien d’autre qu’une archive compressée. Renommez-la en .zip et vous pourrez décompresser tout son contenu. Nous y trouvons alors un certain nombre de dossiers, mais un nous intéresse tout particulièrement : /Payload. C’est ici que se trouve le coeur de votre application. Vous y trouverez un seul fichier : MonAppli.app.

Pour parcourir son contenu, faites clic-droit > Afficher le contenu du paquet.

Vous allez y trouver des fichiers .png, .plist, .strings, .nib, .otf…

Premier réflexe : trier les fichiers par taille. Le plus volumineux sera sûrement le Assets.car. Toutes vos images se trouvent dedans. Nous avons donc ici un premier indicateur : le poids de ce fichier vous donne, en gros, la taille de vos images et, à partir de iOS 9, des ressources statiques.

Si vous souhaitez en voir le contenu (qui est l’équivalent du Assets.xcassets de votre projet Xcode), vous pouvez décompiler cette archive au moyen d’un petit outil à exécuter en ligne de commande nommé cartool.

Quelques manipulations sont nécessaires :

  1. ouvrez le projet cartool dans Xcode ;
  2. compilez ;
  3. dans le dossier /Products, récupérez le fichier cartool (clic droit > Show in Finder) ;
  4. dans Terminal, exécutez : ./cartool {source}/Payload/Assets.car {target}

A la racine du /Payload, vous trouverez également des images. Il s’agit :

  • des images des SDK tierces ;
  • des app icons ;
  • des launch images (splash screens) ;
  • des jpg.

Pour les deux premiers, pas grand chose à faire, et ça ne devrait pas être très lourd. Pour les launch images, attention il s’agit de grands formats (notamment pour les @3x et iPad @2x), elles peuvent dépasser les 2 voire 3Mo.

Enfin, si vous avez des jpg dans vos assets, vous ne devriez pas : convertissez-les en png comme le préconise Apple.

Toujours à la racine du /Payload, vous trouverez aussi :

  • les polices ;
  • tous les nib (équivalent xib) ;
  • et d’autres fichiers, tels que les .strings, .plist, etc.

Voilà pour ce qui pèsera le plus dans le poids de votre application. Tout le reste se compose de code, frameworks, SDK tierces, etc.

Dernier point : si vous avez une target Watch, un dossier /Watch avec un .app associé est également présent et s’apparente au .app de l’application iPhone/iPad (même structure).

Optimiser le poids des images

Si vous avez besoin de réduire le poids de votre application, la première étape indispensable est d’optimiser le poids des images. Sachez qu’un png exporté depuis Photoshop est généralement très lourd et peut très largement être optimisé.

Nous ne parlons pas ici d’une perte de qualité ou de compression comme nous pouvons le faire avec un jpg, car le png est un format non compressé. Non, rien de tout ça, mais néanmoins une optimisation est possible grâce à des petits outils. Il en existe de toute sorte sur la toile, prenons par exemple tiny png. Un simple drag & drop d’un png sur la home vous montrera le gain important que peut apporter cet outil : en moyenne, nous avons constaté une réduction de 60% du poids des png. Multipliez ça par l’ensemble des déclinaisons retina / iPhone / iPad, et vous devriez réduire votre application de plusieurs mégas. A noter que l’éditeur de cet outil propose aussi un plugin Photoshop et une API payante, un bon moyen d’automatiser ce processus d’optimisation.

Attention aux SDK tierces

Impossible de faire autrement : vous allez importer un certain nombre de SDK tiers au sein de votre application. Pensez à jeter un œil à leur poids respectif, certains pourraient peser plusieurs mégas. Reste à savoir ensuite si vous en avez réellement besoin : peut-être que pour certains vous n’utilisez qu’1% de leurs fonctionnalités, ou que plusieurs d’entre eux font le même travail et qu’il est possible de capitaliser sur un seul SDK.

Pensez également à sensibiliser votre client à ce sujet car il pourrait vous demander d’intégrer plusieurs solutions marketing par exemple (A/B Testing, analytics, push, alertings…), ce qui augmentera d’autant plus le poids de votre application mais aussi sa complexité.

Surveillez le poids de vos typos

Moins évident que les images et SDK, les polices de caractères peuvent également avoir une part importante dans le poids de votre application. La plupart d’entre elles, et notamment pour les plus courantes, ne devraient pas peser trop lourd dans la balance… mais certaines d’autres peuvent intégrer de nombreuses plages de caractères inutilisées, notamment les alphabets arabes, cyrilliques et caractères chinois, coréens et japonais. Si c’est le cas, une typo peut peser plusieurs mégas, voire atteindre les 20 Mo ! Il faudrait alors envisager d’utiliser une autre police de caractères, surtout si son usage est très limité au sein de l’application.

Bien construire son catalogue d’assets est une garantie pour l’App Slicing

apple-ios-app-slicingVous en avez sûrement entendu parlé, l’App Slicing est disponible depuis peu et permet de réduire drastiquement le poids d’une application. Le principe est simple : faire télécharger à l’utilisateur uniquement le contenu adapté à son device.

Par exemple, dans le cas d’une application universelle iPhone / iPad, l’installation de celle-ci sur un iPhone 6 Plus n’embarquera que les assets de type iPhone en @3x. C’est justement ce que propose l’App Slicing : diviser une application en plusieurs « petites » archives adaptées pour chaque device, en tenant compte de la plate forme et de la résolution de l’écran.

Cette étape est totalement transparente pour le développeur, mais néanmoins elle exige que le catalogue d’assets soit construit correctement, en indiquant pour chaque asset sa déclinaison dans tous les types de devices.

Seul inconvénient : cette fonctionnalité n’est disponible que depuis iOS 9.

Plus d’informations sur la documentation officielle Apple de l’App Slicing.

Pensez au téléchargement des images à la volée…

Une autre solution consiste à télécharger les visuels les plus lourds au moment où l’utilisateur doit les afficher plutôt que de les embarquer dans l’archive et donc dans l’installation. Si votre application est très fournie en illustrations (par exemple des images de fonds), vous pouvez penser à les mettre à disposition sur un serveur et les télécharger qu’une fois l’écran affiché. Trois avantages à cela :

  • vous réduisez le poids de l’installation ;
  • vous avez la main sur ces visuels si vous souhaitez les mettre à jour sans mettre à disposition une nouvelle version ;
  • ces images n’étant pas stockées, elles n’encombreront pas l’espace de stockage du device.

Par contre, du côté des points négatifs, ceci implique que l’utilisateur soit connecté (le visuel en question ne doit donc pas être indispensable à la bonne compréhension du contenu dans le cas d’absence de réseau) et vous allez donc lui faire consommer son forfait data si il est sur son réseau cellulaire.

Un compromis intéressant : télécharger les images et les écrire dans l’espace de stockage du device pour éviter de solliciter le réseau à chaque lancement de l’application.

…ou « On-Demand » !

Enfin, Apple propose depuis iOS 9 une solution nommée « On-Demand Resources ». Le concept est le suivant : proposer plusieurs ensembles d’assets qui ne seront téléchargés que lorsque l’utilisateur en aura besoin (pas que des images, mais tout autre fichier non exécutable). C’est semblable au point précédent à la différence près que c’est Apple qui stockera les assets pour vous sur ses serveurs (leur poids total est donc limité).

Un point intéressant est que cette fonctionnalité propose trois grandes catégories de ressources « On-Demand » :

  • les ressources à télécharger en même temps que l’application, donc lors de l’installation ;
  • les ressources à télécharger après installation de l’application ;
  • les ressources à télécharger qu’à la demande, lorsque l’application doit les utiliser / afficher.

apple-ios-on-demand-resourcesNous sommes ici dans un cas très particulier, qui ne conviendra pas à tous types d’applications. D’ailleurs, dans sa documentation Apple prend l’exemple d’un jeu où le développeur crée des groupes d’assets par niveau. Nous pouvons aussi imaginer cette solution dans le cas d’un catalogue produits.

Mais attention : à la différence de l’App Slicing, la mise en place de cette solution est assez coûteuse en temps de développement ; vous aurez en effet beaucoup de code à écrire et, qui plus est, sera compatible uniquement à partir d’iOS 9. Là où l’App Slicing peut être considéré comme un « bonus » pour les utilisateurs sous iOS 9 (et donc n’entre pas en conflit avec les OS précédents), le « On-Demand Resources » impose iOS 9.

Si vous souhaitez (et surtout pouvez !) vous lancer dans cette solution, la documentation Apple est très bien fournie sur le « On-Demand Ressources ».

Conclusion

A présent que nous venons de passer en revue les différentes solutions d’optimisations, il convient de choisir la (ou les) bonne(s).

La première qui consiste à optimiser les images est une étape indispensable et sera bien souvent suffisante. Un bon début en somme !

Ensuite, si ce n’est pas suffisant, pour les autres voies il faudra prendre en compte plusieurs aspects : l’OS minimum supporté, le rapport gain / coût de mise en place de la solution et le bon équilibre entre poids du téléchargement initial et consommation data au cours de l’utilisation de l’application.

N’oubliez pas d’évaluer constamment le poids de votre application, si besoin à l’aide de votre usine logicielle, et de ne pas oublier les conséquences sur les temps de téléchargements de vos utilisateurs ainsi que leur capacité de stockage.

Florent Capon
Je suis consultant iOS et je développe en Objective-C / Swift depuis 2012. Je suis dans le monde du Web et passionné depuis le début des années 2000, où j'ai notamment pu toucher à de nombreuses technos back & front comme le HTML, PHP, MySQL, ActionScript. Aujourd'hui, ma passion est clairement tournée vers le mobile et notamment iOS. Fort de mes 6 années passées à développer des sites en Flash, j'aime apporter un soin particulier à l'animation et à la réalisation des applications sur lesquelles je travaille.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *