I was inspecting my crash log and noticed several apps appear to have been jettisoned. But looking at the multitasking bar, they are still there. Is there another way I can confirm that inactive apps are actually being jettisoned before my app crashes? Can this be seen in any of the tools?
Up until now, I assumed my app was being closed without the inactive apps being jettisoned. Now I'm unsure.
Update
I have, on several occasions, had my crashing app stop crashing after I removed everything from the multitasking bar. I didn't check the crash log in those cases, and I'll have to do that in the future. But it's hard to imagine that that was just a coincidence.
The bar is simply a launch history. It doesnt represent the current state of your device memory except by coincidence.....
I used instruments to see what the memory usage was while my app was running. I can see that real memory in the Memory Monitor reports the amount of real memory being used by each app.
Seeing that several inactive apps were showing memory use, I confirmed that they were in the multitasking bar. I was able to manually delete each one from the bar and saw an immediate response in memory usage. Each deleted app disappeared from the memory usage list.
This answers my question -- Instruments can show how much memory is used by apps that show up in the multitasking bar.
Apparently, the multitasking bar is showing applications that are currently taking real memory. It is not just a launch history.
That being said, I don't understand why Jetsam does not release these apps before killing my running app. I'll post that question later as a new one.
Related
If I send my app to background by clicking the home button and wait a certain time (perhaps 1 or 2 hours).
What will happen if i tap on the app icon now?
Will the app relaunch or simply be brought from background to foreground?
Quick "prologue":
Welcome to the wonderful world of stack overflow (SO), I myself am rather new here, but found it much friendlier to use welcome you anyway!
Just in case you haven't: Before you ask a question please look around a bit on SO in case someone else has asked the same thing, but if you can't get your question answered from that, then you should of course ask your own question.
Answer:
This question has no definite answer, because it depends. When you tap the home button your app enters, as you've said, the background and is still running to a certain degree. However after done so, the apps life cycle is up to iOS (the devices operating system) to determine. iOS controls and checks memory and CPU usage (etc..) of the device, and if you start another activity while your app is in the background that makes the available memory and CPU etc of the device not sufficient, iOS will terminate any apps in the background to not waste those resources (or battery etc). If so your app will relaunch next time you tap on it.
Although if you don't do anything performance heavy it is more likely that iOS keeps your device running in the background.
I'm not sure about the exact conditions and such the iOS works on, but i would say its very likely your app will have gotten terminated and is relaunched after 1 or 2 hours "in the background". Additional conditions apply if the device is locked during that period.
For proper documentation of this i would recommend reading Apples documentation for handling App State Transitions and/or the api for UIApplicationDelegate on apples developer website. Where you can see what the different methods in the AppDelegate does and how they interact.
Edit (answer to comment):
A way to relaunch the app everytime it goes into background?
Hm, yes, but also no. I'm not 100% sure about this (never encountered that "wish" before), but you can do this in your AppDelegate: (It will basically crash your app, but beware that apple does not encourage you to crash your own app anywhere). Doing this might stop the app from passing through apple store review process (i.e. your app might not be accepted to the App Store).
func applicationDidEnterBackground(_ application: UIApplication) {
exit(0)
}
Check out the answer to these post for a bit more information: call exit(0) in iphone app , objc - Proper way to exit iPhone application?.
Personally I would recommend you to work around it and don't do this. Also remember that when your app will enter the background applicationWillResignActive will be called and when the user opens it again, applicationDidBecomeActive gets called so you can do a reload or something from there if you want to refresh any data.
Whenever we press the home button in our device, the application releases the currently being used memory and moves to background stage. However, when we press this application app icon again it brings the app on top of the iPhone screen and occupies memory again. This is definitely not the relaunch because relaunch depends upon the UIApplicationDelegate method
didFinishLaunchingWithOptions. When we are switching app from background to foreground then applicationWillEnterForeground method fires.
For better understanding, the following link might be useful
iOS Application Life Cycle
I working on a game that has some hitches (freezes for a bit) under certain loading situations.
If I start the phone or remove/reinstall the game, the hitches are there. If I kill the app and re-open, the hitches are gone which makes me believe they happen when the game assets are being loaded into the RAM. When I kill the app, memory becomes inactive but it's still there to be loaded quickly if I re-open the game.
I need a way to clean the RAM so I can reproduce hitches quickly, that is, quicker than restarting the phone or reinstalling the app.
I tried to do a trick involving holding the wake button then home button but that obviously only kill all apps and do not erase the memory.
I also tried to use this project that uses malloc and memset to clean the memory until it crashes (allocate and erase more memory until it crashes), but it doesn't clean the memory my closed game used. I have the impression that iOS deallocates inactive memory from apps that were used before my game, so the memory allocation app never gets the chance to use my game's inactive memory, because it's killed first.
Therefore, I'd like to understand how iOS chooses which inactive memory to use and how can I make my app inactive memory to be cleaned from RAM.
Please notice I'm not trying to find a way to free memory while playing, not trying to make the game use less memory, I'm trying to clear the memory the game used after the game is closed so the hitches happen 100% of the times I open the game.
I'm using an iPhone 6, iOS 10.3.2.
It's impossible to describe this in a couple of words. First of all I'd recommend you to review this article.
If you want to release unnecessary objects manually, take a look at description of didReceiveMemoryWarning() method of UIViewController
I converted one of my apps over to LibGDX.
In the earlier version, when I launch an in-app purchase and iOS shows the dialog to ask the user for their password, my app would stay visible and running (animations would update) in the background behind the dialog.
After the switch to LibGDX (and no other changes regarding purchasing), the app now disappears and the background behind the password dialog is just black. Right before this happens, LibGDX reports [debug] IOSApplication: paused and right when my app comes back to life, I get the message [debug] IOSApplication: resumed.
Is there any way to have LibGDX keep updating my app's screen while it's paused (preferably only if it is still partially visible, though), or at least keep displaying the last drawn frame rather than switching to black?
PS: I have continuous rendering turned off.
I found a way to fix the problem: Get rid of LibGDX.
Here's how: https://stackoverflow.com/a/35094695/1217178
Disclaimer:Clearly this isn't a true answer to the original question, but unfortunately I don't have the time to go hunting for bugs in libGDX, especially since my app is almost 1MB (15%) smaller and starts faster without it, too. But if someone else comes across this issue and figures it out, please do post your answer and I will accept it instead of this one.
The reason why I am doing everything below: I have a GPS tracking application which should run in background all day long. Memory usage doesn't go down when I put application in background. It seems like views are not removed from memory when app goes into the background... That is why the app is closed in few hours of normal usage of iPhone ... From IOS6 experience - memory usage should drop to cca 8KB.
Then I tried to debug/isolate the problem ...
I created simple ViewController with UIMapKitView just to make sure that view is consuming a lot of RAM (e.g.: 12-17MB). When app goes to background app uses same amount of RAM until "Terminated due to Memory Pressure" message. Still - sometimes memory lowers to 4KB and everything is OK. Problem is because it works kind of "random" and the app is plain simple.
Can I manually release RAM which is consumed by views? E.g.: set self.view = nil? Should I do it?
I also noticed that "- (void)didReceiveMemoryWarning" is not always called before app is killed. I would expect that when OS needs more memory it would first release views, than ask me to clear anything I can via this method ... Isn't this a little bit strange?
Apple redesigned the way a VC's (view controller's) views were loaded quite a while back - I want to say starting with iOS 5? iOS 6? It used to be that the system would unload your VC's views when a VC was not front-most and it needed the memory.
With the changes, a VC's views are NEVER unloaded while the VC is active. ViewDidLoad only gets called once in the lifetime of the VC, and viewDidUnload is no longer called at all.
I don't know what would happen if you set your (non-frontmost) VCs' content views to view manually. Would the system load your view hierarchy when that view became frontmost again? You'd have to try it, but it is risky since I don't think the OS is designed that way any more.
If your VCs views are holding significant amounts of memory, you might want to re-architect your app so only the front-most app is kept around, and the other VCs are released (after saving their state.)
Apple does not make this sort of app easy to write. To the contrary, they actively discourage it. The GPS is a huge power drain, so keeping it active constantly is going to drain the user's battery fast.
I remember hearing about a new location chip in the 5s that will record a "crumb trail" of location data for your app even when it's not running, at your request. You might look into that, although it would only work on the newest devices with the A7 chip and location chip.
In my case the problem was specific IOS7 version. Every app was crashing with this version of OS. When we updated OS version, everything started working back as it should.
I am facing the above issue and unsure why it is happening or how to fix it. When the app goes to the background and is later reopened, it always starts from the initial view.
I would like it to show the view that was shown when the app was dismissed - which is usually the default for iOS apps.
Can someone please explain why this might be happening and how I can resolve it.
Your app is probably killed while in the background to free it's resources for other tasks.
If applicable you can opt to use a background mode for your app so it keeps running in the background. This is possible if you require location updates, play audio or interact with bluetooth le devices.
By your description it's more likely you want to implement State preservation and Restoration (Programmig Guide)
Even if your app supports background execution, it cannot run forever. At some point, the system might need to terminate your app to free up memory for the current foreground app. However, the user should never have to care if an app is already running or was terminated. [...]
The state preservation system in UIKit provides a simple but flexible infrastructure for preserving and restoring the state of your app’s view controllers and views.
If you are on an iPhone older that the 3GS, this is normal. Apps are closed instead of backgrounded on these older models.
The other possible reason is that you've set
UIApplicationExitsOnSuspend=YES
in your Info.plist. In that case, your app will also always terminate when going to the background.