From my perspective, things that mostly affected ANRs and are relatively easy to fix:
1) Music playback with flash. Use external ANEs to play music. Sounds were less of an issue as they end quickly. MediaPlayer ANE works great as ANR fix.
2) Big CPU tasks in one frame like parsing huge XMLs or JSONs, loading and parsing long files. If you give to CPU any task that may take few seconds to complete in one frame, that's almost an ANR as if a user taps on a screen when your CPU intensive process starts and his tap will not have response for few seconds (as CPU is busy with your task), that's a straightforward definition of ANR. And it's quite easy to reproduce, just get a slow device, tap on screen many times when that long CPU-intensive process starts and do not forget to turn on "show all ANRs" on developers system menu. So if you load like some 1000 things from a file (saves/levels/etc.) and that takes more than a second, you'd better load 200, than wait 1/30 sec. (giving Starling time to dispatch Touch event), then load next 200 and so on, that should help.
Btw, loading many ANEs before flash app starts might also count as a CPU intensive task, so very early tap and too much ANEs might also be a problem, especially when you just after loading ANEs when main class constructor executes, immediately start other CPU intensive tasks.
3) Do not forget to stop Starling, timers, timeouts, intervals and all audio when app is on background. ApplicationStateEvent.BACKGROUND from Application ANE dispatches quicker for Android than common Event.DEACTIVATE , you can use them both to be sure to stop all activities (audio, Starling, timers, etc.) sooner.
4) Read about cold start, warm start, hot start and lower their time if possible.
