Using React Native 0.33
After some seconds, the application stops (only tested on Android)
Looking at the android logs I get :
I have no idea how to examine the problem.
this fixes my issue:
Add this to your "android/app/src/main/AndroidManifest.xml"
<application android:largeHeap="true"
ref: https://github.com/facebook/react-native/issues/6799
Using the below might help you
<application android:largeHeap="true">
But you might need to check your application for possible memory leaks. for eg:
Unreleased timers/listeners added in componentDidMount
Closure scope leaks.
Large image sizes.
Use of global variables.
We were facing the same issues with our react native app. It took us a lot of time and effort in making our apps somewhat stable. You can check out this blog which helped us a lot https://blog.swmansion.com/hunting-js-memory-leaks-in-react-native-apps-bd73807d0fde
Update:
Loading large amount of data in API continuously was putting load on the RAM at least on low end devices causing Out of Memory issues. You will need to clean this up as well and find a better and optimised way to load data.
For Android: in manifest file Android tag
application android:largeHeap="true"
android:hardwareAccelerated="true"
For iOS :Bundle React Native code and imagessection under the Build Phases
export NODE_BINARY=node
export NODE_ARGS=--max-old-space-size=8192
export NODE_OPTIONS=--max-old-space-size=8192
../node_modules/react-native/scripts/react-native-xcode.sh
Also if your app loading image from web then use below lib
https://github.com/fungilation/react-native-cached-image
Related
In a bigger project, I have a fairly high amount of used third-party libraries, including firebase, redux, etc and some more specific ones (but only used on several pages) like konvaJS, jimp, ....
I just migrated recently to nextJS to speed up the website & maybe allow SSR. However, after migrating, the Lighthouse Speedtest dropped compared to the Pure React Version. The main problem seems to be the shared JS first Load bundles.
After some optimizing, including lazy loading bigger Components with dynamic() & modules with await import(), I managed to compress the shared first load JS bundles by half, but they are still around 400KB which is way too heavy. I guess heavy modules like firebase are included there as well, because it is needed basically everywhere in the App.
I also tried to analyze the dependencies with #next/bundle-analyzer. But the Visualization is not really easy to interpret. Is it true that it also lists modules that are lazy loaded? And in addition, I have some dependency packed multiple times in different bundles. Last but not least, the bundles visualized by the analyzer do not match the names of the build output.
Any help to reduce or understand the process better is well appreciated. I am using current React & Next.js versions.
Edit: This is the composition of the shared JS bundles after build:
Edit2: I am still confused about the output of bundle-analyzer. The module jspdf for instance, is only used in one page / component and lazy loaded. Is it correct that it is still visible in the analyzer? It does not have any impact on the shared JS bundle size.
Edit3: I managed to lazy load my firebase modules (which are crucial for my App), so I saved over 200KB shared JS size. Still hoping to cut down the remaining. Btw, the bundle analyzers output did not really change.
Are you using FontAwesome?
We were able to reduce our "First Load JS shared by all" from
504kb down to 276kb
by removing FontAwesome dependency and downloading the individual .svg icons
directly.
Before
After
simple problem that I've seen asked in a few places and seems to have no structured answer. Because of this I though I would start a thread here and maybe get something going that will help everybody!
Diving right into it, I have build a react app using create-react-app, compiling this into a prod version using npm run build it does everything that it needs to and completes successfully.
After all of this we can observe the compiled app having multiple chunks.
All good and well until we enter the app and try to navigate to a different page, where we find it is not loading any other chunks besides the chunks responsible for the first page you access when entering the app.
This is the base problem, I realize I'm not giving any snippets or anything but again, this is because the problem seems very general, there are a lot of people with different applications and code looking for a solution to this and haven't found something practical and normal (having messaged some on forums and such).
If anybody needs any specific information to may case please ask and I will happily provide :)
As far as I can tell, this is webpack related or something like that, webpack from what I understand only includes one chunk and then loads the others as needed, is this correct?
If so and if the chunks are created but not loaded when switching to other pages, then it seems like a webpack issue, but what?
When you, then other developers, create a react app and it contains multiple chunks, do they load well?
Any and all information is appreciated, lets try to tackle this issue!
P.S. If you go into the compiled production build and manually add all the chunks, everything works perfectly. I will try to add any and all information to this thread as I find out more.
I've been working on an app I'm building, and until now it's had a reasonably small footprint. Today, however, I was looking into why my computer was suddenly running slowly, and I can see the app in Chrome is occupying around 1.2 GB of RAM!
Looking through my commits, I can't really spot anything suspicious. Where should I look when trying to debug enormous memory usage? I'd post code examples, but I can't see anything relevant, really.
To check what React is doing, try go get a snapshot of your app using the React profiler: Introducing the React Profiler
For everything else, try checking out the built-in profiler in the Chrome developer tools: Chrome DevTools: JavaScript CPU Profiling in Chrome 58
Those should be two good starting points to look at.
Sorry, we might need some more clarification about what you've tried.
It could be a ton of things. Most likely you're storing some sort data from the server or have some sort of memory leak (like adding something to a collection, but never deleting it).
One thing you can do is use the Chrome profiler to see when your memory climbs:
(This can be found in the drawer that open when you push Esc.)
The "Performance" tab can also be nice if you want to view the memory on pageload (using the 🔄button). Just make sure that memory is checked.
We have a sails-js app whose ui is built with React and state container custom created with MVVM method. Our app takes ridiculously too much memory (over 400mb) even when user isn't doing anything. At times it also just crashes (on the iphone cordova build specifically). Also, even though we do not have much actions involved (except loading and playing some web audio songs etc), our webpack bundle is over 18mb (unminimised, 2,5mb minimised).
So what could be the reason for the lagging performance and the oversized bundle? How can I fix it? One option I'm thinking that will hopefully resolve the matter is to implement Mobx instead of our custom solution for state management. Because it is extremely complicated for me and there's absolutely no documentation for it. Would you have reasons that will likely resolve my problem as well?
Thanks!
I found the first web page loading time for CN1 Javascript Built taking too long, need about 2 minutes.
I attached the Chrome's network loading screen shot, found the classes.js is the most heavy page, possible to zip it?
Second, there is 2 theme files that downloaded sequentially, is it possible for them to load at the same time?
Kindly advice.
Normally I would answer that you can look at the performance section of the developer guide but the relevant sections there relate to reducing the theme.res size which seems pretty small in your case.
The largest portion in your code is the class files so I'm guessing that the best way to reduce them is to further reduce dependencies so the obfucator can remove more dead code. Keep in mind that the classes.js file is cached and can be deployed via CDN's such as cloudflair to improve download speeds. It can be served in a gzipped form as well which is a part of the CDN repertoire.