作者chengreg (想重回校園的工程師)
看板MacDev
標題[問題] 有關UITableView與Sqlite效能問題...
時間Sun Feb 5 01:27:14 2012
各位前備好:
小弟也如同各位前輩一同喜好開發iPhone程式,如今小弟在效能中有一問
請教各位前輩,也請前輩給予建議與指導,謝謝~~
狀況:
小弟有一Sqlite資料庫,此資料庫為之龐大,約有18萬筆資料於一Table表內
而小的設計一查詢界面撈取此Table表資料,平均約30~40sec完成
而完成的定義是顯示與UITableView內.
30~40sec是個很大的問題,因為iPhone4就是這個速度,那iPhone3GS or iPad1
的速度將會是個頭大的問題,因為使用者會以為當機拉!!!T_T
小弟開始分段取出每個時耗,想要抓出真正好時的地方是哪裡?
一開始以為是Sqlite Query DB時最久,但是發現
當小的Sql語法執行時,過程相當短暫(about 1sec~2sec)
重點在于,當執行完語法後,要將FMResult,用While回圈寫入NSDictionary
時,這個回圈的時間太久,(小弟需要計算每個UITableCell高度)造成30-40sec
的時間.....
左思右想,雖然知道原因,卻沒有任何方向去提升效能...
然而,小弟看了一下相同狀況於Android上卻出奇的快
原因是Android直接binding資料庫的DataSet...
我想這就是兩者的差別了...
以上狀況,不知是否有類似經驗的前輩給予經驗指導,與分享心得
請各位前輩不另惜分享....
再度謝謝^^
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 219.71.36.222
1F：推 DLMC:不確定你現在還有沒有時間，或有精力去修改， 02/05 10:21
2F：→ DLMC:但是如果改用CoreData在效能及程式碼的管理上， 02/05 10:22
3F：→ DLMC:會有很大的改善。 02/05 10:22
4F：推 DLMC:CoreData Programming Guide有兩段可以參考一下： 02/05 10:54
6F：→ chengreg:喔?謝謝D大,因為都用Sqlite所以沒去瞭解過coerData 02/05 13:10
7F：→ chengreg:小弟去試試看 02/05 13:10
8F：→ kusowan:我想直接放到UITable不是個好的選擇 02/05 13:29
9F：推 DLMC:同意kusowan大，如果在UITableView delegate處理資料， 02/05 19:42
10F：→ DLMC:會重重影響到效能。 02/05 19:42
11F：→ chengreg:不太明瞭K大的意思,K大是指將Result放到UITable?還是? 02/06 10:00
12F：推 Adonisy:處理這麼大量的資料，本來就不建議啊... 02/06 11:59
13F：推 popcorny:你是要把18萬資料都放進UITableView. 還是只有查詢出部分 02/06 13:32
14F：→ popcorny:再把部分資料放進UITablewView? 02/06 13:33
15F：→ popcorny:有建index..且只查出部分資料應該是花不到多少啊.. 02/06 13:33
16F：→ chengreg:回P大:是撈取後於UITableView呈現資料,但是While回圈造成 02/06 14:54
17F：→ chengreg:時耗,Query DB沒有耗時多少時間 02/06 14:55
18F：推 popcorny:既然跟query db沒關..那標題就不應該扯到sqlite囉.. 02/06 15:13
19F：→ popcorny:你把你的tableView:heightForRowAtIndexPath:這邊貼出來 02/06 15:13
20F：→ chengreg:回P大,還是跟Sqlite有關,問題在FMResultSet讀取每筆資料 02/06 15:17
21F：→ chengreg:需要用到While回圈把資料寫入NSDictionary內,這個時間 02/06 15:18
22F：→ chengreg:消耗最久,所以還沒將資料放到UITableView上就要耗時約40s 02/06 15:18
23F：推 popcorny:請問FMResultSet裡面有幾筆? 如果超過100筆 02/06 15:40
24F：→ popcorny:可否用limit來限制query出來的數量? 02/06 15:40
25F：→ popcorny:還有是否可以只select出需要呈現的column..而不要用 02/06 15:41
26F：→ popcorny:select *這種把所有資料都撈出來的行為 02/06 15:41
27F：→ chengreg:回P大,當然,小弟一定不敢用select *這種可怕的東西,但由 02/06 15:47
28F：→ chengreg:於PM要求不可以分頁顯示(下拉10筆)的方式,所以必然先撈出 02/06 15:49
29F：→ chengreg:來,Ｔ＿＿Ｔ 02/06 15:49
30F：推 popcorny:即使PM要求不要分頁顯示..但是實作上還是可以模擬這種 02/06 16:29
31F：→ popcorny:行為..這種我們稱為infinite scroll.. 簡單講,就是捲到 02/06 16:30
32F：→ popcorny:boundary..這再透過limit,offset去query下個window的data 02/06 16:30
33F：→ chengreg:回p大:恩~~小弟也是這樣想,架構要大改 T_T 謝謝P大 02/06 17:00
34F：推 aecho:如果問題是在db上，那CoreData不見得會比較快… 02/07 06:39
36F：→ aecho:上面這篇連結的作者，最後從CoreData改回用FMDB 02/07 06:44
37F：→ aecho:就為了解決CoreData造成的效能問題。 02/07 06:45