iOS 关于tableview性能优化概述

时间:2021-07-07 23:29:33

随着项目越做越多,对app的性能慢慢的有了一些要求。

下面我们一起探讨下对tableview的性能优化问题。

当说到这里又会说一些题外话。之前写过一点关于代码自动布局方面的东西。讨论过基于autolayout的布局是使用XIB,SB好一些还是纯代码写好一些。

当然这个问题仁者见仁智者见智,各有各的选择。但是在我看来我还是会选用纯代码布局。原因有一下几点:

1.项目大小问题:当使用SB或者XIB布局时,我们的项目往往会比纯代码布局大的多,这个大多少就要看XIB或者SB文件的多少了。

2.修改布局是速度问题:每当打开XIB或者SB时屏幕上总是会显示一个大大的菊花,等待时间长短不一,做为猿类的我们来说很是不能忍。若使用代码就不会存在这一点。

3.多人开发时:当多人开发时,SIB或者SB上界面的连线与控件问题,当你修改别人的xib或者sb时看着很头疼,往往有种想推了重来的冲动。在纯代码的情况下,有人可能就会反驳,纯代码布局,布局代码那么多看着也头疼,但是界面布局的代码肯定会写在一起,写好注释这一点也就不存在问题了,修改起来也很直接。

以上就是我选择纯代码布局的理由。(仅个人看法不喜勿喷)

 

下面开始我们这次讨论的正题:关于tableview性能优化问题;

以下仅为个人观点,如有错误请大家指出。

核心点:让cell尽量快的本生成出来。也就是让- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath这个函数以及在它之前执行的函数快速的被执行。

让我们看下一般情况下- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath之前会执行哪些函数:

1.- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section;

2.- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath;

我们这里就不去讨论有多个section的情况。

为了达到我们我核心点的目的,那么在我们这个情况下,我们就只能在这3个函数中去想办法让他们快速的执行完成。

1.- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section;

2.- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath;

这两个函数,我们的优化就是对这两个函数内部的算法尽量的精简。对函数1.我们尽量让它没有计算的步奏直接给出具体有多少row的值。这样就缩短了他执行的时间,从而达到优化的目的

对于函数2.计算每个row的高度。这个高度的计算我们可以放在cell中去执行。把这个具体的高度再传到这个函数中,总之一句话就是让他尽量快的被执行完成。

3.- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath 对于这个函数才是我们对tableview性能优化的重中之重。

通常我们都是在这个函数中去给cell赋值。导致了这个函数执行时间比较长。在滑动tableview的时候会出现卡顿。

为了让- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath函数快速的执行完成,那么我们讲cell的赋值操作放在其他函数中进行不在此函数中进行。

- (void)tableView:(UITableView *)tableView willDisplayCell:(UITableViewCell *)cell forRowAtIndexPath:(NSIndexPath *)indexPath我们把cell的赋值放到这个函数中去执行。

当我们完成这些操作后。我们的性能优化可以说已经完成了50%左右了。那么大家会说那剩下的50%在哪儿喃?

剩下的50%就是对cell的布局优化。

众所周知现在布局分为直接布局和相对布局两种方式。这两种方式又分为代码布局和可视化布局。

代码布局和可视化布局在文章的开头基本上就说了再次就不再重复了

系统读取XIB或者SB的速度肯定要低于读取代码的速度。

现在我们再来比较下相对布局和直接布局。

相对布局我相信大家都知道他的布局方式是基于父视图的一种布局方式;也就是说这种布局方式是父视图布局完成后才能进行子视图的布局。

那么直接布局他是采用坐标点的形式对控件进行布局,就没有相对布局的限制。

看到这里大家可能就已经发现,那种布局的方式系统的执行速度很更快一些了吧。

那么当我们做好以上几个方面的优化之后,那么我相信在大多数情况下你的tableview性能是绝对能达到要求的。

下面粘贴一点自己的代码片段:

iOS 关于tableview性能优化概述

iOS 关于tableview性能优化概述