Иван

Чистяков

В этой статье я хочу разобрать механизм Copy-on-Write (COW) в Swift — как он работает с типами-значениями, и что происходит в момент, когда мы присваиваем значение одной переменной другой. Такая ситуация часто встречается в разработке, поэтому важно понимать, как именно всё устроено «под капотом».

Простые типы данных

Для начала рассмотрим простые типы данных. Возьмём Int и посмотрим, что происходит при присваивании одной переменной другой:

var intValue1: Int = 5
var intValue2: Int = intValue1
 
let ptrA = UnsafeRawPointer(&intValue1)
let ptrB = UnsafeRawPointer(&intValue2)
 
print("Same address:", ptrA == ptrB) // → false

В этом примере, когда мы с помощью UnsafeRawPointer создаём указатели на переменные и сравниваем их, программа выводит false. Это означает, что переменные находятся по разным адресам в памяти. Значит, при присваивании система копирует значение в новое адресное пространство.

То же поведение наблюдается и у других простых типов данных — Bool, Float, Double и т. д.

Copy-on-Write для коллекций

В Swift существуют более сложные типы значений: Array, String, Dictionary, Set. Разработчики используют их каждый день, и важно понимать, как они работают. Рассмотрим тип Array (остальные работают аналогично).

Чтобы получить адрес первого элемента массива, используем функцию:

public func withUnsafeBufferPointer(_ body: (UnsafeBufferPointer) throws(E) -> R) throws(E) -> R where E : Error

Немного опишу как работает функция, чтобы понимать как можно взять адрес определенного элемента массива:

var array = [10, 20, 30]
 
array.withUnsafeBufferPointer { buffer in
    // адрес элемента массива с индексом 0
    let ptr0 = buffer.baseAddress
    // адрес элемента массива с индексом 1
    let ptr1 = buffer.baseAddress?.advanced(by: 1)
    // адрес элемента массива с индексом 2
    let ptr2 = buffer.baseAddress?.advanced(by: 2)
}

Теперь мы можем перейти к изучению того, как устроен механизм Copy-on-Write для коллекций. Создадим массив, присвоим его другой переменной, затем посмотрим адреса первых элементов:

var array1: Array = [10, 20, 30]
var array2: Array = array1
 
array1.withUnsafeBufferPointer { buffer in
    let ptr0 = buffer.baseAddress
    print(ptr0)
}
 
array2.withUnsafeBufferPointer { buffer in
    let ptr0 = buffer.baseAddress
    print(ptr0)
}

Вывод программы будет следующим:

Optional(0x0000600001726aa0)
Optional(0x0000600001726aa0)

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

Но когда же происходит копирование объекта в другое адресное пространство? Как понятно из названия, это происходит именно в тот момент, когда мы изменяем объект — удаляем, добавляем или заменяем элементы:

var array1: Array = [10, 20, 30]
var array2: Array = array1
// добавляем новый элемент
array2.append(40)
 
array1.withUnsafeBufferPointer { buffer in
    let ptr0 = buffer.baseAddress
    print(ptr0)
}
 
array2.withUnsafeBufferPointer { buffer in
    let ptr0 = buffer.baseAddress
    print(ptr0)
}

Вывод программы:

Optional(0x0000600001714aa0)
Optional(0x000060000210c700)

Мы изменили `array2`, добавив в него элемент `40`. В этот момент система зарезервировала новое место под массив, скопировала все элементы `array1` по новому адресу и добавила новый элемент. Поэтому мы видим два разных адреса памяти.

То же самое поведение будет наблюдаться и с другими коллекциями, такими как String, Set, Dictionary. Правда, для этих коллекций метод withUnsafeBufferPointer не подходит: `String` может храниться не в непрерывной области памяти, а Set и Dictionary скорее всего реализованы таким образом, что их элементы не располагаются последовательно в памяти. Однако механизм COW для них тоже работает.

Копирование при передаче в функцию

Интересный вопрос: что происходит, когда мы передаём массив в функцию? Происходит ли копирование, или внутри функции используется тот же объект?

func printArrayAdress(array: [Int]) {
    array.withUnsafeBufferPointer { buffer in
        let ptr0 = buffer.baseAddress
        print(ptr0)
    }
}
 
var array1: Array = [10, 20, 30]
 
array1.withUnsafeBufferPointer { buffer in
    let ptr0 = buffer.baseAddress
    print(ptr0)
}
 
printArrayAdress(array: array1)

Вывод программы:

Optional(0x000060000172d0e0)
Optional(0x000060000172d0e0)

Это значит, что внутри функции используется тот же адрес массива, что и снаружи. Копирования не происходит.

Пользовательские структуры

Теперь перейдём к важной части, ради которой и написана данная статья: что происходит с пользовательскими структурами?

Для всех пользовательских структур механизм Copy-on-Write, к сожалению, не работает. Следующий пример это наглядно демонстрирует.

Создадим структуру точки с двумя координатами:

struct Point {
    var x: Double
    var y: Double
}

Теперь создадим объект и присвоим его другой переменной:

var firstPointRef: Point = Point(x: 1, y: 1)
var secondPointRef = firstPointRef
 
withUnsafePointer(to: &firstPointRef) { pointer in
    print(pointer)
}
 
withUnsafePointer(to: &secondPointRef) { pointer in
    print(pointer)
}

Вывод:

0x00000001049fc3e0
0x00000001049fc3f0

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

Реализация COW вручную

Но что делать, если нам всё же нужен подобный механизм? Ответ прост: его можно реализовать с помощью классов, так как классы — ссылочный тип, и на один объект может ссылаться несколько переменных.

Создадим класс, в котором можно хранить любую пользовательскую структуру:

final class COWObject {
 
    var value: T
 
    init(_ value: T) {
        self.value = value
    }
 
}

Мы создаём шаблонный класс, в котором будет храниться пользовательская структура. Само свойство value открыто на запись и чтение — мы можем изменять его как угодно, и это именно то, что нам нужно.

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

Чтобы узнать, есть ли более одной ссылки на объект, мы будем использовать функцию:

@inlinable public func isKnownUniquelyReferenced(_ object: inout T) -> Bool where T : AnyObject

С этой функцией всё просто: она принимает объект класса и возвращает true, если на объект есть только одна сильная ссылка, и false — если ссылок больше одной. Таким образом, контейнер будет выглядеть следующим образом:

struct COWContainer {
 
    private var object: COWObject
 
    var value: T {
        get {
            object.value
        }
        set {
            if !isKnownUniquelyReferenced(&object) {
                object = COWObject(newValue)
            } else {
                object.value = newValue
            }
        }
    }
 
    init(_ value: T) {
        object = COWObject(value)
    }
 
    func printAdress() {
        print(Unmanaged.passUnretained(object).toOpaque())
    }
 
}

В структуре хранится объект COWObject. Это свойство скрыто извне, чтобы к нему не было прямого доступа, поэтому оно помечено как private. Снаружи доступ к пользовательскому типу T осуществляется через свойство value, которое открыто на чтение и запись. Как только объект изменяется, срабатывает блок set, в котором выполняется проверка: если на данный объект существует более одной ссылки, создаётся новый объект; если ссылка одна — значение заменяется у текущего объекта.

Для проверки добавим функцию, которая выводит адрес объекта object.

Теперь проверим, как будет работать наш механизм.

var firstPointRef: COWContainer = .init(Point(x: 1, y: 1))
var secondPointRef = firstPointRef
 
firstPointRef.printAdress()
secondPointRef.printAdress()

Программа выводит следующий результат:

0x0000600000218040
0x0000600000218040

Видно, что в данный момент существует один объект, который хранит в себе значение точки, поскольку этот объект является экземпляром класса. На объект COWObject, который хранит точку, ссылаются два объекта — firstPointRef и secondPointRef.

Давайте теперь попробуем изменить свойства у второго объекта и посмотрим, что будет происходить.

var firstPointRef: COWContainer = .init(Point(x: 1, y: 1))
var secondPointRef = firstPointRef
// Меняем свойства объекта
secondPointRef.value.x = 2
 
firstPointRef.printAdress()
secondPointRef.printAdress()

Вывод:

0x000060000020f1a0
0x0000600000228a20

