Ressources mémoires utilisées par mon app
igreg
Membre
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=';)' />
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
Mots clés:
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
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 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 ;-)