Diferencias entre ConstraintLayout y RelativeLayout

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

La intención de 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 colocar una vista en términos de 0% y 100% de compensación horizontal y vertical con respecto a los controles (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 identificador de línea de base (tubería larga con esquinas redondeadas, debajo del identificador de círculo) se usa para alinear el contenido de la vista con otra referencia de vista.

Los tiradores cuadrados (en cada esquina de la vista) se utilizan para cambiar el tamaño de la vista en dps.

Esto se basa totalmente en opiniones y mi impresión de ConstraintLayout

Propiedades equivalentes de diseño relativo y diseño de restricción

(1) Diseño relativo:

android:layout_centerInParent="true"    

(1) Equivalente de diseño de restricción:

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) Equivalente de diseño de restricción:

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) Equivalente de diseño de restricción:

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

(4) Diseño relativo:

android:layout_alignParentLeft="true"   

(4) Equivalente de diseño de restricción:

app:layout_constraintLeft_toLeftOf="parent"

(5) Diseño relativo:

android:layout_alignParentStart="true"

(5) Equivalente de diseño de restricción:

app:layout_constraintStart_toStartOf="parent"

(6) Disposición relativa:

android:layout_alignParentRight="true"

(6) Equivalente de diseño de restricción:

app:layout_constraintRight_toRightOf="parent"

(7) Disposición relativa:

android:layout_alignParentEnd="true"    

(7) Equivalente de diseño de restricción:

app:layout_constraintEnd_toEndOf="parent"

(8) Diseño relativo:

android:layout_alignParentTop="true"

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

app:layout_constraintTop_toTopOf="parent"

(9) Disposición relativa:

android:layout_alignParentBottom="true" 

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

app:layout_constraintBottom_toBottomOf="parent"

(10) Diseño relativo:

android:layout_alignStart="@id/view"

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

app:layout_constraintStart_toStartOf="@id/view"

(11) Disposición relativa:

android:layout_alignLeft="@id/view" 

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

app:layout_constraintLeft_toLeftOf="@id/view"

(12) Disposición relativa:

android:layout_alignEnd="@id/view"  

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

app:layout_constraintEnd_toEndOf="@id/view"

(13) Disposición relativa:

android:layout_alignRight="@id/view"

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

app:layout_constraintRight_toRightOf="@id/view"

(14) Disposición relativa:

android:layout_alignTop="@id/view"  

(14) Equivalente de diseño de restricción:

app:layout_constraintTop_toTopOf="@id/view"

(15) Disposición relativa:

android:layout_alignBaseline="@id/view" 

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

app:layout_constraintBaseline_toBaselineOf="@id/view"

(16) Disposición relativa:

android:layout_alignBottom="@id/view"

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

app:layout_constraintBottom_toBottomOf="@id/view"

(17) Disposición relativa:

android:layout_toStartOf="@id/view"

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

app:layout_constraintEnd_toStartOf="@id/view"

(18) Disposición relativa:

android:layout_toLeftOf="@id/view"  

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

app:layout_constraintRight_toLeftOf="@id/view"

(19) Disposición relativa:

android:layout_toEndOf="@id/view"

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

app:layout_constraintStart_toEndOf="@id/view"

(20) Disposición relativa:

android:layout_toRightOf="@id/view"

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

app:layout_constraintLeft_toRightOf="@id/view"

(21) Disposición relativa:

android:layout_above="@id/view" 

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

app:layout_constraintBottom_toTopOf="@id/view"

(22) Disposición relativa:

android:layout_below="@id/view" 

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

app:layout_constraintTop_toBottomOf="@id/view"

Reportado por @davidpbr ConstraintLayout performance

Hice dos diseños similares de 7 niños, uno con un padre ConstraintLayouty un archivo RelativeLayout. Según la herramienta de seguimiento de métodos de Android Studio, parece que ConstraintLayoutpasa más tiempo en onMeasure y realiza trabajo adicional en onFinishInflate.

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

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

Dispositivos / Versiones de Android reproducidas en: Samsung Galaxy S6 (SM-G920A. Lo sentimos, no hay cajero automático 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 el poder dual tanto del diseño relativo como del diseño lineal: establezca las posiciones relativas de las vistas (como el diseño relativo) y también establezca pesos para la interfaz de usuario dinámica (que solo era posible en el diseño lineal).

2. Un uso muy poderoso es agrupar elementos formando una cadena. De esta manera 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. Se 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 Blue print y la herramienta Visual Editor, que facilita el diseño de una página.

Todas estas características conducen a un 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 se puede adaptar 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 romperá el diseño si tiene una cadena y desea que una vista desaparezca en el medio.

Además de la respuesta de @ dhaval-jivani.

Actualicé el proyecto del proyecto github a la última versión del diseño de restricciones 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 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 pantalla que se abre después del lanzamiento de la aplicación)

Disposición relativa

OnCreate: 123ms

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

Diseño de restricción

OnCreate: 120.3ms

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

Además de eso, verifiqué la prueba de rendimiento de este artículo , aquí el código y descubrí que en recuentos de bucles menos de 100, la variante de diseño de restricción es más rápida durante la ejecución de inflado, medición y diseño, luego 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 las vistas antiguas y 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ía ser seguro usarlo. pero, como ya he dicho, no migres simplemente por migrar. Solo hágalo si es necesario y se beneficia de ello. Sin embargo, para diseños nuevos, casi siempre uso ConstraintLayout. Es mucho mejor en comparación con lo que teníamos antes.

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 honesto, creo que Google ha copiado cómo se diseña la interfaz de usuario en las aplicaciones de iOS , tendrá sentido si está familiarizado con el desarrollo de la interfaz de usuario en iOS, pero en el diseño relativo es 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 del diseño relativo, como el posicionamiento relativo circular donde podemos colocar otra vista relativa a esta en cierto radio con cierto ángulo que no se puede hacer en el diseño relativo

Lo digo de nuevo, diseñar la interfaz de usuario utilizando el diseño de restricciones es lo mismo que diseñar la interfaz de usuario en iOS, por lo que en el futuro, si trabaja en iOS, le resultará más fácil si ha utilizado el diseño de restricciones

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 pregunta real que debemos hacernos 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, más flexibles, reaccionan mejor a los cambios, solucionan los problemas cuando los elementos desaparecen, se ajustan mejor a tipos de pantallas radicalmente diferentes y no usan un montón de bucles anidados con tanto tiempo. estructura de árbol dibujada para todo. Puedes poner cualquier cosa en cualquier lugar, con respecto a cualquier cosa, en cualquier lugar.

Eran un poco chiflados a mediados de 2016, cuando el editor de diseño visual simplemente no era lo suficientemente bueno, pero están al punto de que si tiene un diseño, es posible que desee considerar seriamente el uso de 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 veo la construcción de nada más en este momento. Si comenzaran con esto, no hubieran agregado nada más.

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, un movimiento más arriesgado es 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