Мы изменили второй объект secondPointRef, изменив координату x на значение 2. Сработал блок set, и поскольку на объект COWObject ссылаются два контейнера, произошло создание нового объекта COWObject. Таким образом, теперь существует два объекта COWObject и, соответственно, две разные точки.

В этой статье мы рассмотрели, как в Swift происходит копирование объектов и как можно реализовать механизм Copy-on-Write для пользовательских структур. Это особенно полезно, когда структуры занимают относительно большой объём памяти, и важно избегать лишнего копирования.

#swift #copyonwrite #cow #memory #ios #разработка

Разберем класс UIViewController. Любым экраном в IOS приложении буквально управляет объект UIViewController, этот объект занимается:

• Обновлением содержимого экрана
• Взаимодействием между пользователем и вью иерархией
• Расположением и лэйаутом интерфейса
• Координацией других объектов, может координировать и другие вью контроллеры

У вью контроллера есть свой жизненный цикл. Как и у любого другого объекта, создание происходит в методе init, а конкретнее

init(nibName: String?, bundle: Bundle?)

После того как объект создан, вью контроллер будет пытаться создать свой view. У каждого UIViewController есть это свойство:

var view: UIView!

Для этого контроллер вызывает метод:

func loadView()

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

override func loadView() {
    self.view = MyCustomView()
}

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

Когда view загружена в память вызывается метод:

func viewDidLoad()

Обычно этот метод переопределяется, чтобы добавить в иерархию свои объекты: лейблы, кнопки, другие вью и так далее. Сам метод вызывается всего один раз и больше не повторяется.

Важно понимать, что размеры view в этом методе не всегда могут быть известны. Например, если заменить стандартное view своим, то на этом этапе его размеры ещё не определены — они будут известны только если мы зададим их вручную заранее.

Перед тем как контроллер появится на экране, вызывается метод:

func viewWillAppear(_ animated: Bool)

В этот момент контроллер еще не появился на экране. Здесь можно выполнить подготовительные работы перед его отображением - например, запустить анимацию. Важно учитывать, что этот метод, как и последующие методы жизненного цикла, может вызываться многократно в течение существования контроллера.

После фактического появления контроллера на экране вызывается метод:

func viewDidAppear(_ animated: Bool)

Важно учитывать, что:

1. Метод viewWillAppear может быть вызван, но последующий вызов viewDidAppear не гарантирован
2. Ситуация возможна, когда процесс отображения прерывается системой

Относительно недавно Apple ввела дополнительный метод жизненного цикла. Теперь при непосредственном отображении контроллера вызывается метод:

func viewIsAppearing(_ animated: Bool)

Этот метод (viewIsAppearing) вызывается в промежутке между viewWillAppear и viewDidAppear. Раньше я часто запускал анимации в viewWillAppear, чтобы добиться более плавного начала. Однако, как я упоминал ранее, вызов viewWillAppear не гарантирует последующего вызова viewDidAppear и вообще факта появления экрана. Поэтому с появлением метода viewIsAppearing стало возможным безопасно запускать анимации именно в нём.

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

func viewWillDisappear(_ animated: Bool)

После исчезновения контроллера с экрана вызывается метод:

func viewDidDisappear(_ animated: Bool)

Важно понимать, что вызов viewWillDisappear не гарантирует последующего вызова viewDidDisappear и не означает, что контроллер будет окончательно скрыт. Это легко продемонстрировать на примере UINavigationController: когда пользователь начинает свайп для возврата, но отменяет его, система вызовет, но не вызовет viewDidDisappear, так как экран остаётся видимым.

Практические примеры:

1. Наблюдение за клавиатурой
Оптимальная стратегия:

• Начинать наблюдение в viewDidAppear
• Прекращать наблюдение в viewDidDisappear

1. Управление медиаконтентом
Для видео/аудио плеера:

• Запускать воспроизведение в viewDidAppear
• Останавливать в viewDidDisappear (для экономии ресурсов устройства)

Шаблон класса:

import UIKit
 
final class MyViewController: UIViewController {
 
    private let keyboardListener = KeyboardListener()
 
    private let myButton = UIButton()
    private let videoView = VideoView()
 
