Silverlight 4 кажется голодной памятью

Question

Я немного поигрался с Silverlight и пытаюсь перенести приложение Silverlight 3.0 на Silverlight 4.0. Мое приложение загружает различные файлы XAP и по запросу пользователя создает экземпляр пользовательского элемента управления Xaml и добавляет его в основной контейнер, в своего рода MEF-подходе, чтобы я мог иметь расширяемое и подключаемое приложение.

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

На Silverlight 3.0 все работало без проблем. Переходя на SL 4.0, я заметил, что когда процесс подходит к созданию экземпляров пользовательских элементов управления, макет неожиданно замирает на минуту, а иногда и больше. Глядя на диспетчер задач, использование IE увеличивается с 50 МБ до 400 МБ, а иногда и до 1,5 ГБ.

Если процесс не займет так много времени, верстка будет отображена правильно, даже если использование памяти все еще очень велико. В противном случае происходит сбой из-за нехватки памяти.

При запуске того же приложения, скомпилированного в SL3, используемая память составляет около 200 МБ, когда загружены все пользовательские элементы управления. Время, затрачиваемое на загрузку приложения в SL3, составляет около 10 секунд, а в SL4 - до 3 минут. В макете нет прозрачных пленок, не заданы прозрачности, нет эффектов и анимации.

Пользовательские элементы управления создаются на лету и специально добавляются или удаляются в визуальном дереве, когда пользователь переключается с одного экрана на другой. Все ресурсы очищаются должным образом, когда пользовательское управление удаляется из визуального дерева, чтобы позволить ГХ работать в фоновом режиме.

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

Answer 1

UPDATE:

Сервисная версия Silverlight 4 для устранения утечек памяти: http://timheuer.com/blog/archive/2010/09/01/silverlight-service-release-september-2010-gdr1.aspx

Silverlight 4 обнаружил утечки памяти, и исправление в настоящее время тестируется.

Вот нить Microsoft об этом:

Пользователь "heuertk" - разработчик Microsoft Silverlight .... он объясняет проблемы и состояние исправления ...

http://forums.silverlight.net/forums/t/171739.aspx

Answer 2

Silverlight 4 протекает повсюду. Это не освобождает память должным образом.

Answer 3

Я продолжаю тестировать и хотел бы поделиться тем, что я обнаружил до сих пор. Может быть полезно понять поведение SL4.

Поскольку это звучит довольно странно, UIThread может так долго рендерить множество графических компонентов, и, учитывая, что Microsoft улучшила конвейер рендеринга, я вернул свое решение к SL3, но я сохранил SL4 установленным на своем локальном хосте.

Приложение использует службы RIA, и переход на SL4 вперед и назад означает, что я должен внести некоторые изменения в код согласно опубликованной документации.

Приложение работает очень гладко, чем когда оно было протестировано с Visual Studio 2008. Использование памяти ниже, чем было раньше, когда SL4 не был установлен.

Как только я переключаюсь на VS2010, это совершенно другой сценарий. Память растет бесконечно, компоновка медленна, чтобы уловить взаимодействие с пользователем, и иногда она зависает, как объяснено ранее.

Я отключил службы RIA, используя стандартную службу отдыха, и качество процесса не изменилось.

В заключение, учитывая, что я продолжу тестирование, чтобы наконец понять, что действительно мешает запустить приложение в приемлемом режиме, я считаю, что проблема с памятью связана с процессом отладки VS 2010 или комбинацией VS 2010 и SL4

Answer 4

Только для вашей информации: при использовании Silverlight Toolkit Charts в Silverlight 4.0 произошла утечка памяти. Это известная ошибка, и Microsoft работает над ней.

Answer 5

Честно говоря, несмотря на ваше утверждение «Все ресурсы очищаются должным образом, когда пользовательский элемент управления удаляется из визуального дерева», - вот где я бы начал искать. Это действительно пахнет элементами UserControls, не выпущенными должным образом.

Обычно это происходит, когда существуют долгоживущие (например, статические) объекты, которые вызывают события, к которым присоединяются более кратковременные объекты. Если эти обработчики событий не отключены, они оставляют эти объекты в памяти.