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

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

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

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

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

Ответ 1

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

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

AAR vs Jar s:

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

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

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

Ответ 2

Утверждение "Основное различие между Jar и AAR заключается в том, что AAR включают в себя такие ресурсы, как макеты, чертежи и т.д." не соответствует спецификации файла JAR и, следовательно, не является правдой. В соответствии с спецификация файла JAR:

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

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

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

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

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

Ответ 3

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

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

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

dependencies {
    compile ('io.github.andviane:uncover:[email protected]')
    ..
}

для ссылки this Централизованное развертывание Maven.