Différences entre ConstraintLayout et RelativeLayout

Je suis confus quant à la différence entre ConstraintLayoutet RelativeLayout. Quelqu'un pourrait-il me dire les différences exactes entre eux?

L'intention ConstraintLayoutest d'optimiser et d'aplatir la hiérarchie des vues de vos présentations en appliquant certaines règles à chaque vue pour éviter l'imbrication.

Les règles vous rappellent RelativeLayout, par exemple, le réglage de la gauche vers la gauche d'une autre vue.

app:layout_constraintBottom_toBottomOf="@+id/view1"

Contrairement à RelativeLayout, ConstraintLayoutoffre une biasvaleur qui est utilisée pour positionner une vue en termes de décalage horizontal et vertical de 0% et 100% par rapport aux poignées (marquées d'un cercle). Ces pourcentages (et fractions) offrent un positionnement transparent de la vue sur différentes densités et tailles d'écran.

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

La poignée de ligne de base (long tuyau aux coins arrondis, sous la poignée circulaire) est utilisée pour aligner le contenu de la vue avec une autre référence de vue.

Des poignées carrées (à chaque coin de la vue) sont utilisées pour redimensionner la vue en dps.

C'est totalement basé sur l'opinion et mon impression de ConstraintLayout

Propriétés équivalentes de disposition relative et de disposition de contrainte

(1) Disposition relative:

android:layout_centerInParent="true"    

(1) Équivalent de la disposition des contraintes:

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) Disposition relative:

android:layout_centerHorizontal="true"

(2) Équivalent de la disposition des contraintes:

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

(3) Disposition relative:

android:layout_centerVertical="true"    

(3) Équivalent de disposition de contrainte:

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

(4) Disposition relative:

android:layout_alignParentLeft="true"   

(4) Équivalent de la disposition des contraintes:

app:layout_constraintLeft_toLeftOf="parent"

(5) Disposition relative:

android:layout_alignParentStart="true"

(5) Équivalent de disposition de contrainte:

app:layout_constraintStart_toStartOf="parent"

(6) Disposition relative:

android:layout_alignParentRight="true"

(6) Équivalent de la disposition des contraintes:

app:layout_constraintRight_toRightOf="parent"

(7) Disposition relative:

android:layout_alignParentEnd="true"    

(7) Équivalent de la disposition des contraintes:

app:layout_constraintEnd_toEndOf="parent"

(8) Disposition relative:

android:layout_alignParentTop="true"

(8) Équivalent de la disposition des contraintes:

app:layout_constraintTop_toTopOf="parent"

(9) Disposition relative:

android:layout_alignParentBottom="true" 

(9) Équivalent de la disposition des contraintes:

app:layout_constraintBottom_toBottomOf="parent"

(10) Disposition relative:

android:layout_alignStart="@id/view"

(10) Équivalent de la disposition des contraintes:

app:layout_constraintStart_toStartOf="@id/view"

(11) Disposition relative:

android:layout_alignLeft="@id/view" 

(11) Équivalent de la disposition des contraintes:

app:layout_constraintLeft_toLeftOf="@id/view"

(12) Disposition relative:

android:layout_alignEnd="@id/view"  

(12) Équivalent de la disposition des contraintes:

app:layout_constraintEnd_toEndOf="@id/view"

(13) Disposition relative:

android:layout_alignRight="@id/view"

(13) Équivalent de la disposition des contraintes:

app:layout_constraintRight_toRightOf="@id/view"

(14) Disposition relative:

android:layout_alignTop="@id/view"  

(14) Équivalent de la disposition des contraintes:

app:layout_constraintTop_toTopOf="@id/view"

(15) Disposition relative:

android:layout_alignBaseline="@id/view" 

(15) Équivalent de la disposition des contraintes:

app:layout_constraintBaseline_toBaselineOf="@id/view"

(16) Disposition relative:

android:layout_alignBottom="@id/view"

(16) Équivalent de la disposition des contraintes:

app:layout_constraintBottom_toBottomOf="@id/view"

(17) Disposition relative:

android:layout_toStartOf="@id/view"

(17) Équivalent de disposition de contrainte:

app:layout_constraintEnd_toStartOf="@id/view"

(18) Disposition relative:

android:layout_toLeftOf="@id/view"  

(18) Équivalent de la disposition des contraintes:

app:layout_constraintRight_toLeftOf="@id/view"

(19) Disposition relative:

android:layout_toEndOf="@id/view"

(19) Équivalent de la disposition des contraintes:

