在Android上保存本地数据有三种方式，SharedPreferences、Files和Sqlite。SharedPreferences主要是用来保存键值对形式的程序配置信息，与ini、properties操作类似。Files主要是用来保存图片、音视频等二进制数据。Sqlite是一种轻量级的关系型数据库，运行在android系统中为应用程序提供按照表结构存储数据的功能。Sqlite并不想与传统的大型的关系型数据库竞争，它的目标很明确，在硬件资源有限的情况下，为应用程序提供基本的数据库操作功能。因此，Sqlite在嵌入式系统、智能移动设备上广泛应用。同样，因为轻量的原因，Sqlite在处理并发性的能力上比起大型的数据库就要欠缺很多。这个问题不是Sqlite的缺陷而是它的特点，作为开发人员需要掌握它。Sqlite提供的是文件锁，即在同一时间内，只能有一个程序对它进行写操作，可以有多个程序对它进行读操作。这对于在嵌入式系统中运行的程序来说，应该足够了，并且程序的结构也可以很清晰，实现一个全局的写操作连接由整个程序共享，并且通过代码控制其并发操作，同时允许多个读操作连接并发执行。但是这种想法在Android上完全是错误的。

　　在Android的官网上有一个操作Sqlite的例子，正因为是官方发布的例子，那么可以想象有多少开发人员会在实际的项目中用到它。

public class FeedReaderDbHelper extends SQLiteOpenHelper {
    // If you change the database schema, you must increment the database version.
    public static final int DATABASE_VERSION = 1;
    public static final String DATABASE_NAME = "FeedReader.db";

    public FeedReaderDbHelper(Context context) {
        super(context, DATABASE_NAME, null, DATABASE_VERSION);
    }
    public void onCreate(SQLiteDatabase db) {
        db.execSQL(SQL_CREATE_ENTRIES);
    }
    public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) {
        // This database is only a cache for online data, so its upgrade policy is
        // to simply to discard the data and start over
        db.execSQL(SQL_DELETE_ENTRIES);
        onCreate(db);
    }
    public void onDowngrade(SQLiteDatabase db, int oldVersion, int newVersion) {
        onUpgrade(db, oldVersion, newVersion);
    }
}

　　Google为Android开发出了一个SQLiteOpenHelper来管理Sqlite，包括创建数据库文件、创建表和数据库更新。在使用Sqlite时，程序实例化SQLiteOpenHelper的子类，然后再进行相关操作。

FeedReaderDbHelper mDbHelper = new FeedReaderDbHelper(getContext());

SQLiteDatabase db = mDbHelper.getWritableDatabase();

// Create a new map of values, where column names are the keys
ContentValues values = new ContentValues();
values.put(FeedEntry.COLUMN_NAME_ENTRY_ID, id);
values.put(FeedEntry.COLUMN_NAME_TITLE, title);
values.put(FeedEntry.COLUMN_NAME_CONTENT, content);

// Insert the new row, returning the primary key value of the new row
long newRowId;
newRowId = db.insert(
         FeedEntry.TABLE_NAME,
         FeedEntry.COLUMN_NAME_NULLABLE,
         values);

　　以上代码的标题赫然写着：Put Information into a Database。紧接着，下面代码的标题是：Read Information from a Database。

SQLiteDatabase db = mDbHelper.getReadableDatabase();

// Define a projection that specifies which columns from the database
// you will actually use after this query.
String[] projection = {
    FeedEntry._ID,
    FeedEntry.COLUMN_NAME_TITLE,
    FeedEntry.COLUMN_NAME_UPDATED,
    ...
    };

// How you want the results sorted in the resulting Cursor
String sortOrder =
    FeedEntry.COLUMN_NAME_UPDATED + " DESC";

Cursor c = db.query(
    FeedEntry.TABLE_NAME,  // The table to query
    projection,                               // The columns to return
    selection,                                // The columns for the WHERE clause
    selectionArgs,                            // The values for the WHERE clause
    null,                                     // don't group the rows
    null,                                     // don't filter by row groups
    sortOrder                                 // The sort order
    );

