Starting Performance

[dlallie]

Whenever the ScanView start method is called, a large amount of processing is done on the main thread. Even on the latest iOS devices, there is an extremely noticeable ~1 second lag when the app "freezes" because the main thread is blocked up.

I understand that some of the work done by the start method such as inserting the preview layer, etc. needs to happen on the main thread but could a majority of the CPU-intensive work be pushed to a background thread instead?

[janekp]

You are correct.

1. The start() method itself has a ~1s delay. The initial version (iOS ~8 & 9?) used an asynchronous approach, but could crash the app on iOS 8. It's probably worth to revisit this issue.

2. The sample buffer appears to use the main thread and this can be optimised in the next release. However, it's used only to copy video pixels to a separate buffer for processing. Processing happens on a background thread and is the most CPU-intensive part.

[dlallie]

Thanks for your quick response.

1. That sounds like a good idea. I know that as an API distributor you are wanting to provide a very compatible option but I wonder how many (if any) users of this SDK are still targeting iOS 8. The app I am integrating Quikkly with, for example, has a minimum version of iOS 10 and even then 95% of our users are on iOS 11.

2. Thanks for that insight. Naturally, with the SDK being a binary framework it's difficult for users to profile/know where the performance hits are.

[janekp]

Yeah, iOS 8 & 9 are ancient history.

[janekp]

Managed to reduce startup time ~0.5s on iPhone X

[janekp]

You can try 3.4.6

[dlallie]

Thank you very much, the starting performance is much improved now! The main thread also seems to not be getting blocked up at all now any more.

I'll close this issue now as it has been resolved completely. Thank you again for taking care of this so well and so quickly.