I have a RSS feed reader app that I'm running through profiler, and I'm noticing that whenever I load a uiwebview and pop it from my navigation controller, my Live Bytes goes up by a small amount (.10-.40MB). I'd expect Live Bytes to stay where it was at before the uiwebview was launched. Does this indicate that I'm leaking something or is this normal for uiwebview objects?
On the basis of your comments, I went back and examined my webview to see if there were any leaks. Profiler didn't report any leaks, but the number of Live Bytes was definitely going up a small amount every time I presented and subsequently dismissed the webview. In my case, Live Bytes was going up by 40-50kb each time, not 100-400kb, but nonetheless, it was definitely growing. My earlier comments were based upon leaks identified by Profiler's Leaks tool (e.g. the Twitter.framework definitely has a known identified leak but it's tens of bytes, not kilobytes). I generally don't track Live Bytes, so I apologize if I misled you.
So, in answer to your question, I guess it is not unusual for memory to be consumed as you present and dismiss webview controls. I would not be inclined, though, to consider the growth in Live Bytes a leak unless the Profiler is also reporting a leak in the Leaks tool.
Related
We were testing our app, on the first generation iPad, using the profile tool, which uses a lot of memory on the iPad, in Xcode and found that our app had slow memory deallocation (It took more than 1 minute to deallocate 20 MB). However, in our code we properly deallocate memory. We then monitored some professional 3rd party apps (Chrome and Flipboard) and noticed those apps also had the same rate of deallocation.
Does iOS or iPad 1 have slow memory deallocation or perhaps the profiler interferes with iOS's memory deallocation?
We are using the lastest iOS version. And yes, in real world usage our app's performance will be affected by the slow deallocation of memory
We measured the rate of deallocation by loading the app and waiting for the memory to stabilize and then loading media or a view and waiting for that to stabilize then we go back to the original view and see how load it takes to deallocate the previous view/media. Which goes at a rate of (less than 20 MB every 1 minute). The app will never go back to it's original memory usage, the usage after opening the app and waiting for it to stabilize, when on the startup view.
We measured the rate of deallocation by loading the app and waiting for the memory to stabilize and then loading media or a view and waiting for that to stabilize then we go back to the original view and see how load it takes to deallocate the previous view/media.
This is not a useful benchmark. Okay, so you allocated some memory. Then you told the OS that you didn't need it any more. Fine so far. It's often not going to bother doing much about it unless it needs the memory elsewhere. It makes more sense to keep a cache so that if you need it again, it's available quicker. You aren't measuring anything useful - you're measuring how long it takes the system to need the memory elsewhere, not how long is necessary to deallocate it. Common sense should tell you that a minute to deallocate 20MB is not correct.
I suggest you come up with a benchmark that measures what you are actually interested in. How would your application be affected by slow deallocation? Are you sure you aren't inadvertently using that as a poor substitute for a factor you really are interested in?
If you do release memory when needed (i. e. you make the effort to minimize the time during which memory is allocated), then you don't have to worry about "slow deallocation" (whatever this nonsense word means).
Don't overestimate a profiler's abilities.
I'm trying to debug a mysterious app crash that happens after running the app for a few hours.
My hunch is that this may be memory related, as I've not done any memory optimization since starting to build my app.
I'm looking at my application with the "allocations" instrument and I see these numbers:
All allocations 4.70mb
Living 51072
Transitory 357280
Overall Bytes 100.23mb
Overall 408000
Which is the important number here? Does my app take 4.7 Mb of memory or 100 Mb? At which point should I be concerned about my app being killed for memory reasons? I want to avoid premature optimization :)
Since I'm using ARC and TabBarController, most of the controller related memory seems to be out of my hands, unless I find out how to create a tab and lazily init a controller when that tab is first touched.
Thank you!
When I try to send images as attachements(summar size ~4mb) by using MFMailCompose, activity monitor says, what 100(+-2)mb of memory is used. After sending or cancelling memory is freeing ~20 megabytes, but what happened to the remaining 80 megabytes if shared item with images is deallocated?
Thanks!:)
An image's file size and the amount of memory it consumes when displayed are two completely different things.
Images such as JPEGs and PNGs are compressed. When they are drawn to the screen they are uncompressed.
A quick rule of thumb to figure out how much memory an image will consume when displayed is
memory consumed = (width * height) * 4
Example, a image that is 2 KB on disk, but is 62 x 52 pixels will actually consume 12,896 bytes or 12 KB. I imagine an image that is 4 MB on disk will consume a lot more than 4 MBs.
The problem is that MFMailComposer displays the images in it's compose view when you add them as attachments and as a result they are decompressed, consuming memory. So your 4 MBs of images actually consume a lot more than you think they do.
Perhaps try sending only one image at a time. You also need to be conscious that you're releasing the images and the MFMailComposeViewController when you're done with them, or that would surely be the source of the leak.
Also be aware of how you initially load your images. UIImage's imageNamed: method actually caches images. Cached images are only purged in low memory situations, so they can hang around for a while if you're not hitting the limits.
Finally, you've noted that you're seeing the memory consumption in Instruments, but have you actually verified that it is actually a problem? Are you experiencing app crashes due to low memory when testing your app while it is not connected to Instruments or the debugger?
No body is perfect - and that goes for Apple too. There have been documented cases in the past where Apple's frameworks have shown memory leaks (UIImage's caching leaked in iOS 2.x), but I wouldn't be so quick to blame the frameworks when you notice a spike in memory consumption. If the leaks instrument is not showing any leaks, and the analyser isn't showing any issues, the likeliest scenario is that it's just simply memory consumption and not a leak.
Its important to remember that iOS devices don't have gigabytes of RAM like computers do. You need to be conservative with the memory that you use. If that means not sending XX MBs of images at the same time, then that's the way it has to be.
I'm having strange effects with my app. I implemented my own PDF viewer. It shows ONE page at a time. Using Instruments Activity Monitor I see that my real memory is constantly at around 50MB.
After switching pages forth and back a couple of times I receive a memory warning level 0.
I do my best to react on it and sacrifice the low-res background image I'm rendering first to show something until CATiledLayer catches up.
Does not help. A few pages later I get memory warning level 1 and level 2 and after a few more pages my app gets killed with reason "9". Memory NEVER goes above 50MB!
Why do I get those warnings in the first place? There IS enough memory available.
This is happening on on iPad running iOS 4.3.
I don't think there's anything mysterious going on here -- which I'm sure is not what you wanted to hear. There are no absolute figures of "safe" amounts of memory to use. The rule is: when the OS tells you you're using too much, use less. It will jettison background processes first and in preference to your foreground app but there are still limits.
In the "olden days," you used to be lucky to get 20Mb. I'm sure you can safely get more than that on an iPad but, apparently, it's less than 50Mb.
You don't say how much memory you free by releasing the background image, but it seems that you need to be caching less data. You might also want to check Leaks (also in Instruments) to make sure you're releasing the objects you think you are.
Ah.. We've developed a good iPhone application. Now, 'm passing through last phases of it, i.e. profiling it and I've encountered few problems. Application has few leaks and objects occupying large memory chunks. We just checked somehow, application is not lowering its memory requirements and blocks remain occupied with creation of each View Controller.
Some of the views I really don't want after their disappearance, but they are not deallocated.
We're also downloading large files into iPhone through app but once we download very large file (> 10 MB), it crashes. Because after download we've also used thumbnail generation logic into which UIImage is created with 'contentsOfFile'..! So, app generally crashes after use of large files. We've used UIWebView for thumbnails.
My real problem is download, thumbnail, preview of larger files... clearing unnecessary memory (objects) once view is not in focus..!
Can anyone help me get rid of such problems easily???
I really don't wanna go through long long code..!
Thank You..!
As has been written hundreds of times on SO, use ASIHTTPRequest for networking, especially for large files. It can stream big files directly to disc so you don't run out of memory. As for creating a thumbnail of a >10mb file, it sounds like you would do yourself a favor by storing a thumbnail on the server instead.
If your views don't unload, something is wrong with your retain/release cycles. Have you implemented viewDidUnload on all your view controllers? Without more details, it's very hard to help.