Diferencias entre RestraintLayout y RelativeLayout


219

Estoy confundido acerca de la diferencia entre ConstraintLayouty RelativeLayout. ¿Podría alguien decirme las diferencias exactas entre ellos?


99
ConstraintLayout está diseñado principalmente para los nuevos programadores para que puedan diseñar fácilmente el diseño utilizando el Editor visual en lugar de crear el diseño con la mano a través de XML.
CopsOnRoad

1
@Jack definitivamente también tiene un propósito más profundo para los desarrolladores expertos experimentados
Moses Aprico

@MosesAprico tienes razón, tiene eso. Pero creo que los desarrolladores avezado experto ya tienen muchas otras maneras (que ya saben como RealtiveLayout, LinearLayout, GridLayoutetc.) para obtener la jerarquía de vistas que quieren.
CopsOnRoad

55
@CopsOnRoad En realidad estás equivocado. Apple ha estado haciendo diseños de restricción por más de 5 años. Obtiene un diseño receptivo a cualquier tamaño y no tiene que escribir una tonelada de diseños complejos. Cuando comienza a vincular varias vistas, solo necesita 3 controles básicos para crear un diseño totalmente receptivo.
Nick Turner

Respuestas:


145

La intención ConstraintLayoutes optimizar y aplanar la jerarquía de vistas de sus diseños aplicando algunas reglas a cada vista para evitar el anidamiento.

Las reglas le recuerdan RelativeLayout, por ejemplo, establecer la izquierda a la izquierda de alguna otra vista.

app:layout_constraintBottom_toBottomOf="@+id/view1"

A diferencia RelativeLayout, ConstraintLayoutofrece un biasvalor que se utiliza para posicionar una vista en términos de 0% y 100% de desplazamiento horizontal y vertical en relación con los controladores (marcados con un círculo). Estos porcentajes (y fracciones) ofrecen un posicionamiento perfecto de la vista en diferentes densidades y tamaños de pantalla.

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

El controlador de línea de base (tubo largo con esquinas redondeadas, debajo del controlador de círculo) se usa para alinear el contenido de la vista con otra referencia de vista.

Las manijas cuadradas (en cada esquina de la vista) se utilizan para cambiar el tamaño de la vista en dps.

ingrese la descripción de la imagen aquí

Esto está totalmente basado en la opinión y mi impresión de ConstraintLayout


99
Todavía podemos crear un diseño plano usando RelativeLayout, ¿por eso estoy confundido cuando ConstraintLayout se cuida donde RelativeLayout no puede?

77
RelativeLayout es un diseño de dos pasos, que sufre de doble imposición. Debe medir / diseñar al menos dos veces. ConstraintLayout no sufre esta penalización de rendimiento.
Christopher Perry

55
@ Nada, aún podemos crear un diseño plano con RelativeLayout. Pero además de todos los mencionados aquí, ConstraintLayout le permite usar márgenes negativos y subvistas de tamaño en una relación predefinida . La última es la forma más sólida de mantener una relación de 16: 9 para su ImageView en CardView de acuerdo con el diseño del material
Eugene Brusov

44
Hay algunos diseños que son imposibles en RelativeLayout a menos que anide un LinearLayout u otro RelativeLayout. Por ejemplo: centrar una "pila" de 3 Vistas verticalmente en relación con otra Vista
Gak2

@ Gak2 No puedo ver nada imposible en su ejemplo sin un diseño anidado. Tal vez te refieres a algo más con "apilar" que yo. Solo uso "layout_alignEnd", "layout_below", "layout _..." y puedo construir cualquier tipo de pila con él ...
El increíble

81

Diseño relativo y propiedades equivalentes de diseño de restricción

Diseño relativo y propiedades equivalentes de diseño de restricción

(1) Diseño relativo:

android:layout_centerInParent="true"    

(1) Diseño de restricción equivalente:

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) Diseño relativo:

android:layout_centerHorizontal="true"

(2) Diseño de restricción equivalente:

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

(3) Diseño relativo:

android:layout_centerVertical="true"    

