-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
[No QA] Add React Native Firebase Performance monitoring #4173
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't ran the tests, just reviewed the code. But the implementation looks good to me, I have no changes to suggest.
I wonder if it might be worth migrating the Grafana timers to Firebase too later on -- as Firebase is much more closely tied to the app dashboards and perhaps more likely to be used.
import com.google.firebase.perf.FirebasePerformance; | ||
import com.google.firebase.perf.metrics.Trace; | ||
|
||
public class StartupTimer extends ReactContextBaseJavaModule { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NAB: Actually, my only comment is that maybe this could be made generic, so that each timing trace doesn't require a new Java class. But I'm sure you're aware of this, and it's not necessary until we add the second trace.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair point, I guess my thinking here was that we really only need a single timer in the native layer (when the app starts) for now. If we need to do performance traces with firebase we can do that via the JS later and this package
Good thought @Julesssss! I think we can pretty easily move some of the Grafana stuff to Firebase. The only thing is Firebase will not tell us anything about web - so if we want to move some of the traces to Firebase then they will be split between the two platforms. Not necessarily a bad thing. I think it's more likely we'll be worried about native performance than web performance in the long run anyway. |
✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release. |
🚀 Deployed to staging in version: 1.0.79-5🚀
|
🚀 Deployed to production in version: 1.0.80-2🚀
|
Details
This PR adds some new events to the Firebase dashboard for
Expensify/App
:js_loaded
custom event - how long the app takes to launch + for the main app component to mountThis should give us some valuable metrics for detecting material improvements or regressions to app start time.
Fixed Issues
$ https://github.com/Expensify/Expensify/issues/171518
Tests
The metrics are disabled when in
DEBUG
to avoid logging bad values for now. Dev builds take considerably longer to start up because the JS is bundled in metro and the app is technically "launched" while that's happening.To get around this we need to create release builds. Instructions for how to do that are here:
How do I run iOS Native Chat release builds on the iOS Simulator?
How do I run Android Expensify.cash release builds in Android Studio?
iOS / Android
To verify we are only running this in debug we can build the apps normally (debug) and grep for this log:
QA Steps
No QA
Tested On
Screenshots
Web
Mobile Web
Desktop
iOS
Android