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）不管是調用getWritableDatabase方法還是getReadableDatabase方法，SQLIteOpenHelper都會以可讀寫模式打開數據庫。
（2）如果應用程序想以WAL模式打開數據庫，可在自定義SQLiteOpenHelper類的構造方法中調用setWriteAheadLoggingEnabled(true)。
SQLiteOpenHelper.java
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時需要注意以下幾點：
（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實例返回給應用程序使用。