RUM-6263 Trigger based approach

[maciejburda]

What and why?

This PR changes the default behaviour of the SR recorder from scheduler to trigger based approach. Significantly reducing the SR footprint on idle.

How?

It's achieved by introducing RecordingTrigger which is responsible for subscribing to two events: UIView.layoutSubviews and UIApplication.sendEvent using obj-c swizzling. Trigger takes a weak dependency on the recording coordinator to start/stop it, as well as invoke captureNextRecord.

Those events happen frequently (every touch interaction and each view's layout change), they are throttled for 100ms (which matches scheduler capture frequency).

Below you can find screenshots from the basic Xcode profiler showcasing CPU usage for similar scenario (go through checkout and stay idle on dashboard):

Before

After

Review checklist

• Feature or bugfix MUST have appropriate tests (unit, integration)
• Make sure each commit and the PR mention the Issue number or JIRA reference
• Add CHANGELOG entry for user facing changes

[datadog-datadog-prod-us1]

Datadog Report

Branch report: maciey/RUM-6263-trigger-based-recording
Commit report: 8450ffd
Test service: dd-sdk-ios

❌ 1 Failed (1 Known Flaky), 192 Passed, 3147 Skipped, 17.27s Total duration (1m 47.66s time saved)

❌ Failed Tests (1)

• testWhenEnabled_itSendsConfigurationTelemetry - SessionReplayTests - ❄️ Known flaky - Details

  Expand for error

   Assertion Failure at SessionReplayTests.swift:216: XCTUnwrap failed: expected non-nil value of type "ConfigurationTelemetry"
  

[ncreated]

Great optimization idea 👍 💯 . I left few feedbacks, but most importantly a change request to offload the main thread from unnecessary tasks.

[maciejburda]

I have addressed all the feedback, which led to small refactor. But I think it makes more sense now.

Key change is that trigger is a dependency of coordinator and it notifies it through a delegate pattern.

On checking shouldSkipFrame outside of queue. I made some tests and it's significantly more performant when done from within the queue.

[maxep]

Looks good 👍 I have left some suggestions and a change-request regard thread safety

[maciejburda]

Addressed all the requested changes, and did some extra tests (internal).

SR Enabled:

SR Disabled:

[maxep]

Looks great! Thanks for the changes 🙏

[mariedm]

Awesome work! And this CPU improvement is very welcome! 👏

General question: Since we're fully transitioning to swizzling for SR recording, should we consider updating the documentation to add warnings for customers? E.g., potential conflicts with other SDKs or their own code that might also be using swizzling.

[maciejburda]

We decided to slightly revamp the approach. Closing this one for the time being.

[maciejburda]

Just noticed I need to add tests for the new swizzlers. On it. Will reopen when done.

[maxep]

It looks good, I like the split between RecordingCoordinator and RecordingTrigger 👍

What's less clear to me is the various method that we swizzle, it seems empirical and I'm not sure why we need so many. For example, CALayer.draw seems sufficient to catch all rendering, then why do we need CALayer.setNeedsDisplay and UIView.layoutSubviews? In this context, UIViewController.viewDidAppear seems redundant.

Also, I think we should let the previous swizzled implementation execute and then notify to coordinator. To not delay the CoreGraphics rendering and record the new layout.

I also left some minor question/nit but these 2 points are the most important.

[maxep]

Lets address the comments above.