Mauvaise performance ListView sur Gluon

Question

J'ai une implémentation personnalisée ListCell, montré dans l'image ci-dessous.

Le côté gauche, ce qui représente la date, composé de 3 étiquettes, mis dans un VBox et le « CounterContent » constitué par le compteur, avec un TextField pour chaque chiffre, contenu dans un HBox, et deux Hboxes contenant des étiquettes pour kWh, kWh/jour et ainsi de suite. Et cela semble être trop, pour être performant.

J'ai essayé de charger les données dans une tâche d'arrière-plan, montrant un indicateur de progression, tandis que la tâche est en cours d'exécution, mais contrairement au bureau, sur android les performances sont très pauvres. Chaque fois que je passe à la liste, la collecte des ordures entre en jeu et bloque le thread ui, de sorte que l'indicateur de progression n'apparaît jamais.

Je l'ai essayé sur un Huawei Y-300, 4.1.1 Android, javafxports 8.60.6 (parce que javafxports 8.60.7 provoque un bug, qui rend inutilisable TextField), et sur un Samsung S5 mini, Android 5 +. Sur le téléphone Samsung, la performance en général est bien meilleure, comme prévu, à cause de la compilation Ahead-of-Time je suppose, mais il y a toujours le problème de la récupération de place. De plus, après que la liste ait été remplie avec des cellules, le défilement n'est pas très lisse.

Est-ce que listcell est complexe ou quoi d'autre pourrait être la cause de la mauvaise performance?

MISE À JOUR:

Après avoir exécuté beaucoup de tests, il semble que le défilement saccadés n'est pas causée par des problèmes de performance. Au moins sur le S5 (javafxports 8.60.7).

I enlevé tout style CSS, et a remplacé le textfields par une seule étiquette (le nœud de compteur est déjà un contrôle personnalisé (oublié à ce sujet), qui définit les textfields dans 2 Regions (non HBoxes) et les noeuds de la ListCell sont instanciées dans le constructeur). En outre, j'ai commuté le ListView pour un CharmListView et j'ai défini android.monocle.input.touchRadius = 1.

Aucune de ces étapes n'a abouti à une amélioration considérable. Juste pour clarifier: Contrairement au téléphone Huawei, le défilement sur le S5 et Android 5+ est utilisable, mais ce n'est pas très lisse, ce qui rend l'expérience utilisateur insatisfaisante. Sur le Huawei (javafxports 8.60.6), changer les champs de texte du compteur pour une étiquette, a donné une amélioration significative, mais pas au point où le défilement est devenu utilisable. Jusqu'à ce que je mette en place ce switch expérimental magique: gluon.experimental.performance = true, ce qui fait que la listview défile rapidement (après un peu de temps d'échauffement), mais pas vraiment lisse.

Answer 1

Il existe de nombreuses raisons pour lesquelles les performances d'une scène complexe sont réduites. Il ne s'agit donc que d'une liste d'idées susceptibles de l'améliorer, dans n'importe quel ordre.

listcell

Pour commencer, le nombre de noeuds dans la cellule est très élevé. Notez que chaque scroll que vous faites signifie le rendu complet du flux virtuel qui contient les cellules visibles. Et pour chaque cellule, cela signifie recréer son contenu à nouveau.Sans voir votre code je ne peux pas le dire, mais vous devriez éviter de créer de nouvelles instances de chaque nœud de la cellule tout le temps, en ayant une seule instance, et dans la méthode updateItem seulement changer le contenu des nœuds .

Jetez un oeil à ce sample. La classe NoteCell est une cellule personnalisée, où ListTile est utilisé.

Nombre de nœuds

Avez-vous essayé d'utiliser juste un Label pour remplacer les 8 et textfields 3 boîtes?

Cache

Si vous utilisez des images téléchargées sur Internet, utilisez gluons Charm vers le bas Cache pour éviter la même image en cours de téléchargement, encore et encore.

Jetez un oeil à ce sample. Sans le cache, même sur le bureau, la performance est vraiment affectée.

Utilisez également le cache intégré JavaFX pour n'importe quel noeud, en essayant différentes stratégies de cache.

CSS

CSS complexe nécessite beaucoup de temps CPU. Essayez de le simplifier. Même vous pouvez supprimer l'ensemble du CSS pour un test rapide. Puis décidez ce que vous pouvez ou ne pouvez pas utiliser.

De même pour les animations: évitez les animations, les transitions ou même les effets CSS, si possible.

contrôle personnalisé

Le compteur noeud complexe pourrait probablement être remplacé par un contrôle personnalisé qui optimise le rendu.

CharmListView

Avez-vous essayé d'utiliser le contrôle Charm gluons CharmListView au lieu du ListView?

Il existe un nouveau drapeau expérimental que vous pouvez utiliser pour tester une optimisation possible qui pourrait améliorer les performances tout en faisant défiler la liste. Définissez gluon.experimental.performance=true sur le fichier java.custom.properties et faites-en l'essai.

JavaFXPorts Version

Vous avez mentionné que vous utilisez 8.60.6 à cause du bug TextField. Dans ce cas, vos noeuds TextField sont-ils modifiables? Si ce n'est pas le cas, je suggère de les remplacer par d'autres nœuds et de les utiliser avec la version 8.60.7, car elle contient de nombreuses améliorations de performances.

Outils de performance

Utiliser des outils de performance comme Monitor et utiliser ses profiling options afin que vous pouvez tracer vers le bas tout goulot de la bouteille possible.

CPU

Last but not least: les spécifications de votre appareil mobile sont toujours critiques. Essayer de rendre une scène complexe sur un Cortex A5, étant donné que «c'est l'application ARMv7 processor la plus petite, la moins chère et la plus économique», ou utiliser un très vieux Android 4.1.1, ne peut pas fonctionner aussi bien que en cours d'exécution sur un tout nouvel appareil avec des spécifications plus élevées.

Comme vous l'avez également mentionné, le fonctionnement sur un Cortex A7 est «bien meilleur». Jetez un oeil à ce comparison, et de trouver la bonne architecture pour le travail.

De toute façon, il y a toujours de la place pour l'amélioration, et beaucoup d'efforts y sont mis. Votre retour est toujours le bienvenu.