Czy IBOutlety powinny być mocne czy słabe pod ARC?

Tworzę wyłącznie na iOS 5 przy użyciu ARC. Czy IBOutlets UIView(s) i (podklasy) powinny być stronglub weak?

Następujące:

@property (nonatomic, weak) IBOutlet UIButton *button;

Pozbyłby się tego wszystkiego:

- (void)viewDidUnload
{
    // ...
    self.button = nil;
    // ...
}

Czy są jakieś problemy? Szablony są używane, strongpodobnie jak automatycznie generowane właściwości tworzone podczas łączenia bezpośrednio z nagłówkiem z edytora „Interface Builder”, ale dlaczego? Ten UIViewControllerjuż ma strongodniesienie do jego, viewktóry zachowuje swoje widoki.

Obecnie zalecaną najlepszą praktyką firmy Apple jest, aby IBOutlety były silne, chyba że słaba jest szczególnie potrzebna, aby uniknąć cyklu przechowywania. Jak wspomniano powyżej Johannes, zostało to skomentowane podczas sesji „Implementing UI Designs in Interface Builder” z WWDC 2015, gdzie inżynier Apple powiedział:

Ostatnią opcją, na którą chcę zwrócić uwagę, jest typ pamięci, który może być mocny lub słaby. Ogólnie rzecz biorąc, powinieneś wzmocnić swój punkt sprzedaży, szczególnie jeśli podłączasz go do widoku podrzędnego lub do ograniczenia, które nie zawsze będzie zachowane przez hierarchię widoków. Jedynym czasem, kiedy naprawdę potrzebujesz osłabić gniazdko, jest posiadanie niestandardowego widoku, który odwołuje się do czegoś, co tworzy kopię zapasową hierarchii widoków i ogólnie nie jest to zalecane.

Zapytałem o to na Twitterze inżyniera z zespołu IB, który potwierdził, że domyślne powinno być silne, a dokumenty programistów są aktualizowane.

https://twitter.com/_danielhall/status/620716996326350848 https://twitter.com/_danielhall/status/620717252216623104

OSTRZEŻENIE, ODPOWIEDZIALNA ODPOWIEDŹ : ta odpowiedź jest nieaktualna w rozumieniu WWDC 2015, aby uzyskać poprawną odpowiedź, patrz zaakceptowana odpowiedź (Daniel Hall) powyżej. Ta odpowiedź zostanie zapisana.

Podsumowane z biblioteki programistów :

Z praktycznego punktu widzenia gniazda w iOS i OS X powinny być zdefiniowane jako deklarowane właściwości. Outlety powinny być na ogół słabe, z wyjątkiem tych od właściciela pliku do obiektów najwyższego poziomu w pliku stalówki (lub, w iOS, scenie scenorysu), które powinny być mocne. Utworzone punkty sprzedaży zazwyczaj są zatem domyślnie słabe, ponieważ:

• Utworzone ujścia, na przykład w widokach podrzędnych widoku kontrolera widoku lub okna kontrolera okna, są dowolnymi odniesieniami między obiektami, które nie implikują własności.

• Silne gniazda są często określane przez klasy frameworka (na przykład ujście widoku UIViewController lub ujście okna NSWindowController).

  @property (weak) IBOutlet MyView *viewContainerSubview;
  @property (strong) IBOutlet MyOtherClass *topLevelObject;
  

Podczas gdy dokumentacja zaleca używanie weakwłaściwości do widoków podrzędnych, od iOS 6 wydaje się być dobrym rozwiązaniem strong(domyślny kwalifikator własności). Jest to spowodowane zmianą w UIViewControllertym, że widoki nie są już rozładowywane.

