Performances Android: Ajout d'une vue par programme vs vue de configuration à GONE / VISIBLE

Je travaille dans un projet qui nécessite de gonfler un tutoriel simple. Affichage lorsque l'utilisateur ouvre l'application pour la première fois. J'essaie de le faire «correctement», et je me demande le problème de performance.

Actuellement, j'ai dans ma disposition une vue définie sur android:visibility="GONE" , que je passe à VISIBLE fonction d'un SharedPreference. Cela me permet de laisser l'utilisateur apprendre comment fonctionne l'application lors des premiers lancements.

Ce que je me demande, c'est ce qu'il implique lorsque la vue est rendue dans mon fragment. Je suppose que la vue sera gonflée inutilement, même si sa visibilité est définie sur GONE .

Maintenant, je pense à une alternative: que faire si je n'ajoute que mon onCreateView sur les premiers lancements, mais par programmation, dans mon Fragment onCreateView . Cela devrait permettre à la vue de ne pas être gonflé lors de lancements ultérieurs, mais ne gonflerait-il pas la vue implique de manière programmatique de mauvaises performances lors des premiers lancements?

3 Solutions collect form web for “Performances Android: Ajout d'une vue par programme vs vue de configuration à GONE / VISIBLE”

Donc, pour répondre à ma propre question, j'ai utilisé l'outil DDMS TraceView pour surveiller les appels de mon fragment sur l' onAttach jusqu'à son onResume . Il me permet de voir quelle implémentation est la moins efficace.

Pour faire le test, j'ai eu un FrameLayout RelativeLayout avec un FrameLayout intérieur (montré tout le temps). J'ai utilisé une mise en page personnalisée pour ajouter chaque fois, par programmation ou avec une visibilité de GONE sur mon fichier de mise en page. La mise en page personnalisée était composée d'un RelativeLayout avec 4 enfants (un ImageView, un TextView, un View et un Button).

My onCreateView était le suivant, permettant à l'application de gonfler la bonne mise en page en fonction de deux constantes static final boolean permanentes static final boolean pour modifier les mises en page.

 public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) { LinearLayout root; if(INFLATE_PROGRAMMATICALY) { root = (LinearLayout) inflater.inflate(R.layout.fragment_test_prgmcly, container, false); if(SHOULD_FYI_VIEW_BE_SHOWN) { View tutoView = inflater.inflate(R.layout.inner_view, root, false); root.addView(tutoView); } } else { root = (LinearLayout) inflater.inflate(R.layout.fragment_test_gone,container,false); if(SHOULD_FYI_VIEW_BE_SHOWN) { View tutoView = root.findViewById(R.id.RL_inner_view); tutoView.setVisibility(View.VISIBLE); } } return root; } 

Cela aboutit aux résultats suivants:

Lorsque la mise en page optionnelle est gonflée

SHOULD_FYI_VIEW_BE_SHOWN=true

L'estimation maximale "en temps réel" donnée par TraceView est de 75 ms lorsqu'il existe juste une vue de passer de GONE à VISIBLE , mais de 110 ms lorsque nous devons instancier la inner_view .

Lorsque la disposition facultative n'est pas gonflée, SHOULD_FYI_VIEW_BE_SHOWN=false

Dans ce cas, l'estimation maximale en temps réel donnée par TraceView est de 102ms pour l'inflation de la vue GONE , contre 39ms lorsque la vue gonflée n'a pas la vue GONE .

Ainsi, pour le gain de performance lorsque les vues n'ont pas besoin d'être gonflées, je dirais que la meilleure solution est de gonfler votre vue par programme, si vous avez seulement besoin de l'afficher quelques fois .

Vous pouvez trouver le projet de test sur un sérum

Je pense que vous réinventez une roue. Pour ce scénario est déjà un outil existant dans les mises en page xml d'Android. On l'appelle ViewStub. Vous pouvez lire plus ici: Chargement ondemand

Je pense que je me suis juste découpé au hasard sur la réponse à votre question de performance.

Du document d'animation :

Pour que la vue soit décolorée, définissez sa visibilité sur GONE. Cela empêche la vue de prendre l'espace de disposition et l' omit des calculs de mise en page , ce qui accélère le traitement.

Cela signifie que les performances ne sont pas compromises tant que vous ne définissez pas android:visibility à autre chose que GONE .

coAndroid est un fan Android de Google, tout sur les téléphones Android, Android Wear, Android Dev et Android Games Apps.