RUM-6263 Trigger based approach #2074
Conversation
Datadog ReportBranch report: ❌ 1 Failed (0 Known Flaky), 3236 Passed, 0 Skipped, 1m 54.38s Total Time ❌ Failed Tests (1)
🔻 Code Coverage Decreases vs Default Branch (1)
|
DatadogSessionReplay/Sources/Recorder/RecordingCoordinator.swift
Outdated
Show resolved
Hide resolved
DatadogSessionReplay/Sources/Recorder/RecordingCoordinator.swift
Outdated
Show resolved
Hide resolved
maciejburda
force-pushed
the
maciey/RUM-6263-trigger-based-recording
branch
from
ce52eaa
to
2c0baea
Compare
|
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 |
DatadogSessionReplay/Sources/Recorder/RecordingCoordinator.swift
Outdated
Show resolved
Hide resolved
| stopRecording() | ||
| } catch { | ||
| telemetry.error("[SR] Failed to take snapshot", error: error) | ||
| queue.run { [weak self] in |
There was a problem hiding this comment.
/question We can assume we are already on the main thread, no?
There was a problem hiding this comment.
this runs async job on main thread
There was a problem hiding this comment.
I mean the captureNextRecord is called by triggers from the main thread, so I wonder why we jump on the main thread again?
DatadogSessionReplay/Sources/Recorder/RecordingCoordinator.swift
Outdated
Show resolved
Hide resolved
| private var shouldSkipFrame: Bool { | ||
| return dateProvider.now.timeIntervalSince(lastFrameTimestamp ?? .distantPast) < Constants.throttingRate | ||
| } |
There was a problem hiding this comment.
/suggestion We could have a Debouncer object that could take care of this, similar to the future TimeBank, WDYT?
There was a problem hiding this comment.
Totally - but for now I'd suggest merging this as is - and refactor once we have timebank in place. It will shed some more slight on our approach of unit testing this
|
Addressed all the requested changes, and did some extra tests (internal). SR Enabled: |
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
RecordingTriggerwhich is responsible for subscribing to two events:UIView.layoutSubviewsandUIApplication.sendEventusing 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