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

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

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

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

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

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

Dlls можно использовать совместно с приложениями, в которых AARфайлы as и jar упакованы вместе с вашим приложением.

AARs vs Jars:

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

В заключение AARскажу, что это большой шаг в правильном направлении.

Примечание:
аналогичные попытки были сделаны с apk-libs, но теперь они устарели, так как AARs намного лучше.

Утверждение « Основное различие между 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, и, как он прокомментирован в других комментариях здесь, его пользовательский интерфейс поддерживает формат aar для библиотек Android.

Но, кроме Android Studio, остальной мир не знает, что это за файл (артефакт). Например, если ваша сборка Android основана на Maven, предпочтительным файлом для совместного использования ресурсов будет jar, потому что это собственный артефакт Java-проекта Maven, и нет никаких ограничений, что помещать в стандартный файл 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.