推荐:http://code4app.com/ios/VVeboTableView/565d75a3594b90bf268b49ff
1: heightForRowAtIndexPath方法小做文章
原因:tableview继承自scrollview,当tableview加载时需要将contentSize计算出来。所以第一次加载时会频繁调用此方法,如:table有100行,则此方法调用100次,将每次得出的结果相加得到contentSize。就像每次使用scrollview滚动时都要设置contentSize这个属性一样。
小做文章1:如果table每一个cell的高度固定,使用_tableView.rowHeight = 200;
小做文章2:如果cell高度可变,不要在heightForRowAtIndexPath中调用cellForRowAtIndexPath来计算。取而代之的是,cell的工厂方法。如:
小做文章3:在获取数据的时候就将高度计算好并存储到数据中,heightForRowAtIndexPath方法则直接使用该数据。如:
总结:尽可能使用第三种方法,分析如下
第二种方法时间分析如下:
第三种方法时间分析如下:
两种方法本质上都是遍历数据获取相应高度,计算高度的代码完全相同。但是第二种方法中heightForRowAtIndexPath的运行时间占比很大,并且随着table滚动而不断增加,证明每次用户滚动table时,计算高度的方法都执行一次,如果计算高度的方法用时比较多,如我当前用的
每次计算的时间都在330个单位上下,那么如果数据量大,滚动很快时,这简直就是灾难。
第三种方法计算高度的代码则是在获取数据后,table加载之前执行,并且只执行一次。210ms的时间不随着table的滚动儿增加。而我们的heightForRowAtIndexPath的方法,执行时间已经降到了1ms,几乎可以忽略不计了。
当然,在一个只有table的demo中,这点优化基本看不出有什么作用。
2:添加不如画:cellForRowAtIndexPath方法大费周折
平时使用cellForRowAtIndexPath时最常用的方法就是在cell的init方法中addSubview如
这个是添加子视图的方法将数据灌在cell中。
画的方法则是在最开始推荐的demo中的方法,感谢作者。
像这样:
画的代码很多,基本属于CoreGraphics框架的东东,说大费周折,基本都在这了。
添加子视图的方法时间分析如下:
画的方法时间分析如下:
实话实说呀,这画的方法代码执行的时间真心是吓了我一跳了,画cell的线程真心是-_-#
但是呢,用户滚动table是感觉不到地,因为所有画的线程都是子线程,而主线程占比只有区区的2%,就是setimage的方法。
反过来,添加子视图的方法cellForRowAtIndexPath则几乎全部都在主线程执行,子线程只有查找缓存图片的方法。这个办法真心卡卡卡的呀。
真机跑一下,明显感觉画的方法要比添加子视图的方法顺畅的多。
ps:只分析代码执行时间,不分析内存占用量。