ios 提高 iPhone UITableView 滚动性能的技巧?
声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow
原文地址: http://stackoverflow.com/questions/1352479/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Tricks for improving iPhone UITableView scrolling performance?
提问by Jonah
I have a uitableview that loads fairly large images in each cell and the cell heights vary depending on the size of the image. Scrolling performance is decent, but can sometimes be jerky.
我有一个 uitableview 可以在每个单元格中加载相当大的图像,并且单元格高度取决于图像的大小。滚动性能不错,但有时会很不稳定。
I found these tips I found on the FieryRobot blog:
我在 FieryRobot 博客上找到了以下提示:
glassy-scrolling-with-uitableview
more-glassy-scrolling-with-uitableview
Does anyone have any tips for improving uitableview scrolling performance?
有没有人有任何提高 uitableview 滚动性能的提示?
回答by rpetrich
- Cache the height of the rows (the table view can request this frequently)
- Create a least-recently-used cache for the images used in the table (and invalidate all the inactive entries when you receive a memory warning)
- Draw everything in the
UITableViewCell
'sdrawRect:
if possible avoid subviews at all costs (or if you require the standard accessibility functionality, the content view'sdrawRect:
) - Make your
UITableViewCell
's layer opaque (same goes for the content view if you have one) - Use the reusableCellIdentifier functionality as recommended by the
UITableView
examples/documentation - Avoid gradients/complicated graphical effects that aren't pre-baked into
UIImage
s
- 缓存行的高度(表视图可以频繁请求)
- 为表中使用的图像创建最近最少使用的缓存(并在收到内存警告时使所有非活动条目无效)
- 如果可能,在
UITableViewCell
's 中绘制所有内容,drawRect:
不惜一切代价避免子视图(或者如果您需要标准的辅助功能,则在内容视图中drawRect:
) - 使你
UITableViewCell
的图层不透明(如果你有的话,内容视图也是如此) - 使用
UITableView
示例/文档推荐的 reusableCellIdentifier 功能 - 避免未预先烘焙到
UIImage
s 中的渐变/复杂图形效果
回答by Shaggy Frog
- If you are subclassing
UITableViewCell
, don't use a Nib, write it in code instead. It's much faster than loading Nib files. - If you're using images, make sure you're caching them so you don't have to load from file more than once for each (if you have the memory -- you'd be surprised how much space images take up).
- Make as many elements opaque as possible. Similarly, try not and use images with transparency.
- 如果你是子类化
UITableViewCell
,不要使用 Nib,而是用代码编写它。它比加载 Nib 文件快得多。 - 如果您正在使用图像,请确保您正在缓存它们,这样您就不必为每个文件多次加载(如果您有内存——您会惊讶于图像占用了多少空间)。
- 使尽可能多的元素不透明。同样,尽量不要使用透明的图像。
回答by beno
The developer behind Tweetie has written extensively about this and has some code that demonstrates how it was done for that app. Basically, he/she advocates one custom view per table cell, and drawing it manually (rather than subviewing with Interface Builder, among other options).
Tweetie 背后的开发人员对此写了大量文章,并有一些代码演示了该应用程序是如何完成的。基本上,他/她提倡每个表格单元格一个自定义视图,并手动绘制它(而不是使用 Interface Builder 进行子查看,以及其他选项)。
fast-scrolling-in-tweetie-with-uitableview
Also, Apple has updated its own sample code for TableView in its TableViewSuite tutorials (maybe in response to this?)
此外,Apple 在其 TableViewSuite 教程中更新了自己的 TableView 示例代码(可能是为了回应这个?)
回答by HymanyJohnson
#1 performance killer for UITableView scrolling is drawing shadows on any cell view layer, so if scrolling performance matters then don't do shadows unless basically it doesn't slow down your main thread.
UITableView 滚动的 #1 性能杀手是在任何单元格视图层上绘制阴影,所以如果滚动性能很重要,那么不要做阴影,除非它基本上不会减慢主线程的速度。
thought this had to be said since none of the accepted answers made mention of shadows and layers. :+)
认为必须这样说,因为没有一个公认的答案提到阴影和图层。:+)
回答by Nirav Bhatt
Any problem with UITableView
scrolling performance can be solved using techniques already described in other answers. However many a times sluggish performance is caused by something inherently erroneous, or repetitive.
UITableView
滚动性能的任何问题都可以使用其他答案中已经描述的技术来解决。然而,很多时候性能低下是由一些固有的错误或重复引起的。
The fact that UITableView
reuses the cells, and the fact that each cell may need its own image - together makes the solution bit complex. From how it's being solved the general way, here I summarize things that should be taken care of:
这一事实UITableView
重用细胞,而事实上,每一个细胞都需要有自己的形象-一起使得该解决方案有点复杂。从一般的解决方法来看,我在这里总结了应该注意的事项:
- Load data into data source - from REST / database. This step should be done on background, eventually using dispatch_async along with GCD queue.
- Create and initialize relevant data model objects and putting them inside an array
[tableView reloaddata]
- Inside
cellForRowAtIndexPath
, include code that will set data (text) from correct data model object of the array. - Now images maybe in the form of URL too, so this step might be little quirky because of cell reuse done by table view. The heart of the fact is to load once again image from device cache / URL using async queue, then set it to correct cell.image (whatever is your cell image property).
- 将数据加载到数据源 - 从 REST / 数据库。这一步应该在后台完成,最终使用 dispatch_async 和 GCD 队列。
- 创建并初始化相关的数据模型对象并将它们放入数组中
[tableView reloaddata]
- 在里面
cellForRowAtIndexPath
,包含将从数组的正确数据模型对象设置数据(文本)的代码。 - 现在图像也可能是 URL 的形式,所以这一步可能有点古怪,因为表格视图完成了单元格重用。事实的核心是使用异步队列从设备缓存/URL 再次加载图像,然后将其设置为正确的 cell.image(无论您的单元格图像属性是什么)。
To avoid problems, refer to this tutorial about lazy loading of imagesinside table view.
为避免出现问题,请参阅有关在表格视图中延迟加载图像的教程。