Pourquoi 0dp est-il considéré comme une amélioration de performance?

Une réponse à la fin de cette question a été complétée, combinant remarques et solutions.

Question

J’ai cherché autour de moi mais je n’ai rien trouvé qui explique vraiment pourquoi Android Lint , ainsi que certains indices Eclipse, suggèrent de remplacer certaines valeurs de layout_height et layout_width par 0dp .

Par exemple, j’ai un ListView qui a été suggéré de changer

Avant

   

Après

   

De même, il a suggéré des modifications à un élément ListView . Celles-ci se ressemblent avant et après les changements, mais je suis intéressé à comprendre pourquoi ce sont des boosters de performance.

Quelqu’un a une explication de pourquoi? Si cela aide, voici la présentation générale avec ListView .

          

Répondre

Je mets une réponse ici parce que c’est une combinaison de réponses et de liens référencés ci-dessous. Si je me trompe sur quelque chose, faites le moi savoir.

De quel est le truc avec 0dip layout_height ou layouth_width?

Il y a 3 atsortingbuts de mise en page généraux qui fonctionnent avec la largeur et la hauteur

  1. android:layout_height
  2. android:layout_width
  3. android:layout_weight

Lorsqu’un LinearLayout est vertical , le layout_weight affectera la hauteur de la View enfant s ( ListView ). layout_height vous 0dp layout_height sur 0dp , cet atsortingbut sera ignoré.

Exemple

     

Lorsqu’un LinearLayout est horizontal , le layout_weight affectera la largeur de la View enfant s ( ListView ). layout_width vous 0dp layout_width à 0dp , cet atsortingbut sera ignoré.

Exemple

     

La raison de vouloir ignorer l’atsortingbut est que si vous ne l’ignoriez pas, il serait utilisé pour calculer la disposition qui utilise plus de temps processeur.

De plus, cela évite toute confusion sur l’apparence de la mise en page lorsque vous utilisez une combinaison des trois atsortingbuts. Ceci est mis en évidence par @android developer dans une réponse ci-dessous.

En outre, Android Lint et Eclipse disent tous deux utiliser 0dip . À partir de cette réponse ci-dessous, vous pouvez utiliser 0dip , 0dp , 0px , etc., car la taille zéro est la même dans toutes les unités.

Évitez wrap_content sur ListView

De Layout_width d’une ListView

Si vous vous êtes déjà demandé pourquoi getView(...) est appelé autant de fois que je l’ai fait, il se trouve lié à wrap_content .

L’utilisation de wrap_content comme ci-dessus entraînera la mesure de toutes les View enfant, ce qui entraînera un temps CPU supplémentaire. Cette mesure provoquera l’ getView(...) votre getView(...) . Je l’ai maintenant testé et le nombre de fois que getView(...) est appelé est considérablement réduit.

Lorsque j’utilisais wrap_content sur deux getView(...) , getView(...) était appelé 3 fois pour chaque ligne sur une ListView et 4 fois pour chaque ligne.

En changeant cela en 0dp recommandé, getView(...) été appelé une seule fois pour chaque ligne. Ceci est une amélioration, mais a plus à faire pour éviter wrap_content sur un ListView que sur 0dp .

Cependant, la suggestion de 0dp améliore considérablement les performances à cause de cela.

Tout d’abord vous avez ceci,

   

Ne prenez jamais la hauteur de ListView comme wrap_content, cela entraînera des problèmes. Here la raison de cela et de this answer .

En outre,

J’ai cherché autour de moi mais je n’ai rien trouvé qui explique vraiment pourquoi Android Lint, ainsi que certains indices Eclipse, suggère de remplacer certaines valeurs de layout_height et layout_width par 0dp.

C’est parce que vous utilisez layout_weight = "1" qui signifie que votre ListView prend la hauteur autant que possible. Donc, dans ce cas, il n’est pas nécessaire d’utiliser layout_height = "wrap_content" suffit de le changer pour android:layout_height="0dp" et la hauteur de ListView sera gérée par layout_weight = "1" .

Donc, quand Android: layout_weight est utilisé sur View X et LinearLayout est horizontal, alors android: layout_width est simplement ignoré.

Semblable, quand Android: layout_weight est utilisé sur View X et LinearLayout est vertical, alors Android X: layout_height est ignoré.

Cela signifie que vous pouvez mettre n’importe quoi dans ces champs ignorés: 0dp ou fill_parent ou wrap_content. Cela n’a pas d’importance. Mais il est recommandé d’utiliser 0dp pour que les vues ne calculent pas leur hauteur ou leur largeur (qui est alors ignorée). Ce petit tour économise simplement les cycles du processeur.

de :

Quel est le truc avec 0dip layout_height ou layouth_width?

autant que je sache, il y a une différence entre utiliser 0dp (ou 0px btw, c’est la même chose puisque 0 vaut 0, quelle que soit l’unité) et le wrap_content ou fill_parent (ou match_parent, c’est pareil).

cela dépend du poids que vous utilisez. Si vous n’utilisez que le poids 1, ils ont tous la même apparence, mais le sens est toujours différent et important pour la performance.

pour le montrer, essayez ce qui suit:

      

puis essayez de remplacer le 0px par match_parent. vous verrez que le résultat est très différent.

généralement, pour une meilleure compréhension et pour de meilleures performances, vous voudrez utiliser 0px.

LinearLayout mesure tous les enfants en fonction des valeurs layout_width / layout_height , puis divise l’espace restant (qui peut être négatif) en fonction des valeurs layout_weight .

0dp est plus efficace que wrap_content dans ce cas, car il est plus efficace de simplement utiliser zéro pour la hauteur d’origine, puis de diviser la hauteur totale du parent en fonction du poids plutôt que de mesurer d’abord l’enfant, puis de diviser le rest en fonction du poids.

L’efficacité vient donc de ne pas mesurer l’enfant. 0dp devrait être exactement aussi efficace (et produire exactement le même résultat) que match_parent , ou 42px , ou tout autre nombre fixe.

Attention à utiliser Android: layout_height = “0dp”

J’ai trouvé que dans un ListView (avec le recyclage de vue recommandé en utilisant convertView, voir par exemple http://lucasr.org/2012/04/05/performance-tips-for-androids-listview/ ), en définissant Android: layout_height = ” 0dp “pour la ligne TextView peut conduire à une troncation de texte pour le contenu de texte multiligne.

Chaque fois qu’un object TextView précédemment utilisé pour afficher un texte ajusté sur une seule ligne est recyclé pour afficher un texte plus long nécessitant plusieurs lignes, ce texte est tronqué sur une seule ligne.

Le problème est résolu en utilisant Android: layout_height = “wrap_content”