Being an Android developer, one of the most common issues that I have come across in Android apps is App Not Responding (ANR). ANR affects the user experience and smooth functioning of an Android app.
Normally, an ANR dialog appears on an Android device is when the UI thread/ main thread, that is responsible for updating the User Interface and process user input events, gets stuck for more than 5 seconds or when the Broadcast Receiver has not finished its execution in 10 seconds.
Some of the conditions I’ve noticed that can trigger ANR in an Android app are
When the app is executing slow operations involving I/O on the main thread.
When long calculations are executed on the main thread.
When the main thread is executing a synchronous binder call to another process and that process is executing a big task.
When the main thread is blocked waiting for another process which is executing a time-consuming task.
When the main thread is in a deadlock with another thread.
There could be instances when developers tend to overlook the code-level implementations, and cause ANR. Therefore, it is important for developers to get notified about possible ANR during development and testing.
With basic integration, Finotes development SDK is capable of monitoring UI/ Main thread in an Android App for frame-rate issues.
If the UI thread gets stuck for more than 5 seconds in Android apps, Finotes detects and reports it as a possible ANR issue.
For more details, please visit our documentation page.
The Development flavor of Finotes SDK reports ANR issues with relevant data points like activity trail, device, and device state data.
Activity Trail is a list of chronologically ordered app events, that helps us developers to identify where exactly the issue has occurred.
Activity Trail consists of three components:
The Activity segment, that has the details of the app event.
The timestamp segment, that has details of the time at which event got recorded.
The memory segment, that shows the percentage of free memory.
The above screenshot shows that Finotes has detected a possible ANR in an Android App, due to frame rate issues, that blocked the UI thread for 5000 milliseconds.
On close inspection of Activity Trail, it is evident from the timestamp that ‘ContactsReaderActivity: reading contacts’ occurred at 23:47:32:987 and the issue occurred at 23:47:37:183. No other activity was recorded between these two events. This clearly shows the UI thread that executed this event was blocked for more than 5000 milliseconds while ‘reading contacts’ in ContactsReaderActivity, which led to an ANR.
By tracing the Activity Trail events, developers can reproduce the exact frame rate issue that led to ANR and fix them fast.
The only way to avoid ANR in Android apps is by ensuring the UI thread has very less burden and all time-consuming processes that take beyond 16 milliseconds per frame are executed through worker threads. Why 16 milliseconds?. Most modern mobile screens have a refresh rate of 60 fps or frames per second i.e 60 frames per 1000 milliseconds. This gives us the magic number of 16 milliseconds per frame.
Finotes is also capable of detecting frame-rate issues in iOS and watchOS apps. Apart from ANR, Finotes also detects API call issues, memory leaks, abnormal memory usage, function failures, and delays along with custom issues and crashes.
Update: One of our customers tells us on how the ANR detection feature helped them identify the root cause. https://www.blog.finotes.com/post/identifying-root-cause-of-anr-in-android-apps.
Update: Identifying the root cause of ANR is even more easier in Finotes 6.0.0. The report now includes stacktraces that pinpoint the line number where ANR was triggered. For more details visit https://www.blog.finotes.com/post/detecting-and-fixing-anr-in-android-apps.
Visit finotes.com to know more about Finotes. Detailed documentation is available at docs.finotes.com.
Comments