Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ttid span to ActivityLifecycleIntegration #2369

Merged
merged 15 commits into from Dec 14, 2022
Merged

Conversation

stefanosiano
Copy link
Member

📜 Description

Added ttid (time to initial display) span to ActivityLifecycleIntegration

💡 Motivation and Context

We want to add the ttid info to the transactions, so we are adding a span to the automatic activity tracking transactions

💚 How did you test it?

Added unit test to check ttid span is created and cancelled in case activity finishes early

📝 Checklist

  • I reviewed the submitted code
  • I added tests to verify the changes
  • I updated the docs if needed
  • No breaking changes

🔮 Next steps

@github-actions
Copy link
Contributor

github-actions bot commented Nov 16, 2022

Messages
📖 Do not forget to update Sentry-docs with your feature once the pull request gets approved.

Generated by 🚫 dangerJS against f953c3c

…tyStarted(), not onActivityCreated() anymore
@github-actions
Copy link
Contributor

github-actions bot commented Nov 16, 2022

Performance metrics 🚀

  Plain With Sentry Diff
Startup time 375.68 ms 454.04 ms 78.36 ms
Size 1.73 MiB 2.33 MiB 614.00 KiB

Baseline results on branch: main

Startup times

Revision Plain With Sentry Diff
81a1a6c 328.73 ms 421.28 ms 92.55 ms
ecf9680 326.55 ms 360.26 ms 33.71 ms
ecf9680 303.12 ms 346.35 ms 43.23 ms
38e4f11 358.20 ms 433.73 ms 75.53 ms
703d523 330.27 ms 377.66 ms 47.39 ms
81a1a6c 294.04 ms 341.19 ms 47.15 ms
ecf9680 321.55 ms 385.52 ms 63.97 ms
4a9c176 320.62 ms 334.68 ms 14.06 ms
3695453 301.78 ms 371.14 ms 69.36 ms
b85d8aa 289.35 ms 335.92 ms 46.56 ms

App size

Revision Plain With Sentry Diff
81a1a6c 1.73 MiB 2.32 MiB 612.47 KiB
ecf9680 1.73 MiB 2.32 MiB 612.39 KiB
ecf9680 1.73 MiB 2.32 MiB 612.39 KiB
38e4f11 1.73 MiB 2.32 MiB 609.82 KiB
703d523 1.73 MiB 2.33 MiB 613.23 KiB
81a1a6c 1.73 MiB 2.32 MiB 612.47 KiB
ecf9680 1.73 MiB 2.32 MiB 612.39 KiB
4a9c176 1.73 MiB 2.33 MiB 612.69 KiB
3695453 1.73 MiB 2.32 MiB 611.62 KiB
b85d8aa 1.73 MiB 2.32 MiB 611.62 KiB

Previous results on branch: feat/android-ttid

Startup times

Revision Plain With Sentry Diff
8d63d7f 327.04 ms 366.00 ms 38.96 ms
8aeeb7f 348.82 ms 398.40 ms 49.58 ms
d125af1 325.12 ms 361.04 ms 35.92 ms
2c9607d 328.42 ms 398.77 ms 70.35 ms
89f6386 279.98 ms 356.45 ms 76.47 ms
15034e6 346.20 ms 376.02 ms 29.82 ms
abb2f2e 346.82 ms 395.04 ms 48.22 ms
0e7deaa 353.50 ms 386.40 ms 32.90 ms

App size

Revision Plain With Sentry Diff
8d63d7f 1.73 MiB 2.33 MiB 613.28 KiB
8aeeb7f 1.73 MiB 2.33 MiB 614.04 KiB
d125af1 1.73 MiB 2.33 MiB 614.08 KiB
2c9607d 1.73 MiB 2.33 MiB 612.93 KiB
89f6386 1.73 MiB 2.33 MiB 614.05 KiB
15034e6 1.73 MiB 2.32 MiB 609.87 KiB
abb2f2e 1.73 MiB 2.32 MiB 609.87 KiB
0e7deaa 1.73 MiB 2.32 MiB 609.87 KiB

@codecov-commenter
Copy link

