Hacker News new | past | comments | ask | show | jobs | submit login

Great article Martin. Do you have any performance figures or tips that you learned when porting the save feature?

Specifically how was performance across Android/iOS?




Great question. First off, worth mentioning there are many performance metrics you might want to measure. On one hand start up times, but since you specifically mentioned Save, I assume you want to learn more about scroll perf (i.e.: dropped frames, memory usage, time to render next pages, etc).

We don't have numbers we can share but but the React Native team is working on further improving this. Check out Spencer's commit (https://github.com/facebook/react-native/commit/a3457486e39d...) for a sneak peek of what's coming up :).


Awesome, thanks for that link! So far I have been pretty happy with react native. On Android myself and another developer I have been working hit some issues around images on Android.

Part of the issues were our own fault: overlaying a transparent image provided by our designers instead of asking for a non transparent one, not using flags like renderToHardwareTextureAndroid.

Others were due to our use of the navigation library, react-native-router-flux, which on Android is backed by fragments. This caused a bunch of overdraw issues (i.e previously pushed views, which were not visible were being rendered in the background). We are planning on migrating away from this routing library to another one.

I'd love to read more articles about react native and performance based on real world examples at scale so please keep publishing them.


To what extent is React Native performance on iOS limited by the fact that an iOS application using JavaScriptCore outside of a WKWebView can't use the JIT compiler, but only the interpreter?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: