Синхронизация изолированного метода MainActor во время инициализации и обеспечение параллелизма Swift 6

Я не хочу, чтобы мой LogManager был изолирован от MainActor, поскольку его можно вызывать из множества разных потоков.

В этом суть дела: вам нужно перестать так думать. Это именно та глупость, которую решает Swift Concurrency.

Избавьтесь от всех объектов DispatchQueue в своем коде (за исключением редких случаев, когда они могут вам понадобиться, чтобы сделать тип @unchecked Sendable действительно потокобезопасным — но на самом деле это не тот случай) и тщательно и последовательно внедряйте Swift Concurrency. . Тогда нет «потоков» и переключение контекста перестает иметь значение. Просто изолируйте LogManager от какого-нибудь актера и перестаньте беспокоиться.

Предположим, просто ради примера, что мы изолируем LogManager от главного актера. Тогда мы можем переписать это так:

@objc @MainActor public final class LogManager: NSObject {

    static let sharedInstance = LogManager()
    private let loggingActor = LoggingActor()

    private override init() {
        super.init()
        Task {
            await loggingActor.log(UIDevice.current.systemName)
        }
    }

    func log(_ what: String) {
        Task {
            await loggingActor.log(what)
        }
    }

    actor LoggingActor {
        private var _logs: [String] = []
        func log(_ log: String) {
            self._logs.append(log)
            print("****LogManager**** \(log)")
        }
    }
}

Теперь, когда мы вызываем LogManager.sharedInstance.log(#function) в didFinishLaunching, мы получаем:

****LogManager**** iOS
****LogManager**** application(_:didFinishLaunchingWithOptions:)

какой правильный порядок. Все упорядочено и будет оставаться в правильном порядке, потому что за этим стоит полная уверенность и доверие Swift Concurrency. Если вы находитесь на другом актере, а не на главном актере, и вы не находитесь в методе async, то вы скажете

    Task {
        await LogManager.sharedInstance.log(#function)
    }

и вы все равно получите все в правильном порядке.

Вот действительно приятная часть. Давайте решим полностью отделить LogManager от главного актера и изолировать его от нашего собственного глобального актера:

@globalActor public actor LoggingGlobalActor {
    public static let shared = LoggingGlobalActor()
}

@objc @LoggingGlobalActor public final class LogManager: NSObject { // ...

Что происходит, когда мы это делаем? Абсолютно ничего! Весь наш код продолжает работать так же, как и раньше. И в этом моя точка зрения: ваше «его можно вызывать из разных потоков» полностью отпадает.

Если вы хотите, чтобы сообщения журнала отображались в правильном порядке, используйте свою очередь, например:

@objc
public final class LogManager: NSObject, @unchecked Sendable {
    @objc(sharedInstance)
    static let shared = LogManager()

    private var _logs: [String] = []
    private let serialQueue = DispatchQueue(label: "LoggingSerialQueue")

    private override init() {
        super.init()

        serialQueue.async {
            let message = DispatchQueue.main.sync {            // note, we rarely use `sync`, but this is an exception
                SysInfo.sysInfo()
            }
            self.appendToLog(message: message)
        }
    }

    func log(_ message: String) {
        serialQueue.async {                                    // but do not use `sync` here; why make the caller wait?
            self.appendToLog(message: message)
        }
    }
}

private extension LogManager {
    func appendToLog(message: String) {
        dispatchPrecondition(condition: .onQueue(serialQueue)) // make sure caller used correct queue
        _logs.append(message)
        print("****LogManager**** \(message)")
    }
}

private final class SysInfo {
    @MainActor
    static func sysInfo() -> String {
        UIDevice.current.systemName
    }
}

Используя очередь, вам гарантирован порядок выполнения.

Несколько наблюдений:

1. Нет причин, по которым ваша функция log должна выполняться синхронно с вашей serialQueue. Вы ничего не возвращаете, поэтому sync не нужен и только снижает эффективность. Сейчас это, возможно, не имеет большого значения, но давайте представим, что ваш регистратор тоже записывает информацию в постоянное хранилище; вы не хотели бы существенно влиять на производительность вашего приложения из-за вашей системы журналирования.

2. dispatchPrecondition не требуется, но хорошей практикой является, чтобы метод, зависящий от конкретной очереди, явно указывал это требование. Таким образом, отладочные сборки предупредят вас о неправильном использовании. Это закрытый метод, поэтому мы знаем, что потенциальное неправильное использование ограничено этим классом, но это по-прежнему разумный метод защитного программирования при написании кода GCD. Это NOOP в сборках релизов, поэтому у защитного программирования нет недостатков.

3. Не имеет отношения к рассматриваемому вопросу, но соглашение для синглтонов в Swift — shared, поэтому я переименовал его соответствующим образом. Но я также указал @objc(sharedInstance), чтобы вызывающие объекты Objective-C пользовались соглашениями об именах Objective-C.

   Но если вы действительно хотите сохранить версию Swift под названием sharedInstance, это ваш выбор. Но просто поймите, что это не стандартное соглашение.

Кроме того, вы можете рассмотреть возможность полного отказа от этого специального менеджера журналирования и использования встроенной системы Unified Logging . В устаревших кодовых базах мы бы использовали OSLog . Я знаю, что это неприменимо к вашему случаю, но в iOS 14 и более поздних версиях можно использовать Logger вместо OSLog.

Система «Единое журналирование» предлагает множество преимуществ по сравнению с пользовательскими системами журналирования:

1. Вы можете щелкнуть правой кнопкой мыши сообщение журнала и перейти непосредственно к источнику, сгенерировавшем журнал в Xcode 15+.

2. При запуске приложения на устройстве вы можете отслеживать сообщения журнала в консольном приложении macOS. В целом это полезно, но бесценно при мониторинге фоновых задач, отслеживании журналов на устройстве и т. д.

3. Как в Xcode, так и в консоли macOS вы можете классифицировать сообщения журнала как сообщения отладки и сообщения об ошибках и соответствующим образом фильтровать.

4. Вы даже можете загрузить сообщения журнала на устройство постфактум и просмотреть их в приложении macOS Console:

   $ log collect --device --start '2024-06-12 08:00:00' —output Foo.logarchive
   $ open Foo.logarchive
   

Поначалу это покажется обременительным (особенно если вы застряли на OSLog для поддержки старых ОС, а не на значительно улучшенной Logger iOS 14+), но преимущества неоспоримы, и как только вы начнете его использовать, вы не будете выглядеть назад. Обязательно рассмотрите «Единое журналирование».