Android Archive Library (aar) vs standard jar


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

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

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

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

3 107

3 ответа:

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

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

AAR s vs Jars:

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

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

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

утверждение "основное различие между Jar и AAR заключается в том, что AAR включают такие ресурсы, как макеты, чертежи и т. д." не соответствует спецификации файла jar и поэтому не является истиной. По словам спецификация файла JAR:

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

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

Итак, по вопросу Android Archive Library (aar) vs standard 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 studio также является устаревшим. Такие библиотеки могут быть развернуты в Maven Central, а такие инструменты, как gradle, могут ссылаться на них с помощью суффикса @aar, например пример:

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

ссылка этой центральное развертывание Maven.