At Crashlytics, we often help developers explore ways to build the most stable applications. With this in mind, we've recently begun to look at the common causes of crashes in Android apps. In particular, we are curious about the ability to find some clues to the app crash in the Android Support library, which is one of the most widely used libraries in Android apps. (seems to be written by foreigners)
In the 100 million crashes we analyzed, it was found that about 4% of the crashes were related to the support library. Through deeper analysis, our research shows that the overwhelming majority of crashes are caused by some common minor errors that can be avoided. Based on these analyses, we identified some of the best practices that are often overlooked when using the support library, as well as three key ways to improve stability.
1, asynctasks and configuration information changes
Asynctasks (asynchronous tasks) are often used to implement background operations, and optionally update the user interface after the operation is complete. Changes to the use of asynctasks and processing configuration information (config changes) are the source of common vulnerabilities. When Asynctask is running, if fragment is detached from the corresponding activity, when it tries to enter activity, your app will crash when it calls the stack, such as the following crash:
Java.lang.IllegalStateException:Fragment myfragment not attached to Activity
At Android.support.v4.app.Fragment.getResources (fragment.java:551)
At Android.support.v4.app.Fragment.getString (fragment.java:573)
At the top of the stack, fragment relies on an active activity to get the resources of the app. One way to prevent this collapse is to keep the Asynctask task when the configuration changes. Implementing this method can use Retainedfragment to perform asynctask and inform the listener about the state of the asynctask operation. For more information, see this example Fragmentretaininstance.java
2. Execute fragment Transaction safely
Fragment transactions is used to add, remove, or replace Fragment on an activity. Most of the time, fragment transaction is executed in the activity's OnCreate () method, and may also respond in interaction with the user. However, we have seen many examples where fragment transaction was executed when an activity was resumed. When this happens, your app may crash below:
Java.lang.IllegalStateException:Can not perform this action after onsaveinstancestate
At Android.support.v4.app.FragmentManagerImpl.checkStateLoss (fragmentmanager.java:1327)
At Android.support.v4.app.FragmentManagerImpl.enqueueAction (fragmentmanager:1338)
At Android.support.v4.app.BackStackRecord.commitInternal (backstackrecord.java:595)
At Android.support.v4.app.BackStackRecord.commit (backstackrecord:574)
At Android.support.v4.app.DialogFragment.show (dialogfragment:127)
Whenever a fragmentactivity is placed in the background, the mstatesaved flag in the corresponding Fragmentmangerimpl is set to true. This flag is used to check if there is a state loss. When attempting to execute a transaction, if the flag is true, then the IllegalStateException exception is thrown first. To prevent state loss, fragment transaction cannot be executed until the Onsaveinstancestate () method is called. A crash can occur because the state has been saved but the flag has not been set back to false before the Onresume () method has been called.
To prevent this collapse, you should prevent fragment transactions from being executed in the Onresume () method of the activity. Otherwise, use the Onresumefragment () method, which is recommended for dealing with fragment in the right state.
3. Manage the life cycle of the cursor
CursorAdapter can easily bind the cursor's data to a ListView object. However, if a cursor becomes invalid, the following crash occurs if the user interface is updated:
Java.lang.IllegalStateException:this should only being called when the cursor is valid
At Android.support.v4.widget.CursorAdapter.getView (cursoradapter.java:245)
At Android.widget.HeaderViewListAdapter.getView (headerviewlistadapter.java:253)
This exception is thrown when the Mdatavalid field of CursorAdapter is set to false. This happens for the following reasons:
Cursor is set to NULL;
A requery operation on the cursor failed;
The oninvalidated () method on data is called.
One reason for this is whether you use both the Cursorloader and Startmanagingcursor () methods to manage your cursor. Startmanagingcursor () has been deprecated and replaced by Cursorloader. If you are using fragments, be sure to use Cursorloader to manage the cursor life cycle and remove references to all startmanagingcursor () and Stopmanagingcursor () methods.
Summary
The above three considerations can greatly reduce the chance of the support library from throwing a fatal anomaly. This leads to a better user experience, better scoring and a more successful application.
Crashlytics for Android reports uncaught exceptions that are thrown from the support library or the application elsewhere. Add the Android SDK to your app to see what else crashes you've overlooked.
Three key ways to improve the stability of Android support library
