Управление памятью/ресурсами с помощью MonoTouch и MonoTouch.Dialog

У меня есть приложение MonoTouch, у которого есть UITabBarController, причем каждая из вкладок является UINavigationController. Некоторые из них завершают UIViewController, который добавляет UITableView и UIToolbar, а другие переносят DialogViewController.

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

До сих пор я предполагал, что каждый DialogViewController, который я нажимаю на стек nav, очищает свои представления и другие вещи, которые он выделяет, когда я его всплываю. Но я начинаю понимать, что это, вероятно, не так просто, и что мне нужно начать вызов Dispose() на вещи.

Существуют ли лучшие методы для управления ресурсами и памятью с помощью MonoTouch и MT.D? В частности:

Требуется ли вызывать Dispose на DialogViewController после его всплытия? Если да, то где это лучше всего сделать? (ViewDidUnload? DidReceiveMemoryWarning? Destructor?)
DVC автоматически удаляет объекты, подобные RootElement, которые ему переданы, или мне нужно беспокоиться об этом? Как насчет UIImages, который он загружает как часть рендеринга ячейки таблицы (например, StyledStringElement)?
Есть ли места, где я должен называть GC.Collect(), чтобы лучше выделять коллекции, чтобы не отвлекаться на отзывчивость, когда происходит GC?
Помогает ли сборщик мусора генерации с проблемами интерактивности и достаточно ли он достаточно для использования в производственном приложении? (Я считаю, что он все еще выставлен как "экспериментальный" в MonoDevelop 3.0.2/MT 4.3.3)
Что мне нужно сделать в DidReceiveMemoryWarning, чтобы уменьшить вероятность того, что iOS запустит мое приложение? Поскольку каждый невидимый контроллер представления, похоже, получает этот вызов, я предполагаю, что я должен очистить ресурсы этого контроллера представления... должен ли я делать то же самое, что и в ViewDidUnload?
Кажется, я не вызываю вызов ViewDidUnload (даже после получения DidReceiveMemoryWarning). На самом деле я не помню, чтобы когда-либо видел это в моем журнале. Если iOS всегда вызывал мою ViewDidUnload после DidReceiveMemoryWarning, я мог бы просто выполнить всю очистку в ViewDidUnload... Каков наилучший способ разделить ответственность очистки между ViewDidUnload и DidReceiveMemoryWarning?

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

Обновить: чтобы сделать вопрос более конкретным: после использования инструментов и профайлера Xamarin Heapshot мне ясно, что я утечка UIViewControllers, когда пользователь всплывает стек навигации. Рольф подал bug для этого, и у него есть два дубликата, так что это реальная проблема не только для меня. К сожалению, я не нашел хорошего обходного пути для утечки UIViewControllers - я не нашел подходящего места для вызова Dispose(). Естественное место для свободных ресурсов, выделенных ViewDidLoad, находится в сообщении ViewDidUnload, но оно никогда не вызывается на симуляторе, поэтому объем памяти продолжает расти. На устройстве я вижу DidReceiveMemoryWarning, но я не хочу использовать это как место для свободного доступа к моему контроллеру и его ресурсам, поскольку мне не гарантировано, что iOS фактически выгрузит мое представление и, следовательно, не гарантирует, что мой ViewDidLoad снова будет вызван либо (приводя к ViewDidAppear, который должен был бы защищать код от ситуаций, когда были расположены его основные ресурсы). Я хотел бы получить совет о том, как выйти из этого беспорядка...

Ответ 1

Я провел пару дней в исходном коде MTD и в профилировщике. Хотя я все еще ищу общие рекомендации относительно того, какой лучший шаблон проектирования для реализации DidReceiveMemoryWarning и ViewDidUnload, у меня есть общие замечания, которые могут быть полезны кому-то:

MonoTouch.Dialog очень хорошо себя ведет. Это не утечка каких-либо ресурсов при обычном использовании. Он держит дерево управления под DVC.Root и каждый метод Dispose Element Dispose содержит базовый элемент управления UIKit. Вам даже не нужно беспокоиться об утилизации старого RootElement, если вы заменили DVC.Root - средство настройки свойств автоматически использует его для вас. В целом, MTD, похоже, не страдает от существенных проблем с памятью. Существует одно исключение - см. Ниже.
При создании собственных пользовательских элементов (например, MultilineEntryElement) обязательно переопределите метод Dispose (bool), удалив базовый элемент управления UIKit (например, UITextView) и связав метод базового класса Dispose(). Исходный код проекта Miguel MT.D github содержит множество хороших примеров. Все элементы реализуют стандартный шаблон Dispose (хотя они опускают деструктор/финализатор, который вызывает Dispose (false)).
При реализации настраиваемых контроллеров представлений обычно нет необходимости реализовывать Dispose в подклассах UIViewController, а также в классах TableView DataSource или Delegate. Когда контроллер просмотра получит GC'ed, он будет правильно вызывать Dispose по его ссылкам. Все ячейки, которые вы выделяете в DataSource, будут правильно настроены.
В качестве исключения для (3) - я столкнулся с неприятной проблемой при добавлении моего собственного поднабора в ячейку TableView. Этот подвью - это элемент управления, который я создал под названием "UICheckbox", который в конечном итоге наследует UIImageView, который имеет два UIImages (вкл. И выкл.) И публичное событие с именем Clicked. Я испытываю только проблему, когда обработчик события, который ссылается на элементы DataSource, подключен к этому событию (если обработчик события не ссылается на сам DataSource или контроллер, все хорошо). Однако, когда выполняются вышеприведенные условия, и контроллер отклоняется, по-видимому, существует некоторый цикл, который GC не может понять, и каждый UICheckbox, который я помещал в TableView, просочился (вместе с его изображениями). Единственный способ, с помощью которого я работал, это добавить код в ViewDidDisappear, чтобы избавиться от ViewController и очистить его IFF состояния, он больше не находится в стеке навигации. Он взломан, но работает.
В общем, я придерживаюсь следующего шаблона для размещения объектов в контроллерах моего представления:
- ничего не выделять в конструкторе (используйте его только для передачи состояния)
- создайте дерево управления в ViewDidLoad (и удалите его в ViewDidUnload). подумайте "InitializeComponent" в XAML (если это поможет). Если UIViewController собирается нажимать DialogViewController на стек навигатора, ViewDidLoad является хорошим местом для создания DVC.
- инициализировать значения в дереве управления в ViewDidAppear. Например. вы можете добавлять/удалять/заменять элементы, разделы и даже корень DVC в этом методе. Но не создавайте новый DVC.
Существует общая проблема с утечкой ViewControllers, когда пользователь переводит навигационный стек (я ссылаюсь на ссылку bugzilla в "Обновить" в вопросе). Это также влияет на MT.D. Существует довольно простой способ обхода - добавьте следующую строку кода в ViewDidAppear родительского контроллера представления:
```
    // HACK: touch the ViewControllers array to refresh it (in case the user popped the nav stack)
    // this is to work around a bug in monotouch (https://bugzilla.xamarin.com/show_bug.cgi?id=1889)
    // where the UINavigationController leaks UIViewControllers when the user pops the nav stack
    int count = this.NavigationController.ViewControllers.Length;
```

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

Я надеюсь, что кто-то найдет это полезным. Я также надеюсь, что кто-то умнее меня имеет некоторые рекомендации относительно того, как обращаться с DidReceiveMemoryWarning и как разделить работу между этим методом и ViewDidUnload.

Обновление: Еще несколько заметок:

Теперь я понимаю протокол для DidReceiveMemoryWarning и ViewDidUnload: первый всегда доставляется к каждому контроллеру представления, в то время как последний отправляется только для контроллеров представления, которые в настоящее время не отображаются, И не глубже, чем корень навигации стек. В конце концов, я решил игнорировать DidReceiveMemoryWarning, потому что на самом деле у меня нет изображений, которые я кэширую и могу сбросить (согласно руководству iOS). В ViewDidUnload я освобождаю все ресурсы, которые я выделил в ViewDidLoad.
В моем приложении есть TabBar, где на каждой вкладке находится UINavigationController, большая часть которого вызывает DialogViewController. Одной из проблем, с которыми я столкнулся, является утечка DialogViewController после того, как ViewDidUnload отпустил ссылку на него. Я попробовал Disposing DVC в ViewDidUnload, но iOS продолжал настаивать на его повторении, и я получал исключение для вызова селектора на объект GC. Я обнаружил причину - контроллер навигации держался на DVC в массиве ViewControllers. Решение состоит в том, чтобы освободить массив, создав вместо него массив нулевой длины - в ViewDidUnload:
```
this.ViewControllers = new UIViewController[0];
```

Старый массив теперь будет GC'ed, так же как и DVC, потому что больше ничего не указывает на него. И iOS никогда не будет повторно запускать объект. Примечание - нет необходимости вызывать Dispose на DVC.