SQLite数据库学习小结——Frameworks层实现

3. SQLite的Frameworks层实现

3.1 Frameworks层架构

    Android系统方便应用使用,在Frameworks层中封装了一套Content框架,之所以叫Content框架而不叫数据库框架之类的,是因为这里Content不一定是来自数据库的内容,也可以是来自其他数据源的内容,开发人员只需要知道如何使用ContentResovler和ContentProvider就可以在应用进程之间共享数据了。

  这里我们只讨论数据源是数据库的ContentProvider,开发人员需要实现一个SQLiteOpenHelper的派生类,它使用了一系列SQLite相关的类封装了native层的SQLite动态库的接口方法,那么SQLite在Frameworks层是如何封装的,我们在使用SQLite时又需要注意些什么呢?

    我们先来看一看基于SQLite的Content框架的整体架构:

    Android系统在Frameworks层

  1、ContentResolver:Content框架的客户端,对应用提供增、删、改、查的接口方法,通过Authority指定目标Content服务,并连接到服务端执行数据操作。 
  2、ContentProvider:Content框架的服务端,Android应用四大组件之一,通过Authority注册到PMS,在运行时有客户端请求时由AMS调度来响应客户端的数据操作。 
  3、SQLiteOpenHelper:管理SQLite的帮助类,提供获取SQLIteDatabase实例的方法,它会在第一次使用数据库时调用获取实例方法时创建SQLiteDatabase实例,并且处理数据库版本变化,开发人员在实现ContentProvider时都要实现一个自定义的SQLiteOpenHelper类,处理数据的创建、升级和降级。
  注意: 

    (1)不管是调用getWritableDatabase方法还是getReadableDatabase方法,SQLIteOpenHelper都会以可读写模式打开数据库。

    (2)如果应用程序想以WAL模式打开数据库,可在自定义SQLiteOpenHelper类的构造方法中调用setWriteAheadLoggingEnabled(true)。 

    SQLiteOpenHelper.java

     

  4、SQLiteDatabase:代表一个打开的SQLite数据库,提供了执行数据库操作的接口方法。如果不需要在进程之间共享数据,应用程序也可以自行创建这个类的实例来读写SQLite数据库。 
  5、SQLiteSession:SQLiteSession负责管理数据库连接和事务的生命周期,通过SQLiteConnectionPool获取数据库连接来执行具体的数据库操作。 

  6、SQLiteConnectionPool:数据库连接池,管理所有打开的数据库连接(Connection)。所有数据库连接都是通过它来打开,打开后会加入连接池,在读写数据库时需要从连接池中获取一个数据库连接来使用。 

  7、SQLiteConnection:代表了数据库连接,每个Connection封装了一个native层的sqlite3实例,通过JNI调用SQLite动态库的接口方法操作数据库,Connection要么被Session持有,要么被连接池持有。 

  8、CursorFactory:可选的Cursor工厂,可以提供自定义工厂来创建Cursor。 

  9、DatabaseErrorHandler:可选的数据库异常处理器(目前仅处理数据库Corruption),如果不提供,将会使用默认的异常处理器。 

  10、SQLiteDatabaseConfiguration:数据库配置,应用程序可以创建多个到SQLite数据库的连接,这个类用来保证每个连接的配置都是相同的。 

  11、SQLiteQuery和SQLiteStatement:从抽象类SQLiteProgram派生,封装了SQL语句的执行过程,在执行时自动组装待执行的SQL语句,并调用SQLiteSession来执行数据库操作。这两个类的实现应用了设计模式中的命令模式。 

3.2 关键模块实现

    本节介绍几个关键模块的实现和使用时需要注意的事项。

3.2.1 SQLiteSession

  Android系统Frameworks层的数据库读写操作都是通过SQLiteSession完成的,SQLiteSession负责管理数据库连接和事务的生命周期。

  一个SQLiteDatabse实例可以同时持有多个活跃的Session(但是为防止死锁,每个线程只能持有一个DB的Session),每个Session在执行SQL语句时获取数据库连接,在SQL语句执行结束后释放数据库连接,Session只有在只执行SQL语句期间保持数据库连接,执行完后就释放了。这个特性也是连接池的实现基础。

SQLiteSession.java

  如果连接池中所有连接都已分配出去了,那么获取连接的SQLiteSession会阻塞直到有可用连接为止。

  所以,在使用SQLite时需要注意以下几点: 

  (1)不要在UI线程中执行数据库操作。 

  (2)执行的事务尽量短。 

  (3)如果读写事务很长,可以考虑使用yieldTransaction()方法先提交部分事务,给其他事务执行的机会。

