New Gingerbread API:StrictMode

StrictMode是Gingerbread的一个新API，用来设置对一个thread的策略，你可以设置不允许在这个thread上执行的某些操作，并且设置对应的惩罚措施，如果出现不允许的操作的话。通过优雅的设计，这些策略可以通过一些整数很容易的指定。
默认情况下，你允许所有的操作，除非你已经指定了。你可以指定如下的一些操作：
detect disk writes

detect disk reads

detect network usage

on a violation: log

on a violation: crash

on a violation: dropbox

on a violation: show an annoying dialog

此外，在大多数访问磁盘(java.io.*,android.database.sqlite.*)或者网络(java.net.*)的地方StrictMode有一大堆钩子，在那可以检查thread的策略，执行你的指令。

StrictMode强大的地方是每个thread的策略是可以自我繁殖的，当Binder IPC 调用Services或者Providers，

你也许知道你的应用在什么时候访问的磁盘，但是你知道系统中的那些services和providers什么时候会访问吗？我不知道，但肯定有很多地方访问。因此我习惯使用StrictMode来帮忙，找出那些不经意中访问了磁盘的地方。

等等，为什么要访问磁盘?Android 设备不是一直允许在内存中吗？就像一个超速的SSD？我不需要去关心？不幸的是，我们需要关心。
你不能指望android设备上的内存或者文件系统一如既往的快。在许多android设备上使用的YAFFS文件，当执行操作时，有一个全局的锁。只有一个磁盘操作能真正执行，不幸运的话，即使一个简单的"stat"操作也会让你等上一会。其他设备上基于传统的阻塞式文件系统，可能偶尔会让你饱受等待的折磨，当系统去回收垃圾或者做一些清除的操作时。
Android的回掉和生命周期事件都是在主thread(即UI thread)上发生的。很多时候让我们更轻松，但是有时候，你总是需要小心一点，因为所有的动画，拖动，以及手势的处理过程都是在主thread上回掉完成的。
如果你想以60帧/秒的速度动画，同时处理一个输入事件，你需要在16ms内做出反应，如果你的处理过程超过了16ms，比如写操作，可能就会导致动画卡顿。读操作可能更好点，但是也可能超过16ms，尤其是在YAFFS上，如果你正在等待一个文件锁，而该文件正写操作了一半。
网络尤其会慢，而且不连续，因此你不能在主thread上进行网络的请求操作。事实上，即将发布的Honeycomb版本，我们把在主thread上请求网络，视为一个严重的错误，如果那样，除非你的应用工作在Honeycomb之前的版本上.因此如果你想使用Honeycomb SDK，请确保不要在UI thread上请求网络。
启用StrictMode
推荐的使用StrictMode的方式是，在开发阶段，打开它，在发布应用前，关闭它。
例如：在你的应用中，onCreate():
public void onCreate() {
if (DEVELOPER_MODE) {
StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
.detectDiskReads()
.detectDiskWrites()
.detectNetwork()
.penaltyLog()
.build());
}
super.onCreate();
}
或者简单点：

public void onCreate() {
if (DEVELOPER_MODE) {
StrictMode.enableDefaults();
}
super.onCreate();
}
后面这种方式是为了兼容Gingerbread之前的版本而特意添加的API,让你仍然能使用StrictMode或者其他的技术。例如：你能在Donut(Android 1.6)上使用，如果你在Gingerbread的设备或者模拟器上调试的话。
Watching StrictMode
如果你使用penaltyLog(),也是默认选项，只需要运行adb logcat ,查看终端输出，一些违反规则的信息会在这控制台上打出来，
如果你想更炫一点，打开penaltyDropbox()，将使用DropBoxManager来写，你可以使用以下命令解压来查看：
adb shell dumpsys dropbox data_app_strictmode --print

Tops on being smooth
除了Thread和java.util.concurrent.*,还可以检查如下Android APIs,如Handler,AsyncTask,AsyncQueryHandler,IntentService.

我们的经验
开发Android时，每天我们有一个新的"dogfood"编译工整个组使用，贯穿整个开发Gingerbread的过程中，我们每天编译，使用StrictMode来记录和上传发现的违规部分，用来分析。每个小时，有一个MapReduce作业在运行，生成一个交互的报告，所有事件的循环场景，堆栈内容，出现的比率，出现在哪些过程/包中，等等。
使用这些由StrictMode收集的数据，我们修复了整个系统中上百个无响应的bug和动画故障。我们在Android核心(系统services和providers)做性能优化，所有的应用都会因此受益，也同时修复了巨量的应用方面的问题。即使你还在使用Froyo,最近的GMail,Google Maps, 和YouTube的更新也因此受益，通过使用Gingerbread设备来收集数据。
我们不能使系统自动变快，转而我们通过增加一些API来使这些工作更加容易高效。
让系统更快，当然不能完全归功于StrictMode,Gingerbread中新的并发垃圾收集器也极大的减少了这些潜伏的短暂没反应的问题。

以后StrictMode API当然会继续扩展。