Android上的SQLLite效能分析

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

根據你所使用的版本不同，一個相同的查詢的已耗用時間可能從幾毫秒到幾分鐘不等。例如，一個查詢可能在 Galaxy S2 運行少於一秒(在 iPhone 4 上可能更快)，但是在 Atrix 2 和 HTC Desire 上運行卻需要一分鐘。所有這些手機都有類似的硬體，那麼區別在哪裡?

在對代碼研究了幾天后，我發現問題在於查詢語句的設計。當你使用大量的 joins 或者 unions 的時候，問題就出現了。組合一張大的資料表和一張或多張中等大小的資料表，需要非常小心的最佳化來保證在所有的裝置上都有良好的效能。在做 unions 或者 joins 之前限制資料表的大小很重要!

我們以下面的資料庫和資料表為例：

· 一張 Person 表，有 name, height, age 等欄位

· 一張 Family 表，包含了家庭的詳情

· 一張 City 表，包含了所有城市的資訊

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

這裡的痛點是如何知道使用者使用的是什麼版本的 SQL Lite。雖然 Android 有一個預設的版本，但是似乎不同的廠商在不同的裝置上用了不同的 SQL Lite 版本。這就給我們造成了很大的麻煩。

在 StackOverFlow 上有一些關於這方面的資訊。總之嘗試去獲得裝置的 SQL Lite 版本是很困難的，你最好還是把力氣花在最佳化 SQL 上面，以保證在所有的裝置上都有良好的效能。

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