Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tempted to Abandon React Native for Native Android

kelvinpompey.me

Post reply on HN
Print view View original

21–30 of 63 posts

Re: Tempted to Abandon React Native for Native Android

#21

Post by silkodyssey »

frostik wrote: post #19
silkodyssey wrote: post #9

Earlier quoted context omitted.

That's an interesting idea. The code to select and resize the images are native third-party plugins so in this case I am not sure anything more could be done. I thought maybe the problem was that the app had to switch to another app to select the image. I reimplemented the code using a pure JavaScript plugin based on React Native's CameraRoll API to avoid switching apps and it still crashed when the image was selecte…

Just a wild guess - you said opening for processing. Depending on what you're doing with the file and how you're opening it the whole data get's passed over the bridge resulting in some catastrophic memory allocations. I would recommend tapping into the bridge communication and start checking if everything stays where it should. Some picker modules tend to send base64 encoded file beside the URL.

The first module I tried was react-native-image-picker and yes it returns an object with base64 encoded data. What I do with this data is first, resize the image then display the resized image in an ImageView then upload the resized image to Firebase Storage.

Re: Tempted to Abandon React Native for Native Android

#22

Post by tomwilson »

silkodyssey wrote: post #20
teyc wrote: post #16

If you already know how to do the image related task in Native Android, you could spike a test project and verify that it's performant on the smaller devices and the problem could be attributed to React Native alone. Then it's a matter of porting the high level API to JS. Given that you believe this is a memory-related problem, perhaps it's because the image is too large to fit into the available memory, and having R…

I did just that. I created a native Android project that selected an image from the image picker and displayed it in an image view. I tested it with a few images and it worked. Even the image that crashed the React Native app. "Given that you believe this is a memory-related problem, perhaps it's because the image is too large to fit into the available memory, and having React Native made it worse. " This is precisel…

Seems like it can't be that hard to use that native code you wrote in your test in the react-native app though. Write the final image to disk. Load the image in an image view. Never pass the data through the JavaScript bridge.

Re: Tempted to Abandon React Native for Native Android

#23

Post by CodeWriter23 »

silkodyssey wrote: post #20
teyc wrote: post #16

If you already know how to do the image related task in Native Android, you could spike a test project and verify that it's performant on the smaller devices and the problem could be attributed to React Native alone. Then it's a matter of porting the high level API to JS. Given that you believe this is a memory-related problem, perhaps it's because the image is too large to fit into the available memory, and having R…

I did just that. I created a native Android project that selected an image from the image picker and displayed it in an image view. I tested it with a few images and it worked. Even the image that crashed the React Native app. "Given that you believe this is a memory-related problem, perhaps it's because the image is too large to fit into the available memory, and having React Native made it worse. " This is precisel…

Maybe this is your opportunity to create "SilkOdyssey's Badass Image Picker for RN, now with less crashy". It seems like you're partway there already. Maybe fork or PR the one you're using.

Re: Tempted to Abandon React Native for Native Android

#24

Post by devmunchies »

htormey wrote: post #15
t1amat wrote: post #13

I've been playing a lot with React Native over the last year; professionally for almost 4 months now. This really aligns with my experience. I don't share the same opinion of going back to native code though. This really is a fantastic platform. You really can, today, write native cross platform and web apps with the same code base. With few exceptions, everything from including native modules to upgrading is painles…

Yep, exactly my experience. I love React Native but if your not used to the Javascript style of million's dependencies your in for a world of pain. It's critical to spend more time vetting third party React Native/Javascript libraries as the quality level varies way more than with native libraries. As a native developer I hadn't spent a lot of time working deeply with npm. One thing to be careful about when saving pa…

facebook actually recommends using yarn instead of npm. it has faster install times.

Re: Tempted to Abandon React Native for Native Android

#25

Post by cageface »

htormey wrote: post #15
t1amat wrote: post #13

I've been playing a lot with React Native over the last year; professionally for almost 4 months now. This really aligns with my experience. I don't share the same opinion of going back to native code though. This really is a fantastic platform. You really can, today, write native cross platform and web apps with the same code base. With few exceptions, everything from including native modules to upgrading is painles…

Yep, exactly my experience. I love React Native but if your not used to the Javascript style of million's dependencies your in for a world of pain. It's critical to spend more time vetting third party React Native/Javascript libraries as the quality level varies way more than with native libraries. As a native developer I hadn't spent a lot of time working deeply with npm. One thing to be careful about when saving pa…

I recommend pinning to exact versions and using a tool like npm-check-updates when you want to upgrade to newer versions of libraries. We had a lot of problems with breakage due to different developers having slightly different versions of dependencies.

React Native is a great platform but it's still very fragile, particularly on Android.

Re: Tempted to Abandon React Native for Native Android

#26

Post by a13n »

htormey wrote: post #11

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. O…

> 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.

Re: Tempted to Abandon React Native for Native Android

#27

Post by iOSGuy »

silkodyssey wrote: post #21
frostik wrote: post #19

Earlier quoted context omitted.

Just a wild guess - you said opening for processing. Depending on what you're doing with the file and how you're opening it the whole data get's passed over the bridge resulting in some catastrophic memory allocations. I would recommend tapping into the bridge communication and start checking if everything stays where it should. Some picker modules tend to send base64 encoded file beside the URL.

The first module I tried was react-native-image-picker and yes it returns an object with base64 encoded data. What I do with this data is first, resize the image then display the resized image in an ImageView then upload the resized image to Firebase Storage.

You definitely will want to write images to file, then pass the file path over the bridge. That's an easy solution.

I've been using React Native cross platform for over a year, and it has a ridiculous number of issues, but they're trade offs. There are benefits that come with it. React Native is just another tool, evaluate it as you would any other framework.

Re: Tempted to Abandon React Native for Native Android

#28

Post by BoorishBears »

fn1 wrote: post #17
htormey wrote: post #11

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. O…

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/8780 https://github.com/fa…

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.

Re: Tempted to Abandon React Native for Native Android

#30

Post by quotemstr »

BoorishBears wrote: post #28
fn1 wrote: post #17

Earlier quoted context omitted.

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/8780 https://github.com/fa…

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 pr…

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?
Post reply on HN