0

Looking forward for response other then : - ARC and non-ARC environment

Joe
  • 3,774
  • 1
  • 17
  • 25

1 Answers1

2

Strong and Weak help with retain-release cycles (RRC), a form of memory leak. iOS uses something called Automatic Reference Countin (ARC) to know when an object is in use and should be kept in memory, or is no longer in use and should be deleted to gain back resources. ARC works because the runtime knows for each object, how many objects are referencing it. When that found reaches 0, the object is deleted.

Issues arise when you have two objects that hold references to each other. Because object A holds a reference to object B, and B to A, the reference count for both A and B will never be 0, this A and B will always be in memory. It's also possible that there are no other objects holding references to A or B, so we've just created a memory leak.

Getting back to Strong and Weak, these keywords are used to "denote ownership", if you will. They help you eliminate retain-release cycles by limiting what objects increment the reference count for another object. A strong property is one where you increment the reference count of the object. If object A has a strong reference to B, and no other object is referencing B, B has count 1 (A owns, or needs to exist B). Now, if B wants to have a reference to A, we would want to use a weak reference. Weak references don't increment the reference count of the object. So in this particular case, if A has no other objects referencing it but B, A's count would be 0 given B's weak reference.

Can you see how this is eliminating the RRC? Assuming no external references and not using strong/weak references, A and B would perpetually reside in memory. Using the strong and weak references we outlined above, A would have count 0, so it would be removed from memory. This in turn would deincrement B's reference count from 1 to 0, causing B to be removed from memory.

Nonatomic is used to denote that the object being referenced in not thread safe. This means that the object is not able to deal with multiple requests at the same time. Atomicity is the idea that once you make a request, it either happens or it doesn't. When an operation is atomic, you're guaranteeing that the entity you're applying the operation to will never be in an intermediate state. Regardless of how you look at that entity, it either looks the way it did before you requested the operation, or it looks the way it will once the operation is done. (When thinking about atomicity, think of atoms. The word means indivisible. Atomic operations are those which can't be divided into smaller operations.)