    //MARK: Init
    init() {
        super.init(nibName: nil, bundle: nil)
        /// здесь объект уже создан
    }
 
    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }
 
    //MARK: Lifecycle
    override func viewDidLoad() {
        super.viewDidLoad()
        // здесь добавляем свои объекты, например
        view.addSubview(myButton)
        let buttonSize: CGFloat = 100
        myButton.frame = CGRect(x: 0, y: 0, width: buttonSize, height: buttonSize)
    }
 
    override func viewDidLayoutSubviews() {
        /// Здесь известны размеры view и его subview, допустим надо сделать кнопку круглой
        myButton.layer.cornerRadius = myButton.bounds.width / 2
    }
 
    override func viewWillAppear(_ animated: Bool) {
        super.viewWillAppear(animated)
        // вызывается перед появлением контроллера на экране
    }
 
    override func viewIsAppearing(_ animated: Bool) {
        super.viewIsAppearing(animated)
        // вызывается в момент когда контроллер показывается
    }
 
    override func viewDidAppear(_ animated: Bool) {
        super.viewDidAppear(animated)
        // вызывается после появления контроллера на экране
        // начинаем следить за клавиатурой
        keyboardListener.beginListening()
        videoView.startVideo()
    }
 
    override func viewWillDisappear(_ animated: Bool) {
        super.viewWillDisappear(animated)
        // вызывается перед исчезновением контроллера с экрана
    }
 
    override func viewDidDisappear(_ animated: Bool) {
        super.viewDidDisappear(animated)
        // вызывается после исчезновения контроллера с экрана
        // заканчиваем слежение за клавиатурой
        keyboardListener.endListening()
        videoView.stopVideo()
    }
 
}

После удаления с экрана контроллер может выгрузиться из памяти — тогда вызовется deinit у контроллера, объект будет удалён, а память освобождена. Но это происходит не всегда: иногда экран, будучи скрытым, вновь может появляться, и тогда снова будет вызван метод viewWillAppear, а затем viewDidAppear.

Такой процесс может происходить, когда один UIViewController отображает другой. Чтобы это представить, можно вообразить стопку контроллеров: пользователь открывает один экран, нажимает на кнопку — и у него снова открывается новый экран. Теперь в стопке два вью-контроллера.

Например, пользователь находится в мессенджере на экране списка чатов и открывает отдельный чат — появляется новый экран.

В этот момент у нижнего контроллера вызываются методы viewWillDisappear → , а у верхнего — viewWillAppear → viewDidAppear. Когда верхний контроллер исчезает с экрана (например, пользователь его закрывает), у нижнего снова вызываются viewWillAppear → viewDidAppear.

#swift #uiviewcontroller #разработка #ios #iosразработка #uikit

При разработке iOS-приложений важно понимать, какие состояния проходит приложение в процессе работы и как оно взаимодействует с системой. Рассмотрим основные этапы жизненного цикла приложения.

Точка входа в приложение

Многие считают, что выполнение iOS-приложения начинается с объекта AppDelegate.

Однако это не совсем так. Настоящая точка входа — файл main.swift. В Swift его роль сведена к минимуму, так как точка входа определяется с помощью атрибута @main, который помечает точку входа в приложение. Например, такой атрибут есть над классом AppDelegate.

UIApplication – центральный объект приложения

UIApplication играет ключевую роль в управлении приложением:

• Представляет собой само приложение.
• Обеспечивает взаимодействие с системой.
• Открывает ссылки в браузере.
• Запускает фоновые задачи.
• Обрабатывает нажатия и жесты пользователя.

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

С iOS 13 появился UISceneDelegate, который отвечает за обработку жизненного цикла сцен (окон) в многосценовых приложениях. В iOS 12 и более ранних версиях управление происходило исключительно через UIApplicationDelegate.

Рассмотрим в каких состояниях может быть IOS приложение

1. Unattached (не запущено)

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

2. Inactive (запуск и подготовка)

После нажатия на иконку приложения система:

• Отображает Launch Screen.
• Создаёт объект UIApplication.
• Загружает основные компоненты.

В этот момент приложение ещё не готово к взаимодействию с пользователем.

3. Active (активное)

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

4. Inactive (неактивное)