　　看到这里，自信的开发人员可能已经感到在Android上操作Sqlite已经没有问题了，一个getWritableDatabase()和一个getReadableDatabase()。再加上Sqlite文件锁这个特点，那么程序理所当然是将所有涉及写操作的函数用synchronized保护起来，而读操作可以任意执行，强大的Google已经分离了WritableDatabase和ReadableDatabase。但事实并非如此，官网上的这个例子以及这些API的命名产生了很大的混淆。Kevin Galligan在他的博客《Android Sqlite Locking》中讨论过这个问题，并专门写了一个测试程序证明多线程操作Sqlite时会导致数据库操作失败。为了突出问题便于测试，在该测试程序的基础上做了一些修改以表明：在正常情况下，同一个SQLiteOpenHelper的getWritableDatabase()和一个getReadableDatabase()返回的是同一个SQLiteDatabase并且是线程安全的。因此，数据库操作会串行执行，而并不能实现一个写、多个读的结构。下面代码故意使用getReadableDatabase()实现写操作，getWritableDatabase()实现读操作，同时在LogCat中打印出不同线程中SQLiteDatabase对象的Hash Code。

public void insert(String desc) {
        SQLiteDatabase readableDatabase = getReadableDatabase();
        Log.i(Thread.currentThread().toString(), "insert: " + readableDatabase.hashCode());
        
        ContentValues contentValues = new ContentValues();
        contentValues.put("description", desc);
        readableDatabase.insertOrThrow("session", null, contentValues);
    }

    public int count() {
        SQLiteDatabase writableDatabase = getWritableDatabase();
        Log.i(Thread.currentThread().toString(), "count: " + writableDatabase.hashCode());
        
        Cursor cursor = writableDatabase.rawQuery(
                "select count(*) from session", null);
        cursor.moveToFirst();
        return cursor.getInt(0);
    }

　　通过上面的测试可以看到，一个SQLiteOpenHelper实际代表着一个数据库连接，对于一个数据库（在Sqlite中相当于一个.db文件）同时只能建立一个连接执行数据库操作，所以在程序中操作同一个数据库时SQLiteOpenHelper应该是唯一的，SQLiteDatabase对象可以有多个，并且能在多线程中执行操作。在Android自带的Samples里有一个Notepad例子，它采用了ContentProvider作为操作Sqlite的接口。这种方式就是让系统初始化一个SQLiteOpenHelper对象，供其它程序使用。它有一个明显的缺陷，针对每个表都需要实现一个专门的ContentProvider从而使得表间操作相当繁琐。

　　OrmLite这个持久层的框架解决了上述问题。在OrmLite里是使用OpenHelperManager来管理SQLiteOpenHelper，通过查看源代码可以看到OpenHelperManager使用了单例模式来确保SQLiteOpenHelper的唯一性。在下面的工厂方法中有两个小技巧：第一，Context实际上是获取的整个应用程序的上下文；第二，设置了一个引用计数器，instanceCount，确保程序通过releaseHelper()能够正确关闭SQLiteOpenHelper。

private static <T extends OrmLiteSqliteOpenHelper> T loadHelper(Context context, Class<T> openHelperClass) {
        if (helper == null) {
            if (wasClosed) {
                logger.info("helper was already closed and is being re-opened");
            }
            if (context == null) {
                throw new IllegalArgumentException("context argument is null");
            }
            Context appContext = context.getApplicationContext();
            helper = constructHelper(appContext, helperClass);
            logger.trace("zero instances, created helper {}", helper);
            DaoManager.clearDaoCache();
            instanceCount = 0;
        }

        instanceCount++;
        logger.trace("returning helper {}, instance count = {} ", helper, instanceCount);
        @SuppressWarnings("unchecked")
        T castHelper = (T) helper;
        return castHelper;
    }