Различия между ConstraintLayout и RelativeLayout

Ответ 1

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

Правила напоминают вам о RelativeLayout, например, устанавливая левую часть слева от другого представления.

app:layout_constraintBottom_toBottomOf="@+id/view1"

В отличие от RelativeLayout, ConstraintLayout предлагает значение bias, которое используется для позиционирования представления с точки зрения 0% и 100% горизонтального и вертикального смещения относительно ручек (помеченных кружком). Эти проценты (и фракции) предлагают бесшовное позиционирование вида по разным размерам экрана и размерам.

app:layout_constraintHorizontal_bias="0.33" <!-- from 0.0 to 1.0 -->
app:layout_constraintVertical_bias="0.53" <!-- from 0.0 to 1.0 -->

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

Квадратные ручки (в каждом углу представления) используются для изменения размера представления в формате dps.

Это полностью основанное мнение, и мое впечатление от ConstraintLayout

Ответ 2

Об этом сообщает @davidpbr ConstraintLayout performance

Я сделал два одинаковых 7-дочерних макета, по одному с родительским ConstraintLayout и RelativeLayout. Основанный на инструменте трассировки методов Android Studio, кажется, ConstraintLayout проводит больше времени в onMeasure и выполняет дополнительную работу в onFinishInflate.

Используемая библиотека (support-v4, appcompat-v7 …):

com.android.support.constraint:constraint-layout:1.0.0-alpha1

Версии устройств /Android воспроизводятся на: Samsung Galaxy S6 (SM-G920A. Извините, но нет Nexus Atm). Android 5.0.2

Быстрое сравнение методов отслеживания:

Пример репозитория Github: https://github.com/OnlyInAmerica/ConstraintLayoutPerf

Ответ 3

Эквивалентные свойства относительного макета и макета ограничения

(1) Относительная компоновка:

android:layout_centerInParent="true"    

(1) Эквивалент макета ограничения:

app:layout_constraintBottom_toBottomOf="parent"
app:layout_constraintLeft_toLeftOf="parent"
app:layout_constraintStart_toStartOf="parent"
app:layout_constraintRight_toRightOf="parent"
app:layout_constraintEnd_toEndOf="parent"
app:layout_constraintTop_toTopOf="parent"

(2) Относительная компоновка:

android:layout_centerHorizontal="true"

(2) Эквивалент макета ограничения:

app:layout_constraintLeft_toLeftOf="parent"
app:layout_constraintStart_toStartOf="parent"
app:layout_constraintRight_toRightOf="parent"
app:layout_constraintEnd_toEndOf="parent"

(3) Относительная компоновка:

android:layout_centerVertical="true"    

(3) Эквивалент макета ограничения:

app:layout_constraintBottom_toBottomOf="parent"
app:layout_constraintTop_toTopOf="parent"

(4) Относительная компоновка:

android:layout_alignParentLeft="true"   

(4) Эквивалент макета ограничения:

app:layout_constraintLeft_toLeftOf="parent"

(5) Относительная компоновка:

android:layout_alignParentStart="true"

(5) Эквивалент макета ограничения:

app:layout_constraintStart_toStartOf="parent"

(6) Относительная компоновка:

android:layout_alignParentRight="true"

(6) Эквивалент макета ограничения:

app:layout_constraintRight_toRightOf="parent"

(7) Относительная компоновка:

android:layout_alignParentEnd="true"    

(7) Эквивалент макета ограничения:

app:layout_constraintEnd_toEndOf="parent"

(8) Относительная компоновка:

android:layout_alignParentTop="true"

(8) Эквивалент макета ограничения:

app:layout_constraintTop_toTopOf="parent"

(9) Относительная компоновка:

android:layout_alignParentBottom="true" 

(9) Эквивалент макета ограничения:

app:layout_constraintBottom_toBottomOf="parent"

(10) Относительная компоновка:

android:layout_alignStart="@id/view"

(10) Эквивалент макета ограничения:

app:layout_constraintStart_toStartOf="@id/view"

(11) Относительная компоновка:

android:layout_alignLeft="@id/view" 

(11) Эквивалент макета ограничения:

app:layout_constraintLeft_toLeftOf="@id/view"

(12) Относительная компоновка:

android:layout_alignEnd="@id/view"  

(12) Эквивалент макета ограничения:

app:layout_constraintEnd_toEndOf="@id/view"

(13) Относительная компоновка:

android:layout_alignRight="@id/view"

(13) Эквивалент макета ограничения:

app:layout_constraintRight_toRightOf="@id/view"

(14) Относительная компоновка:

android:layout_alignTop="@id/view"  

(14) Эквивалент макета ограничения:

app:layout_constraintTop_toTopOf="@id/view"

(15) Относительная компоновка:

android:layout_alignBaseline="@id/view" 

(15) Эквивалент макета ограничения:

app:layout_constraintBaseline_toBaselineOf="@id/view"

(16) Относительная компоновка:

android:layout_alignBottom="@id/view"

(16) Эквивалент макета ограничения:

app:layout_constraintBottom_toBottomOf="@id/view"

(17) Относительная компоновка:

android:layout_toStartOf="@id/view"

(17) Эквивалент макета ограничения:

app:layout_constraintEnd_toStartOf="@id/view"

(18) Относительная компоновка:

android:layout_toLeftOf="@id/view"  

(18) Эквивалент макета ограничения:

app:layout_constraintRight_toLeftOf="@id/view"

(19) Относительная компоновка:

android:layout_toEndOf="@id/view"

(19) Эквивалент макета ограничения:

app:layout_constraintStart_toEndOf="@id/view"

(20) Относительная компоновка:

android:layout_toRightOf="@id/view"

(20) Эквивалент макета ограничения:

app:layout_constraintLeft_toRightOf="@id/view"

(21) Относительная компоновка:

android:layout_above="@id/view" 

(21) Эквивалент макета ограничения:

app:layout_constraintBottom_toTopOf="@id/view"

(22) Относительная компоновка:

android:layout_below="@id/view" 

(22) Эквивалент макета ограничения:

app:layout_constraintTop_toBottomOf="@id/view"

Ответ 4

Ниже приведены различия/преимущества:

1) Макет Constraint имеет двойную мощность как относительной компоновки, так и линейного макета: задайте относительные позиции просмотров (например, относительную компоновку), а также установите весы для динамического интерфейса (что было возможно только в линейной компоновке).

2) Очень мощное использование - группировка элементов путем формирования цепочки. Таким образом, мы можем сформировать группу представлений, которые в целом могут быть размещены желаемым образом без добавления другого уровня иерархии только для формирования другой группы представлений.

3) В дополнение к весам мы можем применять горизонтальное и вертикальное смещение, которое представляет собой не что иное, как процент перемещения из центра. (смещение 0,5 означает централизованное выравнивание. Любое значение меньше или больше означает соответствующее движение в соответствующем направлении).

4) Еще одна очень важная особенность заключается в том, что она уважает и предоставляет функциональные возможности для обработки представлений GONE, так что макеты не разбиваются, если какое-либо представление установлено в GONE через java-код. Подробнее можно найти здесь: https://developer.android.com/reference/android/support/constraint/ConstraintLayout.html#VisibilityBehavior

5) Обеспечивает автоматическое ограничение, применяемое с помощью инструмента Blue print и Visual Editor, что упрощает разработку страницы.

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

Вот лучшее место для быстрого изучения: https://codelabs.developers.google.com/codelabs/constraint-layout/#0

Ответ 5

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

Ответ 6

Процесс рисования Android View состоит из 3 этапов. Вы можете найти соответствующие методы, когда расширяет ViewGroup

1. Мера
2. раскладка
3. Рисовать

Используя инструмент Systrace, мы можем рассчитать measure/layout

Systrace для варианта макета, который использует RelativeLayout:

Systrace для варианта макета, который использует ConstraintLayout:

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

ConstraintLayout работает примерно на 40% лучше в фазе measure/layout чем RelativeLayout

И последнее, но не менее важное: ConstraintLayout - это современный способ создания ответственного пользовательского интерфейса, он постоянно развивается, и каждый выпуск предоставляет интересные функции, которые делают жизнь проще. Последняя версия - Constraint Layout 1.1

