也許有人還不知道，Android 是有一些內建的 類庫支持 SQL Lite 數(shù)據(jù)庫的操作。他提供了一個很好的方式在 Android 上組織少量的數(shù)據(jù)。不管怎樣，在使用這些類庫的時候有一些陷阱是需要注意的。

根據(jù)你所使用的版本不同，一個相同的查詢的運行時間可能從幾毫秒到幾分鐘不等。例如，一個查詢可能在 Galaxy S2 運行少于一秒（在 iPhone 4 上可能更快），但是在 Atrix 2 和 HTC Desire 上運行卻需要一分鐘。所有這些手機都有類似的硬件，那么區(qū)別在哪里？

在對代碼研究了幾天后，我發(fā)現(xiàn)問題在于查詢語句的設計。當你使用大量的 joins 或者 unions 的時候，問題就出現(xiàn)了。組合一張大的數(shù)據(jù)表和一張或多張中等大小的數(shù)據(jù)表，需要非常小心的優(yōu)化來保證在所有的設備上都有良好的性能。在做 unions 或者 joins 之前限制數(shù)據(jù)表的大小很重要！

我們以下面的數(shù)據(jù)庫和數(shù)據(jù)表為例：

• 一張 Person 表，有 name, height, age 等字段
• 一張 Family 表，包含了家庭的詳情
• 一張 City 表，包含了所有城市的信息

在 Android 上面把所有這些表聯(lián)合起來（假設 Person 表有超過2000條記錄）在大部分設備上是沒有問題的。但是假如你的用戶正在使用一個老版本的 SQL Lite 版本，你的應用就慢的無法使用了。你要盡量讓 join 的記錄越少越好以保證性能。例如，你從 Person 表中抽取一部分記錄再做 join，性能就會好很多。

這里的難點是如何知道用戶使用的是什么版本的 SQL Lite。雖然 Android 有一個默認的版本，但是似乎不同的廠商在不同的設備上用了不同的 SQL Lite 版本。這就給我們造成了很大的麻煩。

在 StackOverFlow 上有一些關于這方面的信息。總之嘗試去獲得設備的 SQL Lite 版本是很困難的，你最好還是把力氣花在優(yōu)化 SQL 上面，以保證在所有的設備上都有良好的性能。

還有一個有趣的地方就是 Android 上面，一條查詢究竟是何時被執(zhí)行的。也許你認為當你獲得 Cursor 對象的時候，查詢就執(zhí)行完了。但事實情況是，查詢不會被執(zhí)行直到 Cursor 被第一次訪問，例如 moveToNext，moveToFirst 操作。所以請不要在 UI 線程或者相關的線程中使用 cursor，否則界面會卡死。