Différences entre ConstraintLayout et RelativeLayout

219

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

b2mob
la source
9
ConstraintLayout est principalement conçu pour les nouveaux programmeurs afin qu'ils puissent facilement concevoir la mise en page à l'aide de Visual Editor au lieu de construire la mise en page à la main via XML.
CopsOnRoad
1
@Jack a certainement un but plus profond pour les développeurs expérimentés
Moses Aprico
@MosesAprico vous avez raison, il a cela. Mais je pense que les devs d'experts chevronnés ont déjà beaucoup d'autres moyens (ils savent déjà comme RealtiveLayout, LinearLayout, GridLayoutetc.) pour obtenir la hiérarchie de la vue qu'ils veulent.
CopsOnRoad
5
@CopsOnRoad En fait, vous vous trompez. Apple fait des mises en page de contraintes depuis plus de 5 ans. Vous obtenez un design réactif à n'importe quelle taille et n'avez pas à écrire une tonne de mises en page complexes. Lorsque vous commencez à lier plusieurs vues, vous n'avez besoin que de 3 commandes de base pour créer une conception entièrement réactive.
Nick Turner

Réponses:

145

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.

entrez la description de l'image ici

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

Nikola Despotoski
la source
9
Nous pouvons toujours créer une mise en page aplatie à l'aide de RelativeLayout, c'est pourquoi je suis confus là où ConstraintLayout fait attention où RelativeLayout ne peut pas?
7
RelativeLayout est une configuration en deux passes, souffrant de double imposition. Il doit mesurer / mettre en page au moins deux fois. ConstraintLayout ne souffre pas de cette pénalité de performance.
Christopher Perry
5
@Rien Oui, nous pouvons toujours créer une mise en page aplatie à l'aide de RelativeLayout. Mais en plus de tout le monde mentionné ici, ConstraintLayout vous permet d'utiliser des marges négatives et des sous- vues de taille dans un rapport prédéfini . Le dernier est le moyen le plus robuste de conserver un rapport 16: 9 pour votre ImageView dans CardView conformément à la conception matérielle
Eugene Brusov
4
Certaines dispositions sont impossibles dans RelativeLayout sauf si vous imbriquez un LinearLayout ou un autre RelativeLayout. Par exemple: centrer une "pile" de 3 vues verticalement par rapport à une autre vue
Gak2
@ Gak2 Je ne vois rien d'impossible dans votre exemple sans une disposition imbriquée. Peut-être que vous voulez dire autre chose avec "pile" que moi. J'utilise juste "layout_alignEnd", "layout_below", "layout _..." et je peux construire n'importe quel type de pile avec ...
L'incroyable
81

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

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"

Naimatullah
la source
2
Pouvez-vous publier sous forme de texte au lieu d'image? Pour que cela me soit très utile à moi et à d'autres à l'avenir.
Nouveau développeur
3
Tout le monde qui commence à apprendre les dispositions de contraintes doit le voir. Merci.
grantespo
1
Il s'agit d'informations utiles, mais il s'agit simplement d'un vidage de la documentation et ne fait rien pour expliquer la différence entre elles.
YetAnotherRandomUser
1
Non, je n'ai pas le temps de regarder dans les documents, c'est certainement utile. Et écrit dans un langage simple. Upvoting.
CodeToLife
46

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:

1

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

Dhaval Jivani
la source
du même problème: je vais fermer ceci pour l'instant - alpha 4/5 a apporté pas mal d'amélioration des performances. Nous pourrons probablement l'améliorer davantage, mais cela pourrait attendre la version 1.0.
Oleksandr
Pouvez-vous expliquer dans quel outil vous avez utilisé pour créer cette grande comparaison?
Nativ
2
@Nativ Monotirs-> CPU-> Icône de suivi du temps
Andrey T
18
Exécuter et profiler le même code sur avec constraint-layout: 1.0.1 sur Nexus 5 avec android 6.0.1, voici les résultats: Disposition relative - init 2ms sur Measure 30ms + 16ms = 62ms sur Layouyt 7ms = 9ms au total 54 ms Disposition de contrainte - init 7ms Constraint Layout générer des paramètres de mise en page + ajouter une vue ~ 7 * 2ms = 14ms sur mesure 60ms + 52ms ~ 112ms sur mise en page 8ms au total ~ 141ms Première initialisation de la mise en page relative presque trois fois plus rapide que Constraint.
Andrey T
2
La disposition des contraintes est introduite afin que la hiérarchie des vues imbriquées puisse être réduite. Ainsi, moins de hiérarchie signifie moins de temps pour parcourir de haut en bas dans l'arborescence de la vue. Alors, quel est l'intérêt de créer une hiérarchie de vues imbriquées qui peut ne pas être nécessaire dans la disposition Contrainte et de la comparer avec la disposition relative dans laquelle vous avez plus de chances de vous retrouver avec une structure imbriquée?
codepeaker
27

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

Vishu Gupta
la source
6) ConstraintLayout permet de dimensionner les sous-vues dans des ratios prédéfinis medium.com/google-developers/… . Cela serait utile par exemple lorsque vous allez conserver votre ImageView en 16: 9.
Eugene Brusov
15

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.

Herrbert74
la source
pouvez-vous me donner un exemple? supposons que 3 boutons soient là. Je cacherai le 2ème bouton et le 3ème bouton sera attaché au 2ème bouton avec l'ID comme btn2. Supposons que je cache le 2e bouton, puis comment le 3e bouton pourrait-il trouver l'identifiant du 2e bouton?
1
Ce n'est pas vrai. Si vous définissez la visibilité d'un bouton sur "INVISIBLE" au lieu de "GONE", vous ne briserez pas les contraintes. Quant à moi, la plus grande différence, comme @Nikola l'a dit, est le biais qui vous aide à créer des vues plus «réactives».
2017 zapotèque
@ Rien Supposons que les boutons soient l'un sous l'autre. Même si vous masquez le tButton 2, il est toujours là dans le "view contract", soit dans votre xml, soit dans votre code. ConstraintLayout le respectera et le bouton 3 se trouvera sous le bouton 1. Dans un RelativeLayout, le bouton 2 est parti, la contraint a disparu, donc le bouton 3 sera dans la position par défaut, donc en haut à gauche de l'écran.
Herrbert74
@zapotec Je respecte le fait que d'autres choses sont plus importantes pour vous, mais pour moi, c'est une différence vraiment cool. Corrige la seule chose que je détestais dans RelativeLayout. L'utilisation d'invisible n'est pas une option, car elle réclamera l'espace.
Herrbert74
7

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.

Andrey T
la source
6

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.

serv-inc
la source
6

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.

Tatarize
la source
1
Y a-t-il une preuve plus rapide?
Rajesh Nasit
1
Oui. C'est plus rapide. La disposition est en panne dans un seul solveur plutôt que d'itérer dans un arbre. Pour la plupart des choses, cela n'a pas d'importance car cela se fait lors de l'appel à la mise en page. Mais, l'arborescence des vues, bien que facile, crée un tas de vues à l'intérieur des vues qui nécessitent des appels nécessitant des appels. Bien que cela soit théoriquement plus agréable, dans la pratique, la mise en page dans un bit de code est beaucoup plus facile que d'itérer dans l'arborescence de vue entière. Cela deviendrait plus impressionnant avec plus de vues, mais voici un point de repère de mai: medium.com/@krpiotrek/constraintlayout-performance-c1455c7984d7
Tatarize
Je suis confronté à une autre question, dois-je remplacer tous les Relativelayouts existants dans l'application sur laquelle je travaille? Cela améliorera-t-il considérablement les performances?
Sreekanth Karumanaghat
@SreekanthKarumanaghat, il semble que vous ne fassiez jamais reculer le temps qu'il faut pour remplacer ceux de retour dans le temps, le changement vous sauverait. Nous parlons de cycles de 3,5 ms tombant à 3,25 ms dans la plupart des cas. Si cela vous donne une fonctionnalité supplémentaire ou quelque chose dont vous avez besoin, bien sûr, mais uniquement pour des raisons de vitesse non. Bien que nous parlions de frapper un bouton de conversion.
Tatarize
5

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

murali krish
la source
1

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

Wilson
la source