Dear fellow iOS developers,
I'm still developing without ARC (switching coming soon) and after an interesting discussion with a iOS beginner, I've presented my way to initialize a retain property (let's call it property), that I inherited from Apple docs at their pre-ARC era:
NSObject *tmpProperty = [[NSObject alloc] init];
self.property = tmpProperty;
[tmpProperty release];
I see a great benefit with this: it makes memory management clear.
There's also a great drawback: it takes 3 lines, for something very basic. So we assumed: why not the following solution?
self.property = [[[NSObject alloc] init] autorelease];
It's less clear about memory management but much more compact (and it propably make the ARC-migration easier to achieve).
What are (were?) you using yourself? Do you think one of these is a clearly better solution than the other?
Using autorelease is never a great option, as you have no control over the lifetime of the object you are initializing, so it may be the case that
In a ViewController you have initialized some object e.g. property, and you are swtiching to some other views, and if you want to come back to the older ViewController and access the object, it might be released by the iOS, and your app might crash.
I think switching to ARC at the earliest would be your best option. I think ARC should be used by every developer, almost all the devices are being provided by the iOS5 update, so there might be least chances of supporting older devices.
Hope this solves your doubt
I am using the first where ever I can, because it uses less memory. In the second case the object you have allocated is released when the run loop finishes. This can be important when you have this code in a for loop or in a table view cell. In some circumstances this can make the difference between 'memory warning' and 'everything is fine'.
By the way: Switch to ARC.
A little of both. I don't think it something that a convention should say "One or the other".
The one-liner works well when you need just one line. Ownership requires no additional reading.
When you need further initialization (e.g. before you set self.property) or in some cases want to minimize possibility of an object being added to an autorelease pool or its destruction more predictable, then you may favor the second.
However, I wouldn't fret about it much if you're about to move over to ARC -- a lot will change then and you may wind up going through extra work for no gain following the migration.
Related
I remember from watching CS193P from Stanford University on YouTube (yes, I'm a smart bunz)... that there's this thing called a memory leak or "retain cycle" -- something really bad -- that can happen when you do things like this:
referencing self. within a completion block
referencing self. within a timer callback
referencing self. within a SyncQueue.sync() method
referencing self. within a DispatchQueue.main.async() method
The solution generally seems to be to use the "weak self" reference instead.
I have 104 of these asynchronous self. references in my ViewController which is why I am a little worried.
HOWEVER... this app is a single-page app... and ALL these self. references are pointing to this main ViewController (or one of its permanent sub-views) which is always there, never dismissed, and never "popped from the stack."
My app seems to work fine... and I don't see the total memory usage going haywire or anything... So does that mean I can leave my (ViewController) code as-is in this regard?
Thanks for help!
Here are two situations where you may regret not fixing your code:
If the device runs low on memory when your app is in the background, there are aspects of your view controller and its views that can be deleted. See this (admittedly old, but still interesting) article. This could easily affect your app more significantly in a future iOS version, or maybe even now depending on what your code is doing.
Jump 6 months ahead, where you or someone else on your team is borrowing some of your code for another app. You (or they) will likely get burned. Best to just fix the code now. The fixes shouldn't cause a major refactor, but if you find one that does, you could always insert a big warning comment at that line instead.
I'm using lots of audio, video, and images in one of my apps and seem to be having minor memory issues and was wondering what the best way to free up memory is.
I use lots of optional variables like this:
var myImageView: UIImageView?
I was wondering if it is considered best practice to set these to nil as soon as you know you won't need it anymore to free up memory like this:
myImageView = nil
It seems like setting it to nil would remove the last strong reference and cause it to be released, but I would also prefer not to litter my code with XXXX = nil all over the place if possible.
I also thought about creating a deinit method for the class that uses this variable and do it in there like this:
deinit {
myImageView = nil
}
The only thing is the instance I'm using doesn't actually get destroyed before it's used again. But normally when an instance is destroyed, all of it's optionals should be released as well, right?
From Apple's documentation on Automatic Reference Counting (ARC), they say:
Swift uses Automatic Reference Counting (ARC) to track and manage your app’s memory usage. In most cases, this means that memory management “just works” in Swift, and you do not need to think about memory management yourself. ARC automatically frees up the memory used by class instances when those instances are no longer needed.
The following part seems interesting to you
However, in a few cases ARC requires more information about the
relationships between parts of your code in order to manage memory for
you.
You haven't posted any code, so I can't know whether you have weak references, unowned references, strong reference cycles for closures etc.
For example, if you have a strong reference cycle for closure as described in the documentation link above:
Swift provides two ways to resolve strong reference cycles when you work with properties of class type: weak references and unowned references.
I think it would be beneficial for you to read the documentation as it will give you a clear idea of how ARC works in Swift.
Apple encourages you to use as little memory as possible. By doing this, the system may keep more apps in memory and dedicate memory to apps that really need it. To do this, you could use the following strategies:
Reduce Memory Footprint
If your memory footprint is too high, your application may be terminated, so it's a good idea to free up memory whenever is possible if you use a lot of resources.
If you don't need a resource anymore, you could get ride of its strong references by setting all references to nil, thus, deallocating it. But, depending on your code design, consider using one strong reference on a primary object and a bunch of weak references on others if you use the same resources throughout your code. It may avoid strong references cycles, abandoned memory, and you don't need setting your references to nil every time you want to free up memory. Just set to nil your strong reference.
Memory Warnings
You could also observe low-memory warnings in your app and remove unnecessary resources and resources that can be recreated. You have access to these warnings through:
applicationDidReceiveMemoryWarning method in the app delegate.
didReceiveMemoryWarning method in your view controllers.
UIApplicationDidReceiveMemoryWarningNotification notification.
Note: You're right. When a instance is destroyed, all their properties are released but not deallocated if it has a strong reference in another place. So there's no need to set a property to nil in the deinit method.
For more information, see:
Automatic Reference Counting
Use Memory Efficiently section at Performance Tips
Optionals are a way to use datatypes meaningfully.
For example, you have a variable called age. Just because the user doesn't specify a value to that variable, you cant take its value as zero which is absurd.
So, optional simply means that it accepts a nil value, which is why we unwrap optional variable before using it, to make sure if it has a value.
And memory management is handled by the iOS through ARC. The memory issues that you face could be due to retain cycles.
I would like to know in what situation did you use -retainCount so far, and eventually the problems that can happen using it.
Thanks.
You should never use -retainCount, because it never tells you anything useful. The implementation of the Foundation and AppKit/UIKit frameworks is opaque; you don't know what's being retained, why it's being retained, who's retaining it, when it was retained, and so on.
For example:
You'd think that [NSNumber numberWithInt:1] would have a retainCount of 1. It doesn't. It's 2.
You'd think that #"Foo" would have a retainCount of 1. It doesn't. It's 1152921504606846975.
You'd think that [NSString stringWithString:#"Foo"] would have a retainCount of 1. It doesn't. Again, it's 1152921504606846975.
Basically, since anything can retain an object (and therefore alter its retainCount), and since you don't have the source to most of the code that runs an application, an object's retainCount is meaningless.
If you're trying to track down why an object isn't getting deallocated, use the Leaks tool in Instruments. If you're trying to track down why an object was deallocated too soon, use the Zombies tool in Instruments.
But don't use -retainCount. It's a truly worthless method.
edit
Please everyone go to http://bugreport.apple.com and request that -retainCount be deprecated. The more people that ask for it, the better.
edit #2
As an update,[NSNumber numberWithInt:1] now has a retainCount of 9223372036854775807. If your code was expecting it to be 2, your code has now broken.
NEVER!
Seriously. Just don't do it.
Just follow the Memory Management Guidelines and only release what you alloc, new or copy (or anything you called retain upon originally).
#bbum said it best here on SO, and in even more detail on his blog.
Autoreleased objects are one case where checking -retainCount is uninformative and potentially misleading. The retain count tells you nothing about how many times -autorelease has been called on an object and therefore how many time it will be released when the current autorelease pool drains.
I do find retainCounts very useful when checked using 'Instruments'.
Using the 'allocations' tool, make sure 'Record reference counts' is turned on and you can go into any object and see its retainCount history.
By pairing allocs and releases you can get a good picture of what is going on and often solve those difficult cases where something is not being released.
This has never let me down - including finding bugs in early beta releases of iOS.
Take a look at the Apple documentation on NSObject, it pretty much covers your question:
NSObject retainCount
In short, retainCount is probably useless to you unless you've implemented your own reference counting system (and I can almost guarantee you won't have).
In Apple's own words, retainCount is "typically of no value in debugging memory management issues".
Of course you should never use the retainCount method in your code, since the meaning of its value depends on how many autoreleases have been applied to the object and that is something you cannot predict. However it is very useful for debugging -- especially when you are hunting down memory leaks in code that calls methods of Appkit objects outside of the main event loop -- and it should not be deprecated.
In your effort to make your point you seriously overstated the inscrutable nature of the value. It is true that it is not always a reference count. There are some special values that are used for flags, for example to indicate that an object should never be deallocated. A number like 1152921504606846975 looks very mysterious until you write it in hex and get 0xfffffffffffffff. And 9223372036854775807 is 0x7fffffffffffffff in hex. And it really is not so surprising that someone would choose to use values like these as flags, given that it would take almost 3000 years to get a retainCount as high as the larger number, assuming you incremented the retainCount 100,000,000 times per second.
What problems can you get from using it? All it does is return the retain count of the object. I have never called it and can't think of any reason that I would. I have overridden it in singletons to make sure they aren't deallocated though.
You should not be worrying about memory leaking until your app is up and running and doing something useful.
Once it is, fire up Instruments and use the app and see if memory leaks really happen. In most cases you created an object yourself (thus you own it) and forgot to release it after you were done.
Don't try and optimize your code as you are writing it, your guesses as to what may leak memory or take too long are often wrong when you actually use the app normally.
Do try and write correct code e.g. if you create an object using alloc and such, then make sure you release it properly.
Never use the -retainCount in your code. However if you use, you will never see it returns zero. Think about why. :-)
You should never use it in your code, but it could definitely help when debugging
The examples used in Dave's post are NSNumber and NSStrings...so, if you use some other classes, such as UIViews, I'm sure you will get the correct answer(The retain count depends on the implementation, and it's predictable).
Recently I was facing an issue where I was navigating from a screen A to screen B. when I was coming back from screen B to screen A, the Live Bytes in the application were not returning to the initial value. After further investigation I found out that I was retaining some global objects in some methods which were called more than once. So I had to fix the calling mechanism of the method.
I fixed the issue, but I was thinking about one alternate solution. What if I simply used a for loop in dealloc which runs depending on the value of retain count. I think it is not advisable to use such approach, but what is the exact problem in this approach if I am sure that the objects are not accessed from anywhere outside the file.
Thanks in advance.
What if I simply used a for loop in dealloc which runs depending on the value of retain count.
I wouldn't be surprised if Xcode detects code like that and energizes the aluminum case of your MacBook Pro with several amps.
I think it is not advisable to use such approach, but what is the
exact problem in this approach if I am sure that the objects are not
accessed from anywhere outside the file.
You're right -- not advisable. There are at least two problems:
It completely breaks the memory management paradigm of Objective-C. You really can't be sure that no other object has retained one of your objects. Just one example: you don't know in your -dealloc method whether any of the objects to which your ivars refer might have been autoreleased.
It's the wrong fix. Doing what you propose doesn't fix bugs in your code, it only covers them up. Your objects should correctly manage the objects that they use, and not worry about what other objects may or may not have retained. If you follow that simple formula, you don't have to worry about whether objects are accessed from "outside the file" or not -- everything just works.
Not only should you not use -retainCount to run the number of retains down to 0, you shouldn't look at -retainCount at all.
Retain count is not for you to count on. There are some internal implementations which increase/decrease the retain count without you know it so using it is not advisable.
You should use the xcode instruments for finding memory leaks which will lead you to places in your code where objects are retained and not released.
or you can just enable ARC and let it manage the memory for you.
Suppose you have a tableview that you can refresh. Would you keep the activityAnimator in memory or re-create it every time you click on refresh?
I know this could sound pretty obvious, it seems pretty clear that in the first case you get to speed up your app and in the other case you get to have more free memory space.
But I was wondering whether one of the two was closer to "Apple standards".
Which one is more important? CPU use or memory use?
And don't tell me it depends on what I need to do.
By "activityAnimator" I assume you mean UIActivityIndicatorView.
If that is the case, you should add the indicator via Interface Builder, and connect it to your view controller. This means if the controller is not top most, the OS can release the connected objects, including the indicator if required. It also means you don't have to create and destroy it each time you use it. Best of both worlds.
Having said that, this feels like premature optimisation. I would imagine the datasource backing your table view would take up much more memory that what a UIActivityIndicatorView will. I suggest setting up UIActivityIndicatorView in IB and use it.
I don't think that's exist an "Apple standards".
However I think that the best way is to keep your object in the memory because it allows the application to increase the performance. If the application needs memory the os will call the didReceiveMemoryWarning method and you'll have to release unused object at this time.
But if you have a lot of object it should be a good idea to release some objects from time to time.
If you need more information you can see the Memory Management Programming Guide for Cocoa
Make a method that will create and return the activityAnimator. It should check if its nil and if it is create it. If not just return the existing. Then you can persist it and only release it on dealloc of that viewController or if didRecieveMemoryWarning. Then when ever you need to use it instead of referencing the class' reference call your method to make sure the reference is instianted. That way you have the best performance, but don't run afoul of memory issues.