Multitasking and Memory Management in iOS
Many people are concerned about whether their available memory is 350MB or 380MB, and they rack their brains to optimize for a little more available memory. The task management and memory management of iOS differs greatly from Windows. Many people habitually use the Windows mindset when looking at iOS.
In Windows, the more windows that are open, the slower the system becomes. Why? Because all windows are running, consuming CPU resources; and they all occupy memory. Insufficient available memory can force the system to use the hard drive as virtual memory, frequent hard disk read/write operations will consume more power, and the speed of the hard disk is also relatively slow.
iOS is different. First, except for a few that can run in the background (such as music playback), most background tasks in iOS are suspended. For example, Need for Speed, when switched to the background, the engine roar disappears, and after switching back, you need to press "Continue" to start running again. Letting this kind of software continue to run in the background would only increase power consumption without any significance. You wouldn't want the car in Need for Speed to continue crashing around when it's switched to the background, right?
Since the software is suspended in the background, it naturally does not consume CPU, thus not wasting electricity.
When software is suspended in the background, it doesn't consume CPU, but does it still occupy memory? Does occupying more memory consume more power? Does it slow down the system?
The answer remains: no.
iOS does not prepare virtual memory for IPA. If the foreground software runs out of memory, iOS will directly release the memory occupied by the background software, unlike Windows which uses hard disk virtual memory (causing increased power consumption). Releasing a block of memory is simple, just change the flag of the memory block from "occupied" to "free", the content of the memory is directly discarded, no need to swap to flash memory, very fast.
It is clear that our experience with Windows does not apply to iOS.
There are also considerations for which background software's memory should be released. Some background software, if released, could have serious consequences, such as game software. After being released, the software ends, and switching back is like starting over, losing game progress.
Some software, however, is inconsequential. For example, e-book software, after releasing retained memory, the software can only retain a bookmark, switch back to reload content, and continue reading. For example, Safari browser, after its occupied memory is released, switching back simply reloads the page, causing no serious consequences.
iOS prioritizes releasing those background software that are not sensitive to memory.
For software that has already been switched to the background, neither consuming CPU nor having its memory released, in fact, the software has ended. Such background software is even less likely to consume power. Most of the background task lists seen by double-clicking HOME are this kind of software.
After saying so much, it means: iOS can arbitrarily open software without deliberately ending it.
In fact, iOS software doesn't even have an exit function, leading some people to complain, why isn't Apple's iOS design user-friendly? To exit a software, you need to double-click HOME, then long-press the icon below, the icon shakes, then press the cross, very troublesome. In fact, knowing what was said before, iOS software doesn't need to be exited at all.
In fact, the purpose of Apple's iOS multitasking design is to let you forget the existence of multitasking, using multitasking like single-tasking in IOS 3.x. Run whichever software you want, and don't want to run, just press HOME. No matter how many software are opened in the background, they won't slow down the foreground software (after all, the background is suspended state not occupying CPU). This is unimaginable for Windows, but Apple has indeed achieved it.
It's not that Windows is incapable, but because Windows is used for work, requiring comprehensive multitasking, while iOS is just a mobile operating system, with different priorities.
---
Some people question whether the power consumption is the same when iOS memory is idle or fully loaded, believing that idle memory saves power and full load consumes more power.
This view is incorrect.
Idle and full load refer to the operating system. But for memory chip circuits, what is seen is just 0 and 1. Even idle memory units contain 0 and 1 inside, they must faithfully preserve all data. iPhone4 has 512MB of memory, as soon as it is turned on, the chip must continuously preserve power to save 512MB of data. It is impossible for the operating system to cut off power to those idle memory units to save power.
Take a computer as an example, you have two sticks of memory, once turned on, both sticks of memory must be fully powered. It won't cut off power to one stick of memory because there is a lot of idle memory, and then re-power it when the system needs more memory space.
Believing that full load increases power consumption is still the habitual thinking of Windows. Again, in the Windows system, when memory is fully loaded, the system will use the hard drive as virtual memory, thus increasing power consumption and slowing down speed; iOS does not use the hard drive as virtual memory, but directly releases part of the memory occupied by background software until there is enough memory to allocate.
Therefore, whether the memory is idle or fully loaded, the power consumption for iOS is the same. Since the memory is directly released without needing to be saved to the hard drive (which is different from Windows), the speed difference between idle and fully loaded memory for iOS is also non-existent.
---
Some people base their argument on whether turning on background processes significantly affects power consumption.
Regarding this point, I will say again:
On forums, some people close all background processes, turn off notifications, even turn on airplane mode, and still lose less than 10% of battery overnight. Others who know nothing and do nothing, fools have good fortune, and still maintain 100% battery overnight on January 5, 2012.
Power consumption varies from person to person and cannot be generalized.
As for myself, only opening 2G signal standby, with notifications on, intentionally leaving a few large games running in the background, I lost 1% overnight.
In fact, when you switch back to the background game, it will all be paused, all needing to tap the screen's Resume to continue, which proves: the game is paused in the background. A completely paused background task, if it still consumes power doing useless work, you underestimate the system designers at Apple.
For example, in the game Plants vs Zombies, when switching to the background and then back, you see the words "Game Paused"? The game is completely paused in the background. Only after you press resume does it continue. All native-supported games are like this.
The advantage of this multitasking management mechanism is that it does not slow down system performance, opening many things remains very smooth. The disadvantage is that QQ cannot truly run in the background (so there is push notification), download tasks will pause, etc. However, there is powerful background software like Backgrounder on iPhones. I'm not sure if there is similar software on WP7. Actually, once you get used to WP7 or iPhone, you realize you don't really need true background. QQ push notifications done well actually work the same way. Software just needs to support Mango background, and when you switch away, it pauses, and when you switch back, it continues.
WP7 limits the background to 5 apps because with 256MB system memory, the upper limit of usable memory per app is 90MB. Currently, devices have 512MB memory, with each app having 90+256MB of usable memory, roughly allowing 4 apps to run simultaneously. Considering that general apps do not always use up 90MB of memory, running 5 apps simultaneously is a reasonable number.
What is meant by "no impact" is generally speaking. The principle is that when new apps request insufficient memory, previous programs are automatically cleared. Although automatic clearing is a system judgment process, sometimes it can be felt, especially when opening a large app, it may crash, then re-entering works fine.
Push notifications can be understood as text messages sent by your carrier, theoretically instant.
A representative example is the built-in Messenger in WP7, integrated into SMS, which can stay online 24 hours without changing power consumption. Whether standby time is two days or not, as long as you don't select offline, other WP7 users' Messenger contacts see you as online 24 hours, and any message sent to you is received instantly like SMS.
Push notifications themselves are not about software on the phone constantly refreshing data, such as every 30 seconds, one minute, or two minutes. That method would drain the battery too quickly and cause delays.
The Messenger in WP7 stays online 24 hours without any noticeable power consumption, maintaining two days of standby.
Push notifications should theoretically be instant, but definitely not as instant as socket long connections due to more delay-prone links.
QQ's push notifications, the first delay link is the server's processing of messages itself. TX uses Microsoft's push service, so TX's server must connect to Microsoft's server, potentially causing delays, and finally, Microsoft pushes the message, and the phone obtains the message via network connection...
Anyway, there are many potential delay links in push notifications. Sockets, on the other hand, directly connect to TX servers, like earlier versions of QQ where push notifications were erratic, but newer versions are better because TX has improved its own responsible links.
Messenger is Microsoft's own product, with fewer uncontrollable links, and better delay control.
Like certain foreign software that can achieve stable push notifications, Microsoft's own Messenger goes without saying, and QQ still needs improvement, solving network latency issues, like how we access live services being extremely slow, and the store acting erratically. So, without Microsoft setting up servers domestically, there are more uncontrollable factors in push notifications.
Actually, apart from BlackBerry's push notifications and Find My Phone functions, others are not real-time push notifications. They still use pseudo-long connections or timed data retrieval, including iPhone, WP, and Android.
BlackBerry has a specific SMS-like sending protocol with carriers, requiring carrier system support. Others are actually client-initiated polling. However, due to unified Push servers, the number of connections is reduced, thus achieving power savings. Each device has a specific device ID and certificate, used to authenticate identity when retrieving data from the push server.
(Note: RAM preserving data consumes power. Each bit of RAM kept as "1" requires continuous charging of the circuit gap, otherwise circuit leakage would lower the voltage.)
Just remember one thing, too many cars on the road create traffic jams! If the two-lane road is allocated and scheduled well, it's fine; no need for eight lanes...
Theoretically, memory is always powered, with constant voltage, so data exchange does not increase supposed power consumption. Unlike hard drives, where power consumption differs between seeking and not seeking. Similarly, CPU changes frequency based on computational load, resulting in varying power consumption. However, it's important to understand that programs occupy memory to execute parts of data. The primary function of memory is pre-caching, enabling direct and rapid data exchange. Fundamentally, software opening still reads data stored on the data card or flash chips, equivalent to being in the seeking phase, and the CPU must allocate part of its resources to preprocess these.
No matter what background mechanism, as long as there is background operation, it will certainly consume resources. The system and hardware work together, meaning optimization is key. If scheduling is efficient, the same two-lane road can handle ten vehicles within the same time frame; if not, it might only handle five. Ultimately, the system integrates, allocates, schedules, and executes hardware resources efficiently.
The multitasking mechanism of Windows is designed for comprehensive work. The system architecture and design philosophy differ fundamentally. Compatibility refers more to various aspects of hardware, meaning software can run on more complex hardware systems and simultaneously run more software without conflicts, achieving balanced efficiency. Those familiar with the system architecture of macOS know that it targets specific hardware. Therefore, macOS can only compare with Windows. iOS can only compare with WM and WP7. iOS is fundamentally different from previous versions of WM, and comparing it with Windows makes no sense. Personally, I believe there are differences in the background mechanisms of iOS and WP7, and in some ways, WP7 may be more efficient. iOS essentially labels the entire program in the background as terminated, so it can quickly terminate and release resources upon reaching the threshold. But this termination is somewhat slippery, like deleting a file but putting it in the recycle bin, ready for restoration if needed, manually confirming recovery from the recycle bin. Files in the recycle bin obviously occupy space, i.e., resources.
WP7, on the other hand, is more like stopping a running task, taking necessary data snapshots, logically deleting them, but physically keeping the data intact on the disk unless overwritten. At this point, the program’s required processes and resources have been released during the background transition. This is what I understand as the tombstone mechanism—digging a hole, burying, filling, but leaving a tombstone to mark details. Resources aren’t wasted for programs that are naturally dead, but if needed, the original information can be cloned and restored. The sole concern is the efficiency of resurrection and ensuring data correctness through verification.
Some friends might think this seems more trouble and resource-intensive, but those familiar with disk storage principles or detailed RAID applications should easily understand. Data is just a bunch of 0s and 1s, and RAID1 or 5 adds marking and verification information during read/write and modification. When disks are damaged, data is fully recovered according to these marks. However, it’s crucial to note that the original data package of the program, i.e., the data files after installation, hasn’t been deleted, so complete recording or restoration isn’t necessary. Only necessary data generated and associated during runtime is recorded, so restoration doesn’t require drastic measures. QQ under iOS maintains constant network connection legitimacy, naturally prioritizing over system termination thresholds, thus staying in the background smoothly. Therefore, for programs like QQ that constantly refresh memory data and modify disk data, WP7 shows less tolerance. Under WP7, except for Microsoft-approved programs allowed in the background, once you go to the background, you're packed and buried regardless of needs or priorities. Microsoft’s restriction of allowing five background programs is probably for convenience... Microsoft-designated backend interfaces, if compromised in the future, could allow software to falsely claim privileged background status.
The tombstone mechanism is a program execution rule in Microsoft's Windows Phone 7 mobile operating system. Simply put, when a task on the phone is forcibly interrupted (such as an incoming call), the system records the current application state (like inscribing events on a tombstone) and then terminates the program. When resuming, the system restarts the application process and restores the state data according to the "tombstone" content, restoring the program to its pre-interruption state. This mechanism is called the "tombstone mechanism."
Specific Manifestations of the Tombstone Mechanism
Microsoft recently released the new Windows Phone 7 mobile operating system, but confusingly, WP7 does not support multitasking. It turns out that WP7 isn't strictly single-tasked; for example, Microsoft's own IE and ZUNE can run simultaneously in WP7.
First, let's discuss some basic rules for WP7 system program execution. Microsoft does not allow any third-party applications to run in the background in WP7. Within a specific time, only one application runs in the foreground. If your application is not displayed in the foreground, it indicates these programs are not running, thus not consuming operational memory and processor resources. This is mainly done to extend battery life and ensure a consistently responsive user experience.
However, all WP7 phones come equipped with a return button hardware. Besides returning navigation functionality, this button also supports switching between applications. For instance, when you click a webpage link inside an application and invoke the built-in browser to view it, after viewing, you can press the return key to go back to the previous application.
Now the question arises: when switching from the current application back to the previous one, is it restoring an application or reopening it? As previously mentioned, WP7 does not allow background-running programs. The difference lies in whether reopening retains the previous usage state or not. Restoration can continue the usage state, whereas reopening cannot. Here comes Microsoft's tombstone (Tombstone) mechanism.
The tombstone is a handling mechanism Microsoft created for WP7 to switch application states. Taking the usage process as an example, when a user is using an application, such as a game or news reader, and a call comes in, the incoming call prompt and conversation page will appear in the foreground. The running game will disappear, but WP7 does not allow background-running applications. At this point, the tombstone mechanism triggers, freezing and saving the game's running state, including visuals and progress, akin to pausing. However, the game is not actually running, hence the name "tombstone": the application is dead, but the tombstone records all its final states. After the call ends, the operating system will restart the application process and restore the state data according to the record on the tombstone, equivalent to the application crawling out of the graveyard and restoring according to the recorded state.
In code examples, Microsoft provides four App.xaml.cs files related to the execution modes: Application_Launching, Application_Activated, Application_Deactivated, Application_Closing, corresponding to startup, resurrection (activating the program to restore its state), deactivation (recording tombstone data), and closing (complete closure). Developers need to use Microsoft-provided tools and relevant codes during development to make their applications support the tombstone mechanism; otherwise, when a user is using the application and a call comes in, they would need to manually reopen the program from scratch, which would frustrate users.
In early versions of WP7, Microsoft did not completely kill processes when applications were inactive but paused them instead. This caused confusion in the background operation stack, with frequent API and event trigger issues. Thus, Microsoft decided to implement the tombstone mechanism.
However, fully implementing the tombstone mechanism affects certain telephone functionalities, such as SMS, instant messaging, weather updates, which need to remain operational and updated. Microsoft provided Push Notification Services APIs to allow applications to maintain real-time updates.
---