Android 应用程序中的所有 Activity 共享一个 SQLiteOpenHelper 实例是否可以？

Question

将 SQLiteOpenHelper 的单个实例作为子类应用程序的成员，并且让所有需要 SQLiteDatabase 实例的活动从一个帮助器获取它是否可以？

Answer 1

单击此处查看我关于此主题的博客文章。

---

CommonsWare 正常运行（像往常一样）。扩展他的帖子，这里有一些示例代码，说明了三种可能的方法。这些将允许在整个应用程序中访问数据库。

方法#1：子类化“Application”

如果您知道您的应用程序不会很复杂（即，如果您知道最终只会有一个 Application 的子类），那么您可以创建一个子类Application 并让您的主 Activity 扩展它。这可确保数据库的一个实例在应用程序的整个生命周期中运行。

public class MainApplication extends Application {

    /**
     * see NotePad tutorial for an example implementation of DataDbAdapter
     */
    private static DataDbAdapter mDbHelper;

    /**
     * Called when the application is starting, before any other 
     * application objects have been created. Implementations 
     * should be as quick as possible...
     */
    @Override
    public void onCreate() {
        super.onCreate();
        mDbHelper = new DataDbAdapter(this);
        mDbHelper.open();
    }

    public static DataDbAdapter getDatabaseHelper() {
        return mDbHelper;
    }
}

方法 #2：让 `SQLiteOpenHelper` 成为静态数据成员

这不是完整的实现，但它应该可以让您了解如何正确设计 DatabaseHelper 类。静态工厂方法确保任何时候都只存在一个DatabaseHelper实例。

/**
 * create custom DatabaseHelper class that extends SQLiteOpenHelper
 */
public class DatabaseHelper extends SQLiteOpenHelper { 
    private static DatabaseHelper mInstance = null;

    private static final String DATABASE_NAME = "databaseName";
    private static final String DATABASE_TABLE = "tableName";
    private static final int DATABASE_VERSION = 1;

    private Context mCxt;

    public static DatabaseHelper getInstance(Context ctx) {
        /** 
         * use the application context as suggested by CommonsWare.
         * this will ensure that you dont accidentally leak an Activitys
         * context (see this article for more information: 
         * http://developer.android.com/resources/articles/avoiding-memory-leaks.html)
         */
        if (mInstance == null) {
            mInstance = new DatabaseHelper(ctx.getApplicationContext());
        }
        return mInstance;
    }

    /**
     * constructor should be private to prevent direct instantiation.
     * make call to static factory method "getInstance()" instead.
     */
    private DatabaseHelper(Context ctx) {
        super(context, DATABASE_NAME, null, DATABASE_VERSION);
        this.mCtx = ctx;
    }
}

方法#3：使用“ContentProvider”抽象 SQLite 数据库

这是我建议的方法。首先，新的 LoaderManager 类严重依赖于 ContentProviders，因此如果您希望 Activity 或 Fragment 实现 LoaderManager.LoaderCallbacks（我建议您利用，这太神奇了！），您需要为您的应用程序实现一个 ContentProvider。此外，您无需担心使用 ContentProviders 创建 Singleton 数据库助手。只需从 Activity 中调用 getContentResolver() ，系统就会为您处理好一切（换句话说，无需设计 Singleton 模式来防止创建多个实例）。

希望有帮助！

Answer 2

拥有一个SQLiteOpenHelper实例可以在线程情况下有所帮助。由于所有线程将共享公共SQLiteDatabase，因此提供了操作同步。

但是，我不会创建 Application 的子类。只需有一个静态数据成员，即 SQLiteOpenHelper。这两种方法都可以让您从任何地方访问。但是，Application 只有一个子类，这使得您使用Application的其他子类变得更加困难（例如，GreenDroid 需要一个 IIRC）。使用静态数据成员可以避免这种情况。但是，在实例化此静态 SQLiteOpenHelper（构造函数参数）时，请务必使用 Application Context，这样就不会泄漏其他 Context< /代码>。

而且，如果您不处理多个线程，您只需为每个组件使用一个 SQLiteOpenHelper 实例即可避免任何可能的内存泄漏问题。然而，在实践中，您应该处理多个线程（例如，Loader），因此此建议仅与琐碎的应用程序相关，例如在某些书籍中找到的应用程序...:-)

Answer 3

我编写了 MultiThreadSQLiteOpenHelper，它是一个针对 Android 应用程序的增强型 SQLiteOpenHelper，其中多个线程可能会打开和关闭同一个 sqlite 数据库。

线程不调用 close 方法，而是请求关闭数据库，从而防止线程对已关闭的数据库执行查询。

如果每个线程都要求关闭，则实际执行关闭。每个活动或线程（ui 线程和用户线程）在恢复时对数据库执行打开调用，并在暂停或完成时请求关闭数据库。

源代码和示例可在此处获取：
https://github.com/d4rxh4wx/MultiThreadSQLiteOpenHelper

Answer 4

我对这个主题做了很多研究，我同意 commonware 提到的所有观点。但我认为这里每个人都忽略了重要的一点，这个问题的答案完全取决于您的用例，因此如果您的应用程序通过多线程读取数据库并且仅使用 Singleton 读取具有巨大的性能由于与数据库有一个连接，所有函数都同步并串行执行，因此命中
顺便说一句，开源很棒。您可以直接深入研究代码并查看发生了什么。从这一点和一些测试中，我了解到以下事实是正确的：

Sqlite takes care of the file level locking.  Many threads can read, one can write.  The locks prevent more than one writing.
Android implements some java locking in SQLiteDatabase to help keep things straight.
If you go crazy and hammer the database from many threads, your database will (or should) not be corrupted.

如果您尝试同时从实际不同的连接写入数据库，则会失败。它不会等到第一个完成后再写入。它根本不会写入您的更改。更糟糕的是，如果您没有在 SQLiteDatabase 上调用正确版本的插入/更新，则不会出现异常。您只会在 LogCat 中收到一条消息，仅此而已。

第一个问题，真实的、独特的联系。开源代码的伟大之处在于您可以直接挖掘并查看正在发生的事情。 SQLiteOpenHelper 类做了一些有趣的事情。尽管有一种方法可以获取只读数据库连接和读写连接，但在幕后，它始终是相同的连接。假设没有文件写入错误，即使只读连接实际上也是单个读写连接。很有趣。因此，如果您在应用程序中使用一个辅助实例，即使是在多个线程中，您也永远不会真正使用多个连接。

此外，SQLiteDatabase 类（其中每个帮助程序只有一个实例）本身实现了 Java 级别锁定。因此，当您实际执行数据库操作时，所有其他数据库操作都将被锁定。因此，即使您有多个线程在做事情，如果您这样做是为了最大限度地提高数据库性能，我也有一些坏消息要告诉您。没有任何好处。

有趣的观察

如果你关闭一个写入线程，那么只有一个线程正在写入数据库，但另一个线程正在读取，并且两者都有自己的连接，读取性能会大幅提高，我不知道没有看到任何锁定问题。这是值得追求的事情。我还没有尝试过写批处理。

如果您要执行多次任何类型的更新，请将其包装在事务中。看起来我在事务中执行的 50 次更新与事务外的 1 次更新花费的时间相同。我的猜测是，在事务调用之外，每次更新都会尝试将数据库更改写入磁盘。在事务内部，写入是在一个块中完成的，写入的开销使更新逻辑本身相形见绌。

Answer 5

是的，这就是您应该采取的方式，为需要数据库实例的活动提供一个帮助程序类。