4 ms·

That's funny that this would come up on HN right now. I've just spent the last day or two struggling with a potential GC bug on Android. It might be somewhere

That's funny that this would come up on HN right now. I've just spent the last day or two struggling with a potential GC bug on Android. It might be somewhere in JavaScriptCore, Android, or Genymotion, but I really have no idea. The last few hours have consisted of repeatedly clicking through my app, and trying to figure out why it crashes every 5 minutes or so. In this case it's not a memory leak, it's memory that is getting wiped for no good reason. I've also posted about it on StackOverflow [1]. So far I've really enjoyed working with React Native. iOS has been almost perfect, but all my problems seem to be happening on Android. There was one case where my components were just disappearing randomly during animations (even without native drivers). The only workaround was to rotate the component "keys" so that they were regularly destroyed and recreated. The native animation drivers for Android are also incredibly unstable and buggy [2]. Ah well, I would still recommend React Native, but only if you're already comfortable with Cocoa, ObjC, and Java. You're going to face a ton of roadblocks if you can't get your hands dirty with native code from time to time. [1] http://stackoverflow.com/questions/43470160/in-a-react-native-javascript-app-why-would-the-android-gc-behavior-change-if-i http://stackoverflow.com/questions/43470160/in-a-react-nativ... [2] https://github.com/facebook/react-native/issues/13530 https://github.com/facebook/react-native/issues/13530 [3] https://github.com/react-native-community/react-native-blur https://github.com/react-native-community/react-native-blur

BoorishBears 10y ago
Because I've worked so much with native Android bugginess (versions of Android that crash if you try and pause an HTML5 video, crashes after X number of MediaPlayer loops where X is a large number around 5000, etc.), it can hard for me to use React Native because there's so many workarounds you're hoping the people behind components are implementing unless you want to start augmenting them yourself
- nathan_f77 10y ago
  That's actually one of the reasons why I like React Native, because I'm hoping that it can be like "jQuery" for Android apps (in terms of jQuery's cross-browser compatibility). I'm assuming that the core RN code already contains a lot of workarounds for different Android versions, so we can just use one consistent API via JavaScript. But you're right that it can get very tricky when you want to use a lot of third-party libraries. For example, I thought I would be able to just drop in 'react-native-blur' [1] and everything would work out of the box. I didn't realize that the Android component has been broken for a very long time, so I had to dive into the code and fix it. And then I ended up basically rewriting the whole library for iOS and Android, including the example apps, the README, and even the GIF in the README. But the nice thing is that other people can use it now, and they won't have to go through all of that. The other nice thing is that I learned a ton about developing native modules for React Native, so I don't regret it at all. Just think that you're going to have to implement those workarounds anyway, so it makes sense to contribute them to an open source library that everyone can use. For your video examples, it would be awesome if you could take a look at react-native-video [2], and see if they already include those workarounds. (I would personally appreciate that a lot, because I'm working on a cross-platform RN app that plays a lot of videos.) [1] https://github.com/react-native-community/react-native-blur https://github.com/react-native-community/react-native-blur [2] https://github.com/react-native-community/react-native-video https://github.com/react-native-community/react-native-video
  - BoorishBears 10y ago
    The fear for me is running into a situation where I unexpectedly have to come up with the workaround. With native I generally know where the bugginess is and plan for it, there's a small layer of indirection when you use RN. I say small because to be fair, in a world without deadlines I'd just vet every library I want to use upfront. But sometimes things slip, and finding out the component you used is failing on <insert specific android version or Samsung model> before right before release is a little scary (but again, even with native that's a risk).
  - deleted 10y ago
    [deleted]
benmmurphy 10y ago
i would try creating a minimum test case that reproduces the problem. you are probably not going to be able to get much help with your issue if others aren't able to reproduce it. to me it doesn't look like a memory corruption issue because you are seeing zero data as the corruption instead of trash data. but it could just be that whatever is corrupting the data is writing zeros :/ i'm not familiar with android but if its possible to turn on any runtime memory protections i would try that. if something is doing use-after-free or overflowing a buffer it might be able to catch where it is happening. https://source.android.com/devices/tech/debug/asan https://source.android.com/devices/tech/debug/asan

BoorishBears 10y ago

Because I've worked so much with native Android bugginess (versions of Android that crash if you try and pause an HTML5 video, crashes after X number of MediaPlayer loops where X is a large number around 5000, etc.), it can hard for me to use React Native because there's so many workarounds you're hoping the people behind components are implementing unless you want to start augmenting them yourself

nathan_f77 10y ago
That's actually one of the reasons why I like React Native, because I'm hoping that it can be like "jQuery" for Android apps (in terms of jQuery's cross-browser compatibility). I'm assuming that the core RN code already contains a lot of workarounds for different Android versions, so we can just use one consistent API via JavaScript. But you're right that it can get very tricky when you want to use a lot of third-party libraries. For example, I thought I would be able to just drop in 'react-native-blur' [1] and everything would work out of the box. I didn't realize that the Android component has been broken for a very long time, so I had to dive into the code and fix it. And then I ended up basically rewriting the whole library for iOS and Android, including the example apps, the README, and even the GIF in the README. But the nice thing is that other people can use it now, and they won't have to go through all of that. The other nice thing is that I learned a ton about developing native modules for React Native, so I don't regret it at all. Just think that you're going to have to implement those workarounds anyway, so it makes sense to contribute them to an open source library that everyone can use. For your video examples, it would be awesome if you could take a look at react-native-video [2], and see if they already include those workarounds. (I would personally appreciate that a lot, because I'm working on a cross-platform RN app that plays a lot of videos.) [1] https://github.com/react-native-community/react-native-blur https://github.com/react-native-community/react-native-blur [2] https://github.com/react-native-community/react-native-video https://github.com/react-native-community/react-native-video
- BoorishBears 10y ago
  The fear for me is running into a situation where I unexpectedly have to come up with the workaround. With native I generally know where the bugginess is and plan for it, there's a small layer of indirection when you use RN. I say small because to be fair, in a world without deadlines I'd just vet every library I want to use upfront. But sometimes things slip, and finding out the component you used is failing on <insert specific android version or Samsung model> before right before release is a little scary (but again, even with native that's a risk).
- deleted 10y ago
  [deleted]

benmmurphy 10y ago

i would try creating a minimum test case that reproduces the problem. you are probably not going to be able to get much help with your issue if others aren't able to reproduce it. to me it doesn't look like a memory corruption issue because you are seeing zero data as the corruption instead of trash data. but it could just be that whatever is corrupting the data is writing zeros :/ i'm not familiar with android but if its possible to turn on any runtime memory protections i would try that. if something is doing use-after-free or overflowing a buffer it might be able to catch where it is happening. https://source.android.com/devices/tech/debug/asan https://source.android.com/devices/tech/debug/asan