安卓ContentProvider性能

Question

我想知道是否有人对通过ContentResolver查询ContentProvider和在同一进程中查询SQLiteDatabase对象进行了性能测试。 我猜测通过ContentResolver查询会返回一个与数据库通过Binder（Android IPC）通信的Cursor。这意味着，如果我通过Cursor读取100条记录的内容，那么将会有100次Binder方法调用。我的猜测正确吗？ 如果是，那么相比于在同一进程中访问数据库，这样做会慢得多吗？

- satur9nine

---

顺便提一下，我在一台800MHz的Android设备上进行了测试，比较了调用本地方法和调用远程方法。使用一个简单的26个字符的字符串参数调用远程方法比调用本地方法多花费了大约400纳秒的时间。发送一个10,000个字符的字符串参数需要多花费2.3毫秒的时间。显然，发送（或接收）的数据越多，所需的时间就越长。 - satur9nine

我学到的一些东西：通过ContentProviders传递的光标包含一个CursorWindow，CursorWindow是一个缓存区域，大小为2MB，大多数查询都适合于整个缓冲区。因此，通常从光标访问数据不会启动Binder方法调用，因为所有数据已经存在其中。然而，如果您尝试在巨大的光标之外读取数据，则Window将需要移动并且缓存将通过Binder重新发送。 - satur9nine

Answer 1

我没有做过完全相同的测试。我的测试是通过ContentProvider或直接通过SQLite数据库插入多个数据来测试性能。

我逐个插入了大约1000个数据项。通过ContentProvider插入的速度要慢得多。在我的测试中，几乎慢了10%。

- Fernwilter

---

如果您要逐个插入1000个项目，则应使用“ContentProviderOperation”并执行“batchInsert”。无论您使用什么，逐个插入1000个项目都将非常缓慢，因此我不会过多关注这个基准测试。根据我的经验，“使用ContentProvider”和“不使用ContentProvider”的区别从未归结为执行操作的速度/效率。 - Alex Lockwood

根据使用情况而定。如果我需要在不到100毫秒的时间内获取某些特定信息（例如UI主题），ContentProvider就不太适用了。 - 3c71

Answer 2

没有确定的答案，结果取决于您做什么以及如何做。

例如，我想在应用程序之间共享首选项，因此ContentProvider似乎是完美的答案。是的，如果我不介意第一次读取时需要更长的延迟，因为连接到ContentProvider这个过程在S10+上需要120ms！

因此，如果您的UI依赖于这些设置，则最好在应用程序之间复制首选项文件（使用ContentProvider），然后直接从文件中读取，否则在显示适当的主题之前，UI将被延迟。事实上，onStart()方法已经被调用了。

相反，进行DB操作（如果正确执行）不会改变结果太多，除非您需要频繁重新连接，这会增加显著的开销。

- 3c71