android StrictMode应用

首先来介绍下ANR：

ANR(Application Not Responding)定义 在Android上，如果你的应用程序有一段时间响应不够灵敏，系统会向用户显示一个对话框，这个对话框称作应用程序无响应（ANR：Application Not Responding）对话框。 用户可以选择“等待”而让程序继续运行，也可以选择“强制关闭”。所以一个流畅的合理的应用程序中不能出现anr，而让用户每次都要处理这个对话框。 因此，在程序里对响应性能的设计很重要，这样系统不会显示ANR给用户。默认情况下，在android中Activity的最长执行时间是5秒，BroadcastReceiver的最长执行时间则是10秒。      

如何避免ANR

考虑上面的ANR定义，让我们来研究一下为什么它会在Android应用程序里发生和如何最佳构建应用程序来避免ANR。 Android应用程序通常是运行在一个单独的线程（例如，main）里。这意味着你的应用程序所做的事情如果在主线程里占用了太长的时间的话，就会引发ANR对话框，因为你的应用程序并没有给自己机会来处理输入事件或者Intent广播。 因此，运行在主线程里的任何方法都尽可能少做事情。特别是，Activity应该在它的关键生命周期方法（如onCreate()和onResume()）里尽可能少的去做创建操作。潜在的耗时操作，例如网络或数据库操作，或者高耗时的计算如改变位图尺寸，应该在子线程里（或者以数据库操作为例，通过异步请求的方式）来完成。

StrictMode策略

ANR窗口产生的原因是多种多样的。程序的主线程因为IO读写或网络阻塞而导致被阻塞了，外部存储设备被独占了或系统负荷（load）过高（即不是自己编写的程序的问题，可能是系统或者其他第三方程序导致的问题），都有可能导致ANR窗口的出现。

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

目前有两大类的策略可供使用，一类是关于常用的监控方面的，另外一类是关于VM虚拟机等方面的策略。

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

常用的监控方面的策略有如下这些：

　　Disk Reads 磁盘读

　　Disk Writes 磁盘写

　　Network access 网络访问

　　Custom Slow Code 自定义的运行速度慢的代码分析

StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
				.detectDiskReads().detectDiskWrites().detectNetwork() // or
																		// .detectAll()
																		// for
																		// all
																		// detectable
																		// problems
				.penaltyLog().build());

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

VM方面的策略重点关注如下几类：

　　内存泄露的Activity对象

　　内存泄露的SQLite对象

　　内存泄露的释放的对象

StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder()
				.detectLeakedSqlLiteObjects().detectLeakedClosableObjects()
				.penaltyLog().penaltyDeath().build());

当应用启用了strictmode模式时，其实跟普通的应用没什么两样，在测试和运行时，跟平时运行普通应用程序一样就可以了。当启用了Strictmode模式时，会监视所有的程序运行情况，当发现出现重大问题或违背策略规则时，会提示用户。

忽略某些规则

　　应该说大部分由StrictMode产生的规则警示都应去遵守，但有时也不是所有产生的信息都表明你的程序有错误。比如，在应用程序的主线程中去快速读写磁盘其实不会对应用的性能产生太大的影响，又或者你在调试程序阶段有一些调试的代码违反了设定的规则，这些都可以忽略掉这些规则。

　　忽略规则有两种方法，一种是单纯在代码中把Strictmode的代码注释掉，另外一种比较好的方法是，在需要忽略的时候和地方，增加相应的代码去让系统停止使用这些规则去检查，等开发者认为有必要检查时，再重新应用这些规则。

StrictMode是一个十分有用的类，它可以很方便地应用于检查Android应用程序的性能和存在的问题。当开启这个模式后，开发者能很好地检查应用中存在的潜在问题，更多的请参考Android文档中的相关API说明。