tableView优化思路

一般优化的思路：

  1. 提前计算并缓存好高度（布局），因为heightForRowAtIndexPath:是调用最频繁的方法。

  2. 复杂界面可采用异步绘制。

  3. 在大量图片展示时，可以滑动时按需加载。

  4. 尽量少用或不用透明图层，多个透明元素重叠显示可采用合并成一张图片显示。

  5. 减少subviews的数量，如果是不需要交互可以使用CALayer 替换掉 UIView。

  6. 在heightForRowAtIndexPath:中尽量不使用cellForRowAtIndexPath:。

  7. 根据场景合理使用imageWithContentsOfFile和imageNamed。

  8. 页面元素多的时候，减少autolayout布局，采用frame。

  9. 缓存NSDateFormatter结果，不多次创建，及时释放。

  10. 图片解码时，CALayer 被提交到 GPU 前，CGImage 中的数据才会得到解码，GPU执行，卡主线程。常见的做法是在后台线程先把图片绘制到 CGBitmapContext 中，然后从 Bitmap 直接创建图片。

  11. CALayer 的 border、圆角、阴影、遮罩（mask）触发的离屏渲染，可开启CALayer.shouldRasterize ，转嫁到CPU上或是截图或者采用图片实现。

  12. 使用RunLoop和多线程在闲时处理一些繁重的计算工作。

缓存高度

提前计算好 cell 的高度和布局

// 关于UITableView有两个重要的方法
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath;
- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath;

iOS8后，会边滑动边调用heightForRowAtIndexPath:这个方法; 想想一下, 如果把计算cell高度的方法写在这儿, 不仅每次都会调用计算方法, 而且重复滑动的话, 还会再次计算; 所以我们一般在网络请求结束后，更新界面之前就把每个 cell 的高度算好，缓存到相对应的 model 中。

异步绘制

在Cell上添加系统控件的时候，实质上系统都需要调用底层的接口进行绘制，当我们大量添加控件时，对资源的开销也会很大，所以我们可以索性直接绘制，提高效率。

//异步绘制
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
    CGRect rect = CGRectMake(0, 0, 100, 100);
    UIGraphicsBeginImageContextWithOptions(rect.size, YES, 0);
    CGContextRef context = UIGraphicsGetCurrentContext();
    [[UIColor lightGrayColor] set];
    CGContextFillRect(context, rect);

    //将绘制的内容以图片的形式返回，并调主线程显示
    UIImage *temp = UIGraphicsGetImageFromCurrentImageContext();
    UIGraphicsEndImageContext();

    // 回到主线程
    dispatch_async(dispatch_get_main_queue(), ^{
        //code
    });
});

减少层级

减少SubViews的数量, 在滑动的列表上，多层次的view会导致帧数的下降。
例如: 绘制 cell 不建议使用 UIView，建议使用 CALayer。
从形式来说：UIView 的绘制是建立在 CoreGraphic 上的，使用的是 CPU。CALayer 使用的是 Core Animation，CPU，GPU 通吃，由系统决定使用哪个。View的绘制使用的是自下向上的一层一层的绘制，然后渲染。Layer处理的是 Texure，利用 GPU 的 Texture Cache 和独立的浮点数计算单元加速 纹理 的处理。

从事件的响应来说：UIView是 CALayer 的代理，layer本身并不能响应事件，因为layer是直接继承自NSObject，不具备处理事件的能力。而 UIView 是继承了UIResponder 的，这也是事件转发的角度上说明，view要比单纯的layer复杂的多。多层次的view再加上各种手势的处理势必导致帧数的下降。

hide

尽量少用addView给Cell动态添加View，可以初始化时就添加，然后通过hide来控制是否显示

避免离屏渲染

为了保证TableView的流畅，当快速滑动的时候，cell必须被快速的渲染出来。所以cell渲染的速度必须快。如何提高cell的渲染速度呢？

  • 当有图像时，预渲染图像，在bitmap context先将其画一遍，导出成UIImage对象，然后再绘制到屏幕，这会大大提高渲染速度。具体内容可以自行查找“利用预渲染加速显示iOS图像”相关资料。
  • 渲染最好时的操作之一就是混合(blending)了,所以我们不要使用透明背景，将cell的opaque值设为Yes，背景色不要使用clearColor，尽量不要使用阴影渐变等
  • 由于混合操作是使用GPU来执行，我们可以用CPU来渲染，这样混合操作就不再执行。可以在UIView的drawRect方法中自定义绘制。

当然除了这些, 还有其他的优化方法:

  • 正确地使用UITableViewCell的重用机制
  • 避免阻塞主线程
  • 按需加载
  • 尽可能重用开销比较大的对象
  • 尽量减少计算的复杂度
posted @ 2017-12-06 20:30  Sky109  阅读(296)  评论(0)  编辑  收藏  举报