从Room源码看抽象与封装——SQLite的抽象

2019-06-30 本文已影响0人珞泽珈群

前言

什么是Room？Room是Android Jetpack包的一部分，为应用提供数据库支持。

The Room persistence library provides an abstraction layer over SQLite to allow for more robust database access while harnessing the full power of SQLite.

Room持久性库提供了一个基于SQLite的抽象层，以便在利用SQLite的全部功能的同时，实现更强大的数据库访问能力。

如官方定义所说，Room是对SQLite的抽象，让我们可以更加方便且安全地使用SQLite数据库。
抽象与封装可以说是软件开发的灵魂，由此也诞生出了非常多的理论来指导我们的实践，譬如，设计原则和设计模式。诸多大神们为提升开发效率，构建健壮、可维护的代码以及保住大家的发量可谓操碎了心，奈何，我们也是力不从心啊，有时候，我们也意识到了应该对某些代码进行良好的抽象与封装，但是，臣妾做不到啊。在这一点上，Room提供了良好的范本，首先，数据库之于应用还是非常常见的需求，大家对此也不陌生。其次，Room对于SQLite的抽象也不算复杂，具有非常好的学习价值。本文从源码出发，来看看Room是如何对SQLite进行抽象与封装的。（源码版本androidx.room:room-runtime:2.1.0）

1. SQLite的基本使用

今时不同往日，在Android平台上直接使用SQLite的情况越来越少了，我们一般都会使用各种ORM框架来帮助我们完成数据库的操作，以至于现在让我不用ORM框架，我都不知道Android平台原生的SQLite是如何操作的。但是，要想知道Room是如何封装SQLite的，就必须了解SQLite原来是怎么使用的。好歹，这一切并不复杂。不复杂，我们就直接看代码。

//表名、列名
const val TABLE_NAME = "entry"
const val COLUMN_NAME_ID = "id"
const val COLUMN_NAME_TITLE = "title"
const val COLUMN_NAME_SUBTITLE = "subtitle"

//建表 SQL，是不是很容易犯错，如果使用Java就更容易犯错了
//即使你说这些我信手拈来，但是依然很繁琐
private const val SQL_CREATE_ENTRIES =
        "CREATE TABLE $TABLE_NAME (" +
                "$ID INTEGER PRIMARY KEY," +
                "$COLUMN_NAME_TITLE TEXT," +
                "$COLUMN_NAME_SUBTITLE TEXT)"

class ReaderDbHelper(context: Context) : SQLiteOpenHelper(context, DATABASE_NAME, null, DATABASE_VERSION) {
    companion object {
        const val DATABASE_VERSION = 1
        const val DATABASE_NAME = "FeedReader.db"
    }
    
    override fun onCreate(db: SQLiteDatabase) {
        db.execSQL(SQL_CREATE_ENTRIES)
    }
    
    override fun onUpgrade(db: SQLiteDatabase, oldVersion: Int, newVersion: Int) {
        //根据oldVersion和newVersion编写相应的SQL语句对数据库进行升级
        //在实际应用中，这是比较难处理的一部分，因为缺少必要的验证，极容易出错
    }
    
    //基类中包含了两个重要的方法 getWritableDatabase() 和 getReadableDatabase()
    //这是我们操作数据库的入口
}

以上就是SQLite的基本使用方式，首先要继承SQLiteOpenHelper类，SQLiteOpenHelper包含了操作数据库的一系列API，是Android平台对SQLite的原生封装；其次就是在SQLiteOpenHelper的onCreate和onUpgrade方法中通过SQL语句来建表和升级数据库；最后通过getWritableDatabase 或者 getReadableDatabase对数据库进行增删改查（CRUD）。增删改查都有对应的方法，分别是insert、delete、update和query，其使用都是一些套路似的步骤，在此略过。
使用SQLiteOpenHelper的方式来操作数据库有诸多的问题：

极容易在主线程对数据库进行操作。无论是getWritableDatabase()抑或是增删改查等方法的调用，都应该放在子线程中，但是，由于没有什么方法来阻止我们这么做，所以你不自觉的就会在主线程中这么干。法无禁止皆可为，不抛出来个异常，你是不会在意的。
SQL语句的正确性及安全性都没有保证，问题被延迟到了运行时才能被发现。
从数据库数据到我们所需要的类数据之间的转换繁琐不堪，这也是ORM（Object Relational Mapping，对象关系映射）框架的意义所在。
升（降）级数据库缺乏必要验证，极容易出错。导致的结果就是，有时候为了避免数据库升级，甚至在建表的时候增加诸多冗余字段，丑陋不堪。