(3) Diseño de restricción equivalente:

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

(4) Diseño relativo:

android:layout_alignParentLeft="true"   

(4) Diseño de restricción equivalente:

app:layout_constraintLeft_toLeftOf="parent"

(5) Diseño relativo:

android:layout_alignParentStart="true"

(5) Diseño de restricción equivalente:

app:layout_constraintStart_toStartOf="parent"

(6) Diseño relativo:

android:layout_alignParentRight="true"

(6) Diseño de restricción equivalente:

app:layout_constraintRight_toRightOf="parent"

(7) Diseño relativo:

android:layout_alignParentEnd="true"    

(7) Diseño de restricción equivalente:

app:layout_constraintEnd_toEndOf="parent"

(8) Diseño relativo:

android:layout_alignParentTop="true"

(8) Equivalente en el diseño de restricción:

app:layout_constraintTop_toTopOf="parent"

(9) Diseño relativo:

android:layout_alignParentBottom="true" 

(9) Equivalente en el diseño de restricción:

app:layout_constraintBottom_toBottomOf="parent"

(10) Diseño relativo:

android:layout_alignStart="@id/view"

(10) Equivalente en el diseño de restricción:

app:layout_constraintStart_toStartOf="@id/view"

(11) Diseño relativo:

android:layout_alignLeft="@id/view" 

(11) Equivalente en el diseño de restricción:

app:layout_constraintLeft_toLeftOf="@id/view"

(12) Diseño relativo:

android:layout_alignEnd="@id/view"  

(12) Equivalente en el diseño de restricción:

app:layout_constraintEnd_toEndOf="@id/view"

(13) Diseño relativo:

android:layout_alignRight="@id/view"

(13) Equivalente en el diseño de restricción:

app:layout_constraintRight_toRightOf="@id/view"

(14) Diseño relativo:

android:layout_alignTop="@id/view"  

(14) Diseño de restricción equivalente:

app:layout_constraintTop_toTopOf="@id/view"

(15) Diseño relativo:

android:layout_alignBaseline="@id/view" 

(15) Equivalente en el diseño de restricción:

app:layout_constraintBaseline_toBaselineOf="@id/view"

(16) Diseño relativo:

android:layout_alignBottom="@id/view"

(16) Equivalente en el diseño de restricción:

app:layout_constraintBottom_toBottomOf="@id/view"

(17) Diseño relativo:

android:layout_toStartOf="@id/view"

(17) Equivalente en el diseño de restricción:

app:layout_constraintEnd_toStartOf="@id/view"

(18) Diseño relativo:

android:layout_toLeftOf="@id/view"  

(18) Equivalente en el diseño de restricción:

app:layout_constraintRight_toLeftOf="@id/view"

(19) Diseño relativo:

android:layout_toEndOf="@id/view"

(19) Equivalente en el diseño de restricción:

app:layout_constraintStart_toEndOf="@id/view"

(20) Diseño relativo:

android:layout_toRightOf="@id/view"

(20) Equivalente en el diseño de restricción:

app:layout_constraintLeft_toRightOf="@id/view"

(21) Diseño relativo:

android:layout_above="@id/view" 

(21) Equivalente en el diseño de restricción:

app:layout_constraintBottom_toTopOf="@id/view"

(22) Diseño relativo:

android:layout_below="@id/view" 

(22) Equivalente en el diseño de restricción:

app:layout_constraintTop_toBottomOf="@id/view"


2
¿Se puede publicar como texto en lugar de imagen? Para que sea muy útil para mí y también para otros en el futuro.
Nuevo desarrollador

3
Todos los que comienzan a aprender Diseños de restricciones deben ver esto. Gracias.
grantespo

1
Esta es información útil, pero es simplemente un volcado de documentación y no hace nada para explicar la diferencia entre ellos.
YetAnotherRandomUser

1
No, no tengo tiempo para buscar documentos, esto es ciertamente útil. Y escrito en lenguaje simple. Votación a favor.
CodeToLife

46

Reportado por @davidpbr ConstraintLayout performance

