APK Analyzer
В Android Studio 2.2 появилась новая утилита APK Analyzer, позволяющая просмотреть важную информацию о составе файлов внутри сборки приложения — ресурсы, манифест, количество методов в классах (приложение не может превышать лимит 64k).
Чтобы посмотреть внутренности apk-файла, откройте меню Build | Analyze APK и затем выберите нужный файл. Можно поступить ещё проще. Просто перетащите файл в окно редактора студии и утилита запустится сама.
Таким образом вы можете просматривать не только собственные файлы, но и другие.
APK Analyzer предназначена для работы с release-версиями APK. Если вам нужно проанализировать debug-версию вашего приложения, убедитесь, что вы используете APK, который не предназначен для Instant run (можно узнать, что APK для Instant Run, проверив наличие в архиве файла instant-run.zip).
Утилита показывает размеры файлов, которые входят в сборку приложения. Причём, показывается полный размер в несжатом виде и сжатый размер.
Если приложение содержит несколько файлов AndroidManifest.xml (варианты сборки, другие библиотеки), то в финальной версии они объединяются в один файл. И утилита позволяет просмотреть итоговый вариант. И даже показать предупреждения или ошибки.
Выше уже упоминалось, что вы можете просматривать ресурсы — картинки, текст и др.
Другая полезная возможность — просмотр названий пакетов, классов, методов. Заодно вы сразу видите, сколько методов содержится в пакете или в классе.
Наконец, ещё одна функциональность утилиты — сравнение двух apk-файлов. Для этой цели служит кнопка Compare with. в верхней части окна.
Вы увидите разницу между двумя вариантами финальной и отладочных версий приложения.
Источник
Перевод — Максимальное использование APK Analyzer
Одним из моих любимых последних дополнений к Android Studio является APK Analyzer, который вы можете найти в главном меню в разделе «Сборка → Анализ APK».
Полезный совет: можно просто перетаскивать APK-файлы в редактор, чтобы открыть их
APK Analyzer позволяет вам открывать и проверять содержимое любого APK файла, который у вас есть на компьютере, который может быть создан из вашего проекта в Android Studio, либо получен с сервера сборки или другого хранилища. APK-файл не обязательно собирать (Build → Build APK) перед этим, и вам не нужен исходный код для этого APK.
Примечание. APK Analyzer лучше всего работает с release-версиями APK. Если вам нужно проанализировать debug-версию вашего приложения, убедитесь, что вы используете APK, который не предназначен для Instant run. Чтобы получить этот APK, соберите APK Build → Build APK. А еще можно узнать, открыли ли вы APK Instant Run, проверив наличие в архиве файла instant-run.zip.
Использование APK Analyzer — отличный способ обзора APK файла и узнать об его структуре, проверить содержимое перед выпуском или проверить некоторые распространенные проблемы, например размер APK и проблемы с DEX.
Уменьшение размера приложения с помощью APK Analyzer
APK Analyzer может предоставить вам много интересной и полезной информации о размере приложения. В верхней части экрана вы можете увидеть размер необработанного файла — это размер APK на диске. Размер загрузки показывает, сколько данных будет использовано для загрузки вашего приложения, принимая во внимание сжатие, которое делает Play Store.
Список файлов и папок сортируется по их размеру в порядке убывания. Благодаря этому вам сразу показывают как «на блюдце с голубой каемочкой» что можно проще всего оптимизировать в размере APK. Переходя в какую-либо папку в APK файле, вы увидите ресурсы и объекты, которые занимают больше всего места в APK.
Ресурсы отсортированы в порядке убывания по размеру
В этом примере, изучая APK для возможного уменьшения размера, я сразу смог заметить, что 3-кадровая анимация PNG — самая большая вещь в ресурсах, весом в 1,5 МБ, и это для плотности xxhdpi!
Поскольку эти изображения выглядят как идеальные кандидаты для хранения в виде векторов, мы нашли исходные файлы для иллюстраций и импортировали их как VectorDrawables, используя новую поддержку PSD в инструменте импорта векторных ресурсов Android Studio 2.2.
Пройдя этот же процесс для другой оставшейся анимации (instruction_touch _ * .png) и удалив эти PNG-файлы во всех плотностях, мы смогли сэкономить более 5 МБ. Чтобы поддерживать обратную совместимость, мы использовали VectorDrawableCompat из библиотеки поддержки.
Просматривая другие папки ресурсов, было легко обнаружить некоторые несжатые WAV-файлы, которые можно было бы преобразовать в OGG, что означало еще большую экономию, не касаясь строки кода.
Далее в списке вещей, которые нужно проверить, была папка lib/, которая содержит собственные библиотеки для трех поддерживаемых нами ABI.
Было принято решение использовать поддержку разделов APK в нашей сборке Gradle для создания отдельных версий приложения для каждого ABI.
Просмотр других папок в APK
Я быстро просмотрел AndroidManifest.xml и заметил, что в application отсутствует атрибут android:extractNativeLibs. Установка этого атрибута в false позволяет сохранить некоторое пространство на устройстве, поскольку оно предотвращает копирование собственных библиотек из APK в файловую систему. Единственное требование состоит в том, что эти файлы выравниваются по страницам и сохраняются несжатыми внутри APK, которые поддерживаются новым упаковщиком в плагине Android Gradle версии 2.2.0+.
Полный AndroidManifest.xml при просмотре в APK Analyzer
После внесения этих изменений мне было любопытно сравнить новую версию приложения с предыдущей. Для этого я проверил источник из git commit, с которого я начал, скомпилировал APK и сохранил его в другой папке. Затем я использовал функцию «Compare with…», чтобы увидеть разницу в размерах между старыми и новыми сборками.
Сравнение APK — доступ к нему через кнопку в правом верхнем углу
Мы хорошенько прошлись по ресурсам и нативным библиотекам, сэкономив 17 МБ с очень небольшими изменениями в приложении. Тем не менее, я вижу, что наш размер DEX регрессируется, а class2.dex растет на 400 КБ.
Отладка проблем DEX
В этом случае разница была связана с обновлением наших зависимостей до более новых версий и добавлением новых библиотек. Proguard и Multidex уже были включены для наших сборок, поэтому этого размера DEX не так много. Тем не менее, анализатор APK — отличный инструмент для отладки любых проблем с этой настройкой, особенно когда вы впервые включаете Multidex или Proguard для своего проекта.
Просмотр содержимого classes.dex
Когда вы нажимаете на любой файл DEX, вы увидите информацию о том, сколько классов и методов оно определяет, и сколько общих ссылок на методы оно содержит (это те методы, которые учитываются в ограничении 64K в одном файле DEX). В этом примере скриншот, приложение вот-вот достигнет предела, а это значит, что в ближайшем будущем ему понадобится MultiDex для разделения классов на отдельные файлы.
Вы можете просмотреть содержимое пакетов, чтобы узнать, какие из них используют все ссылки. В этом примере мы видим, что основными причинами раздутого DEX-файла являются библиотека поддержки и Службы Google Play.
Количество ссылок на пакет
После того, как вы включили MultiDex и скомпилировали приложение, вы увидите второй файл classes2.dex (и, возможно, classes3.dex и т. Д.) Решение MultiDex в плагине Android-Gradle определяет, какие классы необходимы для запуска вашего приложения и помещает их в основной файл classes.dex, но в редком случае, когда это не работает, и вы получаете исключение ClassNotFoundException, вы можете использовать APK Analyzer для проверки файлов DEX, а затем принудительно добавить отсутствующие классы в первичный файл DEX.
Вы столкнетесь с подобными проблемами при включении Proguard и использовании классов или методов путем отражения или из макетов XML. APK Analyzer может помочь в проверке правильности конфигурации Proguard, позволяя вам легко проверить, имеются ли в APK методы и классы, и переименованы ли они (при обфускации). Также можно убедиться, что классы, которые вы хотите удалить, на самом деле удалены, и не учитываются в счетчике методов.
Нам было бы интересно узнать, какие другие применения вы найдете для APK Analyzer и какие другие функции вы бы хотели увидеть интегрированными в этот инструмент!
Источник
Making the most of the APK analyzer
One of my favorite recent additions to Android Studio is the APK Analyzer, which you can find in the top menu under Build → Analyze APK.
APK Analyzer lets you open and inspect the contents of any APK file you have on your computer, either built from your local Android Studio project or acquired from your build server or other artifact repository. It doesn’t have to be built from any project you have open in Android Studio and you don’t need the source code for that particular APK.
Note: APK Analyzer works best with release builds. If you need to analyze a debug build of your app, make sure you are using an APK that is not instrumented for Instant Run. To obtain it, you can use the Build → Build APKcommand. You can see if you’ve opened an Instant Run instrumented APK by checking the presence of an instant-run.zip file inside the archive.
Using the APK analyzer is a great way to poke around APK files and learn about their structure, verify the file contents before releasing or debug some common problems, including APK size and DEX issues.
Reducing app size with the APK Analyzer
The APK analyzer can give you a lot of useful, actionable info about app size. At the top of the screen, you can see the Raw File Size which is just the APK on-disk size. The Download size shows an estimate of how much data will used to download your app by taking into account compression applied by the Play Store.
The list of files and folders is sorted by total size in descending order. This makes it great for identifying the low hanging fruit of APK size optimization. Each time you drill down into a folder, you can see the resources and other entities that take up the most space in your APK.
In this example, when examining an APK for possible size reductions, I was able to immediately notice that a 3-frame PNG animation is the single biggest thing in our drawable resources, weighing in at 1.5MB, and that’s just for the xxhdpi density!
Since these images look like perfect candidates for storing as vectors, we found the source files for the artwork and imported them as VectorDrawables using the new PSD support in the Vector Asset import toolin Android Studio 2.2.
By going through the same process for the other remaining animation ( instruction_touch_*.png) and removing these PNG files across all densities, we were able to save over 5MB. To maintain backward compatibility we used VectorDrawableCompat from the support library.
Looking at other resource folders, it was easy to spot some uncompressed WAV files that could be converted to OGG, which meant even more savings without touching a line of code.
Next on the list of things to check was the lib/ folder, which contains native libraries for the three ABIs that we support.
The decision was made to use APK splits support in our Gradle build to create separate versions of the app for each ABI.
I quickly looked over the AndroidManifest.xml next and noticed that is missing the android:extractNativeLibs attribute. Setting this attribute to false can save some space on the device as it prevents copying out the native libraries from the APK to the filesystem. The only requirement is that the files are page aligned and stored uncompressed inside the APK, which is supported with the new packager in the Android Gradle plugin version 2.2.0+.
After I made these modifications, I was curious to see how the new version of the app compares to the previous one. To do that, I checked out the source from the git commit with which I started, compiled the APK and saved it in another folder. I then used the Compare with… feature to see a breakdown of size differences between the old and new builds.
We made a lot of progress on the resources and native libraries, saving a total of 17MB with very little changes in the app. However, I can see that our DEX size regressed, with the classes2.dex growing by 400KB.
Debugging DEX issues
In this case, the difference came from upgrading our dependencies to newer versions and adding new libraries. Proguard and Multidex were already enabled for our builds so there’s not much that can be done about our DEX size. Still, APK analyzer is a great tool to debug any issues with this setup, especially when you’re enabling Multidex or Proguard for your project for the first time.
When you click on any DEX file, you will see a summary of how many classes and methods it defines, and how many total references it contains (it’s references that count against the 64K limit in a single DEX file). In this example screenshot, the app is just about to reach the limit, which means it will need MultiDex to split the classes into separate files in the near future.
You can drill down into the packages to see which ones are using up all of the references. In this case, we can see that the Support library and Google Play Services are the main causes for this situation:
Once you’ve enabled MultiDex and compiled your app, you will notice a second classes2.dex file (and possibly classes3.dex, and so on). The MultiDex solution in the Android gradle plugin figures out which classes are needed to start your app and puts them into the primary classes.dex file, but in the rare case when it doesn’t work and you get a ClassNotFoundException, you can use APK Analyzer to inspect the DEX files, and then force the missing classes to be put in the primary DEX file.
You will encounter similar issues when enabling Proguard and using classes or methods by reflection or from XML layouts. The APK Analyzer can help you with verifying that your Proguard configuration is correct, by letting you easily check if the methods and classes you require are present in the APK and if they are being renamed (obfuscated). You can also make sure that classes you want gone are actually removed, and not taking up your precious reference method count.
We’re curious to hear what other uses you find for the APK Analyzer and what other features you’d like to see integrated in the tool!
Источник