2. Room的基本使用

简单介绍一下Room的基本使用方式。Room的使用基本上就是加各种各样的注解。
数据库表用@Entity注解，表中的其它信息有各种各样的注解，最主要的两个注解是@PrimaryKey和@ColumnInfo，这两个注解的作用也是一目了然：

@Entity
data class User(
    //PrimaryKey包含一个autoGenerate属性，默认false，设置为true表示自增
    @PrimaryKey val uid: Int,
    //如果全部使用ColumnInfo的默认设置，@ColumnInfo注解可以省略
    @ColumnInfo val firstName: String?,
    //最主要的可以修改属性是 列名
    @ColumnInfo(name = "last_name") val lastName: String?
)

数据库操作用@Dao注解，CRUD有各自的注解：

@Dao
interface UserDao {
    @Query("SELECT * FROM user")
    fun getAll(): List<User>

    //参数可以用 :参数 这种形式获取
    @Query("SELECT * FROM user WHERE uid IN (:userIds)")
    fun loadAllByIds(userIds: IntArray): List<User>
    
    @Query("SELECT * FROM user WHERE uid = :userId")
    fun getUserById(userId: Int): User?

    @Query("SELECT * FROM user WHERE firstName LIKE :first AND " +
           "lastName LIKE :last LIMIT 1")
    fun findByName(first: String, last: String): User?

    @Insert
    fun insert(user: User)

    @Delete
    fun delete(user: User)
    
    @Update
    fun update(user: User)
}

多说一句，不要被SQL语句吓住，ORM框架的优劣与是否需要编写SQL语句没有直接关系。Room作为ORM框架的后起之秀，必然研究了之前种种ORM框架，最后选择了这种实现方式，这肯定是有它的道理的。退一步讲，我们平常应用中使用到的绝大部分SQL语句真的都非常简单。并且，Room还提供了良好的代码提示和编译时检查，写起来不费劲也不容易出错。

最后还少不了数据库本身，需要继承RoomDatabase并用@Database注解：

@Database(entities = [User::class], version = 1)
abstract class AppDatabase : RoomDatabase() {
    abstract fun userDao(): UserDao
}

//创建数据库，注意保持单例
val db = Room.databaseBuilder(
            applicationContext,
            AppDatabase::class.java, "database-name"
        ).build()
        
//使用时通过Dao来操作数据库
db.userDao().getAll()

以上是对Room最基本使用方法的介绍，更多内容可以查看官方文档。

3. 抽象从接口隔离开始

接口隔离是抽象的良好开端，对于复杂系统的抽象更是如此。接口隔离首先需要定义接口，定义接口的过程其实就是抽象的过程。接口中的方法是对职责的明晰，明确了我们需要暴露出哪些API，屏蔽掉哪些底层的细节；接口之间的关联是对被抽象系统关系的梳理，明确被抽象系统的关系有助于我们抽象出更加简洁、合理的关联系统。
是时候展现真正的技术了，以上所说其实可以概括为设计原则中的接口隔离原则（保持瘦接口）和依赖倒置原则（抽象不依赖于具体，具体依赖于抽象），还可以加上单一职责原则。

上文所说的接口隔离和接口隔离原则中的“接口隔离”不是同一个概念，我所表达的接口隔离的意思是，通过接口的方式来把抽象系统和被抽象系统隔离开来，使得我们的抽象系统建立在我们的抽象接口之上，不依赖与被抽象系统的具体细节。

3.1 SQL语句类的抽象

数据库增删改查四种基本操作其实可以分为两类，增删改是一类，查是一类。“增删改”可以返回哪一行受了影响或者总共多少行受影响之类的信息（int或long），而“查”则返回的是Cursor。如前所述，可以调用WritableDatabase的insert、delete和update方法分别进行增删改，这其实是Android对SQLite进行的基础封装，最终的实现都是通过一个叫SQLiteStatement类来完成的，SQLiteStatement顾名思义就是SQLite声明的意思，SQLiteStatement可以在数据库上执行，并且可以返回一个值（对应着增删改这种情形，这个值是row ID或者多少行受到了影响）。SQLiteStatement又继承自SQLiteProgram这个类，SQLiteProgram的主要作用是编译SQL语句，翻译成大白话就是对SQL语句中的占位符(?)进行bindNull,bindLong,bindString等绑定工作。

