logo标签列表

使用`CIFilter`模糊图像时，应用程序崩溃。

iosuiimageviewcore-imagecifilterciimage
5

自从使用这个函数对图像进行模糊处理后，我经常会收到 CoreImage 的崩溃报告：

// Code exactly as in app
extension UserImage {

    func blurImage(_ radius: CGFloat) -> UIImage? {

        guard let ciImage = CIImage(image: self) else {
            return nil
        }

        let clampedImage = ciImage.clampedToExtent()

        let blurFilter = CIFilter(name: "CIGaussianBlur", parameters: [
            kCIInputImageKey: clampedImage,
            kCIInputRadiusKey: radius])

        var filterImage = blurFilter?.outputImage

        filterImage = filterImage?.cropped(to: ciImage.extent)

        guard let finalImage = filterImage else {
            return nil
        }

        return UIImage(ciImage: finalImage)
    }
}

// Code stripped down, contains more in app
class MyImage {

    var blurredImage: UIImage?

    func setBlurredImage() {
        DispatchQueue.global(qos: DispatchQoS.QoSClass.userInitiated).async {

            let blurredImage = self.getImage().blurImage(100)

            DispatchQueue.main.async {

                guard let blurredImage = blurredImage else { return }

                self.blurredImage = blurredImage
            }
        }
    }
}

根据Crashlytics的报告：

  • 崩溃仅发生在一小部分会话中
  • 崩溃发生在各种iOS版本，从11.x到12.x不等
  • 崩溃发生时0％的设备处于后台状态

我无法复现此崩溃，该过程如下：

  1. MyImageView对象（UIImageView的子对象）接收到一个Notification
  2. 有时（取决于其他逻辑），在线程DispatchQueue.global(qos: DispatchQoS.QoSClass.userInitiated).async上创建了一个UIImage的模糊版本
  3. 在主线程上，该对象使用self.image = ...设置UIImage

根据崩溃日志（UIImageView setImage）显示，应用程序似乎在第3步之后崩溃。另一方面，崩溃日志中的CIImage指示问题出现在第2步，即使用CIFilter创建图像的模糊版本。注意：MyImageView有时用于UICollectionViewCell。

崩溃日志：

EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000000000000

Crashed: com.apple.main-thread
0  CoreImage                      0x1c18128c0 CI::Context::recursive_render(CI::TileTask*, CI::Node*, CGRect const&, CI::Node*, bool) + 2388
1  CoreImage                      0x1c18128c0 CI::Context::recursive_render(CI::TileTask*, CI::Node*, CGRect const&, CI::Node*, bool) + 2388
2  CoreImage                      0x1c18122e8 CI::Context::recursive_render(CI::TileTask*, CI::Node*, CGRect const&, CI::Node*, bool) + 892
3  CoreImage                      0x1c18122e8 CI::Context::recursive_render(CI::TileTask*, CI::Node*, CGRect const&, CI::Node*, bool) + 892
4  CoreImage                      0x1c18122e8 CI::Context::recursive_render(CI::TileTask*, CI::Node*, CGRect const&, CI::Node*, bool) + 892
5  CoreImage                      0x1c18122e8 CI::Context::recursive_render(CI::TileTask*, CI::Node*, CGRect const&, CI::Node*, bool) + 892
6  CoreImage                      0x1c18122e8 CI::Context::recursive_render(CI::TileTask*, CI::Node*, CGRect const&, CI::Node*, bool) + 892
7  CoreImage                      0x1c18122e8 CI::Context::recursive_render(CI::TileTask*, CI::Node*, CGRect const&, CI::Node*, bool) + 892
8  CoreImage                      0x1c18122e8 CI::Context::recursive_render(CI::TileTask*, CI::Node*, CGRect const&, CI::Node*, bool) + 892
9  CoreImage                      0x1c18122e8 CI::Context::recursive_render(CI::TileTask*, CI::Node*, CGRect const&, CI::Node*, bool) + 892
10 CoreImage                      0x1c18122e8 CI::Context::recursive_render(CI::TileTask*, CI::Node*, CGRect const&, CI::Node*, bool) + 892
11 CoreImage                      0x1c1812f04 CI::Context::render(CI::ProgramNode*, CGRect const&) + 116
12 CoreImage                      0x1c182ca3c invocation function for block in CI::image_render_to_surface(CI::Context*, CI::Image*, CGRect, CGColorSpace*, __IOSurface*, CGPoint, CI::PixelFormat, CI::RenderDestination const*) + 40
13 CoreImage                      0x1c18300bc CI::recursive_tile(CI::RenderTask*, CI::Context*, CI::RenderDestination const*, char const*, CI::Node*, CGRect const&, CI::PixelFormat, CI::swizzle_info const&, CI::TileTask* (CI::ProgramNode*, CGRect) block_pointer) + 608
14 CoreImage                      0x1c182b740 CI::tile_node_graph(CI::Context*, CI::RenderDestination const*, char const*, CI::Node*, CGRect const&, CI::PixelFormat, CI::swizzle_info const&, CI::TileTask* (CI::ProgramNode*, CGRect) block_pointer) + 396
15 CoreImage                      0x1c182c308 CI::image_render_to_surface(CI::Context*, CI::Image*, CGRect, CGColorSpace*, __IOSurface*, CGPoint, CI::PixelFormat, CI::RenderDestination const*) + 1340
16 CoreImage                      0x1c18781c0 -[CIContext(CIRenderDestination) _startTaskToRender:toDestination:forPrepareRender:error:] + 2488
17 CoreImage                      0x1c18777ec -[CIContext(CIRenderDestination) startTaskToRender:fromRect:toDestination:atPoint:error:] + 140
18 CoreImage                      0x1c17c9e4c -[CIContext render:toIOSurface:bounds:colorSpace:] + 268
19 UIKitCore                      0x1e8f41244 -[UIImageView _updateLayerContentsForCIImageBackedImage:] + 880
20 UIKitCore                      0x1e8f38968 -[UIImageView _setImageViewContents:] + 872
21 UIKitCore                      0x1e8f39fd8 -[UIImageView _updateState] + 664
22 UIKitCore                      0x1e8f79650 +[UIView(Animation) performWithoutAnimation:] + 104
23 UIKitCore                      0x1e8f3ff28 -[UIImageView _updateImageViewForOldImage:newImage:] + 504
24 UIKitCore                      0x1e8f3b0ac -[UIImageView setImage:] + 340
25 App                         0x100482434 MyImageView.updateImageView() (<compiler-generated>)
26 App                         0x10048343c closure #1 in MyImageView.handleNotification(_:) + 281 (MyImageView.swift:281)
27 App                         0x1004f1870 thunk for @escaping @callee_guaranteed () -> () (<compiler-generated>)
28 libdispatch.dylib              0x1bbbf4a38 _dispatch_call_block_and_release + 24
29 libdispatch.dylib              0x1bbbf57d4 _dispatch_client_callout + 16
30 libdispatch.dylib              0x1bbbd59e4 _dispatch_main_queue_callback_4CF$VARIANT$armv81 + 1008
31 CoreFoundation                 0x1bc146c1c __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12
32 CoreFoundation                 0x1bc141b54 __CFRunLoopRun + 1924
33 CoreFoundation                 0x1bc1410b0 CFRunLoopRunSpecific + 436
34 GraphicsServices               0x1be34179c GSEventRunModal + 104
35 UIKitCore                      0x1e8aef978 UIApplicationMain + 212
36 App                         0x1002a3544 main + 18 (AppDelegate.swift:18)
37 libdyld.dylib                  0x1bbc068e0 start + 4

可能导致崩溃的原因是什么？

更新

可能与CIImage内存泄漏有关。在分析时，我看到了很多与崩溃日志中相同的堆栈跟踪的CIImage 内存泄漏：

Img

可能与Core Image和内存泄漏，swift 3.0有关。我发现图像存储在内存中的数组中，onReceiveMemoryWarning没有被正确处理，也没有清除该数组。因此，在某些情况下，应用程序会因内存问题而崩溃。也许这可以解决这个问题，我会在这里发布更新。

更新2

似乎我能够重现这个崩溃。在iPhone Xs Max上测试一个5MB的JPEG图像。

  • 当显示未模糊全屏幕的图像时，应用程序的内存使用量为160MB。
  • 当显示图像在1/4屏幕大小的状态下被模糊时，内存使用量为380MB。
  • 当显示图像在全屏幕中被模糊时，内存使用量跳到>1.6GB，大多数情况下应用程序会崩溃，并显示：

来自调试器的消息：由于内存问题终止

我很惊讶一个5MB的图像可以导致“简单”的模糊处理产生>1.6GB的内存使用量。我需要手动释放任何东西吗，如CIContext，CIImage等，还是这是正常现象，我需要在模糊处理之前手动调整图像大小到~kB？

更新3

添加多个显示模糊图像的图像视图会导致内存使用量每次增加几百MB，直到移除视图，即使每次只有1个图像可见。也许不应该使用CIFilter来显示图像，因为它占用的内存比呈现图像本身还要多。

所以我将模糊处理函数更改为在上下文中渲染图像，效果显著，内存仅在短时间内增加，用于渲染图像，并在模糊处理之前回到原始水平。

这里是更新后的方法：

func blurImage(_ radius: CGFloat) -> UIImage? {

    guard let ciImage = CIImage(image: self) else {
        return nil
    }

    let clampedImage = ciImage.clampedToExtent()

    let blurFilter = CIFilter(name: "CIGaussianBlur", withInputParameters: [
        kCIInputImageKey: clampedImage,
        kCIInputRadiusKey: radius])

    var filteredImage = blurFilter?.outputImage

    filteredImage = filteredImage?.cropped(to: ciImage.extent)

    guard let blurredCiImage = filteredImage else {
        return nil
    }

    let rect = CGRect(origin: CGPoint.zero, size: size)

    UIGraphicsBeginImageContext(rect.size)
    UIImage(ciImage: blurredCiImage).draw(in: rect)
    let blurredImage = UIGraphicsGetImageFromCurrentImageContext()
    UIGraphicsEndImageContext()

    return blurredImage
}

此外，感谢在评论中建议通过将图像降采样后再进行模糊处理来减轻高内存消耗的@matt和@FrankSchlegel。这让我也采取了同样的措施。即使是300x300px大小的图像也会导致内存使用量急剧增加约500MB，这令人惊讶。考虑到应用程序被终止的极限为2GB，我将在应用程序更新后发布更新通知。
第4次更新： 我添加了此代码来将图像降采样至最大300x300px后再进行模糊处理：
func resizeImageWithAspectFit(_ boundSize: CGSize) -> UIImage {

    let ratio = self.size.width / self.size.height
    let maxRatio = boundSize.width / boundSize.height

    var scaleFactor: CGFloat

    if ratio > maxRatio {
        scaleFactor = boundSize.width / self.size.width

    } else {
        scaleFactor = boundSize.height / self.size.height
    }

    let newWidth = self.size.width * scaleFactor
    let newHeight = self.size.height * scaleFactor

    let rect = CGRect(x: 0.0, y: 0.0, width: newWidth, height: newHeight)

    UIGraphicsBeginImageContext(rect.size)
    self.draw(in: rect)
    let newImage = UIGraphicsGetImageFromCurrentImageContext()
    UIGraphicsEndImageContext()

    return newImage!
}

现在这些崩溃看起来不同了，但我不确定这些崩溃是发生在降采样还是绘制模糊图像时，因为两者都使用了UIGraphicsImageContext。 

EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000000000010
Crashed: com.apple.root.user-initiated-qos
0  libobjc.A.dylib                0x1ce457530 objc_msgSend + 16
1  CoreImage                      0x1d48773dc -[CIContext initWithOptions:] + 96
2  CoreImage                      0x1d4877358 +[CIContext contextWithOptions:] + 52
3  UIKitCore                      0x1fb7ea794 -[UIImage drawInRect:blendMode:alpha:] + 984
4  MyApp                          0x1005bb478 UIImage.blurImage(_:) (<compiler-generated>)
5  MyApp                          0x100449f58 closure #1 in MyImage.getBlurredImage() + 153 (UIImage+Extension.swift:153)
6  MyApp                          0x1005cda48 thunk for @escaping @callee_guaranteed () -> () (<compiler-generated>)
7  libdispatch.dylib              0x1ceca4a38 _dispatch_call_block_and_release + 24
8  libdispatch.dylib              0x1ceca57d4 _dispatch_client_callout + 16
9  libdispatch.dylib              0x1cec88afc _dispatch_root_queue_drain + 636
10 libdispatch.dylib              0x1cec89248 _dispatch_worker_thread2 + 116
11 libsystem_pthread.dylib        0x1cee851b4 _pthread_wqthread + 464
12 libsystem_pthread.dylib        0x1cee87cd4 start_wqthread + 4