app:layout_constraintStart_toEndOf="@id/view"

(20) Disposition relative:

android:layout_toRightOf="@id/view"

(20) Équivalent de la disposition des contraintes:

app:layout_constraintLeft_toRightOf="@id/view"

(21) Disposition relative:

android:layout_above="@id/view" 

(21) Équivalent de la disposition des contraintes:

app:layout_constraintBottom_toTopOf="@id/view"

(22) Disposition relative:

android:layout_below="@id/view" 

(22) Équivalent de la disposition des contraintes:

app:layout_constraintTop_toBottomOf="@id/view"

Rapporté par @davidpbr ConstraintLayout performance

J'ai fait deux dispositions similaires pour 7 enfants, chacune avec un parent ConstraintLayoutet RelativeLayout. Basé sur l'outil de traçage de méthode Android Studio, il semble ConstraintLayoutpasser plus de temps dans onMeasure et effectuer des travaux supplémentaires dans onFinishInflate.

Bibliothèque utilisée ( support-v4, appcompat-v7…):

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

Appareils / Versions d'Android reproduites sur: Samsung Galaxy S6 (SM-G920A. Désolé, pas d'atmosphère Nexus). Android 5.0.2

Comparaison rapide du traçage des méthodes:

Exemple de référentiel Github: https://github.com/OnlyInAmerica/ConstraintLayoutPerf

Voici les différences / avantages:

1. La disposition de contrainte a un double pouvoir de mise en page relative et de mise en page linéaire: définissez les positions relatives des vues (comme la mise en page relative) et définissez également des poids pour l'interface utilisateur dynamique (ce qui n'était possible que dans la mise en page linéaire).

2. Une utilisation très puissante est le regroupement d'éléments en formant une chaîne. De cette façon, nous pouvons former un groupe de vues qui dans son ensemble peut être placé de la manière souhaitée sans ajouter une autre couche de hiérarchie juste pour former un autre groupe de vues.

3. En plus des poids, nous pouvons appliquer un biais horizontal et vertical qui n'est rien d'autre que le pourcentage de déplacement par rapport au centre. (un biais de 0,5 signifie aligné au centre. Toute valeur inférieure ou supérieure signifie un mouvement correspondant dans la direction respective).

4. Une autre caractéristique très importante est qu'elle respecte et fournit les fonctionnalités pour gérer les vues GONE afin que les présentations ne se cassent pas si une vue est définie sur GONE via le code java. Plus d'informations peuvent être trouvées ici: https://developer.android.com/reference/android/support/constraint/ConstraintLayout.html#VisibilityBehavior

5. Fournit la puissance de l'application automatique de contraintes par l'utilisation de l'outil Blue print et Visual Editor qui facilite la conception d'une page.

Toutes ces fonctionnalités conduisent à un aplatissement de la hiérarchie des vues, ce qui améliore les performances et aide également à rendre l'interface utilisateur réactive et dynamique qui peut s'adapter plus facilement à différentes tailles et densités d'écran.

Voici le meilleur endroit pour apprendre rapidement: https://codelabs.developers.google.com/codelabs/constraint-layout/#0

Une grande différence est que ConstraintLayout respecte les contraintes même si la vue a disparu. Cela ne cassera donc pas la disposition si vous avez une chaîne et que vous souhaitez faire disparaître une vue au milieu.

En plus de la réponse @ dhaval-jivani.

J'ai mis à jour le projet github project vers la dernière version de la disposition des contraintes v.1.1.0-beta3

J'ai mesuré et comparé le temps de la méthode onCreate et le temps entre le début de onCreate et la fin de l'exécution de la dernière méthode preformDraw visible sur le moniteur du CPU. Tous les tests ont été effectués sur Samsung S5 mini avec android 6.0.1 Voici les résultats:

Nouveau départ (première ouverture d'écran après le lancement de l'application)

Disposition relative

OnCreate: 123ms

Dernier temps de préformeDessin - Temps de création: 311,3 ms

Disposition des contraintes

OnCreate: 120,3 ms

Dernière préforme Temps de tirage - Temps de création: 310 ms

En plus de cela, j'ai vérifié le test de performances de cet article , voici le code et j'ai constaté que sur le nombre de boucles, moins de 100 variantes de disposition de contraintes sont plus rapides lors de l'exécution du gonflage, de la mesure et de la disposition, puis des variantes avec la disposition relative. Et sur les anciens appareils Android, comme Samsung S3 avec Android 4.3, la différence est plus grande.

