Boost Android Cold Start: Lessons from Redex and Interdex Optimization

Introduction

In October last year Facebook announced Redex, a tool that can process APKs to improve startup performance and reduce package size. Redex was finally open‑sourced in April, and we investigated it, discovering many useful ideas for cold‑start optimization (excluding Android 5.0+ systems).

1. Using Redex and Its Pitfalls

1. Installation and Usage

Redex does not support Windows, so we had to run it in an Ubuntu VM and install numerous dependencies as described in the official GitHub guide.

2. Optimization Principles and Configuration

Redex offers many optimizations that can be enabled via its configuration file. The default configuration includes:

A. Inlining – removes intermediate method calls. Example: func1 -> static func2 -> static func3 After inlining: func1 -> static func3 This reduces call overhead and bytecode size. Similar optimizations apply to object references.

B. Removing dead code and empty classes

C. Replacing single‑implementation interfaces or super‑classes with the concrete class

D. SynthPass – eliminates synthetic accessor methods generated for private static members, effectively making them public.

E. String shrinking – provides ProGuard‑like obfuscation and DEX metadata optimization, reducing APK size.

F. Interdex – reorders classes in the DEX according to a startup class sequence, improving cold‑start time by about 30% according to Facebook’s data.

3. Pitfalls Encountered in Practice

Despite the many optimizations, several bugs and issues reduced the cost‑effectiveness of Redex:

A. IllegalAccessError – caused by inlining that changes method visibility, leading to runtime exceptions.

Func1 -> public static func2 -> private static func3

After optimization it becomes: Func1 -> private static func3 Resulting in inaccessible private methods.

B. NoClassDefError – an unexplained runtime error where the class exists in the DEX but cannot be loaded.

C. NoSuchMethodError – occurs when Redex removes methods that plugins later reference.

D. Interdex side effects – reordering can disrupt multi‑DEX layouts and patch injection logic.

E. Signing – after Redex processing the APK must be re‑signed, which may conflict with existing signing steps.

By disabling problematic optimizations, we could still achieve modest APK size reduction (~100 KB) and limited startup gains, but the effort to integrate Redex into a large project was substantial.

2. Interdex for Cold‑Start Optimization

Implementing Interdex ourselves is feasible because it only requires reordering classes in the main DEX without full dependency analysis.

1. How to Implement Interdex

We need to solve three problems: obtaining the class load sequence at startup, placing those classes into the main DEX, and adjusting the class order.

A. Obtaining the startup class sequence – we hook ClassLoader.findClass to log class names during loading, then extract the sequence from the logs.

B. Placing classes into the main DEX – modify the existing multi‑DEX packaging logic to ensure required classes are compiled into the primary DEX.

C. Adjusting class order – replace the standard dx.jar with a custom version that overrides the orderItems method to sort classes according to the startup sequence.

Understanding the DEX file format is essential; the classDef section holds class definitions, and reordering can be achieved by editing this section.

2. Optimization Results

After implementing Interdex, the startup time of the actLoginA flow decreased by roughly 30% in local debug builds. However, the same changes did not affect release builds built with RDM.

3. Why Release Builds Did Not Benefit

Release builds apply code obfuscation, which changes class names, breaking the class‑sequence mapping. Updating the mapping after ProGuard resolved this but still showed no improvement.

Other investigated factors (ZipAlign, class order changes) were ruled out. The decisive factor was hot‑patch instrumentation: the release build’s classloader patching added instrumentation that prevented classes from being pre‑verified, nullifying Interdex gains. Removing this instrumentation restored the expected speedup.

4. Underlying Optimization Principle

Interdex works by moving frequently loaded startup classes into the main DEX, increasing the likelihood that they satisfy pre‑verification conditions, which reduces first‑load overhead. Instrumentation that disables pre‑verification negates this benefit.

3. Summary

Interdex can noticeably improve cold‑start performance by co‑locating related classes and enabling pre‑verification, but it conflicts with classloader‑based hot‑patch solutions.

Redex remains a powerful tool with many optimizations; it is easier to adopt in small apps than large projects, yet it offers valuable ideas.

Practical experimentation is essential—some optimizations (e.g., class order) may have limited impact, while understanding DEX structure and custom dx tooling can be broadly useful.