Пожалуйста, прочитайте больше здесь, здесь, здесь

Ответ 7

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

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

Макеты ограничений лучше во всех отношениях (они стоят около 150 КБ в размере APK). Они быстрее, они проще, они более гибкие, они лучше реагируют на изменения, они решают проблемы, когда элементы уходят, они лучше соответствуют радикально различным типам экранов и не используют кучу вложенных циклов с такой длинной нарисовал древовидную структуру для всего. Вы можете поместить что угодно где угодно, относительно чего угодно, где угодно.

Они были немного сумасшедшими в середине 2016 года, когда визуальный редактор макетов просто не был достаточно хорош, но они настолько важны, что, если у вас вообще есть макет, вы можете серьезно подумать об использовании макета ограничений, даже когда он делает то же самое, что и RelativeLayout, или даже простой LinearLayout. FrameLayouts явно все еще имеет свое назначение. Но я не могу строить что-либо еще в этой точке. Если бы они начали с этого, они бы ничего не добавили.

Ответ 8

В дополнение к ответу @dhaval-jivani.

Я обновил проект github до последней версии макета ограничений v.1.1.0-beta3

Я измерил и сравнил время метода и времени onCreate между началом onCreate и окончанием выполнения последнего метода preformDraw, который отображается на мониторе CPU. Все тесты были выполнены на Samsung S5 mini с Android 6.0.1 Здесь результаты:

Свежий старт (открытие первого экрана после запуска приложения)

Относительная компоновка

OnCreate: 123ms

Last preformDraw time - OnCreate time: 311.3ms

Макет ограничений

OnCreate: 120.3ms

Последнее время предварительной обработки - Время включения: 310 мс

Кроме того, я проверил тест производительности из этой статьи , здесь код и обнаружил, что при подсчете циклов менее 100 вариантов компоновки ограничений быстрее во время раздувания, измерения и макета, а затем вариантов с относительной компоновкой. И на старых устройствах Android, таких как Samsung S3 с Android 4.3, разница больше.

В качестве заключения я согласен с комментариями статьи :

Стоит ли реорганизовать старый просмотр на него из RelativeLayout или LinearLayout?

Как всегда: зависит от 🙂

Я бы не реорганизовал что-либо, если у вас нет проблемы с производительностью с вашей текущей иерархией раскладки, или вы все равно хотите внести существенные изменения в макет. Хотя в последнее время я не оценил это, я не нашел никаких проблем с производительностью в последних выпусках. Поэтому я думаю, вы должны быть в безопасности, чтобы использовать его. но, как сказал Iv, не просто мигрировать ради миграции. Только делайте это, если это необходимо и выгодно для него. Однако для новых макетов я почти всегда использую ConstraintLayout. Его гораздо лучше сравнить с тем, что мы имели раньше.

Ответ 9

Официально ConstraintLayout намного быстрее

В N-версии Android класс ConstraintLayout обеспечивает функциональность, аналогичную RelativeLayout, но при значительно более низкой стоимости.

Ответ 10

Вывод, который я могу сделать,

1) Мы можем сделать дизайн пользовательского интерфейса, не касаясь XML-части кода, если честно, я чувствую, что Google скопировал дизайн пользовательского интерфейса в приложениях для iOS, это будет иметь смысл, если вы знакомы с разработкой пользовательского интерфейса в iOS, но в относительной компоновке это Трудно установить ограничения, не касаясь дизайна XML.

2) Во-вторых, он имеет плоскую иерархию представлений в отличие от других макетов, поэтому имеет лучшую производительность, чем относительный макет, который вы могли видеть из других ответов.

3) У него также есть дополнительные вещи помимо того, что имеет относительное расположение, такое как круговое относительное расположение, где мы можем расположить другое представление относительно этого на определенном радиусе с определенным углом, который не может сделать в относительном расположении

Я повторю еще раз: разработка пользовательского интерфейса с использованием макета ограничений аналогична разработке пользовательского интерфейса в iOS, поэтому в будущем, если вы будете работать на iOS, вам будет проще, если вы использовали макет ограничений

Ответ 11

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