说起实时模糊,最先想到的就是 iOS 7 中的 UIToolBar
和 iOS 8 中的 UIVisualEffectView
,这两玩意儿的优点很明显,那就是快。美中不足的是,它们并不能改变模糊半径,或者说程度,而且其效果受到设置中的“降低透明度”开关的限制。
方案
就我所知的,处理图像的框架有以下几个:CoreImage,GPUImage 以及 Accelerate 这仨,前面两个可能听得比较多,但是 Accelerate 就没怎么听过了。它是用于向量和矩阵运算、数字信号处理和图像处理等高性能框架,提供了一堆 C API 实现诸如卷积之类的运算功能。
我弄了个测试项目去比较这几者的性能。前两个库我用的是高斯模糊的滤镜,对于 Accelerate 框架,我抄别人的代码,用的是 vImageBoxConvolve_ARGB8888()
函数实现均值模糊,所以只是作为参考而不是严谨的测试。
这个测试主要做的事情就是不断地从背景中扣图,交给 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 中类似下图的效果:
一般都是在上滑的时候,通过更改 UIVisualEffectView
的 alpha
来改变其“模糊程度”,也算是一种比较好的方案。
至于其它需求嘛,只能具体需求具体分析啦。😁