Ressources mémoires utilisées par mon app

igreg

Salut à  tous j'aurais besoin de votre avis sachant que c'est la première app mac que je souhaite release. Ma question porte sur la mémoire utilisée par mon app. En effet mon app est juste un utilitaire et je ne veux pas qu'il devienne un gouffre à  ressources !!



En gros une des fonctions du soft est de récupérer la playlist en cours et d'afficher les infos des tracks contenues dans cette playlist (via ScriptBridging).



Pour un test extrême, j'ai créé une playlist avec 2200 tracks. Le plus gourmand est bien sur la récupération des artworks présents dans le track. Pour corser la chose, les artworks peuvent atteindre la taille de 10Mo.



Après une journée à  optimiser le tout:



1 - premièrement récup des infos dites "light" (nom, artiste, durée ...) via GCD

2 - reload tableview sans les artworks

3 - a l'affichage de la cellule je récup l'artwork via scriptBridging (probablement l'opération la plus couteuse) et crée un thumbnail via une NSOperationQueue

4 - finalement avec KVO la cellule est notifié que le thumbnail est dispo et l'affiche.



Avec tout ceci, l'app consomme au max une 150 aines de Mo lorsque que l'on scroll la tableView. Cela vous parait-il correct ??



L'autre problème concerne la partie recup et création du thumbnail. En effet si mon NSOperationQueue

a un maxConcurrentOperationCount par défaut, les premiers scrolls de ma tableView sont saccadées, hors si je mets la valeur à  2 par exemple, aucun souci d'effet de "lags" mais évidement la création des thumbnail met plus de temps (même si cela reste respectable, car la tableView n'a pas une hauteur importante, et une animation (fade in/out) lors de l'affichage du thumbnail divertit l'oeil de l'utilisateur). Un conseil ?



Merci pour vos conseils /wink.png' class='bbc_emoticon' alt=';)' />

System

Pour info je suis l'auteur de Ecoute sur Mac (un peu à  l'abandon maintenant), je génère aussi des thumbnails mais via QuickLook uniquement (car moins gourmand et ne nécessite pas iTunes)

Du coup QuickLook me permet déjà  de définir la taille de mon thumbnail au lieu d'aller récupérer l'image en haute def (je suppute qu'il y a un système de cache côté QuickLook après tout).

Les thumbnails sont stockés dans un répertoire situé dans le dossier tmp du système. Malgré tout, je conserve les artworks en mémoire tant qu'on ne change pas de vue, et ce pour une plus grande rapidité lors du scroll. Mais de mon côté les thumbnails sont vraiment minus.. probablement 60x60 au max, donc je peux me le permettre. L'application s'en sort à  50Mo pas plus.. sachant qu'elle ne fait pas que ça évidemment.



Un bon conseil, passe à  tout GCD. Tu y gagneras vraiment en rapidité. Les NSOperation sont lourdes, et je les trouve plus destinées à  des opérations vraiment longues ou de la concurrency réseau

xyloweb

AFNetworking is for you !

igreg

Merci ldesroziers, je vais regarder du coté de QuickLook. Le problème avec GCD, c'est qu'il n'est pas possible de stopper une tache en cour d'exécution or j'en ai besoin par exemple, si la playlist en cours change alors que la queue qui traitait la précédente est toujours en exécution.



xyloweb pourquoi tu me parles de AFNetworking ?? (les images sont en local dans les fichiers audio).

igreg

arrff QuickLook fonctionne seulement avec les fichiers présents dans les dossiers spécifiés pour le sandboxing. Pas cool, car c'est vrai que les thumbnails sont générés vraiment super rapidement, mais je pense que beaucoup d'utilisateurs placent leurs fichiers en dehors du dossier "Music". Dommage !! /crazy.gif' class='bbc_emoticon' alt=' ' />

AP

Les NSOperation n'utilisent pas GCD ?

xyloweb

xyloweb pourquoi tu me parles de AFNetworking ?? (les images sont en local dans les fichiers audio).

autant pour moi, je pensais que tu récupérais les artworks sur le net... scusi ;-)