• Przed iOS 6, jeśli utrzymywałeś silne linki do widoków podrzędnych widoku kontrolera, jeśli główny widok kontrolera widoków został rozładowany, będą one podtrzymywać widoki podrzędne, dopóki kontroler widoku będzie w pobliżu.
• Od wersji iOS 6 widoki nie są już rozładowywane, ale ładowane raz, a następnie są wyświetlane tak długo, jak długo jest tam kontroler. Tak silne właściwości nie będą miały znaczenia. Nie będą również tworzyć silnych cykli odniesienia, ponieważ wskazują na silny wykres odniesienia.

To powiedziawszy, jestem rozdarty między używaniem

@property (nonatomic, weak) IBOutlet UIButton *button;

i

@property (nonatomic) IBOutlet UIButton *button;

w iOS 6 i później:

• Użycie weakwyraźnie oznacza, że ​​kontroler nie chce mieć prawa do przycisku.

• Ale pominięcie weaknie boli w iOS 6 bez rozładowywania widoku i jest krótsze. Niektórzy mogą zauważyć, że jest to również szybsze, ale jeszcze nie spotkałem aplikacji, która jest zbyt wolna z powodu weak IBOutlets.

• Nieużywanie weakmoże być postrzegane jako błąd.

Konkluzja: Od iOS 6 nie możemy się już mylić, dopóki nie używamy odciążania widoku. Czas na imprezę. ;)

Nie widzę z tym żadnego problemu. Przed ARC zawsze robiłem moje IBOutlety assign, ponieważ są już zachowane przez ich superwizje. Jeśli je weakwykonasz, nie powinieneś ich zerować w viewDidUnload, jak zauważyłeś.

Jedno zastrzeżenie: możesz obsługiwać iOS 4.xw projekcie ARC, ale jeśli tak, nie możesz go używać weak, więc musisz je zrobić assign, w którym to przypadku nadal chcesz zerować odniesienie, viewDidUnloadaby uniknąć zwisający wskaźnik. Oto przykład wiszącego błędu wskaźnika, którego doświadczyłem:

UIViewController ma UITextField dla kodu pocztowego. Używa CLLocationManager do odwrócenia geokodowania lokalizacji użytkownika i ustawienia kodu pocztowego. Oto wywołanie zwrotne delegata:

-(void)locationManager:(CLLocationManager *)manager
   didUpdateToLocation:(CLLocation *)newLocation
          fromLocation:(CLLocation *)oldLocation {
    Class geocoderClass = NSClassFromString(@"CLGeocoder");
    if (geocoderClass && IsEmpty(self.zip.text)) {
        id geocoder = [[geocoderClass alloc] init];
        [geocoder reverseGeocodeLocation:newLocation completionHandler:^(NSArray *placemarks, NSError *error) {
            if (self.zip && IsEmpty(self.zip.text)) {
                self.zip.text = [[placemarks objectAtIndex:0] postalCode];
            }
        }];    
    }
    [self.locationManager stopUpdatingLocation];
}

Odkryłem, że jeśli odrzuciłem ten widok we właściwym czasie i nie wprowadziłem zerowego self.zip viewDidUnload, wywołanie zwrotne dla delegata może zgłosić wyjątek złego dostępu do self.zip.text.

IBOutletpowinien być silny, ze względu na wydajność. Zobacz temat Storyboard Reference, Strong IBOutlet, Scene Dock w iOS 9

Jak wyjaśniono w tym akapicie, ujścia widoków podrzędnych widoku kontrolera widoku mogą być słabe, ponieważ te widoki podrzędne są już własnością obiektu najwyższego poziomu pliku stalówki. Jednak gdy ujście jest zdefiniowane jako słaby wskaźnik, a wskaźnik jest ustawiony, ARC wywołuje funkcję środowiska wykonawczego:

id objc_storeWeak(id *object, id value);

Spowoduje to dodanie wskaźnika (obiektu) do tabeli przy użyciu wartości obiektu jako klucza. Ta tabela jest nazywana słabą tabelą. ARC używa tej tabeli do przechowywania wszystkich słabych wskaźników twojej aplikacji. Teraz, gdy wartość obiektu zostanie zwolniona, ARC będzie iterować po słabej tabeli i ustawi słabe odniesienie na zero. Alternatywnie ARC może zadzwonić:

void objc_destroyWeak(id * object)

Następnie obiekt jest niezarejestrowany i obiekt objc_destroyWeak wywołuje ponownie:

objc_storeWeak(id *object, nil)

Księgowość związana ze słabym odniesieniem może potrwać 2–3 razy dłużej niż wydanie silnego odniesienia. Tak więc słabe odniesienie wprowadza narzut środowiska wykonawczego, którego można uniknąć, po prostu definiując gniazda jako silne.

Jak sugeruje Xcode 7 strong

Jeśli oglądasz sesję 407 WWDC 2015 Implementowanie projektów interfejsu użytkownika w Konstruktorze interfejsów , sugeruje (transkrypcja z http://asciiwwdc.com/2015/sessions/407 )

Ostatnią opcją, na którą chcę zwrócić uwagę, jest typ pamięci, który może być mocny lub słaby.

Zasadniczo powinieneś wzmocnić swoje ujście, szczególnie jeśli podłączasz ujście do widoku podrzędnego lub do ograniczenia, które nie zawsze będzie zachowane przez hierarchię widoków.

Jedynym czasem, kiedy naprawdę potrzebujesz osłabić gniazdko, jest posiadanie niestandardowego widoku, który odwołuje się do czegoś, co tworzy kopię zapasową hierarchii widoków i ogólnie nie jest to zalecane.

Więc wybiorę silny i kliknę Connect, który wygeneruje mój wylot.

W rozwoju iOS ładowanie NIB nieco różni się od rozwoju Maca.

W rozwoju Maca IBOutlet jest zwykle słabym odniesieniem: jeśli masz podklasę NSViewController, zachowany zostanie tylko widok najwyższego poziomu, a po zwolnieniu kontrolera wszystkie jego widoki podrzędne i ujścia zostaną automatycznie zwolnione.

UiViewController wykorzystuje kodowanie wartości klucza do ustawienia gniazd przy użyciu silnych referencji. Więc kiedy zwolnisz swój UIViewController, widok z góry zostanie automatycznie zwolniony, ale musisz także cofnąć przydział wszystkich jego gniazd w metodzie zwolnienia.

W tym poście z Big Nerd Ranch omawiają ten temat, a także wyjaśniają, dlaczego użycie silnej referencji w IBOutlet nie jest dobrym wyborem (nawet jeśli w tym przypadku jest zalecane przez Apple).

Jedną rzecz, na którą chciałbym tutaj zwrócić uwagę, a mianowicie, pomimo tego, co inżynierowie Apple stwierdzili w swoim własnym filmie WWDC 2015 tutaj:

https://developer.apple.com/videos/play/wwdc2015/407/

Apple ciągle zmienia zdanie na ten temat, co mówi nam, że nie ma jednej właściwej odpowiedzi na to pytanie. Aby pokazać, że nawet inżynierowie Apple są podzieleni na ten temat, spójrz na najnowszy przykładowy kod Apple, a zobaczysz, że niektórzy ludzie używają słabych, a niektórzy nie.

W tym przykładzie Apple Pay zastosowano słaby: https://developer.apple.com/library/ios/samplecode/Emporium/Listings/Emporium_ProductTableViewController_swift.html#//apple_ref/doc/uid/TP40016175-Emporium_ProductTableViewController_switch

Podobnie jak w przypadku obrazu w obrazie: https://developer.apple.com/library/ios/samplecode/AVFoundationPiPPlayer/Listings/AVFoundationPiPPlayer_PlayerViewController_swift.html#//apple_ref/doc/uid/TP40016166-AVFlayer

Podobnie jak przykład Listera: https://developer.apple.com/library/ios/samplecode/Lister/Listings/Lister_ListCell_swift.html#//apple_ref/doc/uid/TP40014701-Lister_ListCell_swift-DontLinkElementID_57

Podobnie jak przykład z lokalizacją podstawową: https://developer.apple.com/library/ios/samplecode/PotLoc/Listings/Potloc_PotlocViewController_swift.html#//apple_ref/doc/uid/TP40016176-Potloc_PotlocViewController_swlement

Podobnie jak widok kontrolera przykład podglądu: https://developer.apple.com/library/ios/samplecode/ViewControllerPreviews/Listings/Projects_PreviewUsingDelegate_PreviewUsingDelegate_DetailViewController_swift.html#//apple_ref/doc/uid/TP40016546-Projects_PreviewUsingDelegate_PreviewUsingDelegate_DetailViewController_swift-DontLinkElementID_5

Podobnie jak w przypadku przykładu HomeKit: https://developer.apple.com/library/ios/samplecode/HomeKitCatalog/Listings/HMCatalog_Homes_Action_Sets_ActionSetViewController_swift.html#//apple_ref/doc/uid/TP40015048-HMCatalog_Hift_Serv_Data_Widoku

Wszystkie są w pełni zaktualizowane dla iOS 9 i wszystkie używają słabych gniazd. Z tego dowiadujemy się, że A. Problem nie jest tak prosty, jak się wydaje. B. Apple wielokrotnie zmieniało zdanie, i C. Możesz używać wszystkiego, co cię uszczęśliwia :)

