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

[kusowan (kuso)]

我覺得這種情況並非您的數據庫太大，而是FMResult返回的數據量太大
當用while去讀取的時候iOS要復制每個object導致大量時耗
而android不用復制所以快很多

這種情況就連apple本身也沒什麼好的解決方法
看看App store的search界面，以及眾多的滑動下拉菜單，很明顯，不
要一次顯示那麼多才是王道

不知道為什麼您要分別計算每個UITableCell的高度，如果是我的話，會
用固定形態的UITableCell分頁顯示...壞處是會降低一些用戶體驗

流行的設計是分頁顯示一個超出顯示範圍的UITable，這樣滑動手勢仍可
起作用；然後在到達底部時用下拉顯示更多這種提示來加載下一頁的數
據。也就是說，將您的30秒延遲分隔成10個3秒，這樣既提高了效能，又
不失用戶體驗

--
Come with an evil heart
Don't fear to become dark

--
※ 發信站: 批踢踢實業坊(ptt.cc) 
◆ From: 140.109.82.61
推 chengreg:K大果然很有經驗,我切確的問題就是While造成時耗,
→ chengreg:但是基於公司UI的要求必然要調整動態高度,所以不得不
→ chengreg:而且PM強烈要求不可以卷到最後才繼續讀取資料..T_T哎..
→ chengreg:而且PM還說,你看.人家Android就那磨快!!iphone不是更好?
推 Blueshiva:不要卷到最後，可以捲到剩20/50筆再讀，這樣也可以騙過
→ Blueshiva:去啊
推 chengreg:請問B大,小弟的UITableView需要用到動態高度調整,也就是
→ chengreg:說會在heightForRowAtIndexPath內調整cell高度,但是若
→ chengreg:NSArray變動後(+20筆),就要去呼叫reloadData,而只要呼叫
→ chengreg:reloadData則NSArray就會從0開始跑一次,高度那邊會更久..
→ chengreg:不知道B大是否有解決方案...T_T
→ popcorny:你不是每個item都存成Dictionary嗎? 算過的加個rowHeight
→ popcorny:的資料代表算過不就解決了
→ lunaglyph:新增的用insert row 就好了，不用 reload table吧