2009-06-27 4 views
1

Je viens de finir de débarrasser mon projet de fuites, mais il y a encore des milliers d'objets dans la catégorie "GeneralBlock-0". Le nombre d'allocations nettes est à travers le toit (il se rapproche d'un million que je tape), mais aucun d'entre eux sont des fuites et aucun d'entre eux ont une taille supérieure à 0 octets.Des milliers de nouveaux objets de taille 0 sont ajoutés à mon total net toutes les secondes, devrais-je m'inquiéter?

MISE À JOUR & EDIT:

QuartzCore est responsable de tous les objets incriminés.

Les appelants responsables sont (dans l'ordre d'exécution par itération de la boucle de jeu:

-[CALayer setPosition:] 
x_hash_table_new_ // x2 
hash_table_modify 
-[CALayer setPosition:] // x9 
-[CALayer(CALayerPrivate)_copyRenderLayer:flags:] //x13 

Lorsqu'il est exécuté sur un dispositif, 48 octets objets de taille sont attribués sous GeneralBlock-64, 128, 256 etc., avec . ces mêmes propriétés que décrit ci-dessus Cette est inacceptable car elle provoque évidemment un ralentissement significatif C'est ce code dans mon projet, le problème est imputable à:.

topRow.center = CGPointMake(topRow.center.x,topRow.center.y-PIXELS_PER_FRAME); 
while (nextRow = thisTopRow.below) { //stops running when thisTopRow.below is nil 
    nextRow.center = CGPointMake(nextRow.center.x,nextRow.center.y-PIXELS_PER_FRAME);  
    if (nextRow.center.y+20 < 401 && !nextRow.userInteractionEnabled) 
     [nextRow enableInteraction];   
    thisTopRow = nextRow; 
} 

I w comme sous l'impression que CGPoint était un type, et serait désaffecté à la fin du bloc de code. Pourquoi est-ce que ça monopolise ma mémoire? Si tout se résume à cela, je vais télécharger le fichier de trace que j'ai enregistré dans les instruments pour toute personne intéressée, mais je suis sûr que j'ai tout couvert.

+0

Ce même problème se produit dans iTennis par iCodeBlog.com, un tutoriel que je commençais à utiliser. Toutes les choses pointent vers changer la position d'un UIImageView, soit en changeant le centre ou le cadre. – Tozar

Répondre

1

En supposant que vous pouvez dupliquer le comportement sous le simulateur, vérifiez que le RSIZE de votre application n'augmente pas aussi en utilisant 'top -u' dans un Terminal. Ceci est probablement dû au fait que QuartzCore a implémenté son propre allocateur et sa propre zone d'allocation, mais qu'il n'a pas complètement intégré le mécanisme de collecte de statistiques utilisé par Instruments.

S'il vous plaît déposer un bug.

+0

Vous m'avez perdu là ... pouvez-vous expliquer ce que vous essayez de me dire en termes simples? – Tozar

+0

La commande 'top' affiche des informations sur les processus. Bill suggère d'exécuter le haut de Terminal et d'observer le comportement de RSIZE (taille de la mémoire résidente) pour votre application. Il suggère que Instruments ne peut pas surveiller la mémoire QuartzCore, qui peut être allouée dans une zone différente (région de la mémoire) que la valeur par défaut pour les objets Objective-C "normaux". Fondamentalement, si Instruments dit que vous avez des fuites massives, mais que 'top' montre que RSIZE reste stable, alors les Instruments ont tort car ils n'obtiennent pas les stats correctes pour la mémoire de QuartCore.Si oui, envoyez un bogue - http://bugreport.apple.com –

0

Même problème aussi ... Les octets zéro sont alloués dans le simulateur mais dans le périphérique pour chaque appel de méthode dans CALayer augmente ma mémoire avec 48 octets.

Cela entraîne des problèmes de mémoire.

Murali.

+0

Oui, vous et niv éprouvez le même problème que moi. Moi aussi, j'obtiens le coût d'allocation de 48 octets pour chaque instance d'UIImageView changeant d'emplacement uniquement sur l'appareil, mais je n'utilise pas d'UIScrollView. Aussi, gardez à l'esprit que vous avez posté une réponse lorsque cet article n'offre pas de réponse à la question. À l'avenir, veuillez utiliser le bouton "Ajouter un commentaire" ci-dessous la question pour faire un commentaire et réserver la section "Réponses" pour des solutions. – Tozar

0

Je suis également confronté à ce problème. J'utilise A UIScrollView avec quelques UIImageViews à l'intérieur, et chaque fois que le décalage de la vue défilement change il y a un appel à - [CALayer (CALayerPrivate) _copyRenderLayer: flags:] étant fait qui augmente la mémoire de 48 octets.

Encore une fois - sur le simulateur, cela est enregistré comme 0 octets, mais sur mon appareil, il ronge constamment ma mémoire.

+0

C'est aussi un problème qui me vient à l'esprit. S'il vous plaît voir le commentaire sur le post de Murali. En tant que nouvel utilisateur, c'est quelque chose que vous aurez besoin de lire. – Tozar

Questions connexes