Facebook Optimizes Android Bytecode

Facebook Redex

Facebook Optimizes on the byecode level with their Redex code

In order to improve the mobile performance of its social network, Facebook, exert more focus on their Redex project in order to optimize the applications DEX file. Dex stands for Dalvik Executable.

Facebook engineers Marty Greenia, Bert Maher, and Shane Ney emphasized a responsibility to “keep things fast, particularly in developing areas where devices stay in the market longer.”

At the beginning of our optimization project, we decided that the best place to do our optimizations was after the .dex files were created and before assembling the .dex files into an APK. The advantage of doing our optimizations at the bytecode level (as opposed to, say, on the source code directly) is that it gives us the maximum ability to do global, interclass optimizations across the entire binary, rather than just doing local class-level optimizations. We opted to perform the transform on dex bytecodes rather than Java bytecodes because certain transforms can only be done post-DXing. This would be analogous to the post-linking stage in a C-style compilation process, where you can make global optimizations across your entire binary.

We realized that engineers would likely continue to come up with new and creative bytecode optimizations over time. Facebook engineers tend to move fast, so we wanted to architect something that would benefit from multiple engineers working on lots of optimizations. We organized our optimization pipeline as a series of stages, with the “original” .dex entering at the beginning of the pipeline and the “transformed” .dex exiting at the end. Each stage in the pipeline can be thought of as a stand-alone “optimization plugin” that snaps into place behind the previous stage, allowing us to chain multiple different, potentially unrelated transforms behind one another. This makes it really flexible from an engineering perspective, as multiple engineers can experiment with different optimizations in parallel and then plug them into the final pipeline only when they are ready.


This means that the Redex project will take the compiled dex files and reoptimize it further on the byte level before they are included in the application’s APK file. Some pipelining was also introduced that enhances segments of the application’s code.

The optimization includes minimizing the java codes making “this-is-an-awesome-function()” into “a()” which removes human readability. Compilers on the other hand does not care if the function names, variables and other like items become useless to the human eye. They aim to reduce JavaScript’s sizes using this approach.

String are also minified on the final APK file. Minification is the process of removing whitespaces making the code extremely hard to read. The new enhancement also added a feature to remove dead codes on the fly.

This approaches may render the APK file faster to load and smaller but it will be a nightmare running debug with the current minifications


The TechnoJunkie of the group who studied engineering but got stuck with software development. Remember kids, 90% of your problems can be solved by marketing. Solving the other 10% just requires good procrastination skills.

You may also like...

1 Response

  1. October 16, 2015

    […] Other issues encountered are missing friend feeds, photos that won’t appear, blank contact photo, frozen app, WSD (White screen of Death) and a lot more. There was no official explanation on what the real cause of this problems but it may be in connection with the breaches and bugs that caused Facebook to crash last month or perhaps it was in connection with their ReDex Project. […]

Leave a Reply

%d bloggers like this: