下次自动登录
现在的位置:
& 综合 & 正文
问答 ——如何加强 iOS 里的列表滚动时的顺畅感？
如果你想要如丝般顺滑的效果，那么：1、每次都看一下有没有能重用的 cell，而不是永远重新新建（这个是 UITableView 的常识）2、Cell 里尽量不要用 UIView 而是全部自己画3、图片载入放到后台进程去进行，滚出可视范围的载入进程要 cancel 掉,需要显示多大图片就加载多大的图。比如图片墙，如果接口返回的图片没有小图，可以用程序处理成小图缓存起来，然后实际加载小图，这样可以很大程度加快滚动时的渲染速度，提高运行效率，注意，这里说的处理成小图不是UIImageView压缩成小图，而是直接把UIImage处理成小图，因为UIImageView虽然显示出了小图，但实际上渲染的还是大图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好再用。
【上篇】【下篇】如何加强 iOS 里的列表滚动时的顺畅感_百度知道
如何加强 iOS 里的列表滚动时的顺畅感
我有更好的答案
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条，可以找来看看）。
采纳率：95%
来自团队：
申明：以下回答摘自南峰子技术博客的一篇文章，非原创内建方法我相信大多数阅读这篇文章的人都知道这些方法，但一些人，即便是使用过这些方法，也没有以正确的姿式来使用它们。✻ ✻ ✻ ✻ ✻首先是重用cell/header/footer的单个实例，即便是我们需要显示多个。这是优化UIScrollView(UITableView的父类)最明显的方式，UIScrollView是由苹果的工程师提供的。为了正确的使用它，你应该只有cell/header/footer类，一次性初始化它们，并返回给UITableView。在苹果的开发文档里面已经描述了重用cell的流程，在这就没有必须再重复了。但重要的事情是：在UITableView的dataSource中实现的tableView:cellForRowAtIndexPath:方法，需要为每个cell调用一次，它应该快速执行。所以你需要尽可能快地返回重用cell实例。不要在这里去执行数据绑定，因为目前在屏幕上还没有cell。为了执行数据绑定，可以在UITableView的delegate方法tableView:willDisplayCell:forRowAtIndexPath:中进行。这个方法在显示cell之前会被调用。✻ ✻ ✻ ✻ ✻第二点也不难理解，但是有一件事需要解释一下。这个方法对于cell定高的UITableView来说没有意义，但如果由于某些原因需要动态高度的cell的话，这个方法可以很容易地让滑动更流畅。正如我们所知，UITableView是UIScrollView的子类，而UIScrollView的作用是让用户可以与比屏幕实际尺寸更大的区域交互。任何UIScrollView的实例都使用诸如contentSize、contentOffset和其它许多属性来将正确的区域显示给用户。但是UITableView的问题在哪？正如所解释的一样，UITableView不会同时维护所有cell的实例。相反，它只需要维护显示给用户的那些cell。那么，UITableView是如何知道它的contentSize呢？它是通过计算所以cell的高度之和来计算contentSize的值。UITableView的delegate方法tableView:heightForRowAtIndexPath:会为每个cell调用一次，所以你应该非常快地返回高度值。很多人会犯一个错误，他们会在布局初始化cell实例并绑定数据后去获取它们的高度。如果你想优化滑动的性能，就不应该以这种方式来计算cell的高度，因为这事难以置信的低效，iOS设备标准的60 FPS将会降低到15-20 FPS，滑动会变得很慢。如果我们没有一个cell的实例，那如何去计算它的高度呢？这里有一段示例代码，它使用类方法，并基于传入的宽度及显示的数据来计算高度值:可以用以下方式来使用上面这个方法返回高度值给UITableView:你在实现这一切的时候能获得了多少乐趣呢？大多数人会说没有。我没有保证过这事很容易。当然，我们可以构建我们自己的类来手动布局和计算高度，但有时候我们没有足够的时间来做这件事。你可以在Telegram的iOS应用代码中找到这种实现的例子。从iOS 8开始，我们可以在UITableView的delegate中使用自动高度计算，而不需要实现上面提到的方法。为了实现这一功能，你可能会使用AutoLayout，并将rowHeight变量设置为UITableViewAutomaticDimension。可以在StackOverflow中找到更多详细的信息。尽管可以使用这些方法，但我强烈建议不要使用它们。另外，我也不建议使用复杂的数学计算来获取cell的高度，如果可能，只使用加、减、乘、除就可以。但如果是AutoLayout呢？它真的跟我所说的一样慢么？你可能会很惊讶，但这是事实。如果你想让你的App在所有设备上都能平滑的滚动，你就会发现这种方法难以置信的慢。你使用的子视图越多，AutoLayout的效率越低。AutoLayout相对低效的原因是隐藏在底层的命名为”Cassowary“的约束求解系统。如果布局中子视图越多，那么需要求解的约束也越多，进而返回cell给UITableView所花的时间也越多。哪一个更快呢：使用少量的值来执行基本的数学计算，还是找一个求解大量线性等式或不等式的系统么？现在想像一下，用户想要快速地滑动，每个cell的自动布局也执行着疯狂的计算。✻ ✻ ✻ ✻ ✻使用内建方法优化UITableView的正确方法是：重用cell实例：对于特殊类型的cell，你应该只有一个实例，而没有更多。不要在cellForRowAtIndexPath:方法中绑定数据，因为在此时cell还没有显示。可以使用UITableView的delegate中的tableView:willDisplayCell:forRowAtIndexPath:方法。快速计算cell高度。对于工程师来说这是常规工作，但你将会为优化复杂cell的平滑滑动所付出的耐心而获取回报。具体可以搜索南峰子的技术博客
为您推荐：
其他类似问题
换一换
回答问题，赢新手礼包
个人、企业类
违法有害信息,请在下方选择后提交
色情、暴力
我们会通过消息、邮箱等方式尽快将举报结果通知您。如何加强 iOS 里的列表滚动时的顺畅感_百度知道
如何加强 iOS 里的列表滚动时的顺畅感
我有更好的答案
在加载表格时，做的事情越少，就越流畅。重用，cell必须重用，而且，要尽最大的可能重用。能在创建表格时设置的值就不要放到表格重用以后再来设置。动态计算高度的，如果计算过程比较复杂，最好能将值缓存起来，避免再次计算。基本上做到这两点，就OK了。
采纳率：71%
1、关于图片的加载：
UIImageView 是由CALayer, UIImage-&CGImage 构成的，CGImage 在加载的时候不会
解码图像，只有在第一次用的时候才会解码图像(Lazy Loading)。所以，尽量用
UIImageView 不要直接把图像画在 drawrect:iOS本身对于PNG文件进行了很多优化：例如（这个我怕翻不太准）：Premultiply alpha, and byte-swapTurn off some PNG compression modesAllow 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还是CPU1. CGDrawing 和 imageIO 是CPU2. 渲染系统并不每一帧都工作在CPU上3. 渲染本身是在GPU上的4. 可以用OpenGL ES instruments 上的device utilization查看GPU使用情况如果是100%左右的，肯定是GPU如果是16%之类的，就应该是CPU如果是GPU，有一个 Core Animation instruments可以查看在scrolling 的 16ms 中，我们需要做的是1. calculate new scrolling position2. Prepare and commit animation3. Render frame减少blending，blending就是经常需要多重画的self.layer.shouldRasterize = YES在Time profiler 里，如果有很多时间被浪费在了spring board 里，spring board实际是render server的所在，所以，结论应该是，应用里有太多的layer了。结论：1、多在不同设备上测试动画、他们的区别可能在于GPU, CPU, Retina blabla2、不同场景有不同的解决方法，到底是用drawRect? 还是用SubView？3、测量、测试、迭代
为您推荐：
其他类似问题
ios的相关知识
换一换
回答问题，赢新手礼包
个人、企业类
违法有害信息,请在下方选择后提交
色情、暴力
我们会通过消息、邮箱等方式尽快将举报结果通知您。如何加强 iOS 里的列表滚动时的顺畅感_百度知道
如何加强 iOS 里的列表滚动时的顺畅感
我有更好的答案
1、关于图片的加载：UIImageView 是由CALayer, UIImage-&CGImage 构成的，CGImage 在加载的时候不会解码图像，只有在第一次用的时候才会解码图像(Lazy Loading)。所以，尽量用UIImageView 不要直接把图像画在 drawrect:iOS本身对于PNG文件进行了很多优化：例如（这个我怕翻不太准）：Premultiply alpha, and byte-swapTurn off some PNG compression modesAllow 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还是CPU1. CGDrawing 和 imageIO 是CPU2. 渲染系统并不每一帧都工作在CPU上3. 渲染本身是在GPU上的4. 可以用OpenGL ES instruments 上的device utilization查看GPU使用情况如果是100%左右的，肯定是GPU如果是16%之类的，就应该是CPU如果是GPU，有一个 Core Animation instruments可以查看在scrolling 的 16ms 中，我们需要做的是1. calculate new scrolling position2. Prepare and commit animation3. Render frame减少blending，blending就是经常需要多重画的self.layer.shouldRasterize = YES在Time profiler 里，如果有很多时间被浪费在了spring board 里，spring board实际是render server的所在，所以，结论应该是，应用里有太多的layer了。结论：1、多在不同设备上测试动画、他们的区别可能在于GPU, CPU, Retina blabla2、不同场景有不同的解决方法，到底是用drawRect? 还是用SubView？3、测量、测试、迭代
采纳率：88%
来自团队：
为您推荐：
其他类似问题
ios的相关知识
换一换
回答问题，赢新手礼包
个人、企业类
违法有害信息,请在下方选择后提交
色情、暴力
我们会通过消息、邮箱等方式尽快将举报结果通知您。webapp 滚动卡顿
[问题点数：50分，无满意结帖，结帖人a8673136]
webapp 滚动卡顿
[问题点数：50分，无满意结帖，结帖人a8673136]
不显示删除回复
显示所有回复
显示星级回复
显示得分回复
只显示楼主
2015年7月 Web 开发大版内专家分月排行榜第三
2015年7月 Web 开发大版内专家分月排行榜第三
匿名用户不能发表回复！|}