Архивная библиотека Android (aar) против стандартной банки

Я читал некоторые статьи о новом внедрении Gradle в качестве стандартной системы сборки для Android-приложений. Ну, исходя из стандартной разработки Java, я обычно зависеть от файлов jar для создания моего проекта. Однако, похоже, что у Android также есть пакеты aar , которые эквивалентны DLL- файлам в ОС Windows, как упоминалось здесь :

Во-первых, вы должны понимать, что платформа Android не позволяет использовать «общие библиотеки» на уровне приложений. На «традиционных» платформах программирования, C, C ++, Java, вы называете это, у нас есть этот механизм совместного использования библиотек времени исполнения. (Например, DLL в Windows, DSO в Unix, Jar на JVM и т. Д.). Однако на Android вы не сможете этого сделать, если только вы не являетесь Google или производителем телефона (см. Сноску 1 ниже). В качестве разработчика приложений это может быть фундаментальным ограничением. «Совместное использование» или «повторное использование» кодов, как во время сборки, так и во время выполнения, является очень важной частью практики разработки программного обеспечения. Это довольно сложно (не сложно, просто сложнее) на Android из-за вышеупомянутого ограничения.

Однако у меня есть некоторые сомнения по поводу этой концепции. Я имею в виду, когда разработчик должен интересоваться, в том числе, аранными зависимостями в своем приложении? Связаны ли эти зависимости с минимальной версией SDK?

Например, в одном проекте я получаю доступ к COM-порту, для которого я использую предварительно скомпилированные библиотеки NDK .so . Должен ли я создать aar, если я хочу поделиться этой утилитой?

Solutions Collecting From Web of "Архивная библиотека Android (aar) против стандартной банки"

Файлы AAR больше похожи на Jar чем на Dll s по следующей причине:

Dll s можно разделить между приложениями, в которых AAR и банки упакованы вместе с вашим приложением.

AAR s против Jar s:

Основное различие между Jar и AAR заключается в том, что AAR включают ресурсы, такие как layouts, drawables и т. Д. Это значительно упрощает создание автономных визуальных компонентов. Например, если у вас несколько приложений, которые используют один и тот же экран входа в систему, с Jar s вы можете делиться классами, но не с макетом, стилями и т. Д., Вам все равно придется их дублировать. С AAR все в комплекте в одном аккуратном пакете.

В заключение, AAR – большой шаг в правильном направлении.

Заметка:
Аналогичные попытки были предприняты с apk-lib но теперь они устарели, так как AAR намного лучше.

Утверждение « Основное различие между Jar и AAR заключается в том, что AAR включают в себя такие ресурсы, как макеты, чертежи и т. Д. », Не соответствует спецификации JAR-файла и, следовательно, не является правдой. Согласно спецификации файла JAR :

JAR-файл – это формат файла на основе популярного формата ZIP-файла и используется для объединения многих файлов в один. Файл JAR – это, по существу, zip-файл, который содержит необязательный каталог META-INF.

Как вы можете видеть, ограничение содержимого не запрещает включать в файл JAR такие ресурсы, как макеты, чертежи и т. Д. Более подробно см. Статью 5.3 «Создание и загрузка» спецификации виртуальной машины Java®.

Итак, на вопрос Android Archive Library (aar) против стандартного jar. Ответ зависит от того, какой инструмент сборки вы используете.

Если вы используете Android Studio в качестве инструмента сборки (соответственно, как организатор проекта), вам определенно лучше использовать файлы * .aar для обмена инкапсулированными ресурсами между проектами Android. Формат файла AAR является частью сборки Android Studio, и, как он комментируется в других комментариях, его пользовательский интерфейс поддерживает формат aar для Android-библиотек.

Но, кроме Android Studio, остальной мир не знает, что это за файл aar file (артефакт). Например, если ваша сборка Android основана на Maven, предпочтительным файлом для совместного использования ресурсов будет jar, потому что это собственный артефакт проекта Maven java, и нет никаких ограничений на то, что помещать в стандартный файл jar. Кроме того, есть способ объяснить Maven любым файловым форматом, включить aar с помощью улучшения жизненного цикла с помощью нового компонента. Простой пример доступен здесь. Как создать новый тип упаковки для Maven?

Цитирование в вопросе не имеет ничего общего с текущей реальностью. Конечно, в Android можно использовать внешние библиотеки и доступно множество библиотек. Возможно, они хотели сказать, что каждое приложение должно связывать все библиотеки, в которых оно нуждается, но повторное использование библиотеки во время сборки (статическая привязка) действительно не является проблемой.

.aar отличается от .jar не более .jar отличается от .zip . В нем есть определенные концепции, по которым следует ожидать такого содержания, но как .jar и .aar чаще всего содержат скомпилированные классы и ресурсы. .aar просто указывает, что библиотека специфична для Android и имеет некоторую ожидаемую структуру, разумную для таких библиотек (ну, .jar также имеет некоторую ожидаемую структуру).

Представление, что .aar поддерживается только в студии Android, также устарело. Такие библиотеки можно развернуть в Maven Central, и такие инструменты, как gradle, могут ссылаться на них с помощью суффикса @aar, например:

 dependencies { compile ('io.github.andviane:uncover:2.0.1@aar') .. } 

Чтобы ссылаться на это центральное развертывание Maven.