Room对增删改的支持也是通过SQLiteStatement。所以Room对SQLiteProgram和SQLiteStatement进行了封装，以一种几乎完全映射的方式定义了SupportSQLiteProgram和SupportSQLiteStatement两个接口。并且使用委托的形式又把相应的职责委托给了原本的SQLiteProgram和SQLiteStatement。

class FrameworkSQLiteProgram implements SupportSQLiteProgram {
    private final SQLiteProgram mDelegate;

    FrameworkSQLiteProgram(SQLiteProgram delegate) {
        mDelegate = delegate;
    }

    @Override
    public void bindNull(int index) {
        mDelegate.bindNull(index);
    }
    
    //其它方法省略，都只是简单的委托
}

class FrameworkSQLiteStatement extends FrameworkSQLiteProgram implements SupportSQLiteStatement {
    private final SQLiteStatement mDelegate;

    FrameworkSQLiteStatement(SQLiteStatement delegate) {
        super(delegate);
        mDelegate = delegate;
    }

    @Override
    public void execute() {
        mDelegate.execute();
    }

    //其它方法省略，都只是简单的委托
}

以上是Room对增删改SQL的抽象，还是非常接近于原生的SQLite的，这种抽象更多的是为了做隔离。

看完增删改，再来看看最重要的查询。其实查询SQL与增删改并没有太多不同，只是我们必须通过WritableDatabase/ReadableDatabase的query方法来执行，以便获取Cursor。Room将查询SQL抽象为了SupportSQLiteQuery：

public interface SupportSQLiteQuery {
    /**
     * 查询SQL语句，可以包含若干占位符(?)以便之后进行参数绑定
     */
    String getSql();

    /**
     * 参数绑定的回调，意思就是调用这个方法会把参数绑定到占位符(?)
     */
    void bindTo(SupportSQLiteProgram statement);

    /**
     * 查询SQL中有几个参数，也就是有几个占位符(?)
     */
    int getArgCount();
}

还包含一个简单的实现SimpleSQLiteQuery：

public final class SimpleSQLiteQuery implements SupportSQLiteQuery {
    private final String mQuery;
    @Nullable
    private final Object[] mBindArgs;

    public SimpleSQLiteQuery(String query, @Nullable Object[] bindArgs) {
        mQuery = query;
        mBindArgs = bindArgs;
    }

    public SimpleSQLiteQuery(String query) {
        this(query, null);
    }

    @Override
    public String getSql() {
        return mQuery;
    }

    @Override
    public void bindTo(SupportSQLiteProgram statement) {
        bind(statement, mBindArgs);
    }

    @Override
    public int getArgCount() {
        return mBindArgs == null ? 0 : mBindArgs.length;
    }

    public static void bind(SupportSQLiteProgram statement, Object[] bindArgs) {
        if (bindArgs == null) {
            return;
        }
        final int limit = bindArgs.length;
        for (int i = 0; i < limit; i++) {
            final Object arg = bindArgs[i];
            bind(statement, i + 1, arg);
        }
    }

    private static void bind(SupportSQLiteProgram statement, int index, Object arg) {
        // extracted from android.database.sqlite.SQLiteConnection
        if (arg == null) {
            statement.bindNull(index);
        } else if (arg instanceof byte[]) {
            statement.bindBlob(index, (byte[]) arg);
        } else if (arg instanceof Float) {
            statement.bindDouble(index, (Float) arg);
        } else if (arg instanceof Double) {
            statement.bindDouble(index, (Double) arg);
        } else if (arg instanceof Long) {
            statement.bindLong(index, (Long) arg);
        } else if (arg instanceof Integer) {
            statement.bindLong(index, (Integer) arg);
        } else if (arg instanceof Short) {
            statement.bindLong(index, (Short) arg);
        } else if (arg instanceof Byte) {
            statement.bindLong(index, (Byte) arg);
        } else if (arg instanceof String) {
            statement.bindString(index, (String) arg);
        } else if (arg instanceof Boolean) {
            statement.bindLong(index, ((Boolean) arg) ? 1 : 0);
        } else {
            throw new IllegalArgumentException("Cannot bind " + arg + " at index " + index
                    + " Supported types: null, byte[], float, double, long, int, short, byte,"
                    + " string");
        }
    }
}

