最近知乎上有人提问, tableView的顺畅性能, 各位大神纷纷出炉, 很多东西值得学习的, 吾mark之 !
知乎链接: http://www.zhihu.com/question/20382396
另附一个链接,说的很好很实用:http://my.oschina.net/jeans/blog/63203
大致总结了这几点, 记录之, 有用时可查询!
问题: 如何加强 iOS 里的列表滚动时的顺畅感?
Path 的列表滚动感觉非常流畅,没有 UITableView 的迟滞感(当然是指同样多子 view 的情况下)。想知道 Path 用的是什么方案?暂时只想到可能是完全纯自绘。其他还有吗?希望有相关经验者不吝赐教....
解答一: 如果你想要如丝般顺滑的效果,那么:
1、每次都看一下有没有能重用的 cell,而不是永远重新新建(这个是 UITableView 的常识)
2、Cell 里尽量不要用 UIView 而是全部自己用 drawRect 画(之前因为 iOS 有 bug,这样做会有性能上质的飞越。也有很多大神写过很多文章解释原理,有兴趣的自己去看看吧我就不做复制粘贴了。后来 iOS 也改掉了这个问题,这么做的效果就没那么明显了。)
3、图片载入放到后台进程去进行,滚出可视范围的载入进程要 cancel 掉
4、圆角、阴影之类的全部 bitmap 化,或者放到后台 draw 好了再拿来用
5、Cell 里要用的数据提前缓存好,不要现用现去读文件
6、数据量太大来不及一次读完的做一个 load more cell 出来,尽量避免边滚边读数据,这样就算是双核的 CPU 也难保不会抽
做到以上6条的话,应该就能做出很顺畅的滚动了(现在的 Twitter 官方客户端的原作者写过一篇文章,总结起来也无非就是我说的前3条,可以找来看看)。
Path 2.5 的那个滚动说实在的不是很顺畅,图片显示出来的时候都会抽一下,他们还有很大的改进余地。
对于3的补充说明:UIImageView 的载入是惰性的说法,是对的。但是大部分开发者都没有正确理解这一点。下面就详细解释一下:
[UIImage imageWithContentOfFile:] 出来的 UIImage 其实并没有真正把文件解码到内存,而是要等到用的时候(例如去显示或者去 scale)才会去做这件事情。但问题就在于 UIImageView 试图去 draw 图片的时候,它读文件、渲染也是在主线程里做的,所以你要读入的图片如果很大(比如 iPad3 上的 @2x 图),这一步就很容易会卡一下。这也就是为什么我说图片要放到后台进程去解码完之后(解码是可以后台做的!很多“大神”居然都不知道这一点),再拿来显示(显示只能在主线程做)的原因。
1、每次都看一下有没有能重用的 cell,而不是永远重新新建(这个是 UITableView 的常识)
2、Cell 里尽量不要用 UIView 而是全部自己用 drawRect 画(之前因为 iOS 有 bug,这样做会有性能上质的飞越。也有很多大神写过很多文章解释原理,有兴趣的自己去看看吧我就不做复制粘贴了。后来 iOS 也改掉了这个问题,这么做的效果就没那么明显了。)
3、图片载入放到后台进程去进行,滚出可视范围的载入进程要 cancel 掉
4、圆角、阴影之类的全部 bitmap 化,或者放到后台 draw 好了再拿来用
5、Cell 里要用的数据提前缓存好,不要现用现去读文件
6、数据量太大来不及一次读完的做一个 load more cell 出来,尽量避免边滚边读数据,这样就算是双核的 CPU 也难保不会抽
做到以上6条的话,应该就能做出很顺畅的滚动了(现在的 Twitter 官方客户端的原作者写过一篇文章,总结起来也无非就是我说的前3条,可以找来看看)。
Path 2.5 的那个滚动说实在的不是很顺畅,图片显示出来的时候都会抽一下,他们还有很大的改进余地。
对于3的补充说明:UIImageView 的载入是惰性的说法,是对的。但是大部分开发者都没有正确理解这一点。下面就详细解释一下:
[UIImage imageWithContentOfFile:] 出来的 UIImage 其实并没有真正把文件解码到内存,而是要等到用的时候(例如去显示或者去 scale)才会去做这件事情。但问题就在于 UIImageView 试图去 draw 图片的时候,它读文件、渲染也是在主线程里做的,所以你要读入的图片如果很大(比如 iPad3 上的 @2x 图),这一步就很容易会卡一下。这也就是为什么我说图片要放到后台进程去解码完之后(解码是可以后台做的!很多“大神”居然都不知道这一点),再拿来显示(显示只能在主线程做)的原因。
解答二:
2012年的WWDC的238 section讲的就是一些关于增强图形动画性能的tips,我做了一些笔记,我又整理了一下,楼主可以参考:
1、关于图片的加载:
- UIImageView 是由CALayer, UIImage->CGImage 构成的,CGImage 在加载的时候不会解码图像,只有在第一次用的时候才会解码图像(Lazy Loading)。所以,尽量用UIImageView 不要直接把图像画在 drawrect:
- iOS本身对于PNG文件进行了很多优化:例如(这个我怕翻不太准):
- Premultiply alpha, and byte-swap
- Turn off some PNG compression modes
- Allow concurrent decoding of a single image
- 此外,iOS6对Jpeg文件也已经优化了很多,但是不建议用Jpeg文件作为UI元素;永远不要用其他格式的图片作为UI元素,尽管iOS都支持。
- [UIImage imageNamed:] 的数据会缓存在内存中,而[UIImage imageWithContentOfFile:]则不会,所以需要慎重选择方法。这也是为什么有时候模拟器跑得很好,而真机跑的时候很悲剧的原因,模拟器设置的缓存内存比真机大很多。
- 在设置背景图片的时候不要在drawRect里
[self.image drawInRect: [self bounds] blendMode kCGBlendModeNormal alpha:1.0], 可以这样:myView.layer.content = (id)[self.image CGImage]; - iOS 6新功能 myView.layer.drawAsynchronously = YES 对于一个view里有很多需要draw的内容来说,很有用,但是有时候会很差,需要用time profile验证以后再尝试.
- 在需要用到SetNeedDisplay的时候,看能不能用setNeedsDisplayInRect: 代替,这个会节省很多开销!!!
- 学会用Instruments!!!
- 所有scrolling都需要 60 fps 小于 45fps用户依然能察觉。所以我们拥有的时间仅有: 16ms/frame
- 考虑优化功能的部分是在GPU还是CPU
1. CGDrawing 和 imageIO 是CPU
2. 渲染系统并不每一帧都工作在CPU上
3. 渲染本身是在GPU上的
4. 可以用OpenGL ES instruments 上的device utilization查看GPU使用情况
如果是100%左右的,肯定是GPU
如果是16%之类的,就应该是CPU
如果是GPU,有一个 Core Animation instruments可以查看
在scrolling 的 16ms 中,我们需要做的是
1. calculate new scrolling position
2. Prepare and commit animation
3. Render frame
减少blending,blending就是经常需要多重画的
self.layer.shouldRasterize = YES
在Time profiler 里,如果有很多时间被浪费在了spring board 里,spring board实际是render server的所在,所以,结论应该是,应用里有太多的layer了。
结论:
1、多在不同设备上测试动画、他们的区别可能在于GPU, CPU, Retina blabla
2、不同场景有不同的解决方法,到底是用drawRect? 还是用SubView?
3、测量、测试、迭代
解答三:
- UITableViewCell里不要添加太多subview,最好只添加一个cellview。
- UITableViewCell 上的子View的opaque属性设为YES。其实默认也是不透明。UITableViewCell尽量不要包含透明的子View。
- 在cellview里,重写drawRect函数绘制UITableViewCell的内容。
- 在绘制字符串时,尽可能使用drawAtPoint: withFont:,而不要使用更复杂的drawAtPoint:(CGPoint)point forWidth:(CGFloat)width withFont:(UIFont *)font lineBreakMode:(UILineBreakMode)lineBreakMode; 如果要绘制过长的字符串,建议自己先截断,然后使用drawAtPoint: withFont:方法绘制。
- 在绘制图片时,尽量使用drawAtPoint,而不要使用drawInRect。drawInRect如果在绘制过程中对图片进行放缩,会特别消耗CPU。
- 如果绘制cell过程中,需要下载cell中的图片,建议在绘制cell一段时间后再开启图片下载任务。譬如先画一个默认图片,然后在0.5S后开始下载本cell的图片。
- 即使下载cell 图片是在子线程中进行,在绘制cell过程中,也不能开启过多的子线程。最好只有一个下载图片的子线程在活动。否则也会影响UITableViewCell的绘制,因而影响了UITableViewCell的滑动速度。(建议结合使用NSOpeartion和NSOperationQueue来下载图片,如果想尽可能找的下载图片,可以把[self.queuesetMaxConcurrentOperationCount:4];)
- 最好自己写一个cache,用来缓存UITableView中的UITableViewCell,这样在整个UITableView的生命周期里,一个cell只需绘制一次,并且如果发生内存不足,也可以有效的释放掉缓存的cell。
- 不要将tableview的背景颜色设置成一个图片。这回严重影响UITableView的滑动速度。在限时免费搜索里,我曾经翻过一个错误:self.tableView_.backgroundColor = [UIColorcolorWithPatternImage:[UIImageimageNamed:@"background.png"]]; 通过这种方式设置UITableView的背景颜色会严重影响UTIableView的滑动流畅性。修改成self.tableView_.backgroundColor = [UIColor clearColor];之后,fps从43上升到60左右。滑动比较流畅。
- cell的行高不是固定值,需要计算,则要尽可能缓存行高值,避免重复计算行高。这里指的是UITableViewDelegate里的行高函数。
解答四: