How Facebook Automates Android Performance Tracing with Bytecode Rewriting

Facebook constantly seeks to improve the runtime speed of its Android apps. Although it already uses an internal system similar to CTScan, the fragmentation of Android devices prevents exhaustive lab testing, so the company turned to telemetry collected from real users' devices.

Traditional telemetry relied on manual instrumentation: developers inserted start and end markers around operations such as a feed refresh. This approach suffers from limited granularity, difficulty handling asynchronous code, and high maintenance overhead as the codebase evolves.

The team evaluated two alternatives—Android’s built‑in Debug‑based method tracing (which incurs high overhead and can disable JIT compilation) and extensive manual instrumentation—but both were unsuitable.

Ultimately, they adopted a rule‑based bytecode rewriter built on the ASM library. The rewriter runs as part of the build process, modifies Java bytecode before it is converted to Dalvik/ART, and automatically inserts markers at method entry and exit points based on configurable rules.

For example, a rule can inject code that logs an event whenever a specific method is entered or exited. These events are written to a log that can later be merged into a single trace file, capturing interactions between the app and the Android framework as well as framework‑to‑app calls.

The bytecode approach also enables transparent handling of asynchronous execution. By propagating context identifiers across threads, the system can stitch together a complete execution trace—from UI input through background tasks and back—revealing scheduling delays and unexpected async jumps.

Another rule demonstrates tracing of the Handler API, showing that a small set of rules can cover most asynchronous code paths.

During execution, the injected markers produce compact 32‑bit identifiers, which are later mapped back to source locations on the server, keeping trace files small and minimizing runtime overhead.

The team faced several challenges: object‑pool bottlenecks caused GC pressure; a single global event stream required careful buffering; using only primitive types limited flexibility; and excessive marker insertion could inflate app size, necessitating continuous monitoring.

Despite these hurdles, the bytecode‑based instrumentation gave Facebook deep insight into app execution flows, exposing hard‑to‑detect performance defects such as scheduling latency and unnecessary async switches.