真是什么都没干，只是简单的绑定了一下。

总结一下Room对于SQL语句类的抽象，概括起来就是映射SQLiteStatement的行为；将Query抽象为SQL语句和绑定，并且是延迟绑定，调用bindTo方法时才进行绑定（这么做是有它的意义的，后文会看到）。其实，SQL语句在执行之前仅仅是个语句而已，如果有占位符?，在执行之前都需要进行绑定，不分什么增删改查。但是由于我们想要获取的数据不同，这导致我们选择的执行方式不同，增删改、查两类不同的SQL对应着两种不同的执行方式，也对应着两种不同的抽象方式。

3.2 数据库的抽象

这里的数据库指的就是通过SQLiteOpenHelper的getWritableDatabase或者getReadableDatabase返回的数据库对象，它是一个SQLiteDatabase类的对象。
数据库的抽象分为两部分：

对于数据库本身的SQLiteDatabase的抽象。
对于数据库打开方式SQLiteOpenHelper的抽象。

3.2.1 SQLiteDatabase的抽象

Room对于SQLiteDatabase的抽象比较简单，几乎完全模仿了SQLiteDatabase的行为，只是在某些方法上做了一些“收紧”。

public interface SupportSQLiteDatabase extends Closeable {
    Cursor query(String query);

    Cursor query(String query, Object[] bindArgs);

    /**
     * Runs the given query on the database.
     * <p>
     * This class allows using type safe sql program bindings while running queries.
     *
     * 最主要的“收紧”体现在这个方法上，以“类型安全”的方式执行查询
     */
    Cursor query(SupportSQLiteQuery query);

    @RequiresApi(api = Build.VERSION_CODES.JELLY_BEAN)
    Cursor query(SupportSQLiteQuery query, CancellationSignal cancellationSignal);
    
    //其它方法省略
}


//SupportSQLiteDatabase的实现
class FrameworkSQLiteDatabase implements SupportSQLiteDatabase {
    private final SQLiteDatabase mDelegate;

    FrameworkSQLiteDatabase(SQLiteDatabase delegate) {
        mDelegate = delegate;
    }
    
    @Override
    public Cursor query(String query) {
        return query(new SimpleSQLiteQuery(query));
    }

    @Override
    public Cursor query(String query, Object[] bindArgs) {
        return query(new SimpleSQLiteQuery(query, bindArgs));
    }


    @Override
    public Cursor query(final SupportSQLiteQuery supportQuery) {
        //所有的查询都是以一致的方式进行的，使用SQLiteDatabase比较底层的方法 rawQueryWithFactory
        return mDelegate.rawQueryWithFactory(new SQLiteDatabase.CursorFactory() {
            @Override
            public Cursor newCursor(SQLiteDatabase db, SQLiteCursorDriver masterQuery,
                    String editTable, SQLiteQuery query) {
                //这里面的具体逻辑之后再解释，虽说就两行，但是体现的东西还是很多的
                supportQuery.bindTo(new FrameworkSQLiteProgram(query));
                return new SQLiteCursor(masterQuery, editTable, query);
            }
        }, supportQuery.getSql(), EMPTY_STRING_ARRAY, null);
    }

    @Override
    @androidx.annotation.RequiresApi(api = Build.VERSION_CODES.JELLY_BEAN)
    public Cursor query(final SupportSQLiteQuery supportQuery,
            CancellationSignal cancellationSignal) {
        return mDelegate.rawQueryWithFactory(new SQLiteDatabase.CursorFactory() {
            @Override
            public Cursor newCursor(SQLiteDatabase db, SQLiteCursorDriver masterQuery,
                    String editTable, SQLiteQuery query) {
                supportQuery.bindTo(new FrameworkSQLiteProgram(query));
                return new SQLiteCursor(masterQuery, editTable, query);
            }
        }, supportQuery.getSql(), EMPTY_STRING_ARRAY, null, cancellationSignal);
    }

    //其它方法的实现几乎都是简单的委托
}

SupportSQLiteDatabase最主要的“收紧”体现在query方法上。SQLiteDatabase上的query方法的重载有很多个，虽然给了你很多种方式，但是我们依然不喜欢使用，主要原因在于这些方法要传的参数实在是太多了，最少的一个重载方法要传7个参数，多的要传9个参数，这并不是说Android对于SQLite的封装有问题，问题在于如果你不想写查询SQL语句的话，就只能通过这种方式来帮你拼接出来真正的SQL语句，而查询SQL包含的情况实在是太多了，必须需要这么多参数才能明确。
说了这么多，原来是怪我喽，那我写SQL还不行吗？！嗯，其实，也不太行。

大兄弟，不要急，这就叫按下葫芦起了瓢。
想使用查询SQL语句，SQLiteDatabase提供了rawQuery(String sql, String[] selectionArgs)方法，很明显需要我们提供查询SQL语句（可以包含占位符?）以及顶替占位符的参数。这就会有如下问题：

SQL语句的正确性无从保证，只有到运行时才能检验，哪怕你只是手误敲错了一个字符，也只能等到运行时抛出异常才能发现，实在是不友好。
稍微复杂一点的查询SQL语句几乎都需要绑定一些参数，比如说WHERE语句啥的，如果我们使用字符串拼接的方式，把参数直接拼接到SQL中，不使用selectionArgs，这既丑陋又容易犯错；如果我们使用占位符+selectionArgs，那匹配占位符和selectionArgs也不是件容易的事，有个五六个占位符就够你对照一会了，况且selectionArgs还必须是String的，其它类型的参数还必须转成String类型。

Room解决这些问题的方式就是，使用注解+注解处理器的方式在编译时就验证SQL语句的正确性，尽早发现可能的问题，并且帮我们生成最终的SQL语句，保证占位符与绑定参数的对应。这些之后都会看到，体现在SupportSQLiteDatabase上就是大幅简化查询方法（减少到只有两个种类，4个方法），内部通过SQLiteDatabase的rawQueryWithFactory方法去真正地执行查询（其实SQLiteDatabase中那么多查询方法最终调用的也是这个rawQueryWithFactory方法）。

3.2.2 SQLiteOpenHelper的抽象

说一千道一万，你最终打开数据库的方式还得是通过SQLiteOpenHelper。我们想想SQLiteOpenHelper都包含哪些功能。

创建数据库，onCreate方法。
升级/降级数据库，onUpgrade/onDowngrade方法。
打开数据库，onOpen方法。
获取数据库，getWritableDatabase/getReadableDatabase方法。

我们经常使用的就是这四种。这四种方法可以分为两个阶段，前三种方法属于数据库打开之前的配置阶段，最后一种方法属于数据库已经打开后的使用阶段。Room也以这样的标准对SQLiteOpenHelper的功能进行了拆分，拆分之后各自的职责更加明晰。

public interface SupportSQLiteOpenHelper {
    String getDatabaseName();

    @RequiresApi(api = Build.VERSION_CODES.JELLY_BEAN)
    void setWriteAheadLoggingEnabled(boolean enabled);

    SupportSQLiteDatabase getWritableDatabase();

    SupportSQLiteDatabase getReadableDatabase();

    void close();
}

这就是抽象后SupportSQLiteOpenHelper，清晰明确了许多。SupportSQLiteOpenHelper是对使用阶段SQLiteOpenHelper职责的抽象。SQLiteOpenHelper配置阶段的职责通过回调的形式来实现：

public interface SupportSQLiteOpenHelper {
    //...
    
    abstract class Callback {
        public final int version;

        public Callback(int version) {
            this.version = version;
        }

        /**
         * Called when the database connection is being configured, to enable features such as
         * write-ahead logging or foreign key support.
         */
        public void onConfigure(SupportSQLiteDatabase db) {

        }

        public abstract void onCreate(SupportSQLiteDatabase db);

        public abstract void onUpgrade(SupportSQLiteDatabase db, int oldVersion, int newVersion);

        public void onDowngrade(SupportSQLiteDatabase db, int oldVersion, int newVersion) {
            throw new SQLiteException("Can't downgrade database from version "
                    + oldVersion + " to " + newVersion);
        }

        public void onOpen(SupportSQLiteDatabase db) {

        }

        public void onCorruption(SupportSQLiteDatabase db) {
            
        }
    }
}

类似于SQLiteOpenHelper，除了onCreate和onUpgrade之外，别的方法都不是必须实现的。
SupportSQLiteOpenHelper除了包括以上所说的数据库配置和使用的职责之外，还有一些辅助的功能。为了创建SupportSQLiteOpenHelper定义了一个工厂方法，为了工厂方法方便创建SupportSQLiteOpenHelper定义了一个配置类Configuration，配置类Configuration又采用了Builder模式：

