Networking runs on IO, but the app still has ANRs. What would you investigate next?

Answer

Moving network waits off Main eliminates one possible bottleneck. It does not prove the rest of the response pipeline is safe. Large JSON transformations, synchronous disk access, and waiting for a lock can all stall Main afterward.

Investigation

1. Identify the ANR type and affected user journey from reports. A screenshot of a frozen screen is not enough.
2. Read the main-thread stack and relevant worker stacks. If Main is waiting on a monitor, find its owner.
3. Reproduce with realistic response sizes and capture a system trace. Trace parsing, mapping, persistence, and rendering separately.
4. Fix the measured bottleneck, then compare the same workload before and after.

Example failure

Copy codeWorker: acquires shared cache lock -> performs slow disk write
Main:   needs cache lock to render -> waits behind disk write

The disk operation is already on a worker, yet Main still depends on it. Shorten the critical section or change data ownership so rendering can read a snapshot without waiting on slow work. Moving more calls to IO does not remove the dependency.

Follow-up to practise

Would StrictMode find everything? It can reveal certain problematic operations, but it is not a complete lock-contention or ANR diagnosis. Confirm a fix using traces and production ANR trends, not just the disappearance of one warning.

Reference

Android Developers: Diagnose ANRs