使用UICollectionView实现瀑布流的性能问题。

全部话题移民创业 iOS Mac Objective-C Swift Android 招聘求职

使用UICollectionView实现瀑布流的性能问题。

由 zedzhao 发布于 2013年09月08日
无人欣赏。

Layout 用的是 CHTCollectionViewWaterfallLayout，图片都是从网络下载。图片加载使用SDWebImage~ 最后出来的效果滑动时会有点卡。应该还是加载图片的线程过多阻塞到UI线程了。

我试了在cellForIndex中判断当view在滑动时不去加载图片，但是最后的效果不太好，配合SDWebImage似乎会有很多图片没缓存到。请教下大家有没有遇到过类似的问题？

万分感谢。

共9条回复

回复楼长

tinyfool 回复于 2013年09月08日

你可以参考一下UITableView的传统例子，LazyTableImages，虽然不完全相同，但是机理应该是一样的

回复 2楼

abigfrog 回复于 2013年09月08日

图片异步加载就不会影响到性能

回复 3楼

yangjie6020 回复于 2013年09月09日

嗯异步加载我之前实现一个异步加载很简单的不过要是高性能还是要仔细规划一下

回复 4楼

elepone 回复于 2013年09月09日

我再补充一点儿，就是异步图片加载要在CollectionView.dragging==NO和CollectionView.Decelerating==NO的时候。

回复 5楼

WeZZard 回复于 2013年09月09日

你应该用Instrument来看到底是哪里占时间多。我最近的一个例子，写一个Date Picker，要 tile 很多日期，iPhone5一屏有50多个，开始非常卡。因为WWDC 2013上说UIFontDescriptor的系统开销相当小，我没想是这点，后来用Instrument一看，好家伙，UIFontDescriptor的一个方法调用居然占了40%的时间，后来缓存一下生成的UIFont对象而不是每次都从UIFontDescriptor生成就好了。

回复 6楼

tinyfool 回复于 2013年09月09日

5楼 @WeZZard 任何的卡顿，首先是UI任务和非UI任务没有分开，这个先要解决，然后再说性能问题

回复 7楼

WeZZard 回复于 2013年09月09日

6楼 @tinyfool 恩，想了下，确实应该是这个优化顺序，可能我自己这方面遇到得不多吧，没有产生这种感悟，一般我会习惯打开Instrument看占用时间，然后再想办法优化。

回复 8楼

abigfrog 回复于 2013年09月10日

再提供一个思路可以自己子类化UIImageView,在这里实现图片的异步加载和缓存这样在其他地方也可以复用了

回复 9楼

zedzhao 回复于 2013年09月10日

SDWebImage肯定是已经实现了异步下载图片的。我估计应该有两个问题。

这个瀑布流一屏差不多要12张以上的图片，(这里线程过多会有问题么？）
尺寸要等加载好了自己算，算好了存一个数组，然后在heightForCell中返回各个cell的高度，然后再调用reloadAtIndexPath去调整layout。(感觉这里也不太合理)。
LazyTableImages里面的思路不错，在scrolling的状态下什么都不做

缓存到还没用过~~~不知道会不会很复杂~~有空研究下~~

请登录或者注册。

发布新帖