High numbers on iOS?

[pfulop]

We are currently using this library to determine which part of the app is currently the slowest to load. One thing we noticed are high numbers for measuring nativeLaunchEnd relative to nativeLaunchStart on ios. For instance, we see 340756159ms which translated to almost 4 days. This would mean the app is taking 4 days to start. Are there some cases where this can happen and how to prevent them? This is currently polluting our measurements.

[oblador]

Are you seeing this in development or real user monitoring? If the latter is it possible that it's related to users backgrounding the app during startup?

[pfulop]

This is in production.

If the latter is it possible that it's related to users backgrounding the app during startup?

I would not expect days in that case but max hours. I would expect ios clearing that process within a day.

[gavrix]

Was seeing this too in RN 0.68.2 Which I believe was fixed in facebook/react-native#33983 and is not reproducible in 0.68.9 anymore.

The issue I believe is in difference of "now" primitives used by react-native-performance and by RN runtime itself.
RNPerformanceGetTimestamp uses std::chrono::steady_clock::now() while RN used std::chrono::system_clock::now().

[gavrix]

Native launch indeed reporting very high numbers which likely the result of iOS pre-warming.

On iOS we can no longer assume that process creation time is the time when user launched the app. Process can be created way ahead of time (pre-warming) before user launches the app, at which point main entry point starts executing. More on this topic can be found here.

This is legit issue @oblador. I think the way to resolve this is to break up native_launch into native_load and native_initialization:

• native_load: interval between process creation and code initialization (__attribute__((constructor)) attribute)
• native_initialization: interval between calls to main (or appDidFinishLaunchingWithOptions) and RN module initialization (where we currently calculate sNativeLaunchEnd)

Not sure how this would translate to android though. I guess, we can also assume native_launch to be a sum of those two and keep things simple.

[oblador]

Closing this as it should have been fixed in 5.0.0, please open a new issue if it persists.