Specjalne podziękowania dla Paula Hudsona (autora www.hackingwithsift.com), który udzielił mi wyjaśnień i odniesień do tej odpowiedzi.

Mam nadzieję, że to trochę lepiej wyjaśnia ten temat!

Dbać.

Od WWDC 2015 odbywa się sesja dotycząca implementacji projektów interfejsu użytkownika w Konstruktorze interfejsów . Około 32 minuty mówi, że zawsze chcesz wzmocnić swoją @IBOutlet siłę .

Bądź świadomy, IBOutletCollectionpowinien być @property (strong, nonatomic).

Wygląda na to, że coś się zmieniło przez lata, a teraz Apple zaleca stosowanie silnego w ogóle. Dowody na ich sesję WWDC znajdują się w sesji 407 - Implementacja projektów interfejsu użytkownika w interfejsie Konstruktora i rozpoczyna się o 32:30. Moja uwaga z tego, co mówi, brzmi (prawie, jeśli nie dokładnie, cytując go):

• połączenia wyjściowe powinny być silne, szczególnie jeśli połączymy widok podrzędny lub ograniczenie, które nie zawsze jest zachowywane przez hierarchię widoków

• słabe połączenie wylotowe może być potrzebne podczas tworzenia niestandardowych widoków, które zawierają odniesienia do czegoś, co zostało utworzone w hierarchii widoków i ogólnie nie jest zalecane

Na innych oddziałach powinno być teraz zawsze silne, o ile niektóre z naszego niestandardowego widoku nie tworzą cyklu przechowywania z niektórymi widokami w hierarchii widoków

EDYTOWAĆ :

Niektórzy mogą zadać pytanie. Czy utrzymywanie go z silnym odwołaniem nie tworzy cyklu przechowywania, ponieważ kontroler widoku głównego i widok właściciela zachowuje odniesienie do niego? Albo dlaczego to się stało? Myślę, że odpowiedź jest wcześniejsza w tym wykładzie, kiedy opisują, jak stalówki są tworzone z Xib. Istnieje oddzielna końcówka stworzona dla VC i dla widoku. Myślę, że to może być powód, dla którego zmieniają zalecenia. Byłoby jednak miło uzyskać głębsze wyjaśnienie od Apple.

Myślę, że najważniejszą informacją jest: Elementy w Xib są automatycznie wyświetlane w pod-widoku. Wywiady to NSArray. NSArray jest właścicielem jego elementów. itd. mają silne wskazówki. Więc w większości przypadków nie chcesz tworzyć kolejnego silnego wskaźnika (IBOutlet)

A dzięki ARC nie musisz nic robić viewDidUnload