Facebook is one of the world’s largest social networks and is known within the industry as being driven to improve the performance and efficiency of applications and services. In short, if there’s a way to do something faster and better for its 1.5 billion users around the world, Facebook wants to be in on the action. On the Android platform, this drive has certainly been welcome and very much needed: the Facebook application has been greatly improved over the years. It is still large and at times sluggish, but compared to the application a couple of years ago it is much improved. Facebook use a hybrid of a local and cloud based system for the Android application: they are able to effect changes to how things work without changing the application, providing we are running a compatible version. Facebook is also keenly aware that if an application is sluggish and unresponsive, users quickly tire: nobody wants to stare at a spinning logo as they wait for an application update.
Today’s story concerns one of Facebook’s internal projects, called ReDex, which has been released as an open source project. ReDex is designed to optimise Android application’s bytecode, that is, a compiled part of the application designed to talk to the underlying operating system. This may spring to mind the idea of a standalone desktop application or perhaps a cloud service whereby a developer feeds into the system their standalone application and it spits out a leaner, faster version. However, this is now how the ReDex system works. Instead, the developer adds the code to his or her application and it recompiles things on the fly. This means that there is very little work needed in order to use the ReDex system. According to Facebook software engineer Bery Maher: “It transforms bytecode magically into better bytecode.”
Facebook’s statistics are telling. Bert explained that the cold start Facebook application performance is improved by 15% on 2015 Android devices. This is increased to 25% for Android devices from 2011. Facebook also state that the application is some 25% more responsive. Unfortunately, Facebook do not disclose the hardware and software that they used for these comparisons: in 2011, many Android devices used a single core application processor although there were some that used a dual core chip. In 2015, the majority of devices used at least a quad-core application processor and many of these were 64-bit chips. Nevertheless, we may suppose that ReDex works proportionally better on older, slower hardware running older, obsolete versions of Android compared with modern devices: this is good news as it’s arguably these devices that will benefit the most from application optimisation.
One reason for the relative difference in application performance may be that older versions of Android used a different way of dealing with applications. Google switched from the Dalvik runtime to the Android runtime with the release of Android 5.0 Lollipop (although the Android runtime was available for some devices running Android 4.4 Kit Kat). The Android runtime pre-compiles applications upon installation in order to improve performance whereas the Dalvik system compiles applications upon first launch. It may be that an application injected with the ReDex is better able to optimise itself when used on an older operating system because Google’s newer Android runtime is more efficient. It is also possible that the ReDex system is better able to use multiple application processor cores to distribute the load and so reduce the time it takes to launch an application. Why would Facebook wish to become the fairy Godmother to developers and wave that magic wand to optimise applications? It improves their visibility to developers and could attract talent to the business. As the ReDex system is being released as open source, developers may learn from how the system works and this ultimately should be good for the whole ecosystem.