android - 是 DB-Activity 架构和/或上下文泄漏的 ContentProvider 解决方案吗

Question

当使用大型数据库时，在我的情况下，大约有 20 个 DataSource 定义（每个 DS 2-5 个表，存储在同一个 SQLiteDatabase 中），很少出现问题

例如：

线程同步（ReentrantLock、同步锁）
SQLiteOpenHelper子类的Singleton ( 1 , 2 ) 模式
SQLiteOpenHelper和/或 DataSources 的单例上可能的上下文泄漏
- 或者如果使用应用程序的 Context ( Context.getApplicationContext())则使用大内存堆

尽管我知道，在不将应用程序的数据暴露给其他服务/应用程序（ 1、2 ）时，没有必要使用 ContentProviders ，但我认为它解决了上述大多数问题，并允许/推动实现有趣的功能，例如广播或使用访问数据的游标。

这只是对 ContentProvider 模式的误解，还是真的很复杂地解决了可能的问题，而不仅仅是提到的问题？

score 2 · Accepted Answer

ContentProvider 实现可能需要编写大量样板代码，这就是我开发 Mechanoid DB 的原因。如果您计划实现一个支持 sqlite 的内容提供程序，它可能会让您的生活更轻松。

score 1 · Accepted Answer

鉴于最近弃用了startmanagingcursor，以及您可以从文档以及几本书（包括 reto meyer 的书）中阅读的内容，contentprovider 似乎是克服一系列问题的建议方法，包括您列出的问题。

即使官方文档声明如果您不打算与其他应用程序共享数据，您不需要开发自己的提供程序，但很明显基于加载器的方法得到了强烈的宣传，并且让您不必担心您遇到的问题只是提到了，更不用说每当您的数据更改时可以自动通知加载程序。

另请注意，您可以向外界隐藏您的内容提供者

android:exported="false"

在任何情况下，线程同步都不应该担心，因为 sqllite 调用是线程安全的（据我所知）。

我也同意编写内容提供程序包含很多样板代码，这就是为什么我编写了一个脚本来为我编写它:-)。如果你有兴趣，你可以在这里查看，但也要考虑在谷歌上寻找“内容提供者生成器”会返回一些不错的选择，如果不是更好的选择的话。

2 回答 2