Пять ловушек для начинающего свифтера

Всем привет! Я — начинающий свифтер, то есть изучаю Swift без опыта ObjC. Недавно мы с компаньонами начали проект, требующий приложение под iOS. А еще у нас есть idée fixe: с нами непременно должен работать студент из Физтеха, а приложение должно быть написано на языке Swift. И вот, пока мы ищем физтеховцев и знакомимся с ними, я решил не терять время и параллельно начать своими силами пилить проект на Swift. Так я впервые открыл XCode.

Вдруг обнаружилось много знакомых, которые точно так же не имея опыта мобильной разработки, стали осваивать ее именно посредством Swift, а не ObjC. Кто-то из них подтолкнул меня поделиться опытом на Хабре.

Итак, вот топ пять «ловушек», своевременное понимание которых точно бы сэкономило мне время.

1. Блоки (замыкания) могут порождать утечки памяти

Если вы, как и я, пришли в мобильную разработку минуя ObjC, то, наверное, одним из самых важных вводных материалов я бы назвал документацию Apple по Automatic Reference Counting. Дело в том, что при «скоростном» изучении нового языка путем погружения (то есть, начав сразу пилить реальный проект) у вас может развиться склонность пропускать «теорию», не имеющую отношения к задачам типа «показать всплывающее окно здесь и сейчас». Однако мануал по ARC содержит очень важный раздел, специально объясняющий неочевидное свойство замыканий, порождающее утечки.

Итак, пример «ловушки». Простой контроллер, который никогда не очистится из памяти:

class ViewController: UIViewController {
    var theString = "Hello World"
    var whatToDo: (()->Void)!
    override func viewDidLoad() {
        whatToDo = { println(self.theString) }
    }
    override func touchesBegan(touches: NSSet, withEvent event: UIEvent) {
        whatToDo()
        navigationController!.setViewControllers([], animated: true)
    }  
    deinit { println("removed from memory") }
}

Запускаем и тычем пальцем в экран. Если у нас мало опыта, то мы ошибочно ожидаем увидеть в консоли:

Hello World
removed from memory

Но на самом деле мы видим:

Hello World

То есть мы потеряли возможность обращаться к нашему контроллеру, а тот остался висеть в памяти.

Почему же? Оказывается, вызов self вот в этой невинной строчке

{ println(self.theString) }

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

Если внутри замыкания НЕ используется вызов self, то такого подвоха НЕ возникает.

В свифте, конечно, предусмотрено решение, которое Apple почему-то называет элегантным. Вот оно:

whatToDo = { [unowned self] in println(self.theString) }

Et voila! Вывод: будьте внимательны с жизненным циклом всех замыканий, содержащих вызов self.

2. Array, Dictionary и Struct по умолчанию немутабельные типы, никогда не передающиеся по ссылке

Когда стоит задача освоить новый язык очень быстро, я склонен забивать на чтение доков по таким интуитивно очевидным типам, как массивы и словари, полагаясь на то, что autocomplete научит меня всему, что надо, непосредственно в процессе кодинга. Такой торопливый подход все-таки подвел меня в ключевом месте, когда я всю дорогу воспринимал «массивы массивов» и «массивы страктов» как наборы ссылок (по аналогии с JS) — они оказался наборами копий.

После прочтения доков я все-таки прозрел: в Свифте массивы и словари являются страктами и поэтому, как любые стракты, передаются не по ссылке, а по значению (путем копирования, который компилятор оптимизирует под капотом).

Пример, иллюстрирующий мега-подвох, который вам приготовил Свифт:

struct Person : Printable {
    var name:String
    var age:Int
    var description:String { return name + " (\(age))" }
}
class ViewController: UIViewController {
    var teamLeader:Person!
    var programmers:[Person] = []
    func addJoeyTo(var persons:[Person]) {
        persons.append(Person(name: "Joey", age: 25))
    }
    override func viewDidLoad() {
        teamLeader = Person(name: "Peter", age: 30)
        programmers.append(teamLeader)
        
        // Строим ошибочные ожидания...
        teamLeader.name = "Peter the Leader"
        addJoeyTo(programmers)
     
        // ...и вот он, момент истины
        println(programmers)
    }
}

При запуске, если мы ошибочно мыслим в ключе «передача по ссылке», то ожидаем увидеть в консоли:

[Peter the Leader (30), Joey (25)] // Результат 1

Вместо этого видим:

[Peter (30)] // Результат 2

Будьте внимательны! Как же выйти из положения, если нам в действительности нужен именно первый результат? На самом деле, каждый конкретный случай требует индивидуального решения. В данном примере сработает вариант замены struct на class и замены [Person] на NSMutableArray.

3. Singleton Instance — выбираем наилучший «хак»

Ловушка заключается в том, что на текущий момент классы в Swift не могут иметь статических хранимых свойств, а только статические методы (class func) или статические вычисляемые свойства (class var x:Int {return 0}).



При этом сам Apple вообще не имеет предубеждений против глобальных инстансов в духе паттерна Singleton — в этом мы регулярно убеждаемся, используя такие перлы, как NSUserDefaults.standardUserDefaults(), NSFileManager.defaultManager(), NSNotificationCenter.defaultCenter(), UIApplication.sharedApplication(), ну и так далее. Мы действительно получим статические переменные в следующем общем обновлении — Swift 1.2.

Так как же нам создать собственные такие же инстансы в текущей версии Swift? Есть несколько возможных «хаков» под общим названием Nested Struct, но самый лаконичный из них — это следующий:

extension MyManager {
    class var instance: MyManager {
        func instantiate() -> MyManager {
            return ... // постройте свой инстанс здесь
        }
        struct Static {
            static let instance = instantiate() // lazily loaded + thread-safe!
        }
        return Static.instance
    }
}

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

Внимание! В следующей версии свифта (1.2) этот «хак» уже не понадобится, но дата общего релиза не известна. (Уже доступна бета-версия для тестирования, но для этого необходима также бета-версия XСode6.3, билд из которой от вас не примет Appstore. Короче — ждем глобального релиза.)

4. Методы didSet и willSet не будут вызваны в процессе выполнения конструктора

Вроде мелочь, но это способно ввести вас в тотальный ступор при отладке багов, если вы не знаете этого. Поэтому если вы запланировали какой-то набор манипуляций внутри didSet, который важен как при инициализации, так и далее в течение жизненного цикла объекта, делать это нужно таким образом:

class MyClass {
    var theProperty:OtherClass! {
        didSet {
            doLotsOfStuff()
        }
    }
    private func doLotsOfStuff () {
        // здесь реагируем на didSet theProperty
    }
    ...
    init(theProperty:OtherClass)
    {
        self.theProperty = theProperty
        doLotsOfStuff()
    }
}

5. Нельзя просто так взять и обновить UI, когда пришел ответ с сервера

Программисты с опытом ObjC могут посмеяться над этой «ловушкой», потому что она должна быть общеизвестна: методы, связанные с UI, безопасно дергать только из главного потока. Иначе — непредсказуемость и баги, толкающие в тотальный ступор. Но это наставление почему-то проходило мимо меня, пока я, наконец, не столкнулся с жуткими багами.

Пример «проблемного» кода:

func fetchFromServer() {
    let url = NSURL(string:urlString)!
    NSURLSession.sharedSession().dataTaskWithURL(url, completionHandler: { data, response, error in
        if (error != nil) {
            ...
        } else {
            self.onSuccess(data)
        }
    })!.resume()
}
func onSuccess(data) {
    updateUI()
}

Обратите внимание на блок completionHandler — все это будет исполняться вне главного потока! Тем, кто еще не столкнулся с последствиями, советую не экспериментировать, а просто не забыть обставить updateUI следующим образом:

func onSuccess(data) {
    dispatch_sync(dispatch_get_main_queue(), {
        updateUI()
    })
}

Это типичное решение. Одной строчкой мы возвращаем updateUI обратно в главный поток и избегаем неожиданностей.

На сегодня все. Всем новичкам успехов!

Опытные хабровчане из mobile — ваши замечания будут очень полезны мне и всем начинающим свифтерам.