Android:StrictMode（严苛模式）

从Android 2.3开始提供了一个新的类StrictMode，该类可以用于捕捉发生在应用程序主线程中耗时的磁盘、网络访问或函数调用，可以帮助开发者改进程序，使主线程处理UI和动画在磁盘读写和网络操作时变得更平滑，避免主线程被阻塞。
ANR窗口产生的原因是多种多样的。程序的主线程因为IO读写或网络阻塞而导致被阻塞了，外部存储设备被独占了或系统负荷（load）过高

（即不是自己编写的程序的问题，可能是系统或者其他第三方程序导致的问题），都有可能导致ANR窗口的出现。

从Android 2.3开始提供了一个新的类StrictMode，可以帮助开发者改进他们的Android应用，StrictMode可以用于捕捉发生在应用程序，主线程中耗时的磁盘、网络访问或函数调用，可以帮助开发者使其改进程序，使主线程处理UI和动画在磁盘读写和网络操作时变得更平滑，避免主线程被阻塞，导致ANR窗口的发生。

下面简要说明下Android 2.3新特性StrictMode限制模式的工作方式。

线程策略

第一个和线程相关，它主要针对主线程（或UI线程）。由于在主线程中读写磁盘和进行网络访问都不是好的做法，Google已经在磁盘和网络代码中添加了严苛模式（StrictMode）钩子（hook）。如果你对某个线程打开严苛模式（StrictMode），当那个线程进行磁盘和网络访问，你将获得警告。你可以选择警告方式。一些违例包含用户慢速调用（custom slow calls 这么翻译行吗？），磁盘读写，网络访问。你能选择将警告写入LogCat，显示一个对话框，闪下屏幕，写入DropBox日志文件，或让应用崩溃。最通常的做法是写入LogCat或让应用崩溃。如下代码显示了一个为线程策略设置严苛模式（StrictMode）的例子。

publicvoid onCreate() {
     if (DEVELOPER_MODE) {
         StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
                 .detectDiskReads()
                 .detectDiskWrites()
                 .detectNetwork()   // 这里可以替换为detectAll() 就包括了磁盘读写和网络I/O
                 .penaltyLog()   //打印logcat，当然也可以定位到dropbox，通过文件保存相应的log
                 .build());

     }
     super.onCreate();
 }

Builder类使得设置变得很简单，Builder函数定义所有策略都返回Builder对象，从而这些函数能像列表2-9那样串连在一起。最后调用build()函数返回一个ThreadPolicy对象作为StrictMode对象的setThreadPolicy()函数的参数。注意到setThreadPolicy()是一个静态函数，因此不需要实例化StrictMode对象。在内部，setThreadPolicy()将对当前线程应用该策略。如果不指定检测函数，也可以用detectAll()来替代。penaltyLog()表示将警告输出到LogCat，你也可以使用其他或增加新的惩罚（penalty）函数，例如使用penaltyDeath()的话，一旦StrictMode消息被写到LogCat后应用就会崩溃。
你不需要频繁打开严苛模式（StrictMode），你可以在主活动的onCreate()函数中打开它，你也可以在Application派生类的OnCreate()函数中设置严苛模式（StrictMode）。线程中运行的任何代码都可以设置严苛模式（StrictMode），但你的确只需要设置一次，一次就够了。

虚拟机策略

类似于线程策略（ThreadPolicy），严苛模式（StrictMode）有虚拟机策略（VmPolicy）。虚拟机策略（VmPolicy）能检查内存泄漏，譬如，当关闭一个SQLite对象前的完结操作，或其他任何类似可关闭对象在关闭前的完结操作。虚拟机策略（VmPolicy）由一个类似的Builder类创建，如列表2-10所示。和线程策略（ThreadPolicy）不同的是，虚拟机策略（VmPolicy）不能通过一个对话框提供警告。
如下代码为设置严苛模式（StrictMode）的虚拟机策略

 StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder()
                 .detectLeakedSqlLiteObjects() //探测SQLite数据库操作
                 .penaltyLog()  //打印logcat
                 .penaltyDeath()
                 .build());

其他

因为设置发生在线程中，严苛模式（StrictMode）甚至能在从一个对象到另一个对象的控制流中找到违例事件。当违例发生，你会惊奇地注意到代码正运行于主线程，而栈trace将帮助你发现它如何发生。于是你能单步调试解决问题，或是将代码移到它自己的后台线程，或是就保持原来的处理方式。这都取决与你。当然，你可能希望适时关闭严苛模式（StrictMode），当你的程序作为产品发布时，你可不希望它仅为了一个警告在你的用户手里崩溃。
有两个方法可以关闭严苛模式（StrictMode），最直接的就是移除相应代码，但这样做不利于持续开发的产品。你通常可以定义一个应用级别布尔变量来测试是否需要调用严苛模式（StrictMode）代码。在发布产品前将这个值定义为FALSE。更优雅的方式是利用调试模式（debug mode）的特点，在AndroidManifest.xml中定义这个布尔变量。<application>字段的属性之一是android:debuggable，其义自明。如下代码给出了利用该特性的控释方法。
如下代码调试模式设置严苛模式（StrictMode）

// 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());  
} 

使用Eclipse或者Android Studio调试环境，ADT自动为你设置debuggable属性，使项目更易于管理。当你在模拟器上或直接在设备上部署应用，debuggable属性为TRUE，当你导出应用建立一个产品版本，ADT将该属性置为FALSE。注意，如果你另行设置了这个属性值，ADT不会改变它。
严苛模式（StrictMode）很不错，不过在Android 2.3之前的版本上该模式不工作。为了避免这个问题，你要在StrictMode对象还不存在的时候就验证版本是否在Android2.3及以上。你能利用反射技术（reflection），当严苛模式（StrictMode）函数有效时间接调用它，反之不去调用。方法很简单，你能按如下代码处理。
利用反射技术（reflection）调用严苛模式（StrictMode）

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...");  
}  

当严苛模式（StrictMode）不存在，将捕捉到ClassNotFoundException异常。enableDefault()是严苛模式（StrictMode）类的另一个函数，它检测所有违例并写入LogCat。因为这里调用的是静态形式的enableDefault()，所以用null作为参数传入。
某些时候你不希望报告所有违例。那在主线程之外的其他线程中设置严苛模式（StrictMode）很不错。譬如，你需要在正在监视的线程中进行磁盘读取。此时，你要么不去调用detectDiskReads()，要么在调用detectAll()之后跟一个permitDiskReads()。类似允许函数也适用于其他操作。但要是你要在Anroid2.3之前版本上做这些事，有办法吗？当然有。
当应用中严苛模式（StrictMode）无效，如果你试图访问它，将抛出一个VerifyError异常。如果你将严苛模式（StrictMode）封装在一个类里，并捕捉这个错误，当严苛模式（StrictMode）无效时，你能忽略它。列表1显示一个简单的严苛模式（StrictMode）封装类StrictModeWrapper。列表2显示了如何在你的应用中使用这个封装类。
列表 1 在Anroid2.3之前版本建立严苛模式（StrictMode）封装类

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());  
        }  
    }  
} 

列表2 在Anroid2.3之前版本调用严苛模式（StrictMode）封装类

try {  
    StrictModeWrapper.init(this);  
}  
catch(Throwable throwable) {  
    Log.v("StrictMode", "... is not available. Punting...");  
}  

//如果考虑到关于版本兼容问题，因为按照上面的写法在2.3以下系统是没有问题的，但是在2.3以上的话，就会出错，所以应该采用以下方式来处理：

      @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及以上调用严苛模式
                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());
             */
        }
    } 

http://blog.csdn.net/brokge/article/details/8543145/