Testing Android UI Performance
Article Summary
Glance's engineering team serves 100M+ users where visual experience is everything. When UI performance drops, users notice immediately—and they leave.
Rishi from Glance breaks down their systematic approach to Android UI performance testing. This is part 1 of a 3-part series that moves from high-level metrics to granular debugging.
Key Takeaways
- The benchmark: 60 fps consistently, anything less creates visible jank
- Three-level approach: 1000 ft view (gfxinfo), 100 ft (Systrace), 10 ft (CPU Profiler)
- Automated tests wired to PR merges give instant performance feedback to developers
- 99th percentile frame time reveals what 99% of users actually experience
- Profile HWUI rendering shows exactly which screens cross the 16ms threshold
Glance automated their entire UI performance testing pipeline to catch regressions before merge, moving from manual testing to continuous performance monitoring.
About This Article
Rishi's team at Glance needed to measure UI performance with actual data instead of just watching it happen. They wanted frame-by-frame metrics to see which screens and user flows were causing rendering to go over the 16ms benchmark.
They set up three diagnostic tools. Profile HWUI rendering showed frame rates at a high level. The gfxinfo dumpsys commands captured 99th percentile frame times. Color-coded rendering pipeline stages helped them find where the slowdowns were happening.
Glance automated gfxinfo collection and connected the tests to PR merges. This turned UI performance testing from a manual, error-prone process into continuous feedback. Now developers get immediate alerts when code changes affect frame rendering times.