Hello Guys!!! Hope You All are doing Well!!!
Avoiding ANRs becomes a way of life when developing with the Android's SDK and UI Framework. Here I am going to give you a quick tip for troubleshooting ANRs and keeping your app's UI responsive.
If you've been programming on the Android platform for more than a day, you've probably experienced an Application Not Responding (ANR) dialog (below is the image).
An ANR occurs when Android detects the system is unable to respond to user input for more than a few seconds, and the result is the dreaded your-app-has-stopped-responding dialog. If you're interested in the nuts-and-bolts of what causes an ANR and techniques for avoiding them in your own apps here is the link on Developer site for a good Article.
Now question is arises why ANR occurs?
In any situation in which your app performs a potentially lengthy operation on main thread or UI thread. This keeps the UI thread concluding that your code has frozen. So It shows ANR dialog. Following is the case in which Main thread shows ANR dialog :-
Android applications normally run entirely on a single thread by default the "UI thread" or "main thread"). This means anything your application is doing in the UI thread that takes a long time to complete can trigger the ANR dialog because your application is not giving itself a chance to handle the input event or intent broadcasts.
Therefore, any method that runs in the UI thread should do as little work as possible on that thread. In particular, activities should do as little as possible to set up in key life-cycle methods such as onCreate() and onResume().
So long running operations such as network or database operations, or computationally expensive calculations such as resizing bitmaps should be done in a worker thread. The most effecive way to create a worker thread for longer operations is with the AsyncTask class. Simply extend AsyncTask and implement the doInBackground() method to perform the work. To post progress changes to the user, you can call publishProgress(), which invokes the onProgressUpdate() callback method. From your implementation of onProgressUpdate() (which runs on the UI thread), you can notify the user.
The last question How can we trace the ANR in our application?
There are a number of ways to find the bottleneck in your code that causes an ANR. One technique I've begun to use recently is the trace file that the system generates on the device whenever an ANR occurs.
...adt-bundle-windows-x86-20130917\sdk\platform-tools>adb pull /data/anr/traces.txt
3. At this point the file should be on your local drive.
You can open the file in any text editor. You'll have to dig through the time stamps to find out exactly what was going on when your application hung.
The log seems to get appended to continuously, so there may be quite a bit of trace data to filter through. Still, it's a relatively quick and painless way to begin narrowing down an ANR, especially in instances where the exact circumstances that cause the ANR are tough to reproduce on the debugger.
Happy Coding !!!!
Avoiding ANRs becomes a way of life when developing with the Android's SDK and UI Framework. Here I am going to give you a quick tip for troubleshooting ANRs and keeping your app's UI responsive.
If you've been programming on the Android platform for more than a day, you've probably experienced an Application Not Responding (ANR) dialog (below is the image).
An ANR occurs when Android detects the system is unable to respond to user input for more than a few seconds, and the result is the dreaded your-app-has-stopped-responding dialog. If you're interested in the nuts-and-bolts of what causes an ANR and techniques for avoiding them in your own apps here is the link on Developer site for a good Article.
Now question is arises why ANR occurs?
In any situation in which your app performs a potentially lengthy operation on main thread or UI thread. This keeps the UI thread concluding that your code has frozen. So It shows ANR dialog. Following is the case in which Main thread shows ANR dialog :-
- No response to an input event (such as key press or screen touch events) within 5 seconds.
- A BroadcastReceiver hasn't finished executing within 10 seconds.
Android applications normally run entirely on a single thread by default the "UI thread" or "main thread"). This means anything your application is doing in the UI thread that takes a long time to complete can trigger the ANR dialog because your application is not giving itself a chance to handle the input event or intent broadcasts.
Therefore, any method that runs in the UI thread should do as little work as possible on that thread. In particular, activities should do as little as possible to set up in key life-cycle methods such as onCreate() and onResume().
So long running operations such as network or database operations, or computationally expensive calculations such as resizing bitmaps should be done in a worker thread. The most effecive way to create a worker thread for longer operations is with the AsyncTask class. Simply extend AsyncTask and implement the doInBackground() method to perform the work. To post progress changes to the user, you can call publishProgress(), which invokes the onProgressUpdate() callback method. From your implementation of onProgressUpdate() (which runs on the UI thread), you can notify the user.
The last question How can we trace the ANR in our application?
There are a number of ways to find the bottleneck in your code that causes an ANR. One technique I've begun to use recently is the trace file that the system generates on the device whenever an ANR occurs.
1. Open a command window and find the platform-tools directory of your Android SDK
.../Applications/adt-bundle-windows-x86-20130917/sdk/platform-tools
2. Connect the device you received the ANR on via USB and issue an ADB pull command....adt-bundle-windows-x86-20130917\sdk\platform-tools>adb pull /data/anr/traces.txt
3. At this point the file should be on your local drive.
You can open the file in any text editor. You'll have to dig through the time stamps to find out exactly what was going on when your application hung.
The log seems to get appended to continuously, so there may be quite a bit of trace data to filter through. Still, it's a relatively quick and painless way to begin narrowing down an ANR, especially in instances where the exact circumstances that cause the ANR are tough to reproduce on the debugger.
Happy Coding !!!!
Very useful information that you have shared and it is very useful to me.Thanks for sharing the information with us.
ReplyDeletemobile app development company in chennai