Dodo engineering

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

Напишите где-нибудь в UI потоке (например в методе onStart) такой код:

//где-то в UI потокеrunBlocking(Dispatchers.Main) {  println(Hello, World!)}

Вы получите дедлок приложение зависнет. Это не ошибка, а на 100% ожидаемое поведение. Тезис может показаться неочевидным и неявным, поэтому давайте погрузимся поглубже и я расскажу, что здесь происходит.

Сравним код выше с более низкоуровневым подходом с потоками. Вы можете написать в главном потоке вот так:

//где-то в UI потокеHandler().post {println("Hello, World!") // отработает в UI потоке}

Или даже так:

//где-то в UI потокеrunOnUiThread {  println("Hello, World!") // и это тоже отработает в UI потоке}

Вроде конструкция очень похожа на наш проблемный код, но здесь обе части кода работают (по-разному под капотом, но работают). Чем они отличаются от кода с runBlocking?

Как работает runBlocking

Для начала небольшой дисклеймер. runBlocking редко используется в продакшн коде Android-приложения. Обычно он предназначен для использования в синхронном коде, вроде функций main или unit-тестах.

Несмотря на это, мы всё-таки рассмотрим этот билдер при вызове в главном потоке Android-приложения потому, что:

• Это наглядно. Ниже мы придем к тому, что это актуально и не только для UI-потока Android-приложения. Но для наглядности лучше всего подходит пример на UI-потоке.

• Интересно разобраться, почему всё именно так работает.

• Всё-таки иногда мы можем использовать runBlocking, пусть даже в тестовых приложениях.

Билдер runBlocking работает почти так же, как и launch: создает корутину и вызывает в ней блок кода. Но чтобы сделать вызов блокирующим runBlocking создает особую корутину под названием BlockingCoroutine, у которой есть дополнительная функция joinBlocking(). runBlocking вызывает joinBlocking() сразу же после запуска корутины.

Фрагмент из runBlocking():

// runBlocking() function// val coroutine = BlockingCoroutine<T>(newContext, )coroutine.start(CoroutineStart.DEFAULT, coroutine, block)return coroutine.joinBlocking()

Функция joinBlocking() использует механизм блокировки Java LockSupport для блокировки текущего потока с помощью функции park(). LockSupport это низкоуровневый и высокопроизводительный инструмент, обычно используется для написания собственных блокировок.

Кроме того, BlockingCoroutine переопределяет функцию afterCompletion(), которая вызывается после завершения работы корутины.

