说起实时模糊，最先想到的就是 iOS 7 中的 UIToolBar 和 iOS 8 中的 UIVisualEffectView，这两玩意儿的优点很明显，那就是快。美中不足的是，它们并不能改变模糊半径，或者说程度，而且其效果受到设置中的“降低透明度”开关的限制。
方案
就我所知的，处理图像的框架有以下几个：CoreImage，GPUImage 以及 Accelerate 这仨，前面两个可能听得比较多，但是 Accelerate 就没怎么听过了。它是用于向量和矩阵运算、数字信号处理和图像处理等高性能框架，提供了一堆 C API 实现诸如卷积之类的运算功能。
我弄了个测试项目去比较这几者的性能。前两个库我用的是高斯模糊的滤镜，对于 Accelerate 框架，我抄别人的代码，用的是 vImageBoxConvolve_ARGB8888() 函数实现均值模糊，所以只是作为参考而不是严谨的测试。
testcase_snapshot.jpeg
这个测试主要做的事情就是不断地从背景中扣图，交给 category 中的方法去计算，再返回模糊化后的图片，作为 blurArea 的 layer.contents，在不断的上下滚动的过程中观察左上角的帧率，并记录相应操作的耗时。
实现
实现“实时”的第一步肯定是扣背景这个没跑了，起初我是这么干的：
-(UIImage *)visibleImageInBlurAear {
UIImage *croppedImage;
CGRect visibleRect = _blurArea.frame;
UIGraphicsBeginImageContextWithOptions(visibleRect.size, YES, UIScreen.mainScreen.scale);
CGContextRef ctx = UIGraphicsGetCurrentContext();
CGContextTranslateCTM(ctx, -visibleRect.origin.x, -(visibleRect.origin.y + _scrollView.contentOffset.y));
CALayer *bgLayer = _backgroundImageView.layer;
[bgLayer renderInContext:ctx];
croppedImage = UIGraphicsGetImageFromCurrentImageContext();
UIGraphicsEndImageContext();
return croppedImage;
}
直接将背景的 layer 渲染到 blurArea 那么大的 ImageContext 中，再导出 Image，结果在初代 iPad mini 上测试卡得生活不能自理。对于 60 FPS 的目标，我们只有 16.7ms 的时间去绘制一帧，但-renderInContext: 这个方法就要耗掉 60~70ms（如非特别说明都是在初代 iPad mini 上的测试时间），然而这应该是 CALayer 对象到 UIImage 对象的唯一方法了吧？
所以只能搞个伪实时，第一次获取背景时将其内容作为实例，然后每次需要更新的时候从这个实例中截取。虽然第一次获得 originCGImage 需要 230ms 左右的时间，但是之后的裁剪只用 40~55us，各单位注意，是 us 而不是 ms。
-(UIImage *)visibleImageInBlurAear {
CGRect visibleRect = _blurArea.frame;
visibleRect.origin.y += _scrollView.contentOffset.y;
UIImage *image;
CGImageRef croppedImage = CGImageCreateWithImageInRect(self.originCGImage, visibleRect);
image = [UIImage imageWithCGImage:croppedImage];
CGImageRelease(croppedImage);
return image;
}
-(CGImageRef)originCGImage {
if (!_originCGImage) {
CGSize backgroundViewSize = _backgroundImageView.layer.frame.size;
UIGraphicsBeginImageContext(backgroundViewSize);
CGContextRef context = UIGraphicsGetCurrentContext();
[_backgroundImageView.layer renderInContext:context];
_originCGImage = CGBitmapContextCreateImage(context);
UIGraphicsEndImageContext();
}
return _originCGImage;
}
到了模糊处理这一步，我就不贴代码了，全都在 UIImage+Blur，这里只列举一下它们在本次测试的数据：
| 实现方式 | 平均耗时(ms) | 帧率(FPS) |
|---|---|---|
| CoreImage Filter（non-reuse context and filter） | 239.48 | 4 |
| CoreImage Filter（reuse context and filter） | 42.22 | 20 |
| GPUImage Filter | 21.48 | 38 |
| Accelerate vImage | 20.22 | 40 |
正如文档中的 Performance Best Practices一节所说，复用 context 和 filter 对象确实能提高不少性能，所以将这两个变量：
static CIContext *context;
static CIFilter *ciFilter;
弄成全局的静态变量也是“迫不得已”的。
最后
在性能方面，这种伪实时的模糊效果不是好的实践方案，毕竟要一直占用很高的 CPU 资源，还不如一次性处理完毕后随滑动裁剪处理后的图片，亦或者是只在滑动的时候刷新。这里只是作为一项不严谨的测试罢了。
至于效果的话，虽高斯模糊是比均值模糊更讨好我的眼球，但后者在处理时间上更少，可以去 category 那里调节下 boxSize 直到满意为止。
还有某些 App 中类似下图的效果：
today_snapshot.jpg
一般都是在上滑的时候，通过更改 UIVisualEffectView 的 alpha 来改变其“模糊程度”，也算是一种比较好的方案。
至于其它需求嘛，只能具体需求具体分析啦。😁
网友评论