How Facebook Is Trying to Reduce iOS App Crashes

What is a FOOM, and how is Facebook trying to eliminate them from its flagship iOS application?

What is a FOOM, and how is Facebook trying to eliminate them from its flagship iOS application?

Software engineers Ali Ansari and Grzegorz Pstrucha described the social network’s efforts to reduce instances of OOMs, FOOMs and BOOMs—out-of-memory events, foreground OOMs and background OOMs—from the Facebook iOS app in an engineering blog post.

According to Ansari and Pstrucha, OOMs occur when iOS devices are running low on memory, causing iOS to shut down the app in order to reclaim memory and bringing users to devices’ home screens without warning.

The software engineers said they listed all of the known reasons why the app could terminate, starting with the question, “What can cause the app to start up?” This enabled them to figure out when OOMs occurred and break those OOMs down into FOOMs and BOOMs.

WhyIsTheAppStarting

They wrote:

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. 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).

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. 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.

ProcessMemoryUsage

While profiling for memory usage through Instruments, we also observed instances in the app usage where the app allocated a significant amount of memory (~30 megabits) temporarily and then deallocated shortly thereafter. If the CPU (central processing unit) was not idle during this allocation, there was a chance that the OS (operating system) could kill the app. We were able to get rid of these temporary allocations, which helped reduce OOM crashes for certain scenarios by up to 30 percent. We also experimented and discovered that allocating once and holding on to memory was better for app reliability, rather than having repeat allocations and deallocations.

For much more on the process, please see the blog post.

iOS users: Has your app crashed? If so, do you find that it is crashing less?

CrashBOOMFOOM