作者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