usrbowe
commented
3 years ago This would really helpful addition for React Native! 👍
Would it be possible to specify each needed data point? I think we could use User Timing API as well, to collect the traces, since its already used for React markers (https://github.com/facebook/react-native/blob/main/Libraries/Performance/Systrace.js#L24).
For hermes, we should also be able to leverage this to gather profiling data: https://github.com/react-native-community/hermes-profile-transformer
If we have a list of all data point to collect, we could tackle one by one and see where to gather the data from (some might even need data to be exposed from native side).
bvaughn
The Scheduling Profiler currently reads data from an exported Chrome performance profile, including User Timing API marks created by React.
The Chrome profile contains native events (e.g. "click" events), CPU samples that can be used to display a flame graph of what JavaScript was running at a point in time, and base64 encoded screenshots (if enabled). The User Timing data contains info about when state updates are scheduled, when React renders or commits work, when components suspend, etc. This data is processed together to generate the Scheduler Profiler UI.
React Native (or more specifically Hermes) doesn't provide a way for users to record or export this data. (I think CPU sampling can be done somehow but I'm not sure how to access the information.) However even if we only had the React User Timing marks, this would still be useful data to display in the profiler. (We could probably also add markers for React's synthetic events as a replacement for the native events.)
This data would need to be collected by something though (a User Timing polyfill for the embedded DevTools backend? some other more explicit API we add that calls through to User Timing API for the browser case and logs in-memory for RN?) and shared from the backend to the frontend.
What about profiling locally? Perhaps the backend could gather this sample and periodically send it (encoded) to the frontend to be exported/downloaded. We'd probably only want to do this if the user started profiling (recording) in the UI. This would require us to add state for the new profiler (since it's currently read-only). But we plan to do this anyway for the browser extension (#22015).
This task is a placeholder for researching and proposing a way to add at least basic RN support.