Утечка памяти в .NETCF - создание динамических элементов управления?

Question

У меня проблема с утечкой памяти в приложении .NET CF.

Использование RPM Я определил, что динамическое создание элементов управления не является сборкой мусора, как ожидалось. Выполнение одного и того же фрагмента кода в формах .NET Window ведет себя по-разному и предоставляет управление, как я ожидал.

Смотрите вывод из RPM через PerfMon для процесса Heap счетчик:

GC Heap:

Мое предположение, что слабое Ссылка на панель является по какой-то неизвестной причине не сделать объект подходящим для GC, не так ли?

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

Я включил упрощенную версию источника, чтобы проиллюстрировать эту проблему:

using System; 
using System.Windows.Forms; 

namespace CFMemTest 
{ 
    public partial class Form1 : Form 
    { 
     public Form1() 
     { 
      InitializeComponent(); 
     } 

     // Calling this event handler multiple times causes the memory leak 
     private void Button1_Click(object sender, EventArgs e) 
     { 
      Panel uc = new Panel(); 
      // Calling uc.Dispose() cleans up the object 
     } 
    } 
} 

Обновление:
1. Вызов GC.Collect() также не приводит к панелям очищаемой вверх ,
2. Использование .NET CF 2.0 SP1 на устройстве Windows CE 4.2.

Answer 1

Дополнительная информация здесь, объясняющая это поведение.

According to Ilya Tumanov:

Все пользовательский интерфейс, связанный с NETCF является преднамеренно удален из GC объема так он никогда не собирал. Это поведение отличается от рабочего стола и было изменено в NETCF V3.5 (если не работает в режиме совместимости).

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

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

Answer 2

Уверены ли вы, что у вас есть утечка памяти? Сборщик мусора .NET Compact Framework работает несколько иначе, чем в полной платформе .NET. От Steven Pratschner's blog:

Коллекция инициируется, когда:

• 1MB объектов были выделены,

• Приложение перемещается в фоновом режиме,

• Сбой для выделения памяти

• Приложение вызывает GC.Collect.

Answer 3

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

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

Я настоятельно рекомендую вам взглянуть на MSDN webcast on memory management in the CF. Он дает гораздо более подробное объяснение тому, что происходит под капотом - гораздо больше, чем мы могли бы дать в ответе здесь.

Answer 4

Я думаю, что вам нужно динамически удалить кнопки Click EventHandler тоже, как вы можете видеть из этого блога: http://blogs.msdn.com/stevenpr/archive/2007/03/08/finding-managed-memory-leaks-using-the-net-cf-remote-performance-monitor.aspx

Это от Стивена Pratschner тоже.

Кстати, аудиофайл упоминался выше, связан здесь: http://msevents.microsoft.com/cui/WebCastEventDetails.aspx?culture=en-US&EventID=1032318791&CountryCode=US

Надеется, что это помогает!