Fluidité d'une TableView et static const
[EDIT modo]Ce sujet est la suite d'un post sur le retour de fluidité d'une appli[/EDIT]
J'ai toujours des problèmes avec la fluidité de l'application.. mais bon bravo!
J'ai toujours des problèmes avec la fluidité de l'application.. mais bon bravo!
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Moi je la trouve assez rapide pour des données provenant en live d'un serveur.
(Mais je chipotte peut-être trop)
J'avais déjà passé du temps sur le système de cache (avec toute la gestion des callbacks par blocks et la gestion des cas un peu complexes des images utilisées dans les TableView dont les cellules peuvent être recyclées entre le moment où l'image est demandée et celui où l'image est téléchargée et dispo), mais j'ai encore repensé l'architecture sur ce nouveau cache modulaire et cette future optimisation devrait donc encore améliorer les choses.
Après j'ai fait ça pour optimiser l'empreinte mémoire de l'appli qui manipule un nombre très important d'images (encore plus dans tes tableviews et des feeds), et donc limiter les memoryWarnings & co... mais par contre côté fluidité tu es bien le seul à nous avoir remonté des soucis : même ceux qui ont un 3G ou 3GS n'ont rien remonté de particulier de ce côté...?!
Tu me diras avec le nouveau cache qd il sera mis en place si tu vois une différence, mais bon.
Et si, je te rassure, j'ai déjà codé ça avec des images et j'y ai passé un temps fou. Et FoodReporter lag plus que la normale.
Les images sont-elles optimisées pour la tableView?
C'est bien là , le seul point noir de l'appli : je trouve les images assez "sales", mais bon, vu que c'est pris avec un iPhone + la compression + le fait que les users doivent s'en ficher un peu de la qualité de la photo prise...
Les images de la tableView ne font que quelques Ko (3 à 4Ko pour les images "thumb" du feed, exemple ici ou ici qui fait même que 2.7K) et nous avons un peu rogné sur la qualité (pour avoir une meilleure compression et donc une plus petite taille) pour les images thumb utilisées dans le feed (mais les images "palm" et "full" sont de meilleure qualité... enfin après ça dépend si elles ont été prises avec un iPhone 3G/3GS ou un iPhone 4 évidemment )
Donc vraiment je te défie de faire mieux côté optimisation de cette TableView, franchement je vois pas : justement ça fait partie de ces choses que j'ai beaucoup travaillé (avec justement mon CacheManager) dans l'appli pour la rendre fluide, donc c'est pas pour te démentir ou me dédouaner car je sais qu'il y a des choses à améliorer dans l'appli... mais cette partie-là ça m'étonne !
Après si tu as une idée d'optimisation je suis preneur, mais à part dessiner avec CoreGraphics la cellule plutôt que d'utiliser des UIView (chose qui d'après ce que j'ai entendu ne gagne pas tant que ça et en plus compliquerait énormément les choses pour les images qui sont téléchargées et mises à jour automatiquement dès que disponibles actuellement) je crois que j'ai tout fait côté optim... et tu es le seul à me remonter ce sentiment !
Fais-nous une vidéo (et rends la fluide, cette vidéo, qu'elle lag pas à cause de l'encodage lol) pour qu'on se rende compte et poste là ici qu'on puisse voir, ça nous aiguillera peut-être ?
Toute façon, une fois la nouvelle version iOS disponible pour tout le monde, je réinstalle mon iPhone et FoodReporter par la même occasion. Si vraiment ça continue de lagger je ferai probablement une vidéo.
Pour l'optim, je confirme que CG ou UIView, on y voit que du feu...
C'est vraiment pas pour te faire chier ou quoi que ce soit hein, c'est juste que je trouve ça trop bizarre, après tout ce que tu dis, que ça puisse lagger autant... A titre de comparaison, même l'appli LeclercDrive est plus fluide en scroll que FoodReporter.
Par contre oui si tu avais testé la version beta et que tu constates ces lags, ça peut valoir le coup de supprimer la version beta de ton iPhone, rebooter ton iPhone (l'éteindre/le rallumer hein, pas le réinstaller pour autant), et télécharger la 1.1 de l'AppStore et voir déjà si c'est un peu mieux ? Enfin ça coute rien à tester même si bon j'y crois pas trop.
PS : Si on t'avais filé une version AdHoc (je m'en souviens plus vu que le nombre de BetaTesteurs a explosé nos espérances et qu'on avais 1000 utilisateurs en beta...) il se peut qu'on t'ai filé plusieurs versions AdHoc utilisant successivement plusieurs DevProfiles, il est alors bon de les supprimer de ton iPhone (Réglages -> Général -> Profils installés) pour faire un peu de ménage... même si ça ça n'a rien à voir avec les perfs ou la fluidité de l'appli ^^
'tin quand même, t'es dur là !!!!
Viens au gros resto lundi soir pour nous montrer et pour comparer avec tous les autres utilisateurs :P
Du coup conséquence, j'ai pas le bon reuseIdentifier donc le mécanisme de recyclage des cellules de ma TableView n'est pas fonctionnel !
(Alors que j'enlève le "static" et tout marche comme attendu)
Ce qui m'étonne c'est que le compilateur ne dit rien et j'ai aucun warning ou aucun retour m'indiquant que j'essaye de réaffecter une variable ou qu'il y a conflit ou quoi... C'est sioux comme truc je trouve !
Donc conclusion : attention aux static const dans les .h !
Ouais, subtil le bug
En fait, tu déclares deux variables de même nom, mais qui ont une portée différente: static au fichier dans lequel elle est déclarée pour le .m
et globale à l'application pour celle déclarée dans le .h
Plus précisément, pour les variables globales statics, si j'en crois google, la portée est celle de l'unité de compilation, c'est à dire, que si elles sont déclarées dans une librairie, leur portée est limitée à cette librairie.
J'ai fourni une version corrective (1.1a) à Louka car j'avais vu une piste pour peut-être accélérer la fluidité de l'app chez lui.
Sauf que sur cette version 1.1a j'ai introduit le problème du "static const". Du coup le scroll sur cette version corrective était pire chez lui.
J'ai corrigé ce pb du "static const" et lui ai fourni encore une autre version (1.1b) et là ... bah ça laguait plus comme la 1.1a... mais d'après lui c'est quasi pareil en fluidité que la version 1.0 qui est sur AppStore (enfin si un peu plus fluide qd les photos sont pas chargées, car optimisation de mon cache, quand même, mais ça je le savais). Donc retour au point de départ, pas plus ni moins fluide que la version qu'il avait avant.