android - SQL 或一般文件访问是否适用于 Android 主 UI 线程？

Question

我正在尝试遵循 Android 最佳实践，因此在 Debug模式下我打开了以下所有内容:

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

当我尝试在主 (UI) 线程中使用任何类型的文件访问或 SQL 时，Android 现在会对我大喊大叫。但是我看到很多建议在主线程中使用文件访问和/或 SQL。例如，主 Activity 应在 onCreate() 中加载默认首选项值，以防它们尚未设置:

PreferenceManager.setDefaultValues(context, resId, readAgain);

糟糕 --- 这会导致在第一次执行应用程序时访问文件，因为在 UI 线程上调用了 onCreate()。我能看到的唯一绕过它的方法是启动一个单独的线程——这会引入与其他 UI 代码的竞争条件，这些代码可能会读取首选项并期望已经设置默认值。

还可以考虑 DownloadManager 等服务。 (实际上，它有很多错误，在现实生活中毫无用处，但让我们假装它能工作一秒钟。)如果你排队下载，你会得到一个事件(在主线程上)告诉你下载已经完成。要实际获取有关该下载的信息(它只会为您提供下载 ID)，您必须查询 DownloadManager --- 它涉及一个游标，如果您启用了严格的策略，则会给您一个错误。

那么到底是怎么回事——在主线程中访问游标可以吗？或者这是一件坏事，一半的 Android 开发团队和 Android 书籍作者忘记了这一点？

Answer 1

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.

然后使用 AsyncTask，将 setDefaultValues() 调用放入 doInBackground() 和“可能读取首选项的其他 UI 代码” "在 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.

因此在后台线程中查询DownloadManager。

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

这取决于你对“好”的定义。

在 Android 1.x 和大多数 2.x 设备上，使用的文件系统是 YAFFS2，它基本上序列化所有进程中的所有磁盘访问。最终结果是，虽然您的代码在单独情况下可能表现出足够的性能，但由于后台发生的其他事情(例如，下载新电子邮件)，它有时在生产中显得迟缓。

虽然这在 Android 3.x 及更高版本(他们切换到 ext4)中不是什么大问题，但毫无疑问，闪存 I/O 仍然相对较慢——它只是会更慢一些，这是可以预见的。

StrictMode 旨在指出可能出现迟缓的位置。由您决定哪些是良性的，哪些不是。在一个理想的世界里，你会把它们全部清理干净；在理想的世界里，我会有头发。

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

一直都是“坏事”。

我不能代表“一半的 Android 开发团队”。我推测，在早期，他们希望开发人员应用他们现有的开发专业知识来检测迟缓行为——这与任何其他平台中的性能问题没有太大区别。随着时间的推移，除了系统级更改(例如 YAFFS2->ext4)以减少这种情况外，他们还提供了更多模式来引导开发人员走上积极的道路(例如 Loader 框架)的一个问题。在某种程度上，他们正试图解决 Android 引入明显的性能相关挑战的问题，例如单线程 UI。

同样，我不能代表所有 Android 图书作者。在我的书的早期版本中，我当然没有关注性能问题，因为我关注的是 Android 特性和功能。随着时间的推移，我在这些方面增加了更多建议。我还贡献了与这些主题相关的开源代码。 2012 年，我将对我的书籍进行大量修订，并创建更多开源项目，以继续解决这些问题。从你的语气来看，我怀疑我(可能还有其他人)在你眼中在这方面完全失败了，当然欢迎你发表意见。