Ce atomicși nonatomicînseamnă în declarațiile de proprietate?
@property(nonatomic, retain) UITextField *userName;
@property(atomic, retain) UITextField *userName;
@property(retain) UITextField *userName;
Care este diferența operațională între aceste trei?
Ultimele două sunt identice; „atomic“ este comportamentul implicit ( rețineți că nu este de fapt un cuvânt cheie, acesta este specificat numai prin absența - nonatomicatomics - a adăugat ca un cuvânt cheie în versiunile recente ale LLVM / zăngănit).
Presupunând că sunteți @synthesizing implementările metode, atomice vs. schimbari non-atomice codul generat. Dacă scrieți propriile setter / getteri atomic / nonatomic / reține / atribui / copie sunt doar consultativ. (Notă: @synthesize este acum comportamentul implicit în versiunile recente ale LLVM Există , de asemenea , nu trebuie să declare variabile de instanta, acestea vor fi sintetizate în mod automat, de asemenea, și va avea o. _Prefixate cu numele lor , pentru a preveni accesul accidental directă).
Cu „atomic“, Setter / getter sintetizat se va asigura că o întreagă valoare este întotdeauna returnată de getter sau stabilit de setter, indiferent de activitate setter pe orice alt fir. Adică, dacă firul A este în mijlocul getter în timp ce firul B solicită setter, o valoare reală viabilă - un obiect autoreleased, cel mai probabil - va fi returnat apelantului în A.
În nonatomic, nici o astfel de garanții sunt făcute. Astfel, nonatomiceste considerabil mai rapid decât „atomic“.
Ce „atomic“ nu nu face nici o garanție este de a face cu privire la protecția firelor de execuție. Dacă firul A apelează getter simultan cu firul B și C apelarea setter cu valori diferite, firul A se poate obține oricare dintre cele trei valori returnate - o înainte de orice setter fiind numită sau oricare dintre valorile transmise în setteri în B și C. de asemenea, obiectul se poate termina cu valoarea de la B sau C, nici un fel de a spune.
Asigurarea integrității datelor - una dintre provocările principale ale programării multi-threaded - se realizează prin alte mijloace.
Se adaugă la acest lucru:
atomicity de o singură proprietate, de asemenea, nu poate garanta siguranța firului atunci când mai multe proprietăți dependente sunt în joc.
Considera:
@property(atomic, copy) NSString *firstName;
@property(atomic, copy) NSString *lastName;
@property(readonly, atomic, copy) NSString *fullName;
În acest caz, firul A ar putea fi redenumirea obiectului de apel setFirstName:și apoi de asteptare setLastName:. Între timp, firul B poate apela fullNameîntre două apeluri înfãºuraþi și va primi noul nume de prima cuplat cu vechiul nume de familie.
Pentru a rezolva acest lucru, aveți nevoie de un model de tranzacțional . Adică un alt fel de sincronizare și / sau excludere care permite să excludă accesul la în fullNametimp ce proprietățile dependente sunt în curs de actualizare.
Acest lucru este explicat în Apple documentația , dar mai jos sunt câteva exemple de ceea ce se întâmplă de fapt. Rețineți că nu există nici un „atomic“ de cuvinte cheie, dacă nu specificați „nonatomic“ , atunci proprietatea este atomic, dar specificând „atomic“ explicit va avea ca rezultat o eroare.
//@property(nonatomic, retain) UITextField *userName;
//Generates roughly
- (UITextField *) userName {
return userName;
}
- (void) setUserName:(UITextField *)userName_ {
[userName_ retain];
[userName release];
userName = userName_;
}
Acum, varianta atomica este un pic mai complicat:
//@property(retain) UITextField *userName;
//Generates roughly
- (UITextField *) userName {
UITextField *retval = nil;
@synchronized(self) {
retval = [[userName retain] autorelease];
}
return retval;
}
- (void) setUserName:(UITextField *)userName_ {
@synchronized(self) {
[userName_ retain];
[userName release];
userName = userName_;
}
}
Practic, versiunea atomică trebuie să ia un sistem de blocare pentru a garanta siguranța firului, și, de asemenea, este bumping numărul de ref pe obiect (iar numărul AutoreleasePool să-l echilibru), astfel încât obiectul este garantat să existe pentru apelant, în caz contrar este o condiție potențială cursă dacă un alt fir stabilește valoarea, determinând numărul de ref să scadă la 0.
Există de fapt, un număr mare de variante diferite de modul în care funcționează aceste lucruri, în funcție de faptul dacă proprietățile sunt valori sau obiecte scalare, și cum să păstreze, copie, numai citire, nonatomic, etc interacționa. În general, sintetizatoare de proprietate doar știu cum să facă „ceea ce trebuie“ pentru toate combinațiile.
Cel mai bun mod de a înțelege diferența este folosind următorul exemplu.
Să presupunem că există o proprietate șir atomic numit „nume“, iar dacă te sun de [self setName:@"A"]la firul A, apelați [self setName:@"B"]la firul B, și de apel de [self name]la fir C, atunci toate operațiunile de pe fire diferite , vor fi efectuate în serie , ceea ce înseamnă , dacă un fir se execută un setter sau getter, atunci alte fire va aștepta.
Acest lucru face ca proprietate „nume“ citire / scriere în condiții de siguranță, dar dacă un alt fir, D, solicită [name release]simultan , atunci această operațiune s - ar putea produce un accident , deoarece nu există nici un apel setter / getter implicat aici. Ceea ce înseamnă că un obiect este de citire / scriere în condiții de siguranță (ATOMICA), dar nu și cu firele de executie ca un alt fire pot trimite simultan orice tip de mesaje la obiect. Dezvoltatorul ar trebui să asigure firului de siguranță pentru astfel de obiecte.
În cazul în care proprietatea „numele“ era nonatomic, atunci toate firele din exemplul de mai sus - A, B, C și D se va executa simultan producând orice rezultat imprevizibil. In cazul atomic, fie unul dintre A, B sau C, se va executa în primul rând, dar D poate executa în continuare în paralel.
Sintaxa și semantica sunt deja bine definite de alte răspunsuri excelente la această întrebare. Deoarece executie si performanta nu sunt detaliate bine, voi adăuga răspunsul meu.
Care este diferența funcțională între aceste 3?
Aș considerat întotdeauna atomică ca implicit destul de curios. La nivelul de abstractizare la care lucrăm, folosind proprietățile atomice pentru o clasă ca vehicul pentru a atinge 100% a firului de siguranță este un caz colț. Pentru programele multithreaded cu adevărat corecte, intervenția de programator este aproape sigur o cerință. În același timp, caracteristicile de performanță și de execuție nu au fost încă detaliate în profunzime. După ce a scris unele programe puternic multithreaded de-a lungul anilor, am fost declararea proprietăților mele ca nonatomictot timpul , deoarece atomic nu a fost sensibil pentru orice scop. În timpul discuției cu privire la detaliile proprietăților atomice și nonatomic această întrebare , am făcut unele de profiluri întâlnite unele rezultate curioase.
Execuţie
O.K. Primul lucru pe care aș dori să clarific faptul că este punerea în aplicare de blocare este captată definit de punere în aplicare. Louis folosește @synchronized(self)în exemplul lui - am văzut acest lucru ca o sursă comună de confuzie. Punerea în aplicare nu de fapt utiliza @synchronized(self); se folosește la nivel de obiect încuietori de spin . Ilustrare Louis este bun pentru o ilustrare la nivel înalt , folosind constructe suntem toți familiarizați cu, dar este important să se știe că nu folosește @synchronized(self).
O altă diferență este că proprietățile atomice va păstra / ciclu de eliberare a obiectelor în cadrul getter.
Performanţă
Iată partea interesantă: Performanța folosind proprietatea atomică accesează în necontestată ( de exemplu , un singur fir) de cazuri poate fi într - adevăr foarte rapid , în unele cazuri. In mai putin ideale cazuri, utilizarea de accesări atomice poate costa mai mult de 20 de ori aeriene de nonatomic. Deși contestată cazul folosind 7 fire a fost de 44 de ori mai lent pentru struct trei octeți (2.2 GHz Core i7 Quad Core, x86_64). Struct trei octeți este un exemplu de o proprietate foarte lent.
Interesant notă: definite de utilizator Conturi cu acces din struct trei octeți au fost de 52 de ori mai rapid decât sintetizate atomice Conturi cu acces; sau 84% viteza de nonatomic sintetizate Conturi cu acces.
Obiectele în cazurile contestate pot depăși, de asemenea, de 50 de ori.
Datorită numărului de optimizări și variații în implementări, este destul de dificil să se măsoare impactul lumea reală în aceste contexte. S-ar putea auzi de multe ori ceva de genul „Ai încredere în ea, decât dacă profilul și pentru a găsi că este o problemă“. Datorită nivelului de abstractizare, este de fapt destul de dificil să se măsoare impactul real. Muncind costurile reale de profiluri pot fi foarte consumatoare de timp, și din cauza abstracțiuni, destul de inexacte. De asemenea, ARC vs MRC poate face o mare diferență.
Deci , să pas înapoi, nu concentrându -se pe punerea în aplicare a proprietății accesări, vom include suspecții obișnuiți , cum ar fi objc_msgSend, și să examineze unele din lumea reală rezultate la nivel înalt pentru multe apeluri la un NSStringgetter în necontestate cazuri (valori în secunde):
După cum ați ghicit, probabil, numărul de referință de activitate / mersul pe bicicleta este un factor care contribuie semnificativ cu Atomics și sub ARC. Veti vedea, de asemenea, diferențe mai mari în cazurile contestate.
Deși am să acorde o atenție aproape de performanță, eu încă mai spun Semantica Primul! . În același timp, performanța este o prioritate scăzută pentru mai multe proiecte. Cu toate acestea, știind detaliile de execuție și costurile tehnologiilor pe care le folosiți cu siguranță nu doare. Ar trebui să utilizați tehnologia potrivita pentru nevoile tale, scopuri și abilități. Să sperăm că acest lucru va salva câteva ore de comparații și pentru a vă ajuta să ia o decizie mai bine informate atunci când se concep programe.
Atomic = fir de siguranță
Non-atomic = Nici un fir de siguranță
Variabilele de instanta sunt thread-safe în cazul în care se comportă în mod corect atunci când este accesat din fire multiple, indiferent de programarea sau intercalarea a executării acestor fire de mediu de rulare, și fără o sincronizare suplimentară sau de alt tip de coordonare din partea codului de asteptare.
În cazul în care un fir schimbă valoarea instanței valoarea modificată este disponibilă pentru toate firele, și doar un singur fir poate schimba valoarea la un moment dat.
atomic:în cazul în care variabila instanță se va fi accesată într-un mediu multithread.
atomic:Nu la fel de repede ca , nonatomicdeoarece nonatomicnu are nevoie de nici o lucrare câine de pază cu privire la acest din timpul rulării.
nonatomic:În cazul în care variabila instanță nu va fi schimbată de mai multe fire îl puteți folosi. Acesta îmbunătățește performanța.
Am găsit o explicație destul de bine pus proprietăților atomice și non-atomice aici . Iată un text relevant din aceeași:
„atomic“ înseamnă că nu poate fi defalcate. În termeni / programare OS un apel de funcție atomică este una care nu poate fi întreruptă - întreaga funcție trebuie să fie executată, și nu schimbat în afara procesorului de context , de obicei , sistemul de operare de comutare până când este completă. Doar în cazul în care nu a știut: deoarece procesorul poate face doar un singur lucru la un moment dat, sistemul de operare se rotește de acces la CPU la toate procesele care rulează în puțin timp-felii, pentru a da iluzia de multitasking. CPU Planificatorul poate (și nu) întrerupe un proces în orice punct în executarea acestuia - chiar și în funcția de apel la mijlocul. Deci , pentru acțiuni cum ar fi actualizarea variabilelor contra partajate în cazul în care două procese ar putea încerca să actualizeze variabila, în același timp, ele trebuie să fie executate „atomically“, adică, fiecare acțiune de actualizare trebuie să termine în întregime înainte de orice alt proces poate fi schimbat pe produsul PROCESOR.
Așa că aș fi ghicit că atomică, în acest caz, înseamnă metodele cititorului de atribut nu poate fi întreruptă - în vigoare în sensul că variabila (e) fiind citite prin metoda nu se poate schimba jumătatea lor valoare de drum prin, deoarece unele fire de alt / apel / funcția devine au schimbat pe CPU.
Deoarece atomicvariabilele nu poate fi întreruptă, valoarea conținută de acestea în orice punct este (fir-blocare) garantat să fie nedeteriorat , cu toate că, asigurând această blocare fir face acces la ele mai lent. non-atomicvariabile, pe de altă parte, nu fac nici o astfel de garanție , dar nu oferă luxul de acces mai rapid. Pentru a rezuma, du - te cu non-atomicatunci când știi variabilele nu vor fi accesate de mai multe fire simultan și lucruri de viteză în sus.
Dupa ce a citit atât de multe articole, stiva de posturi preaplinului și de a face aplicații demonstrative pentru a verifica atributele de proprietate variabile, am decis să pun toate informațiile atributele împreună:
atomic // Mod implicitnonatomicstrong = retain // Mod implicitweak = unsafe_unretainedretainassign // Mod implicitunsafe_unretainedcopyreadonlyreadwrite // Mod implicitÎn articol atributele de proprietate variabile sau modificatori în iOS puteți găsi toate atributele menționate mai sus, și că te va ajuta cu siguranta.
atomic
atomic înseamnă doar un singur fir de acces variabila (tip static).atomic este fir în condiții de siguranță.atomic este comportamentul implicitExemplu:
@property (retain) NSString *name;
@synthesize name;
nonatomic
nonatomic înseamnă acces multiplu fir variabila (de tip dinamic).nonatomic este fir nesigur.nonatomicNU este implicit comportamentul. Trebuie să adăugați nonatomiccuvântul cheie în atributul de proprietate.Exemplu:
@property (nonatomic, retain) NSString *name;
@synthesize name;
Cea mai simplă răspuns mai întâi: Nu există nicio diferență între a doua dvs. două exemple. În mod implicit, de proprietate sunt atomice Conturi cu acces.
atomice într-un Conturi cu acces mediu non gunoi colectate (de exemplu, atunci când se utilizează reține / eliberare / AutoreleasePool) va folosi un sistem de blocare pentru a se asigura că un alt fir nu interferează cu setarea corectă / obținerea a valorii.
A se vedea „ Performanță și Threading secțiunea“ a documentației Apple Objective-C 2.0 pentru unele mai multe informații și pentru alte considerente atunci când crearea de aplicații multi-thread.
garanții atomice care accesul la proprietate se va efectua într-o manieră atomică. De exemplu, acesta returnează întotdeauna o obiecte complet inițializată, orice get / set de proprietate pe un singur fir trebuie să completeze înainte de alta poate accesa.
Dacă vă imaginați următoarea funcție care apar pe două fire dintr-o dată puteți vedea de ce rezultatele nu ar fi destul.
-(void) setName:(NSString*)string
{
if (name)
{
[name release];
// what happens if the second thread jumps in now !?
// name may be deleted, but our 'name' variable is still set!
name = nil;
}
...
}
Pro: Întoarcere de obiecte complet inițializată de fiecare dată când cea mai bună alegere în caz de multi-threading face.
Contra: performanță lovit, face un pic mai lent de execuție
Spre deosebire de Atomic, nu se asigură obiect complet inițializată reveni de fiecare dată.
Pro: execuție extrem de rapid.
Contra: Sansele de valoare gunoi în caz de multi-threading.
Atomic înseamnă doar un singur fir accesează variabila (de tip static). Atomic este thread-safe, dar este lent.
Nonatomic înseamnă mai multe fire a avea acces la variabila (de tip dinamic). Nonatomic este fir nesigur, dar este rapid.
Atomic este fir în condiții de siguranță , este lent și ea bine-(nu , asigura garantat) că numai valoarea blocat este furnizat indiferent de cât de multe fire încearcă de acces în aceeași zonă. Când se utilizează atomică, o bucată de cod scrise în interiorul acestei funcții devine parte a secțiunii critice, la care un singur fir poate executa la un moment dat.
Acesta asigură numai siguranța firului; aceasta nu garantează că. Ceea ce vreau sa spun este sa angajeze un șofer expert pentru tine masina, totuși nu garantează masina nu va întâlni un accident. Cu toate acestea, probabilitatea rămâne cea mai mică.
Atomic - nu poate fi rupt în jos, astfel încât rezultatul este de așteptat. Cu nonatomic - atunci când un alt fir de acces în zona de memorie se poate modifica, astfel încât rezultatul este neașteptat.
Cod Discuție:
Atomic face getter și setter firului de proprietate în condiții de siguranță. de exemplu, în cazul în care u au scris:
self.myProperty = value;
este fir în condiții de siguranță.
[myArray addObject:@"Abc"]
NU este fir în condiții de siguranță.
Nu există nici un astfel de cuvânt cheie „atomic“
@property(atomic, retain) UITextField *userName;
Putem folosi cele de mai sus ca
@property(retain) UITextField *userName;
A se vedea Stack Overflow întrebare Sunt obtinerea de probleme , dacă am folosi @property (atomic, retine) NSString * myString .
Implicită este atomic, acest lucru înseamnă că vă costă performanța de fiecare dată când utilizați proprietatea, dar este sigur fir. Ce Obiectiv-C nu este stabilit un sistem de blocare, astfel încât numai firul real poate avea acces la variabila, atâta timp cât setter / getter este executat.
Exemplu cu MRC unei proprietăți cu un _internal Ivar:
[_internal lock]; //lock
id result = [[value retain] autorelease];
[_internal unlock];
return result;
Deci, ultimele două sunt aceleași:
@property(atomic, retain) UITextField *userName;
@property(retain) UITextField *userName; // defaults to atomic
Pe de altă parte , nu nonatomicadaugă nimic în codul. Deci, este fir în condiții de siguranță numai dacă cod , vă mecanism de securitate.
@property(nonatomic, retain) UITextField *userName;
Cuvintele cheie nu trebuie să fie scris ca atribut prima proprietate, la toate.
Nu uita, acest lucru nu înseamnă că proprietatea în ansamblu este thread-safe. Numai apelul metoda de setter / getter este. Dar, dacă utilizați un setter și după aceea un getter în același timp cu 2 fire diferite, poate fi rupt prea!
atomic (implicit)
Atomic este implicit: dacă nu tastați nimic, proprietatea este atomic. O proprietate atomică este garantat că, dacă încercați să citiți de la ea, veți primi înapoi o valoare validă. Ea nu face nici o garanție cu privire la ceea ce ar putea fi acea valoare, dar va primi înapoi date bune, nu doar de memorie nedorită. Ce acest lucru vă permite să faceți este dacă aveți mai multe fire sau procese multiple care indică într-o singură variabilă, un fir poate citi și un alt fir poate scrie. În cazul în care au lovit în același timp, firul cititorului este garantat pentru a obține unul dintre cele două valori: fie înainte de schimbarea sau după schimbarea. Ce atomic nu da este nici un fel de garanție cu privire la care dintre aceste valori pe care le-ar putea obține. Atomic este într-adevăr frecvent confundat cu a fi-fir în condiții de siguranță, și că nu este corect. Ai nevoie pentru a garanta siguranța dvs. fir de alte moduri. Cu toate acestea, atomic va garanta că, dacă încercați să citiți, te întorci un fel de valoare.
nonatomic
Pe de alta parte, non-atomice, după cum puteți ghici, probabil, înseamnă pur și simplu, „nu face asta chestii atomice.“ Ceea ce ai pierdut este că garanția că veți obține întotdeauna înapoi ceva. Dacă încercați să citiți în mijlocul unei scrie, ai putea primi înapoi de date de gunoi. Dar, pe de altă parte, tu du-te un pic mai repede. Deoarece proprietățile atomice au de a face unele magic, pentru a garanta că veți primi înapoi o valoare, ele sunt un pic mai lent. Dacă este o proprietate pe care accesați o mulțime, poate doriți să scadă în jos pentru a nonatomic pentru a vă asigura că nu suporta acea penalizare de viteză.
Vezi mai multe aici: https://realm.io/news/tmi-objective-c-property-attributes/
Cum să declare:
Ca atomic este implicit, deci,
@property (retain) NSString *name;
ȘI în dosarul de punere în aplicare
self.name = @"sourov";
Să presupunem că o sarcină legată de trei proprietăți sunt
@property (retain) NSString *name;
@property (retain) NSString *A;
@property (retain) NSString *B;
self.name = @"sourov";
Toate proprietățile funcționează în paralel (cum ar fi asincronă).
Dacă apelați „nume“ de la firul A ,
Și
În același timp, dacă apelați
[self setName:@"Datta"]
din firul B ,
Acum , dacă * proprietate nume este nonatomic atunci
Thats de ce non atomic se numește fir nesigur, dar, dar este rapid în performanță din cauza execuției paralele
Acum, dacă * Numele proprietății este atomică
De aceea atomic se numește fir de siguranță și de aceea , este numit citire-scriere în condiții de siguranță
O astfel de operațiune situație se va efectua în serie. Și lentă în performanță
- Nonatomic înseamnă acces multiplu fir variabila (tip dinamic).
- Nonatomic este firul nesigur.
- dar este rapid în performanță
-Nonatomic NU este implicit comportamentul, avem nevoie pentru a adăuga un cuvânt cheie în nonatomic atribut de proprietate.
Pentru În Swift Confirmarea că proprietățile Swift sunt nonatomic în sensul ObjC. Unul dintre motive este, astfel încât să se gândească dacă Atomicitate per proprietate este suficient pentru nevoile dumneavoastra.
Referință: https://forums.developer.apple.com/thread/25642
Fro mai multe informații vă rugăm să vizitați site - ul http://rdcworld-iphone.blogspot.in/2012/12/variable-property-attributes-or.html
Dacă utilizați proprietatea în codul multi-threaded, atunci s-ar putea vedea diferența dintre atributele nonatomic si atomice. Nonatomic este mai rapid decât atomică și atomic este thread-safe, nu nonatomic.
Vijayendra Tripathi a dat deja un exemplu pentru un mediu multi-thread.
Înainte de a începe: Trebuie să știți că fiecare obiect în memorie trebuie să fie deallocated din memorie pentru o nouă scriere să se întâmple. Nu poți pur și simplu , pur și simplu scrie pe partea de sus a ceva ce faci ca pe hârtie. Tu trebuie să ștergeți mai întâi (dealloc) l și apoi puteți scrie pe ea. Dacă în momentul în care erase se face (sau pe jumătate făcut) și nimic nu a fost încă fost scris (sau jumatate a scris) și încercați să citiți aceasta ar putea fi foarte problematic! Ajutor atomic și nonatomic vă trateze această problemă în diferite moduri.
Mai întâi citiți această întrebare și apoi citiți răspunsul Bbum lui . În plus , apoi citiți rezumatul meu.
atomic va garanta întotdeauna
Păstrează contează sunt modul în care memoria este gestionat în Objective-C. Când creați un obiect, are un număr de păstrează 1. Când trimiteți un obiect un mesaj păstrează, numărul său reține este incrementat cu 1. Când trimiteți un obiect un mesaj de eliberare, numărul său păstrează este decrementat cu 1. Când trimite un obiect un mesaj AutoreleasePool , numărul său păstrează este decrementat cu 1 , la un moment dat în viitor. În cazul în care un object's reține numărul este redus la 0, este deallocated.
Stai ce?! Sunt multithreading și siguranță fir diferit?
Da. Multithreading înseamnă: fire multiple poate citi o bucată partajată de date în același timp, și nu se va prăbuși, dar aceasta nu garantează că nu citiți de la o valoare non-autoreleased. Cu siguranță fir, este garantat că ceea ce ai citit nu este eliberat automat. Motivul pentru care noi nu facem totul atomic implicit este, pentru că există un cost de performanță și pentru cele mai multe lucruri nu într-adevăr nevoie de siguranță fir. Câteva părți ale codului nostru au nevoie de ea și pentru cele câteva părți trebuie să scrie codul nostru într-un mod sigur fir folosind încuietori, mutex sau sincronizare.
nonatomic
În general acestea sunt diferite în 2 aspecte:
Crashing sau nu din cauza de a avea sau de a nu avea AutoreleasePool.
Permiterea de a fi citite chiar în mijlocul unei „scriere nu a fost încă terminat sau valoarea gol“ sau nu permite și numai să permită să citească atunci când valoarea este pe deplin scris.
Înainte de a discuta despre atributele @property, ar trebui să știi ce este utilizarea de @property. @property oferă o modalitate de a defini informațiile pe care o clasă este destinată a îngloba. Dacă declarați un obiect / variabila folosind @property, atunci acel obiect / variabilă va fi accesibile altor clase care importă clasa sa. Dacă declarați un obiect folosind @property în fișierul antet, atunci trebuie să-l sintetizeze folosind @synthesize în fișierul de punere în aplicare.
Exemplu:
clasa .h
@interface ExampleClass : NSObject
@property (nonatomic, retain) NSString *name;
@end
clasa .m
@implementation ExampleClass
@synthesize name;
@end
Acum, compilatorul va sintetiza Accessor metode de nume.
ExampleClass *newObject=[[ExampleClass alloc]init];
NSString *name1=[newObject name]; // get 'name'
[obj setName:@“Tiger”];
Lista de atribute ale @property: atomice. nonatomic. reține. copie. readonly. Citeste, scrie. atribui. puternic.
atomic: Este comportamentul implicit. În cazul în care un obiect este declarat ca atomica, atunci devine thread-safe. mijloace thread-safe, la un moment dat doar un fir dintr-un caz particular de acea clasă poate avea controlul asupra acelui obiect.
exemplu:
@property NSString *name; //by default atomic
@property (atomic)NSString *name; // explicitly declared atomic
nonatomic: Nu este thread-safe. Puteți utiliza atributul de proprietate nonatomic pentru a specifica faptul că sintetizate pur și simplu setați Conturi cu acces sau de a reveni în mod direct o valoare, fără garanții cu privire la ceea ce se întâmplă în cazul în care aceeași valoare este accesată simultan din fire diferite. Din acest motiv, este mai rapid pentru a avea acces la o proprietate nonatomic decât una atomică.
@property (nonatomic)NSString *name;
reține: este necesară atunci când atributul este un pointer la o metodă setter object.The va crește păstra numărul de a obiectului, astfel încât acesta va ocupa de memorie în AutoreleasePool.
@property (retain)NSString *name;
copie: Dacă utilizați copia, nu puteți utiliza reține. Utilizarea copie instanță a clasei va conține propria copie. Chiar dacă un șir de caractere mutabil este setat și modificat ulterior, instanța capturează orice valoare are în momentul în care este setat. Nu există metode setter și getter vor fi sintetizate.
@property (copy) NSString *name;
NSMutableString *nameString = [NSMutableString stringWithString:@"Liza"];
xyzObj.name = nameString;
[nameString appendString:@"Pizza"];
numai citire: Dacă nu doriți să permiteți proprietatea de a fi schimbat prin metoda setter, puteți declara proprietatea readonly.
@property (readonly) NSString *name;
ReadWrite: este comportamentul implicit. Nu aveți nevoie să specificați atributul ReadWrite în mod explicit.
@property (readwrite) NSString *name;
alocați: va genera un setter care atribuie valoarea variabilei la instanță în mod direct, mai degrabă decât copierea sau păstrarea acestora. Acest lucru este cel mai bun pentru tipurile primitive, cum ar fi NSInteger și CGFloat, sau obiecte pe care nu le dețineți în mod direct, cum ar fi delegați.
@property (assign) NSInteger year;
puternic: este un înlocuitor pentru păstreze.
@property (nonatomic, strong) AVPlayer *player;
unsafe_unretained: Există câteva clase în cacao și cacao Touch care nu acceptă încă referințe slabe, ceea ce înseamnă că nu se poate declara o proprietate slabă sau variabilă locale slabe pentru a ține evidența acestora. Aceste clase includ NSTextView, NSFont și NSColorSpace, etc. Dacă trebuie să utilizați o referință slabă la una dintre aceste clase, trebuie să utilizați o referință nesigură. O referință nesigură este similară cu o referință slabă în faptul că nu ține obiectul său asociat în viață, dar nu va fi setat la zero în cazul în care obiectul de destinație este deallocated.
@property (unsafe_unretained) NSObject *unsafeProperty;
Proprietatea asigură atomică pentru a păstra o valoare complet inițializat, indiferent de cât de multe fire fac getter si setter pe ea.
Proprietatea nonatomic specifică faptul că pur și simplu set sintetizat Conturi cu acces sau returna o valoare în mod direct, fără garanții cu privire la ceea ce se întâmplă în cazul în care aceeași valoare este accesată simultan din fire diferite.
Atomic înseamnă doar un singur fir poate avea acces la variabila la un moment dat (de tip static). Atomic este thread-safe, dar este lent.
Nonatomic înseamnă mai multe fire pot avea acces la variabila în același timp (de tip dinamic). Nonatomic este fir nesigur, dar este rapid.
Dacă utilizați atomică, înseamnă că firul va fi în siguranță și numai în citire. Dacă utilizați nonatomic, înseamnă firele multiple acces variabila si este firul nesigur, dar este executat rapid, face o citire și scriere operații; acesta este un tip dinamic.
Atomicitate atomic (implicit)
Atomic este implicit: dacă nu tastați nimic, proprietatea este atomic. O proprietate atomică este garantat că, dacă încercați să citiți de la ea, veți primi înapoi o valoare validă. Ea nu face nici o garanție cu privire la ceea ce ar putea fi acea valoare, dar va primi înapoi date bune, nu doar de memorie nedorită. Ce acest lucru vă permite să faceți este dacă aveți mai multe fire sau procese multiple care indică într-o singură variabilă, un fir poate citi și un alt fir poate scrie. În cazul în care au lovit în același timp, firul cititorului este garantat pentru a obține unul dintre cele două valori: fie înainte de schimbarea sau după schimbarea. Ce atomic nu da este nici un fel de garanție cu privire la care dintre aceste valori pe care le-ar putea obține. Atomic este într-adevăr frecvent confundat cu a fi-fir în condiții de siguranță, și că nu este corect. Ai nevoie pentru a garanta siguranța dvs. fir de alte moduri. Cu toate acestea, atomic va garanta că, dacă încercați să citiți, te întorci un fel de valoare.
nonatomic
Pe de alta parte, non-atomice, după cum puteți ghici, probabil, înseamnă pur și simplu, „nu face asta chestii atomice.“ Ceea ce ai pierdut este că garanția că veți obține întotdeauna înapoi ceva. Dacă încercați să citiți în mijlocul unei scrie, ai putea primi înapoi de date de gunoi. Dar, pe de altă parte, tu du-te un pic mai repede. Deoarece proprietățile atomice au de a face unele magic, pentru a garanta că veți primi înapoi o valoare, ele sunt un pic mai lent. Dacă este o proprietate pe care accesați o mulțime, poate doriți să scadă în jos pentru a nonatomic pentru a vă asigura că nu suporta acea penalizare de viteză. Acces
curtoazie https://academy.realm.io/posts/tmi-objective-c-property-attributes/
atributele de proprietate Atomicitate (atomice și nonatomic) nu sunt reflectate în declarația de proprietate Swift corespunzătoare, dar garanțiile de atomicitate de implementare Obiectiv-C, dețin în continuare atunci când proprietatea importate este accesat din Swift.
Deci - dacă definiți o proprietate atomică în Objective-C va rămâne atomică atunci când sunt utilizate de către Swift.
curtoazie https://medium.com/@YogevSitton/atomic-vs-non-atomic-properties-crash-course-d11c23f4366c
Proprietăți atomice : - Atunci când o variabilă atribuită cu proprietatea atomică ceea ce înseamnă că are doar un singur fir de acces și va fi în siguranță fir și va fi bună perspectivă de performanță, va avea un comportament implicit.
Non Atomic Proprietăți : - Atunci când o variabilă atribuită cu proprietatea atomică ceea ce înseamnă că are acces multiplu fir și nu va fi fir în condiții de siguranță și va fi lentă în perspectivă de performanță, va avea un comportament implicit și atunci când două fire diferite , doresc să acceseze variabile în același timp aceasta va da rezultate neașteptate.
Adevărul este că ei folosesc de blocare de spin pentru a pune în aplicare de proprietate atomică. Codul de mai jos:
static inline void reallySetProperty(id self, SEL _cmd, id newValue,
ptrdiff_t offset, bool atomic, bool copy, bool mutableCopy)
{
id oldValue;
id *slot = (id*) ((char*)self + offset);
if (copy) {
newValue = [newValue copyWithZone:NULL];
} else if (mutableCopy) {
newValue = [newValue mutableCopyWithZone:NULL];
} else {
if (*slot == newValue) return;
newValue = objc_retain(newValue);
}
if (!atomic) {
oldValue = *slot;
*slot = newValue;
} else {
spin_lock_t *slotlock = &PropertyLocks[GOODHASH(slot)];
_spin_lock(slotlock);
oldValue = *slot;
*slot = newValue;
_spin_unlock(slotlock);
}
objc_release(oldValue);
}
Pentru a simplifica întreaga confuzie să ne înțelegem de blocare mutex lock.Mutex ca pe numele blochează mutabilitatea a object.So dacă obiectul este accesat de către o clasă de nici o altă clasă poate avea acces la aceeași @sychronise object.In iOS, de asemenea, oferă mutex lock.Now servi în modul FIFO și asigură fluxul nu este afectată de două clase care împart același instance.However în cazul în care sarcina este pe firul principal obiect accesarea Evitați utilizarea proprietăților atomice, deoarece poate deține UI și degrada performanța
Atomic: Asigurați-vă că firul de siguranță prin blocarea firului folosind NSLOCK.
Non atomice: nu asigură siguranța pentru fire, deoarece nu există nici un mecanism de blocare a firului.