Hello everyone, meet again. I'm Jun Quan. I wish every programmer can learn more languages.
Android 2.3 provides a debugging feature called strict mode, which Google says has benefited hundreds of Google applications on Android. What does it do? It will report policy violations related to threads and virtual machines. Once a policy violation is detected, you will get a warning, which includes a stack trace to show where your application has violated. You can force warnings to replace crash es, or you can log only warnings to keep your application running. The details of the strategy are still difficult to determine. We can expect that with the maturity of Android, Google will add many other strategies.
At present, there are two strategies available. The first one is related to threads, which is mainly aimed at the main thread (or UI thread). Because it is not a good practice to read and write disk and network access in the main thread, Google has added strict mode hook s to disk and network code. Suppose you turn on strict mode for a thread. When that thread accesses disk and network, you will get a warning. You can choose how to warn. Some violations include user slow calls, disk read / write, and network access. You can choose to write the warning to LogCat, display a dialog box, flash down the screen, write to the DropBox log file, or crash the application. The most common approach is to write LogCat or crash the application. Listing 2-9 shows an example of setting strict mode for thread policy.
Listing 2-9 setting the thread policy for strict mode
view plain print ?
StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder() .detectDiskReads() .detectDiskWrites() .detectNetwork() .penaltyLog() .build());
The Builder class makes the setting very easy. The Builder function defines that all policies return the Builder object, so that these functions can be connected together like listing 2-9. Finally, call the build() function to return a ThreadPolicy object as the parameter of the setThreadPolicy () function of the StrictMode object. Note that setthreadpolicy () is a static function, so there is no need to instantiate the strictmode object. Internally, setThreadPolicy() will apply the policy to the current thread. Assuming no detection function is specified, detectAll() can be used instead. penaltyLog() means to output the warning to LogCat. You can also use other or add new penalty functions. For example, if you use penaltyDeath(), the application will crash once the strictmode message is written to LogCat.
You don't need to open strict mode frequently. You can open it in the oncreate() function of the main activity, and you can also set strict mode in the oncreate() function of the Application derived class. Any code executed in the thread can set strict mode, but you really only need to set it once, once is enough.
Similar to ThreadPolicy, strict mode has VmPolicy. Virtual machine policy (VmPolicy) can check memory leakage, such as the completion operation before closing a SQLite object, or the completion operation before closing any similar object. The virtual machine policy (VmPolicy) is created by a similar Builder class, as you can see in listing 2-10. Unlike thread policy, virtual machine policy (VmPolicy) cannot provide warnings through a dialog box.
Listing 2-10 setting the virtual machine policy of strict mode
view plain print ?
StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder() .detectLeakedSqlLiteObjects() .penaltyLog() .penaltyDeath() .build());
Since the setting occurs in the thread, strict mode can even find violations in the control flow from one object to another. When a violation occurs, you will be surprised to notice that the code is executing on the main thread, and stack trace will help you find out how it happens. So you can step through debugging to solve this problem, or move the code to its own background thread, or keep the original processing method. It's up to you. Of course, you may want to turn off strict mode in time. When your program is released as a product, you don't want it to crash in the hands of your users just for a warning.
There are two ways to turn off strict mode. The most direct way is to remove the corresponding code, but this is not conducive to the continuous development of products. You can usually define an application level boolean variable to test whether you need to call strict mode code. Define this value as FALSE before publishing the product. A more elegant way is to use the characteristics of debug mode to define this boolean variable in AndroidManifest.xml< One of the attributes of the application > field is android:debuggable, which is self-evident. Listing 2-11 shows the controlled release methods using this feature.
Listing 2-11 setting strict mode only in debug mode
view plain print ?
// Return if this application is not in debug mode
ApplicationInfo appInfo = context.getApplicationInfo();
int appFlags = appInfo.flags;
if ((appFlags & ApplicationInfo.FLAG_DEBUGGABLE) != 0) {
// Do StrictMode setup here
StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder()
.detectLeakedSqlLiteObjects()
.penaltyLog()
.penaltyDeath()
.build());
} Using the Eclipse debugging environment, ADT actively sets the debuggable attribute for you to make the project easier to manage. When you deploy an application on the simulator or directly on the device, the debuggable attribute is TRUE. When you export an application to establish a product version number, ADT sets this attribute to FALSE. Note that if you set this property value separately, ADT will not change it.
Strict mode is very good, but it doesn't work on Android versions before 2.3. To avoid this problem, you should verify whether the version number is Android 2.3 or above when the StrictMode object does not exist. You can use reflection technology to call the strict mode function when it is effective, and not on the contrary. The method is very easy, and you can handle it according to the code in listing 2-12
List 2-12 Using reflection technology to call strict mode
view plain print ?
try {
Class sMode = Class.forName("android.os.StrictMode");
Method enableDefaults = sMode.getMethod("enableDefaults");
enableDefaults.invoke(null);
}
catch(Exception e) {
// StrictMode not supported on this device, punt
Log.v("StrictMode", "... not supported. Skipping...");
} When the strict mode does not exist, a ClassNotFoundException exception is caught. enableDefault() is another function of the strict mode class, which detects all violations and writes to LogCat. Since enableDefault() in static form is called here, null is passed in as a parameter.
Sometimes you don't want to report all violations. It's good to set strict mode in threads other than the main thread. For example, you need to read the disk in the thread you are monitoring. At this point, you either do not call detectDiskReads(), or call detectAll() followed by a permitDiskReads(). Similar consent functions are also applicable to other operations. But if you want to do these things on the version number before anroid 2.3, is there a way? Of course.
When the strict mode in the application is invalid, if you try to access it, a VerifyError exception will be thrown. Suppose you encapsulate the strict mode in a class and catch this error. When the strict mode is invalid, you can ignore it. Listing 2-13 shows a simple StrictMode wrapper class. Listing 2-14 shows how to use this wrapper class in your application.
List 2–13 stay Anroid2.3 The previous version number establishes a rigorous mode( StrictMode)Encapsulation class view plain print ?
import android.content.Context;
import android.content.pm.ApplicationInfo;
import android.os.StrictMode;
public class StrictModeWrapper {
public static void init(Context context) {
// check if android:debuggable is set to true
int appFlags = context.getApplicationInfo().flags;
if ((appFlags & ApplicationInfo.FLAG_DEBUGGABLE) != 0) {
StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
.detectDiskReads()
.detectDiskWrites()
.detectNetwork()
.penaltyLog()
.build());
StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder()
.detectLeakedSqlLiteObjects()
.penaltyLog()
.penaltyDeath()
.build());
}
}
} List 2 – 14 Before anroid 2.3, the version number called strict mode to encapsulate the class
view plain print ?
try {
StrictModeWrapper.init(this);
}
catch(Throwable throwable) {
Log.v("StrictMode", "... is not available. Punting...");
} //Assuming that considering the compatibility of version numbers, there is no problem in the system below 2.3 according to the above writing method, but there will be errors above 2.3, so the following methods should be adopted:
@SuppressLint("NewApi")
public static void init(Context context) {
// check if android:debuggable is set to true
int appFlags = context.getApplicationInfo().flags;
if ((appFlags & ApplicationInfo.FLAG_DEBUGGABLE) != 0) {
try {
//Android 2.3 and above call harsh mode
Class sMode = Class.forName("android.os.StrictMode");
Method enableDefaults = sMode.getMethod("enableDefaults");
enableDefaults.invoke(null);
} catch (Exception e) {
// StrictMode not supported on this device, punt
Log.v("StrictMode", "... not supported. Skipping...");
}
/*
* StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
* .detectDiskReads() .detectDiskWrites() .detectNetwork()
* .penaltyLog() .build()); StrictMode.setVmPolicy(new
* StrictMode.VmPolicy.Builder() .detectLeakedSqlLiteObjects()
* .penaltyLog() .penaltyDeath() .build());
*/
}
} Publisher: full stack programmer, stack length, please indicate the source for Reprint: https://javaforall.cn/118873.html Original link: https://javaforall.cn