Next, we dived into the memory profiler in Apple’s Instruments application and noticed a repeated pattern of UIWebView allocating a lot of memory once the application opened any web page. Profiling memory usageĪs we started fixing leaks, we saw some reduction in the OOM crash rate, but we still didn’t observe the significant reduction that we were hoping for. Unfortunately, we didn’t observe a real change in the number of OOM crashes, so we then shifted our focus to large allocations, starting with those that might be leaking (never cleaned up), especially via potential retain cycles. Our first effort to reduce the number of OOMs was to attempt to shrink the memory footprint of our app by proactively deallocating memory as quickly as we could, as soon as it was no longer needed. Seeing the correlation in our logging helped us verify our process-of-elimination approach and continue to improve the logging (we didn’t actually identify all cases at first, such as app upgrades). The logging showed that there was a higher rate of OOMs on devices with less memory, which was expected and reassuring since the application process was more likely to be evicted on a constrained-memory device. We also kept track of when the app backgrounded and foregrounded so that we could accurately break down OOMs into BOOMs and FOOMs, respectively. The app ran out of memory (an OOM) in the background or the foreground.īy process of elimination, looking for instances that didn’t fall into the other cases, we could then figure out when an OOM had occurred.The device restarted (which includes an OS upgrade).A user swiped up to force-exit the application.The app could need to start up for the following reasons: The actual question we looked into was “What can cause the application to start up?” To get a handle on how often our app was being terminated due to OOM crashes, we started by enumerating all the known paths through which the application could be terminated and then logging them. This leaves us with no easy way to know that the app was killed by the OS due to memory pressure. On iOS, the OS does its best to send a memory warning to the app, but there is no guarantee that one will always be received before the OS evicts the process from memory. If the rate of memory consumption increases drastically, the application can be killed without receiving any signal that memory is running out. In both cases, the app unexpectedly terminates, appearing to vanish, and the user is taken back to the home screen of the device. We refer to these internally as FOOMs and BOOMs, respectively - it’s just a bit more fun to say that the app went BOOM!įrom the user’s perspective, a foreground OOM crash (FOOM) is indistinguishable from a native crash. ![]() ![]() ![]() It can happen whether the app is in the foreground or the background. OOMs occur when the system runs low on memory and the OS kills the app to reclaim memory. We dug into the user reports and began to theorize that out-of-memory events (OOMs) might be happening. In the past, most of the crashes have been due to programmatic errors, and they always came with a stack trace that blamed the line in the code that caused the crash and always offered a hint as to what the issue might be.Īs we continued to fix crashes, we observed a drop in our measured crash rate but noticed in the App Store reviews that the community was continuing to surface frustration with the app crashing. We’ve worked hard to reduce the number of crashes in the Facebook iOS app and to increase its overall reliability. ![]() At Facebook we strive for our apps to be stable, fast, and reliable.
0 Comments
Leave a Reply. |