Приложение из активного состояния может перейти в состояние когда оно будет неактивно, такое состояние называется inactive, в таком состоянии оно по прежнему отображается на экране и может выполнять какие то процессы, однако у пользователя нет возможности взаимодействия с ним. Например это может произойти в следующих случаях:

• Отображение системного алерта.
• Открытие «Пункта управления».

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

На протяжении одной сессии приложение может многократно переходить между Active и Inactive.

5. Background (фоновый режим)

При сворачивании приложения оно продолжает выполнение процессов в фоне. Например:

• Проигрывание музыки.
• Завершение загрузки файлов.

Через некоторое время система может приостановить выполнение процессов приложения, чтобы не тратить ресурсы устройства.

6. Suspended (приостановленное)

Приложение остаётся в памяти устройства, но его процессы не выполняются. Если системе понадобится память, она может выгрузить приложение, переведя его обратно в Unattached. Тем не менее, приложение может вернуться из этого состояния к Inactive, а потом и к Active состоянию.

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

#swift #ios #программирование #UIKit

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

• Первый том - «Азы программирования»

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

• Второй том - «Системы и сети»

В данной книге идёт обучению языку программирования Си, рассказывается о базовых средства языка Си. Ещё в книге есть очень интересная часть про устройство операционной системы из семейства UNIX систем.

• Третий том - «Парадигмы»

По названию становится понятно, что язык программирования, который будет объясняться в этой книге - это C++. Ну и естественно вы поймёте о главных парадигмах ООП.

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

Многие могут сказать, ну вот язык Паскаль устарел, зачем его нужно изучать. Да устарел, но зато вы сможете легко понять как устроены указатели, и для вас уже второй том будет казаться не таким сложным!

к изучение Си нужно подходить, уже понимая указатели и умея с ними обращаться

Ведь в языке Си все построено на указателях, у многих это основной барьер в изучении этого языка!

А теперь обещанный лайфках

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

Чтобы настроить:
Настройки - TenChat - свайп в любую сторону для ответа (Последняя фотка - скрин)

Фишки для удобной работы в TenChat

Не так давно была добавлена функция поделиться материалом из других приложений. На данный момент можно поделиться фотографией, документом или ссылкой. Расскажу как это можно сделать на системе iOS.

Рассмотрим этот механизм на примере фотографии, например можно зайти в приложение фотографии на IPhone, нажать на значок поделиться, откроется список приложений, в которые вы можете отправить фотографию. Но у многих иконки приложения TenChat не будет, потому что его надо добавить в избранное. Так вот в конце списка приложений есть значок «еще», если на него нажать, то можно там найти TenChat!

Добавляйте TenChat в избранное и всегда сможете быстро и легко делиться материалами из других приложений в TenChat! Все что для этого нужно - это только выбрать из списка чатов или контактов кому отправить

P.S не забудьте обновиться до новой версии

Стало известно о секретном 5-летнем договоре Apple с Китаем на $275 млрд.

Apple обязалась инвестировать в экономику и технологическое развитие Китая в обмен на свободное ведение бизнеса в стране.

Договор был заключён в 2016 году, но может быть продлён до мая 2022 года.

Android-разработчик Джеймсон Уильямс решил проверить, как MacBook Pro (2021) с системой-на-чипе Apple M1 Max позволяет экономить время разработчиков и деньги компаний.

Уильямс считает, что в среднем Android-разработчики тратят 45 минут ежедневно на сборку проектов. Новый MacBook Pro справляется с одним проектом в два раза быстрее модели на Intel 2019 года выпуска — 5,45 минуты против 11,65 минуты соответственно. То есть каждый день можно экономить 22 минуты.

Стоимость базовой версии на M1 Max с учётом доставки и налогов в США — 3500 долларов. На команду из девяти человек потребуется потратить 31 500 долларов.

Средняя стоимость часа работы программиста — 150 долларов, и это с учётом других затрат компании. Получается, экономя на сборке 22 минуты ежедневно, компания потратит на каждого сотрудника на 55 долларов меньше, или на 495 долларов меньше на команду. То есть приобретение новых MacBook Pro окупится через три-четыре месяца, а после начнёт работать на прибыль.