2018版Instruments学习之Core Animatio

作者: kikido | 来源:发表于2018-07-09 10:55 被阅读96次

Instruments是Xcode组件中没有被充分利用的一个工具。很多iOS开发者从没用过Instruments，或者只是用Leaks工具检测循环引用。实际上有很多Instruments工具，例如为动画性能调优的东西。这里我将介绍其中的两样工具Core Animation，Time Profiler，用来优化系统性能。

你可以通过在菜单中选择Product --> Profile选项来打开Instruments（在这之前，记住要把目标设置成真机iOS设备，而不是模拟器）。然后将会显示下图（如果没有看到所有选项，你可能设置成了模拟器选项）。

PS:我用自己的手机，在打开测试工具的时候，会一直停留在初始化阶段，用公司的测试机就不会有问题。所以，如果你发现你使用不了Instruments工具的时候，就换个手机或者升级Xcode再试一下吧(手机版本与Xcode版本对应)。后面是stackoverflow里面一个相似的问题：https://stackoverflow.com/questions/49744280/time-profiler-in-instruments-is-not-working

你应该始终将程序设置成发布选项。幸运的是，配置文件默认就是发布选项，所以你不需要在分析的时候调整编译策略。

Instruments的一个很棒的功能在于它可以创建我们自定义的工具集。除了你初始选择的工具之外，如果在Instruments中点击+号，你可以拖拽别的工具到左侧边栏。我们将创建以上我们提到的两个工具，然后就可以并行使用了。

Time Profiler调试选项

时间分析器有一些选项来帮助我们定位到我们关心的的方法。可以点击下面的Call Tree打开。其中最有用的是如下几点：

1.Separate By Thread(线程分离)

这可以通过执行的线程进行分组。如果代码被多线程分离的话，那么就可以判断到底是哪个线程造成了问题。

2.Hide System Library(隐藏系统库)

可以隐藏所有苹果的框架代码，来帮助我们寻找哪一段代码造成了性能瓶颈。由于我们不能优化框架方法，所以这对定位到我们能实际修复的代码很有用。

Core Animation的调试选项

Core Animation不仅仅可以用来查看视图的FPS(Frame per second)，我们还可以利用它的许多选项来分析系统性能。

1.Color Blended Layers (图层混合)

Instruments可以在物理机上显示出被混合的图层Blended Layer(用红色标注)，Blended Layer是因为这些Layer是透明的(Transparent)，系统在渲染这些view时需要将该view和下层view混合(Blend)后才能计算出该像素点的实际颜色，如果这种blended layer很多，那么在滚动列表时就会出现卡顿。

解决blended layer问题也很简单，检查红色区域view的opaque属性，记得设置成YES；将backgroundColor属性设置成不是[UIColor clearColor]的对象。

会出现图层混合的原因有以下几项：

视图控件的backgroundColor是透明的
对于UIImageView，它的image是包含透明通道的png文件
opaque属性为NO（不过默认好像就是Yes）
alpha属性小于1

2.ColorHitsGreenandMissesRed(栅格化)

很多视图Layer由于Shadow、Mask和Gradient等原因渲染很高，因此UIKit提供了API用于缓存这些Layer：[layer setShouldRasterize:YES]，系统会将这些Layer缓存成Bitmap位图供渲染使用，如果失效时便丢弃这些Bitmap重新生成。图层Rasterization栅格化好处是对刷新率影响较小，坏处是删格化处理后的Bitmap缓存需要占用内存，而且当图层需要缩放时，要对删格化后的Bitmap做额外计算。使用这个选项后时，如果Rasterized的Layer失效，便会标注为红色，如果有效标注为绿色。当测试的应用频繁闪现出红色标注图层时，表明对图层做的Rasterization作用不大。

具体使用可以看下面的例子。

3.Color Copied Images

有时候寄宿图片的生成意味着Core Animation被强制生成一些图片，然后发送到渲染服务器，而不是简单的指向原始指针。如应用中有一些从网络下载的图片，而GPU恰好不支持这个格式，这就需要CPU预先进行格式转化，这个选项把这些图片渲染成蓝色。复制图片对内存和CPU使用来说都是一项非常昂贵的操作，所以应该尽可能的避免。

4.Color Non-Standard Surface Formats

不标准的表面颜色格式。