public interface SupportSQLiteOpenHelper {
    //...
    
    class Configuration {
        @NonNull
        public final Context context;
        
        @Nullable
        public final String name;
        
        @NonNull
        public final SupportSQLiteOpenHelper.Callback callback;

        Configuration(@NonNull Context context, @Nullable String name, @NonNull Callback callback) {
            this.context = context;
            this.name = name;
            this.callback = callback;
        }

        public static Builder builder(Context context) {
            return new Builder(context);
        }

        /**
         * Builder class for {@link Configuration}.
         */
        public static class Builder {
            //标准Builder模式，从略
        }
    }

    interface Factory {
        SupportSQLiteOpenHelper create(Configuration configuration);
    }
}

略显繁琐，但都是一些简单设计模式的合理使用。
当SupportSQLiteOpenHelper把职责拆分成SupportSQLiteOpenHelper本身以及SupportSQLiteOpenHelper.Callback回调之后，就必须在创建SupportSQLiteOpenHelper的时候传入SupportSQLiteOpenHelper.Callback的实现，所以才有了SupportSQLiteOpenHelper.Factory和SupportSQLiteOpenHelper.Configuration。不过不用担心，这些都不用我们自己去实现，当我们使用Room时，注解处理器会帮我们生成对应的实现代码。

SupportSQLiteOpenHelper接口已经定义好了，接下来再来看看其实现类FrameworkSQLiteOpenHelper：

class FrameworkSQLiteOpenHelper implements SupportSQLiteOpenHelper {
    //这是一个 SQLiteOpenHelper，具体实现在下方
    private final OpenHelper mDelegate;

    FrameworkSQLiteOpenHelper(Context context, String name, Callback callback) {
        mDelegate = createDelegate(context, name, callback);
    }

    private OpenHelper createDelegate(Context context, String name, Callback callback) {
        final FrameworkSQLiteDatabase[] dbRef = new FrameworkSQLiteDatabase[1];
        return new OpenHelper(context, name, dbRef, callback);
    }

    @Override
    public String getDatabaseName() {
        return mDelegate.getDatabaseName();
    }

    @Override
    @androidx.annotation.RequiresApi(api = Build.VERSION_CODES.JELLY_BEAN)
    public void setWriteAheadLoggingEnabled(boolean enabled) {
        mDelegate.setWriteAheadLoggingEnabled(enabled);
    }

    @Override
    public SupportSQLiteDatabase getWritableDatabase() {
        return mDelegate.getWritableSupportDatabase();
    }

    @Override
    public SupportSQLiteDatabase getReadableDatabase() {
        return mDelegate.getReadableSupportDatabase();
    }

    @Override
    public void close() {
        mDelegate.close();
    }

    //数据库的打开必然还是要通过 SQLiteOpenHelper 的
    static class OpenHelper extends SQLiteOpenHelper {
        /**
         * 我们常用的技巧，使用final对象数组来保存对象引用，进而在匿名内部类中可以引用
         */
        final FrameworkSQLiteDatabase[] mDbRef;
        final Callback mCallback;
        private boolean mMigrated;

        OpenHelper(Context context, String name, final FrameworkSQLiteDatabase[] dbRef,
                final Callback callback) {
            super(context, name, null, callback.version,
                    new DatabaseErrorHandler() {
                        @Override
                        public void onCorruption(SQLiteDatabase dbObj) {
                            //回调
                            callback.onCorruption(getWrappedDb(dbRef, dbObj));
                        }
                    });
            mCallback = callback;
            mDbRef = dbRef;
        }

        synchronized SupportSQLiteDatabase getWritableSupportDatabase() {
            mMigrated = false;
            SQLiteDatabase db = super.getWritableDatabase();
            if (mMigrated) {
                // there might be a connection w/ stale structure, we should re-open.
                close();
                return getWritableSupportDatabase();
            }
            return getWrappedDb(db);
        }

        synchronized SupportSQLiteDatabase getReadableSupportDatabase() {
            mMigrated = false;
            SQLiteDatabase db = super.getReadableDatabase();
            if (mMigrated) {
                // there might be a connection w/ stale structure, we should re-open.
                close();
                return getReadableSupportDatabase();
            }
            return getWrappedDb(db);
        }

