Dev Faq
7
votes

Décalage lorsque recyclerview défilant

Je ne peux pas comprendre quelle est la raison pour laquelle les freins lorsque vous faites défiler sur mon recyclerview. Le défilement est appelé par mrecyClerView.smoothscrollToposition (position); Lorsque vous faites défiler la liste des contractions Twitches (délai de rendu> 16ms)

alphaadapter.java xxx

élément de présentation qui participe à l'adaptateur est composé de linearlayout, imageview, 2 TextView.

Au début, je pensais que le problème dans le téléchargement d'images, essayez de les charger dans l'asyncaptage, de télécharger Bitmap via Picasso et sans, mais après tout retiré de leur marque, et la liste sera toujours en retard.

Pour vider la RAM après le défilement est, il indique qu'il y a 71 instances de mémoire à l'origine du titulaire de la mémoire, après avoir ajouté xxx

cette valeur est réduite à 15 -16, Bien que le tarif pour recyclerview - 5 copies, et cela devrait les remplacer, Mais ne crée pas de nouveaux lorsque vous faites défiler. Screenshot 1

item_null.xml xxx

item_game.xml xxx < / p>

5 commentaires

Pourriez-vous poster des mises en page? r.layout.item_game et r.layout.item_null

@Eleven a ajouté des mises en page

Avez-vous essayé de charger votre animation une seule fois? Comme dans le constructeur de votre adaptateur?

J'ai essayé de définir l'animation sur tous les articles de RV, seulement si Boolean Isanimate == True

Dans cette question, l'animation est désactivée

3 Réponses :

6
votes

Vous passez un contexte à l'adaptateur. Tout d'abord cela pourrait entraîner des fuites de mémoire et pourrait également affecter votre performance. Au lieu de passer le contexte dans l'adaptateur, faites-le simplement du titulaire de la vue. Vous pouvez toujours obtenir une référence de contexte à l'intérieur de RecyclerView.adapter sans avoir besoin de le transmettre.

Pour vider la RAM après le défilement, il montre qu'il y a 71 instances de mémoire à l'origine du titulaire de la vue.

juger de la décharge C'est probablement le cas. xxx

1 commentaires

Le contexte n'est pas la raison de cela. Ajouté ma réponse.

1
votes

En réponse à la réponse acceptée ici:

Comment un contexte pourrait-il être une fuite de mémoire sur un adaptateur? Ou même le rendre plus lent? Il est attaché uniquement à la recyclerview de l'activité de toute façon ... Une fois que l'activité est partie, le contexte est gc-ed avec l'adaptateur. Non seulement cela, mais obtenir le contexte de la vue de la vue vous rappellera toujours le même, il est donc inutile et appelle aux fonctions sans besoin. Vous pouvez même rendre l'adaptateur une classe interne statique, de sorte que vous puissiez y accéder directement, au lieu d'avoir un champ déclaré. En bref, le contexte n'est pas la raison pour laquelle vous avez une fuite de mémoire.

Qu'est-ce qui pourrait être le problème, alors? Je pense que vous devez annuler la demande d'image précédente sur Picasso, chaque fois que vous vous attachez à un porte-visée, comme celui-ci: xxx

Vous voudrez peut-être aussi le faire pour tous, dans CAS L'activité a été détruite (mais pas à cause du changement d'orientation), mais cela dépend de vos besoins.

Je suggère également d'essayer la bibliothèque de Glide. Il semble plus moderne et toujours entretenu.

3 commentaires

Eh bien, je n'ai jamais dit que c'était une fuite de 7% de mémoire, tout ce que j'ai dit est que ce n'est pas une bonne pratique de passer un contexte comme ça. Pour une raison très simple, si vous définissez un fragment pour conserver une instance, il survivra à votre activité, tandis que la vue Recycler qui appartient au fragment contient une référence au contexte d'activité. C'est un cas très fondamental, je suis sûr qu'il y a beaucoup d'autres moyens de fuir un contexte de cette façon.

À peu près sûr que OncreeView est appelé à nouveau dans ce cas, que vous recréez à nouveau l'adaptateur avec la nouvelle instance de contexte. Donc, si vous le faites correctement, il est correct d'utiliser le contexte comme champ.

@ Développeur Android .hi. Pouvez-vous m'aider à ma question? Stackoverflow.com/q/46790086/4813855 Merci beaucoup

0
votes

Après avoir retiré

Android: HardwareAscelerated = "False"

de l'application dans Manifeste, résolue la traîne

0 commentaires

Articles qui pourrait vous intéresser :

MotionLayout empêche ClickListener sur toutes les vues
Modifier l'indicateur de texte n'est pas visible dans l'aperçu de la conception du studio Android, mais est visible sur l'émulateur lorsque l'application s'exécute
Après la migration vers AndroidX, erreur de gonflage de la classe android.support.design.widget.AppBarLayout
Code de réponse 403 inattendu lors de la récupération des données des API