我试图按照Android的最佳实践，所以在调试模式下我把所有以下的：

  StrictMode.setThreadPolicy（新StrictMode.ThreadPolicy.Builder（）detectAll（）penaltyLog（）建立（）。）; //检测并记录所有线程违规
StrictMode.setVmPolicy（新StrictMode.VmPolicy.Builder（）detectAll（）penaltyLog（）建（））; //检测并记录所有虚拟机侵犯
 

Android的现在骂我，当我尝试使用任何类型的文件访问或SQL主（UI）线程。但是，我看到这么多的建议，使用文件访问和/或SQL在主线程。例如，他们没有确定的主要活动应装入盒内的onCreate默认preference值（）：

  preferenceManager.setDefaultValues​​（背景下，渣油，readAgain）;
 

哎呀---这导致在第一个应用程序执行文件访问，因为的onCreate（）被称为UI线程。围绕它的唯一途径，我可以看到的是启动一个单独的线程---这引入了竞争条件与其他UI code可能读取preferences和期望的默认值已被设置。

想想也是服务，如下载管理器中。 （事实上​​，它是如此的越野车，它是在现实生活中毫无用处，但我们pretend它工作一秒钟。）如果你排队下载，你会得到一个事件（在主线程中），告诉您下载已完成。要真正获取有关的下载信息（只给你一个下载ID），你必须查询下载管理器---这涉及到一个光标，给你一个错误，如果你有一个严格的政策打开。

那么，有什么故事---是罚款访问光标在主线程？或者是一件坏事，而一半的Andr​​oid开发团队和Android书的作者忘了这一点？

它周围的唯一途径，我可以看到的是启动一个单独的线程---这引入了竞争条件与其他UI code可能读取preferences并期望默认值已经被设置。

然后使用的AsyncTask ，把 setDefaultValues​​（）在调用doInBackground（） 和其他UI code可能读取preferences在 onPostExecute（）。

要真正得到有关的下载信息（只给你一个下载ID），你必须查询下载管理器---这涉及到一个光标，给你一个错误，如果你有一个严格的政策打开。

所以查询下载管理器在后台线程。

那么，有什么故事---是罚款访问光标在主线程？

这取决于你的精的定义。

在Android 1.x和2.x的大部分设备，使用的文件系统是YAFFS2，基本上整个序列化的所有进程都接盘。净效应是，当你的code可以出现在隔离足够高性能，它出现在迟缓由于其他事情正在进行中的背景（例如，下载新的电子邮件）倍生产

虽然这是Android的3.x和上面少一点的问题（他们切换到ext4），毫无疑问那一刹那I / O还是比较慢的 - 它只是一个多一点predictably慢。

StrictMode 的目的是指出哪里可能会出现低迷。它是由你来决定哪些是良性的，哪些不是。在一个理想的世界，你会收拾他们所有;在一个理想的世界，我有头发。

或者是一件坏事，而一半的Andr​​oid开发团队和Android书的作者忘了这一点？

这一直是一个不好的事情。

我不能说的半个Android开发团队。我presume的是，在早期，他们希望开发人员能够利用他们现有的开发技术来检测低迷的行为 - 这是不是比在其他任何平台上的性能问题显著不同。随着时间的推移，他们已经提供了更多的模式来引导在积极的开发路径（例如，装载机框架），除了系统级的变化（例如，YAFFS2-> EXT4），以使一个问题的这一小。在某种程度上，他们正在试图解决的地方，Android的推出独特的性能相关的挑战，比如单线程UI。

同样，我不能代表所有的Andr​​oid书的作者。我当然没有专注于性能问题，在我的书的早期版本，因为我是专注于Android的特性和功能。随着时间的推移，我在这些方面增加了更多的建议。我也贡献开源$ C ​​$ C与这些主题相关。 2012年，我会做大量的修改，以我的书，并创造更多的开源项目，继续解决这些问题。我怀疑，给你的口气，我（也可能是其他人）都在你的眼睛完全失败在这方面，你肯定是欢迎你的意见。

I'm trying to follow Android best practices, so in debug mode I turn all the following on:

StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder().detectAll().penaltyLog().build()); //detect and log all thread violations
StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder().detectAll().penaltyLog().build()); //detect and log all virtual machine violations

Android now yells at me when I try to use any sort of file access or SQL in the main (UI) thread. But I see so many recommendations to use file access and/or SQL in the main thread. For example, the main activity should load default preference values inside onCreate() in case they haven't been set yet:

PreferenceManager.setDefaultValues(context, resId, readAgain);

Oops---that results in a file access on the first application execution, because onCreate() is called on the UI thread. The only way around it I can see is to start a separate thread---which introduces a race condition with other UI code that might read the preferences and expect the default values to already be set.

Think also of services such as the DownloadManager. (Actually, it's so buggy that it's useless in real life, but let's pretend it works for a second.) If you queue up a download, you get an event (on the main thread) telling you a download has finished. To actually get information about that download (it only gives you a download ID), you have to query the DownloadManager---which involves a cursor, giving you an error if you have a strict policy turned on.

So what's the story---is it fine to access cursors in the main thread? Or is it a bad thing, and half the Android development team and Android book authors forgot about that?

The only way around it I can see is to start a separate thread---which introduces a race condition with other UI code that might read the preferences and expect the default values to already be set.

Then use an AsyncTask, putting the setDefaultValues() call in doInBackground() and the "other UI code that might read the preferences" in onPostExecute().

To actually get information about that download (it only gives you a download ID), you have to query the DownloadManager---which involves a cursor, giving you an error if you have a strict policy turned on.

So query the DownloadManager in a background thread.

So what's the story---is it fine to access cursors in the main thread?

That depends on your definition of "fine".

On Android 1.x and most 2.x devices, the filesystem used is YAFFS2, which basically serializes all disk access across all processes. The net effect is that while your code may appear sufficiently performant in isolation, it appears sluggish at times in production because of other things going on in the background (e.g., downloading new email).

While this is a bit less of an issue in Android 3.x and above (they switched to ext4), there's no question that flash I/O is still relatively slow -- it will just be a bit more predictably slow.

StrictMode is designed to point out where sluggishness may occur. It is up to you to determine which are benign and which are not. In an ideal world, you'd clean up them all; in an ideal world, I'd have hair.

Or is it a bad thing, and half the Android development team and Android book authors forgot about that?

It's always been a "bad thing".

I cannot speak for "half the Android development team". I presume that, early on, they expected developers to apply their existing development expertise to detect sluggish behavior -- this is not significantly different than performance issues in any other platform. Over time, they have been offering more patterns to steer developers in a positive path (e.g., the Loader framework), in addition to system-level changes (e.g., YAFFS2->ext4) to make this less of a problem. In part, they are trying to address places where Android introduces distinct performance-related challenges, such as the single-threaded UI.

Similarly, I cannot speak for all Android book authors. I certainly didn't focus on performance issues in early editions of my books, as I was focusing on Android features and functions. Over time, I have added more advice in these areas. I have also contributed open source code related to these topics. In 2012, I'll be making massive revisions to my books, and creating more open source projects, to continue addressing these issues. I suspect, given your tone, that I (and probably others) are complete failures in your eyes in this regard, and you are certainly welcome to your opinion.