OC

Knowledge OS
登录 注册
全部话题 移民 创业 iOS Mac Objective-C Swift Android 招聘 求职

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

zedzhao
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的状态下什么都不做

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

登录 或者 注册

AltStyle によって変換されたページ (->オリジナル) /