Android Dev Tool: Best practice with StrictMode





StrictMode (android.os.StrictMode) is a developer tool which detects things you might be doing wrong by accidently and brings them to your attention.

Best practice in Android says “keeping the disk and network operations off from the main thread makes applications much smoother and more responsive”.  So StrictMode is use to catch the coding issues such as disk I/O or network access on the application's main thread i.e. UI thread.

This is a debugging tool introduced in Android 2.3(API level 9) but more features were added in Android 3.0.


StrictMode Policies

StrictMode has two types of policies and each policy has various rules.
1.    Thread policy
2.    VM policy

Thread Policy-

Thread policies are focused on the things which is not recommended to do in main thread like disk or network operations. The thread policy can monitor following violations:

·       Disk Reads
·       Disk Writes
·       Network access
·       Resource Mismatch
·       Custom Slow Code


VM Policy-

VM policies are focused on memory leaks because of bad coding practices like forgot to close the SQLite cursor or leaks in Activities. The VM policy can monitor following violation:

·       Activity leaks
·       SQLite objects leaks
·       Closable objects leaks
·       Registration objects leaks
·       Class instance limit
·       File URL exposure


Ways to notify

There are variety of different ways by which user/developer get to know when a rule you set has been violated. In terms of StrictMode it is known as Penalty. Some of them are listed below-

penaltyLog(): Log the detected violations into the system log.
penaltyDeath(): Crash the whole process when violation of rule found.
penaltyDialog(): Display a dialog for detected violations.
penaltyDeathOnNetwork(): Crash the whole process on any network usage.
penaltyDropBox(): Enable detected violations log a stacktrace and timing data to the DropBox on policy violation.
penaltyFlashScreen(): Flash the screen during a violation.


How to use

To enable and configure the StrictMode in your application, you require to use setThreadPolicy() and setVmPolicy() methods of StrictMode.  It is a good practice to set policies either in Application class or initial activity.

Here is the example of Thread Policy:
StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
                 .detectDiskReads()
                 .detectDiskWrites()
                 .detectNetwork()  
                 .penaltyLog()
                 .build());

Here is the example of VM Policy:
         StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder()
                 .detectLeakedSqlLiteObjects()
                 .detectLeakedClosableObjects()
                 .penaltyLog()
                 .penaltyDeath()
                 .build());

You can decide what should happen when a violation is detected like in the above example we have used only penaltyLog() for Thread Policy but in the VM Policy we used penaltyLog() as well as penaltyDeath() to notify.

Here is the example of penaltyLog() showing the logs which explains StrictMode is warning us that we are using disk write operation on the main thread.

DEBUG/StrictMode(23134): StrictMode policy violation; ~duration=319 ms: android.os.StrictMode$StrictModeDiskWriteViolation: policy=31 violation=1
DEBUG/StrictMode(23134):     at android.os.StrictMode$AndroidBlockGuardPolicy.onWriteToDisk(StrictMode.java:1041)
DEBUG/StrictMode(23134):     at android.database.sqlite.SQLiteStatement.acquireAndLock(SQLiteStatement.java:219)
DEBUG/StrictMode(23134):     at android.database.sqlite.SQLiteStatement.executeUpdateDelete(SQLiteStatement.java:83)
DEBUG/StrictMode(23134):     at android.database.sqlite.SQLiteDatabase.updateWithOnConflict(SQLiteDatabase.java:1829)
DEBUG/StrictMode(23134):     at android.database.sqlite.SQLiteDatabase.update(SQLiteDatabase.java:1780)
DEBUG/StrictMode(23134):     at com.test.data.MainActivity.update(MainActivity.java:87)


And here is the warning dialog looks like:



Ignore Policies

Don't try to fix everything that StrictMode finds. In most of the cases we access the disk to quickly read some data from Activity or main thread. It won’t create noticeable glitch or hanging behavior in the application UI. So instead use the StrictMode to find things you did by accident.


Conclusion

As we have seen StrictMode is a very useful tool to find and fix performance issues, object leaks, and other hard-to-find runtime issues for Android developers.  
If you find violations that you feel are problematic, there are a variety of tools to help solve them like threads, Handler, AsyncTask, IntentService, etc.
For more info on StrictMode policies and rules, please go through Android Official page.


  
To find more interesting topics on Software development follow me at https://medium.com/@ankit.sinhal.

Twitter: https://twitter.com/ankitsinhal

Comments

Post a Comment

Popular posts from this blog

Android O: Impact On Running Apps And Developer Viewpoint

Image
It’s been just about a year since Google released Android Nougat. In the next version of its Android operating system, it revealed the first developer preview of Android O (Hoping it’ll named Android Oreo) on 21 March 2017. In this article, we are going to discuss all the important features and changes of Android O from developer’s perspective. The Android O release will be known as Android 8.0. The final version of Android 8.0 will be out sometime in Q3 of 2017 and before that Google has plan to rollout DP #4. Based on DP #1, here are list of major behavioral changes which will impact on all currently running applications when run on Android O platform. ·        Background execution limits ·        Background location limits ·        Handles identifiers(Android ID) differently ·        Account Access ·        Notification Channel ·        Logging of uncaught exceptions ·        Locales and internationalization ·        Security changes
Read more

Android Performance: Avoid using ENUM on Android

Image
What and why we use ENUM? Enum in java is a data type that contains fixed set of constants. When we required predefined set of values which represents some kind of data, we use ENUM. We always use Enums when a variable can only take one out of a small set of possible values. For example: public enum Season {   WINTER, SPRING, SUMMER, FALL } Instead of using Integer or String constants, we generally use ENUM to increase compile time checking and avoid errors from passing in invalid constants. Drawback of using ENUM Each value in an ENUM is an object and each declaration will take some runtime memory simply to reference the object. So ENUM values will take more memory then Integer or String constant. Even in old android devices (<=2.2), there were some performance issue related to ENUM which were solved in JIT compiler. Adding a single ENUM will increase the size (13x times than the Integer constant) of final DEX file. It also generates the pr
Read more

Smart way to update RecyclerView using DiffUtil

Image
Say Good Bye To notifyDataSetChanged() We generally use List in any of our day to day development. It also requires to update the list data when user scrolls the list. To achieve this, we often fetch the data from server and update the newly received items. If there is a small delay during this process it impact on the user experience so we want this to be done as soon as possible with along with less resources. When the content of our list gets changed, we have to call notifyDataSetChanged() to get the updates but it is very costly. There are so many iterations for getting the job done in the case of notifyDataSetChanged(). Here DiffUtil class comes into picture and Android developed this utility class to handle data updates for a RecyclerView. What is DiffUtil As of 24.2.0, RecyclerView support library, v7 package offers really handy utility class called DiffUtil. This class finds the difference betwe
Read more