Мои контроллеры представления сохраняются (я думаю), но я не могу найти сильную ссылку - PullRequest
Новая
       10

Мои контроллеры представления сохраняются (я думаю), но я не могу найти сильную ссылку

0 голосов
/ 11 октября 2019

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

  • Для каждого из моих классов я хотел бы включить deinit, который регистрирует сообщение. Так я впервые узнал, что объекты не были освобождены.
  • Когда я исследовал график памяти, я обнаружил контроллеры представления, которые были отключены, но все еще находятся в памяти. Ничто визуально не выглядело как цикл сохранения. Все ссылки weak var. Не было никаких предупреждений от Xcode.
  • Когда я пропустил мемграф через утечки, он сообщил: 0 leaks for 0 total leaked bytes.

Когда я играл с утечками, я заметил команду под названием traceTree. Я запустил его с адресом объекта, которого не должно быть. Он сообщил следующее ... 

2 <CaptureViewController 0x7fee7a008800> [1536]
  2 <WaterfallCollectionViewLayout 0x7fee47c0b450> [368]   +264: delegate 0x7fee47c0b558
    2 <UICollectionView 0x7fee7a060e00> [3072]  +1744: __strong _layout 0x7fee7a0614d0
      1 0x7fee47c10590 [112]    +24:  0x7fee47c105a8 --> offset 2
      + 1 0x7fee7b028000 [16896] +10600:  0x7fee7b02a968
      +   1 Region libobjc.A.dylib __DATA __bss: 'objc::AssociationsManager::_mapStorage' 0x7fff89c160c8
      1 0x7fee67d02c30 [304]   +112:  0x7fee67d02ca0
        1 0x7fee67d02100 [304]     +8:  0x7fee67d02108
          1 0x7fee7900be00 [8704]  +2432:  0x7fee7900c780
            1 Region dyld __DATA __common: '_main_thread' + 800 0x1155e1060

Вопрос : Я действительно не знаю, на что смотрю. Это говорит мне о том, что есть сильная ссылка от WaterfallCollectionViewLayout до CaptureViewController?

CaptureViewController - это UICollectionViewController, а WaterfallCollectionViewLayout - это пользовательский UICollectionViewLayout. Класс макета использует контроллер представления коллекции в качестве делегата для целей макета. Похоже на это ... 

protocol WaterfallCollectionViewLayoutDelegate: class {
    func waterfallCollectionViewLayout(_ waterfallCollectionViewLayout: WaterfallCollectionViewLayout, sizeForCellAt indexPath: NSIndexPath, fitting size: CGSize) -> CGSize
}

class WaterfallCollectionViewLayout: UICollectionViewLayout {

    /* ... */

    weak var delegate: WaterfallCollectionViewLayoutDelegate!

    /* ... */

}

Любые предложения или советы будут с благодарностью.

1 Ответ

0 голосов
/ 15 октября 2019

Я понял это, ладно. Оказывается, было закрытием.

Я реализовывал новый источник данных, который можно использовать для закрытия ячеек и необязательное закрытие для предоставления заголовков. Я не использовал «слабое я» в этих замыканиях.

Вывод заключается в том, что отладчик может вводить в заблуждение: он показал мой UICollectionViewLayout как единственную ссылку на мой объект, хотя эта ссылка была слабой. Я обнаружил истинного виновника, установив эту конкретную ссылку на nil в viewDidDisappear, и внезапно отладчик стал намного полезнее. * Достижения в источниках данных пользовательского интерфейса - WWDC 2019 - 220

...