3.2.2 SQLiteConnectionPool

  数据库连接池保持所有打开的数据库连接,在任何时候,一个数据库连接要么被连接池持有,要么被一个SQLiteSession持有,如果SQLiteSession使用完数据库连接,必须把它还给连接池。如果连接池中所有的连接都已被占用,则待执行的事务要等待有空闲的连接才能执行。

  目前Android系统的实现中,如果以非WAL模式打开数据库,连接池中只会保持一个数据库连接,如果以WAL模式打开数据库,连接池中的最大连接数量则根据系统配置决定,默认配置是两个。

SQLiteConnectionPool.java:

  虽然名为连接池,但是从源码来看,目前实现的池中只有一个数据库连接(以后的Android版本可能会扩展),所以如果应用程序中有大量的并发数据库读和写操作的话,每个操作的时长都可能受到影响,所以数据库操作应放在工作线程中执行,以免影响UI响应。

3.2.4 Cursor

  从ContentProvider查询的数据结果是放在Cursor中返回给客户端的,在客户端看来Cursor就是一个数据容器,但隐藏在Cursor后面的实现方式很灵活,它的数据既可以不是从数据库返回的,也可以是在使用时才真正加载的,很好的体现了面向对象编程的特性和优点。

  在Frameworks中把Cursor定义为了一个接口,它的定位是可以随机访问的数据集,在接口中定义了访问数据集的通用方法。业务可以根据自己的需要实现一个Cursor,具体怎么实现接口的方法由具体实现决定,所以Cursor有很多子类来满足不同场景的需要。

  通过SQLiteDatabase返回的就是其中的SQLiteCursor,如果数据不是从数据库返回的,开发人员也可以在ContentProvider中动态创建一个MatrixCursor,然后填充数据并返回给客户端。

  从Cursor接口和其派生类的定义来看它们都没有实现Parcelable接口,那么它是怎么跨进程传递的呢?这需要Cursor首先要解决两个问题。

  第一个问题:Cursor没有实现Parcelable接口,一个Cursor实例怎么跨进称传递呢?答案是传递的不是具体数据,而是Binder引用,即在ContentProvider端创建Cursor的Binder服务端实例,然后把Binder应用传递给客户端,在客户端通过这个Binder引用跨进程获取查询到的数据的。这里Frameworks定义了一个接口:IBulkCursor。

  IBulkCursor定义了跨进程的Cursor需要实现的接口方法,其中getWindow()用来获得数据窗口,onMove()用来移动Cursor的位置。

  那么第二个问来了:我们知道通过Binder传递的数据大小有限(1MB),而查询到的数据大小可能超出限制,那么怎么跨进程传递数据呢?既然数据大小不定,那么我们就不通过Binder传递数据了,而是通过共享内存传递数据,这块共享内存是封装在CursorWindow中的。

  CursorWindow就是数据窗口,它在服务端分配(窗口大小有Android系统配置决定)并传递到客户端,客户端再映射到自己的进程空间中,这样,服务端填充的数据就可以被客户端读取到了。上面IBulkCursor接口中定义的getWindow()方法就是获取CursorWindow的。

  CursorWindow在初始化时是空的,在调用Cursor的moveToXXX方法时会通过IBulkCursor的onMove()方法调用服务端的Cursor去填充数据窗口的内容。

CursorWindow.java

frameworks\base\libs\androidfw\CursorWindow.cpp

  服务端创建共享内存。

CursorWindow.java

frameworks\base\libs\androidfw\CursorWindow.cpp

  客户端映射共享内存到进程内存空间。

  上面知道了Frameworks解决跨进程传递Cursor数据的思路,我们再来看下具体执行跨进程传递数据的类:CursorToBulkCursorAdapter(服务端)和BulkCursorToCursorAdapter(客户端)。

服务端:

客户端:

  在ContentProviderNatvie类中可以看到Cursor的专递过程。

服务端:

ContentProviderNative.onTransact()

CursorToBulkCursorAdaptor.java

  服务端在通过ContentProvider得到Cursor后,用它创建一个CursorToBulkCursorAdaptor实例,然后把adaptor封装在一个实现了Parcelable接口的BulkCursorDescriptor实例中返回给客户端。

  虽说是在使用时才填充数据窗口,但是实际上传递Cursor的过程中,从上面代码可以看到服务端已经替应用程序填充过一次数据了:mCursor.getCount()。

SQLiteCursor.java

客户端:

ContentProviderProxy.query()

BulkCursorToCursorAdaptor.java 

    在得到服务端返回的数据后创建一个BulkCursorDescriptor实例,在用它初始化一个BulkCursorToCursorAdapter实例返回给应用程序使用。 

posted @ 2016-06-05 09:10  寒带鱼  阅读(...)  评论(... 编辑 收藏