Salutations, cher harazhiteli! Ce message m'a incité à écrire un article (ou plutôt, la sensation d'une forte augmentation de la température locale dans la région ... hmm, bas du dos, qui se produit généralement lorsque quelqu'un se trompe sur Internet).
Commençons par le tout début. Je suis tout à fait d'accord pour dire "qu'il y a quelque chose en commun entre le cycle de vie de l'activité et le travail de RecyclerView" - c'est "quelque chose" - la nécessité de comprendre ce que nous faisons et pourquoi. Et lisez la documentation. Et le non-respect de ces deux nécessités, comme le rêve de la raison, donne naissance à des monstres. Seulement ici, avec la façon dont l'auteur précédent propose de combattre ces monstres, je suis fortement en désaccord.
Considérez 2 conditions.
Condition Nombre de fois
Si vous raccrochez un auditeur quelque part, alors vous devez le déconnecter ailleurs. Habituellement, ils le font dans des fonctions symétriques - attachez-le à onViewAttachedToWindow , supprimez-le à onViewDetachedFromWindow . Nous attachons dans onBindViewHolder ... Nous n'attachons pas dans onBindViewHolder . Cet appel n'est pas symétrique, il peut être appelé plusieurs fois selon différentes conditions. Pas besoin de compliquer votre vie.
Si vous, comme l'auteur de l'article d'origine, pensez: «Mais il y a des cas où ... dans l'écouteur, il est nécessaire de prendre en compte la position d'un élément dans la liste, dont l'accès est disponible dans la méthode onBindViewHolder () et est absent dans onViewAttachedToWindow ()" , puis pilotez ceci réfléchi. Vous ne pouvez pas faire ça. Même si vous en avez vraiment envie. Comme indiqué dans la documentation , cette méthode ne sera pas appelée si seule la position de l' élément a changé, mais pas son contenu, nous risquons donc d'avoir la mauvaise position dans notre écouteur. Utilisez getAdapterPosition .
Condition numéro deux
RecyclerView est une chose assez compliquée. Plus besoin de compliquer encore plus votre vie. Si vous n'êtes pas impliqué dans l'optimisation des performances, peu importe que cet élément soit ou non dans le pool général.
Résultat
Dans ces deux conditions, il est peu probable que vous ayez besoin de réinventer la roue sous la forme d'un indicateur viewWasRecycled .
Que se passe-t-il?
Que peut-il arriver à un élément de RecyclerView en général? Tout d'abord, gardez à l'esprit qu'il existe 2 «référentiels»: cache et pool. Un élément pénètre dans le cache s'il a dépassé les limites de l'écran, mais peut revenir à tout moment - sans même lier à nouveau cet élément (c'est-à-dire que la méthode onBindViewHolder ne sera pas appelée). Si le cache est plein, ou pour une autre raison, RecyclerView décidé que nous n'aurions pas besoin de cet élément dans un avenir proche, il ira au pool (ici onViewRecycled sera appelé). L'élément récupéré du pool sera re-lié (car il est probable que sa position ait changé) et nous recevrons un appel onBindViewHolder . Mais si l'élément a quitté le pool, le nouvel élément passera par tout le cycle - onCreateViewHolder , onBindViewHolder , onViewAttachedToWindow .
Au total, nous avons 3 options pour le développement d'événements:
- il n'y avait aucun élément avant: nous créons, nous attachons, nous attachons;
- l'élément était dans le pool: lier, attacher;
- l'élément était dans le cache: il suffit de le joindre.
Où et comment?
Quoi et à quelles étapes vaut-il mieux faire avec un élément?
onCreateViewHolder . Créez, hmm, ViewHolder . Il n'est pas nécessaire de lier un auditeur, de le remplir de contenu, etc. Déterminez simplement le type dont nous avons besoin et créez-le.onBindViewHolder . Nous effectuons la liaison de contenu réelle - texte, images. Le paramètre position ne peut être utilisé que dans la méthode elle-même - nous ne l'enregistrons pas, nous ne l'envoyons pas aux fermetures, rappelez-vous que cette méthode sera rappelée si les données ont changé (et elle ne le sera pas si seule la position a changé). Je ne voudrais pas accrocher un auditeur ici non plus - pour des raisons de symétrie.onViewAttachedToWindow . L'élément sera désormais visible à l'écran, l'utilisateur pourra interagir avec lui - un bon moment pour attacher un auditeur. N'oubliez pas que si nous avons besoin de la position d'un élément à l'intérieur, nous l'obtenons via getAdapterPosition .onViewDetachedFromWindow . L'élément ne sera pas affiché à l'écran. L'utilisateur ne pourra pas interagir avec lui. Supprimez l'auditeur.onViewRecycled . L'article est envoyé à l'enfer piscine Ici, vous pouvez libérer de lourdes ressources (images en cache, par exemple). Si l'élément sera réutilisé - alors, très probablement, pour une position différente.
Cela semble être tout. J'espère que je n'ai rien oublié ou mélangé quoi que ce soit, mais si quelque chose, piquez-vous le nez, ne soyez pas timide.