I am particularly new to iOS & still quite distant from the basic Concepts.
I read in iOS books & forums that the application crashes due to low memory but why does it crash?
It would be helpful if someone could throw some light.
iOS Devices Use virtual memory with Paging . As it is a Mobile device and there is no Extensible memory or pretty
large Memory available (Like Hard drives) , so the availability of the pages is limited by various factors such as the number of applications open , Allocations by different applications , etc. Moreover , some on-board applications will always keep using some pages even when they are in dormant state such as safari , i-tunes , messaging etc.
So , essentially with number of application active , the number of pages your application can use gets diminished further.
So , your application will crash in cases when the rate of allocation by your application is exceeding the rate at which pages are being freed by other Applications.
OS only frees up read-only data from the memory while writable data is not freed-up .When the writable data crosses a certain threshold , the OS asks the application to free memory.Unable to free the memory leads to the crash.
Memory Allocations Apple
It does not really crash. Apps get terminated by the kernel if they do not free enough memory after a notification.
To make this transparent a crash report is written which contains the specifics about the current situation. To the user it looks like the application crashed, as it just suddenly disappears.
The devices don’t have much memory and if you are piggy with memory, you are looking for trouble
iOS have good memory tool called ARC. Please read the full documentation here
I've been burned before in my own apps when loading table views consisting of nothing but UIImages, which might look like tiny thumbnails in the table but end up being full resolution (and lots of memory) objects behind the scenes.
You need to be careful when working with objects that can be potential memory hogs.
But take heart, Apple provides tools like Xcode Instruments you can use to profile your app's memory performance.
Related
I recently profiled my app using Xcode VM tracker instrument.I found that app has lot of dirty memory especially performance tool data. So i want to know what are the reasons of the huge dirty memory and performance tool data.
Any help would be appreciated.
Your app takes 51MB to store, when it is suspended. The performance tool itself adds an overhead of 30MB. Which leaves 20MB for your app.
From the listed items, it looks like your app is graphics heavy. In fact, it looks very similar to this post. Which makes me wonder if these objects are still processing or waiting to be released, when the app is suspended.
Alternatively, I wonder if you could free a lot of those animations and images when entering background, and reconstruct them when entering foreground.
Finally, note that Apple recommends removing strong references to images, data from disk and media to reduce dirty memory.
Since I just had the same problem, here is what I found:
The "Performance tool data" entries were from libBacktraceRecording.dylib.
You can disable backtrace recording in the scheme editor.
See the related question Memory leak with “libBacktraceRecording.dylib” in React Native ios application.
All over this document Apple mention iOS terminates apps under certain conditions, and the most popular reason seems to be freeing up some RAM. And that causes issues for apps that do not implement state restoration - some of the content user is working on and stepped away from for a moment could be easily erased. There's even a 16 page thread on Apple forums where users complaining about that.
Is anyone aware why iOS actually terminates apps instead of moving memory occupied by them onto disc/swap?
Does termination actually provide considerable performance improvement compared to other means?
What you are describing is paging, or more accurately, page swapping. The iOS version of BSD Unix does not perform paging, for lots of reasons. Here are a few educated guesses:
It's too power-hungry for a mobile device.
Flash memory can't handle the churn involved in paging. Flash memory has a limited number of lifetime write cycles per storage location, and paging would chew through the life of the flash chip.
As the other poster pointed out, swapping to disk would use up available disk space, which is also limited. Not a problem when you have a 500 GB drive, but it is a big problem on a device with only 16 GB of HD and 1 GB of RAM.
You're not going to get an answer for this question here. Apple don't explain the inner workings of iOS and anything else is going to be guesswork.
Here's my guesswork:
iOS is a heavily resource constrained environment. Memory is limited but so is disk space - a 16GB iPhone has 1GB of RAM, so "swapping to disk" isn't really something that can be freely applied. When do you stop? How do you know this isn't already being done, but there is only a limited swap in place?
The primary goal of iOS has always been to prioritise responsiveness of the foreground app. Anything other than warning, then closing background apps would probably impact this too much. If there are 15 apps in the background then imagine the processor load on nicely swapping the memory out for each process?
Because the RAM that was saved onto the disc would be much slower. It's better to cut the program then having it run poorly. I think that answered both questions.
Thanks everybody for responses. I had to do some research to answer this question, though. So I was looking for more understanding that led into "app termination" decisions. I know, there are some smart people working in Apple, but for me it always help to understand the reason something is build "this way" rather then just following it.
It turned down into these 2 questions
Why iOS terminates apps instead of freeing memory by paging out (swapping)?
Does termination provide considerable performance win?
To understand that I dug a bit into the history of iPhone. There's a video that was accessible on iTunes, unfortunately the link does not work anymore. Anyways, the video was introducing the very first version of multitasking on iPhone 3G (or was it 3GS? Not sure which device starts to support multitasking).
Nowadays iPhone devices are quite advanced in terms of hardware. Those are actually more advanced then some desktops we had 7-10 years ago, which already have had incorporated swapping long ago. But if we look for first iPhone releases, those are not that much advanced in terms of hardware. iPhone 3G is 620 Mhz ARM and 128 RAM. iPod touch 1gen had 400mhz ARM. And multitasking was supposed to run on all the devices of that time.
If we take a look at iOS, it was always has the smoothness of animations in priority; taking look at hardware I see it would be challenging to have both snappy and responsive device along with processing swapping background applications memory, so it seems very logical and very fair to terminate apps. A year or two later Apple provided APIs to facilitate implementation state restoration.
But if we look at the current iPhones and iPads - they do have enough power in order not to terminate apps and just drop their memory on disk without any drop downs in animations and foreground app performance. Why not add that on latest devices? I assume this is common for the software industry; new features often prioritised higher then improvements on existing workflows; Apple has been releasing MobileMe, support for Retina displays, AutoLayout, iCloud - so I can understand that cool improvements of already existing features has been sacrificed.
The issue with apps that don't provide state restoration is easily solved by providing state restoration.
Just killing apps when the system runs out of memory is a huge performance gain. Consider that the system usually runs out of memory when you launch another app, and any action that is done instead of killing old apps would have to be done before launching the new app; that's about the most performance critical point in time.
And for at least five years you have been told that when your app goes to the background, you should store just enough state to come back to that state if your app is restarted.
I'm trying to get a feel for the amount of memory an iOS app can reliably allocate to help me drive some design decisions. The app is going to involve real time synchronised processed audio and animation.
Other than writing code that loads up the frameworks I'll need then trying to progressively allocate memory until I get warnings, is there any way to determine this kind of thing?
The simulator doesn't let you select a specific hardware model, so I assume I can't even simulate this stuff.
You cannot determine how much memory an app allocate as far as I know. Always try to keep the lowest memory possible for your app.
The memory allocated to your app depends on many factors like : number of background process happening, amount of memory available, memory used by other apps, the device you are running etc..
So, its not a good practice to keep a maximum line for memory consumed by your app and design accordingly.
Also try to hold only the necessary memory you need and handle memory issue in the memory callback methods like 'didreceivememorywarning'. Always consider that you have the least amount of memory allocated by the OS.
Can someone suggest to me a way to count (inside an iOS app) all open apps on OS, to show to the user an alert if there's not enough memory to run my app?
While theoretically this is possible, it's not a good idea. First of all, the number of open apps is an inadequate measure when in fact you care about memory consumption. Next, this doesn't take into account the fact that different devices have different amounts of memory. Last but not least, if memory is running tight iOS will first kill background applications and free some memory for you.
So, don't do it. Instead, try to be a better iOS citizen: respond to memory warnings, try to cache stuff in files and read up on memory mapping (for example with mmap) to reduce your app's memory footprint.
I'm developing an iOS application which (like any other) requires a certain amount of free memory to run correctly. In my case - at least 4MB, I cannot use any less than that. It's a fairly small amount, but a few times (on my device at least) I got only 2MB free and the program crashed. What do you think is the best way to tell users how much memory you need. I know the code to get the currently available memory, but even if I tell the user (like in a UIAlertView when the user starts the program) that he is running low, what can I suggest him to do to free more memory (except turning off and on the device). Any ideas?
On older devices you can't really rely on getting more than 8MB. 4MB is a great target, and if through your profiling you've determined that's all you need, you should be fine.
However, I think the concept here is that if you receive memory warnings you wouldn't bother the user with those types of things. I would find it pretty annoying myself. It would be better to limit your app's activity or throttle back whatever you are doing that is so memory intensive.
On which kinds of iPhone devices your app is being tested? I suppose that the iOS has to do its job well to free enough memory for you or kill alll background app so it can have more memory