App Hang/Session Replay should use runloop observers

[noahsmartin]

Problem Statement

The app hang implementation (and session replay) is using CADisplayLink which causes it to use the main thread every frame. Instead of forcing the runloop to execute as fast as possible it should use a runloop observer that only measures the duration of runloop iterations that would otherwise be executing. This is a more passive way of detecting hangs that has much less overhead.

For session replay it would also allow capturing only the frames that actually change. However, it won't run during animations that are control by the Core Animation render server rather than the apps main run loop. This is probably not a problem, just a difference from CADisiplayLink behavior.

This screenshot shows how the main thread is constantly being used even when the user is not interacting with the app, since the hang detection feature is spinning the runloop

Solution Brainstorm

No response

Are you willing to submit a PR?

Yes!

[philprime]

Couple of thoughts we need to verify regarding Session Replay, as mentioned in this PR comment:

The app hang implementation (and session replay) is using CADisplayLink which causes it to use the main thread every frame.

That's why I opened #5258, because CADispayLink can be configured with a preferred frame rate, which was simply not done yet when the first implementation was done.

Furthermore, we need to make sure that changing the generated video segments from a constant frame rate to a dynamic one does not break play-ability.

For session replay it would also allow capturing only the frames that actually change. However, it won't run during animations that are control by the Core Animation render server rather than the apps main run loop. This is probably not a problem, just a difference from CADisiplayLink behavior.

This needs to be evaluated carefully.

[philprime]

Summary from internal discussion:

• We might be able to not use CADisplayLink or RunLoop for Session Replay as a normal timer might suffice (only one screenshot per second)
• We need to double-check if there are side effects with drawViewHierarchy's parameter afterScreenUpdates
• We need to check the docs for any reason why CADisplayLink is preferred over normal (dispatch) timers

We should split changing the trigger for App Hangs and Session Replay into separate issues to work on because they can be investigated and solved independently.

[hovox]

hi,
As I understood reading this and other related issue, there might be internal decision for using runloop observer in case of app hangs (thats the case which we are interested in).
Can you please give an update on that ?
Thank you.

[philipphofmann]

@hovox, yes, we plan on using the runloop observer for calculating UI frame statistics, which we also use for detecting app hangs V2. We don't have an ETA yet for this, though.

[Angelodaniel]

Hey Team, I currently have a customer who forked the SDK and implemented the Runloop Observer themselves which ideally is not needed. Do you think specifically for App hangs we can use the Observer.

Any updates on the timeline? Are open PR's welcome?

[philipphofmann]

@Angelodaniel, we don't have an update on the timeline yet. @noahsmartin opened a PR for using the runloop observers for the app hang detection, which is slightly related, but we didn't merge it yet #6237

[fdiaz]

Hey folks! Any updates on this one?

[philprime]

Thanks for the ping @fdiaz. I am going to pick this up as one of my next tasks.