Meine Vermutung ist, dass durch die Deklaration der Zeichenfolge als statisch jedes Mal, wenn es in -dequeueReusableCellWithIdentifier:CellIdentifierforIndexPath: übergeben wird, derselbe Zeiger jedes Mal verwendet wird (wie statisch deklarierte Variablen nur einmal auf dem Heap, sehr früh in der Ausführung eines Programms)
[NSString -isEqualToString:] wird höchstwahrscheinlich implementiert, um zuerst einen Zeigervergleich durchzuführen, gefolgt von einem zeichenweisen Vergleich als Fallback, von dem ich vermutete, dass er bei jeder Iteration ein paar Zyklen abschneidet.
Es gibt nicht viel zu gewinnen, wie (a) Tabelle Zellwiederaufnahme arbeitet auf einer typisch sehr kleinen Satz von Zellen und ist gut optimiert, und (b) Tabellenaktualisierung ist stoßweise - es passiert einmal und Dann passiert es nicht mehr, bis der Benutzer scrollt oder die Anwendungslogik den Inhalt ändert. Wenn Sie 100 Mal pro Sekunde -reloadTable aufrufen, ist Ihre Anwendungslogik offensichtlich nicht in Ordnung.
Ich vermute, das statische Schlüsselwort ist ein Rest Legacy-Konvention - vielleicht zurück in den Tag, Apple hashed auf den Zeiger, anstatt eine ordnungsgemäße Zeichenfolge vergleichen.
Wenn Sie "jedes Mal ein Mal machen" meinen, "einen konstanten Zeiger in eine Stapelvariable zu schieben", ist das sicher. Aber es ist genauso teuer wie "int i = 3;" zu sagen, da der Compiler "@" Identifier "' in eine Konstante kompiliert hat. Die einzige Zeit, zu der die Statik tatsächlich von Vorteil wäre, ist, wenn die Zeichenkette zur Laufzeit erstellt wird, anstatt eine konstante Zeichenkette zu verwenden. –
Das ist immer noch ein Vorteil. Es schaltet bei jedem Start der Methode zwei Prozessorzyklen aus (was sehr oft vorkommen kann). – ughoavgfhw
@hughoavgfhw Ja, aber macht es Ihre Binärdatei nicht größer und macht Ihre App mehr Speicher? – ma11hew28