-
-
Notifications
You must be signed in to change notification settings - Fork 241
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Memory Leak in Navigation #1215
Comments
@JimGreenberg I'm subscribed to this, this has been a teething problem. @vakrilov 👍 |
I ended up switching to angular router outlet instead of page router n create my own stack of navigation (( |
Hey @JimGreenberg Some clarifications: Also using the stock So, here some suggestions on the particular problem:
I think there is a room for improvement in the framework for supporting such scenarios. So any ideas and suggestions are welcome. |
Hi @vakrilov, thanks for the response As we would expect, the tests done with Using The suggestion I would make is to have a configurable stack limit for the navigation- so developers could limit the navigation stack to a finite number of navigations- but this might be a much larger refactor than expected. |
For sure the About your other suggestion (limiting the nav stack) - indeed it might be more challenging thing to implement as you will have to clear only portions of the navigation stack. It is a good suggestion for a feature though, so it will be a good idea to open a separate issue about it. |
The abnormal memory behaviour is probably related to these open issues - Issue1/Issue2 in Angular repository. |
Just to add my 2ct. I recently had the pleasure to investigate a memory leak on an N-Angular app. The problem was only observable on iOS. Android released the memory just fine. It turned out the app had a lot of rxjs subscribe() calls but it never unsubscribed because the assumption was that would not be required because the component got destroyed which would clean up the subscriptions. Not on iOS it didn’t. So we added unsubscribe() calls in ondestroy and the problem was solved. |
Hey @EddyVerbruggen, |
Yeah in my case those were manual subscribes. Nothing automatic / behind the scene framework stuff that causes trouble afaik. So manually unsubscribe (in ondestroy) anything you’ve subscribed to previously - if using router back() navigation destroy should run and you get rid of the subscriptions. |
Hi @JimGreenberg, has there been any new progress on this issue? |
Hi @lankaixi , unfortunately no- we haven't made any progress specifically on this issue. We did as much as to identify and isolate the problem, and after exhausting the things in our control (like making sure all our rxjs subscriptions were properly disposed etc) we just left it in the back of our minds. As it turned out- none of our beta testers mentioned anything nor did we encounter it in our internal testing through normal use. While I'm keen on a solution, the "problem" wasn't really pressing- so we discontinued efforts towards it. Sorry I couldn't be more help |
Hi @JimGreenberg and @lankaixi Long story short: enabling angular prod mode significantly improved the situation:
@JimGreenberg - if you enable prod mode for the distributions for your beta testers, that might explain why they have never noticed a problem. More DetailsI've tested with a modified version of your original project - I have included 1000 Here is what I did in the tests:
Here is the result without And here is the result with Tips
|
Description of problem:
My team and I are working on an app and we noticed that after a number of navigations the app would ANR and crash under certain conditions. We suspected a memory leak- here is an example of the memory profile during a few repetitions of an action containing a navigation:
Note that more memory is freed after each GC.
Here is that same action repeated, but without the navigation:
Note that we're able to perform many more actions before the OS decides to GC, indicated by the fineness of the increases in allocated memory- and also that after the GC the memory drops to its starting point whereas the first example this was not the case.
Isolating the issue:
I've created a simple app here: testapp.zip
It consists of 2 pages with a large button that navigates between them. Because the components are so small compared to a production app, this did take some time, however the problem is still visible in the memory profile- memory is unbounded and increasing:
What I have tried:
Conclusion:
Should components revisited via forward navigation be reinstantiated? This seems like it could be the culprit, however I cannot verify. I'm curious as to whether there are some best practices that I missed, because this seems like such a general issue I'm surprised nobody else has encountered it- everything navigation related that we use is right out of the box. Similar issues posted here are either too old to be relevant (and were already marked as resolved) or related to something else entirely (images in particular).
Thanks for reading
The text was updated successfully, but these errors were encountered: