Android 应用开发稳定性测试之 StrictMode
http://www.cnblogs.com/frydsh/archive/2012/10/26/2741740.html
从Android 2.3（API Level 9）开始，Android提供了一个程序性能诊断工具，它就是StrictMode。
目前，StrictMode的能力与限制包括：
1.基于线程的对磁盘读写，网络操作，以及自定义耗时操作等的监控；
2.基于VM进程的对对象泄露（Activity对象，SQLite对象，未反注册对象，未关闭对象）的监控；
3.可以检测到跨进程的耗时操作（当然必须是同步操作）；
4.当前不支持在jni中发生的网络与磁盘操作。
随着Android的进化，StrictMode的功能也将越来越强大。
当StrictMode检测到指定的事件发生时，它以指定的方式通知你：崩溃，弹出对话框，闪屏，logcat，dropbox。
为什么磁盘操作也被认为是耗时的？
虽然Android设备几乎都使用flash memory作为存储，读写速度堪比固态硬盘（SSD），但是建立在其上的文件系统可能会限制读写并发性，使得读写操作的时间不够稳定。
例如，广为使用的YAFFS文件系统使用了一个全局的同步锁，在同一时间只允许一个磁盘读写操作，这使得磁盘读写的时间变得相当的不可靠。
在程序的发布版本中，一定要注意关掉StrictMode，但是可以在Beta版本中保留它，以便从志愿者那里收集性能数据。
参考连接：
http://android-developers.blogspot.com/2010/12/new-gingerbread-api-strictmode.html
https://code.google.com/p/zippy-android/
StrictMode有多种不同的策略，每一种策略又有不同的规则，当开发者违背某个规则时，每个策略都有不同的方法去显示提醒用户。在本文中，将举例子说明如何使用在Android 中使用 StrictMode。
StrictMode的策略和规则
目前，有两大类的策略可供使用，一类是关于常用的监控方面的，另外一类是关于VM虚拟机等方面的策略。常用的监控方面的策略有如下这些：
Disk Reads 磁盘读
Disk Writes 磁盘写
Network access 网络访问
Custom Slow Code 自定义的运行速度慢的代码分析
前面三种的意思读者应该很清楚，就是正如它们的名字所示，分别对磁盘的读和写，网络访问进行监控。而第四种的自定义慢代码分析，是仅当访问调用类的时后才触发的，可以通过这种方法去监视运行缓慢的代码。当在主线程中调用时，这些验证规则就会起作用去检查你的代码。比如，当你的应用在下载或者解析大量的数据时，你可以触发自定义运行速度慢代码的查询分析，作用很大。StrictMode可以用于捕捉发生在应用程序主线程中耗时的磁盘、网络访问或函数调用，可以帮助开发者使其改进程序，使主线程处理UI和动画在磁盘读写和网络操作时变得更平滑，避免主线程被阻塞的发生
而VM方面的策略重点关注如下几类：
内存泄露的Activity对象、 内存泄露的SQLite对象、 内存泄露的释放的对象
其中，内存泄露的Activity对象和内存泄露的SQLite对象都比较好理解，而所谓对关闭对象的检查，主要是去监那些本该释放的对象，比如应该调用close()方法的对象。
当开发者违反某类规则时，每种策略都会有不同的方法令开发者知道当时的情况。相关的违反情况可以记录在LogCat中或者存储在DropBox中(android.os.DropBox)服务中。而常用监控类的策略还会在当违规情况发生时显示相关的对话框和当时的上下文环境，所有的这些都为了能让开发者尽快地了解程序的瑕疵，以提交程序的质量。
实例代码，将代码放入main activity的onCreate函数中：
StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
.detectDiskReads()
.detectDiskWrites()
.detectNetwork() // 这里可以替换为detectAll() 就包括了磁盘读写和网络I/O
.penaltyLog() //打印logcat
.build());
StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder()
.detectLeakedSqlLiteObjects() //探测SQLite数据库操作
.penaltyLog() //打印logcat
.penaltyDeath()
.build());