Android Gradle Реализация vs CompileOnly Performance

В документах упоминается, что implementation обеспечивает значительное улучшение времени сборки по сравнению с compile/api. Что насчет compileOnly?

Мой вариант использования - это мультимодуль (извините, мне не нравится проект с несколькими проектами w140), где у меня есть приложение для Android и несколько библиотек, от которых зависит приложение (implementation). Некоторые библиотеки также зависят друг от друга. Должен ли я использовать implementation или compileOnly при объявлении зависимостей в библиотечных модулях? Мой модуль приложения будет использовать implementation, чтобы зависеть от этих артефактов, поэтому мне не нужно, чтобы они проходили через библиотечные модули.

ОТВЕТЫ

Ответ 1

Конфигурация api должна использоваться для зависимостей, которые экспортируются во внешние modules (транзитивная зависимость). Конфигурация implementation наоборот должна использоваться для зависимостей, которые являются внутренними для компонента (не транзитивная зависимость).

реализация против compileOnly:

В их работе нет сходства, compileOnly

  • конфигурация, унаследованная от java-плагина
  • требуется во время компиляции
  • также не включается в путь к классам среды выполнения и не подвергается зависимым проектам.

Таким образом, compileOnly не заменяет задание конфигурации implementation например:

implementation 'com.android.support:appcompat-v7:25.1.0' // can't use compileOnly here
testCompile 'junit:junit:4.12'

compile "com.google.dagger:dagger:2.8" // can't use here also
annotationProcessor "com.google.dagger:dagger-compiler:2.8" // can't use here also
compileOnly 'javax.annotation:jsr250-api:1.0' // we can use compileOnly here because it required on run time only.

Поскольку ваш случай является "многомодульным", вы должны использовать конфигурацию api, пока не дойдете до финального модуля, лучше использовать implementation.

Следующий график описывает эти конфигурации:

enter image description here

Спектакль?

Я думаю, что api требует больше памяти, потому что gradle будет снимать каждый класс в этом транзитивном модуле, и наоборот, implementation является предпочтительной конфигурацией, потому что (как упомянуто выше) она использовала для своих собственных внутренних реализаций.

Ответ 2

В плагине Android Gradle 3.0 ключевое слово compile устарело в пользу implementation и api.

  • api: вы пропускаете интерфейс этого модуля через свой собственный интерфейс, что означает то же самое, что и старая зависимость compile

  • implementation: вы используете этот модуль только для внутреннего использования и не пропускаете его через интерфейс

Узнайте больше о реализации API против здесь и здесь

Зависимости compileOnly функционируют аналогично provided, позволяя объявлять compileOnly зависимости, используемые только во время компиляции.

Зависимости только для компиляции охватывают ряд вариантов использования, в том числе:

  • Зависимости, необходимые во время компиляции, но никогда не требующиеся во время выполнения, такие как аннотации только для исходного кода или процессоры аннотаций;
  • Зависимости, необходимые во время компиляции, но требующиеся во время выполнения только при использовании определенных функций, так называемые необязательные зависимости (при его использовании);
  • Зависимости, API которых требуется во время компиляции, но реализация которых должна обеспечиваться библиотекой, приложением или средой выполнения.

Зависимости только для компиляции заметно отличаются от обычных зависимостей компиляции. Они не включены в путь к классам среды выполнения и не являются транзитивными, то есть они не включены в зависимые проекты.

читать больше здесь