浅析iOS开发中UITableViewCell的复用机制

写在前面

UITableView是iOS开发中一种非常常用的组件,在主流App中几乎可以看到(微信和QQ的聊天列表等)。这篇文章主要探讨UITableView的数据载体——UITableViewCell的一些相关内容

UITableViewCell是什么

UITableViewCell就是UITableView展示数据的基本单位 可以理解为单元格
此处蓝色背景的为已经填充的Cell 剩下的位置是没有Cell的
浅析iOS开发中UITableViewCell的复用机制_第1张图片
实现代码也比较简单

/* 此处代码返回的是UITableViewCell的数量 实际使用中应该与数据源绑定 此处写死 */
- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section {
    return 10;
}

/* 此处代码返回的是根据indexPath的位置 返回该indexPath应该展示的Cell */
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
    UITableViewCell* cell = [[UITableViewCell alloc] init];
    cell.textLabel.text = @"UITableViewCell";
    cell.backgroundColor = UIColor.cyanColor;
    
    return cell;
}

UITableViewCell的复用机制

上面的代码这样写,就容易引起一些问题
根据每行都生成一个新的Cell,当行数非常多的时候,将会占用非常大的内存,出于这方面的考虑,Apple引入了UITableViewCell的复用机制,先看这段代码

- (void)setupView {
    
    _tableView = [[UITableView alloc] initWithFrame:[[UIScreen mainScreen] bounds]];
    _tableView.delegate = self;
    _tableView.dataSource = self;
    
    /* 要先在UITableView中注册要复用的Cell类型 并设置一个id*/
    [_tableView registerClass:[UITableViewCell class] forCellReuseIdentifier:@"reuse"];
    
    [self.view addSubview:_tableView];
}

/* 此处代码返回的是UITableViewCell的数量 实际使用中应该与数据源绑定 此处写死 */
- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section {
    return 1000;
}

/* 此处代码返回的是根据indexPath的位置 返回该indexPath应该展示的Cell */
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {

    /* 此处从UITableView中的复用队列中取cell 使用的id要与注册时使用的id相同*/
    UITableViewCell* cell = [tableView dequeueReusableCellWithIdentifier:@"reuse"];
    
    printf("cell---------%ld被添加到视图中了\n", (long)indexPath.row);
    NSLog(@"%@", cell.description);
    
    cell.textLabel.text = @"UITableViewCell";
    cell.backgroundColor = UIColor.cyanColor;
    
    return cell;
}

此处是复用机制的实现 特意使cell放到了1000个,下面看打印结果
浅析iOS开发中UITableViewCell的复用机制_第2张图片
最终打印了20个 即UITableView在启用复用机制后 会事先载入两倍于屏幕的cell数量
浅析iOS开发中UITableViewCell的复用机制_第3张图片
下面我们向下拉动屏幕 会发现如下打印结果:
浅析iOS开发中UITableViewCell的复用机制_第4张图片
其实会发现和这些cell的地址与cell0-4的地址是相同的,证明发生了复用

如果不使用复用机制会是下面的结果
浅析iOS开发中UITableViewCell的复用机制_第5张图片
可以发现地址变了 不再是复用

总结一下
在UITableView的滑动过程中如果启用了复用机制,会将滑出屏幕的cell出队 等待下一次的使用,队列中的cell数量一定,通过来回反复出队入队实现复用

UITableViewCell的其他的一些简单的性能优化问题

离屏渲染(Off-Screen Rendering)

(其实这一块我也是一知半解,还需要不断的加强学习)
代码被装入内存执行过程中,在CPU中完成对视图布局的计算(此处应包含对AutoLayout的计算),布局属性计算完成后,提交到GPU渲染,渲染成图形再提交到显示器进行展示

离屏渲染就是由于用户做了一些对视图图层的操作,如圆角、阴影等,这些操作会触发离屏渲染,即由GPU再开一个“屏幕”进行渲染,渲染结束后提交到显示器,即不在当前显示器做渲染操作,这样是相对比较影响流畅性的

根据上面的分析我们可以得知,UITableView在不断滑动中会不断的有Cell滑入滑出,这样的话对CPU计算布局和GPU渲染的开销相对较大,如果再触发离屏渲染,就可能会影响帧率,影响用户体验。

至于怎么高效的避免离屏渲染和割圆角,网上的大牛文章很多,本文暂不说明(我也不太会用)

高度适配问题

众所周知实际使用中Cell中数据多种多样,比如一个简单的Label可能实际内容量会大于一行,这样就需要AutoLayout来将这个Cell“撑开”以使他能展示全部的内容
但是又众所周知,AutoLayout会比较影响性能,毕竟是动态计算,我们可以采取如下方法优化该问题:

首先利用NSAttributedString通过代码方式计算出文本的高度 文本为calcedStr
此处引用了iOS计算文本高度的几种方法

 NSMutableParagraphStyle *paragraphStyle = [[NSParagraphStyle defaultParagraphStyle] mutableCopy];
    paragraphStyle.lineBreakMode = NSLineBreakByWordWrapping;
    paragraphStyle.alignment = NSTextAlignmentLeft;
    paragraphStyle.lineSpacing = 2;

NSDictionary* attributes = @{NSFontAttributeName:[UIFont systemFontOfSize:14],
                                 NSParagraphStyleAttributeName: paragraphStyle,
                                 NSForegroundColorAttributeName: [UIColor blackColor]};
    
CGRect rect = [calcedStr boundingRectWithSize:limitSize
                                     options:NSStringDrawingUsesLineFragmentOrigin | NSStringDrawingUsesFontLeading
                                  attributes:attributes
                                     context:nil];

然后再UITableView的代理方法中实现
然后再根据数据源文本,计算高度缓存到一个数组中,再在此处返回数组indexPath对应值即可

/* 此处代码返回的是根据indexPath的位置 返回该处cell的高度*/
- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath {
    return 100.0;
}

你可能感兴趣的:(浅析iOS开发中UITableViewCell的复用机制)