Swiping 4 fingers to switch between apps is fast and simple, the only problem is that it takes several seconds for apps to become responsive after switching to them. Obviously if it was true multitasking these apps would already be running and would instantly be ready for interaction. I respect Apple's decision to handle multitasking as they have, it keeps the devices speedy for the most part and negates the need for a task manager.
If I am not mistaken the current implementation merely saves the state of the app and then has to reload this state after the app is resumed. The first few seconds of viewing the app after switching back to it you are met with a static image, if you look closely you can see artifacts in this image. I am guessing these states are stored in a pagefile of sorts on the iPad's SSD and not in RAM. If this is not the case then the save states are stored in RAM and it is more a limitation of the software's ability to pull this information back up then it is a hardware bottleneck.
Could Apple make it so the most recently used apps, say 4, are stored in RAM while the rest are thrown into the pagefile? This should make app switching more instantaneous. Or, if app stats are stored in RAM, could these 4 apps actually continue to run in the background? With a rotating list of only 4 apps running this way it should maintain iOS's speed and be almost seamless to the end user.
I am sure the issue is far more complex than how I have stated it and Apple's engineers are more qualified than myself, but I enjoy speculating. Either way it is an issue I hope Apple will address so as switching between apps becomes easier and faster so does the responsiveness of their multitasking implementation.
Discussion about
Alright, the new gestures in 4.3 are impressive, but they really show the limitations of Apple's current multitasking implementation.
Sorry, this is just plain wrong.
When memory is low a background app may be killed in which case when the user switch, the app actually start from scratch, but the most recently used apps are restored and available immediately. How many apps are running in background depends on how much memory each of them use and how much memory is available in the device.
For example, apps such as Pandora are able to play musing while in background: how could it be achieved without true multi-tasking?
When an application is restored from background, an event is triggered and the application can do some stuff: depending on the code put in this event, the app may indeed be unresponsive at this stage, but this is completely dependent on the app itself, not the OS.
It is advised by Apple to release as much memory as possible when going in background in order to avoid being killed: the more memory an app use in background, the most probable it will be killed. So, it may be required to do some work when the application is restored, but once again, this is only dependent on the application programmer to do it well (e.g. by using a separate thread to prevent the UI from becoming unresponsive).
"Could Apple make it so the most recently used apps, say 4, are stored in RAM while the rest are thrown into the pagefile?"
This is actually what happens for the recently used apps: the other ones are killed.
When memory is low a background app may be killed in which case when the user switch, the app actually start from scratch, but the most recently used apps are restored and available immediately. How many apps are running in background depends on how much memory each of them use and how much memory is available in the device.
For example, apps such as Pandora are able to play musing while in background: how could it be achieved without true multi-tasking?
When an application is restored from background, an event is triggered and the application can do some stuff: depending on the code put in this event, the app may indeed be unresponsive at this stage, but this is completely dependent on the app itself, not the OS.
It is advised by Apple to release as much memory as possible when going in background in order to avoid being killed: the more memory an app use in background, the most probable it will be killed. So, it may be required to do some work when the application is restored, but once again, this is only dependent on the application programmer to do it well (e.g. by using a separate thread to prevent the UI from becoming unresponsive).
"Could Apple make it so the most recently used apps, say 4, are stored in RAM while the rest are thrown into the pagefile?"
This is actually what happens for the recently used apps: the other ones are killed.
Your example of Pandora isn't completely accurate. The entire Pandora app isn't running, the service for the audio streaming is running via Apple's API. There are a limited number of API's available for developers to allow certain multitasking features. Another is to allow downloads to finish in the background. This isn't true multitasking because the app itself isn't still running, a particular service is running through an API Apple has made available.
I am not saying my entire post is completely accurate, which is why I am asking these questions, but iOS does not utilize true multitasking because the full apps aren't actually running in the background.
I am not saying my entire post is completely accurate, which is why I am asking these questions, but iOS does not utilize true multitasking because the full apps aren't actually running in the background.
See my mext message: you are correct, but this is still true multi-tasking according to my definition. But obviously, it may depend on the definition of "true multi-tasking" :)
The app is not running per se (no CPU used or limited CPU), but it is loaded in memory and restored immediately.
The only important point is the end result for the user: iOS way of doing thing ensure that the front app has always enough resources and background apps may be killed if necessary.
The app is not running per se (no CPU used or limited CPU), but it is loaded in memory and restored immediately.
The only important point is the end result for the user: iOS way of doing thing ensure that the front app has always enough resources and background apps may be killed if necessary.
Android does have a level of task management but it isn't great. In my opinion neither solution is anywhere near perfect. My complaint with iOS is that when switching between apps there is a lag before I can interact with it, if my descriptions of how I believe these events function are incorrect I apologize.
You may be right that some apps do remain running in their entirety, but if so the resource management is a little to aggressive to me. Maybe it would just require a bit more RAM as dave said to make these switches seem smoother. As an example: when switching between the Kindle app and the Twitter app (the only 2 open apps) there is a 3-4 second delay in the time between the app screen appearing and my ability to actually interact with it.
On a PC the instant I switch to a new app I can begin interacting. This is also true for WebOS, QNX and Android... well unless I over do it a little with a few dozen apps.
You may be right that some apps do remain running in their entirety, but if so the resource management is a little to aggressive to me. Maybe it would just require a bit more RAM as dave said to make these switches seem smoother. As an example: when switching between the Kindle app and the Twitter app (the only 2 open apps) there is a 3-4 second delay in the time between the app screen appearing and my ability to actually interact with it.
On a PC the instant I switch to a new app I can begin interacting. This is also true for WebOS, QNX and Android... well unless I over do it a little with a few dozen apps.
You are correct, but the lag is mostly linked to the way the application is coded, not the OS.
iOS ressources management is indeed very aggressive for memory hungry applications and yes, more RAM would help!
Concerning WebOS, QNX and Android responsiveness, I don't know how they actually work (and nobody know for QNX I would say until the PlayBook is available because we have seen only controlled demos until now). However I don't believe in miracles: every OS with limited resources will have problems handling a badly coded or memory hungry application: even powerful desktop computer are not always responsive and I don't see how Android, QNX and WebOS could be different.
iOS ressources management is indeed very aggressive for memory hungry applications and yes, more RAM would help!
Concerning WebOS, QNX and Android responsiveness, I don't know how they actually work (and nobody know for QNX I would say until the PlayBook is available because we have seen only controlled demos until now). However I don't believe in miracles: every OS with limited resources will have problems handling a badly coded or memory hungry application: even powerful desktop computer are not always responsive and I don't see how Android, QNX and WebOS could be different.
I don't know if it is from the application. If it is then every single app has the exact same issue. Even Apple's own apps do it. Replace Twitter and Kindle with Mail and Safari and the same thing occurs.
I'm trying right now on my iPad switching between Mail, Safari and Map and I don't see any lag. If I add the App Store, I have may be 1-2 sec lag in this application, but still no lag in the other three.
When using the device normally, I never feel it was an issue, but of course it all depends on your expectations :)
I don't know why you have this problem yourself in every apps.
When using the device normally, I never feel it was an issue, but of course it all depends on your expectations :)
I don't know why you have this problem yourself in every apps.
I actually see the lag on an Engadget video that Nilay posted:
www.engadget.com/2011/01/12/ios-4-3-beta-arrives-f...
www.engadget.com/2011/01/12/ios-4-3-beta-arrives-f...
Well, I was talking about the 4.2 release using the home button to switch: I may have misunderstood the OP?
I don't know about the 4.3, but it is a beta.
Sorry if you were talking about the new 4.3 beta release :)
To be honnest, on my iPad, I feel that iOS 4.2 is not as responsive as iOS 3.2 was overall: 256MB is not a lot of RAM indeed.
I don't know about the 4.3, but it is a beta.
Sorry if you were talking about the new 4.3 beta release :)
To be honnest, on my iPad, I feel that iOS 4.2 is not as responsive as iOS 3.2 was overall: 256MB is not a lot of RAM indeed.
I don't know how multi-tasking is implemented in Android, but miracles do not exists: if nothing prevents background apps from using too much resources (memory or CPU), you will get into troubles quickly as current devices do not have a lot of RAM or very powerful processors (compared to computers).
In iOS, Apple prevent background app from using too much CPU by limiting the kind of tasks an application can do while in background. Memory hungry apps are just killed as memory get low.
iOS implementation of multi-tasking ensures that the front app has always enough resources: background apps are killed if necessary.
As far as I know, there is no such mechanism in Android which means that depending on how many applications are running in background and how well they are coded the front app will be more or less responsive.
You can prefer Android way or Apple way: both have pros and cons. But iOS has true multi-tasking contrary to what many Android users say: do not forget that iOS is based on MacOS X and thus UNIX.
In iOS, Apple prevent background app from using too much CPU by limiting the kind of tasks an application can do while in background. Memory hungry apps are just killed as memory get low.
iOS implementation of multi-tasking ensures that the front app has always enough resources: background apps are killed if necessary.
As far as I know, there is no such mechanism in Android which means that depending on how many applications are running in background and how well they are coded the front app will be more or less responsive.
You can prefer Android way or Apple way: both have pros and cons. But iOS has true multi-tasking contrary to what many Android users say: do not forget that iOS is based on MacOS X and thus UNIX.
I definitely agree with you.
This might be an issue with the fact that the iPad has such limited RAM (256MB, compared to 512MB in the iPhone 4). It's especially noticeable in things like Safari, where just switching between a few tabs within a short period of time results in a webpage having to completely reload.
Hopefully this is something they'll address (and further optimize for) in the next iPad update!
This might be an issue with the fact that the iPad has such limited RAM (256MB, compared to 512MB in the iPhone 4). It's especially noticeable in things like Safari, where just switching between a few tabs within a short period of time results in a webpage having to completely reload.
Hopefully this is something they'll address (and further optimize for) in the next iPad update!
I'm currently developing my first iOS app and I can now tell you that a typical application use less than 50MB in memory (20-40MB I would say). But a badly coded application which load too much images without using the "lazy" technique (load only what you see on the display) can easily consume 100 or 200MB.
256MB is thus enough for 4-5 applications running at the same time I would say if they are well coded, but as soon as you use a badly coded application which request 200MB while being the front app, all background application will be killed.
Having more memory is thus indeed the most important point in the future to allow more complete background tasks.
256MB is thus enough for 4-5 applications running at the same time I would say if they are well coded, but as soon as you use a badly coded application which request 200MB while being the front app, all background application will be killed.
Having more memory is thus indeed the most important point in the future to allow more complete background tasks.
