.
Un de mes ajouts récents préférés à Android Studio est l’analyseur APK, que vous pouvez trouver dans le menu supérieur sous Build → Analyze APK.
APK Analyzer vous permet d’ouvrir et d’inspecter le contenu de n’importe quel fichier APK que vous avez sur votre ordinateur, qu’il soit construit à partir de votre projet Android Studio local ou acquis à partir de votre serveur de construction ou d’un autre référentiel d’artefacts. Il n’a pas besoin d’être construit à partir d’un projet que vous avez ouvert dans Android Studio et vous n’avez pas besoin du code source de cet APK particulier.
Note : APK Analyzer fonctionne mieux avec les builds de version. Si vous devez analyser une build de débogage de votre application, assurez-vous que vous utilisez un APK qui n’est pas instrumenté pour Instant Run. Pour l’obtenir, vous pouvez utiliser la commande Build → Build APK. Vous pouvez voir si vous avez ouvert un APK instrumenté pour Instant Run en vérifiant la présence d’un fichier instant-run.zip à l’intérieur de l’archive.
L’utilisation de l’analyseur APK est un excellent moyen de fouiller dans les fichiers APK et d’en apprendre plus sur leur structure, de vérifier le contenu des fichiers avant de les publier ou de déboguer certains problèmes courants, notamment la taille des APK et les problèmes DEX.
L’analyseur APK peut vous donner beaucoup d’informations utiles et exploitables sur la taille des apps. En haut de l’écran, vous pouvez voir la taille brute du fichier qui est juste la taille de l’APK sur le disque. La taille du téléchargement montre une estimation de la quantité de données qui sera utilisée pour télécharger votre app en tenant compte de la compression appliquée par le Play Store.
La liste des fichiers et des dossiers est triée par taille totale en ordre décroissant. Cela en fait un outil idéal pour identifier les fruits mûrs de l’optimisation de la taille des APK. Chaque fois que vous approfondissez un dossier, vous pouvez voir les ressources et autres entités qui prennent le plus d’espace dans votre APK.
Dans cet exemple, lors de l’examen d’un APK pour des réductions de taille possibles, j’ai pu immédiatement remarquer qu’une animation PNG à 3 images est la plus grande chose dans nos ressources exploitables, pesant 1.5MB, et c’est juste pour la densité xxhdpi!
Puisque ces images ressemblent à des candidats parfaits pour le stockage en tant que vecteurs, nous avons trouvé les fichiers sources pour le travail artistique et les avons importés en tant que VectorDrawables en utilisant le nouveau support PSD dans l’outil d’importation Vector Asset dans Android Studio 2.2.
En passant par le même processus pour l’autre animation restante (instruction_touch_*.png) et en supprimant ces fichiers PNG à travers toutes les densités, nous avons été en mesure d’économiser plus de 5MB. Pour maintenir la rétrocompatibilité, nous avons utilisé VectorDrawableCompat de la bibliothèque de support.
En regardant les autres dossiers de ressources, il était facile de repérer quelques fichiers WAV non compressés qui pouvaient être convertis en OGG, ce qui signifiait encore plus d’économies sans toucher une ligne de code.
Suivant sur la liste des choses à vérifier était le dossier lib/, qui contient des bibliothèques natives pour les trois ABI que nous supportons.
La décision a été prise d’utiliser le support des splits APK dans notre build Gradle pour créer des versions séparées de l’application pour chaque ABI.
J’ai rapidement regardé le AndroidManifest.xml suivant et j’ai remarqué que <application> manque l’attribut android:extractNativeLibs. La définition de cet attribut à false peut permettre d’économiser de l’espace sur l’appareil car il empêche de copier les bibliothèques natives de l’APK vers le système de fichiers. La seule exigence est que les fichiers soient alignés par page et stockés non compressés à l’intérieur de l’APK, ce qui est pris en charge par le nouveau packager du plugin Android Gradle version 2.2.0+.
Après avoir effectué ces modifications, j’étais curieux de voir comment la nouvelle version de l’application se compare à la précédente. Pour ce faire, j’ai extrait la source du commit git avec lequel j’ai commencé, j’ai compilé l’APK et l’ai enregistré dans un autre dossier. J’ai ensuite utilisé la fonction Comparer avec… pour voir une répartition des différences de taille entre l’ancienne et la nouvelle build.
Nous avons fait beaucoup de progrès sur les ressources et les bibliothèques natives, économisant un total de 17MB avec très peu de changements dans l’application. Cependant, je peux voir que la taille de notre DEX a régressé, avec les classes2.dex augmentant de 400KB.
Débogage des problèmes DEX
Dans ce cas, la différence est venue de la mise à niveau de nos dépendances vers des versions plus récentes et de l’ajout de nouvelles bibliothèques. Proguard et Multidex étaient déjà activés pour nos builds, donc il n’y a pas grand-chose à faire sur notre taille DEX. Malgré tout, APK analyzer est un excellent outil pour déboguer tout problème avec cette configuration, surtout lorsque vous activez Multidex ou Proguard pour votre projet pour la première fois.
Lorsque vous cliquez sur n’importe quel fichier DEX, vous verrez un résumé du nombre de classes et de méthodes qu’il définit, et du nombre total de références qu’il contient (ce sont les références qui comptent dans la limite de 64K dans un seul fichier DEX). Dans cette capture d’écran d’exemple, l’application est sur le point d’atteindre la limite, ce qui signifie qu’elle aura besoin de MultiDex pour diviser les classes dans des fichiers séparés dans un avenir proche.
Vous pouvez creuser dans les paquets pour voir lesquels utilisent toutes les références. Dans ce cas, nous pouvons voir que la bibliothèque Support et les services Google Play sont les principales causes de cette situation :
Une fois que vous aurez activé MultiDex et compilé votre application, vous remarquerez un deuxième fichier classes2.dex (et éventuellement classes3.dex, et ainsi de suite). La solution MultiDex du plugin Android gradle détermine quelles classes sont nécessaires pour démarrer votre application et les place dans le fichier primaire classes.dex, mais dans les rares cas où cela ne fonctionne pas et que vous obtenez une ClassNotFoundException, vous pouvez utiliser APK Analyzer pour inspecter les fichiers DEX, puis forcer les classes manquantes à être placées dans le fichier DEX primaire.
Vous rencontrerez des problèmes similaires en activant Proguard et en utilisant des classes ou des méthodes par réflexion ou à partir de dispositions XML. L’APK Analyzer peut vous aider à vérifier que votre configuration Proguard est correcte, en vous permettant de vérifier facilement si les méthodes et les classes dont vous avez besoin sont présentes dans l’APK et si elles sont renommées (obfusquées). Vous pouvez également vous assurer que les classes que vous voulez voir disparaître sont effectivement supprimées et ne prennent pas votre précieux compte de méthodes de référence.
Nous sommes curieux d’entendre quelles autres utilisations vous trouvez pour l’APK Analyzer et quelles autres fonctionnalités vous aimeriez voir intégrées dans l’outil !
.