- zipalign
- Что означает zipalign и как он соответствует тому, как мы используем наши устройства Android?
- Выравнивание приложения утилитой zipalign
- Zipalign android что это
- Компиляция и сборка Android приложения (как это работает)
- В общих чертах процесс сборки приложения выглядит так:
- Немного полезного оффтопа:
zipalign
zipalign is an archive alignment tool that provides important optimization to Android application (.apk) files. The purpose is to ensure that all uncompressed data starts with a particular alignment relative to the start of the file. Specifically, it causes all uncompressed data within the .apk, such as images or raw files, to be aligned on 4-byte boundaries. This allows all portions to be accessed directly with mmap() even if they contain binary data with alignment restrictions. The benefit is a reduction in the amount of RAM consumed when running the application.
This tool should always be used to align your .apk file before distributing it to end-users. The Android build tools can handle this for you. When using Eclipse with the ADT plugin, the Export Wizard will automatically zipalign your .apk after it signs it with your private key. The build scripts used when compiling your application with Ant will also zipalign your .apk, as long as you have provided the path to your keystore and the key alias in your project ant.properties file, so that the build tools can sign the package first.
Caution: zipalign must only be performed after the .apk file has been signed with your private key. If you perform zipalign before signing, then the signing procedure will undo the alignment. Also, do not make alterations to the aligned package. Alterations to the archive, such as renaming or deleting entries, will potentially disrupt the alignment of the modified entry and all later entries. And any files added to an «aligned» archive will not be aligned.
The adjustment is made by altering the size of the «extra» field in the zip Local File Header sections. Existing data in the «extra» fields may be altered by this process.
For more information about how to use zipalign when building your application, please read Signing Your Application.
Источник
Что означает zipalign и как он соответствует тому, как мы используем наши устройства Android?
Что означает «zipalign» и каково его значение?
Когда ПЗУ заявляет, что оно «zipaligned», что это означает и в чем отличие от ПЗУ, которое не «zipaligned»?
Этот механизм описан на сайте разработчиков Android следующим образом:
zipalign — это инструмент выравнивания архива, который обеспечивает важную оптимизацию для файлов приложений Android (.apk). Цель состоит в том, чтобы все несжатые данные начинались с определенного выравнивания относительно начала файла. В частности, он вызывает выравнивание всех несжатых данных в .apk, таких как изображения или необработанные файлы, по 4-байтовым границам. Это позволяет напрямую обращаться ко всем частям с помощью mmap (), даже если они содержат двоичные данные с ограничениями выравнивания. Преимущество заключается в уменьшении объема оперативной памяти, используемой при запуске приложения.
Вкратце: .apk доступ к контенту может быть проще / быстрее / более оптимальным благодаря порядку данных внутри упакованного файла.
Для получения более подробной информации на AddictiveTips доступно «полное руководство»: что такое Zipalign в Android и как сделать приложения Zipaligned , которое отвечает на вторую часть вашего вопроса:
Вполне понятно, что ситуация будет зарезервирована для невыровненных пакетов приложений. Чтение ресурсов будет медленным, а использование памяти будет на более высоком конце спектра. Это также будет зависеть от того, сколько не выровненных приложений. Например, если число приложений с невыровненным домашним приложением меньше, вы увидите более медленное время запуска приложений. Это лучший вариант развития событий. В худшем случае наличие нескольких невыровненных приложений приведет к тому, что система будет многократно запускать и убивать процессы, борясь с задержками и огромным расходом батареи.
Чтобы добавить выше, как именно работает zipalign —
В операционной среде Android файлы данных, хранящиеся в каждом пакете приложения, доступны нескольким процессам, например, установщик прочитает манифест данных, чтобы определить связанные разрешения; системный сервер может читать эти ресурсы по нескольким причинам, например, отображать уведомления; домашнее приложение, например, будет читать ресурсы, чтобы получить имя и значок приложения. Так как Android основан на действительно многозадачной операционной инфраструктуре, к этим файлам постоянно и многократно обращаются. Наконец, что не менее важно, само приложение считывает данные манифеста.
Поскольку Android основан на Linux, отображение памяти играет ключевую роль в эффективной обработке процессов. По сути, оптимальное выравнивание для кода обработки ресурсов ОС Android — это 4-байтовые границы. Это означает, что, если APK-карты сопоставлены с 4-байтовыми границами памяти и соответствующим образом выровнены, ОС не потребуется «читать» весь пакет приложения, чтобы получить требуемый манифест данных. Каждый системный процесс заранее будет знать, где искать нужные ему ресурсы, и, следовательно, будет выполняться гораздо плавнее и быстрее.
Подводя итог, zipaligning APK приводит к выравниванию всех несжатых данных в пакете по 4-байтовым границам, что позволяет получить доступ ко всем частям непосредственно с картой памяти. Потребление ОЗУ уменьшается во время выполнения, потому что запрашивающий код не должен читать весь пакет приложения.
Источник
Выравнивание приложения утилитой zipalign
Весьма желательно, чтобы приложение во время своей работы использовало память максимально эффективно. Если приложение содержит несжатые данные (например, некоторые виды изображений или файлы данных), то Android может отобразить эти данные непосредственно в память с помощью вызова mmap() . Однако для этого данные должны быть выровнены по 4-байтовой границе. Процессоры в Android-устройствах являются 32-разрядными, а 32 бита — это как раз 4 байта. Вызов mmap() делает так, что данные из .apk-файла как будто находятся в памяти, но если данные не выровнены по 4-байтовой границе, то вызов не сработает, и придется осуществлять лишнее копирование данных во время выполнения приложения. Утилита zipalign, которая находится в каталоге инструментальных средств Android SDK, просматривает приложение и слегка сдвигает несжатые данные, чтобы они оказались выровненными по границе 4 байтов. При этом размер файла приложения увеличивается, но незначительно. Для выравнивания .apk-файла запустите в окне инструментов следующую команду (рис. 14.4):
zipalign -v 4 имя_входного_файла.apk имя_выходного_файла.apk
Утилита zipalign не изменяет входной файл — именно поэтому при экспорте из Eclipse мы добавляем к имени часть raw, и выходной файл имеет имя, необходимое для развертывания. Если нужно перезаписать существующий файл outfile.apk, укажите опцию -f. При создании выровненного файла zipalign проверяет выравнивание. Поэтому для проверки правильности выравнивания существующего файла можно использовать утилиту zipalign следующим образом:
zipalign -c -v 4 имя_файла.apk
Очень важный момент заключается в том, что выравнивание должно выполняться после подписания — в противном случае подписание может снова сдвинуть данные с границ 4 байтов. Это не означает, что приложение будет неработоспособным, но оно будет занимать больше памяти, чем необходимо.
Источник
Zipalign android что это
Если вы фанат хардкора Android, велика вероятность того, что вы с нетерпением будете опробовать новые темы, пользовательские ПЗУ и все подобные моды для вашего устройства. Одним из основных вопросов, вызывающих путаницу, является терминология, связанная с этими модами — что-то довольно знакомое разработчикам, но не многим для начинающего пользователя. Двумя наиболее часто встречающимися словами в пользовательских ПЗУ и темах являются «деодексированный» и «zipalign». Несколько дней назад мы подробно рассказали о «деодексированном». В этой статье мы рассмотрим что означает zipalign а также как APK могут быть объединены.
ЧТО ТАКОЕ ZIPALIGN?
zipalign — это инструмент для выравнивания архива, впервые представленный в Android SDK 1.6 (комплект разработки программного обеспечения). Оптимизирует способ упаковки пакета приложений Android (APK). Это позволяет операционной системе Android более эффективно взаимодействовать с приложением и, следовательно, может значительно ускорить работу приложения и всей системы в целом. Время выполнения сводится к минимуму для приложений с zipaligned, что приводит к меньшему потреблению оперативной памяти при запуске APK.
ТАК КАК ЭТО ТОЧНО РАБОТАЕТ?
В операционной среде Android файлы данных, хранящиеся в каждом пакете приложения, доступны нескольким процессам, например, установщик прочитает манифест данных, чтобы определить связанные разрешения; системный сервер может читать эти ресурсы по нескольким причинам, например, отображать уведомления; например, домашнее приложение будет считывать ресурсы, чтобы получить название и значок приложения. Поскольку Android основан на действительно многозадачной операционной инфраструктуре, к этим файлам постоянно и многократно обращаются. Наконец, что не менее важно, само приложение считывает данные манифеста.
Поскольку Android основан на Linux, отображение памяти играет ключевую роль в эффективной обработке процессов. По сути, оптимальное выравнивание для кода обработки ресурсов ОС Android — это 4-байтовые границы. Это означает, что, если APK-файлы сопоставлены с 4-байтовыми границами памяти и соответствующим образом выровнены, ОС не потребуется «читать» весь пакет приложения, чтобы получить требуемый манифест данных. Каждый системный процесс заранее будет знать, где искать нужные ему ресурсы, и, следовательно, будет выполняться гораздо плавнее и быстрее.
Подводя итог, zipaligning APK приводит к выравниванию всех несжатых данных в пакете по 4-байтовым границам, что позволяет получить доступ ко всем частям непосредственно с картой памяти. Потребление ОЗУ снижается во время выполнения, потому что запрашивающему коду не нужно читать весь пакет приложения.
НЕДОСТАТКИ НЕПРАВИЛЬНЫХ АПК
Вполне понятно, что ситуация будет зарезервирована для невыровненных пакетов приложений. Чтение ресурсов будет медленным, а использование памяти будет на более высоком конце спектра. Это также будет зависеть от количества неприсоединившихся приложений. Например, если число приложений с невыровненным домашним приложением меньше, вы увидите более медленное время запуска приложений. Это лучший вариант развития событий. В худшем случае наличие нескольких невыровненных приложений приведет к тому, что система будет многократно запускать и убивать процессы, борясь с задержками и огромным расходом батареи.
КАК ВЫ ЭТО ДЕЛАЕТЕ, ТОГДА?
Как упоминалось ранее, инструмент zipalign стал частью Android SDK начиная с версии 1.6. Его можно найти в папке «tools» в SDK. Чтобы использовать его, просто запустите команду:
где infile.apk это исходный файл, и outfile.apk это выходной файл
Кроме того, вы также можете проверить выравнивание файла APK, используя следующую команду:
где existing.apk может быть любой пакет приложения, который вам нужно проверить. Так же тег в обеих командах должен быть целочисленным значением (в противном случае команда вернет недействительное значение). Это значение, хотя может быть любым целым числом, ДОЛЖНО всегда быть 4, что обеспечит 32-битное выравнивание. Любая другая ценность, и она фактически ничего не сделает.
Наконец, для флагов, используемых в этих командах,
- -f : перезаписывает существующий outfile.zip
- -v : даст подробный вывод
- -с : подтвердит выравнивание данного файла
СЛОВО ОСТОРОЖНО: Операция zipalign должна выполняться только после Вы подписали APK-файл своим закрытым ключом. Если zipaligned до подписания, процедура подписания нарушит выравнивание. То же самое верно для любого другого изменения, добавления или удаления в APK-файл. Любое изменение после запуска zipalign приведет к отмене выравнивания.
Отказ от ответственности: Это руководство предназначено только для образовательных целей. Это никоим образом не заменяет инструментарий разработчика Android и не предназначено для использования в целях разработки. AddictiveTips не предоставляет никакой поддержки, связанной с материалами, представленными здесь.
Источник
Компиляция и сборка Android приложения (как это работает)
Дисклеймер: Я не 23 летний сеньор (мне 19 и до сеньора мне еще ой как далеко, года 4, поэтому супер статьи от меня не ждите.
Основа пути моего, разработчика как — обучение/изучение нового постоянное. Надеюсь, у вас тоже.
Я бы хотел подробно рассмотреть процесс компиляции и сборки Android приложения в конечный .apk. Да, при разработке очередного приложения какашкибезholoстилей эта информация вам нафиг не сдалась, но для общего развития будет полезна всем Android разработчикам.
Конечно, можно было бы ограничиться инструкцией вроде:
- Напишите код
- Нажмите кнопочку Build & Run в вашей IDE
- Продолжайте быть Android разработчиком
Но мы не ищем легких путей.
Примечание:
Это не перевод http://developer.android.com/tools/building/index.html, это статья, основанная в том числе и на данной документации.
В общих чертах процесс сборки приложения выглядит так:
Нас особенно интересует второй этап (компиляция и сборка ресурсов), так что, рассмотрим его более подробно (21 этап как никак):
Пожалуйста, не прокручивайте диаграмму из-за того, что вам лень вникать, она не сложная, к тому же переведенная. Это основа статьи.
(Оригинал здесь: developer.android.com/tools/building/index.html)
Что есть что на диаграмме:
1. Ресурсы приложения — это все xml ресурсы из папки res вашего проекта + некомпилируемые бинарные ресурсы, например, картинки из res/drawable или файлы из /res/raw, а так же файлы из /assets/
2. aapt — утилита, которая ищет в вашем проекте компилируемые ресурсы, такие как AndroidManifest.xml и xml файлы из res/ и компилирует их в бинарное представление, а изначально бинарные ресурсы, такие как картинки, и файлы из /res/raw и /assets не компилируются. Далее, эта утилита генерирует важнейший класс R.java для вашего приложения, благодаря которому вы можете обращаться к ресурсам из вашего кода без всяких заморочек с чтением файлов, как скажем с /assets.
Кстати, кроме компиляции xml ресурсов, aapt создает файл resources.arsc, который представляет собой таблицу для маппинга ресурсов во время выполнения приложение, туда входят все ресурсы из /res/, в том числе и /res/raw/, содержимое /assets не включается в таблицу.
Полезно знать: Утилита aapt находится в папке platform-tools вашего Android SDK. Если вам захотелось сделать реверс-инжиниринг скомпилированных ресурсов приложения, вы можете воспользоваться apk-tool (https://code.google.com/p/android-apktool/)
3. R.java — класс, генерируемый утилитой aapt для того, чтобы вы могли обращаться к ресурсам из папки res без явной работы с файловой системой через библиотеки ввода/вывода.
Если кто-то еще не знал — всякие R.string, R.menu и прочее — это статические вложенные классы, а в R.string.app_name, app_name — public static final int поле класса. Получается, что правило-принцип CamelCase, применяемый в Java, для них нарушен, должно то быть: R.String, R.Menu, а с константами — R.String.APP_NAME, айайай Google.
4. Исходный код приложения — это ваши (или украденные форкнутые с других проектов) .java файлы с кодом проекта из папки src, все просто.
5. Java интерфейсы — это не те, обычные интерфейсы (обычные входят в состав исходного кода приложения, предыдущий пункт), которые вы используете в вашем коде, это интерфейсы, сгенерированные утилитой aidl (следующий пункт содержит пояснение).
6. .aidl файлы — это интерфейсы, которые вы можете написать на Java с немного необычным синтаксисом (на самом деле, язык называется AIDL — Android Interface Defenition Language). Такие интерфейсы нужны для описания взаимодействия между различными процессами, например когда вам нужно, чтобы сервис (Service) вашего приложения работал не просто в отдельном потоке, а именно в отдельном процессе (у такого подхода есть как преимущества, например, раздельные квоты на память для процессов, так и недостатки — необходимость использования aidl), на Хабре есть статья, в которой раскрыта тема использования aidl http://habrahabr.ru/post/139432/).
7. aidl — утилита, которая транслирует ваши .aidl файлы в Java код, она находится в папке platform-tools вашего Android SDK.
8. Java компилятор — (наконец-то мы до него добрались!) это обычный javac из вашего JDK, которому дают на обработку исходный код приложения (4), R.java (3) и интерфейсы aidl, которые переведены в java код с помощью утилиты aidl
9. .class файлы — это «выхлоп» javac — байткод для JVM. Так как Dalvik VM не может интерпретировать java bytecode, а использует свой велосипед под название dex bytecode, то на этом компиляция проекта не заканчивается.
Разработчики Android выбрали регистровую архитектуру Dalvik VM, вместо привычной для JVM — стековой архитектуры из двух ключевых соображений:
1. Производительность регистровой ВМ выше (инфа 100%), особенно на процессорах с RISC-архитектурой, а это все ARM процессоры. Первые версии Dalviik VM даже не включали JIT (до Android 2.2), но давали терпимую производительность приложений, скажем я не испытывал особых проблем с HTC Desire на 2.1.
2. java bytecode транслируется в меньший по объему dex bytecode, что уменьшает размер скомпилированного приложения.
10. dex компилятор (а точнее транслятор) — он транслирует .class файлы в classes.dex (Java bytecode в Dalvik bytecode). Описание .dex вы можете прочитать здесь source.android.com/tech/dalvik/dex-format.html.
Сам компилятор находится в папке platform-tools вашего Android SDK, запускать его можно через dx.bat (для Windows), при этом будет задействован dx.jar из папки platform-tools/lib
11. Сторонние библиотеки и .class файлы — это все то, что вы подключаете в проект как библиотеку или включаете в Build Path. Так как в качестве основного ЯП для Android выбрана Java, вы можете без проблем использовать практически любые java библиотеки, они просто будут обработаны dex компилятором.
12. classes.dex — в данный файл dex компилятор записывает весь исполняемый код вашего проекта.
Да-да, все будет в одном файле, хотя в документации написано, что файлов .dex может быть несколько, но на практике, я не встречал, чтобы .apk содержал .dex файлы кроме classes.dex, может в комментариях меня поправят.
13. Скомпилированные ресурсы — xml ресурсы приложения, скомпилированные в бинарное представление.
14. Другие ресурсы — это реально другие ресурсы, которые не обрабатываются aapt — например файлы, которые вы зачем то хотите засунуть в .apk, так же туда попадают файлы из .jar`ов, которые добавлены в Build Path, но не являются компилируемыми.
15. apkbuilder — утилита, которой на вход подают скомпилированные ресурсы (2, 13), classes.dex (12) и другие ресурсы (14), а она собирает из этого наш вожделенный .apk файл. Утилита лежит в папке tools вашего Android SDK
16. Собранное приложение в файл .apk — это архив, содержащий скомпилированные и нескомпилированные ресурсы, classes.dex, resources.arsc, META-INF, AndroidManifest.xml и т.д.
Формат .apk это надстройка над .jar, а .jar — надстройка над zip, так что, .apk вы можете открыть zip архиватором, такая вот матрешка.
17. jarsigner — это Oracle`вская утилита для подписания .jar архивов. Он подписывает ваш .apk выбранным вами ключом.
Но не надо думать, что ваш .apk теперь защищен от декомпиляции, ничего подобного. В .apk только добавляется папка META-INF, в которой вы можете обнаружить публичную часть release (или debug) сертификата — файл CERT.RSA, а так же файл CERT.SF — который содержит контрольные суммы для всех файлов внутри .apk, кроме тех, что в папке META-INF
Пример содержания CERT.SF:
Signature-Version: 1.0
SHA1-Digest-Manifest-Main-Attributes: O1qITQssq6nv0FUt+eR1aLnqk5w=
Created-By: 1.6.0_43 (Apple Inc.)
SHA1-Digest-Manifest: OwzyFA/Qjd+5X1ZwaJQSxFgdciU=
Name: res/drawable-mdpi-v4/ic_premium_pin.png
SHA1-Digest: 8ksQB8osCHTnMlpL6Ho/GDc719Q=
Name: res/drawable/round_bottom_white.xml
SHA1-Digest: rQelve4dQmwCfkVlYZ2+9j5aW5w=
Еще немного важной информации о подписи приложения:
В Android уникальным идентификатором приложения является имя пакета приложения, например ru.habrahabr.android. Но чтобы злоумышленник не смог подменить ваше установленное приложение на свое с таким же пакетом, Android выполняет проверку, на то чтобы новый .apk был подписан тем же сертификатом, что и уже установленный.
Кроме того, если у вас есть выложенное приложение в Google Play, вы не сможете обновить его, если новая версия подписана другим сертификатом! Так что советую забекапить сертификат, а так же не забыть пароль к нему. Иначе вы не сможете обновлять свои приложения.
18. Debug или Release хранилище ключей — хранилище из которого jarsigner возьмет ключи для подписи приложения. Если вы собираете Debug версию (для запуска на эмуляторе или подключенном устройстве), то .apk подписывается debug ключем, в Windows он находится в папке пользователя/.android/.
Кстати, приложение подписанное debug ключом нельзя установить без подключенного отладчика. Так что, если хотите отправить .apk друзьям на тестирование — подпишите его Release ключем
19. Подписанный .apk — .apk файл вашего приложения, в который добавлена информация о подписи (см. пункт 17).
20. zipalign — утилита, которая оптимизирует ваш .apk для более быстрого запуска и меньшего потребления ОЗУ при работе приложения. Она выравнивает содержимое .apk для более эффективной разархивации (подробнее здесь: http://developer.android.com/tools/help/zipalign.html).
Важное замечание: приложение надо сначала подписать, а затем применить zipalign, т.к. подпись — это добавление папки META-INF в архив, а это изменение архива, следовательно нарушение его оптимизации. То есть, если вы сначала примените zipalign, а потом измените архив — смысла в zipalign не будет. Насчет нарушения контрольных сумм, которые рассчитала утилита jarsign, бояться не стоит, т.к. zipalign делает оптимизации по выравниванию данных в архиве, все это происходит на уровне zip, сами данные не изменяются.
Хозяйке на заметку: во время сборки debug версии проекта zipalign не вызывается, скорее всего, чтобы вы не ждали выполнения еще и этой операции (спасибо и на этом).
21. Подписанный (и, возможно, выравненный) .apk — вожделенный .apk вашего приложения. Конец.
Я думаю, что теперь понятно, почему сборка и запуск Android приложения происходит так долго 🙂 Так что, советую поставить SSD, ну и процессор побыстрее и сэкономить себе нервы и время.
Немного полезного оффтопа:
1. Всегда используйте обфускацию вашего кода. Декомпилировать java приложение очень легко. Даже несмотря на то, что в .apk используется dex bytecode — его сначала транслируют обратно в java bytecode, а затем к нему применят обычные java декомпиляторы. Потратьте пару часов на выбор и настройку обфускатора, иначе можете просто выложить исходники проекта на гитхаб, секономите людям время, а может еще и пулл реквесты получите 🙂
2. Вы знали, что Android инстанциирует для каждого запущенного приложения отдельный экземпляр Dalvik VM? Это сделано для того, чтобы исключить ситуации, когда одно приложение валит Dalvik VM, а за ним тянет все другие запущенные приложения. Яркий пример подобного вмешательства — Facebook, они через reflection изменяют параметры Dalvik VM (не стоит так делать). Если бы Android использовал один инстанс Dalvik — это изменение затронуло бы все запущенные приложения.
3. Dalvik VM не является JVM, т.к. во-первых он не понимает java bytecode, а во-вторых не реализует спецификации для JVM, т.к. использует свой байт код. Так что, советую называть Dalvik VM именно Dalvik VM.
Надеюсь, вы не зря потратили свое время и узнали что-то новое.
Источник
