严苛模式（StrictMode）

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

列表2-9 设置严苛模式（StrictMode）的线程策略

    Builder类使得设置变得非常easy，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）不能通过一个对话框提供警告。

列表2-10 设置严苛模式（StrictMode）的虚拟机策略

    由于设置发生在线程中，严苛模式（StrictMode）甚至能在从一个对象到还有一个对象的控制流中找到违例事件。当违例发生，你会惊奇地注意到代码正执行于主线程，而栈trace将帮助你发现它怎样发生。于是你能单步调试解决这个问题，或是将代码移到它自己的后台线程，或是就保持原来的处理方式。这都取决与你。当然，你可能希望适时关闭严苛模式（StrictMode），当你的程序作为产品公布时，你可不希望它仅为了一个警告在你的用户手里崩溃。

    有两个方法能够关闭严苛模式（StrictMode），最直接的就是移除对应代码，但这样做不利于持续开发的产品。你通常能够定义一个应用级别布尔变量来測试是否须要调用严苛模式（StrictMode）代码。在公布产品前将这个值定义为FALSE。更优雅的方式是利用调试模式（debug mode）的特点，在AndroidManifest.xml中定义这个布尔变量。<application>字段的属性之中的一个是android:debuggable，其义自明。列表2-11给出了利用该特性的控释方法。

列表2-11 仅在调试模式设置严苛模式（StrictMode）

    使用Eclipse调试环境，ADT自己主动为你设置debuggable属性，使项目更易于管理。当你在模拟器上或直接在设备上部署应用，debuggable属性为TRUE，当你导出应用建立一个产品版本号，ADT将该属性置为FALSE。注意，假设你另行设置了这个属性值，ADT不会改变它。

    严苛模式（StrictMode）非常不错，只是在Android 2.3之前的版本号上该模式不工作。为了避免这个问题，你要在StrictMode对象还不存在的时候就验证版本号是否在Android2.3及以上。你能利用反射技术（reflection），当严苛模式（StrictMode）函数有效时间接调用它，反之不去调用。方法非常easy，你能按列表2-12中的代码处理

列表2-12  利用反射技术（reflection）调用严苛模式（StrictMode）

    当严苛模式（StrictMode）不存在，将捕捉到ClassNotFoundException异常。enableDefault()是严苛模式（StrictMode）类的还有一个函数，它检測全部违例并写入LogCat。由于这里调用的是静态形式的enableDefault()，所以用null作为參数传入。

    某些时候你不希望报告全部违例。那在主线程之外的其它线程中设置严苛模式（StrictMode）非常不错。譬如，你须要在正在监视的线程中进行磁盘读取。此时，你要么不去调用detectDiskReads()，要么在调用detectAll()之后跟一个permitDiskReads()。类似同意函数也适用于其它操作。但要是你要在Anroid2.3之前版本号上做这些事，有办法吗？当然有。

    当应用中严苛模式（StrictMode）无效，假设你试图訪问它，将抛出一个VerifyError异常。假设你将严苛模式（StrictMode）封装在一个类里，并捕捉这个错误，当严苛模式（StrictMode）无效时，你能忽略它。列表2-13显示一个简单的严苛模式（StrictMode）封装类StrictModeWrapper。列表2-14显示了怎样在你的应用中使用这个封装类。

列表 2–13 在Anroid2.3之前版本号建立严苛模式（StrictMode）封装类

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

1. try {  
2.     StrictModeWrapper.init(this);  
3. }  
4. catch(Throwable throwable) {  
5.     Log.v(“StrictMode”, “… is not available. Punting…”);  
6. }  

//假设考虑到关于版本号兼容问题，由于依照上面的写法在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());
			 */
		}
	}