        FrameworkSQLiteDatabase getWrappedDb(SQLiteDatabase sqLiteDatabase) {
            return getWrappedDb(mDbRef, sqLiteDatabase);
        }

        @Override
        public void onCreate(SQLiteDatabase sqLiteDatabase) {
            //回调
            mCallback.onCreate(getWrappedDb(sqLiteDatabase));
        }

        @Override
        public void onUpgrade(SQLiteDatabase sqLiteDatabase, int oldVersion, int newVersion) {
            mMigrated = true;
            //回调
            mCallback.onUpgrade(getWrappedDb(sqLiteDatabase), oldVersion, newVersion);
        }

        @Override
        public void onConfigure(SQLiteDatabase db) {
            //回调
            mCallback.onConfigure(getWrappedDb(db));
        }

        @Override
        public void onDowngrade(SQLiteDatabase db, int oldVersion, int newVersion) {
            mMigrated = true;
            //回调
            mCallback.onDowngrade(getWrappedDb(db), oldVersion, newVersion);
        }

        @Override
        public void onOpen(SQLiteDatabase db) {
            if (!mMigrated) {
                // if we've migrated, we'll re-open the db so we should not call the callback.
                //回调
                mCallback.onOpen(getWrappedDb(db));
            }
        }

        @Override
        public synchronized void close() {
            super.close();
            mDbRef[0] = null;
        }

        //把 SQLiteDatabase包装成 FrameworkSQLiteDatabase
        static FrameworkSQLiteDatabase getWrappedDb(FrameworkSQLiteDatabase[] refHolder,
                SQLiteDatabase sqLiteDatabase) {
            FrameworkSQLiteDatabase dbRef = refHolder[0];
            if (dbRef == null || !dbRef.isDelegate(sqLiteDatabase)) {
                refHolder[0] = new FrameworkSQLiteDatabase(sqLiteDatabase);
            }
            return refHolder[0];
        }
    }
}

无论如何，想打开数据库必须扩展SQLiteOpenHelper类，而扩展SQLiteOpenHelper类又必须覆盖onCreate和onUpgrade两个方法。Room通过抽象已经把这部分职责从SupportSQLiteOpenHelper中剥离出来了，所以要以回调类SupportSQLiteOpenHelper.Callback的形式来完成这部分职责。
FrameworkSQLiteOpenHelper是接口SupportSQLiteOpenHelper的实现类，FrameworkSQLiteOpenHelper其实是通过工厂SupportSQLiteOpenHelper.Factory来创建的，而工厂SupportSQLiteOpenHelper.Factory又需要SupportSQLiteOpenHelper.Configuration参数，最终，SupportSQLiteOpenHelper.Configuration是由Room的注解处理器替我们生成出来的，这样一切就关联了起来。

4. 总结

这篇文章主要介绍了Room是如何通过接口的方式来抽象SQLite的，其中有不少接口的定义采用了映射原有系统对应类的方式，然后以简单委托的形式去实现，这并非多此一举。把一切建立在自我构建的抽象系统之上，通过特定的方式建立与原系统的联系（对于SQLite而言就是SQLiteOpenHelper），这是一种非常好的抽象与封装的方式。这种方式隔离了与原系统的直接联系，方便抽象系统的独立发展，也便于测试。
Room有些地方的抽象让人不明所以，但是当你深入理解之后，你会发现这是一种更好的实现方式。比如，对于增删改SQL的抽象，我们平常可能会想着直接使用对应的insert等方法，如果你这么想你必然会对insert等方法进行抽象，而非Room采用的SupportSQLiteStatement的方式；再比如，对于查询SQL，Room使用了参数延迟绑定+rawQueryWithFactory这种更加底层的方式。这说明抽象与封装有时候也取决于我们对于原有系统理解的深度。一看Google工程师们对于SQLite的理解就非常深入，所以我们在很多地方可以看出，Room的抽象使用了更多SQLite较底层的方法，抽象的方式也更加的彻底。
Room的源码分三个层次，最底层是抽象接口层，包含了各种以Support开头的接口；中间层是接口实现层，包含了各种以Framework开头的实现了Support接口的类；最上层才是Room实现层，这一层建立在下面两层的基础之上，包含了注解处理器生成的代码等，实现了数据库的具体逻辑。这篇文章主要介绍了前面两个层次，最后一个层次会在下一篇文章中介绍。

Room抽象的前两个层次