Fluidité d'une TableView et static const

février 2011 modifié dans Vos applications #1
[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!  :D

Réponses

  • muqaddarmuqaddar Administrateur
    02:18 modifié #2
    dans 1298571935:

    J'ai toujours des problèmes avec la fluidité de l'application.. mais bon bravo! 


    Moi je la trouve assez rapide pour des données provenant en live d'un serveur.
  • 02:18 modifié #3
    Bha meme avec les données chargée, quand je scroll ça lag un peu..
    (Mais je chipotte peut-être trop)
  • AliGatorAliGator Membre, Modérateur
    février 2011 modifié #4
    Il est déjà  prévu dans la prochaine version d'intégrer mon nouveau système de cache encore plus performant :
    • l'actuel, sur lequel j'avais déjà  pas mal travaillé en terme d'archi et d'optim, est basé sur un backend uniquement en RAM, qui permet déjà  de réduire les accès réseau et la consommation batterie et optimiser la fluidité de l'app
    • le prochain sera encore plus poussé puisque basé sur un savant mélange entre un backend en DB (pour réduire drastiquement le footprint mémoire et avoir une persistance entre les lancements) et un nouveau backend en RAM (nécessaire pour éviter la multi-allocation quand on utilise la même image à  plusieurs endroits dans l'appli), le tout savamment orchestré par un CacheManager qui équilibre le tout (détection des images inutilisées pour libérer la mémoire au plus tôt, et j'en passe)


    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.
  • AliGatorAliGator Membre, Modérateur
    février 2011 modifié #5
    dans 1298575808:

    Bha meme avec les données chargée, quand je scroll ça lag un peu..
    (Mais je chipotte peut-être trop)
    Attends si c'est comme la vidéo que tu m'avais montré la dernière fois... oui tu chipottes vraiment ! J'appelle pas ça un lag moi ^^ (Twitter scroll aussi vite que ça sur mon iPhone par exemple :P T'as jamais dû coder pour iOS une tableview avec des images toi ^^) !
  • 02:18 modifié #6
    Heuu Twitter est largement plus fluide que Food Reporter, mais c'est pas comparable vu que FReporter a de plus grosses images.
    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?
  • muqaddarmuqaddar Administrateur
    02:18 modifié #7
    Combien pèsent les images téléchargées ?
    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...
  • AliGatorAliGator Membre, Modérateur
    février 2011 modifié #8
    Oh que oui, toutes nos images sont déservies par le serveur à  des tailles adaptées au contexte : on a une version "thumb", une version "palm", et une version "full". C'est la "thumb" qui est utilisée pour la TableView, ce qui fait que le travail de redimentionnement n'est pas effectué par la TableView. Le seul redimentionnement fait éventuellement c'est pour les iPhones non-retina (mais ça c'est l'imageView qui fait un FitInSize pour passer de pixels retina à  points). De plus tout est intégré côté modèle ce qui fait que le remplissage de chaque cellule quand on scroll consiste simplement à  remplir 2-3 champs aux valeurs pré-calculées, on ne recalcule pas tout à  chaque passage.

    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 :D)


    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 ?
  • 02:18 modifié #9
    Organise une bouffe sur Toulouse et je me ferai un plaisir de te montrer  :D
    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.
  • AliGatorAliGator Membre, Modérateur
    02:18 modifié #10
    dans 1298628887:

    Organise une bouffe sur Toulouse et je me ferai un plaisir de te montrer  :D
    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.
    Heu la nouvelle version 1.1 elle est disponible ;) (Tu parlais peut-être d'encore la prochaine qui contiendra un cache encore plus amélioré avec persistance ?)

    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 ^^
  • LeChatNoirLeChatNoir Membre, Modérateur
    02:18 modifié #11
    dans 1298628887:

    A titre de comparaison, même l'appli LeclercDrive est plus fluide en scroll que FoodReporter.


    'tin quand même, t'es dur là  !!!!
  • AliGatorAliGator Membre, Modérateur
    02:18 modifié #12
    Oui je demande vraiment à  voir aussi...
    Viens au gros resto lundi soir pour nous montrer et pour comparer avec tous les autres utilisateurs :P
  • AliGatorAliGator Membre, Modérateur
    02:18 modifié #13
    Louka j'ai peut-être trouvé une explication pour ton problème, un truc un peu alambiqué mais vu que je vois pas ce que ça peut être d'autre... Si t'as l'occasion que je te file une version AdHoc corrective à  l'occasion pour tester si c'est ça ?
  • 02:18 modifié #14
    Quand tu veux !! Je te MP l'ID
  • AliGatorAliGator Membre, Modérateur
    02:18 modifié #15
    Reçu, je tâche de te faire un package ce WE
  • AliGatorAliGator Membre, Modérateur
    février 2011 modifié #16
    Bon ok, arg, saleté de subtilité de "static const" !
    static NSString* const kCellId;
    
    static NSString* const kCellId = @"CellIdentifier";
    
    Et bah avec ça kCellId vaut... nil et pas "CellIdentifier" !

    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 !
  • mpergandmpergand Membre
    février 2011 modifié #17
    Salut,

    Ouais, subtil le bug  :D

    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.

  • LexxisLexxis Membre
    02:18 modifié #18
    Si je ne me trompe pas déclarer une variables 'static' dans un header va créer une variable pour chaque module .c (ou .m ou autre) qui inclut ce header. Modifier la valeur à  partir d'un fonction d'un module (.c ou .m) ne vas pas modifier la valeur dans un autre module qui inclut le header.

  • AliGatorAliGator Membre, Modérateur
    02:18 modifié #19
    Oui tout à  fait Lexxis et je pense que c'est ce qui s'est passé... mais de là  à  trouver que l'erreur vient de là ... :P
  • muqaddarmuqaddar Administrateur
    02:18 modifié #20
    Du coup, Louka avait vu juste ?
  • AliGatorAliGator Membre, Modérateur
    02:18 modifié #21
    Pas tout à  fait c'est plus sioux que ça.

    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.
  • muqaddarmuqaddar Administrateur
    02:18 modifié #22
    ok. Merci.
Connectez-vous ou Inscrivez-vous pour répondre.