在Android主UI线程中SQL或一般文件访问是否合适？

概述我正在尝试遵循 Android最佳做法,因此在调试模式下,我将打开以下所有内容： StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder().detectAll().penaltyLog().build()); //detect and log all thread violationsStrictMode.setVmPoli 我正在尝试遵循 Android最佳做法,因此在调试模式下,我将打开以下所有内容：

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

当我尝试在主(UI)线程中使用任何类型的文件访问或sql时,AndroID现在对我大喊大叫.但我看到很多建议在主线程中使用文件访问和/或sql.例如,主活动应该在onCreate()内加载默认首选项值,以防它们尚未设置：

PreferenceManager.setDefaultValues(context,resID,readAgain);

糟糕 – 导致第一次应用程序执行时访问文件,因为在UI线程上调用了onCreate().我能看到的唯一方法是启动一个单独的线程—它引入了一个竞争条件和其他可能读取偏好的UI代码,并期望已经设置了默认值.

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

那么故事是什么 – 在主线程中访问游标是否可以？或者这是一件坏事,AndroID开发团队和AndroID书籍作者中有一半忘记了这一点？

解决方法

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,将doDeBaultground()中的setDefaultValues()调用和onPostExecute()中的“可能读取首选项的其他UI代码”放在一起.

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年,我将对我的书籍进行大规模修改,并创建更多的开源项目,以继续解决这些问题.我怀疑,鉴于你的语气,我(以及可能是其他人)在这方面完全失败了,你当然欢迎你的意见.

总结

以上是内存溢出为你收集整理的在Android主UI线程中SQL或一般文件访问是否合适？全部内容，希望文章能够帮你解决在Android主UI线程中SQL或一般文件访问是否合适？所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。