Memory Leak in Navigation

[JimGreenberg]

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:

• Experimented with clearHistory option with navigationExtras
• Periodically calling the V8 GC explicitly
• Used the vanilla angular router outlet instead of NS's page router outlet
• Created a custom reuse strategy (page router outlet does not play nicely at all)
• Used the vanilla locationstrategy (NSLocationStrategy still spun up however)
• Refactored to have specific navigation be a child route of another component (This mitigated the issue heavily- enough so that an ANR might never occur under normal use)
  • This of course comes at the cost of defeating all of the features NS put in the page router, so implementing this fullscale seems impractical

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

[jogboms]

@JimGreenberg I'm subscribed to this, this has been a teething problem. @vakrilov 👍

[mhmo91]

I ended up switching to angular router outlet instead of page router n create my own stack of navigation ((

[vakrilov]

Hey @JimGreenberg
Thanks for the detailed explanation and the sample project!

Some clarifications:
Indeed when navigating forward(deeper) in the application with page-router-outlet - all the previous pages are kept in the nav-stack (that is the native behavior and also that is the reason for the custom router reuse strategy). This means that they are not subject to GC, as a reference to them is still kept in the backstack. Making navigation with clearHistory should clear all references and ultimately let GC collect the previous pages - you will loose the history though.

Also using the stock <router-outlet> will create and destroy the components on each navigation, but as you said you will loose the native-ness of the page navigation.

So, here some suggestions on the particular problem:

1. It is a good idea to avoid having a really deeps navigation stack. So if the user will come back to a particular page many times (ex. master -> detail -> master -> detail ....) you might consider doing back() navigation instead of forward or for clearing the history whenever the user arrives to the home screen.
2. Images - they are usually eating a lot of memory. You can check on the images optimizations article in the docs for ideas of limiting their impact.

I think there is a room for improvement in the framework for supporting such scenarios. So any ideas and suggestions are welcome.
One thing that we can probably investigate further is, wether there is a way to release large images (bitmaps) of elements that are currently in the navigation stack but now showing.

[JimGreenberg]

Hi @vakrilov, thanks for the response
I had thought that using the clearHistory parameter on ExtendedNavigationExtras would at least prevent memory from growing- this wasn't the case.
Pictured are 4 similar trials of the test app- 2 with clearHistory and 2 each using routerLink and a regular navigate(). There aren't any major differences- all 4 follow the same pattern so I didn't feel the need to distinguish them.

As we would expect, the tests done with clearHistory logged that the component was being destroyed (and likewise, that without clearHistory the components are not destroyed)- but again, no drop in memory.

Using back() did work- we returned to the previous component and no memory increase was seen. But manually calling back() in order to keep the app from running out of memory seems hacky- and also for our app in particular we want to prevent the user from going back to certain pages.

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.

[vakrilov]

For sure the clearHistory parameter should do a proper cleanup and prevent memory leaks. So this one definitely sounds like a bug and we will investigate it.

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.

[ADjenkov]

The abnormal memory behaviour is probably related to these open issues - Issue1/Issue2 in Angular repository.
Even after explicit ComponentRef.destroy() in our custom reuse strategy the memory for that component is not released.
OnDestroy is properly called, but I suspect that any injected dependencies are still there and running, even though the component is gone.