codecov-commenter commented Nov 16, 2022

Codecov Report

Base: 80.21% // Head: 80.21% // No change to project coverage 👍

Coverage data is based on head (1db34ad) compared to base (703d523).
Patch has no changes to coverable lines.

Additional details and impacted files
@@            Coverage Diff            @@
##               main    #2369   +/-   ##
=========================================
  Coverage     80.21%   80.21%           
  Complexity     3772     3772           
=========================================
  Files           302      302           
  Lines         14221    14221           
  Branches       1885     1885           
=========================================
  Hits          11408    11408           
  Misses         2072     2072           
  Partials        741      741           

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

@stefanosiano stefanosiano marked this pull request as ready for review November 16, 2022 16:51
@romtsn
Copy link
Member

romtsn commented Nov 18, 2022

@stefanosiano
Copy link
Member Author

I'll try to implement it in the same way just to compare the values and see, thanks for posting it

@stefanosiano stefanosiano marked this pull request as draft November 18, 2022 17:50
@stefanosiano
Copy link
Member Author

Firebase implementation logs a lot of things, but the approach on using OnDrawListener is more reliable.
While timings are the same as this implementation most of the times, there are few cases when using Firebase's approach is unsurprisingly more correct.
I'm making this pr a draft and will switch implementation taking inspiration from Firebase

…pan per activity

updated ttidSpan finishing with Firebase's method: span is finished after the very first frame has been drawn using view.getViewTreeObserver().addOnDrawListener
added FirstDrawDoneListener
Sentry.getSpan() could cause issues
@@ -206,7 +205,7 @@ protected void onResume() {
final ISpan span = Sentry.getSpan();
if (span != null) {
span.setMeasurement("screen_load_count", screenLoadCount, new MeasurementUnit.Custom("test"));
span.finish(SpanStatus.OK);
// span.finish(SpanStatus.OK);
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@romtsn I found that using Sentry.getSpan() and then span.finish() is finishing the ttid span
Is it something to be worried about? Would a user be already using something like this?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, it's possible that the users already do this to finish the activity transaction whenever they think it's suitable for them.

Once we implement #1828, this should not matter anymore, but until then, we should probably mention this in the docs + migration docs, that calling span.finish in onResume will change how ttid span is measured.

CHANGELOG.md Outdated Show resolved Hide resolved
Copy link
Member

@romtsn romtsn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me overall, great job 👍 One more thing I'd like to ask you - could you enable auto-finish for activity transactions and test if it works fine with the ttid spans? I think it shouldn't change anything but just for the sake of correctness.

@romtsn
Copy link
Member

romtsn commented Dec 12, 2022

I think it shouldn't change anything but just for the sake of correctness.

Actually after looking at this one more time, I think it will affect the ttid span, because currently we're finishing it as cancelled inside the stopTracing method, which is also called when auto-finish is enabled.

Perhaps we should only finish the ttid span as cancelled in onActivityDestroyed, otherwise we should just finish the activity transaction, and keep the ttid span running until it finishes itself

@stefanosiano
Copy link
Member Author

stefanosiano commented Dec 12, 2022

Perhaps we should only finish the ttid span as cancelled in onActivityDestroyed, otherwise we should just finish the activity transaction, and keep the ttid span running until it finishes itself

Yep, auto-finish stops the ttid. Let's finish the span only in onActivityDestroyed then. Thanks for the catch

What about the stopPreviousTransactions()? It makes sense to cancel the ttid span in that case, right?

@stefanosiano stefanosiano marked this pull request as ready for review December 13, 2022 08:25
@romtsn
Copy link
Member

romtsn commented Dec 13, 2022

What about the stopPreviousTransactions()? It makes sense to cancel the ttid span in that case, right?

yeah I think it makes sense, otherwise it will run indefinitely right? if we switched the screens in the meantime

@stefanosiano
Copy link
Member Author

yeah I think it makes sense, otherwise it will run indefinitely right? if we switched the screens in the meantime

It would end when the previous activity is destroyed, but if an activity is started without destroying the previous one, then it would run indefinitely, yeah

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants