性能问题 about zlcollectionview HOT 4 CLOSED

可以试试我这个，悬浮情况下性能依然高效😁(主要是cpu占用率)
https://github.com/donggelaile/HDCollectionView

from zlcollectionview.

可以试试我这个，悬浮情况下性能依然高效😁(主要是cpu占用率)
https://github.com/donggelaile/HDCollectionView

已好久没做ios开发了，如有空的话能否帮我贡献下代码

from zlcollectionview.

可以试试我这个，悬浮情况下性能依然高效😁(主要是cpu占用率)
https://github.com/donggelaile/HDCollectionView

已好久没做ios开发了，如有空的话能否帮我贡献下代码

你好，应您的请求，我下载并调试了您的代码。
发现两个问题:
1、悬浮时的滑动性能，这个已经有人反馈了。可以将最后一个section的数量返回1000来放大这个问题。
2、悬浮时，滑出去的header在滑回来时会无法正确归位。

对于1，我这边加了判断，并在合适的时机自动进行布局的刷新，而非目前的滑动实时刷新。
对于2，我新增保存了headerAtt的原始frame并在对应时机赋会原值。解决了此bug

经过优化后，悬浮后的cpu使用率由90%+降到了50%以下(6s真机)。稍后会提交一个pr

不过，当数据量更大时，比如20000。滑动时CPU依然在90%以上。因为- (NSArray *)layoutAttributesForElementsInRect:(CGRect)rect函数依然需要优化。
优化的方向，作者可以参考IGList，先找到对应的段，然后在对应段中查找对应属性。或者参考我的HDCollectionView的二分查找(使用二分查找时需要注意数组是否有序及是否漏查)。目前直接返回self.attributesArray肯定在大数据量时会卡顿.

另外，作者的这套代码有点年久失修的感觉。
1、preparelayout中的代码太长了，急需拆分。(如果遇到了bug,一般情况下真不好改。。。)
2、另外给出的接口全部是delegate回调，如果真实项目中像VerticalViewController那样设置数据源的话，以后的维护肯定比较困难。（比如需求要求交换第一段和第二段样式的顺序，需要改动的代码一大堆。。。）
所以如果使用的话，建议先做一层baselistmodel包装。具体可以参考https://juejin.im/post/5d50c664f265da03e71ae6a6

from zlcollectionview.

感谢了，已提交

from zlcollectionview.