Java. Lang. noclassdeffounderror: Android. OS. strictmode $ threadpolicy $ Builder

In the latest Android platform (starting from Android 2.3), a new class is added, called strictmode (Android. OS. strictmode ). This class can be used to help developers improve their applications and provide various policies. These policies can be used to check and report problems existing in developers' applications at any time, for example, you can monitor jobs that shouldn't have been completed in the main thread or other nonstandard and bad code.

Strictmode has a variety of different policies, each of which has different rules. When a developer violates a rule, each policy has different methods to display and remind users. In this article, we will illustrate how to use strictmode in Android.

　　Strictmode policies and rules

Currently, there are two main types of policies available, one for common monitoring and the other for vmvirtual machines. Common monitoring policies include the following:

Disk reads disk read

Disk writes disk write

Network Access

Custom slow code custom code analysis with slow running speed

The readers of the first three concepts should be clear, that is, they monitor disk read, write, and network access, as shown in their names. The fourth type of custom slow code analysis is triggered only when you access the called class. You can use this method to monitor slow code. When called in the main thread, these verification rules work to check your code. For example, when your application is downloading or parsing a large amount of data, you can trigger query and Analysis of custom slow-Running code. Strictmode can be used to capture the time-consuming disks, network access, or function calls that occur in the main thread of an application. It can help developers improve the program, it makes the UI and animation processed by the main thread smoother during disk read/write and network operations to avoid blocking of the main thread.

The VM policies focus on the following categories:

Activity object exposed by memory

SQLite objects with Memory leakage

Released objects with Memory leakage

Among them, the activity objects with memory leaks and SQLite objects with memory leaks are better understood. The so-called inspection of closed objects mainly aims to monitor the objects that should be released, for example, you should call the object of the close () method.

When a developer violates certain rules, each policy has a different method to let the developer know the current situation. Related violations can be recorded in logcat or stored in the Dropbox (Android. OS. Dropbox) service. Common monitoring policies also display related dialog boxes and context when violations occur. All these are designed to allow developers to understand program flaws as soon as possible, to submit the quality of the program. The following describes how to use stritctmode step by step.

　　Step 1 enable strictmode

　　Page 1: Step 1 enable strictmode

To enable and configure strictmode in an application, it is recommended that you use strictmode as early as possible by calling the strictmode method setthreadpolicy. When using common monitoring classes, the best call time is before the application entry and activities are called. For example, in an application, you can place the code in the oncreate () method of the activity class. Below is a sample code that enables all the policies and rules in the current situation, when common rules are violated in the program, the related prompt information window is displayed:

　　

Strictmode. setthreadpolicy (New strictmode. threadpolicy. Builder ()

. Detectall ()

. Penaltylog ()

. Penaltydialog () // print logcat. You can also locate Dropbox and save the corresponding log through the file.

. Build ());

Strictmode. setvmpolicy (New strictmode. vmpolicy. Builder (). detectall ()

. Penaltylog ()

. Build ());

Of course, the above Code should only be run in an application that has not been released and launched in a beta version to facilitate monitoring of relevant running conditions. strictmode should not be enabled in the production version. Therefore, the best code practices should look like the following:

　　