这里是用于调整大小和模糊图像的线程（blurImage() 是第三次更新中描述的方法）：

class MyImage {

    var originalImage: UIImage?
    var blurredImage: UIImage?

    // Called on the main thread
    func getBlurredImage() -> UIImage {

        DispatchQueue.global(qos: DispatchQoS.QoSClass.userInitiated).async {

            // Create resized image
            let smallImage = self.originalImage.resizeImageWithAspectFitToSizeLimit(CGSize(width: 1000, height: 1000))

            // Create blurred image
            let blurredImage = smallImage.blurImage()

                DispatchQueue.main.async {

                    self.blurredImage = blurredImage

                    // Notify observers to display `blurredImage` in UIImageView on the main thread
                    NotificationCenter.default.post(name: BlurredImageIsReady, object: nil, userInfo: ni)
                }
            }
        }
    }
}
1
从崩溃日志上看很难说，你能否发一下创建CIImage和更新视图的代码？ - Frank Rupprecht
1
询问 CIFilter 的 outputImage 并不会应用滤镜。将 CIImage 视为创建图像的“配方”，当实际需要图像内容（在此情况下，当图像视图需要实际像素来显示时）时，首先对其进行评估。因此，CIImage 本质上是懒加载的。 - Frank Rupprecht
1
问题仍然存在，您能否将整个问题，特别是大量的内存使用，简化为一个简单的可重现的示例？我的意思是，我可以模糊一个5MB的JPEG图像而不使用1.6GB的内存。所以在您向我展示之前，我无法想象您是如何做到的。正如已经指出的那样，仅仅说UIImage(ciImage: finalImage)并没有做任何事情；它实际上使用了零内存，因为您所做的只是创建制作图像的指令，而您还没有实际制作图像。因此，问题在于图像的创建和处理。 - matt
1
很抱歉啰嗦，但了解图像的_尺寸_也非常重要。说“5 MB”并不能告诉我们这一点，因为JPEG是压缩的。一个大图像（在尺寸方面）即使不经过滤镜，当你显示它时会占用很多内存！ - matt
1
用半径为100的模糊处理34兆像素图像是非常昂贵的，无论CI在底层做了多少聪明的优化。即使使用线性分离，也需要读取大约400个像素才能处理输出中的一个像素，总共需要13648133216次像素读取！除此之外，仅未压缩的图像就需要大约131 MB的内存，更不用说所有临时资源所需的内存了。我认为你已经遇到了硬件限制。你需要先缩小图像并使用较小的半径进行模糊处理，以保持在硬件限制范围内。 - Frank Rupprecht
显示剩余26条评论
2个回答
2

我进行了一些基准测试，发现在直接渲染到MTKView时，即使处理原始输入大小的图像也可以模糊并显示非常大的图像。以下是整个测试代码：

最初的回答：

import CoreImage
import MetalKit
import UIKit

class ViewController: UIViewController {

    var device: MTLDevice!
    var commandQueue: MTLCommandQueue!
    var context: CIContext!
    let filter = CIFilter(name: "CIGaussianBlur")!
    let testImage = UIImage(named: "test10")! // 10 MB, 40 MP image
    @IBOutlet weak var metalView: MTKView!

    override func viewDidLoad() {
        super.viewDidLoad()

        self.device = MTLCreateSystemDefaultDevice()
        self.commandQueue = self.device.makeCommandQueue()

        self.context = CIContext(mtlDevice: self.device)

        self.metalView.delegate = self
        self.metalView.device = self.device
        self.metalView.isPaused = true
        self.metalView.enableSetNeedsDisplay = true
        self.metalView.framebufferOnly = false
    }

}

extension ViewController: MTKViewDelegate {

