前言

随着App的用户界面的内容越来越丰富，再强的手机可能都无法同时渲染复杂的UI界面和保证流畅的体验。所以，我们这些程序猿=。=在写代码的时候就要注意，如何尽可能提高用户的操作流畅性。

之前的做的项目，青桔音乐iOS客户端里面的首页就是一个类似微信朋友圈的“动态”页面，大致如下：

如果是你，你会怎么实现这个页面呢？

这还用问，当然是用UITableView+自定义的UITableViewCell。

UITableView是可以滑动的，为了不让用户在滑动中感到有卡顿，该如何优化？下面，我就写一下我自己在做项目时的“经验”~

优化

主要分为以下几点：

• 只定义一种Cell。
• 提前计算并缓存每个Cell的高度。
• 提前创建真正显示的、需要加工的数据并缓存。
• 缓存View！
• 其它。

只定义一种Cell

乍一看，这个界面至少有3种样式的Cell，为什么只定义一种呢？

分析结构

仔细分析一下，页面中每个Cell的内容都有头像、标题、正文、评论、其它（歌曲、图片、歌手）。所以，从整体上看，每个Cell的结构是一致的！

重用=大致固定数量的Cell

并且，凡是认真研究过UITableView的人应该都知道，Apple已经为我们提供了Cell的重用，如用“registerNib:forCellReuseIdentifier”方法注册自定义Cell的Nib，然后在“cellForRowAtIndexPath”的时候用“dequeueReusableCellWithIdentifier”获取可以重用的Cell，所以，无论UITableView要显示内容有多少，真正创建出的Cell可能只有5、6个。

所以，我们完全可以只创建一种Cell，虽然这样一个Cell的“体积”可能会很大，但是介于Cell的数量不会很多，所以完全可以接受。

只定义一种Cell的好处

• 减少代码量，减少Nib文件的数量，统一一个Nib文件定义Cell，容易修改、维护。
• 基于Cell的重用，真正运行时铺满屏幕所需的Cell数量大致是固定的，设为N个。所以如果如果只有一种Cell，那就是只有N个Cell的实例；但是如果有M种Cell，那么运行时最多可能会是“M x N = MN”个Cell的实例，虽然可能并不会占用太多内存，但是能少点不是更好吗。

善用hidden隐藏（显示）Subview

既然只定义一种Cell，那该如何显示不同类型的内容呢？
答案就是，把所有不同类型的view都定义好，放在cell里面，通过hidden显示、隐藏，来显示不同类型的内容。如下图定义Cell：

图中的Subview1、Subview2、Subview3就是不同类型Cell的不同之处，所以我们在“cellForRowAtIndexPath”函数中，设置Cell的样式、内容时，就可以通过显示、隐藏这三个子view来显示。

毕竟，在用户快速滑动中，只是单纯的显示、隐藏subview比实时创建要快得多。

提前计算并缓存每个Cell的高度

开发过Android，用过Android的ListView以后，对UITableView需要提前计算Cell的高度很不适应。=。=

首先要确定的是，在iOS中，系统会先调用“tableView:heightForRowAtIndexPath:”获取每个Cell即将显示的高度，从而确定整个UITableView的布局。然后才调用“tableView:cellForRowAtIndexPath”获取每个Cell，我们也是在这里填充、设置Cell的。

所以，既然高度总会被用到，那就早早的在获取数据时就计算好吧！

在Model（Entity）中计算并保存Cell的高度

其实，在Model（Entity）中保存UI的参数是很奇怪的=。=（最好放在ViewModel中，就是MVVM模式的），我们的Entity可能就是下面的样子：

1
2
3
4
5
6
7
8
9
10
11
12
13

@interface DataEntity : NSObject


@property(copy, nonatomic) NSString *content;
@property(copy, nonatomic) NSString *title;


@property(assign, nonatomic) CGFloat cellHeight;


- (void)calculateCellHeight;

@end

这样，就不用在“tableView:heightForRowAtIndexPath:”中每次都计算了。

提前创建真正显示的、需要加工的数据并缓存

Cell中显示的内容，很多时候可能并不是直接从服务器拿到的数据，而是经过“加工”的数据。如本文中的“动态”也，每个Cell的标题、正文都有可点击的连接Link、表情图片等富文本内容，而我们一般用NSAttributeString类来显示。

既然每次都会用到，倒不如在获取到数据的时候就创建、加工好这些内容，等到需要现实的时候，直接拿来用不就行了。

所以，我们的Entity类可能变成下面这个样子:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

@interface DataEntity : NSObject


@property(copy, nonatomic) NSString *content;
@property(copy, nonatomic) NSString *title;


@property(assign, nonatomic) CGFloat cellHeight;


@property(strong, nonatomic) NSAttributedString *showTitle;
@property(strong, nonatomic) NSAttributedString *showContent;


- (void)calculateCellHeight;


- (void)setupShowTitileAndContent;

@end

这样，在“tableView:cellForRowAtIndexPath”中，我们直接拿showTitle、showContent来显示就好，不用再创建。

缓存View!

什么？缓存View？！

是的，当Cell中的部分View是非常独立的，并且不便于重用的，而且“体积”非常小，在内存可控的前提下，我们完全可以将这些view缓存起来！

方法当然也是将缓存的view放在Entity中~。

其它

当然，还有其他的优化方法，简单说一说：

• 尽量设置Cell的view为opaque，避免GPU对Cell下面的内容也进行绘制。
• 避免大量的图片缩放、颜色渐变等。
• 避免同步的从网络、文件获取数据（这个是必须的=。=）
• 用shadowPath创建阴影。
• 尽量减少subview的数量，如多用drawRect绘制元素，替代用view显示。
• 尽量显示“大小刚好合适”的图片资源。

总结

总的来说，就是：

缓存一切可以缓存的！就是“用空间替换时间”！

在UITableView的Delegate、DataSource方法中，减少任何不必要的操作

参考，推荐阅读

• 25 iOS App Performance Tips & Tricks
• Tricks for improving iPhone UITableView scrolling performance?
• How can I speed up a UITableView?

上一篇：Block类型变量-缓存Http请求与回调

下一篇：NSString的Copy与内存分配