loadNibNamed утечка topLevelObjects

Question

loadNibNamed утечка topLevelObjects

Я использую пользовательские ячейки и звоню loadNibNamed:, Кажется, это вызывает утечку памяти, и я не уверен, как ее решить. Если я установлю объекты верхнего уровня в nil после этого я все еще получаю утечку.

topLevelObjects = [[NSBundle mainBundle] loadNibNamed:@"customCell" owner:self options:nil];

Я тогда делаю это

for (id currentObject in topLevelObjects){
        if ([currentObject isKindOfClass:[UITableViewCell class]]){
            cell =  (CustomCell *) currentObject;
            break;
        }
    }

а затем измените свойства ячейки.

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

0

ios objective-c uitableview automatic-ref-counting loadnibnamed

Источник

user356387 19 апр '13 в 14:02

3 ответа

Другие вопросы по тегам ios objective-c uitableview automatic-ref-counting loadnibnamed

user1722214 13 дек '13 в 00:30 2013-12-13 00:30 · Answer 1 · 2013-12-13 00:30

Ответ Мэтта на месте. Вот как выглядит код. Исправлена проблема с памятью сразу, так как ячейка теперь загружена и снята с очереди в порядке.

Сначала зарегистрируйте перо

[self.tableView registerNib:[UINib nibWithNibName:@"customCell"
                                           bundle:nil] 
                           forCellReuseIdentifier:@"customCellID"];

Во-вторых...

CustomCell *cell = [tableView dequeueReusableCellWithIdentifier:@"customCellID"];

Перо нуждается только в одной ячейке таблицы, и вы готовы!

user341994 19 апр '13 в 14:45 2013-04-19 14:45 · Answer 2 · 2013-04-19 14:45

Я подозреваю, что ваша утечка может исходить из розетки в кончике. Обратите внимание на эту фразу в документах на loadNibNamed::

Для установки подключений к розетке этот метод использует метод setValue:forKey:, который может привести к автоматическому сохранению объекта в розетке.

Другими словами, loadNibNamed иногда накладывает дополнительное сохранение из-за странного способа работы кодирования значения ключа.

Тем не менее, это спекуляция, и в этом нет необходимости, потому что вам не нужно звонить loadNibNamed: на первом месте!

Вы используете пользовательский подкласс UITableViewCell, разработанный в виде кончика? Тогда почему бы не сделать это обычным способом? Сделайте перо, содержащее один объект верхнего уровня: ячейку. Создайте ячейку в кончике, установите ее класс, подключите ее к розеткам и т. Д. registerNib:forCellReuseIdentifier: на табличном представлении, чтобы рассказать табличному представлению о вашем наконечнике. Когда вы позже позвоните dequeueReusableCellWithIdentifier:, если в куче повторного использования нет свободных ячеек, табличное представление загрузит ваше перо и передаст вам ячейку. Нет суеты, нет суеты.

user171562 19 апр '13 в 16:50 2013-04-19 16:50 · Answer 3 · 2013-04-19 16:50

Рассмотреть возможность использования UINib вместо. UINib кэширует содержимое файла nib в памяти, сохраняя поездки в файловую систему. Так, например, вы можете создать экземпляр nib и ссылку в свойстве:

self.cellNib = [UINib nibWithNibName:@"customCell" bundle:nil];

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

[self.cellNib instantiateWithOwner:self options:nil];
cell = self.customCell;
self.customCell = nil;

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