Diferencias entre RestraintLayout y RelativeLayout

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

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.

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

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"

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:

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

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

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.

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.

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.

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.

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

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