Hice dos diseños similares de 7 hijos, uno con un padre ConstraintLayouty otro RelativeLayout. Basado en la herramienta de rastreo de métodos de Android Studio, parece que ConstraintLayoutpasa más tiempo en onMeasure y realiza trabajo adicional enonFinishInflate .

Biblioteca utilizada ( support-v4, appcompat-v7...):

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

Dispositivos / versiones de Android reproducidos en: Samsung Galaxy S6 (SM-G920A. Lo sentimos, no hay cajeros automáticos Nexus). Android 5.0.2

Comparación de rastreo de método rápido:

1

Ejemplo de repositorio de Github: https://github.com/OnlyInAmerica/ConstraintLayoutPerf


por el mismo problema: voy a cerrar esto por ahora: alpha 4/5 trajo una mejora considerable en el rendimiento. Probablemente podremos mejorarlo más, pero eso podría esperar después de la 1.0.
Oleksandr el

¿Puede explicar en qué herramienta utilizó para crear esta gran comparación?
Nativ

2
@Nativ Monotirs-> CPU-> Icono del rastreador de tiempo
Andrey T

18
Ejecute y perfile el mismo código con restricción-diseño: 1.0.1 en Nexus 5 con android 6.0.1, aquí resulta: Diseño relativo - init 2ms en Measure 30ms + 16ms = 62ms en Layouyt 7ms = 9ms total 54 ms Diseño de restricción - init El diseño de restricción de 7 ms genera parámetros de diseño + agrega vista ~ 7 * 2 ms = 14 ms en medida 60 ms + 52 ms ~ 112 ms en diseño 8 ms en total ~ 141 ms Primera inicialización del diseño relativo casi tres veces más rápido que la restricción.
Andrey T

2
Se presenta el diseño de restricción para que se pueda reducir la jerarquía de vista anidada. Por lo tanto, Menos jerarquía significa menos tiempo para recorrer de arriba hacia abajo en el árbol de vistas. Entonces, ¿cuál es el punto para hacer una jerarquía de vista anidada que puede no ser necesaria en el diseño de restricción y compararla con el diseño relativo en el que tiene más posibilidades de terminar con una estructura anidada?
codepeaker

27

Las siguientes son las diferencias / ventajas:

  1. El diseño de restricción tiene doble poder tanto en el diseño relativo como en el diseño lineal: establezca las posiciones relativas de las vistas (como el diseño relativo) y también los pesos para la IU dinámica (que solo era posible en el diseño lineal).

  2. Un uso muy poderoso es la agrupación de elementos formando una cadena. De esta forma, podemos formar un grupo de vistas que, en su conjunto, se pueden colocar de la manera deseada sin agregar otra capa de jerarquía solo para formar otro grupo de vistas.

  3. Además de los pesos, podemos aplicar un sesgo horizontal y vertical que no es más que el porcentaje de desplazamiento desde el centro. (sesgo de 0.5 significa alineado centralmente. Cualquier valor menor o mayor significa movimiento correspondiente en la dirección respectiva).

  4. Otra característica muy importante es que respeta y proporciona la funcionalidad para manejar las vistas GONE para que los diseños no se rompan si alguna vista se establece en GONE a través del código java. Puede encontrar más aquí: https://developer.android.com/reference/android/support/constraint/ConstraintLayout.html#VisibilityBehavior

  5. Proporciona el poder de la aplicación automática de restricciones mediante el uso de la herramienta Blue print y Visual Editor que facilita el diseño de una página.

Todas estas características conducen al aplanamiento de la jerarquía de vistas, lo que mejora el rendimiento y también ayuda a crear una interfaz de usuario dinámica y receptiva que puede adaptarse más fácilmente a diferentes tamaños y densidades de pantalla.

Este es el mejor lugar para aprender rápidamente: https://codelabs.developers.google.com/codelabs/constraint-layout/#0


6) ConstraintLayout permite dimensionar subvistas en proporciones predefinidas medium.com/google-developers/… . Sería útil, por ejemplo, cuando va a mantener su ImageView en 16: 9.
Eugene Brusov

15

Una gran diferencia es que ConstraintLayout respeta las restricciones incluso si la vista se ha ido. Por lo tanto, no se romperá el diseño si tiene una cadena y desea hacer que una vista desaparezca en el medio.


¿me puede dar algún ejemplo? supongamos que hay 3 botones allí. Ocultaré el segundo botón y el tercer botón está conectado al segundo botón con la identificación como btn2. Supongamos que oculto el segundo botón y luego cómo el tercer botón podría encontrar la identificación del segundo botón.

1
Eso no es cierto. Si configura la visibilidad de un botón como "INVISIBLE" en lugar de "GONE", no romperá las restricciones. En cuanto a mí, la mayor diferencia como dijo @Nikola es el sesgo que te ayuda a crear más vistas "receptivas".
zapotec

@ Nada Supongamos que los botones están uno debajo del otro. Incluso si oculta tButton 2, todavía está allí en el "ver contrato", ya sea en su código XML o. RestraintLayout lo respetará y el botón 3 estará debajo del botón 1. En un RelativeLayout, el botón 2 desaparecerá, la contracción desaparecerá, por lo que el botón 3 estará en la posición predeterminada, por lo que estará en la parte superior izquierda de la pantalla.
Herrbert74

@zapotec Respeto que otras cosas son más importantes para ti, pero para mí esta es una diferencia realmente genial. Soluciona lo único que odiaba en RelativeLayout. Usar invisible no es una opción, porque reclamará el espacio.
Herrbert74

7

Además de la respuesta @ dhaval-jivani.

He actualizado el proyecto github proyecto a la última versión del diseño de restricción v.1.1.0-beta3

He medido y comparado el tiempo del método onCreate y el tiempo entre el inicio de onCreate y el final de la ejecución del último método preformDraw que es visible en el monitor de la CPU. Todas las pruebas se realizaron en Samsung S5 mini con Android 6.0.1 Aquí los resultados:

Nuevo comienzo (primera apertura de pantalla después del inicio de la aplicación)

Disposición relativa

OnCreate: 123ms

Última preforma Tiempo de dibujo - Tiempo de creación: 311,3 ms

Diseño de restricción

OnCreate: 120.3ms

Última preforma Tiempo de dibujo - Tiempo de creación: 310 ms

Además de eso, he comprobado la prueba de rendimiento de este artículo , aquí el código y descubrí que en el bucle cuenta menos de 100, la variante de diseño de restricción es más rápida durante la ejecución de inflar, medir y diseñar, luego las variantes con Diseño relativo. Y en dispositivos Android antiguos, como Samsung S3 con Android 4.3, la diferencia es mayor.

Como conclusión, estoy de acuerdo con los comentarios del artículo :

¿Vale la pena refactorizar vistas antiguas para activarlo desde RelativeLayout o LinearLayout?

Como siempre: depende 🙂

No refactorizaría nada a menos que tenga un problema de rendimiento con su jerarquía de diseño actual o quiera realizar cambios significativos en el diseño de todos modos. Aunque no lo he medido últimamente, no he encontrado ningún problema de rendimiento en las últimas versiones. Así que creo que deberías estar seguro de usarlo. pero, como he dicho, no solo migre por migrar. Solo hazlo, si es necesario y se beneficia de ello. Sin embargo, para los diseños nuevos, casi siempre uso ConstraintLayout. Es mucho mejor en comparación con lo que teníamos antes.


6

Oficialmente, ConstraintLayoutes mucho más rápido

En la versión N de Android, la ConstraintLayoutclase proporciona una funcionalidad similar RelativeLayout, pero a un costo significativamente menor.


6

La verdadera pregunta es: ¿hay alguna razón para usar un diseño que no sea un diseño de restricción? Creo que la respuesta podría ser no.

Para aquellos que insisten en que están dirigidos a programadores novatos o similares, deben proporcionar alguna razón para que sean inferiores a cualquier otro diseño.