5.Color Immediately

通常Core Animation Instruments以每毫秒10次的频率更新图层调试颜色。对某些效果来说，这显然太慢了。这个选项就可以用来设置每帧都更新(可能会影响到渲染性能，而且会导致帧率测量不准，所以不要一直都设置它)。

6.Color Misaligned Images

这个选项检查了图片是否被缩放，以及像素是否对齐。被放缩的图片会被标记为黄色，像素不对齐则会标注为紫色。黄色、紫色越多，性能越差。

7.Color Offscreen-Rendered Yellow（离屏渲染）

这个选项会把那些离屏渲染的图层显示为黄色。黄色越多，性能越差。这些显示为黄色的图层很可能需要用shadowPath或者shouldRasterize来优化。

可能会出现离屏渲染的原因有以下几项：

重写drawRect方法(重绘)
使用了CALayer的mask属性
添加了阴影效果（可以使用shadowpath属性解决）
CALayer的shouldRasterize属性为YES(开启栅格化)
对于好多文章写的同时使用cornerRadius和masksToBounds就会开启离屏渲染，我测试的时候倒是没有出现过，所以我只能建议你自己可以测试一下。

8.Color Compositing Fast Path Blue，

这个选项会把任何直接使用 OpenGL 绘制的图层显示为蓝色。蓝色越多，性能越好。如果仅仅使用 UIKit 或者 Core Animation 的 API，那么不会有任何效果。如果使用 GLKView 或者 CAEAGLLayer，那如果不显示蓝色块的话就意味着你正在强制 CPU 渲染额外的纹理，而不是绘制到屏幕。

9.Flash Updated Regions

这个选项会把重绘的内容显示为黄色。出现的黄色越多，性能越差。通常我们希望只是更新的部分被标记完黄色。

PS: 上面所说的一些选项也可以同样在模拟器的Debug菜单工具中使用。虽然使用模拟器测试性能可能并不是很好(模拟机上测试性能可能会失真，例如一个动画在模拟器上运行流畅，但在真机上会出现卡顿)，但如果你能通过这些高亮选项识别出性能问题出现在什么地方的话，那么使用模拟器来验证问题也许会比真机测试更加有效。

创建一个测试用例

我们创建一个简单的显示模拟联系人姓名和头像列表的应用。注意为了使应用看起来更真实，即使把头像图片存在应用本地，我们也需要实时加载图片，而不是用–imageNamed:预加载。同样添加一些图层阴影来使得列表显示得更真实。下面的代表是最初版本的实现：


#import "ViewController.h"

@interface ViewController () <UITableViewDelegate, UITableViewDataSource>
@property (nonatomic, strong) NSArray *items;
@property (nonatomic, strong) UITableView *tableView;
@end

@implementation ViewController

- (void)viewDidLoad {
    [super viewDidLoad];
    
    NSMutableArray *array = @[].mutableCopy;
    for (NSInteger i = 0; i < 10; i++) {
        [array addObject:[NSString stringWithFormat:@"image%02ld",(i+1)%10 == 0 ? 10 : (i+1)%10]];
    }
    self.items = array;
    
    [self.view addSubview:self.tableView];
    // Do any additional setup after loading the view, typically from a nib.
}

- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section
{
    return self.items.count;
}

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
    UITableViewCell *cell = [self.tableView dequeueReusableCellWithIdentifier:@"UITableViewCell" forIndexPath:indexPath];
    //load image
    NSString *filePath = [[NSBundle mainBundle] pathForResource:self.items[indexPath.row] ofType:@"png"];
    //set image and text
    cell.imageView.image = [UIImage imageWithContentsOfFile:filePath];

    cell.textLabel.text = [NSString stringWithFormat:@"name %02ld",indexPath.row];
    //set image shadow
    cell.imageView.layer.shadowOffset = CGSizeMake(0, 5);
    cell.imageView.layer.shadowOpacity = 0.75;
    cell.clipsToBounds = YES;
    //set text shadow
    cell.textLabel.backgroundColor = [UIColor clearColor];
    cell.textLabel.layer.shadowOffset = CGSizeMake(0, 2);
    cell.textLabel.layer.shadowOpacity = 0.5;
    return cell;
}


