I am updating app to make it compatible with IOS 6, getting memory warning. live bytes in instrument shows low usage (2.3 MB). In VM tracker dirty size gets around 50%. in VM Tracker type = CG Image -> dirty size increases to 100%. My app requires users to take pictures but i am not using any core graphics objects. is there a way to release CG Image dirty memory ? thank you for taking time and reviewing my request.
My app using ARC starting leaking memory very badly on iOS6 whilst it ran perfectly on iOS5. When I say "leaking", I actually mean allocating memory and then not releasing the memory properly when I removed objects from mutable arrays, causing the app's memory usage to increase dramatically.
After lots of frustration, I've managed to fix it by setting up an #autoreleasepool { ... } around the offending section.
My suspicion is that iOS6 is threading my app differently compared with iOS5, as there used to be an #autorelease pool covering that process.
I suggest you try that solution as it is very quick to implement.
Related
My iphone application have a lot of high resolution images (eg: 2898 × 779 pixels dimension) and the whole project folder is only 17mb in size but if i run the application and when the first view is loaded the real memory and dirty memory showing in the VM Tracker in Instruments is more than 62mb.Can anyone help me to avoid this?Any suggestions will be thankful.
Images once loaded into memory lose (most of?) their compression. So unfortunately, the images may not look big when on disk (bundled in the app) but they can be a lot bigger once loaded into your app.
one 2898x779 image in ram will effectively use 2898x779x4 bytes = ~9mb, compare that with how big your image is on disk and you should see the difference.
so to actually answer your question, either downsize your images (because your devices screen is probably not that big, unless retina ipad or something) or use a CATiledLayer which will only load up parts of the image that are visible on the screen, and not the whole image.
5 tips to reduce memory issues in iOS apps
1. Use virtual memory
iOS doesn’t use swap file but it does support virtual memory. If an app keeps a lot of data in memory for random access you want to organize it as a mapfile rather then loading it to RAM with
malloc()
. An easiest way to do that is to call
NSData initWithContentsOfMappedFile:
2. Avoid stacking autoreleased objects
When you instantiate objects like NSString with no explicit allocation they live until the release of your autorelease pool – typically until your app quits. Extensive usage of such techniques may lead to a lot of garbage in RAM. Use
NSString initWithContentsOfFile:
so you can later release it instead of
NSString stringWithContentsOfFile:
. The same rule applies to
UIImage imageNamed:
– this is not recommended to use for image loading.
3. Handle memory warnings
Unload unnecessary resources when handling memory warning. Even if you can’t unload any of your stuff call
[super didReceiveMemoryWarning]
in all your UIViewControllers. That will by default free some resources like UI controls on non-front views. Failing to handle this event may make iOS decide that your app deserves killing.
4. Consider limited usage of animated view transitions
Animations like flip transition are noticed to cause RAM usage spikes when executed. This feature is very neat and should be used in many cases but it may trigger memory warnings in a heavily loaded multitasking environment. In particular we strongly recommend to avoid animating OpenGL views.
5. Test your memory footprint on device
Use instruments to test. The most useful tools are Allocations, Leaks and Activity Monitor. Testing on simulator is not relevant in most cases since its memory footprint tends to be completely different. Once you test you can figure out how much RAM each part of your app uses, where are the bottlenecks and how you can optimize.
From http://surgeworks.com/
I have a universal app that is essentially a list of articles with images and text, and menu under the left side of the app. I have google analytics in, as well as parse's framework.
The only difference between the app on the iPad and iPhone is that the side menu is always visible on the ipad, and a few interface objects are moved around. (different cell layout for the list--same content, though).
The images are loaded asynchronously using a set of classes that I wrote to download/save in an NSCache object and on the disk using a NSOperationQueue. (disk cache is wiped when the user leaves the app). The NSCache is set to max out at roughly 10 mb. (assuming image size is image hight*image width * 4 bytes per image). (code here is identical for both, so it shouldn't be the culprit, but it is a large chunk of the apps memory use).
I was having some trouble with memory warnings/crashing on an older iphone4 running iOS 5.0, so I ran the app with the Activity Monitor Instrument, and noticed something very odd:
On the iPad (an iPad 2 running iOS 5.1) the app launched, loaded the images that were visible immediately, and was using about 16mb of memory.
On the iPhone4 it launched, loaded the visible images and was using about 35mb of memory--way more than I would expect.
In order to check if it was an OS memory issue, I also ran the app on an iPhone5 running iOS6 and it used about the same amount as the iPhone 4.
I checked my media and the storyboard files to see if anything was different at all, and I could not find anything that could change the memory usage in any significant way.
Is there any way to reduce the memory use of the app on the iphone? I can think of no reason it would use so much memory.
Very difficult to see.. as one person stated pay attention that retina devices will use more memory according to the source, if in the bundle you set #2x images it will load them, and they use more memory.
Have tried to profile the Virtual memory using allocations?
Using memory is usually fine even if it fires a memory warning, the problem is how you respond to it, when it comes does it free enough memory? try with the simulator to simulate a memory warning. Pay attention that sim uses more memory than device.
One other point is that since ARC is difficult to create leaks, but it's easier to create retain cycle and abandoned memory. A correct object life cycle should end with object deallocation.
You say that you use NSCache and load images from the net async, I've got 3 suggestion for you :
Do you know the original image size on the source? maybe on the iPad source images are smaller than on iPhone. A correct approach after you download an image will be resize it according to the really needed size (I'm mean redrawing non just stretching) you ca achieve that with Quartz or using ImageIO
I never understood the behaviour of NSCache after memory warning, Apple says that it will flush the memory but after some test on iOS4 (I don't know now) I don't agree. I've created my own subclass that observe for memory warning and flushes memory
Are you totally sure that you are getting back image from the cache ?
I am working on an iPhone game which receives memory warning that I am not experienced enough to interpret. I have been watching some iTunesU tutorial but I am still not very good at this..
I have received various memory leaks whilst running my game and I wanted to understand how to interpret the stack trace show in Instruments properly.
I attach a screenshot of the ObjectAllocation instrument output . Even when I zoom filter I don't manage to filter the data in the ObjectSummary .
The peaks in memory usage in 1 happen when the GameScene is initialized and all the data is loaded (ParallaxBackground, CCSpriteBatchNode) and Sprites and bullets frames are created (in an CCArray of spriteFrames).
The big blue peak is just at load time but the app freezes and then crashes only after a while and from the graph I see that the memory usage (blue bar) has gone down.. so I don't quiet get that. Also, whenver I try to use the leaks instrument the App crashes..
I know is a very silly question for someone experienced, but I just need some extra help getting started with this toolset.
I think the memory problem are due to the sprites I allocate in sprite cache classes, but I am not sure on this and hence wanted to investigate this using Instruments but can't find out how to see what is the object causing the memory warning and how to access the stack trace..
PS: I am running on an iPod 4th generatio and I am using Cocos2D as library
EDIT: I do not also understand why if the Live Bytes are only 1.01 MB the App crashes and why I still receive a memory warning (see black flags). Is it due to some pointer referencing to some null variable or due to an excessive memory allocation? 1.01 MB doesn't seem much to me..
EDIT 2: Following Marion's advice I used the Activity Monitor and realized that the effective real memory usage is 55.39 MB. I misinterpreted the "live bytes" word. I will try to dig into this further and will leave the question as unaccepted for now to allow other people contribute. If I won't have any other answer within one-two days I'll mark as accepted the current answer. Thanks!
Thanks a lot!
If you want to find leaks, use Leaks instrument instead of Allocations. To find out, how much memory use at the moment, use ActivityMonitor.
If you will have problems with memory in cocos2d, you can try to purge cache. In cocos2d you can purge CCTextureCache, CCSpriteFrameCache, CCAnimationCache. It will release unused textures and frames.
If you want to check if all of unnessesary textures were removed from memory, you can place breakpoint to CCTextureCache class and call, for example, sharedTextureCache and look throw the content of textures_ dictionary. Or add some method to this class to be able to dump current state of cache.
I've looked carefully at leaks and I have none (very few - all under 400 bytes). I've read a few posts about not using imageNamed calls as they cache the images. I'm not using any of those. I'm using imageWithContentsOfFile.
I AM using lots and lots of images. Mostly rendered myself using graphics contexts. I'm releasing everything and you can see the memory being retained and then released in the instruments view.
Bottom line, after flicking back and forth through my images and tabs I get a memory warning level 1, then 2, then crash. All with memory usage usually under 5MB.
Is there some weird cacheing going on? This is driving me nuts. My iPad application is unusable as it crashes within a few minutes of using it as it seems to gradually piles up in memory without indicating any leaks or large memory usage.
Is it something to do with my 'Live Bytes' being 4.57MB but my "# Living" being 53825? Why is there so many objects still living? Is a living object count of > 50,000 normal? It keeps going up and up (the object count) even though the 'Live Bytes' stays the same.
As I describe here, the Allocations instrument does not show the total memory usage of your application. The 5 MB you are seeing in that instrument is only the tip of the iceberg.
Instead, you'll need to use the Memory Monitor instrument to see your application's overall memory size. I think you'll be surprised at the numbers there.
Tuning memory usage is a complex task, particularly with the large images you are dealing with. Just because Leaks doesn't show anything leaking does not mean that you aren't accumulating memory in some area. Perform repetitive actions in your application and use the new Heap Shot functionality in the Allocations instrument to see which objects, if any, are accumulating between each time you repeat an action. I've caught many subtle memory buildups this way.
Above given images is of my application leaks.
Here I want to understand that, in Extended Detail - you can see different colors like light green, light pink, light brown, light purple.
What does each color indicates?
Now the other confusion is "How to locate the code which is creating a memory leak?"
Upto what limit of memory leak - the actual iPhone can go on with.
(suppose 10 bytes no problem, 20 bytes no problem & 200 bytes a problem)
What does each color indicates?
Which color indicates our code / From which detail we can get to the code where we have allocated the object & forgot to dealloc it?
(For example - On clicking of UIKit second cell in detail - we cant get to the code)
Why we must resolve all the leaks? - even a single leak can chock up iPhone ?
Why iPhone allows leaks to be remain in memory? / why garbage collection isn't done automatically after termination of application?
If I try to dealloc objects which should be deallocated according to instruments, My application terminates abnormally. If I don't dealloc, My application runs perfectly, How?
Why it is suggested that you wait in a view up to 10 or more seconds, if there is a leak, leak will be detected by Instruments?
Ignore the colors, in that one the [DashBoard viewDidLoad] is the source of the leak, something in how it's initializing a URLConnection (possibly you did not free that when the connection was finished?)
Now to answer the other questions you had:
Why we must resolve all the leaks? -
even a single leak can chock up
iPhone ?
Yes. Part of the reason is not only that you will simply run out of memory, but since there is only so much memory to go around for the whole phone a watchdog application is constantly monitoring your app and will shut it down early if it sees memory use only ever growing...
Why iPhone allows leaks to be remain
in memory? / why garbage collection
isn't done automatically after
termination of application?
All your application memory is freed when the app quits.
If I try to dealloc objects which
should be deallocated according to
instruments, My application
terminates abnormally. If I don't
dealloc, My application runs
perfectly, How?
Here I can't help, you really need to read more on the retain/release memory cycle... if you release an object that has a retain count of 0, the app crashes because the object is gone.
Why it is suggested that you wait in
a view up to 10 or more seconds, if
there is a leak, leak will be
detected by Instruments?
Because instruments works by sampling memory every so often, so it might take a little bit for instruments to get around to reading the memory after an action.
First of all, the things in the stack are colored by which library they come from, so it doesn't contain that much information.
Second, instead of worrying about how much leakage the iPhone can take, I'd focus on not having it leak.
To find leaks, there are a couple options:
Use the CLANG static analyzer when building your project
Look for leaks manually. You must always follow The Rules of memory management: if you alloc, retain, or copy an object (including using #property (retain) or (copy)), you must release or autorelease it.
The colors represent the different libraries the call stack is going through.
The leak is caused by the frame in your code that made the allocation, even if the actual allocation is taking place deep within an OS library. Instruments is showing you exactly where the leaked memory was allocated. You'll have to figure out which line in your code resulted in the leaked allocation, which will be one of the frames in the stack on the right.
The actual iPhone doesn't have much RAM available to your application. I tend to conservatively estimate about 25MB of RAM for my application to work with. Any leak, no matter how small, can sink the proverbial ship if the code is used enough.
Look for your application name in the stack extended view. Memory allocation usually shown in the end, so you know exactly which library is responsible for memory allocation. So you should trace from the line your code appear downwards till the end. Colors just make easier to trace lines of code, that are related to same libraries. Same library calls will be colored with the same color.
As for tracing leak itself. First go to your application call by double-click on the line in extended view and try to understand what exactly leaks. Sometimes you can replace the leaking call with non-leaking substitute. For example, I used a call imageNamed to retrieve images from the bundle, the application was constantly crashing because of memory shortage. I just googled imageNamed leaks and found very useful article on how to implement image cash in my application. Indeed, imageNamed API leaks. There are API that leaks in iphone SDK.
Also, try to check how you're working with alloc/retain/release and so on, whether you release or autorelease your allocated memory.
Good luck in your detective work.
I too have problems with leaks in instruments. I run my app today for the first time using leaks and found several leaks. Leaks that shouldn't be leaks because there is no way for them to leak, unless some magical code is executing and raising the retain count of my objects. I understand the memory management guidelines, know how to use autorelease pools, etc. But even an empty view based app contained leaks if i put a few controls on it. And just click around 2-3 times. Go ahead and try it. I don't really understant the information instruments is trying to provide. Are those "leaks" really leaks, or just things that are suspicious to the instruments app? Should an empty app with no user code, only a few controls put on an empty view leak memory?