IOS memory management

Memory management is very important in any application, particularly in IOS applications that have memory and other constraints. It refers to ARC, MRC, reference types, and value types. Memory leaks and App crashes are all too common in apps due to poor IOS memory management.
Automatic Counting for References: ARC in IOS memory management
In IOS memory management Swift this is conceptually the same as in Objective-C. ARC keeps track of strong references to class instances and increases or decreases their reference count when assigning or unassigning class instances (reference types) to constants, properties and variables as appropriate. It deals with memory used by objects which have been reduced to zero by reference count. ARC does not increase or decrease the value types reference count, since these are copied when assigned. By default all references will be powerful references.

To learn complete ios tutorials visit:ios app development course

Strong reference cycles
Strong Reference Cycles are one of the key concepts ARC needs to be aware of. To fully de-allocate a class instance under ARC it must be free of all strong references to it. But there is a chance that you ould structure your code in such a way that two instances strongly reference each other and thus never allow the reference count of each other to drop nil.
In Swift, there are two ways to solve this.
● Weak references
● Un-owned references.
Both of these approaches allocate an instance without a strong reference to it. Use the weak keyword before a property or attribute declaration for one keyword, and the un-owned keyword for the other.
● Weak reference
Weak reference is used when you know that a reference can become nil when you are certain that the reference has a longer lifecycle and will never become nil. Since weak references can have a value or no value at all, optional variables must be defined.

Un-owned reference
An un-owned reference must be defined as non-optional, as it is assumed to have a value always.
● Strong Close Reference Cycle:
Strong Reference Duration at Closures is another important concept. They could potentially capture themselves when you use closures within a class instance. If self retains the closure in turn, you would have a solid, mutual reference period between closure and class case. This often happens when, for
example, you use lazy, loaded properties. To stop this you should use the same low and unowned keywords. When you describe your closure a so-called catch list should be added to its scope.
● List of catches:
A catch list determines how references caught in it would be treated by the closure. By default, if you don't use a capture list, you'll get a strong reference to everything. Capture lists are either defined on the same line where the open bracket is being closed, or on the next line after that. They are described by a pair of square brackets, and each element within them has a weak or unowned keyword prefix and is separated by a comma from other elements. The same reasoning applies to a list of closure captures as to variable references: define a catch variable as a weak optional if it may become nil' and the closure will not be deallocated before that, and define a captured reference as unowned if it never is null until
the closure is dealt.

Originally IOS memory management was non-ARC (Automatic Reference Counting), where we must maintain and release the objects. Now, it supports ARC and we don't have to hold the objects and release them. Xcode automatically takes care of the job during compile time. Issues governing IOS memory management
The two main issues in IOS memory management according to Apple's documentation are as follows.
● Freeing or overwriting of still in use files. It causes memory corruption and typically causes corrupted user data to crash, or worse, in your application.
● Failure to free data which is no longer in use creates memory leaks. It is known as memory leak
when reserved memory is not freed as it will never be used again. Leaks cause your application to use can amounts of memory, which in turn can lead to poor system performance or (in iOS) termination of your application.
Rules of IOS memory management
● You own the objects that you create and then we have to release them when they are no longer needed.
● Using Retain to acquire ownership of an entity you failed to create. If these objects are not required, you must release them too.
● Don't release those objects you don't own.
● Conversely, you will not release it if you are not the maker of an entity and have not shown an interest in ownership.
● If you receive an object from another part of your system, it is usually guaranteed that it will remain valid throughout the process or task through which it was obtained. It should be preserved or copied if you want it to remain true outside that reach. When you try to release an already deallocated entity, your program crashes.

Aspects about IOS memory management
For the proper understanding and management of object memory the following principles are essential
● Pools in auto release.
Sending auto release to an object marks the object for subsequent release, which is useful if you want the object released to persist beyond the current scope. Auto releasing an object places it an auto release pool (an example of NSAutoreleasePool), which is created for an arbitrary scope of the program. When the execution of program exits that scope, the objects are released in the pool.
● De-allotment
When the retaining count of an object drops to zero, the runtime calls the class of the object's dealloc method just before it destroys the object. A class implements this method to free up any resources that the object contains, including objects that its instance variables refer to.
● Tools in plant
Many framework classes define class methods, which create class objects for you as a convenience.Such returned items are not assumed to be accurate beyond the limits of the reception process.

Handling ARC Memory through IOS memory management
For ARC you don't have to use release and hold. So, when the view controller is removed, all artifacts of the view controller will be released. Likewise, sub-objects of any object will be released upon entry.
Remember that if other classes have a strong reference to a class object then it won't release the whole class. So, it's recommended that delegates use poor properties.
Tools for IOS Memory Management

With the help of Xcode tool instruments, we can examine memory usage. This contains such resources as the Activity Monitor, Allocations, Leaks, Zombies, etc.

Conclusion
This article briefly explains about IOS memory management. You can learn more concepts in IOS through ios online training.