Gradle: плюсы/минусы, добавляющие зависимости

Ответ 1

В Gradle зависимости сгруппированы в конфигурации как конфигурации зависимостей. Внешняя зависимость зависит от некоторых файлов, созданных за пределами текущей сборки, и хранится в каком-то репозитории, таком как Maven central или корпоративный Maven или Ivy репозиторий или каталог в локальной файловой системе.

Типы зависимостей:

Внешняя зависимость модуля:

Зависимость от внешнего модуля в каком-то репозитории.

Зависимость от проекта:

Зависимость от другого проекта в той же сборке.

Зависимость файлов:

Зависимость от набора файлов в локальной файловой системе.

Зависимость клиентского модуля:

Зависимость от внешнего модуля, где расположены артефакты в каком-то репозитории, но метаданные модуля определяются локальным строить. Вы используете эту зависимость, если хотите переопределить метаданные для модуля.

Gradle зависимость API:

Зависимость от API текущей версии Gradle. Вы используете это вид зависимости, когда вы разрабатываете пользовательские плагины Gradle и типы задач.

Локальная зависимость Groovy:

Зависимость от версии Groovy, используемой текущей версией Gradle. Вы используете такую ​​зависимость при разработке пользовательских Gradleплагинов и типов задач.

Плюсы добавления зависимостей:

• В Gradle вы просто объявляете "имена" своих зависимостей и другие слои определяют, откуда взять эти зависимости.

• Возможно изменение кода в SubProject.

• Очистить прямую зависимость, включая версию используемой библиотеки
  Очистить косвенные управляемые зависимости (например, используемая библиотека использует другую Библиотека - POM файлы) {от пользователя Robert Halter).

• зависит от доступности онлайн

• Необходимая библиотека sdk уже синхронизирована с проектом для сборники.

Минусы:

Таким образом, он не имеет никаких недостатков, но на начальном этапе, добавляя мы должны синхронизировать это, что занимает немного времени, чем просто перетаскивание файла jar.

Замедление времени компиляции с заметной скоростью?

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

Увеличьте размер release-apk и debug-apk, насколько размер добавленной зависимости?

Нет, но практически да, потому что он принимает размер сборки файл (двоичный размер), который вряд ли увеличивает размер в байтах или kb, что вряд ли можно проследить.

Итак, наконец, добавление их в качестве зависимостей Gradle является излишним, когда нам нужно использовать только часть конкретной библиотеки?

Определенно, может быть такая ситуация, как в вашем случае, использовать только подмножество библиотеки. В этом случае оптимизация ProGuard выполнять анализ на уровне байт-кода, внутри и между методами помогите сделать ваше приложение меньше и быстрее работать без переполнения.

Ответ 2

Больше всего беспокоит ваш размер приложения для Android. Многие из методов или классов могут поднять ограничение 64k на файл dex и в большинстве случаев включать режим multi-dex или jumbo. Это может создать проблему с совместимостью, если у вас очень устаревшие клиенты.

Иногда вы можете обойти это, только извлекая нужные классы, но иногда это непростая задача.

Если у вас включен proguard, классы, которые не используются, могут быть систематически удалены.

Ответ 3

Копирование кода сторонней библиотеки в ваш проект вызывает некоторые проблемы с поддержкой этого проекта Что делать, если вам понадобится использовать эту библиотеку более новой версии? Если вы добавите его в качестве зависимости, вам потребуется только изменить номер версии в конфигурации системы сборки

Ответ 4

Что такое плюсы/минусы, добавляющие зависимости из подпроекта в Gradle Build Project?

dependencies {
    compile project(':library')
}

Pros

• Смена кода в библиотеке: возможен подпроект

против

• Управлять самостоятельно Версия подпроекта:

Каковы плюсы и минусы, добавляющие зависимости из зависимой от версий библиотеки a в Gradle Build Project?

dependencies {
    compile 'com.stackoverflow.android:some-great-library:1.0'
}

Pros

• Очистить прямую зависимость, включая версию используемой библиотеки
• Очистить косвенные управляемые зависимости (например, используемая библиотека использует другую библиотеку - файлы POM)
• Другой человек/группа управляет функциональностью библиотеки - вы можете сосредоточиться на своем собственном коде.

против

• None

Добавляет зависимости как: библиотека Подпроект замедляет время компиляции с заметной скоростью?