    func draw(in view: MTKView) {
        guard let currentDrawable = view.currentDrawable,
              let commandBuffer = self.commandQueue.makeCommandBuffer() else { return }

        let input = CIImage(image: self.testImage)!

        self.filter.setValue(input.clampedToExtent(), forKey: kCIInputImageKey)
        self.filter.setValue(100.0, forKey: kCIInputRadiusKey)
        let output = self.filter.outputImage!.cropped(to: input.extent)

        let drawableSize = view.drawableSize

        // Scale image to aspect-fit view.
        // NOTE: This is a benchmark scenario. Usually you would scale the image to a reasonable processing size
        //       (i.e. close to your output size) _before_ applying expensive filters.
        let scaleX = drawableSize.width / output.extent.width
        let scaleY = drawableSize.height / output.extent.height
        let scale = min(scaleX, scaleY)
        let scaledOutput = output.transformed(by: CGAffineTransform(scaleX: scale, y: scale))

        let destination = CIRenderDestination(mtlTexture: currentDrawable.texture, commandBuffer: commandBuffer)
        // BONUS: You can Quick Look the `task` in Xcode to see what Core Image is actually going to do on the GPU.
        let task = try! self.context.startTask(toRender: scaledOutput, to: destination)

        commandBuffer.present(currentDrawable)
        commandBuffer.commit()

        // BONUS: No need to wait, but you can Quick Look the `info` to see what was actually done during rendering
        //        and to get performance metrics, like the actual number of pixels processed.
        DispatchQueue.global(qos: .background).async {
            let info = try! task.waitUntilCompleted()
        }
    }

    func mtkView(_ view: MTKView, drawableSizeWillChange size: CGSize) {}

}

对于10 MB的测试图像（4000万像素！），在渲染期间内存会短暂地飙升到800 MB，这是可以预料的。我甚至尝试了30 MB（约7400万像素！！）的图像，也没有问题，最多使用了1.3 GB的内存。
当我在应用滤镜之前将图像缩放到目标大小时，内存始终保持在约60 MB左右。因此，在任何情况下，这确实是您应该做的。但请注意，在这种情况下，您需要更改高斯模糊的半径以达到相同的效果。
如果您需要呈现结果不仅用于显示，我想您可以使用CIContext的createCGImage API而不是渲染到MTKView的可绘制对象，并获得相同的内存使用情况。
希望这对您有所帮助。
有趣的例子，我在我的第三个更新中体验到了相同的内存峰值，当渲染模糊图像时，即使将其缩放到300x300像素的图像，峰值也达到了数百MB。您确定您的示例中缩放后的图像没有出现峰值，或者峰值如此短暂以至于分析器没有记录它？ - Manuel
有趣的是，在渲染10 MB图像时，出现了一个非常短暂的约200 MB的峰值，但在渲染30 MB图像时却没有... - Frank Rupprecht
我的猜测是，分析器的延迟有时无法记录仅持续几分之一秒的峰值。 - Manuel
应该是这样的。我猜测差异是由于高斯滤波器的实现方式不同造成的。根据输入大小和半径参数，使用不同的缩放和其他优化技术。这些可能具有不同的运行时和内存需求。 - Frank Rupprecht
0

这似乎是一个简单的线程问题。CIFilter 不是线程安全的。您不能在一个线程上形成一条滤镜链，然后在另一个线程上呈现结果 CIImage。您应该限制自己使用小图像，并在主线程上执行所有操作，并使用 GPU 显式地呈现。这就是 Core Image 的全部意义。

我在问题的第四个更新中添加了线程信息。据我理解，图像是在“DispatchQueue.global(qos: DispatchQoS.QoSClass.userInitiated).async”上调整大小和模糊处理的。我认为CIFilter只在模糊图像绘制在UIGraphicsImageContext中之前相关，因为之后它被存储在一个变量中作为UIImage。 - Manuel
http://sealiesoftware.com/blog/archive/2008/09/22/objc_explain_So_you_crashed_in_objc_msgSend.html - matt
同时在后台使用Core Image是一个糟糕的想法，因为你无法在GPU上渲染，这正是整个重点。请参见https://stackoverflow.com/questions/25431317/coreimage-very-high-memory-usage，我越来越倾向于认为这是一个重复的问题。一个永无止境的重复。 - matt
那么我的问题很简单：我该如何创建一个模糊的图像？我不能在主线程上执行此操作，否则会阻塞用户界面。因此，我会在后台线程上执行此操作，可能使用 CPU 而不是 GPU，并且如果需要更长时间也无所谓。因此，图像在后台线程上绘制在上下文中，然后存储在变量中。还有其他选择吗？ - Manuel
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接