- (UITableView *)tableView
{
    if (_tableView == nil) {
        _tableView = [[UITableView alloc] initWithFrame:self.view.bounds style:UITableViewStylePlain];
        [_tableView registerClass:[UITableViewCell class] forCellReuseIdentifier:@"UITableViewCell"];
        _tableView.delegate = self;
        _tableView.dataSource = self;
    }
    return _tableView;
}

@end

可以看到滑动的时候会有卡顿，FPS不超过20。

仅凭直觉，我们猜测性能瓶颈应该在图片加载。我们实时从硬盘加载图片，而且没有缓存，所以很可能是这个原因。我们可以用一些代码修复，使用GCD异步加载图片，然后将它们缓存起来...在开始编码之前，最好先测试一下假设是否成立。首先用我们的两个Instruments工具分析一下程序来定位问题。我们推测问题可能和图片加载相关，所以用Time Profiler工具来试试。

-tableView:cellForRowAtIndexPath:中的CPU利用率只有3.8%(也就是加载头像图片的地方)，这还是比较低的。于是，CPU利用率并不是卡顿的真正因素。接下来我们看一下是不是GPU的问题

1.检查图层混合

我们来用Core Animation调试工具选项来检查屏幕，首先打开Color Blended Layers。

屏幕中所有红色的部分都意味着字符标签视图的高级别混合，这很正常，因为我们把背景设置成了透明色来显示阴影效果。这就解释了为什么渲染利用率这么高了。

只开启Color Blended Layers,然后没有混合的部分会是绿色，混合最严重的部分会是红色。大量的图层混合会消耗GPU的时间，因为对于一个像素点，GPU不能简单的使用最上层的视图的颜色，而是需要进行计算叠加。

2.检查离屏渲染

打开Core Animation工具的Color Offscreen - Rendered Yellow选项

如图所示，所有的表格单元内容都在离屏渲染。这是因为我们给图片和文本视图添加的阴影效果。在代码中禁用阴影，看下性能是否会提高。

3.如何保持阴影效果并且不会影响性能

我们已经找到了卡顿的原因，禁止阴影之后的滑动很流畅。但是我们的列表看起来没有之前的好了。那么如何保持阴影效果并且不会影响性能呢？

在这个demo中，我们并不需要头像及文字动态的改变，即当列表创建完成之后，每一行的文字和头像在每一帧刷新的时候都不需要改变。我们可以使用CALayer的shouldRasterize属性里缓存图层内容，图层会在离屏渲染一次之后将结果保存起来，在后面刷新的时候都可以将这个结果拿出来用。

下面是修改之后的主要代码:

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
    UITableViewCell *cell = [self.tableView dequeueReusableCellWithIdentifier:@"UITableViewCell" forIndexPath:indexPath];
    //load image
    NSString *filePath = [[NSBundle mainBundle] pathForResource:self.items[indexPath.row] ofType:@"png"];
    //set image and text
    cell.imageView.image = [UIImage imageWithContentsOfFile:filePath];

    cell.textLabel.text = [NSString stringWithFormat:@"name %02ld",indexPath.row];
    //set image shadow
    cell.imageView.layer.shadowOffset = CGSizeMake(0, 5);
    cell.imageView.layer.shadowOpacity = 0.75;
    cell.clipsToBounds = YES;
    //set text shadow
    cell.textLabel.backgroundColor = [UIColor clearColor];
    cell.textLabel.layer.shadowOffset = CGSizeMake(0, 2);
    cell.textLabel.layer.shadowOpacity = 0.5;
    
    cell.layer.shouldRasterize = YES;
    cell.layer.rasterizationScale = [UIScreen mainScreen].scale;
    
    return cell;
}

图片08.png

使用Core Animation工具的Color Hits Green and Misses Red选项，屏幕都是绿色，只有当滑动到屏幕时会有一会变成红色(绿色代表使用了缓存，红色代表缓存再生)。滑动时FPS保持在50以上，比较平顺。

结尾

所以我们初始的设想是错的。图片的加载并不是真正的瓶颈所在，而且试图把它置于一个复杂的多线程加载和缓存的实现都将是徒劳。所以在动手修复之前找出问题所在是个很好的习惯！

上面就是我使用Instruments中Core Animation，Time Profiler两个工具来分析系统性能的一点研究，这次的示例代码地址：Demo，如果对你有帮助的话请点个👍哈！