override fun afterCompletion(state: Any?) {//wake up blocked threadif (Thread.currentThread ()! = blockedThread)LockSupport.unpark (blockedThread)}

Эта функция просто разблокирует поток, если она была заблокирована до этого с помощью park().

Как это всё работает примерно показано на схеме работы runBlocking.

Что здесь делает Dispatchers

Хорошо, мы поняли, что делает билдер runBlocking. Но почему в одном случае он блокирует UI-поток, а в другом нет? Почему Dispatchers.Main приводит к дедлоку...

// Этот код создает дедлокrunBlocking(Dispatchers.Main) {  println(Hello, World!)}

...,а Dispatchers.Default нет?

// А этот код создает дедлокrunBlocking(Dispatchers.Default) {  println(Hello, World!)}

Для этого вспомним, что такое диспатчер и зачем он нужен.

Диспатчер определяет, какой поток или потоки использует корутина для своего выполнения. Это некий высокоуровневый аналог Java Executor. Мы даже можем создать диспатчер из Executorа с помощью удобного экстеншна:

public fun Executor.asCoroutineDispatcher(): CoroutineDispatcher

Dispatchers.Default реализует класс DefaultScheduler и делегирует обработку исполняемого блока кода объекту coroutineScheduler. Его функция dispatch() выглядит так:

override fun dispatch (context: CoroutineContext, block: Runnable) =  try {    coroutineScheduler.dispatch (block)  } catch (e: RejectedExecutionException) {    //    DefaultExecutor.dispatch(context, block)  }

Класс CoroutineScheduler отвечает за наиболее эффективное распределение обработанных корутин по потокам. Он реализует интерфейс Executor.

override fun execute(command: Runnable) = dispatch(command)

А что же делает функция CoroutineScheduler.dispatch()?

• Добавляет исполняемый блок в очередь задач. При этом существует две очереди: локальная и глобальная. Это часть механизма приоритезации внешних задач.

• Создает воркеры. Воркер это класс, унаследованный от обычного Java Thread (в данном случае daemon thread). Здесь создаются рабочие потоки. У воркера также есть локальная и глобальная очереди, из которых он выбирает задачи и выполняет их.

• Запускает воркеры.

Теперь соединим всё, что разобрали выше про Dispatchers.Default, и напишем, что происходит в целом.

• runBlocking запускает корутину, которая вызывает CoroutineScheduler.dispatch().

• dispatch() запускает воркеры (под капотом Java потоки).

• BlockingCoroutine блокирует текущий поток с помощью функции LockSupport.park().

• Исполняемый блок кода выполняется.

• Вызывается функция afterCompletion(), которая разблокирует текущий поток с помощью LockSupport.unpark().

Эта последовательность действий выглядит примерно так.

Перейдём к Dispatchers.Main

Это диспатчер, который создан специально для Android. Например, при использовании Dispatchers.Main фреймворк бросит исключение, если вы не добавляете зависимость:

implementation 'org.jetbrains.kotlinx:kotlinx-coroutines-android:..*'

Перед началом разбора Dispatchers.Main стоит поговорить о HandlerContext. Это специальный класс, который добавлен в пакет coroutines для Android. Это диспатчер, который выполняет задачи с помощью Android Handler всё просто.

Dispatchers.Main создаёт HandlerContext с помощью AndroidDispatcherFactory через функцию createDispatcher().

override fun createDispatcher() =  HandlerContext(Looper.getMainLooper().asHandler(async = true))

И что мы тут видим? Looper.getMainLooper().asHandler() означает, что он принимает Handler главного потока Android. Получается, что Dispatchers.Main это просто HandlerContext с Handlerом главного потока Android.

Теперь посмотрим на функцию dispatch() у HandlerContext:

override fun dispatch(context: CoroutineContext, block: Runnable) {  handler.post(block)}

Он просто постит исполняемый код через Handler. В нашем случае Handler главного потока.

Итого, что же происходит?

• runBlocking запускает корутину, которая вызывает CoroutineScheduler.dispatch().

• dispatch() отправляет исполняемый блок кода через Handler главного потока.

• BlockingCoroutine блокирует текущий поток с помощью функции LockSupport.park().

• Main Looper никогда не получает сообщение с исполняемым блоком кода, потому что главный поток заблокирован.

• Из-за этого afterCompletion() никогда не вызывается.

• И из-за этого текущий поток не будет разблокирован (через unparked) в функции afterCompletion().

Эта последовательность действий выглядит примерно так.

Вот почему runBlocking с Dispatchers.Main блокирует UI-поток навсегда.

Главный потокблокируется и ждёт завершения исполняемого кода. Но он никогда не завершается, потому что Main Looper не может получить сообщение на запуск исполняемого кода. Дедлок.

Совсем простое объяснение

Помните пример с Handler().post в самом начале статьи? Там код работает и ничего не блокируется. Однако мы можем легко изменить его, чтобы он был в значительной степени похож на наш код с Dispatcher.Main, и стал ещё нагляднее. Для этого можем добавить операции parking и unparking к текущему потоку, иммитируя работу функций afterCompletion() и joinBlocking(). Код начинает работать почти так же, как с билдером runBlocking.

//где-то в UI потокеval thread = Thread.currentThread()Handler().post {  println("Hello, World!") // это никогда не будет вызвано  // имитируем afterCompletion()  LockSupport.unpark(thread)}// имитируем joinBlocking()LockSupport.park()

Но этот трюк не будет работать с функцией runOnUiThread.

//где-то в UI потокеval thread = Thread.currentThread()runOnUiThread {  println("Hello, World!") // этот код вызовется  LockSupport.unpark(thread)}LockSupport.park()

Это происходит потому, что runOnUiThread использует оптимизацию, проверяя текущий поток. Если текущий поток главный, то он сразу же выполнит блок кода. В противном случае сделает post в Handler главного потока.

Если всё же очень хочется использовать runBlocking в UI-потоке, то у Dispatchers.Main есть оптимизация Dispatchers.Main.immediate. Там аналогичная логика как у runOnUiThread. Поэтому этот блок кода будет работать и в UI-потоке:

//где-то в UI потокеrunBlocking(Dispatchers.Main.immediate) {   println(Hello, World!)}

Выводы

В статье я описал как безобидный билдер runBlocking может заморозить ваше приложение на Android. Это произойдет, если вызвать runBlocking в UI-потоке с диспатчером Dispatchers.Main. Приложение заблокируется по следующему алгоритму:

• runBlocking создаёт блокирующую корутину BlockingCoroutine.

• Dispatchers.Main отправляет на запуск исполняемый блок кода через Handler.post.

• Но BlockingCoroutine тут же заблокирует UI поток.

• Поэтому Main Looper никогда не получит сообщение с исполняемым блоком кода.

• А UI не разблокируется, потому что корутина ждёт завершения исполняемого кода.

Эта статья больше теоретическая, чем практическая. Просто потому, что runBlocking редко встречается в продакшн-коде. Но примеры с UI-потоком наглядны, потому что можно сразу заблокировать приложение и разобраться, как работает runBlocking.

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

val singleThreadDispatcher = newSingleThreadContext("Single Thread")GlobalScope.launch (singleThreadDispatcher) {  runBlocking (singleThreadDispatcher) {    println("Hello, World!") // этот кусок кода опять не выполнится  }}

Если очень надо написать runBlocking в главном потоке Android-приложения, то не используйте Dispatchers.Main. Используйте Dispatchers.Default или Dispatchers.Main.immediate в крайнем случае.

Также будет интересно почитать:

Оригинал статьи на английском How runBlocking May Surprise You.
Как страдали iOS-ники когда выпиливали Realm.
О том, над чем в целом мы тут работаем: монолит, монолит, опять монолит.
Кратко об истории Open Source просто развлечься (да и статья хорошая).

Подписывайтесь начат Dodo Engineering, если хотите обсудить эту и другие наши статьи и подходы, а также на канал Dodo Engineering, где мы постим всё, что с нами интересного происходит.

Если бы сбылись предсказания футурологов и фантастов космической эры, вроде Кларка или Азимова, мы бы жили в совсем другом мире. Базы на Луне и колонии на Марсе, к которым мы летим на ракетах с фотонными двигателями, антропоморфные роботы-помощники, подземные города, освоенная Арктика и вечная весна вот будущее, что мы потеряли. Но потеряли ли? Могло ли вообще сбыться это будущее?

Космической эрой 20-го века я называю 50-е и 60-е время, когда человек стремился в космос и надеялся на научно-технический прогресс. Это время великих предсказаний: мир работает во благо людей, новые технологии направлены на то, чтобы упростить нашу жизнь, мы освоили космос, а люди стали добрее и наступило всеобщее благоденствие. Отсылки на эту эпоху постоянно появляются в поп-культуре, например, в Футураме, а ракета Starship Илона маска выглядит будто срисованная с фантастических фильмов 50-х.

Но этим предсказаниям не суждено было сбыться. Дело в том, что предсказаний в это время и не было. Были фантазии о будущем мечты об усовершенствованном настоящем. Попробую это доказать.

Примечание. Включите судля атмосферы и поехали.

Наивное будущее начала 20-го века

В начале 20-го века газета The New York Times опубликовала предсказание журналиста, оккультиста и кавалера ордена Почётного Легиона Анри Антуана Жюль-Буа. В 2009 году Анри видел, что на летающих велосипедах (мускулолётах) и летающих автомобилях люди добираются с работы в пригороды, потому что в городах больше никто не живет, а только работает.

А в 1900 году в журнале Ladies' Home Journal Джон Элфрет Уоткинс-младший рассказал, что в 21 веке комаров и мух больше не останется: все страны осушат болота, застойные бассейны и химически обработают все водоемы.

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

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

Что объединяет все эти предсказания? В них нет ничего, что не знали бы люди того времени:

• Есть железные дороги.

• В 1899 году началось производство первых дирижаблей-Цеппелинов для полётов.

• Прототипы самолётов вовсю тестируют. Например, 6 мая 1896 на Аэродроме Лэнгли номер 5 впервые успешно испытан аппарат тяжелее воздуха с двигателем. А в 1900 братья Райт начинают свои эксперименты с планерами.

• Подводная лодка известна еще с 18 века, когда в 1776 году французский изобретатель Бушнелл сделал подводную лодку Черепаха. Она даже поучаствовала в боевых действиях в войне за независимость США.

Предсказатели просто взяли всё, о чем знали, перемешали и додумали. Получилось усовершенствованное настоящее. Это заметно хотя бы потому, что на картинах мода за век не поменялась.

Индустриализация и гигантизм

Начало 20-го века время индустриализации, которая сменила традиционное аграрное общество. Новое ядро общества промышленность, которая влияла на экономику, культуру и политику. Жизнь обывателя 19 и 20 веков отличается кардинально.

Развитие науки. К 20-му веку создано радио, освоена горячая сварка, есть двигатель внутреннего сгорания, токарные станки. Открыто электричество, пастеризация, периодическая система элементов, найдены возбудители туберкулеза, холеры, дифтерита, тифа, разработаны лекарства и прививки от них.

Урбанизация. Множество людей переехали из сельской местности в города, где ритм жизни и плотность человека на метр совершенно иные. Житель деревни не видел столько лиц за всю жизнь, сколько в городе за день. Странные самоходные повозки без лошадей ездят по дорогам: по твёрдому покрытию, а не по земле.

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

Специализация. Например, заводы в Англии производили детали для станков в США, а Германия заняла рынок красителей. Здесь неизбежно возникновение жёсткой специализации и разделения труда уже в мировом масштабе. Целые страны становились цехами в мировом разделении производства.

Мечты о будущем усиление настоящего.

Мечты индустриального времени гигантские. Например, о небоскрёбах на сотни этажей и широких шоссе между улицами. Так изобразил будущее Нью-Йорка в 1910 году художник Ричард Раммел.

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

Обратите внимание на странную конструкцию из колеса и башни. Это танк, а рядом с ним дома. Так представляли себе войну. Это неудивительно прототипы танков уже существовали, а уже в 1915 году их начали серийно производить британцы. Модель называлась Mk I и их выпустили 48 штук. Правда, в первом же сражении в Первой Мировой 32 из них не доехали до цели. Странно, ведь их производил не Land Rover.

На примере танков хорошо прослеживается гигантомания времени после Mk I машины всё росли и росли. Но подвижность и функциональность ухудшалась, пока Луи Рено не додумался отказаться от тяжелого корпуса и сделать упор на подвижности. Так появился серийный танк Рено FT-17 лёгкий, манёвренный и быстрый.

Космическая эра

50-е и 60-е золотая эра футуризма. Резкий рост популярности научной фантастики при содействии Азимова, Бредбери или Стругацких, подстегнул изучение научно-технического прогресса. Именно поэтому большинство предсказаний связаны с освоением космоса и колонизацией других планет. Притом они появились до того, как вообще первый человек попала в космос. Люди начали мечтать масштабно о:

• термоядерных реакторах;

• подводной агрономии на шельфах северных морей;

• переводе всего транспорта на аккумуляторы;

• генетической модификации живых организмов;

• полётах в космос и на другие планеты.

Человек 50-х и 60-х чувствует, что живет будущим.

Космическая тема проникает в культуру. Дизайнеры по-новому взглянули на цвет и форму: в одежде и интерьерах преобладают яркие зелёные, золотые и красные цвета. Стал активно использоваться акриловый и цветной пластик для производства посуды, предметов интерьера и мебели. Появилась даже мебель из металла и стекла. Квартира обычного бухгалтера стала выглядеть как космический корабль с кислотными коврами и виниловыми обоями. Бытовая техника эволюционирует: появились кофеварки, тостеры, а телевизоры растут в размерах и качестве картинки.

Пластик стал настолько популярен, что футурологи предсказывали, как люди будут есть из пластиковой посуды, сидеть на пластиковых диванах и жить в пластиковых домах. В 1957 году химический концерн Monsanto даже открыл Дом будущего Monsanto (в Диснейленде) дом полностью из пластика: стены, облицовка, мебель, посуда.

Мечты о космосе отражаются на автомобилях. Не только концепты, но и серийные автомобили становятся похожи на космические корабли.

Футуризм 50-х и 60-х в США хорошо описывает серия работ Артура Радебо (с 1958 по 1962 год). Футуристичные автомобили, которые перекрашиваются электромагнитной пушкой, почтальоны с реактивными ранцами, модифицированные растения на автоматизированных сельхозугодьях узнаваемый стиль времени, яркие цвета, улыбающиеся люди. Но на картинках мы сразу видим прокачанные 50-е и 60-е.

Дух времени покорение: космоса, Арктики, морей, природы.

Что советские, что американские фантасты они мечтали практически об одном и том же. Например, в диафильме В 2017 году в СССР построили плотину через Берингов пролив, пустили Енисей и Обь в Каспийское море, создали подлёдные города. Тепло собирают из глубин Земли, а каналы строят атомными взрывами.

Особая сокровищница несбывшихся предсказаний журнал Техника молодежи. Представления советских футурологов это совершенно иной мир со своим колоритом. Подземные города, лифты ко дну моря, импульсные пушки, невидимое магнитное поле, выводящее из строя танки, и самолёты с атомным двигателем.

Полярный шар для жизни в Арктике, аэросани, гибрид корабля и подводной лодки для передвижения и электролёт аппарат, летающий за счет электромагнитных волн.

Люди мечтали масштабно.

На Западе прогнозисты предсказывали, что через несколько десятков лет мы построим базы на Луне и посетим Марс. Мы сможем посещать другие планеты, как туристы, например, с помощью космического лайнера на 50 000 тонн, вместимостью 10 000 пассажиров, что предсказывал инженер Дэндридж М.Коул. А математик и учёный Д. Г. Бреннан описывал, что к 2018 году мы откроем антигравитацию и сможем летать.

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

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

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

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

Предсказания это экстраполяция достижений науки и техники своего времени.

Люди мечтали об усовершенствованном настоящем: больше космических достижений, больше компьютеров, больше науки. Невозможно представить жизнь без автомобиля? Вот вам супершоссе от Дисней: направления обозначены цветами, дорога нагревается и испаряет воду (после дождя или снега), а в пустынях охлаждается.

Экстраполяция хорошо заметна на примере Айзека Азимова. В 1964 году писатель опубликовал эссе в The New York Times, где описал 2014 год. Колонизация полюсов, подводные гостиницы, подземные дома, автоматизированные бытовые приборы, много компьютеров, 3D-фильмы, автономная техника на батареях и парящие над землей машины. Половина электроэнергии будет вырабатываться на АЭС, а в космосе солнечные батареи будут передавать энергию Солнца на Землю.

Может Азимов взял это всё из головы и предсказал, например, IoT или умные колонки? Нет, это всё он увидел на Всемирной выставке в Нью-Йорке в 1964 году. Все эти чудеса именно там и демонстрировались: футуристичные автомобили, поля с культурами с автоматическим орошением, порт в шельфе Арктики, подводные дома. Азимов даже не стал ничего придумывать просто описал, что увидел.

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

Почему будущее так и не случилось?

Потому что люди представляли не будущее, а усовершенствованное настоящее.

• Вокруг фабрики и заводы на которы ломят спины люди? Хотим автоматическое производство или роботов.

• Вокруг космическая гонка? Хотим летать на Марс на работу, а отдыхать на даче на Луне, самолеты с атомным двигателем и покорение арктики.

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

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

• В фильме Назад в будущее мы видим аналог видеозвонков в скайп или зум. Но этот же аналог мы видим в работах начала 20-го века у французов.

• Первый мобильны телефон создала Моторола в году. Но это устройство они увидели в сериале Стартрек.

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

• В Пятом элементе та же полиция, но в странной броне, машины, но летают, и генетические эксперименты, правда на недосягаемом уровне.

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

В предсказаниях прошлого о будущем нет будущего только аллюзия настоящего.

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

Авторы прогнозов чаще всего рассматривали только технологии. Но их можно оправдать наука развивается волнообразно, и тяжело преодолеть шок будущего, предсказав радикальные изменения.

Например, человек заснул в 1720, а проснулся в 1820ж В целом, он бы не заметил большую разницу: Люди также живут в деревнях, работают в полях, пашут животной силой, особо не следят за временем: ещё светло работай. В обществе всё ещё жесткое разделение между крестьянами и аристократами (элитой), которая живет в городах, а из транспорта гужевые повозки, связь между городами медленная.

А вот если бы этот же человек проснулся бы в 1920, то всё было бы иначе: огромные города, застроенные гигантскими высотками, люди массово работают не в полях, а в огромных зданиях с трубами, из которых извергаются клубы дыма. Город кипит, шумит и вообще страшно, потому что по улицам ездят странные железные повозки без лошадей. По небу в это время летят большие железные птицы, а кто-то передает свои слова по воздуху (радио).

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

Примечание автора. Рассказав о том, что предсказания прошлого лишь фантазии, я не ставил целью кого-то принизить. Я сам был бы рад, если бы предсказания о великих достижениях сбылись. Больше всего мне грустно, что не наступило будущее космической эры 50-х и 60-х. У меня в руках коробочка, которая в 1000 раз мощнее компьютеров, что запустили людей на Луну. И что я с ней делаю? Запускаю эмодзи с ракетами в чатиках. Поэтому мне грустно, когда ночью я смотрю на звёзды. У нас есть всё технологии, чтобы создать будущее, как его представляли в космическую эру и создать эпоху больших достижений. У нас есть всё, но нет желания. Почему? Я не знаю.

Заходите к нам Телеграм-чат, чтобы покритиковать статью и автора. Подписывайтесь на канал Dodo Engineering: там мы постим анонсы статей, подкасты и делимся тем, что нам интересно.

Когда на собеседованиях я спрашиваю у кандидата с какими базами он работал и что делал, то чаще всего слышу про Realm. Типичный ответ: он быстрее и с ним проще работать, создал конфиг, описал модель, готово. Но за все удобства Realm придётся расплачиваться: он вроде бы решает одну проблему, но тут же добавляет пару своих. А последствия, недостатки и проблемы обычно обсудить не получается: нужен опыт использования в пару лет, а его обычно нет.

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

Примечание. Realm читается как рэлм или рилм, но давайте только не реалм

Зачем нужна база данных для заказа пиццы?

Кратко незачем. База данных сначала прикрывала плохое API.

В 2017 году Dodo Pizza решила написать свое приложение. Серверная часть уже работала 6 лет и обслуживала 250+ пиццерий (на начало 2021 почти 700). Много работы было сделано для бизнеса, а для клиентов был только сайт нужно делать приложение.

Чтобы подключить приложение нужно новое API и срочно, ребята торопились. Чтобы ускориться, часть работы разделили: API было больше похоже на прокси для базы данных, а часть логики решало приложение.

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

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

Realm vs Core Data

Сложно вспомнить почему выбрали Realm, а не Core Data. Скорее всего, так было проще: схему базы рисовать не нужно, объекты создаются сразу в коде, работает быстрее, да и опыт работы с ней был. Так и поехало.

Как работало

Первую версию приложения сделала команда на аутсорсе. Уже тогда понимали, что проект будет жить долго, стран будет много, фич навалом. Тогда казалось важным заложить поддержку работы в офлайне. Если нет, то, хотя бы, настроить восстановление между сессиями работы приложения, чтобы меню появлялось сразу на запуске, без скачивания. Архитектурно это заложили с первой строки.

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

• получили данные из сети;

• положили в базу, разметили связи между таблицами;

• прочитали из базы, связанные объекты подтянулись сами;

• переложили данные во view-модели, а дальше уже MVVM.

Realm требователен к переключению потоков, поэтому вся работа с базой архитектурно заворачивалась в один фоновый поток. Это было правильное и удачное решение (без шуток), но к нему мы ещё вернемся.

Недостатки Realm

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

Realm накладывает ряд ограничений сам по себе.

Хранит только сырые данные. Enum надо перекладывать в String или Int, Optional в RealmOptional, массивы в List, обратные ссылки в LinkedList. Чтобы превращать это в нормальные объекты надо писать какие-то конвертеры. В итоге кода становится сильно больше, модели дублируются, проект становится хрупче.

По всему коду размазано обращение к Realm: он импортируется в файл, передается в качестве параметра, из базы тянутся объекты. Мы активно заворачивали всё в репозитории, чтобы скрыть работу с базой, а интерфейсом выходил доменный объект. Но это дополнительный код и слой в архитектуру.

Работа с базой превратилась в целый слой, который надо поддерживать: писать маперы, обертки. Добавить новую сущность это слишком много ручной работы: создать Entity, переложить из DTO в нее, потом из Entity в доменную модель. Это всё ещё и протестировать надо, а мы даже на UI выводить ничего не начали.

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

Realm большая и очень тяжелая зависимость. Наш проект весил 55 Мб, Realm занимал 7 и очень долго билдился. Мы решили проблему пребилдом перенесли билд на этап pod install, стало реже и легче. Но плагин компиляции стал влиять и на другие поды, например, он не работал с XCFramework и мы не могли обновить поды, которые перешли на него. Убрать пребилд мы уже не могли, потому что привыкли к нормальной скорости сборки.

Ну и Realm мог бы и складывать свои файлы в одну папку!

Проблемы в проекте из-за недостатков

Это не критика Realm, а взгляд на то, к чему может привести недальновидность в начале разработки.

Realm стал целым слоем обработки данных, все операции проходили через него. При этом, вся архитектура с бекапом в Realm не работает, если на девайсе мало места. Из-за размера фреймворка не получится переиспользовать код и написать, например, аппклипс: из 10 доступных мегабайт он займет все 10.

Страдает производительность. Обратные связи могут порождать очень большие и сложные деревья, сохранение и запись могут растягиваться. Мы столкнулись с этим в меню, когда появились изменяемые комбо. В комбо были слоты, каждый мог содержать десятки ссылок на продукты. При получении меню запись и чтение из базы занимало 2/3 времени: сетевой запрос проходил за полсекунды, а ещё одну мы просто разбирались с базой в приложении.

Офлайн-режим нашему приложению совсем не нужен, а персистентость нужна лишь частичная. Нет смысла хранить всю корзину, если можно обновить её с сервера по ID. Даже если захотим хранить её, то это проще сделать другим способом: на уровне кеша сети, ручным кешем оригинального JSON или конвертацией доменной модели в файл через Codable.

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

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

Сложно писать тесты. Непонятны зависимости, часто есть только одна, на базу. Что он из неё читает? Города, профиль, корзину? Иногда нужные записи находятся в нескольких таблицах, для теста мучительно ищешь их по дебагеру. Из интерфейса функции совершенно ничего не понятно:

// К каким таблицам пойдёт запись? От чего зависит работа функции?public func saveOrder(_ order: Order, to realm: Realm) 

При обновлении Xcode каждый раз ломался CI. Обновление Realm его быстро чинило, но это лишние нервы каждый год.

Всё вместе это приводило к тому, что весь код вокруг Realm превращался в легаси:

• его сложно рефакторить;

• надо помнить про миграции;

• могли быть неожиданные ошибки.

Это всё неприятно, но не критично: чуть больше кода, чуть меньше контроля, но работает.

Реально бесил лишь перформанс меню, но это можно было решить, стоило только сфокусироваться и попрофилировать. Коллеги на Android столкнулись с отсутствием каскадного удаления, но на iOS мы достаточно хорошо обработали это вручную, когда перед добавлением удаляли все прошлые объекты одного типа. Это же спасало и от разбухания базы.

Многие проблемы можно было решить инфраструктурно, но это только усложняло код. Например, чтобы не работать с объектами базы напрямую мы завели репозитории, которые конвертировали Realm Object в доменные объекты. Но это всё дополнительный код и усложнение.

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

Почему решили удалить две последние капли

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

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

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

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

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

Ситуация всех вымотала, но мы чувствовали, что проблема была в нашем коде. Мы думали, что виноват не Realm, поэтому снова ничего не делали, но затаили обиду.

Realm мигрирует без учета версии схемы. Могут быть сложности при повторном переименовании Property.

Откат. Через два месяца мы столкнулись в непонятным крешем Realm accessed in incorrect thread. Это было очень странно, потому что мы были точно уверены, что работаем с потоком правильно: вся работа с базой велась строго в отдельном потоке. Креш случался в самых разных местах, стабильности не было. Искали его неделю: у нас был pull request на версию с ошибкой, мы отревьювили 700 файлов 3 раза, но не смогли найти проблему.

Миграций базы уже не было, поэтому в качестве быстрого решения мы откатились на прошлую версию приложения. Это была ошибка. С откатом всё стало только хуже: Realm не мог прочитать свой файл из-за разницы версий самого Realm, он не смог прочитать свой файл. Повезло, что мы обновили только 1% пользователей и вовремя остановили. Откат обошелся в 3000 крешей.

Креши нам показали место, на которое мы не обратили внимание: версия Realm обновилась. На устранение проблемы ушла ещё неделя: написали удаление файла Realm в случае проблем с его чтением, дождались ревью и раскатки до пользователей.

Стало ясно, что так выкатывать приложение нельзя, каждый раз что-то случается, в этом каждый раз задействован Realm. Конечно, на ошибках мы учились, но так подставлять нельзя ни пользователей, ни бизнес. Каждый новый релиз стал восприниматься как смертельное решение, страшно было катнуть даже маленький фикс с переводами. Есть ли креши? Никто не знает, он рандомный: UI-тесты иногда показывали, а иногда и по 5 раз проходили без проблем.

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

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

Краткий итог критичных проблем:

• проблемы с несколькими миграциями одного поля;

• проблемы многопоточности в новой версии Realm.

Примечание. Забегая вперед скажу, что ошибку в Realm поправили в версии 5.3.5 20-го августа, а столкнулись мы 6-го. Фикс Realm вышел через две недели после наших проблем, но брейкинчедж появился 16 мая проблему починили только спустя 3 месяца. Нам просто повезло, что мы не обновились раньше.

Как продали бизнесу удаление Realm

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

iOS команда не нашла аргументов за то, чтобы оставить Realm. При этом он мог нам заблокировать любой релиз новым неожиданным образом.

Увы, тут было не до продажи просто поставили перед фактом.

Выпиливание Realm не та задача, которую можно сделать в фоне, да ещё и в конечный период. Пришлось ставить ультиматум, что релизить в таком состоянии мы не можем, надо остановить разработку на какое-то время и выпилить целый слой в приложении. За дело берутся все команды, на тот момент это было 4 iOS-разработчика.

Естественно, первый вопрос от бизнеса на сколько времени останавливаемся. Ответ примерно месяц. Офигели все.

План работ по сносу

Делать такую задачу без плана самоубийство. Надо составить план задач и отслеживать прогресс.

Ключевые строки. Мы выписали ключевые строки, по которым можно отслеживать как много Realm используется в проекте. Это могло бы быть мерилом качества инкапсуляции Realm. Нашли 3300 мест. Погнали выпиливать.

Но такая верхнеуровневая метрика не рассказывает о сложности работы, только её количество.

Домены. Тогда мы выписали наши домены. За 3 года работы над приложением мы развязали домены, работать над ними можно было параллельно. Получилось так:

• меню;

• города и страны;

• профиль;

• адреса;

• активные заказы;

• корзина и детали заказа;

• оценка заказа;

• очередь синхронизации продуктов в корзине.

По каждому домену оценили сколько упоминаний их объектов, а потом всё сложили. Получилось 1500 мест.

Разделить работу оказалось удобно по доменам: одной команде один домен. Начали с самых больших и критичных: меню, корзина, активные заказы.

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

Ревизии. Каждый день делали ревизию по количеству упоминаний, строили график нашей скорости. Дольше всего выпиливали Realm из меню, в нём было 26 видов объектов с 852 упоминаниями. Над ним работало 2 человека и потратили 112 человеко-часов.

Многие домены очистились меньше чем за день. Это было шоком: мы пару лет бесились с того, как сложно работает корзина, а оказалось, что отказаться от кеширования в Realm можно за несколько часов.

Как удаляли

Простое удаление. Прозвучит странно, но где-то просто оказался лишний код. Например, в корзине у нас есть очередь из продуктов, которые ещё не были отправлены на сервер. Она нужна, чтобы не потерять продукт при сетевой ошибке. Мы сохраняли эту очередь в Realm, чтобы продукты не терялись даже между запусками. Хорошо, что это предусмотрено, но реальный шанс так потерять данные очень низкий. Для скорости выпиливания мы отказались от бэкапа корзины.

Замена объектов. Мы уже начали упрощать работу с Realm оборачивая его в абстракцию репозитория. План был такой: про способ хранения знает только репозиторий, а в приложение он отдает только доменные модели. Переписать успели процентов 30, это сильно помогло при удалении. При переписывании мы весь слой старых репозиториев с Realm заменяли на самописные репозитории, которые конвертировали структуры моделей через Codable и сохраняли в файл. Данных у нас не так много, способ подходит.

Самое сложное в таком случае правильно поменять Realm класс Entity на структуру: нужно поменять способ мутации объекта, ведь теперь он каждый раз копируется. Суммарно ошиблись пару раз в тех местах где тестов ещё не было.

Обычно работы по замене выглядели так:

• Убираем наследование от Object, убираем всё @objc dynamic декларации у property, меняем класс на структуру (если надо).

• Меняем запросы к Realm на обращение в наш репозиторий.

• Правим мелочи: тесты, доступ.

• Чистим: меняем типы property с сырых на доменные. Больше никаких непонятных Int, только Enum.

Переписывание. Какие-то части было проще переписать слишком много завязано на логику самого Realm. Так случилось с меню. Домен большой, но у нас было написано довольно много тестов на него, поэтому можно было переписать логику по старым тестам, временами ещё и удаляя легаси.

Ещё проблемы, которые нашли

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

Адреса. Они состоят из 3-х слоев: объект адреса, набор полей, которые его описывают, у каждого поля есть его тип. Например: нужна улица, её значение Ленина и она часть адреса Ленина 25. Простая система, но из-за обратных ссылок в коде можно было ходить по вложенности в любом порядке: не только 1-2-3, но и 1-2-1-2-3-2. Это сильно усложняло код. Написали тесты, поменяли структуру моделей, отрефакторили, теперь можно двигаться только в одном направлении 1-2-3 читать стало проще.

Города. В нашем домене встречаются две модели городов:

• короткая нужна только для списка городов на старте приложения;

• полная, которая подгружается после того, как выбрали город и нужна для работы приложения.

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

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

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

Пауза: фидбек и переоценка сроков

После недели интенсивного рефакторинга мы взяли паузу: стабилизировали релиз, начали брать бизнес-задачи. За неделю мы сделали очень много по доменам упоминание снизилось на 60%. В итоге у нас осталось 3 несвязанных домена: города, оценка заказа и очередь продуктов в корзине.

Релизить всё ещё было страшно, но мы были вдохновлены результатами и даже выпустили релиз.

С новым XCode мы получили новые проблемы с Realm, но и новые пути решений у нас тоже были:

Как нам казалось, до конца проекта оставалось пару недель, поэтому 2 из 3-х команд начали брать бизнес-задачи, а одна продолжила рефакторить проект.

Не так страшны первые 90% рефакторинга, как вторые 90%

В последнюю очередь мы меняли логику для городов. В городах всё оказалось сильно сложнее:

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

• Этот список обновляется на старте, новый список надо сохранять для следующего раза. Сохранить в бандл мы не можем, надо хранить отдельно.

• После выбора города скачивалась полная модель она хранится отдельно. Приложение должно работать только с ней.

• Информацию о городе получали в десятки мест приложения, каждый раз по ID с опциональным результатом. Это всё надо было унифицировать, а потом понять, что мы ничего не сломали. На всё подряд тесты не напишешь, нужен другой подход.

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

Флоу получился такой: мигрируем данные, пользователь выбирает город, докачиваем детали города, кешируем и показываем меню. Внутри есть особенности для разных стран, но сейчас они для нас не важны, да и всё скрыто внутри фреймворка.

Этот этап оказался сложным технически и занял пару месяцев работы. Сам Realm удалился за неделю, в остальном мы рефакторили и выносили код во фреймворк, чтобы однозначно сказать, что всё работает правильно.

Раньше в приложении много где дублировался код:

• Взять текущий идентификатор города.

• Получить запись из базы по идентификатору.

• Взять первый объект в ответе, это считаем текущим городом.

• Повторить в каждом месте.

Надежность перешла на уровень зависимостей между модулями. У приложения всегда есть текущий город, он строго один.Если города нет, то его надо выбрать пользователю (или получить от сервера при миграции) и только потом стартовать основную часть приложения.

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

Примечание. О модульности и тестах напишу как-нибудь потом, подписывайтесь на канал.

Миграция

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

В этом нам сильно повезло: когда мы отказались от миграций в Realm, мы перенесли все нужные для работы ID в UserDefaults. Мы знали ID корзины или выбранного города, поэтому на старте нужно было только получить новые данные от API.

Если бы критичные данные были только в Realm, то пришлось бы удалять базу в несколько апдейтов сильно растягивая переход по времени. Или вообще просить пользователя выбрать город ещё раз.

Храните критичные ID вне базы пригодятся.

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

Чистка после Realm

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

/// Давным давно, когда API был не очень, мы использовали Realm: собирали все ответы в одном базе, а потом читали из неё./// Больше такой фигни нет и мы всё аккуратно раскладываем по репозиториям./// Теперь на месте Realm вот такой маленький шрам, для того чтобы очистить старых клиентов./// Удали этот код, если читаешь это в 2022 году.internal final class RealmCleaner {    let fileManager = FileManager.default     /// Remove all realm files    /// - Returns: total size of removed files    func removeRealmFiles() {        let pathes = filePathes()        fileManager.removeItems(at: pathes)    }     private func filePathes() -> [URL] {        let baseURL = fileManager.documentsDirectory().appendingPathComponent("default.realm")        let realmURLs = [            baseURL,            baseURL.appendingPathExtension("lock"),            baseURL.appendingPathExtension("note"),            baseURL.appendingPathExtension("management"),            baseURL.appendingPathExtension("log_a"),            baseURL.appendingPathExtension("log_b")        ]         return realmURLs    }}

Мы замерили размер удаляемых файлов: в основном меньше 15 МБ, но было и несколько пользователей с размером в 150 и даже 300 МБ. И это не девайсы тестировщиков.

Новое хранилище

Какие-то данные всё равно хочется хранить. Мы уже избавились от Realm-объектов, перевели все на доменные. Хочется использовать их так, чтобы больше не надо было конвертировать из одного типа в другой только для хранения. Core Data таким образом тоже не подходит.

Мы собрали требования к хранению:

• Хотим работать с доменным объектами.

• Умеет работать с разным количеством объектов: хранит как один объект для типа (профиль пользователя может быть только один), так и коллекцию (список из городов).

• Хранить можно в памяти или с кешем на диск. Приложение должно работать даже если на диске нет места. Кеш на диске опционален.

• Для кеша на диск готовы запариться чуть больше, если надо.

• Объемы данных всегда небольшие (меньше мегабайта) и слабо связанные реляционная БД не нужна.

• Допускаем, что каждый фреймворк приложения может хранить данные по-своему. Для сообщений база данных нужна, для кеша городов точно нет, а что-то лежит в UserDefaults. Но стандартизируем подходы по возможности.

Мы разделили способ хранения и количество объектов, которое можно хранить. В объявлении репозитория видно ключевые части:

public class ProfileRepository: SingleRepository<ProfileModel> {    public init() {        super.init(storage: InMemoryStorageWithFilePersistance().toAny())    }}

• SingleRepository хранит один объект.

• Хранит только модель ProfileModel.

• Хранит объект в памяти и кеширует на диск.

• Ещё есть InMemoryStorage и FileStorage. Для хранения на диске модель должна реализовать протокол Codable, а для хранения в памяти это не нужно. Для доменной модели это вполне подходит и легко поддерживать. Теперь отдельную модель для записи в базе создавать не нужно.

Коллекция пиццерий хранится в CollectionRepository: синтаксис похож, только наследуемся от другого класса.

public class PizzeriaRepository: CollectionRepository<PizzeriaModel> {    public init() {        super.init(storage: InMemoryStorageWithFilePersistance().toAny())    }}

Примечание. Про устройство рассказывать долго: там и box typing, и работа с асинхронностью. Пишите в комментарии, если интересно узнать как работает внутри.

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

Мониторинг

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

Запросы во время миграции. Мы пропустили, что во время миграции может восстановиться push-токен от Firebase и мы отправим его в наше API. Хедеры запроса зависят от текущей страны, а она в процессе миграции. Запрос не проходил, возник фон некритичных ошибок.

Падение профиля. Он падал при одновременном чтении и записи из разных потоков. Мы не сталкивались с этим при разработке, а он оказался единственным классом среди всех моделей в репозиториях, остальные были структурами. Переделали на структуру, проблемы с одновременным доступом ушли.

Крешрейт к Новому годы мы довели до 99.95%. Можно улучшать ещё, ведь теперь креши не в рандомных местах Realm, а только в нашем продукте и понятно как их чинить.

Результаты

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

Домены. От изначальной проблемы связанных доменов почти ничего не осталось: всё работает независимо, мы активно разделяем приложение на фреймворки. Работать с такими модулями удобно: быстро компилируются, мало зависимостей и связей, понятная ответственность, легче тестировать. Можно даже из одного модуля создать отдельное приложение-витрину и написать для него UI-тесты.

Сделали первый полный фича-фреймворк. Мы давно, но не спеша занимаемся распилом, только сейчас получилось дожать целый модуль. Стало понятней как строить архитектуру остальных фича-фреймворков.

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

Объём. Приложение уменьшилось на 8 МБ от Realm, запустили процесс по ревизии размера и уменьшили ещё на 10 МБ за счет бандла. Начали трекать размер приложения при каждом релизе.

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

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

Стало проще. Мы нашли старые баги и заревьювили несколько архитектурных задач. Работать стало проще. Теперь в приложении всегда можно быть уверенным, что город имеет все данные и не нужно возиться с опциональностью. Стало проще разрабатывать: у нас получились нормальные доменные объекты, удалили целый слой приложения и маперы из одного в другое, кое-где переосмыслили архитектуру. Упростилось деление приложения на фреймворки, можно идти в сторону аппклипс. Домен городов уехал в отдельный фреймворк.

Блокировки. Перестали блокироваться релизами Realm при обновлении Xcode, смогли обновить Cocoapods и поды на XCFramework.

У каждой зависимости своя цена и её надо прикидывать с самого начала. Нормально стартануть в типовой зависимостью, но надо иметь план на то, как выпиливать, как менять и как это поддерживать.

Realm сложный инструмент и его надо уметь обслуживать. Простота интеграции бывает обманчива.

Больше новостей про разработку в Додо Пицце я пишу в канале Dodo Pizza Mobile. Также подписывайтесь на чат Dodo Engineering, если хотите обсудить эту и другие наши статьи и подходы.