Are silverlight pages initialized every time they are called? InitializeComponent();
Once they are called is this stored in memory?
If they are Initiallzed everytime they are called is there a way to check to see if it has already been rendered so as to bypass the rendering of the page?
A page is an object like any other - if you create one, then navigate to a different page, the original is no longer referenced and becomes eligible for garbage collection. If you visit the page again, you get an all-new instance.
You asked this question in terms of a preconceived solution (avoid page rendering). What is the underlying issue that led you to consider this approach?
Related
I'm working on an MVVM (WPF) application that features one main container. The view that is displayed depends on a menu item that is selected (e.g. Home, Product Information etc.). Whenever a view is accessed for the first time, memory consumption goes up slightly as the associated view model is instantiated; when the same view is further accessed, memory stays the same since the existing instance of the associated view model is used.
However, one view containing a WebBrowser control increases memory usage by ~80MB each time it is accessed without exception; this memory never gets freed — repeatedly switching between Home and that view can cause the application to run out of memory and crash. Using a memory profiler I discovered that this increase happens in unmanaged code, particularly user32.dll.
Going through other StackOverflow posts, I noticed that there is a recurring problem with WebBrowser and memory leaking, but most posts point towards this being an issue with IE7. We're enforcing the usage of IE11 for our application. I need some help investigating this problem and a potential resolution. I'm afraid I can't post code, but any hint can be helpful.
I found the issue and it has nothing to do with the WebBrowser control being leaky. The code (I didn't write it) passed the instance of WebBrowser from the view to the view model thus making the view model contain a hard reference to the view. Since the lifespan of the view model corresponds to the lifespan of the application, those references to the views were forever held. Replacing that logic with a proper one fixed the issue.
I'm new to mobile development, and by extension, Xamarin. One thing I've always noticed is that any time a page is loaded, people always request to make a new page() as opposed to have a pool or set list of pages they can access.
Won't this cause memory problems? Does Xamarin automatically remove older pages from the scope? Sorry if it sounds like a dumb question, but it's something that threw me off as my first instinct as a programmer is usually to limit unnecessary repeats of data in the memory.
Xamarin is .NET based technology and as such memory management is based on the garbage collection. As such if you follow good practices your generated page that is not needed anymore should be garbage collected at some point.
This is a good question. If you are having a memory leak on the page navigation, you can look at this document first.
The NavigationPage class provides a hierarchical navigation experience where the user is able to navigate through pages, forwards and backwards, as desired. The class implements navigation as a last-in, first-out (LIFO) stack of Page objects.
So you can see that all the pages are on the stack when you are navigating the page. Simply put, xamarin handles their memory release internally as the stack is pushed.
If you are still concerned about memory leaks, you can refer to Xamarin.Forms App Lifecycle to manually release objects based on the end of the page's life cycle.
About Explicit call to garbage collector on navigation back in the stack
This one is a controversial one. Some people say that you should never explicitely call to garbage collector. And, in general, I would agree with this. However, in Xamarin the magic call to GC.Collect() can do wanders. If nothing else helps, just call to GC.Collect(); immidiately after calling await _navigation.PopAsync(true) .
I have a Windows 10 UWP app where I do alot of navigation using
Frame.Navigate(typeof(myClass));
I know that this creates a new instance of the class, myClass in this case, when I navigate. This is all working just fine and I am okay with it.
I do also know that I can set navigation cache, particularly when you are going to use the back stack to navigate. However, I am not doing any of that. I basically have a button to go forward and a button to go back. When the button is clicked, I just call Frame.Navigate as I show above.
The reason I do this, I don't want to have to worry about the navigation stack when I want to go forward and back with this simple navigation.
That said, here is the question. I know that the GC can take time to dispose of the instance of the class. If I navigate quickly from class to class, is it possible that GC did not dispose yet and I am instantiating multiple instances of the class? If so, should I explicitly dispose of the class somehow? I am thinking if I override the OnNavigatedFrom and dispose in there?
So, for example, let's say the following is called quickly (within a second or so) because the user is hitting the buttons to go back and forth.
Frame.Navigate(typeof(myClass));
Frame.Navigate(typeof(myClass2));
Frame.Navigate(typeof(myClass));
Frame.Navigate(typeof(myClass2));
Is it possible to end up with two instances of each class temporarily until GC gets around to cleaning up? How should I keep this all clean?
Thanks!
In UWP (XAML / C#) I use Frame.Navigate(typeof(Page2));, and in C# of Page2 I use timer and when I use Frame.GoBack();, the frame really goes back, but the timer is not stopped - I mean the page and all its components are still running in the background, and the app is consuming too much RAM because of that. How can I "kill" the page?
note: if user uses this navigation 10 times, the page is 10 times in the background and it is bad..
It is important to understand that CLR garbage collector is the one who is responsible for "killing" unused objects. An object (and all of it's members) becomes "unused" when it is no longer referenced.
When you start a Windows.UI.Xaml.DispatcherTimer, it adds itself to a timer collection inside the current Dispatcher, thus, creating a direct reference between the Dispatcher and the timer. The timer, in its turn, holds a reference to the page where it is running. Since the Dispatcher is a global object, it will keep your page alive until the timer is stopped.
There can be other causes of memory leak (it is a pretty broad topic), including:
Other sources of direct or indirect references to your page;
Subscriptions to static events;
Complex data bindings like {Binding Path=Property.Subproperty};
I would suggest you to use a memory profiler to find memory leaks if the above doesn't help, such as the Diagnostic Tools included in Visual Studio 2015.
I have a simple aspx page.
I need to instantiate a class object myObj one time on first hit. On subsequent hits from clients the same object needs to be used.
I am reading a file from local drive when obj is created and also maintaining some state. On subsequent hits I want object to be not created but states to be maintained.
I would cache the obj on Application_Start() in the global.asax.
Just be certain you're persisting state after each hit.
See this Caching Objects article to get started. Keep in mind, if you are making changes to the object it can be dangerous due to multi-user collisions so it's best to use the cache for data that you need to reference a lot. A list of states, text strings used throughout, settings, etc. that don't change but you need everywhere are perfect items for the cache.