Slashdot Mirror
Public Service Announcement: You Should Not Force Quit Apps on iOS (daringfireball.net)
John Gruber, writing for DaringFireball: The single biggest misconception about iOS is that it's good digital hygiene to force quit apps that you aren't using. The idea is that apps in the background are locking up unnecessary RAM and consuming unnecessary CPU cycles, thus hurting performance and wasting battery life. That's not how iOS works. The iOS system is designed so that none of the above justifications for force quitting are true. Apps in the background are effectively "frozen", severely limiting what they can do in the background and freeing up the RAM they were using. iOS is really, really good at this. It is so good at this that unfreezing a frozen app takes up way less CPU (and energy) than relaunching an app that had been force quit. Not only does force quitting your apps not help, it actually hurts. Your battery life will be worse and it will take much longer to switch apps if you force quit apps in the background. [...] In fact, apps frozen in the background on iOS unfreeze so quickly that I think it actually helps perpetuate the myth that you should force quit them: if you're worried that background apps are draining your battery and you see how quickly they load from the background, it's a reasonable assumption to believe that they never stopped running. But they do. They really do get frozen, the RAM they were using really does get reclaimed by the system, and they really do unfreeze and come back to life that quickly.
Or so they say
In practice, people who didn't know how to quit apps had shitty battery life... which stopped when they started closing apps.
Maybe newer iOS versions are better, however it has been very obvious through experimentation that closing apps helps performance.
Re-opening it takes more power than unpausing it from the background. Like, the difference between hibernating and rebooting your entire computer. Applications do a lot of work when they are booted from an initial state vs coming back from sleeping. I guess your argument is that they should be designed to boot from initial state as efficiently as possible. In general, that's going to be a goal of the developer, but it'll never be as efficient as coming back from a state when some of the work performed when starting the application is already done and cached somewhere.
This is not rocket science.
"Old man yells at systemd"
Modern app appers only APP APP apps, NOT LUDDITE force quit!
Apps!
You can turn this behavior off in the settings so it will not continue running and using GPS when not in the foreground. So check the settings and be free! :D
Tell me what you believe...I'll tell you what you should see.
This is the number one reason I force quite an apps. A bunch of location-using apps I use must be force-quit in order for them to stop using my location.
Go to Settings -> General -> Background App Refresh and disallow any applications which you don't want to let run in the background... which is probably most of them.
It's a bit irritating that, for most apps, running in the background is enabled by default. There are very few which really need to do that.
Oh, and you may need to occasionally do that again. I've seen all those toggles get re-enabled after certain updates.
#DeleteChrome
Because:
1. it needs to power a separate radio to receive the GPS signals.
2. GPS sends out almanac data (rough position information) and ephemeris data (orbital information)
3. Your device needs to calculate the tragetory and position, and lock on to 4 satellites (3 for psotion, 1 for time) using this data
4. You device then needs to calcutate the total time-delta, to the nanosecond, between the time each satellite sends a message, and when you receive it.
5. ** Using this time delta, you can calculate your exact distance to each satellite.
6. Solve three overlapping sphere equations to triangulate your position at the ground.
7. Solve another equations using 4 satellites to calculate the equivalent atomic clock time.
Your device is processing dozens of messages per second, to keep the locks on each GPS satellite, to switch active satellites as you move out of view of any given satellite, and to keep your calculated position, and delta position (speed) all in sync.
It's very computationally expensive, and thus takes power to operate the chipset doing all this work.
In addition, if you're in a city, without clear line-of-sight to enough satellites, it can boost the power and try to make sense of fainter data, or try harder to calculate which satellites are in theory overhead, and then to obtain a lock on each satellite and it's orbital trajectory and speed. Net result: GPS uses more battery in cities than in countryside.
Early iPhones didn't run apps in the background AT ALL. SO they definately couldn't waste power. When Apple introduced background processing it was under very tight constraints. Very limited things they could do. Any attempt to just keep running resulted in the app being terminated by the OS after a few seconds.
A few cheated by keeping themselves open in the background supposedly streaming audio when they weren't. But Apple jumped on that pretty quickly.
There's never bee a problem with background apps eating up batteries on iOS. Some people don't understand what's going on, and swear they see improvements be quitting background apps. But it's just a placebo effect.
The same basic advice has been peddled and widely ignored by end users who know better across all major mobile platforms. The reality is this is only true for apps don't take advantage of facilities to sidestep background execution restrictions.
Many app intentionally seek to run continuously in the background to enable persistent stalking and download ads as these activities yield profits for app vendors. It should go without saying facilities exist across all major platforms to accommodate.
https://developer.apple.com/li...
Utter bullshit. A GlobalTop FGPMMOPA6H standalone complete GPS module (as used in, e.g., the Adafruit Ultimate GPS breakout) draws 25 mA at 3.3 v during acquisition, and 20 mA at 3.3 v while tracking. And it does all those same things you list. "Very computationally expensive", my ass. All the analog and digital stuff is run off a single tiny MediaTek chip MT3339, which includes a radio and an ARM7EJ-S core. The processor clock runs at no more than 98 MHz.
If you have a 2000 mAh battery, it ought to run the entire GPS load, minus display mapping, for 100 hours. You shouldn't be able to detect any effect at all in "minutes".
The calculations aren't processor intensive, they're really quite easy. The battery drain is from the radio receivers, which are amped up to distinguish the really weak GPS signal from all the noise with the really small antennas built into the phone.