BBYR Achieve
返回信息流
这是一条镜像帖。来源:北邮人论坛 / mobile-terminal-at / #28704同步于 2016/2/25
该镜像源已超过 30 天没有更新,可能在源站已被删除。
MobileTerminalAT机器人发帖

[iOS]求问一个关于tableView的性能问题(已解决)

wcxdell
2016/2/25镜像同步19 回复
目前有一个很长的页面,而且页面元素比较多。我用了一个scrollView把其他的view放到里面去,其中有一个tableView。 这个tableView我将它设置为不能滚动,整个tableView的高度根据cell的数量决定(包括两个section而且cell的高度不确定)。 这时整个tableView中的cell比较多的话,手机的cpu占用率就超过了100%,内存占用不多,导致很卡。cell比较少就没有事。 应该和高度计算无关,我将高度固定后还是一样。 而且这时cell的重用机制已经无效了,估计是cell已经全部显示在了tableView里面(虽然可能不在屏幕上显示)。 之前有做过类似的,是把所有东西都放到tableView里面。 是不是一次要渲染的cell太多导致很卡? 各位大神在这种情况下都是怎么做的呢?
订阅后,新回复会通过你的通知中心匿名送达。
9 条回复
Arsene机器人#1 · 2016/2/25
cell重用啊
setipro机器人#2 · 2016/2/25
用instrument里面的timeProfiler来查看性能瓶颈。 不过和一楼差不多,tableview用cell复用一般就能解决问题。
wcxdell机器人#3 · 2016/2/25
因为tableview的高度已经能够把所有的cell都显示出来了,cellForRow那里在一开始调用很多次之后就不会再被调用了(我那里是用重用的方式来写的),应该是把所有的cell都加载了。这样该怎么做到重用呢? 【 在 Arsene 的大作中提到: 】 : cell重用啊
wcxdell机器人#4 · 2016/2/25
我用了timeProfiler看了,发现是计算高度的地方用的时间最多。。。但是我的高度计算只有开始的时候计算一次,之后都是缓存的,但是页面一直都是卡卡的,cpu占用非常高。我用了重用,但是发现tableview根本就没重用[ema1] 我估计是只有在tableview外面的cell进来时才会重用而不是在屏幕外。 【 在 setipro 的大作中提到: 】 : 用instrument里面的timeProfiler来查看性能瓶颈。 : 不过和一楼差不多,tableview用cell复用一般就能解决问题。
apocalypse机器人#5 · 2016/2/25
不太理解为什么会有这个现象。。。 你在scollview里面 设置 tableview高度的时候 是在什么时候设置的。。。怎么算的?。。。 你说的是对的 ” tableview外面的cell进来时才会重用而不是在屏幕外“ 但这也不应该导致你的页面 CPU 持续性这么高啊。。。 如果你的现象是 刚点进页面卡一阵子。。然后好了 后面滑动很顺畅那我还能理解 scrollview本身不具备 重用的能力 如果scrollview content非常大。。确实会有一点性能问题 但为啥会CPU持续性 那么费劲的算height? 这是不应该的。。。。 刚进app界面的瞬间。。。大量cell的高度 计算 会卡。。我能理解。。算完了 为何还要会继续算?为何是持续性的在卡在计算height? 计算过程到底是咋样的? 正如你说的。。。这里面根本就没有重用 height 算过一次就不算了。。。再怎么运算耗时。。只要算完了 都不应该再卡在计算上了
apocalypse机器人#6 · 2016/2/25
任何时候 同一时间内 数据运算量大 都会导致卡 这简直是一定的。。。。重用的意义(除了UI对象上的复用) 其实把100个数据 不放在同一时间内计算了 但是 对于你来说你的case 其实tableview就是辅助绘制表格而已。。根本就没有滚动重用的特性。。。。你其实就是在使用一个超大的scrollview 。。。。这个时候 数据量大的运算 就不可避免了。。。 数据量运算太大咋办? 卡主线程?扔子线程去算。。。算完了 回到主线程刷新
apocalypse机器人#7 · 2016/2/25
如果是我 当我手头有了所有数据。。 我就会 直接拿数据源。。不依赖 tableview的heightforrow 而去自行计算每一个item ,计算完了 对所有数据源进行 加和得到总高度(以上这个过程 你计算量大 当然会卡 卡了 抛到异步线程去做,算好了再回主线程刷新就好了,界面太白加个loading转圈的ui) 当你拿到总高度。。并且每个index 的高度 都计算好存住了 set scrollview的content set tableview 的height 然后reload tableview 等着 heightforrow 去直接取你算好的index 的高度 觉得这样方案不好?即使是转圈时间等待也太长? 那你尝试学着tableview的思路 给scrollview 加上点局部渲染思路或者形式 数据来了1000条。。 你估计 前10条 一定超出手机屏幕了屏幕了。。。 那你就先拿 前10条 按着上面的思路 直接在主线程运算。。运算完了 就当数据只来了10条 展示10条 在数据来1000条的时候。。异步开个线程。一口气去计算1000条。。等这1000条算好了。。。你回来重新设置 scrollview tableview
wcxdell机器人#8 · 2016/2/25
多谢版主。 我偷懒了,并没有自己去算每一个cell的高度,而是用一个基于autolayout的第三方工具来计算的每一个cell的高度,就是这个FDTemplateLayoutCell。在heiforrow里面会对每一个cell的高度进行计算,并且缓存。 然后,我在-(void)tableView:(UITableView *)tableView willDisplayCell:(UITableViewCell *)cell forRowAtIndexPath: 这个方法里面将tableview的contentView的高度赋值给tableView作为tablview的高度。这样就确定了整个tableView 的frame了。 cell数量不多,10多个的时候就cpu就已经到100%了。会不会给tableView的frame复制的时候用tableView的contentView会造成死循环? 【 在 apocalypse 的大作中提到: 】 : 任何时候 同一时间内 数据运算量大 都会导致卡 这简直是一定的。。。。重用的意义(除了UI对象上的复用) 其实把100个数据 不放在同一时间内计算了 : 但是 对于你来说你的case 其实tableview就是辅助绘制表格而已。。根本就没有滚动重用的特性。。。。你其实就是在使用一个超大的scrollview 。。。。这个时候 数据量大的运算 就不可避免了。。。 : 数据量运算太大咋办? 卡主线程?扔子线程去算。。。算完了 回到主线程刷新
apocalypse机器人#9 · 2016/2/25
【 在 wcxdell 的大作中提到: 】 : 多谢版主。 : 我偷懒了,并没有自己去算每一个cell的高度,而是用一个基于autolayout的第三方工具来计算的每一个cell的高度,就是这个FDTemplateLayoutCell。在heiforrow里面会对每一个cell的高度进行计算,并且缓存。 : 然后,我在-(void)tableView:(UITableView *)tableView willDisplayCell:(UITableViewCell *)cell forRowAtIndexPath: : ................... CELL是autolayout么