En conclusion, je suis d'accord avec les commentaires de l' article :

Vaut-il la peine de refactoriser les anciennes vues pour les activer depuis RelativeLayout ou LinearLayout?

Comme toujours: cela dépend 🙂

Je ne refactoriserais rien sauf si vous avez un problème de performances avec votre hiérarchie de mise en page actuelle ou si vous voulez quand même apporter des modifications importantes à la mise en page. Bien que je ne l'ai pas mesuré récemment, je n'ai trouvé aucun problème de performances dans les dernières versions. Je pense donc que vous devriez être sûr de l'utiliser. mais - comme je l'ai dit - ne migrez pas uniquement pour migrer. Ne le faites que si vous en avez besoin et en bénéficiez. Pour les nouvelles dispositions, cependant, j'utilise presque toujours ConstraintLayout. C'est tellement mieux que ce que nous avions auparavant.

Officiellement, ConstraintLayoutc'est beaucoup plus rapide

Dans la version N d'Android, la ConstraintLayoutclasse fournit des fonctionnalités similaires à RelativeLayout, mais à un coût nettement inférieur.

La vraie question à se poser est la suivante: y a-t-il une raison d'utiliser une disposition autre qu'une disposition de contraintes? Je pense que la réponse pourrait être non.

Pour ceux qui insistent sur le fait qu'ils s'adressent à des programmeurs débutants ou similaires, ils devraient fournir une raison pour qu'ils soient inférieurs à toute autre mise en page.

Les dispositions de contraintes sont meilleures à tous points de vue (elles coûtent environ 150k en taille APK.). Ils sont plus rapides, ils sont plus faciles, ils sont plus flexibles, ils réagissent mieux aux changements, ils corrigent les problèmes lorsque les éléments disparaissent, ils se conforment mieux à des types d'écran radicalement différents et ils n'utilisent pas un tas de boucles imbriquées aussi longtemps dessiné une structure arborescente pour tout. Vous pouvez mettre n'importe quoi n'importe où, par rapport à n'importe quoi, n'importe où.

Ils étaient un peu fous à la mi-2016, où l'éditeur de disposition visuelle n'était tout simplement pas assez bon, mais ils sont au point que si vous avez une disposition, vous voudrez peut-être sérieusement envisager d'utiliser une disposition de contraintes, même quand il fait la même chose qu'un RelativeLayout, ou même un simple LinearLayout. FrameLayoutsont clairement encore leur but. Mais, je ne vois rien construire d'autre à ce stade. S'ils avaient commencé par cela, ils n'auraient rien ajouté d'autre.

La conclusion que je peux faire est

1) Nous pouvons faire la conception de l'interface utilisateur sans toucher à la partie xml du code, pour être honnête, je pense que Google a copié la façon dont l'interface utilisateur est conçue dans les applications iOS , cela aura du sens si vous êtes familier avec le développement de l'interface utilisateur dans iOS, mais dans une disposition relative, son difficile de définir les contraintes sans toucher au design xml .

2) Deuxièmement, il a une hiérarchie de vues plates contrairement à d'autres mises en page, ainsi que de meilleures performances que la mise en page relative que vous auriez pu voir dans d'autres réponses

3) Il a également des choses supplémentaires en dehors de ce que la disposition relative a, comme le positionnement relatif circulaire où nous pouvons positionner une autre vue par rapport à celle-ci à un certain rayon avec un certain angle qui ne peut pas faire dans une disposition relative

Je le répète, la conception de l'interface utilisateur à l'aide de la disposition des contraintes est la même que la conception de l'interface utilisateur dans iOS, donc à l'avenir si vous travaillez sur iOS, vous trouverez plus facile si vous avez utilisé la disposition des contraintes

La seule différence que j'ai remarquée est que les éléments définis dans une disposition relative par glisser-déposer ont automatiquement leurs dimensions par rapport aux autres éléments inférés, donc lorsque vous exécutez l'application, ce que vous voyez est ce que vous obtenez. Cependant, dans la disposition des contraintes, même si vous faites glisser et déposez un élément dans la vue de conception, lorsque vous exécutez l'application, les choses peuvent être déplacées. Cela peut être facilement résolu en définissant manuellement les contraintes ou, un mouvement plus risqué étant de cliquer avec le bouton droit sur l'élément dans l'arborescence des composants, en sélectionnant le sous-menu de disposition des contraintes, puis en cliquant sur «inférer les contraintes». J'espère que cela t'aides