Improvements when capture methods are called in tight loops

[denrase]

Problem Statement

Relates to #2371

When capturing in tight loops (awaiting the SDK methods), we run into memory issues (screenshot integration) on iOS and the watchdog might be killing the app. This probably happens because of screenshot widget, but there also might be other bottlenecks thought the SDK.

@buenaflor Still need to test this on an actual iOS device. In the meantime, can the user in question use something like exponential backoff until we come up with a solution? Think this PR here is good in itself, no need to do processing for dropped tasks, but it will not solve the issue of too many awaited tasks in a loop. Here we are still attaching screenshots.

Come to think of it, what if we cache the screenshot for some time? That way every event would still get a screenshot attached, but we could probably also relieve a bit of CPU/Memory pressure.

#2371 (comment)

Solution Brainstorm

• Further investage where we have bottlenecks that can be improved.
• Use a short-lived cashed screenshot to avoid making hundreds of screenshots if the SDK is called in a tight loop.

Are you willing to submit a PR?

Yes

[denrase]

generally looks good, got one question

so these are not dropped since we await each call but according to the user this example can somewhat reproduce watchdog killing the app on ios.

can you reproduce this?

@buenaflor Just checked this again. The tasks are actually not awaiting on each other, so our code to handle is being called in this particular example. Woking on the cached screenshots now where i use a plain for loop, then the tasks are awaited.

[buenaflor]

oh good 👍