PTT數位生活區 / MacDev

[問題] 有關UITableView與Sqlite效能問題...

看板MacDev作者 (想重回校園的工程師)時間13年前 (2012/02/05 01:27), 編輯推噓10(10推 0噓 27→)
留言37則, 6人參與, 最新討論串1/2 (看更多)
各位前備好: 小弟也如同各位前輩一同喜好開發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
推
02/05 10:21, , 1F
不確定你現在還有沒有時間，或有精力去修改，
02/05 10:21, 1F
→
02/05 10:22, , 2F
但是如果改用CoreData在效能及程式碼的管理上，
02/05 10:22, 2F
→
02/05 10:22, , 3F
會有很大的改善。
02/05 10:22, 3F
推
02/05 10:54, , 4F
CoreData Programming Guide有兩段可以參考一下：
02/05 10:54, 4F
→
02/05 10:55, , 5F
02/05 10:55, 5F
→
02/05 13:10, , 6F
喔?謝謝D大,因為都用Sqlite所以沒去瞭解過coerData
02/05 13:10, 6F
→
02/05 13:10, , 7F
小弟去試試看
02/05 13:10, 7F
→
02/05 13:29, , 8F
我想直接放到UITable不是個好的選擇
02/05 13:29, 8F
推
02/05 19:42, , 9F
同意kusowan大，如果在UITableView delegate處理資料，
02/05 19:42, 9F
→
02/05 19:42, , 10F
會重重影響到效能。
02/05 19:42, 10F
→
02/06 10:00, , 11F
不太明瞭K大的意思,K大是指將Result放到UITable?還是?
02/06 10:00, 11F
推
02/06 11:59, , 12F
處理這麼大量的資料，本來就不建議啊...
02/06 11:59, 12F
推
02/06 13:32, , 13F
你是要把18萬資料都放進UITableView. 還是只有查詢出部分
02/06 13:32, 13F
→
02/06 13:33, , 14F
再把部分資料放進UITablewView?
02/06 13:33, 14F
→
02/06 13:33, , 15F
有建index..且只查出部分資料應該是花不到多少啊..
02/06 13:33, 15F
→
02/06 14:54, , 16F
回P大:是撈取後於UITableView呈現資料,但是While回圈造成
02/06 14:54, 16F
→
02/06 14:55, , 17F
時耗,Query DB沒有耗時多少時間
02/06 14:55, 17F
推
02/06 15:13, , 18F
既然跟query db沒關..那標題就不應該扯到sqlite囉..
02/06 15:13, 18F
→
02/06 15:13, , 19F
你把你的tableView:heightForRowAtIndexPath:這邊貼出來
02/06 15:13, 19F
→
02/06 15:17, , 20F
回P大,還是跟Sqlite有關,問題在FMResultSet讀取每筆資料
02/06 15:17, 20F
→
02/06 15:18, , 21F
需要用到While回圈把資料寫入NSDictionary內,這個時間
02/06 15:18, 21F
→
02/06 15:18, , 22F
消耗最久,所以還沒將資料放到UITableView上就要耗時約40s
02/06 15:18, 22F
推
02/06 15:40, , 23F
請問FMResultSet裡面有幾筆? 如果超過100筆
02/06 15:40, 23F
→
02/06 15:40, , 24F
可否用limit來限制query出來的數量?
02/06 15:40, 24F
→
02/06 15:41, , 25F
還有是否可以只select出需要呈現的column..而不要用
02/06 15:41, 25F
→
02/06 15:41, , 26F
select *這種把所有資料都撈出來的行為
02/06 15:41, 26F
→
02/06 15:47, , 27F
回P大,當然,小弟一定不敢用select *這種可怕的東西,但由
02/06 15:47, 27F
→
02/06 15:49, , 28F
於PM要求不可以分頁顯示(下拉10筆)的方式,所以必然先撈出
02/06 15:49, 28F
→
02/06 15:49, , 29F
來,Ｔ＿＿Ｔ
02/06 15:49, 29F
推
02/06 16:29, , 30F
即使PM要求不要分頁顯示..但是實作上還是可以模擬這種
02/06 16:29, 30F
→
02/06 16:30, , 31F
行為..這種我們稱為infinite scroll.. 簡單講,就是捲到
02/06 16:30, 31F
→
02/06 16:30, , 32F
boundary..這再透過limit,offset去query下個window的data
02/06 16:30, 32F
→
02/06 17:00, , 33F
回p大:恩~~小弟也是這樣想,架構要大改 T_T 謝謝P大
02/06 17:00, 33F
推
02/07 06:39, , 34F
如果問題是在db上，那CoreData不見得會比較快…
02/07 06:39, 34F
推
02/07 06:44, , 35F
02/07 06:44, 35F
→
02/07 06:44, , 36F
上面這篇連結的作者，最後從CoreData改回用FMDB
02/07 06:44, 36F
→
02/07 06:45, , 37F
就為了解決CoreData造成的效能問題。
02/07 06:45, 37F
‣ 更多 chengreg 的文章
文章代碼(AID): #1FBMfqM3 (MacDev)
MacDev 近期熱門文章
更多 近期熱門文章 >>
PTT數位生活區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 chengreg 的文章
文章代碼(AID): #1FBMfqM3 (MacDev)