J'ai toujours utilisé RelativeLayout chaque fois que j'avais besoin d'un conteneur View, en raison de sa flexibilité, même si je voulais juste afficher quelque chose de très simple.
Est-ce correct de le faire, ou devrais-je essayer d'utiliser un LinearLayout lorsque je le peux, du point de vue des performances/bonnes pratiques?
Merci!
Lors d'une conférence à Google I/O 2013 (Écriture de vues personnalisées pour Android), Romain Guy a clarifié le malentendu qui a poussé tout le monde à commencer à utiliser des RelativeLayouts pour tout. Un RelativeLayout doit toujours effectuer deux passes de mesure. Dans l'ensemble, cela est négligeable tant que votre hiérarchie de vues est simple. Mais si votre hiérarchie est complexe, effectuer une passe de mesure supplémentaire pourrait potentiellement être assez coûteux. De plus, si vous imbriquez des RelativeLayouts, vous obtenez un algorithme de mesure exponentiel.
À moins que vous ne conceviez de nombreuses vues (par exemple dans un ListView), la différence de performance entre LinearLayout et RelativeLayout est négligeable. Choisissez celui qui est le plus pratique pour le travail à réaliser, et ne vous inquiétez de la performance que lorsque cela est nécessaire.
Et voici ce que disent les documents officiels à propos de la création de mises en page efficaces en ce qui concerne les performances de RelativeLayout et LinearLayout:
Se tenir aux fonctionnalités de base n'est malheureusement pas la manière la plus efficace de créer des interfaces utilisateur. Un exemple courant est l'abus de LinearLayout, qui entraîne une prolifération de vues dans la hiérarchie des vues. Chaque vue - ou pire, chaque gestionnaire de mise en page - que vous ajoutez à votre application a un coût : l'initialisation, la disposition et le dessin deviennent plus lents. Le passage de mise en page peut être particulièrement coûteux lorsque vous imbriquez plusieurs LinearLayout qui utilisent le paramètre de poids, ce qui nécessite que l'enfant soit mesuré deux fois.
La justification pour la considérer comme négligeable ? j'ai trouvé ceci qui indique que relativeLayout coûte plus cher comme je le soupçonnais bitbucket.org/spencerelliott/mercury/issue/1/…
L'optimisation prématurée est la racine de tout mal. D'accord, ce n'est pas le cas, mais ce qui se passe lorsque vous optimisez prématurément, c'est que vous perdez beaucoup de temps sur des choses qui ont une amélioration de performance négligeable. Optimisez seulement après avoir identifié les parties de votre code qui ralentissent les performances/la durée de vie de la batterie/etc. de votre application.
Relativelayout est plus efficace que Linearlayout.
De ici:
Il est courant de penser que l'utilisation des structures de mise en page de base conduit aux mises en page les plus efficaces. Cependant, chaque widget et mise en page que vous ajoutez à votre application nécessite une initialisation, une mise en page et un dessin. Par exemple, l'utilisation d'instances imbriquées de LinearLayout peut conduire à une hiérarchie de vue excessivement profonde. De plus, l'imbrication de plusieurs instances de LinearLayout qui utilisent le paramètre layout_weight peut être particulièrement coûteuse car chaque enfant doit être mesuré deux fois. Cela est particulièrement important lorsque la mise en page est gonflée de manière répétée, par exemple lorsqu'elle est utilisée dans un ListView ou un GridView.
MISE À JOUR 2018: Dans la version N d'Android, la classe ConstraintLayout offre des fonctionnalités similaires à RelativeLayout, mais à un coût nettement inférieur. C'est un gestionnaire de mise en page très puissant et il devrait être utilisé chaque fois qu'il est nécessaire de construire une interface utilisateur complexe.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
