編輯推薦：稀土掘金，這是一個針對技術(shù)開發(fā)者的一個應(yīng)用，你可以在掘金上獲取最新最優(yōu)質(zhì)的技術(shù)干貨，不僅僅是Android知識、前端、后端以至于產(chǎn)品和設(shè)計都有涉獵，想成為全棧工程師的朋友不要錯過！
前些時候看到興趣小組里有人問“Android上SQLite的最佳實踐”是什么，好奇地搜了一下，確實沒有一個好一點的指導(dǎo)文檔，平時的使用也只是簡單的拷貝code，并沒有深入的研究過。以下是我看到的Kevin關(guān)于其使用的心得，原文的大體的意思是：
Android例子涵蓋了一些Sqlite的基本用法，但它們并沒有深入地給出合理的使用方法，更重要的是，不合理的使用方法。大多數(shù)例子和文檔只是涉及最基本的數(shù)據(jù)庫查詢，或者教你如何創(chuàng)建一個ContentProvider。從來不提及的地方像：
· 什么地方創(chuàng)建和保存SQLiteOpenHelper實例？
· 可以有多少個實例？
· 多線程同時訪問數(shù)據(jù)庫有沒有什么要擔(dān)心的？
基本的內(nèi)容是，你可以任意次數(shù)地連接Sqlite數(shù)據(jù)庫，而且Android系統(tǒng)也支持你這樣做。Sqlite擁有文件級別的鎖，用來同步訪問和防止錯誤。如果你只知道這些，那么，將會給你帶來很大的痛苦。開源的一個好處是，你可以深入代碼一探究竟。從代碼和一些測試中，我了解到以下事實：
· Sqlite擁有文件級別的鎖。許多線程可以同時讀，但只有一個可以寫。鎖阻止多個同時寫入。
· Android在SQLiteDatabase中實現(xiàn)了一些java鎖來確保動作是同步進(jìn)行。
· 如果你用多個線程瘋狂地訪問數(shù)據(jù)庫，你的數(shù)據(jù)庫不會（或不應(yīng)該）崩潰。
沒提到的是，如果你通過多個不同的真實連接同時寫數(shù)據(jù)庫，其中的某個會失敗，它不會等到前一個完成后繼續(xù)寫入。簡單地，不會寫入你的改變，更糟糕的是，你也得不到一個異常，只是在LogCat中輸出一些message，僅此而已。
SQLiteOpenHelper類做了一些有趣的事。盡管它有方法可以獲得一個只讀的連接和可讀寫的連接，但實質(zhì)上它們是同一個連接。假設(shè)沒有文件寫錯誤的話，只讀的連接實質(zhì)上就是一個可讀寫的連接。有趣吧。因此，如果你的app中使用一個helper的話，即便從多線程中使用，你也從未使用多個連接。
同樣，一個helper中只有一個SQLiteDatabase的實例，這個實例中實現(xiàn)了一些java鎖。因此，當(dāng)你正在執(zhí)行數(shù)據(jù)庫的操作時，其它db的操作都將鎖定。即便是你使用多個線程來做這些事以便優(yōu)化數(shù)據(jù)庫的性能，壞消息，沒有什么用。
按照我的認(rèn)識，SQLite工作的方式，基本上不可能會破壞你的數(shù)據(jù)庫，除非代碼里有bug或者有硬件問題。
因此，我推薦這樣使用：創(chuàng)建一個SQLiteOpenHelper靜態(tài)對象。什么時候去close它呢？不需要。當(dāng)app關(guān)閉，它會自動釋放文件引用。
但是，會不會有“close() was never explicitly called on database”異常呢？
如果你注意的話，當(dāng)連接掛在那里的時候，你沒有得到那個異常。你只是在連接已經(jīng)建立，而你又嘗試打開另一個時才會有異常。因此，你只需要打開一次連接。
像這樣來使用：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 | public class DatabaseHelper extends OrmLiteSqliteOpenHelper { private static DatabaseHelper instance; public static synchronized DatabaseHelper getHelper(Context context) { if (instance == null) instance = new DatabaseHelper(context); return instance; } //Other stuff... } |
