Wo ist das Speicherleck hier?

Instrumente sagen mir, dass es in diesem Code ein mem-Leck gibt, aber ich kann es nicht finden .... keine Hilfe? Entschuldigung oder die Newbie Frage.Wo ist das Speicherleck hier?

- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath 
{ 
    int altoBufferCelda = 26; 
    Mensaje *msg = (Mensaje *)[model.mensajes objectAtIndex:indexPath.row]; 

    CGSize txtSize = [msg.texto sizeWithFont:[UIFont systemFontOfSize:17.0f] constrainedToSize:CGSizeMake(222, 222) lineBreakMode:UILineBreakModeTailTruncation]; 

    [alturasDinamicas setObject:[NSNumber numberWithFloat:(txtSize.height + altoBufferCelda)] forKey:[NSNumber numberWithInt:indexPath.row]]; 

    return txtSize.height + altoBufferCelda;  
}

Quelle

2009-07-03 nico

was soll das tun? Was ist los? Welche "Instrumente"? Es hilft Leuten, Ihnen zu helfen, wenn Sie mehr Informationen geben – marcgg

marcgg, Entschuldigung für das Fehlen von Informationen. Dies ist der für iPhone geschriebene Code von objective-c. Die Methode ist Teil eines Delegaten, der zur Steuerung eines GUI-Steuerelements verwendet wird, das den iPhone-Entwicklern bekannt ist. Und Instruments ist ein Entwicklungswerkzeug, um Mem-Leaks und viele andere Dinge zu erkennen. – nico

@marcgg Ich würde sagen, dass es bei Cocoa-Entwicklern ziemlich allgemein bekannt ist, dass "Instruments" die Profiling-Anwendung ist, die zu den Entwicklertools gehört. Zum Zweck, ist "heightForRowAtIndexPath:" nicht klar genug? –

~~Ich würde sagen: [NSNumber numberWithFloat]~~

Es wird für Sie ein Autoreleased Objekt zuordnen. Das iPhone wird nicht Müll gesammelt, nur Referenz gesammelt. Und da Sie den Speicher, den Sie zuweisen, nicht freigeben, bevor Sie die Methode verlassen, meldet Instruments dies als ein Leck.

Da dies derzeit akzeptiert wird, werde ich irgendwie meine Antwort ändern.

Instrumente ist kein göttliches Edikt. Es könnte falsch sein. Verwenden Sie es als eine starke Richtlinie für das, was Sie betrachten sollten, aber wenn Sie ehrlich gesagt nichts falsch oder undicht mit dem Code finden, gehen Sie einfach weiter.

Quelle

2009-07-03 22:32:42

sollte ich dieses Leck ignorieren? oder etwas anderes ausprobieren? Vielen Dank! – nico

Das ist nicht korrekt. [NSNummer numberWithFloat:] gibt ein automatisch freigegebenes Objekt zurück. Du hast Recht, dass es kein GC auf dem iPhone gibt, aber es gibt definitiv Autorelease-Pools. Ich sehe kein Leck im eigentlichen Code. Es ist * möglich * es gibt ein Leck im UIKit-Framework selbst. –

Autorelease-Pools sind nicht dasselbe wie Garbage Collection; Wenn ein automatisch freigegebenes Objekt nicht beibehalten wird, wird es am Ende des aktuellen Ereignisses freigegeben. Dies gilt sowohl für das iPhone als auch für OS X. Durch die Garbage Collection werden Objekte freigegeben, sobald sie nicht mehr im Fokus sind und kein anderes Objekt mehr vorhanden ist Zugang zu ihnen haben (sie sind unerreichbar). numberWithFloat gibt ein NSNumber-Objekt zurück, das automatisch freigegeben wurde und daher nicht freigegeben werden muss, da es in der obigen Methode nicht beibehalten wird. –

Ich kann keinen Speicherverlust in Ihrem Code sehen. Toast weist darauf hin, dass Instrumente nicht immer genau sind. Dies liegt vor allem daran, dass selbst der Code aus den Apple Frameworks Speicherlecks enthält, die ebenfalls von den Instrumenten gemeldet werden.

Wenn Sie XCode 3.2 verwenden, können Sie im Menü Erstellen den Befehl Erstellen und analysieren wählen, der Ihren Code auf Fehler untersucht, die normalerweise vom Compiler nicht erkannt werden. Dies zeigt Ihnen viele mögliche Speicherlecks, die dadurch entstehen, dass Sie vergessen haben, ein Objekt freizugeben.

Quelle

2009-11-07 15:29:38 Alfonso

Wo ist das Speicherleck hier?

Antwort

Verwandte Themen