After a year of effort, I finally achieved 0% ANR in Respawn. Here’s a complete guide on how I did it.
Let’s start with 12 tips you need to address first, and in the next post I’ll talk about three hidden sources of ANR that my colleagues still don’t believe exist.
1. Add event logging to Crashlytics
Crashlytics allows you to record any logs in a separate field to see what the user was doing before the ANR. Libraries like FlowMVI let you do this automatically. Without this, you won’t understand what led to the ANR, because their stack traces are absolutely useless.
Especially encrypted ones. They are the #1 cause of ANRs. Use DataStore with Kotlin Serialization instead. I’ll explain why I hate prefs so much in a separate …
After a year of effort, I finally achieved 0% ANR in Respawn. Here’s a complete guide on how I did it.
Let’s start with 12 tips you need to address first, and in the next post I’ll talk about three hidden sources of ANR that my colleagues still don’t believe exist.
1. Add event logging to Crashlytics
Crashlytics allows you to record any logs in a separate field to see what the user was doing before the ANR. Libraries like FlowMVI let you do this automatically. Without this, you won’t understand what led to the ANR, because their stack traces are absolutely useless.
Especially encrypted ones. They are the #1 cause of ANRs. Use DataStore with Kotlin Serialization instead. I’ll explain why I hate prefs so much in a separate post later.
3. Experiment with handling UI events in a background thread
If you’re dealing with a third-party SDK causing crashes, this won’t solve the delay, but it will mask the ANR by moving the long operation off the main thread earlier.
4. Avoid using GMS libraries on the main thread
These are prehistoric Java libraries with callbacks, inside which there’s no understanding of even the concept of threads, let alone any action against ANRs. Create coroutine-based abstractions and call them from background dispatchers.
5. Check your Bitmap / Drawable usage
Bitmap images when placed incorrectly (e.g., not using drawable-nodpi) can lead to loading images that are too large and cause ANRs.
Non-obvious point: This is actually an OOM crash, but every Out of Memory Error can manifest not as a crash, but an ANR!
6. Enable StrictMode and aggressively fix all I/O operations on the main thread
You’ll be shocked at how many you have. Always keep StrictMode enabled.
Important: enable StrictMode in a content provider with priority Int.MAX_VALUE, not in Application.onCreate(). In the next post I’ll reveal libraries that push ANRs into content providers so you don’t notice.
7. Look for memory leaks
**Never use coroutine scope constructors (CoroutineScope(Job())). Add timeouts to all suspend functions with I/O. Add error handling. Use LeakCanary. Profile memory usage. Analyze analytics from step 1 to find user actions that lead to ANRs.
80% of my ANRs were caused by memory leaks and occurred during huge GC pauses. If you’re seeing mysterious ANRs in the console during long sessions, it’s extremely likely that it’s just a GC pause due to a leak.
8. Don’t trust stack traces
They’re misleading, always pointing to some random code. Don’t believe that - 90% of ANRs are caused by your code. I reached 0.01% ANR after I got serious about finding them and stopped blaming Queue.NativePollOnce for all my problems.
9. Avoid loading files into memory
Ban the use of File().readBytes() completely. Always use streaming for JSON, binary data and files, database rows, and backend responses, encrypt data through Output/InputStream. Never call readText() or readBytes() or their equivalents.
10. Use Compose and avoid heavy layouts
Some devices are so bad that rendering UI causes ANRs.
- Make the UI lightweight and load it gradually.
- Employ progressive content loading to stagger UI rendering.
- Watch out for recomposition loops - they’re hard to notice.
11. Call goAsync() in broadcast receivers
Set a timeout (mandatory!) and execute work in a coroutine. This will help avoid ANRs because broadcast receivers are often executed by the system under huge load (during BOOT_COMPLETED hundreds of apps are firing broadcasts), and you can get an ANR simply because the phone lagged.
Don’t perform any work in broadcast receivers synchronously. This way you have less chance of the system blaming you for an ANR.
12. Avoid service binders altogether (bindService())
It’s more profitable to send events through the application class. Binders to services will always cause ANRs, no matter what you do. This is native code that on Xiaomi “flagships for the money” will enter contention for system calls on their ancient chipset, and you’ll be the one getting blamed.
If you did all of this, you just eliminated 80% of ANRs in your app. Next I’ll talk about non-obvious problems that we’ll need to solve if we want truly 0% ANR. Subscribe to social media or the newsletter so you don’t miss part two.