Social networking site rebuilt native code, reduced garbage collection, and moved photos to native heap

Facebook today announced an updated version of its Android app, which the company claims loads photos and opens up Timelines twice as fast as before, a critical upgrade for end-users who don't have extra seconds to spare waiting for the latest cute cat picture to load.

To the company's credit, it is letting developers in on some of the secrets behind the purportedly speedier app. Facebook engineer Frank Du, who works on the social network's Android team, provided a detailed breakdown of the techniques his group embraced to turbocharge the app.

For starters, Du said that his team rebuilt the native code for the app, moving from a hybrid native/Web view to pure native code. The purpose here was to support the "unique complexity" of the site's stories -- status updates, link shares, and images that pop up on the news feed and Timeline -- across devices.

Among the team's tactics, it reduced garbage collection to boost memory efficiency, which can have a significant impact on UI smoothness, according to Du: "Inefficient memory usage will result in many garbage collection events, which in turn can pause the application for multiple frames and cause visible stutter during scrolling."

The team worked to minimize, eliminate, or defer allocations in performance-critical code, he said. The app also postpones performing allocation-heavy code, such as feed-story parsing, until scrolling stops.

Second, the team wrote a custom lightweight event bus. Common event buses can slow performance and suck up memory as it works to get disparate classes to communicate with one another, according to Du. This one "avoids all reflection and object iterators so it can be registered and unregistered during performance-critical areas of code, such as during scrolling," he explained.

Third, the team took a different approach to loading photos, which can be a memory-intensive operation. "The standard method of allocating them directly on the Java heap can result in significant GCs and out-of-memory errors," he wrote. "We moved our bitmaps to be loaded on the native heap using the inPurgeable flag in the BitmapFactory class."

That native-heap approach means photos can be allocated in native memory instead of in the Java heap or in external memory, "which in turn significantly reduced their impact on our allocations and thus performance."

Finally, Du said Android's native view-recycling support in ListView is inefficient when it comes to list elements with varying row heights, such as in news feed stories. "We wrote a custom view recycler, which detached heavy content views once they were added to the recycling heap," he explained. "We also recycled substories in more complicated aggregated feed stories."