Multitasking and Memory Management in iOS
Many people fret over whether their available memory is 350MB or 380MB, going to great lengths to optimize and free up every bit of available memory. However, iOS's task management and memory management differ significantly from Windows. Many people tend to view iOS through the lens of Windows.
In Windows, the more windows you open, the slower the system becomes. Why? Because all windows are actively running, consuming CPU resources and occupying memory. When available memory runs low, the system may resort to using the hard drive as virtual memory, causing frequent disk reads/writes which not only consume more power but also slow down performance due to the relatively slow speed of hard drives.
iOS operates differently. Except for a few specific tasks that can run in the background (like music playback), most apps are suspended when moved to the background. For example, in games like Need for Speed, the engine roar stops when the app is switched to the background, and you need to tap "Resume" to continue playing when switching back. Running such apps in the background would only waste battery life without any meaningful benefit. You wouldn't want your race car to keep crashing around while the app is in the background, would you?
Since these apps are suspended in the background, they do not consume CPU resources and therefore do not drain the battery.
Even though suspended apps occupy memory, this does not lead to increased power consumption or system slowdown.
iOS does not provide virtual memory for IPA files. If the foreground app requires more memory, iOS will directly release the memory used by background apps instead of using the hard drive as virtual memory (which would increase power consumption). Releasing memory simply involves changing the status of a memory block from "occupied" to "free", discarding the contents without needing to swap them to flash storage, making the process very fast.
Thus, our experiences with Windows do not apply to iOS.
When deciding which background app's memory to release, there are considerations. Some background apps, if released, could have serious consequences. For instance, game apps, if terminated, would lose progress when switched back to. Other apps, like e-book readers, can simply reload content and continue where they left off after releasing memory, or web browsers can reload pages without significant impact.
iOS prioritizes releasing memory from apps that are less sensitive to memory usage.
For apps that are already in the background, neither consuming CPU nor occupying memory, they are essentially terminated and cannot consume power. Most of the apps visible in the double-tap HOME multitasking list fall into this category.
In conclusion, iOS allows users to freely open apps without deliberately ending them. In fact, iOS apps don't even have an explicit exit function, leading some to complain about the lack of user-friendliness in Apple's design. To close an app, one must double-tap HOME, long-press the app icon until it wiggles, then press the X – a cumbersome process. However, as explained earlier, iOS apps do not need to be manually exited.
Apple's design for multitasking in iOS aims to make users forget about multitasking altogether, allowing them to use multiple apps seamlessly as if they were using a single-tasking system like iOS 3.x. Users can run whichever app they desire, and pressing HOME will pause it without affecting the performance of other apps (since background apps are suspended and do not consume CPU). This level of efficiency is unimaginable in Windows, yet Apple has achieved it.
It’s not that Windows lacks capability, but rather its focus is on providing comprehensive multitasking for productivity purposes, whereas iOS is a mobile operating system with different priorities.
---
Some people question why iOS consumes the same amount of power whether its memory is fully loaded or empty, believing that an empty memory saves power while a full memory consumes more.
This perception is incorrect.
The concept of "empty" and "full" applies to the operating system, but for the memory chip circuitry, it only sees 0s and 1s. Even idle memory units contain 0s and 1s that must be faithfully preserved. An iPhone 4 with 512MB of memory requires constant power to maintain this data from the moment it is turned on. The operating system cannot selectively cut power to idle memory units to save energy.
Consider a computer with two sticks of RAM; both sticks must be powered on at startup. The motherboard does not selectively power off one stick of RAM because there is unused memory, nor does it re-power it when more memory is needed.
The belief that a full memory increases power consumption stems from Windows thinking. In Windows, when memory is full, the system uses the hard drive as virtual memory, increasing power consumption and slowing down performance. In contrast, iOS releases memory occupied by certain background apps until sufficient memory is available, without resorting to virtual memory on the hard drive.
Therefore, whether memory is fully loaded or empty, there is no difference in power consumption for iOS. Since memory release involves direct discard without saving to the hard drive (unlike Windows), there is also no difference in speed between full and empty memory states.
---
Some argue that turning off background apps significantly affects power consumption.
Regarding this point:
On forums, some users report that despite closing all background apps, notifications, and even enabling airplane mode, their device still loses less than 10% charge overnight. Others, who do nothing to manage their settings, experience no battery loss overnight, maintaining 100% charge.
Battery consumption varies from person to person and cannot be generalized.
Personally, with only 2G signal enabled, notifications on, and a few large games left in the background, I lose 1% charge overnight.
In reality, when you switch back to a background game, it will be in a paused state, requiring you to tap "Resume" to continue. This clearly shows that the game is paused in the background. It would be illogical for a completely paused background task to continue consuming power unnecessarily.
For example, in the game Plants vs Zombies, the screen displays "Game Paused" when switching back from the background. The game remains paused until you tap "Resume". All natively supported games operate this way.
The advantage of this multitasking management mechanism is that it does not slow down system performance, allowing smooth operation even with many apps open. The downside includes QQ not truly running in the background (hence the need for push notifications) and download tasks pausing. However, powerful background software like Backgrounder exists on iPhones. Whether similar software exists on WP7 remains unclear.
Once users become accustomed to WP7 or iPhones, they realize that true background operation isn't always necessary. Properly implemented QQ push notifications work just as well. As long as apps support Mango's background functionality, they can pause when switched away and resume upon returning.
WP7 limits five background apps due to a 256MB system memory limit per application, with current devices having 512MB memory, allowing roughly four applications to run simultaneously. Considering that apps rarely use the full 90MB, five simultaneous apps is a reasonable number.
While theoretically unaffected, the system automatically clears memory requested by new apps, a process involving automatic judgment.
In practice, sometimes this can be noticeable, especially when opening a large app, resulting in a crash before reopening successfully.
Push notifications can be understood as text messages sent by the carrier, theoretically instantaneous.
A representative example is WP7's built-in Messenger, integrated into SMS, which can remain online 24/7 without noticeable battery impact, maintaining a two-day standby time. Regardless of network conditions, WP7 Messenger contacts see you as always online, receiving instant messages at any time.
Push notifications are not based on continuous data refreshes on the phone, such as every 30 seconds, 1 minute, or 2 minutes. Such methods drain the battery and cause significant delays.
WP7's Messenger remains online 24/7 with no noticeable battery impact, maintaining a two-day standby time.
Push notifications are theoretically instantaneous but not as immediate as socket long connections due to various delay-inducing factors.
QQ's push notification process involves multiple potential delay points: Tencent server message processing, connecting to Microsoft servers, and finally Microsoft pushing the message, with the phone obtaining it via network connection.
Although push notifications may involve delays, socket connections directly link to Tencent servers, reducing issues present in earlier QQ versions. Improved handling of these factors enhances the newer version's performance.
Messenger is a Microsoft product with fewer uncontrollable factors, better controlling delays.
Certain foreign software achieves stable push notifications, with Microsoft's own Messenger excelling. QQ needs improvement in addressing network delay issues, much like accessing live services being slow or stores experiencing glitches. Without domestic servers from Microsoft, there are more uncontrollable factors affecting push notifications.
In fact, aside from BlackBerry's true push notifications and Find My Phone features, others rely on pseudo-long connections or timed data retrieval, including iPhone, WP, and Android.
BlackBerry has a specific SMS-like sending protocol with operator support, whereas others involve client-side polling. Unified Push servers reduce connection numbers, conserving power. Each device has a unique ID and certificate for data verification.
(Note: RAM consumes power to preserve data. Each RAM bit set to "1" requires continuous circuit charging to prevent leakage.)
Simply remember: too many cars congest roads! Properly managed dual lanes suffice; eight lanes aren't necessary.
Theoretically, memory voltage remains constant, so data exchange doesn't increase power consumption. Unlike hard drives, which consume more power during seek operations, CPU frequency changes according to computational load, affecting power consumption.
Programs use memory to execute data, with memory primarily functioning as a pre-cache for quick data exchange. Fundamentally, software must read data stored on data cards or flash chips, akin to seek operations, with the CPU allocating resources for preprocessing.
Regardless of background processes, original data exists at the lower level, continuously issuing I/O requests. The system arranges I/O priority according to predefined logic rules. The CPU schedules resources based on logical commands for execution and computation.
With background processes, I/O requests aren't entirely rejected but allocated resources based on priority, delaying or postponing processing. This inevitably consumes some resources, varying according to system architecture and internal logic instructions.
Regardless of the backend mechanism, as long as background processes exist, they will consume resources. System and hardware optimization equates to efficient scheduling, allowing the same two-lane road to handle ten cars versus five under poor scheduling. Ultimately, the system manages hardware resource integration, distribution, scheduling, and execution efficiency.
Windows' multitasking mechanism is designed for comprehensive work, differing fundamentally in system architecture and design philosophy. Compatibility refers more to hardware aspects, ensuring software runs on more complex hardware simultaneously without conflict and with balanced efficiency.
macOS architecture should be familiar to most, along with previous Mac CPU architectures. Specific systems target specific hardware, forming a one-to-one relationship. Thus, macOS compares best to Windows, while iOS compares to WM and WP7. iOS differs fundamentally from WM and is incomparable to Windows.
Fundamentally, iOS's backend mechanism differs from WP7, potentially being less efficient. iOS marks entire programs in the background with termination tags, allowing quick termination and resource release upon reaching thresholds. This termination is somewhat superficial; iOS deletes files but retains them in the recycle bin, ready for restoration upon demand, though manual confirmation is required. Files in the recycle bin occupy space and resources.
In contrast, WP7 halts running tasks, creating snapshots of necessary data ("termination"). Steps include direct deletion and clearing of the recycle bin, with data remaining logically deleted on the hard drive until overwritten. At this point, program processes and resources are already released during backgrounding. This represents the tombstone mechanism.
Tombstones mark events, burying and flattening them while preserving resurrection details. Unnecessary programs naturally die without wasting resources. If necessary, original information can be cloned and restored. The primary concern is resurrection efficiency and data integrity verification.
Some might argue this method is more trouble and resource-intensive. Those familiar with disk storage principles or RAID configurations understand data as 0s and 1s, with RAID 1 or 5 adding checksums during read/write operations for complete data recovery during disk failure. Importantly, the program's original data package remains intact, avoiding complete recording or restoration. Only necessary runtime data modifications are recorded, simplifying recovery.
For example, QQ maintains network connection legitimacy under iOS, prioritizing system termination thresholds and moving to the background accordingly. Programs like QQ, which frequently update memory and disk data, find WP7 less accommodating. WP7 suspends all non-Microsoft-approved apps, regardless of necessity or priority. Microsoft's restriction of five allowed background apps likely serves convenience. Approved interfaces allow future software to bypass restrictions.
Microsoft's tombstone mechanism in Windows Phone 7 records application states upon interruption (e.g., incoming calls), pauses the program, and restores it to its previous state upon resumption.
Key tombstone-related codes in App.xaml.cs include Application_Launching, Application_Activated, Application_Deactivated, and Application_Closing, representing startup, resurrection, suspension, and closure. Developers must use Microsoft tools and code to support tombstone mechanisms, avoiding user frustration from losing progress due to interruptions.
Early WP7 versions did not terminate background processes but merely paused them, leading to stack confusion and API/event triggering issues. Thus, Microsoft adopted the tombstone mechanism.
However, implementing tombstone mechanisms affects certain phone functionalities, like SMS, instant messaging, and weather updates, which require constant operation and updates. Microsoft provides push notification service APIs to allow real-time updates for such applications.