I am rather confused about how this would be possible with the iOS Sandbox, but there appears to be an app in the App Store that does this: Dual Core System Activity Monitor for iPhone 4S
According to the Developer Website this app can:
Stop Apps:
Use the Stop Apps button to quickly free up memory. Tap the button and dismiss the dialog multiple times to free up additional memory each time. You do not actually need to double press the Home button to kill the apps.
I am able to get a list of processes running with their pid's. How could I "free up memory" by, I assume, killing processes or other apps?
Note: While I intend to submit this particular project for the App Store, I would still be interested to know how this is done on a jailbroken phone, if that's your specialty. Plus I'm sure other programmers reading this could benefit from such knowledge as well.
I think that's a scam app ..it's iOS's duty to terminate processes if you need more memory.
You could read the list of processes and then virtually terminate them (remove them from a table view or something) but not actually terminate the process itself.
Maybe it is claiming a lot of memory (be still below the threshold) so that iOS kills of other running apps. While shortly after releasing the memory.
Related
Suppose I am using one App (no other App is active). Now I lock the iPad by simply clicking the lock button or may be I put it in background mode and put my iPad somewhere.
After what amount of time, the App will get killed automatically by system if I don't use that App? Is there any specification by Apple or we cannot say anything that App will launch from scratch in some scenarios.
Note that in any scenario, I don't kill my App manually.
iOS generally (at least in current versions) doesn't kill apps after some arbitrary time. It kills them when it needs to free up resources. Since modern iPads have quite a bit of memory, that means that apps can stay in the background for a very long time depending on how the iPad is used. As Andreas notes, however, there are no promises about that.
Subtitle: How to make an iOS app launch so fast from background to foreground state?
I just reviewed the App Life Cycle page and make some conclusions.
Checked out the excellent apps like Apple Reminders and Spark mail, their app's launch screen just occurs in the first launch time mostly, after that, no matter how soon it's launched, the main screen will show quickly in my iPhone 6 device. (1G RAM, with lots of app installed.)
Here is my guess, the main cause is on data management when receiving memory warnings, it just releases all the retained data (array) of view controllers and other reusable objects. The app keep a low-level memory usage all the time, especially in the background state, when iOS system get the low-level usable memory to run the active app, it sends the memory warnings to all the un-active apps, especially for the background apps, if someone keeps a high-level memory usage after receiving memory warnings, iOS will try to kill it absolutely, or it's allowed for background apps to keep a low-level memory usage.
If so, how many/percent used memory for iOS app is allowed? What's the threshold? Any documents for that?
I did a lot of search with no luck, please point it for me, great thanks!
Is there any possibility to know which apps are in the background (Those apps that appear when you double tap home button)?
For 3rd party apps, no. Not in a reliable, App Store safe, future proof way. Think of your app as siloed, unaware of what else is running, and you'll be pretty much in the mindset Apple want (and try to technically enforce).
For other apps developed by you, you can use shared containers to write load/unload data each time one of your apps opens/closes, and work out what's currently running.
This is not possible on iOS with public api. There might be private api calls that do this, even though I don't think you will have access to them while running in the sandbox. This however might be possible on jailbroken devices, but you will not be able to submit to the app store with such api usage, unless you know how to hide that from apple.
Also please note that apps shown in the app switcher are not necessarily running. The app switcher shows every app that has been running in the past which the user didn't force-quit. If the user does not force quit an app, every app that has ever been launched is shown in the app switcher. If iOS decides to terminate an app because of memory needs, the app is still shown in the app switcher. This is one of the reasons why everyone should implement state restoration, as the user does not know whether an app is currently running or not!
This question might have been asked before but i couldn't find an answer. If i open an app and press home button it goes in background and if i open it again it calls app delegate methods such as "applicationWillEnterForeground". How long it will take me to be in background so app calls didFinishLaunchingWithOptions and starts the fresh app?
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
Thanks
There are many factors that are taken under consideration to remove your app from the memory (kill the process).
The most simple one is rebooting the device. All apps are off after a reboot. Apps with Voip however are launched automatically into the background after a reboot.
The second and most common one is memory pressure. If your app is in the background and system runs out of RAM, it kills the suspended apps starting from the one that consumes the most RAM and keeps killing them until it reclaims enough memory.
Another, quite common one is something known as the watchdog. There are specific scenarios when your app's main thread has a limited time to finish the task. For example, when you app returns from the background or when the user presses the home button, you have about 10s to free the main thread. (Keep in mind there are situations such as background tasks, music playback and other, that grant your app more execution time in the background).
But, a typical app will be killed if the runloop does not return in about 10.
Another case worth mentioning is if your app uses very little RAM. It was mentioned in one of WWDC sessions, that if your application consumes no more than 16MB of RAM, it will be dumped to flash storage, and restored back to the memory on reopening, rather than being killed. So in this case your app may never be killed (I'm not sure about the reboot, but I assume the dumped image is ignored after a reboot and a normal launch process happens).
Next one is the user's explicit action, that is entering the multitasking UI and swiping the app upwards, which will kill the application.
I think that sums up the most common scenarios.
And of course you might also want to have a look at the docs: https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/TheAppLifeCycle/TheAppLifeCycle.html#//apple_ref/doc/uid/TP40007072-CH2-SW1
How much RAM does the device have? Have much RAM was your app using? Are you following best practices when your app receives didReceiveMemoryWarning:? Are you opening other apps before going back to yours? This is such a "it depends" question.
What's the larger question here? Why do you want to know when your app will get purged from memory?
Is there a any chance that an in memory data might be lost when an iOS app goes to background?
for example if the OS give notice to the app with
didReceiveMemoryWarning and the app didn't take any action to release some space.
so far I have never notice this.
Not instantly, but the app may be terminated at any point, if other apps are used and the system decides, that it needs the memory blocked by your app.