Conseils aux développeurs Android pour réduire la taille du fichier APK

1) ProGuard

Un outil de réduction de code, comme ProGuard, réduira considérablement la taille du fichier APK. L'outil est disponible sur sourceforge. Notez qu'il est très important de tester à nouveau l'ensemble de l'application après l'application de ProGuard, car cela peut parfois modifier le comportement de l'application. Comme ProGuard remplace les symboles d'application, pour rendre le code difficile à lire, il est important que vous conserviez le mappage des symboles, afin que vous puissiez traduire une trace de pile vers les symboles d'origine si vous devez enquêter sur un plantage dans votre application.

2) Suppression des informations de débogage

Je vous recommande de supprimer toutes les fonctionnalités liées au débogage de l'application. L'application ne voit ni n'utilise généralement ces données, et le système d'exploitation Android n'en a pas besoin pour exécuter l'application. Par conséquent, les informations de débogage ne font que gaspiller de l'espace et doivent être supprimées.

Pour ce faire, toutes les fonctionnalités liées au débogage doivent être incluses dans des blocs conditionnels, comme ci-dessous :

 débogage final statique = faux ;
 si (débogage) {
 v(TAG, "Débogage …")
 }

Il est important que l'indicateur de débogage soit défini au moment de la compilation (c'est-à-dire déclaré comme statique final) pour que le compilateur puisse supprimer complètement toutes les fonctionnalités de débogage. Créer votre propre méthode de débogage comme celle illustrée ci-dessous n'est pas une bonne idée car l'appel à myDebugPrint() n'est pas entouré d'un bloc conditionnel, ce qui signifie que le compilateur doit conserver les informations sur myDebugPrint() dans la classe appelante.

 public void myDebugPrint()
si (débogage)
v(TAG, "Débogage …");
}
}
…
myDebugPrint()

3) Suppression des symboles de débogage des bibliothèques natives L'utilisation de symboles de débogage est logique si votre application est encore en développement et nécessite toujours un débogage. Mais si les symboles de débogage apparaissent toujours lorsque vous compilez une version de version et si vous souhaitez les supprimer, nous vous recommandons de supprimer les symboles de débogage des bibliothèques natives (fichiers .so). Cela se fait à l'aide de la commande arm-eabi-strip, à partir du NDK Android.

4) Formats multimédias recommandés Si votre application s'appuie fortement sur des images, de l'audio ou de la vidéo, vous pouvez également réduire la taille du fichier APK en utilisant certains formats multimédias. Nous vous recommandons d'utiliser les formats multimédias suivants pour les images, l'audio et la vidéo :

• Vidéo : Utilisez H264 AVC. Encodez la vidéo à une résolution ne dépassant pas la résolution d'écran de l'appareil cible (si connue).

• Audio : AAC Audio est recommandé pour toutes les ressources audio. AAC réalise une meilleure compression à une qualité donnée, par rapport au mp3 ou Ogg Vorbis. Les formats bruts tels que WAV ne doivent jamais être utilisés. La raison commune pour l'utilisation du format WAV est que le décodage des flux audio compressés signifie généralement une latence élevée lors de la lecture. Cependant, Android fournit l'API Sound Pool qui permet aux applications d'utiliser des flux audio compressés sans la pénalité d'une latence élevée.

• Images : PNG ou JPEG. Utilisez des PNG ; comme il s'agit d'un format sans perte, il convient parfaitement aux textures et aux illustrations car il n'y aura aucun artefact visuel dû à la compression. S'il y a des contraintes d'espace, utilisez des JPEG ou une combinaison de PNG et de JPEG. Une image JPEG de haute qualité peut fonctionner correctement pour les grandes images photoréalistes, pour lesquelles le schéma de compression JPEG est optimisé.

• Optimisez les tailles PNG sans perdre en qualité

Si vous utilisez le format PNG, la taille du fichier des images PNG peut être réduite sans perte de qualité. Pour cela, utilisez un outil comme OptiPNG ou PNGCrush. Les deux sont parfaits pour réduire la taille du fichier PNG tout en garantissant la qualité de l'image. PNGcrush est un programme open source qui itère sur les filtres PNG et les paramètres zlib (Deflate), comprime l'image à plusieurs reprises à l'aide de chaque configuration de paramètre et choisit la configuration qui produit la plus petite sortie compressée (IDAT). D'autre part, OptiPNG effectue les essais entièrement en mémoire et n'écrit que le fichier de sortie final sur le disque. De plus, il offre plusieurs préréglages d'optimisation à l'utilisateur.

5) Supprimer les ressources inutilisées Un autre groupe potentiel de gaspilleurs d'espace à considérer pour la suppression de votre fichier APK sont les ressources inutilisées dans votre répertoire res, telles que les mises en page inutilisées, les drawables et les couleurs. Pour détecter les ressources inutilisées de votre APK qui pourraient être supprimées, utilisez l'outil android-unused-resources. Android Unused Resources est une application Java qui analysera votre projet à la recherche de ressources inutilisées.

6) Éviter la duplication S'assurer que votre application n'a pas de fonctionnalités en double ou d'actifs en double est un moyen évident d'éviter d'avoir des fichiers inutiles dans votre APK. Il est important de comprendre quelles API Android vous utilisez et toutes les fonctionnalités fournies par chacune. Il se peut qu'une API Android fasse déjà le travail d'une autre API. Les actifs dupliqués (chaînes, bitmaps, etc.) sont également un gaspillage d'espace et peuvent être facilement évités. Dans une moindre mesure, le code dupliqué augmentera également inutilement la taille du binaire livré.

7) Réduisez le nombre de méthodes Les développeurs Avid Android ont longtemps été confrontés à un problème provoquant des maux de tête avec leurs applications. Le nombre de méthodes qu'une application peut avoir est limité. Eh bien, c'était limité. Enfin, les bonnes gens de Google ont fourni une solution en octobre dernier, mais c'était loin d'être idéal. Bien que très facile à mettre en œuvre, la solution multidex compliquait et allongeait considérablement le temps de compilation. Ne restant pas immobile, à commencer par Lollipop (Android 5.0), l'ensemble de la machine virtuelle Android a été révolutionné pour offrir une solution beaucoup plus supportable, du genre qui améliore même le temps de compilation habituel. Cependant, pour le moment, la solution Lollipop n'est pas non plus idéale. Cela oblige les développeurs à développer uniquement contre Lollipop, ce qui pourrait être problématique car la plupart des applications veulent être compatibles avec des publics plus larges et peuvent craindre d'utiliser des fonctionnalités qui ne sont pas disponibles dans les versions antérieures d'Android. Donc, pour le moment, la solution Lollipop est une bonne future solution Android, mais pourrait ne pas avoir beaucoup d'impact dans le présent prévisible. Alors que peut-on faire en attendant ? Nous convenons tous que vous ne devriez pas renoncer aux fonctionnalités et aux capacités, juste pour éviter d'atteindre la limite de 65K. Mais il ne fait aucun doute que la meilleure pratique serait toujours de réduire le nombre de méthodes d'application. Alors, comment pouvez-vous encore essayer de réduire le nombre de vos méthodes sans perdre cette petite étincelle qui rend votre application spéciale ?

Un bref aperçu : "D'où viennent toutes ces méthodes ?"

La limite du nombre de méthodes est d'environ 65 000 méthodes (65 536 pour être exact). Cela ressemble à un nombre énorme. Si vous êtes un développeur Android novice, vous pensez peut-être "comment tant d'applications peuvent-elles atteindre ce nombre si rapidement?" Vous auriez probablement un peu raison. Il n'est pas facile d'écrire autant de méthodes par soi-même. Mais les développeurs d'applications n'écrivent pas leur application entière par eux-mêmes. Les développeurs d'applications utilisent de plus en plus de bibliothèques tierces (SDK - Kits de développement logiciel), qui les aident à atteindre certains objectifs et fonctionnalités qu'ils devraient autrement développer entièrement par eux-mêmes. Des publicités aux améliorations de l'interface graphique en passant par les réseaux sociaux, les rapports de plantage et bien d'autres encore, les SDK offrent un large éventail de fonctionnalités et d'API qui permettent de gagner un temps de développement précieux et d'accélérer la diffusion de votre application. Mais chaque SDK ajoute à votre nombre de méthodes, et certains SDK font même plus que ce que vous avez négocié. Ce n'est pas nécessairement une mauvaise chose, bien sûr. Cependant, le coup de grâce est venu de Google lui-même. Leur kit Google Play Services est un grand SDK contenant plus de 28 000 méthodes. La limite étant de 65 000, ce nombre n'est pas exactement bas. Et de nombreux développeurs d'applications aimeraient utiliser ce SDK car il ouvre la porte au royaume magique de Google, une capacité très recherchée qui ajoute beaucoup de valeur à son application. Dans cet article, je n'expliquerai pas seulement comment utiliser de manière sélective les packages Google Play Services, mais je vous donnerai également des informations sur le nombre de méthodes que chacun de ces packages ajoute à votre application. Alors accrochez-vous à vos sièges, ça va être un parcours cahoteux.

Le terrain de jeu des services Google Play

Alors, combien de méthodes les services Google Play ajoutent-ils réellement ? Eh bien, comme pour tout dans la vie, c'est beaucoup plus compliqué qu'un simple chiffre. Mais allons-y une étape à la fois. Le SDK des services Google Play contient en fait 19 SDK différents. Avec Gradle, vous pouvez choisir de manière sélective ceux à utiliser. Tout ce que vous avez à faire est d'ajouter la dépendance suivante au fichier build.gradle de votre module d'application :

 dépendances {
compiler 'com.google.android.gms:play-services:7.5.0'
}

Avec 7.5.0 étant la dernière version GPS publiée à ce moment. Il est étiqueté comme révision 25 dans le gestionnaire de SDK Android. Afin de choisir des packages spécifiques, remplacez la ligne suivante par autant de lignes de dépendance que vous le souhaitez, en spécifiant des packages spécifiques. Supposons, par exemple, que vous ne vouliez que Google Plus, Google Games, Google Ads et Google Maps :

 dépendances {
compiler 'com.google.android.gms:play-services-plus:7.5.0'
compiler 'com.google.android.gms:play-services-games:7.5.0'
compiler 'com.google.android.gms:play-services-ads:7.5.0'
compiler 'com.google.android.gms:play-services-maps:7.5.0'
}

Pas trop difficile, mais voici la première prise. L'un des 19 SDK glorieux s'appelle play-services-base. Si vous incluez un package de service Google Play, il sera également automatiquement ajouté. Combien de méthodes le package de base contient-il ? Près de 8 000 (nombre exact ci-dessous).

Et voici la deuxième prise. Je n'ai pas inclus seulement 3 packages dans l'exemple ci-dessus. Je n'en ai même pas inclus 4, si vous comptez également le package de base. En fait, j'ai inclus 5 paquets. Pourquoi? Parce que le package Google Games utilise le package Google Drive, et donc cela a également été importé (en réalité, Google Ads inclut également un package appelé gestionnaire de balises, mais je ne compte ici que les packages "sélectionnables").

Alors maintenant, nous commençons à comprendre pourquoi il est un peu plus difficile de compter le nombre de méthodes que chaque package des services Google Play ajoute à notre application. Inclure un forfait ne signifie pas nécessairement exclure les autres.

Voici donc les détails - quels packages vous pouvez ajouter, combien de méthodes ils ajoutent et quels autres packages apportent-ils pour planter la fête. Les données se réfèrent à la dernière version des services Google Play (7.5.0 / révision 25) :

Nombre total de méthodes : 28 175. Certains de ces chiffres, vous devez l'admettre, sont vraiment atroces. Si tout ce que vous vouliez était le package panorama, vous ne pouvez pas vous contenter de neuf méthodes, vous devez en obtenir près de 8 000. Pas étonnant que tant d'applications se rapprochent ou dépassent cette limite de 65K.

Certains de ces chiffres peuvent sembler un peu incohérents si vous essayez de les additionner. C'est parce que, encore une fois, la logique derrière les services Google Play est un peu plus délicate qu'il n'y paraît. Par exemple, Google Analytics inclut une seule méthode de Google Ads afin d'obtenir l'identifiant publicitaire du compte.

Notez que lorsque vous calculez combien chaque package ajoute à votre application, assurez-vous d'exclure les doubles (par exemple, ne comptez pas le package de base plus d'une fois).

Vous ne pouvez pas tout ajouter de manière sélective

Et voici la piqûre finale. Il existe deux petits packages dans les services Google Play qui ne peuvent pas être ajoutés de manière sélective. Le package de recherche (vous donnant accès à l'API Google Now) ne comprend que 22 méthodes. Si vous souhaitez l'utiliser, vous n'avez pas d'autre choix que d'ajouter l'ensemble des 28 000 méthodes, l'ensemble des services Google Play. Espérons que cela sera corrigé dans les versions ultérieures.

(Un autre package "inaccessible" est le package appstate qui comprend 111 méthodes, mais il est désormais obsolète au profit de SavedGames , inclus dans le package google-play-games).