swift main thread 100% load

Question

in the iOS App (Swift 5) I use the PDF Export framework. It generates a few PDFs from the UIViews. Now, while generating I present a UIActivityViewController which worked fine. The Activity is spinning and the PDFs are generated. The whole process is like 2-3 seconds long. During this time the CPU is 95-100% loaded, almost all of which is taken on main Thread (PDF is UI stuff)

Now, I'we decided to add some small animation, while generating PDFs. It is a JSON export from After Effects and being implemented in the App with help of Lotti. It is also a UI thing, but there is no space to show the animation smoothly on the screen - it's lagging (like really bad).

To solve the problem I tried

• doing as much work in background thread as possible,
• dispatching back with async and the same QoS (does not make difference which) (also with flag to force QoS),
• using Thread with low priority and QoS instead of DispatchQueue.

Nothing really helps. The lag is still there.

Can someone help, please?

Maybe some other solution will help - if I figure out a way to say to the block of code, that it can dispatch back to main thread, but take not more than some amount of %. But I think it is not possible.

The example project is here. The video of run is here

Thanks!

Answer 1

... figure out a way to say to the block of code, that it can dispatch back to main thread, but take not more than some amount of %. But I think it is not possible.

Yep, when you dispatch back to the main thread, you can’t constrain the %.

That having been said, one of two scenarios is likely taking place. Either (a) the main thread is simply busy with other stuff or (b) the cores are otherwise constrained by another thread (either all the cores are busy doing other stuff, the background work’s QoS is set too high, or, worse, you’ve exhausted the worker threads through thread explosion).

If you profile your app on device, there are two instruments that are potentially useful:

• First is “system trace”, which can show you the thread states (where threads are running, when they’re blocked, etc.) and also the CPU view (so you can see what each core is doing at any given point in time).

  The first thing I’d look at is how many threads are being used (if it’s 64+, then you could just be running out of worker threads). Second, I’d look at how often the main thread is blocked.

  I’d also be inclined to add point of interest ranges (e.g. Alternative to DTSendSignalFlag to identify key events in Instruments?) so you can narrow your focus in the fairly daunting Instruments analysis.

• The other is “time profiler” (including using the “record waiting threads” option) where you can analyze where time is spent in your code.

Realistically, we’re unlikely to be able to diagnose the problem on the basis of the information provided thus far. But the UIActivityIndicatorView is going to fare much better in high contention environments than many manual animation routines. But if you could make a simple reproducible example of the problem, hopefully one that can take Lotti out of the equation, then we could take a look at that.