NotificationCenter.default.addObserver продолжает вызываться несколько раз с Unwind Segue - PullRequest
0 голосов
/ 25 января 2019

Я использую show segue и unwind segue для навигации между двумя iOS viewControllers, VC1 и VC2.В viewDidLoad() VC2 я делаю VC2 наблюдателем.Вот мой код:

override func viewDidLoad() {
    super.viewDidLoad()

    NotificationCenter.default.addObserver(forName: NSNotification.Name(rawValue: "buzzer updated"), object: nil, queue: OperationQueue.main) { _ in
        print("set beeperViewImage")
    }
}

Каждый раз, когда я использую sewwind для перехода от VC2 обратно к VC1, addObserver() вызывается дополнительное время, например, при четвертом возврате segue addObserver называется4 раза;на пятом segue, пять раз и т. д. Это происходит даже тогда, когда приложение отправляется в фоновый режим и вызывается.Он запоминает, сколько сегментов произошло в предыдущем сеансе, и получает отсчет оттуда.

У меня нет проблем с несколькими вызовами в VC1, который является исходным VC.

Я пыталсяустановите VC2 на ноль после раскрутки.

С нетерпением ждем каких-либо указаний.

Ответы [ 2 ]

0 голосов
/ 27 января 2019

Спасибо всем за ваши комментарии по моей проблеме.Основываясь на них, я начал искать то, что могло бы держаться за мой VC2.Оказывается, что причиной моего вызова VC2 viewWillAppear () был вызов на чтение радиосвязи Bluetooth, но я не понимаю, почему:

self.radio?.peripheral?.readValue(for: (self.radio?.buzzerChar)!)

Все работает нормально после удаления вышеуказанной строки кода.Еще раз спасибо за указание, в каком направлении искать.

0 голосов
/ 26 января 2019

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

Например, рассмотрим этот безобидный пример:

extension Notification.Name {
    static let buzzer = Notification.Name(rawValue: Bundle.main.bundleIdentifier! + ".buzzer")
}

class SecondViewController: UIViewController {

    override func viewDidLoad() {
        super.viewDidLoad()

        NotificationCenter.default.addObserver(forName: .buzzer, object: nil, queue: .main) { _ in
            self.foo()
        }
    }

    func foo() { ... }
}

Если я затем войду и выйду из этого контроллера вида три раза, а затем нажму на кнопку enter image description here «график отладочной памяти», я увижу следующее:

enter image description here

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

В этом случае, поскольку я включил функцию «Malloc Stack» в «Product» »« Scheme »» «Edit Scheme ...» »« Run »» «Diagnostics» »« Logging », я вижу составить трассировку в самой правой панели и даже нажать кнопку со стрелкой enter image description here и перейти к нарушающему коду:

code

В этом конкретном примере проблема заключалась в том, что я (намеренно, в иллюстративных целях) ввел постоянную сильную ссылку, где Центр уведомлений поддерживает строгую ссылку на self, навязанную закрытием наблюдателя. Это легко исправить, используя шаблон [weak self] в этом замыкании:

NotificationCenter.default.addObserver(forName: .buzzer, object: nil, queue: .main) { [weak self] _ in
    self?.foo()
}

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

Но с помощью этой кнопки «Диаграмма отладочной памяти» вы можете не только (а) подтвердить, что в памяти действительно есть несколько экземпляров вашего соответствующего контроллера представления; но также (б) определить, что установило эту сильную ссылку. Оттуда вы можете диагностировать причину проблемы. Но кода в вашем вопросе недостаточно, чтобы вызвать эту проблему, но я подозреваю, что где-то существует сильный цикл ссылок.

...