RUM-15454: Add Profiler status in RUM debug widget#3335
Conversation
12cceb8 to
db93569
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: db935697f8
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
This comment has been minimized.
This comment has been minimized.
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## feature/continuous-profiling #3335 +/- ##
=============================================================
Coverage 71.53% 71.53%
=============================================================
Files 948 948
Lines 35072 35092 +20
Branches 5945 5950 +5
=============================================================
+ Hits 25087 25103 +16
- Misses 8300 8312 +12
+ Partials 1685 1677 -8
🚀 New features to boost your workflow:
|
4061876 to
4e9e635
Compare
| // Set the profiling flag in SharedPreferences to profile for the next app launch | ||
| ProfilingStorage.addProfilingFlag(appContext, sdkCore.name) | ||
| sdkCore.setEventReceiver(name, this) | ||
| // TODO RUM-13678: we need to update context from the actual profiler start call, not from here |
There was a problem hiding this comment.
probably the comment still makes sense?
There was a problem hiding this comment.
This is outdated so I decide to remove it:
- the profiling status is already updated both in
ContinuousProfilingSchedulerwhen it starts, also updated when the callback is called as described in TODO - but an update is still needed here for app-launch profiling since the moment when app-launch profiling is started, no context is available for updating, so we need to fetch the profiler status once we initialize the Profiling feature (this is the earliest moment that we can).
| override fun onContextUpdate(featureName: String, context: Map<String, Any?>) { | ||
| if (featureName == Feature.PROFILING_FEATURE_NAME) { | ||
| val running = context[PROFILER_IS_RUNNING] as? Boolean ?: false | ||
| handler.post { |
There was a problem hiding this comment.
seems like the common approach in this class is to call withListenersUpdate, but having more fine-grained approach doesn't hurt anyway
| } | ||
|
|
||
| override fun bindSdkCore(sdkCore: FeatureSdkCore) { | ||
| sdkCore.setContextUpdateReceiver(this) |
There was a problem hiding this comment.
should we unsubscribe at some point?
There was a problem hiding this comment.
good point, fixed with new unbindSdkCore function
| internal const val ONE_SECOND_NS = 1_000_000_000L | ||
|
|
||
| // Contract key; must match ProfilingFeature.PROFILER_IS_RUNNING in dd-sdk-android-profiling. | ||
| private const val PROFILER_IS_RUNNING = "profiler_is_running" |
There was a problem hiding this comment.
for the future: maybe we can move it to the -internal module to share though
There was a problem hiding this comment.
yes, I wanted to do that but it involves too many places, so I decided to address it in another PR.
4e9e635 to
91e00d2
Compare
What does this PR do?
Motivation
It's convenient for debugging continuous profiling
Demo
Review checklist (to be filled by reviewers)