amazon-chime-sdk-ios
amazon-chime-sdk-ios copied to clipboard
Runtime Warning (Hang Risk): -[AVCaptureSession startRunning] should be called from background thread. Calling it on the main thread can lead to UI unresponsiveness
Hello,
We use the provided code with some modifications, and noticed the following warning in runtime.
The code provided in the repository runs from the UI thread as far as I understand (ViewDidLoad etc.), but in our case when we run run it from the UI thread (also can be seen in the stack trace), we get this warning.
What it the correct handling for this? Should we run it from the UI thread? Will this be solved? Or should we run it from the background?
Thank you
Thanks for reporting. We'll investigate and give you updates.
Meanwhile, would you be able to provide
- Device: [e.g. iPhone6]
- OS: [e.g. iOS8.1]
- Version AmazonChimeSDK: [e.g. 0.4.0]
- Version AmazonChimeSDKMedia: [e.g. 0.4.0]
- Can you reproduce this in the demo app? If you are reporting a crash:
- Are you using bitcode supported binaries?
- Please provide full crash logs in the form of a ".crash" or ".ips" file with a binary images section.
- Xcode version
- Some of modifications you have made.
This is the information I can provide currently: Device: iPhone 12 OS: iOS 16 beta Version AmazonChimeSDK: 0.21.0 Xcode version: 14 beta
We adjusted the code to our uses and thus also wrapped some of it in functions, but the logic remains the same.
I will check the demo app as soon as possible and update.
Hi @NiliStein , have you seen the same warning in Xcode 13 or before? The session.startRunning in SDK and being called in the demo app does not throw warnings in Xcode 13.4 and before. If you can confirm that is only occurs on Xcode 14 beta, we may update in later release.
Hi, I haven't seen this warning before in Xcode 13, but sadly I can't build & run the demo app to check on it.
This warning is emitted by the Thread Performance Checker -- a feature added in Xcode 14. It's meant to warn developers of instances where they might be doing blocking work on main thread or using primitives that can lead to priority inversions.
More on this in the talk here:
- https://developer.apple.com/videos/play/wwdc2022/10082/
- https://developer.apple.com/documentation/xcode/diagnosing-performance-issues-early
Thanks for the information. Let me mark it as bug and move it to different thread.