ARC und View-Hierachy

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • ARC und View-Hierachy

    Ich arbeite gerade das aktuelle Buch von Hillegass et al durch amazon.de/Cocoa-Programming-Ne…76958/ref=asap_bc?ie=UTF8). Dabei bin ich über folgendes gestolpert:

    “Weak references are commonly used in three places in Cocoa:
    Outlets to subviews: A window controller has a strong reference to the window, and a window has strong references (indirectly) to its view hierarchy. Therefore, a strong reference is unnecessary and could inadvertently keep a subtree of the view hierarchy alive.”

    Excerpt From: Aaron Hillegass, Adam Preble & Nate Chandler. “Cocoa Programming for OS X.” iBooks. itun.es/de/nOWY6.l

    Nun die Frage: Wie kann es bei einer View-Hierachy zu einen Retain-Cycle kommen wenn die Propertys, die die Subviews halten strong sind?

    Zum Hintergrund: Wenn ich den Interface Builder benutze mache ich die Propertys auch immer weak. Wenn ich aber das ganze im Code mache, mache ich sie strong, damit ich nicht bei der Definition eine lokale Variable benutzen muss. Wenn das aber zu einem Retain-Cycle führen kann, würde ich das natürlich lassen.

  • also von retain-cycle lese ich da nichts und sehe auch nichts.

    es steht ja nur dass dannn eben ein teil der view struktur am leben gehalten wird.

    also wenn du zb ein strong auf window und ein strong auf textview hast, das window dann released wird, existiert nachher das textview (und seine subviews) immer noch weil es ja strong ist.

  • Es gibt keinen Retaincycle, aber der Vorteil von weak outlets ist, dass Du diese nicht explizit freigegeben musst, sondern diese alle freigegeben werden, sobald der root view freigegeben wird. Das hilft Speicher sparen, denn u.U. kann eine riesige Viewhierarchie an einm outlet hängen (collection view). Es ist zwar lästig, ich würde aber bei der Viewerstellung trotzdem weak properties benutzen und diese mit einer lokalen Variable während der Erzeugung bis sie in die view Hierarchie eingefügt sind halten.

    Beste Grüße, Markus

  • gritsch schrieb:




    also wenn du zb ein strong auf window und ein strong auf textview hast, das window dann released wird, existiert nachher das textview (und seine subviews) immer noch weil es ja strong ist.
    Es geht aber um den Fall, wenn das window strong references auf die subviews hat. Sonst aber nichts strong references auf die subviews hat. Dann wird doch die View-Hierachy aufgeräumt, wenn das Window verschwindet, oder?

  • dasdom schrieb:

    gritsch schrieb:

    also wenn du zb ein strong auf window und ein strong auf textview hast, das window dann released wird, existiert nachher das textview (und seine subviews) immer noch weil es ja strong ist.
    Es geht aber um den Fall, wenn das window strong references auf die subviews hat. Sonst aber nichts strong references auf die subviews hat. Dann wird doch die View-Hierachy aufgeräumt, wenn das Window verschwindet, oder?
    es geht ja nicht darum dass das window strong references hat, sondern dass DU strong references zu irgendwelchen subviews erstellst (kann manchmal ja auch gewollt sein).

  • Markus Müller schrieb:

    Es gibt keinen Retaincycle, aber der Vorteil von weak outlets ist, dass Du diese nicht explizit freigegeben musst, sondern diese alle freigegeben werden, sobald der root view freigegeben wird. Das hilft Speicher sparen, denn u.U. kann eine riesige Viewhierarchie an einm outlet hängen (collection view). Es ist zwar lästig, ich würde aber bei der Viewerstellung trotzdem weak properties benutzen und diese mit einer lokalen Variable während der Erzeugung bis sie in die view Hierarchie eingefügt sind halten.

    Beste Grüße, Markus
    Aber wenn keine strong-Reference auf einer View liegt, wird diese doch auch frei gegeben, oder? Ich hab's noch nicht ganz verstanden.

  • gritsch schrieb:

    dasdom schrieb:

    gritsch schrieb:

    also wenn du zb ein strong auf window und ein strong auf textview hast, das window dann released wird, existiert nachher das textview (und seine subviews) immer noch weil es ja strong ist.
    Es geht aber um den Fall, wenn das window strong references auf die subviews hat. Sonst aber nichts strong references auf die subviews hat. Dann wird doch die View-Hierachy aufgeräumt, wenn das Window verschwindet, oder?
    es geht ja nicht darum dass das window strong references hat, sondern dass DU strong references zu irgendwelchen subviews erstellst (kann manchmal ja auch gewollt sein).
    Also ist es egal, ob die Subviews in einem Window oder View strong oder weak sind?

  • dasdom schrieb:

    Markus Müller schrieb:

    Es gibt keinen Retaincycle, aber der Vorteil von weak outlets ist, dass Du diese nicht explizit freigegeben musst, sondern diese alle freigegeben werden, sobald der root view freigegeben wird. Das hilft Speicher sparen, denn u.U. kann eine riesige Viewhierarchie an einm outlet hängen (collection view). Es ist zwar lästig, ich würde aber bei der Viewerstellung trotzdem weak properties benutzen und diese mit einer lokalen Variable während der Erzeugung bis sie in die view Hierarchie eingefügt sind halten.

    Beste Grüße, Markus
    Aber wenn keine strong-Reference auf einer View liegt, wird diese doch auch frei gegeben, oder? Ich hab's noch nicht ganz verstanden.
    du hast ja geschrieben dass du eine strong ivar/property dafür anlegst. brauchst du ja normalerweise nicht weil das window seine subviews am leben hällt.

  • dasdom schrieb:

    gritsch schrieb:

    dasdom schrieb:

    gritsch schrieb:

    also wenn du zb ein strong auf window und ein strong auf textview hast, das window dann released wird, existiert nachher das textview (und seine subviews) immer noch weil es ja strong ist.
    Es geht aber um den Fall, wenn das window strong references auf die subviews hat. Sonst aber nichts strong references auf die subviews hat. Dann wird doch die View-Hierachy aufgeräumt, wenn das Window verschwindet, oder?
    es geht ja nicht darum dass das window strong references hat, sondern dass DU strong references zu irgendwelchen subviews erstellst (kann manchmal ja auch gewollt sein).
    Also ist es egal, ob die Subviews in einem Window oder View strong oder weak sind?

    nein, wenn sie strong sind, dann musst du dich drum kümmern (oder eben potenziellen mem-leak).
    es gibt nur wenige fälle in denen man strong bzw retain verwenden muss (zb wenn man temporär teile der GUI aus dem fenster entfernt).

  • gritsch schrieb:

    es gibt nur wenige fälle in denen man strong bzw retain verwenden muss (zb wenn man temporär teile der GUI aus dem fenster entfernt).
    In der Regel verwendet man strong bei Root-Objekten des NIBs / Storyboards unter iOS. Unter OSX ist das anders. Da hat sich Cocoa, zumindest in älteren Versionen, nicht an die Speicherverwaltungsregeln gehalten und den Root-Objekten ein Retain gesendet, wenn es keinen Setter dafür gibt. Wahrscheinlich ist das seit ARC anders.
    „Meine Komplikation hatte eine Komplikation.“

  • little_pixel schrieb:

    Da gibt es einen Unterschied, ob Du auf iOS, oder OS X bist.

    Amin hat genau zu dem Thema mal hier einen langen Beitrag verfasst und die Sache im Detail erklärt.
    Aber keine Ahnung, wie der zu finden ist…

    Viele Grüße
    Siehst, da kann ich mich schon selbst nicht mehr dran erinnern.

    Also, was behauptet wird ist ja klar. Du hast etwa ein Outlet auf ein Window in einem Window-Controller und ein Outlet auf ein verySpecialView darin. Zweites kann weak sein, da ja das Fenster bereits den View hält.

    Das ist richtig.

    Aber auch blödsinnig.

    Dein Window-Controller wird a) ohnehin mit dem Fenster das Ewige suchen und b) wenn nicht mit einer nil-Property auf das View auch funktional keine Freude haben. Meist pst sich das "Problem" einfach schon deshalb, weil das doppelt haltende Objekt mit dem Erstobjekt verschwindet. In dem Zitat heißt es ja auch nicht einmal, dass eine strong-Property falsch wäre.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Der Unterschied macht sich wahrscheinlich nur bemerkbar, wenn der Viewcontroller seinen View aus dem Speicher schmeißt, so wie das in älteren iOS-Versionen der Fall war. Das geschah in der Regel auf eine Memory-Warning, und da waren starke Referenzen eher kontraproduktiv.

    Inzwischen schweißt iOS die Views aber selbst bei einer Memory-Warning nicht mehr raus.
    „Meine Komplikation hatte eine Komplikation.“