Los diseños de restricciones son mejores en todos los sentidos (cuestan como 150k en tamaño APK). Son más rápidos, más fáciles, son más flexibles, reaccionan mejor a los cambios, solucionan los problemas cuando los elementos desaparecen, se adaptan mejor a tipos de pantalla radicalmente diferentes y no usan un montón de bucles anidados con ese tiempo dibuja la estructura de árbol para todo. Puede poner cualquier cosa en cualquier lugar, con respecto a cualquier cosa, en cualquier lugar.

Fueron un poco complicados a mediados de 2016, donde el editor de diseño visual simplemente no era lo suficientemente bueno, pero hasta el punto de que si tiene un diseño, es posible que desee considerar seriamente usar un diseño de restricción, incluso cuando hace lo mismo que un RelativeLayout, o incluso un simple LinearLayout. FrameLayoutsclaramente todavía tienen su propósito. Pero, no puedo ver construir nada más en este momento. Si comenzaran con esto, no habrían agregado nada más.


1
¿Hay alguna prueba de que sea más rápido?
Rajesh Nasit

1
Si. Es mas rapido. El diseño está abajo en un único solucionador en lugar de iterar a través de un árbol. Para la mayoría de las cosas no importará porque se hace en la llamada al diseño. Pero, lo del árbol de vistas, aunque es fácil, crea un montón de vistas dentro de vistas que requieren llamadas que requieren llamadas. Si bien en teoría es más agradable, en la práctica, realizar el diseño en un bit de código es mucho más fácil que recorrer todo el árbol de vistas. Sería más impresionante con más vistas, pero aquí hay un punto de referencia de mayo: medium.com/@krpiotrek/constraintlayout-performance-c1455c7984d7
Tatarize

Me enfrento a otra pregunta, ¿debo reemplazar todos los Relativelayouts existentes en la aplicación en la que estoy trabajando? ¿Mejorará significativamente el rendimiento?
Sreekanth Karumanaghat

@SreekanthKarumanaghat parece que nunca recuperarías el tiempo que lleva reemplazarlos en el cambio de tiempo que te ahorraría. Estamos hablando de ciclos de 3,5 ms que caen a 3,25 ms en la mayoría de los casos. Si te da una característica adicional o algo que necesitas, entonces seguro, pero solo por motivos de velocidad, no. Aunque estamos hablando de presionar un botón de conversión.
Tatarize

5

La conclusión que puedo hacer es

1) Podemos hacer el diseño de la interfaz de usuario sin tocar la parte xml del código, para ser sincero, creo que Google ha copiado la forma en que la interfaz de usuario está diseñada en las aplicaciones de iOS , tendrá sentido si está familiarizado con el desarrollo de la interfaz de usuario en iOS, pero en un diseño relativo es difícil establecer las restricciones sin tocar el diseño xml .

2) En segundo lugar, tiene una jerarquía de vista plana a diferencia de otros diseños, por lo que tiene un mejor rendimiento que el diseño relativo que podría haber visto en otras respuestas

3) También tiene cosas adicionales aparte de lo que tiene el diseño relativo, como el posicionamiento relativo circular donde podemos colocar otra vista relativa a esta en cierto radio con cierto ángulo que no puede hacer en el diseño relativo

Lo digo nuevamente, el diseño de la interfaz de usuario utilizando el diseño de restricción es lo mismo que el diseño de la interfaz de usuario en iOS, por lo que en el futuro, si trabaja en iOS, será más fácil si ha utilizado el diseño de restricción


1

La única diferencia que he notado es que las cosas configuradas en un diseño relativo mediante arrastrar y soltar automáticamente tienen sus dimensiones relativas a otros elementos inferidos, por lo que cuando ejecuta la aplicación, lo que ve es lo que obtiene. Sin embargo, en el diseño de restricción, incluso si arrastra y suelta un elemento en la vista de diseño, cuando ejecuta la aplicación, las cosas pueden cambiar. Esto se puede solucionar fácilmente configurando manualmente las restricciones o, haciendo un movimiento más arriesgado, hacer clic derecho en el elemento en el árbol de componentes, seleccionar el submenú de diseño de restricciones y luego hacer clic en 'inferir restricciones'. Espero que esto ayude

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.