5 ms·

To summarize this article: The author really enjoyed using React Native up until he hit some performance issues related to loading large images on certain versi

by htormey 10y ago

To summarize this article: The author really enjoyed using React Native up until he hit some performance issues related to loading large images on certain versions of Android. He doesn't go into what specifically the performance issues were, any techniques he used to profile his app, what third party libraries he tired or anything. Performance issues happen all the time with native apps that don't use React Native. Optimizing is a core part of what a software engineer does. Giving up on weeks of learning without a good reason seems like a poor choice to me. As it so happen's I have been working with a colleague of mine who just fixed a React Native performance issue relating to images on Android on older devices. The author might want to check out the following article: https://facebook.github.io/react-native/docs/performance.html#moving-a-view-on-the-screen-scrolling-translating-rotating-drops-ui-thread-fps https://facebook.github.io/react-native/docs/performance.htm... Our particular issue was solved by the following: "This is especially true when you have text with a transparent background positioned on top of an image, or any other situation where alpha compositing would be required to re-draw the view on each frame. You will find that enabling shouldRasterizeIOS or renderToHardwareTextureAndroid can help with this significantly." Apart from the above, this article is pretty shallow, which is sad because I would love to read a good article on React Native's performance. Perhaps I will write one if people are interested.

cel1ne 10y ago
I analysed react-native's performance issues with images and out-of-memory-errors a while back. Their (and their image library Fresco's) problem is that they make heavy use of object-finalizers, which is an error in Java and especially Android. I reported a couple of bugs, but got dismissed: https://github.com/facebook/react-native/issues/8711 https://github.com/facebook/react-native/issues/8711 https://github.com/facebook/react-native/issues/8780 https://github.com/facebook/react-native/issues/8780 https://github.com/facebook/fresco/issues/1363 https://github.com/facebook/fresco/issues/1363 I found this rather frustrating. I also found out that using plain java-serialization/string over the JS/Java bridge is twice as fast compared to their homegrown memory-management written in C. Again, a bugreport, again, dismissed. https://github.com/facebook/react-native/issues/10504 https://github.com/facebook/react-native/issues/10504 It seems that Facebook's Java programmers don't know Java very well.
- htormey 10y ago
  Thanks for all the awesome links! The Android portion of React Native is far behind iOS. "I also found out that using plain java-serialization/string over the JS/Java bridge is twice as fast compared to their homegrown memory-management written in C" We ran into some issues relating to this when wrapping some native code on Android. I'll pass your links on to my Android colleague.
- BoorishBears 10y ago
  Fresco is extremely notorious for causing crashes, I had no idea React Native used it. Picasso and Glide are the two sensible choices for image loading. Facebook's tools for Android are generally written in a way that you get the feeling one could only justify by repeating the manta "We're Facebook, these are Facebook scale problems" the whole time writing you're them. (see: Redex vs just Proguard) Wether they 're problems worth solving again need not be evaluated.
  - quotemstr 10y ago
    Redex does tons of things Proguard doesn't, and it operates on Android's native Java-program format, dex files, not java class files like Proguard. What's the problem?
    - BoorishBears 10y ago
      It's diminishing returns, it breaks in many more ways than Proguard with minimal benefit. I truly question if focusing the engineering effort on reducing bloat in their app won't have saved more space than Redex.
      - indy 10y ago
        "it breaks in many more ways than Proguard" is a phrase I thought I'd never hear
  - cel1ne 10y ago
    They're suffering from not-invented-here-syndrome. Also while custom memory management made sense for Android 2.2, they should have just thrown it out after 3.0. But giving up code isn't easy.
a13n 10y ago
> Apart from the above, this article is pretty shallow, which is sad because I would love to read a good article on React Native's performance. Perhaps I will write one if people are interested. Would definitely be interested.

by htormey 10y ago

cel1ne 10y ago

I analysed react-native's performance issues with images and out-of-memory-errors a while back. Their (and their image library Fresco's) problem is that they make heavy use of object-finalizers, which is an error in Java and especially Android. I reported a couple of bugs, but got dismissed: https://github.com/facebook/react-native/issues/8711 https://github.com/facebook/react-native/issues/8711 https://github.com/facebook/react-native/issues/8780 https://github.com/facebook/react-native/issues/8780 https://github.com/facebook/fresco/issues/1363 https://github.com/facebook/fresco/issues/1363 I found this rather frustrating. I also found out that using plain java-serialization/string over the JS/Java bridge is twice as fast compared to their homegrown memory-management written in C. Again, a bugreport, again, dismissed. https://github.com/facebook/react-native/issues/10504 https://github.com/facebook/react-native/issues/10504 It seems that Facebook's Java programmers don't know Java very well.

htormey 10y ago
Thanks for all the awesome links! The Android portion of React Native is far behind iOS. "I also found out that using plain java-serialization/string over the JS/Java bridge is twice as fast compared to their homegrown memory-management written in C" We ran into some issues relating to this when wrapping some native code on Android. I'll pass your links on to my Android colleague.
BoorishBears 10y ago
Fresco is extremely notorious for causing crashes, I had no idea React Native used it. Picasso and Glide are the two sensible choices for image loading. Facebook's tools for Android are generally written in a way that you get the feeling one could only justify by repeating the manta "We're Facebook, these are Facebook scale problems" the whole time writing you're them. (see: Redex vs just Proguard) Wether they 're problems worth solving again need not be evaluated.
- quotemstr 10y ago
  Redex does tons of things Proguard doesn't, and it operates on Android's native Java-program format, dex files, not java class files like Proguard. What's the problem?
  - BoorishBears 10y ago
    It's diminishing returns, it breaks in many more ways than Proguard with minimal benefit. I truly question if focusing the engineering effort on reducing bloat in their app won't have saved more space than Redex.
    - indy 10y ago
      "it breaks in many more ways than Proguard" is a phrase I thought I'd never hear
- cel1ne 10y ago
  They're suffering from not-invented-here-syndrome. Also while custom memory management made sense for Android 2.2, they should have just thrown it out after 3.0. But giving up code isn't easy.

a13n 10y ago

> Apart from the above, this article is pretty shallow, which is sad because I would love to read a good article on React Native's performance. Perhaps I will write one if people are interested. Would definitely be interested.