Public void oncreate (){

If (cmd_mode ){

Strictmode. setthreadpolicy (New strictmode. threadpolicy. Builder ()

. Detectdiskreads ()

. Detectdiskwrites ()

. Detectnetwork ()

. Penaltylog ()

. Build ());

Super. oncreate ();

　　Page 2: Step 2 run strictmode

When the strictmode mode is enabled for an application, it is actually no different from that for a common application. In testing and running, it is the same as running a common application. When the strictmode mode is enabled, all program running conditions are monitored. When a major problem or rule violation is detected, the system prompts the user. The following figure shows the information displayed to the user when the strictmode mode application is enabled and the rule is violated. Check whether the information is different from the common error information.

　　

09-04 16:15:34. 592: Debug/strictmode (15883): strictmode policy violation ;~ Duration= 319 MS: Android. OS. strictmode $ strictmodediskwriteviolation: Policy = 31 violation = 1

09-04 16:15:34. 592: Debug/strictmode (15883): at Android. OS. strictmode $ androidblockguardpolicy. onwritetodisk (strictmode. Java: 1041)

09-04 16:15:34. 592: Debug/strictmode (15883): at Android. database. SQLite. sqlitestatement. acquireandlock (sqlitestatement. Java: 219)

09-04 16:15:34. 592: Debug/strictmode (15883): At android.database.sqlite.sqlitestatement.exe cuteupdatedelete (sqlitestatement. Java: 83)

09-04 16:15:34. 592: Debug/strictmode (15883): at Android. database. SQLite. sqlitedatabase. updatewithonconflict (sqlitedatabase. Java: 1829)

09-04 16:15:34. 592: Debug/strictmode (15883): at Android. database. SQLite. sqlitedatabase. Update (sqlitedatabase. Java: 1780)

09-04 16:15:34. 592: Debug/strictmode (15883): At com. mamlambo. Tutorial. tutlist. Data. tutlistprovider. Update (tutlistprovider. Java: 188)

09-04 16:15:34. 592: Debug/strictmode (15883): at Android. content. contentprovider $ transport. Update (contentprovider. Java: 233)

09-04 16:15:34. 592: Debug/strictmode (15883): at Android. content. contentresolver. Update (contentresolver. Java: 847)

09-04 16:15:34. 592: Debug/strictmode (15883): At com. mamlambo. Tutorial. tutlist. Data. tutlistprovider. markitemread (tutlistprovider. Java: 229)

09-04 16:15:34. 592: Debug/strictmode (15883): At com. mamlambo. Tutorial. tutlist. tutlistfragment. onlistitemclick (tutlistfragment. Java: 99)

09-04 16:15:34. 592: Debug/strictmode (15883): at Android. Support. v4.app. listfragment $2. onitemclick (listfragment. Java: 53)

09-04 16:15:34. 592: Debug/strictmode (15883): at Android. widget. adapterview. Adjust mitemclick (adapterview. Java: 282)

09-04 16:15:34. 592: Debug/strictmode (15883): at Android. widget. abslistview. Adjust mitemclick (abslistview. Java: 1037)

09-04 16:15:34. 592: Debug/strictmode (15883): at Android. widget. abslistview $ adjust mclick. Run (abslistview. Java: 2449)

09-04 16:15:34. 592: Debug/strictmode (15883): at Android. widget. abslistview $ 1.run( abslistview. Java: 3073)

09-04 16:15:34. 592: Debug/strictmode (15883): at Android. OS. handler. handlecallback (handler. Java: 587)

09-04 16:15:34. 592: Debug/strictmode (15883): at Android. OS. handler. dispatchmessage (handler. Java: 92)

09-04 16:15:34. 592: Debug/strictmode (15883): at Android. OS. login. loop (login. Java: 132)

09-04 16:15:34. 592: Debug/strictmode (15883): at Android. App. activitythread. Main (activitythread. Java: 4123)

09-04 16:15:34. 592: Debug/strictmode (15883): At java. Lang. Reflect. method. invokenative (native method)

09-04 16:15:34. 592: Debug/strictmode (15883): At java. Lang. Reflect. method. Invoke (method. Java: 491)

09-04 16:15:34. 592: Debug/strictmode (15883): At com. Android. Internal. OS. zygoteinit $ methodandargscaller. Run (zygoteinit. Java: 841)

09-04 16:15:34. 592: Debug/strictmode (15883): At com. Android. Internal. OS. zygoteinit. Main (zygoteinit. Java: 599)

09-04 16:15:34. 592: Debug/strictmode (15883): At Dalvik. system. nativestart. Main (NATIVE METHOD

The following prompt window appears, prompting the user:

　　Ignore certain rules

It should be said that most rule warnings generated by strictmode should be followed, but sometimes not all generated information indicates that your program has errors. For example, fast disk read/write in the main thread of the application will not have a big impact on the performance of the application, or some debugging code in the debugging program stage violates the set rules, and these rules can be ignored.

There are two ways to ignore rules. One is to simply comment out the strictmode code in the code, and the other is better, when you need to ignore the rules and places, add the relevant code to stop the system from using these rules for inspection. When the developer deems it necessary to check the rules, re-apply them. For example:

Strictmode. threadpolicy old = strictmode. getthreadpolicy ();

Strictmode. setthreadpolicy (New strictmode. threadpolicy. Builder (old)

. Permitdiskwrites ()

. Build ());

Docorrectstuffthatwritestodisk ();

Strictmode. setthreadpolicy (old );

Here, we use old to save the current policy rule, and then docorrectstuffthatwritestodisk ();

Here, we performed some fast read/write operations to the disk, and finally re-enabled these rules.

　　Summary

Strictmode is a very useful class that can be easily used to check the performance and problems of Android applications. When this mode is enabled, developers can check potential problems in the application. For more information, see the related API descriptions in the android documentation.