如何加强iOS里的列表滚动时的顺畅感

还是知乎给力
http://www.zhihu.com/question/20382396

如何加强 iOS 里的列表滚动时的顺畅感？修改

例如 Path 的列表滚动感觉非常流畅，没有 UITableView 的迟滞感（当然是指同样多子 view 的情况下）。想知道 Path 用的是什么方案？暂时只想到可能是完全纯自绘。其他还有吗？希望有相关经验者不吝赐教。修改

举报添加评论 分享 • 邀请回答

按票数排序

5 个回答

赞同101
反对，不会显示你的姓名

徐哲，天天的就是和
iOS 打交道

曾赟、王宇、杨达浪 等人赞同

如果你想要如丝般顺滑的效果，那么：

1、每次都看一下有没有能重用的 cell，而不是永远重新新建（这个是 UITableView 的常识）

2、Cell 里尽量不要用 UIView 而是全部自己画

3、图片载入放到后台进程去进行，滚出可视范围的载入进程要 cancel 掉

4、圆角、阴影之类的全部 bitmap 化，或者放到后台 draw 好了再拿来用

5、Cell 里要用的数据提前缓存好，不要现用现去读文件

6、数据量太大来不及一次读完的做一个 load more cell 出来，尽量避免边滚边读数据，这样就算是双核的 CPU 也难保不会抽

做到以上6条的话，应该就能做出很顺畅的滚动了（现在的 Twitter 官方客户端的原作者写过一篇文章，总结起来也无非就是我说的前3条，可以找来看看）。

Path 2.5 的那个滚动说实在的不是很顺畅，图片显示出来的时候都会抽一下，他们还有很大的改进余地。

对于3的补充说明：UIImageView 的载入是惰性的说法，是对的。[UIImage imageWithContentOfFile:] 出来的 UIImage 其实并没有真正把文件读入内存，而是要等到用的时候才会去读。但问题就在于 UIImageView 试图去 draw 图片的时候，它读文件、渲染也是在主线程里做的，所以你要读入的图片如果很大（比如 iPad3 上的 @2x 图），不管 iOS 做了何种优化，这一步是一定要卡的。这也就是为什么我说图片要放到后台进程读出来、scale好再用。

2012-08-02 16
条评论

赞同16
反对，不会显示你的姓名

李乐佳，A
Geek

李想、张增明、胡强 等人赞同

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: 代替，这个会节省很多开销！！！

2、关于Scrolling

学会用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、测量、测试、迭代


工作时间，先贴上来，稍后再整理=。=

2012-08-01 4
条评论

赞同2
反对，不会显示你的姓名

隋世聪，iPhone
Developer

asmore、陶智 赞同

自己draw不会对滑动性能有明显提升，因为UIView本身是轻量级的，而且UIView自身的绘制已经被优化到了极致，大部分时候自己draw的不会比UIView自身画得快，跟绘图的时间相比，UIView自身的初始化的性能损耗可以忽略不记。

rasterize是必备的，但对第一次绘制的cell没有作用。而且rasterize再cell的外观改变后，就要重画，对于内容可变的cell，rasterize反而会降低性能。

补充几点：

1.中文的绘制比英文要低效很多，如果可能，尽可能的让中文少显示一些，比如说在cell中加入一个“展开”按钮，只有用户点击展开才能看到较大量的文字内容。

2.如果可以的化，要让cell和tableview opaque，透明的view比较损耗性能。

3.尽可能的使用1:1像素的图片，不要进行缩放，如果是与web端交互的应用，最好能专门为ios客户端设置拉取小图的接口。

2012-08-10 添加评论

赞同2
反对，不会显示你的姓名

赵永鹏，移动开发开发者

godlaugh、雨中泪雪人 赞同

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里的行高函数。

如果做到以上10点，则UITableView 滑动的fps可以达到60 fps。滑动非常顺畅...

2012-08-08 添加评论

赞同1
反对，不会显示你的姓名

林博，iOS程序员，熟悉越狱开发。

小东 赞同

1、Path里面有多种Cell，使用了多个CellIdentifier，并将其放在同一个TableView里面来实现多样式的载入；

2、Path并没有避免透明背景的绘制，所以在透明背景的Label很多的情况下会比较卡，而当整个页面都是图片和评论（评论是白色背景的），流畅度会有明显的提升；

3、Path的图片比较大，多为延迟载入；

4、评论中小头像的圆角使用图片遮盖来实现，避免了过多的绘制圆角。

2012-08-01 2
条评论 感谢 分享 收藏 • 没有帮助 • 举报