I have a few icons in my app that I reuse in multiple views (for example a favorite icon).
In order to save memory, I was wondering if using a class with class methods which loads static images would be a good idea ?
For example :
+ (UIImage *)favoriteIcon {
static UIImage * icon;
if (!icon)
icon = [UIImage imageNamed:#"favorite.png"];
return icon;
}
Or should I just use + (UIImage *) imageNamed:(NSString *)name every time I need ?
Thank you for your advices.
[UIImage imageNamed:] is already doing something like this under the hood. In fact, it's smarter, because it is also doing things like dumping the images when memory is low and they aren't needed right away, while your favoriteIcon method keeps them loaded forever.
In general, it's better to avoid doing optimizations like this until you've built your app and then profiled it to see how/where it needs improvement. Otherwise you are wasting time or maybe even making things worse. I recommend you learn how to use Instruments to profile your app, it's kind of complicated but a lot of fun once you get the hang of it.
Related
So, I have this news feed structure. Every news block is a custom UITableViewCell. Now, every custom cell has a CollectionView that shows images.
The problem is that when scrolling, and news cell (news block) comes out visible, the CollectionView is reloading - every time cell shows up. I'm trying to find the way to cache those images on the main ViewController side.
What would be the best approach?
If you want to avoid implementing your own cache/disk/memory handlers for this kind of job I strongly recommend either AFNetworking or SDWebImage that handle it all for you.
An example of SDWebImage on how to set an image and its cache:
[imageView sd_setImageWithURL:[NSURL URLWithString:#"http://www.domain.com/path/to/image.jpg"]
placeholderImage:[UIImage imageNamed:#"placeholder.png"]];
This handles all the cache/disk/memory for you automatically.
Here is example of how you handle cache with SDWebImage:
// Set memory size limit (check with older devices to avoid memory errors when setting it to high value.)
[[SDImageCache sharedImageCache] setMaxMemoryCost:****];
// Clear disk cache
[[SDImageCache sharedImageCache] clearDiskOnCompletion:^{
}];
// Clear memory cache
[[SDImageCache sharedImageCache] clearMemory];
I would stay away from NSUserDefaults or the above mentioned example setting the images to dictionary or arrays to avoid memory errors and app crashes/performance.
You have to cache your UIImage instance, so, if you get some pictures from any source, you might write something like below:
/* some code before */
UIImage *yourImage = /* Get your UIImage from any available way */
[self.cache setObject:yourImage forKey:#"SomeUniqueID"];
/* some code after */
I guess, this code will look greater as a function, which obtains UIImage instance and it's id as parameters.
For my opinion, it's the most common way to store images. If you need a more proficient way without any overheads with third-party frameworks, you can read the documentation about NSCache.
But in general, you have a lot of different ways how to store your images:
Get the image from the disk
Get the image from the memory
Use one of the variants above, but apart them still use some lightweight & flexible frameworks, you can find a lot of on the GitHub.
So, the code I wrote above will just store images into the memory cache.
I have a method, and in this method, there is this conditional:
if (self.sleepingCharacter.objectSprite.image == [UIImage imageNamed:#"sleepingRight.png"])
{....
This normally works fine. But I've noticed, in the iOS simulator, that when I put my App in the background by pressing command-H, and then i bring my app back, this conditional no longer works. Do you know why this would happen?
I tested to see if the code would work if I wrote this:
if (self.sleepingCharacter.objectSprite.image)
{....
And it did work, which means that there is still an image there. Now I am confused.
You are using the == operator to compare the two images. This will only be true of the two images are actually the same hunk of memory (the same pointer).
The UIImage imageNamed: method caches images. So in theory if you call it again and again for the same image name, you will keep getting the same pointer and your code appears to work.
But the image cache can get purged at times due to memory usage. Once the image gets purged, the next call to imageNamed: will return a new image pointer and your check will fail.
You need a better way to see if the two images are the same. One solution is to convert both images to NSData objects using UIImagePNGRepresentation then compare the two NSData objects using the isEqual: method.
I appear to have a memory management issue when I create UIImage instances the CGImages are not being released.
I have a paging UIScrollView to scroll through a series of JPG images. Below is my entire class that is a page view in the paging scroll view.
The code is being run on the main thread. The code uses ARC. I have tried loading the images using imageWithContentsOfFile: (returns an autoreleased object) as well as initWithContentsOfFile:(returns a retained object). I have tried #autoreleasepool and using performSelectorOnMainThread to ensure that the code is being run on main thread as suggested in other posts.
When scrolling through the images memory usage just grows until the app gets terminated as illustrated in the screenshot from instruments. Note the high allocation to image io.
Screenshot showing virtual memory usage
In the following screenshot it can be seen that the GTGImageScrollerPageViews, UIImageViews and UIImages are being deallocated. Notice there are Transitory objects for these numbering in the high 300's. However the CGImages are not being released and the number of CGImages living is in the high 400's and 0 Transitory.
Screenshot showing allocations
EDIT: Previously I had been recycling and re-using GTGImageScrollerPageView instances in the ScrollView as is the common pattern for scrollviews like this. In order to simplify while trying to debug this problem I allow the entire GTGImageScrollerPageView to be deallocated after it has been displayed in the ScrollView. As you can see in the second image above, there are only 4 GTGImageScrollerPageView living and 377 transitory, there are also 388 UIImageViews and 389 UIIMages listed as transitory so it appears that the UIImageViews and UIImages are being deallocated fine.
If I manually release the CGImage with CGImageRelease (Commented out in the code below) the CGImages are released. I know that I should not do this because I do not own the CGImage but this is useful to verify that this is where the problem is occurring. The screenshots below show the same code tested in Instruments but with CGImageRelease uncommented.
Screenshot showing virtual memory usage with CGImageRelease used
Screenshot showing allocations with CGImageRelease used
In the profiling outputs where CGImageRelease is used, you can see that the correct number of CGImage objects are Living and Transitory and that memory does not grow unbounded. Furthermore the app does not crash during usage with CGImageRelease used.
If this were some system caching of CGImage then it should release the memory when a memory warning is raised, but it doesn't. Memory just continues to grow.
What here could be causing this unbounded growth in memory?
Here is the code for the page view
EDIT: In response to comments I have updated the code to simplify further thus eliminating distractions such as ivars and properties that are not needed to demonstrate the problem. The problem remains unchanged and the results are the same when profiling. I have also added in the NSLog which also outputs the thread. I do see the dealloc being called as expected on the GTGImageScrollerPageView and it is always thread #1 and the call to displayAspectThumbImage is always on thread #1.
I really dont believe that there is anything wrong with the code that is presented here and this is confirmed by the generous effort of Rob. Something else is causing this but all the code related to loading and displaying the image is here; there is no other code in effect here. The only other notable thing that I could think of raising is that the displayAspectThumbImage method is called from scrollViewDidScroll and scrollViewDidEndDecellerating methods of the scrollview delegate but the fact that the methods are called on the main thread should exclude autorelease issues due to being run on another thread.
I have checked and NSZombies is not enabled and there are no Zombies increasing my memory usage. Indeed when the CGImageRelease method is called the memory usage is pretty flat as can be seen in the screenshot above.
#implementation GTGImageScrollerPageView
- (void)dealloc {
NSLog(#"%s %#", __PRETTY_FUNCTION__, [NSThread currentThread]);
}
- (void)displayAspectThumbImage:(NSString *)path {
NSLog(#"%s %#", __PRETTY_FUNCTION__, [NSThread currentThread]);
UIImageView *imageView = [[UIImageView alloc] initWithFrame:self.bounds];
[self addSubview:imageView];
UIImage *image = [[UIImage alloc] initWithContentsOfFile:path];
[imageView setImage:image];
//If uncommented CGImages are disposed correctly
//CGImageRelease([imageView.image CGImage]);
}
#end
Tested on:
iOS 6.1.4
iOS 5.0.1
Really sorry to be answering this question myself but thought it would be useful to share my experience.
It turned out to be a category on UIImage that was part of a third party library I was using. I wont name the library as I have tested with the latest version and the problem is not there so there is nothing to gain by naming the library.
It is particularly strange as the library was not being used anywhere near the code that was leaking. It was only being used in one place in the whole project, but any time I used a UIImage it seems that it was affecting the UIImage instance. The mere presence of this category in the project was enough. This came as a real surprise.
The way I solved this was to begin by simulating the scenario in a new project and found that the code was not leaking there. I then migrated the code a little at a time and when I moved the categories across the leak appeared.
Huge thanks to Rob for his generous efforts to help me with this and even though he did not provide the solution directly, talking to him was really helpful in solving the problem. Nice to know there are such cool people out there.
I did a simple infinite scroller using your code and after scrolling through nearly 100 images the memory usage was, as one would have expected, thoroughly uneventful:
Looking at your source, I would have recommended a few little things (e.g. I would have put aspectImageView into a private class extension rather than the .h, I assume you're setting pageIndex from the calling routine but I'd add it as a parameter of displayAspectThumbImage, I would have made aspectImageView a weak property and refactor the code accordingly (e.g. create image view, add it as subview, then set the weak imageview property to point to this object), etc.), but none of those have direct bearing on your issue here.
Bottom line, your problem does not rest in the code you've shared with us.
Try to use property instead of ivar.
#property (nonatomic, strong) UIImageView *aspectImageView;
I have an application and I am profiling it. I am quite new to instrument and I am quite new ios developer as well. I am working with ios6 and I have a very unusual leak. I create a category on UIImage and added helper methods to return the image for using capinsets. My category looks like this,
#implementation UIImage (Helpers)
+(UIImage*)resizableImageWithName:(NSString *)imageName andCapInsets:(UIEdgeInsets)insets{
UIImage *image = [UIImage imageNamed:imageName];
return [image resizableImageWithCapInsets:insets];
}
#end
The instrument shows 3/4 leaks in this area, the same place and I could not figure out the reason for it. Is it that, I have to release the new image I created inside the category, if I release it what am I going to return ? Could any one please explain the reason that I am leaking memory here.
And I used it like this;
[self.progressView setTrackImage:[UIImage resizableImageWithName:#"progress_bar_background.png" andCapInsets:UIEdgeInsetsMake(2, 2, 2, 2)]];
Is there something wrong in using this method in this way ?
The method that Instruments shows you is the place where the leaked memory is allocated -- not necessarily the place where the memory is leaked. Indeed your method is correct as to memory management.
Thus, you better inspect how you handle the returned UIImage object... possibly, if this hint does not help you finding the leak cause, post some more code.
I have an app that's been running fine in the App Store for 6 months or so, but none of its images (downloaded from a web site via "NSURLConnection initWithRequest") show up in iOS 4.3. It turns out that I have a line of code that looks like this:
UIImage *img = [[UIImage alloc] initWithData:data];
and shortly thereafter, to get ready for the next image, I do this:
data.length = 0;
When I comment out setting the length to zero (deferring it until the download of the next image begins), it works on iOS 4.3.
I've checked carefully to make sure there's no buffer interference, but each of my images is in its own instance of an object that has the buffer (data) as an instance variable.
It seems to me that in iOS 4.3 the initWithData implementation is not completely finished with the data when the method returns. Perhaps some work is being deferred until the UIImage is assigned to the UIImageView, which happens a bit later? Maybe even deferred until the UIImage is rendered?
Can anyone shed light on this seemingly-new behavior in iOS 4.3?
I think your analysis sounds about right. It's easy to imagine the kind of small change that would cause this, for example UIImage may have been changed to retain the data rather than copy it, or something like that. I'd file a bug with Apple to make sure that someone notices the issue, and then work around it by changing your code to:
UIImage *img = [[UIImage alloc] initWithData:[[data copy] autorelease]];
At least, I assume that'd work around it. It'd be very interesting if it doesn't... please let us know one way or the other.