Разница между androidx и com.android.support

Question

Я собирался использовать макет ограничения в своем проекте, когда заметил, что есть две разные зависимости, которые я могу использовать:

• com.android.support.constraint:constraint-layout
• androidx.constraintlayout:constraintlayout

Есть ли разница между этими двумя или некоторыми рекомендациями, которые предпочтительнее?

РЕДАКТИРОВАТЬ

Google прекращает поддержку com.android.support и предлагает пользователям перейти на новый androidx эквивалент.

Примечание: С выпуском Android 9.0 (уровень API 28) появилась новая версия библиотеки поддержки под названием AndroidX, которая является частью Jetpack.Библиотека AndroidX содержит существующую библиотеку поддержки, а также включает новейшие компоненты Jetpack.

Вы можете продолжать использовать библиотеку поддержки.Исторические артефакты (версии 27 и более ранние и упакованные как android.support. *) Останутся доступными в Google Maven.Тем не менее, все новые разработки библиотеки будут происходить в библиотеке AndroidX.

Мы рекомендуем использовать библиотеки AndroidX во всех новых проектах.Вам также следует подумать о переносе существующих проектов на AndroidX.

Вот официальное Руководство по миграции и соответствующие библиотеки эквивалентов.

Answer 1

Это может помочь,

Существует несколько различий в следующем:

1. При текущем соглашении об именах не ясно, какие пакеты связаны сОперационная система Android, которая поставляется вместе с APK (Android Package Kit) вашего приложения.Чтобы устранить эту путаницу, все разделенные библиотеки будут перемещены в пространство имен AndroidX androidx. *, А иерархия пакетов android. * Будет зарезервирована для пакетов, поставляемых с операционной системой Android.Например: android.content.Intent; зависит от ОС Android и androidx.fragment.app.Fragment; поставляется с APK

2. Первоначально имя каждого пакета указывало минимальный уровень API, поддерживаемый этим пакетом, напримерподдержка-v4.Однако версия 26.0.0 библиотеки поддержки увеличила минимальный API до 14, поэтому сегодня многие имена пакетов не имеют ничего общего с минимальным поддерживаемым уровнем API.Когда оба пакета support-v4 и support-v7 имеют минимальный API-интерфейс 14, легко понять, почему люди путаются !.Так что теперь с AndroidX нет никакой зависимости от уровня API.

3. Это просто расширение до 2-го пункта, еще одно важное изменение в том, что артефакты AndroidX будут обновляться независимо, так что вы будетевозможность обновлять отдельные библиотеки AndroidX в вашем проекте, вместо того, чтобы менять каждую зависимость сразу.Эти разочаровывающие сообщения « Все библиотеки com.android.support должны использовать точно такую ​​же версию спецификации », сообщения должны уйти в прошлое!

Answer 2

Одно из различий между библиотеками AndroidX и Support заключается в том, что при использовании библиотек поддержки все библиотеки поддержки должны иметь одинаковую версию, но в androidX такого нет.

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

Answer 3

Как сказано выше и в Миграция на AndroidX , вы можете легко мигрировать в AS:

С Android Studio 3.2 и выше вы можете быстро перенести существующий проект для использованияAndroidX, выбрав Refactor> Migrate to AndroidX в строке меню.

Относительно разницы (TLDR: нет искажений, выделение мое)

AndroidX отображает исходные пакеты API библиотеки поддержки в пространство имен androidx.Изменены только имена пакетов и артефактов Maven; имена классов, методов и полей не изменились .

Answer 4

Все библиотеки поддержки сбрасывают теги v4 v7 v12 v13 и т. Д., И все реорганизуется в пакеты androidx.

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

Канарская версия Android Studio 3.2, которая выйдет на этой неделе (14 мая 2018 года), должна иметь инструмент, позволяющий выполнять автоматический рефакторинг для пакетов androidx. Об этом было объявлено на Google I / O 2018.