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

сообщает @davidpbr ConstraintLayout производительность

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

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

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

устройства / Android версии воспроизводятся на: Samsung Галактика С6 (см-G920AКУПЛЕННЫЙ. К сожалению, не Нексус банкомат.) Android 5.0.2

сравнение быстрого метода трассировки:

образец репозитория Github:https://github.com/OnlyInAmerica/ConstraintLayoutPerf

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

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

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

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

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

5) обеспечивает силу автоматического ограничения применяясь при помощи голубой печати и визуального инструмента редактора который делает его легким конструировать страницу.

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

вот лучшее место, чтобы узнать быстро: https://codelabs.developers.google.com/codelabs/constraint-layout/#0

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

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

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

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

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

RelativeLayout и ConstraintLayout эквивалентных свойств:

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

• мера
• планировка
• ничья

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

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

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

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

ConstraintLayout выполняет около 40% лучше на этапе измерения / компоновки, чем RelativeLayout

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

подробнее:

https://constraintlayout.com/

https://android-developers.googleblog.com/2017/08/understanding-performance-benefits-of.html

https://medium.com/google-developers/building-interfaces-with-constraintlayout-3958fa38a9f7

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

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

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

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

Относительная Разметка

OnCreate: 123ms

последнее время preformDraw-время OnCreate: 311.3 ms

Ограничение Layout

OnCreate: 120.3 ms

последнее время preformDraw-время OnCreate: 310ms

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

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

стоит ли рефакторить старый вид переключиться на него с Уровень мельче или макет?

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

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

официально ConstraintLayout is быстрее

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

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

1) можно do UI design, не касаясь xml-части кода, честно говоря, я чувствую google скопировал, как пользовательский интерфейс разработан в приложениях iOS, это будет иметь смысл, если вы знакомы с разработкой пользовательского интерфейса в iOS, но в относительной компоновке его трудно установить ограничения, не касаясь xml-дизайна.

2) во-вторых он имеет иерархия плоского вида в отличие от других раскладов, так же лучшая производительность, чем относительная компоновка которые вы могли бы видеть из других ответов

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

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

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