Тэги

Silverlight (36) WPF (10) IIS (7) Visual Studio (7) SharePoint (6) .Net Framework (5) ODP.NET (5) ASP.NET (4) C# (4) common (4) Network Settings (3) JavaScript (2) MS Office (2) Resharper (2) WCF (2) WEB (2) XPath (2) XSLT (2) ADO.NET (1) APEX (1) CMD (1) CSS (1) EF (1) HTML (1) Hardware bugs (1) Java (1) MS SQL (1) Oracle (1) PDF (1) Version Control (1) XAML (1)

среда, 10 марта 2010 г.

Silverlight: Популярный вариант утечки памяти связанный с динамическиизменяемым деревом элементов приложения Silverlight.

Нужно помнить следующий вариант утечки памяти, т.к., как мне кажется, он один из самых частых.

Вы создали элемент. (Все, забудьте в WPF / Silverlight слово "контрол" Улыбка ).
Вы добавляете этот элемент динамически в дерево элементов приложения Silverlight.
По действию пользователя вы заменяете этот элемент его новым инстансом (экземпляром).

Все красиво работает, все заменяется и потом удаляется сборщиком мусора, но до тех пор, пока вы не привяжете методы экземпляра вашего элемента, как обработчики событий элементов, постоянно находящихся в иерерхии элементов вашего Silverlight приложения.

Например, очень часто нужно реагировать на события Application.Current.RootVisual.

! Будте внимательны. Как только вы начинаете использовать элемент, как динамически добавляемый / заменяемый / удаляемый, то вы больше не может (не имеете права) привязывать методы его экземпляра к событиям элементов постоянно находящихся в иерархии приложения Silverlight, т.к. в этом случае удаленные / замененные экземпляры вашего элемента не будут уничтожатся сборщиком мусора благодаря механизму событий в .NET Framework.

Вариантов обхода этого ограничения много (Prism: Event Aggregator), поэтому используйте нужный вам по обстоятельствам.

Или используйте слабую ссылку - WeakReference

Чтобы копнуть глубже есть статья Слабые события в C#.

Комментариев нет:

Отправить комментарий