• Да, они тоже должны компилироваться, потому что они находятся в исходном коде в вашем подпроекте
• Gradle Оптимизировать качество с определением задачи ввода/вывода. См. Маркеры UP-TO-DATE при построении.

Зависит ли добавление зависимостей от версии, зависящей от версии, от замедления времени компиляции с заметной скоростью?

• Нет, beacause библиотеки (.jar) уже скомпилированы.

Увеличивает ли добавление зависимостей размер release-apk и debug-apk, а также размер добавленной зависимости?

• Размер apk увеличивает размер двоичного файла (.jar = Zipped.class Files) добавленной зависимости.
• (Если у вас включен proguard, классы, которые не используются, могут быть систематически удалены - от пользователя phdfong)

Ответ 5

Добавить ли стороннюю библиотеку в качестве зависимости

Вы объявляете зависимость от сторонней библиотеки, когда ваша программа использует какой-либо код в этой библиотеке во время компиляции или во время выполнения. Это означает, что сторонний код должен быть доступен, когда ваша программа запущена, поэтому она упакована вместе с вашей программой. Таким образом, размер приложения увеличивается, и это нежелательно, потому что многим пользователям не нравятся огромные приложения. Также это смешно, когда ваша программа небольшая, а сторонняя библиотека огромна.

Следует ли добавлять стороннюю библиотеку в качестве модуля

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

Добавить ли вы только тот код, который вам нужен

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

Добавляет зависимости: замедляет время компиляции с заметной скоростью?

При правильной настройке Gradle (работая как демон в фоновом режиме, используя параллельную обработку) вы не увидите каких-либо существенных изменений в типичном проекте.

Добавляет зависимости: увеличивает размер release-apk и debug-apk, насколько размер добавленной зависимости?

Зависимость jar отправляется в dex для преобразования байт-кода, а также код проекта. Это не конверсия 1:1 с точки зрения размера, поэтому ответ отрицательный. Также у ProGuard есть некоторые трюки для минимизации размера банки, и у Maven есть plugin для упаковки всех зависимых банок в один, поэтому все они могут быть запутаны.

Ответ 6

Я думаю, что этот вопрос не очень зависит от Gradle, но в целом с помощью "средств управления зависимостями".

Конечно, есть ситуации, когда нам нужно только подмножество библиотеки. В этих ситуациях необходимость импортировать всю зависимость может быть не лучшим решением.

Сколько это "перебор"? Очевидно, это зависит от размера вашего проекта. Это зависит от вас, чтобы оценить, насколько "чрезмерная" зависимость может быть: например, если вам нужна только простая функция, и вы импортируете библиотеку из 3 МБ, возможно, да, это бит "overkill!"

Кроме того, вы должны учитывать, что обычно "большие" библиотеки делятся на модули, и поэтому вы можете импортировать только необходимый модуль. В случае Android, как сказал @phdfond, вы можете использовать ProGuard для удаления неиспользуемых классов во время сборки, или вы можете исключить их вручную с помощью Gradle:

//...      
sourceSets {
         main {
             java {
                 exclude '**/IDontWantThisClass.java'
             }
         }

Но IMHO эта ситуация не очень распространена, и у вас может быть много преимуществ с помощью Gradle или другого "инструмента управления зависимостями" (обратите внимание, что в Gradle, Maven, ecc... управление зависимостями одна из их функциональных возможностей).

Например, если вы используете Gradle с первого взгляда, вы знаете свои зависимости, и вы можете легко добавить/удалить их или просто изменить номер, чтобы обновить свою версию. Вы когда-нибудь думали, что ваш проект зависит от libs B и C, а оба B и C могут зависеть от двух разных версий lib D? Хорошо Gradle также может помочь вам в ситуациях, подобных этому. Я не могу продолжать здесь, потому что я буду не по теме, но вы можете найти много информации об этих инструментах.

Наконец, я думаю, что самым важным "CONS" из "инструментов управления зависимостями" является начальное время обучения и настройки. Если вы никогда не использовали инструмент типа Gradle, то в первый раз потребуется больше времени, чем перетащить банку, поэтому я настоятельно рекомендую вам использовать Gradle в ваших проектах, если только это не "игрушечный проект".

Ответ 7

Я бы сказал, что они принципиально разные вещи.

1. Gradle подпроект

dependencies {
  compile project(':foobarlib')
}

В этом первом случае вы зависите от подпроекта Android, входящего в проект Gradle, над которым вы работаете. Вы также можете назвать этот тип зависимости a module, как это делает Intellij.

Если вы хотите внести изменения, вы можете сделать это, и все, что требуется для того, чтобы это изменение было видимым, это компиляция Gradle проекта root Gradle.

2. Проект библиотеки Android

dependencies {
  compile 'com.example:foobarlib:2.1.0'
}

В этом втором случае вы зависите от artefact (т.е. архива в формате JAR или AAR), а не проекта. Это, по сути, черный ящик для вашего проекта Gradle. Все Gradle знает, что он содержит скомпилированные классы (и ресурсы в случае AAR), которые необходимы вашему проекту.

Если вы хотите внести изменения в библиотеку, сначала вам нужно найти соответствующий проект, чтобы отредактировать его источники, скомпилировать проект и опубликовать новый артефакт либо на локальном удаленном maven repository. Наконец, для вашего проекта, чтобы увидеть изменения, внесенные в этот другой проект, вам придется обновить номер версии, объявленный в зависимости, чтобы Gradle знал, что ему придется принести новый опубликованный артефакт.

Какой из них лучше?

Это зависит, конечно. Просто подумайте о том, есть ли у библиотеки смысл для нее быть самостоятельной или если она фактически является только модулем вашего приложения. Как вы видели, второй подход добавляет слишком много накладных расходов, если вы просто работаете над модулем своего приложения, и это также не имеет смысла для версии и распространяет эти изменения без остальной части приложения.

Ответ 8

Gradle зависимость - это избыток

Хорошо, если вы используете некоторую стабильную библиотеку или вы удовлетворены текущими функциями библиотеки. Также, когда библиотека имеет зависимости для обратного переноса или имеет набор функций или говорит классы, которые вам просто не нужны.

Решение возьмет то, что вам нужно от библиотеки, (только когда вы уверены, что этого будет достаточно)

И это не

Если вам нужны автоматические обновления и исправления в вашей библиотеке, легкость интеграции. Многие из библиотек создаются и поддерживаются каждый день, так что размер APK не имеет для нас большого значения, так как обновляется библиотека, поэтому импорт gradle хорош.

Обеспокоенность по размеру APK

A gradle зависимость может иметь много несвязанных вещей, назад поддержка, которую ваше приложение не требует, что в конечном итоге увеличивает размер приложения, также приведет к медленной компиляции тоже.

Итак, если в библиотеке есть один класс или меньше класса, вы можете напрямую добавить его в свое приложение в каком-то пакете. Хорошим примером будет приложение Google IO, в котором некоторые библиотеки находятся в другом пакете.

Вы также можете контролировать, что происходит для отладки или выпуска apk, для зависимостей отладки используйте debugCompile, для тестовых зависимостей используйте testCompile

Добавление библиотеки в зависимость от модуля

Добавление в качестве модуля библиотеки ускорит процесс сборки за счет времени загрузки, необходимого для получения зависимости, чего вы легко можете достичь с помощью Включить автономную синхронизацию для gradle в студии Android.

Также библиотечные модули - это путь, если вы создали некоторую личную библиотеку и используете ее во всех своих проектах, если это не так, вы будете иметь библиотеку, опубликованную и поддерживаемую на центральном уровне maven, и ее легче будет интегрировать в ваш собственный набор проектов через gradle.

Ответ 9

1. slow down compilation time at a noticeable rate?

Короткий ответ: Да.

Длинный ответ: В настоящее время мы используем Gradle в нашем проекте, и существует РАЗМЕЩЕННАЯ разница в compliteion, которое я испытал. Это особенно актуально, если у вас есть проект с несколькими модульными зависимостями. Кроме того, не говоря уже о том, что, если вы продолжаете добавлять множество зависимостей только для того, чтобы использовать кучу классов от каждого из них, вы в конечном итоге сталкиваетесь с очень известным:

Too many references: 66539 error; max is 65536.

Я сам испытал это несколько раз (Gradle и maven) при использовании библиотек, которые являются ресурсоемкими (например, play-services).

2. `increase the size of release-apk and debug-apk, as much as the size of the added dependency?`

Определенно. Не так много для release-apk, так как вы можете оптимизировать proguard во все, что вам нужно. В случае debug-apk я видел изменения размера до 5-6 МБ.

Только мои 2 цента. Надеюсь, это поможет.