How Facebook Cut Down the Crashes in Its iOS App

By Darryl K. Taft  |  Posted 2015-08-25 Print this article Print
Facebook logo

Thus the team tried a number of optimizations, such as cleaning up the cache and clearing the content, but the memory footprint of the app's process was always significantly increased after navigating to a Web view, the team said.

However, iOS 8 introduced a new class — WKWebView — that performs most of its work in a separate process, which means that most Web-view-related memory usage would not be attributed to the Facebook app’s process. In a low-memory event, the Web view's process could be killed and their app would be more likely to stay alive, the post said. “After we migrated our app to WKWebView, we did indeed see a significant reduction of OOMs in our app,” the engineers said in the post.

Yet, even after migrating to WKWebView, the team still found that a small memory leak could affect the OOM rate significantly, especially on the more memory-constrained devices. With the company’s frequent release schedule and many teams contributing to the app, Facebook knew it was important to both catch and prevent memory leaks in the apps they release. So the company used its CT-Scan infrastructure -- originally designed to test for mobile performance -- to log the amount of resident memory in the process, allowing CT-Scan to flag regressions as soon as they were introduced. This has helped to keep the OOM rate much lower than when the team first started working on it.

However, the last key tactic the team used was to construct an in-app memory profiler, to allow profiling the app quickly by tracking all Objective-C object allocations. The team configured this in CT-Scan and in the internal builds of their app.

“Here's how it works: For each class in the system, it keeps a running count of how many instances are currently alive,” the post said. “We can query it at any point and log the current number of objects for each class. We can then analyze this data for any abnormalities release-to-release to identify changes in the overall allocation patterns of our app, usually helping identify leaks when any count shifts drastically. We managed to implement this in a way that is performant enough that it doesn't produce any noticeable impact in application performance to the user.”

After the company rolled out the changes to resolve memory issues in the Facebook iOS app, the team saw a significant decrease in (F)OOMs and in the number of user reports of the app crashing.

“OOM crashes were a blind spot for us because there is no formal system or API for observing the events and their frequency,” the post said. “No one likes it when an app suddenly closes.”



Submit a Comment

Loading Comments...
Manage your Newsletters: Login   Register My Newsletters

Rocket Fuel