Where does your ANR come from? Diagnosing mechanisms and prescribing by symptoms
- chomiNRIネットコム株式会社 アプリケーションエンジニア
You open Crashlytics. You look at the number of ANRs and instinctively look away. You have no idea what caused the app to freeze, and even when you check the report, what is written there does not quite make sense—have you ever felt that ANRs are frustratingly difficult? It all started with introducing WorkManager and an increased frequency of app launches via Deeplinks. These were very common changes in development. However, starting from that point, ANRs began to visibly increase. It was not that new bugs were introduced. Rather, existing implementations that already carried ANR risks surfaced all at once because the launch mechanism and execution flows changed. From there, a painstaking effort began to isolate and eliminate causes one by one. From the ANRs faced in this journey, this session picks up representative examples and explains their causes and solutions. We will specifically cover typical patterns that easily cause ANRs—such as I/O on the main thread, heavy initialization during app launch, and lock contention—from identifying the cause to taking action. In addition, we will explain concepts that are often hard to grasp, such as the main thread and Binder, as well as investigation techniques like reading trace files. After listening, the feeling of "I don't know what's happening" when opening Crashlytics should turn into a perspective of "this might be this pattern." We hope you leave with a stepping stone for forming hypotheses and proceeding with investigations. (Translated by the DroidKaigi Committee)
Intended audience
・Those who are troubled by ANRs