Dodo is

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

Бермудский треугольник проблем

Проблемы разработчиков

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

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

Проблемы инфраструктуры

• 60 ролей;
• 102 плейбука;
• обвязка на Python и Bash;
• тесты в Vagrant, запускаемые вручную.

Проблемы бизнеса

• с одной стороны, для решения таких задач нужны программисты с глубокими знаниями инфраструктуры;
• с другой стороны, нужны operations (назовём их баззвордом DevOps), которые умеют программировать на хорошем промышленном уровне;
• с третьей стороны, бизнесу нужен баланс между надёжностью и доступностью этих систем и их стоимостью.

И что с этим делать?

• механизмы мониторинга приложений и инфраструктуры (спойлер: это мы в 2018 думали, что они хорошие, а сейчас уже всё переписали);
• процессы для дежурств 24/7 on-call;
• практика ведения постмортемов по инцидентам и их анализ;
• нагрузочное тестирование;
• CI/CD-пайплайны для прикладного софта;
• хорошие программисты, которые пишут хороший код;
• евангелист SRE в команде инфраструктуры.

Онбординг SRE-команды

1. Обучить программистов тем знаниям и навыкам, которые необходимы для дежурств и операционной деятельности в команде инфраструктуры.
2. Написать IaC описание всей инфраструктуры в коде. Причём это должен быть полноценный программный продукт с CI/CD, тестами.
3. Пересоздать всю нашу инфраструктуру из этого кода и забыть про ручное накликивание виртуалок мышкой в Azure.

Две составляющие онбординга: обучение и практика

• на чтение статей и книг из списка литературы: Linux, сети, SRE;
• на лекции по конкретным инструментам и технологиям;
• на клубы по технологиям, например, по Linux, где мы разбирали сложные случаи и кейсы.

Практики Extreme Programming в инфраструктуре

Технические и антропогенные проблемы на пути

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

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

Итоги онбординга

• Создали полноценный программный продукт, который управляет нашей DEV-инфраструктурой, с собственным CI-пайплайном, с тестами и прочими атрибутами качественного программного продукта.
• Удвоили количество людей, которые готовы дежурить и сняли нагрузку с текущей команды. Спустя ещё полгода эти люди стали полноценными SRE. Теперь они могут потушить пожар на проде, проконсультировать команду программистов по НФТ, или написать свою библиотеку для разработчиков.
• Сместили майндсет в сторону идей SRE. Не только у участников проекта онбординга, но и у тех программистов из продуктовых команд, которые теперь могут разговаривать с нами на одном языке.
• Сильно устали: и те, кто участвовал в онбординге, и те, кто участвовал в дежурствах.

Вместо выводов: инсайты, не наступайте на наши грабли

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

PPS: Эта статья написана по моему выступлению на DevOpsConf осенью 2019 года. С тех пор прошло довольно много времени, и теперь уже точно понятно, что всё было не зря: тойл теперь не съедает бОльшую часть времени инженеров, наша команда теперь может реализовывать крупные долгосрочные проекты по улучшению инфраструктуры в широком смысле, а программисты почти не жалуются на безумных DevOps-инженеров, которые только мешают жить.

PPPS: В этом году конференция, посвящённая DevOps-практикам, будет называться DevOps Live 2020. Изменения коснутся не только названия: в программе будет меньше докладов и больше интерактивных обсуждений, мастер-классов и воркшопов. Рецепты о том, как расти и перестраивать процессы с помощью DevOps-практик. Формат также изменится два блока по два дня и домашние задания между ними.

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

Бриллиантовый чекаут: предыстория

Смотри, какая классная анимация на iOS. Давай так же сделаем?

1. Клиент нажимал на поле адреса пиццерии -> в ответ открывался фрагмент Самовывоз. Открывался он на весь экран (так было задумано) с резким скачком, при этом список пиццерий появлялся с небольшой задержкой.
2. Когда клиент нажимал Назад -> возврат на предыдущий экран происходил с резким скачком.
3. При нажатии на поле способа оплаты -> снизу с резким скачком открывался фрагмент Способ оплаты. Список способов оплаты появлялся с задержкой, при их появлении экран увеличивался со скачком.
4. При нажатии Назад -> возврат обратно с резким скачком.

В чём, собственно, проблема: где клиенту хорошо, там у нас ограничения

Предварительная разметка

<?xml version="1.0" encoding="utf-8"?><FrameLayout xmlns:android="http://personeltest.ru/away/schemas.android.com/apk/res/android"    android:layout_width="match_parent"    android:layout_height="wrap_content"    android:background="@drawable/dialog_gray200_background"    >   <androidx.fragment.app.FragmentContainerView      android:id="@+id/container"      android:layout_width="match_parent"      android:layout_height="match_parent"      /> </FrameLayout>

<?xml version="1.0" encoding="utf-8"?><selector xmlns:android="http://personeltest.ru/away/schemas.android.com/apk/res/android">  <item>    <shape android:shape="rectangle">      <solid android:color="@color/gray200" />      <corners android:bottomLeftRadius="0dp" android:bottomRightRadius="0dp" android:topLeftRadius="10dp" android:topRightRadius="10dp" />    </shape>  </item></selector>

Первые попытки реализовать анимацию

animateLayoutChanges

<?xml version="1.0" encoding="utf-8"?><FrameLayout xmlns:android="http://personeltest.ru/away/schemas.android.com/apk/res/android"    android:layout_width="match_parent"    android:layout_height="wrap_content"    android:background="@drawable/dialog_gray200_background"    >   <FrameLayout      android:id="@+id/container"      android:layout_width="match_parent"      android:layout_height="match_parent"      android:animateLayoutChanges="true"      /> </FrameLayout>

setCustomAnimations

<?xml version="1.0" encoding="utf-8"?><set xmlns:android="http://personeltest.ru/away/schemas.android.com/apk/res/android"    android:duration="500"    android:interpolator="@android:anim/accelerate_interpolator">  <translate android:toXDelta="100%" /></set>

<?xml version="1.0" encoding="utf-8"?><set xmlns:android="http://personeltest.ru/away/schemas.android.com/apk/res/android"    android:duration="500"    android:interpolator="@android:anim/accelerate_interpolator">  <translate android:fromXDelta="-100%" /></set>

<?xml version="1.0" encoding="utf-8"?><set xmlns:android="http://personeltest.ru/away/schemas.android.com/apk/res/android"    android:duration="500"    android:interpolator="@android:anim/accelerate_interpolator">  <translate android:toXDelta="-100%" /></set>

<?xml version="1.0" encoding="utf-8"?><set xmlns:android="http://personeltest.ru/away/schemas.android.com/apk/res/android"    android:duration="500"    android:interpolator="@android:anim/accelerate_interpolator">  <translate android:fromXDelta="100%" /></set>

fragmentManager    .beginTransaction()    .setCustomAnimations(R.anim.to_left_in, R.anim.to_left_out, R.anim.to_right_in, R.anim.to_right_out)    .replace(containerId, newFragment)    .addToBackStack(newFragment.tag)    .commit()

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

А может попробуем что-то внезапное: Shared Element Transition

• пометить начальный элемент и конечный элемент атрибутом transitionName с одинаковым значением;
• указать sharedElementEnterTransition для второго фрагмента.

<?xml version="1.0" encoding="utf-8"?><androidx.constraintlayout.widget.ConstraintLayout     xmlns:android="http://personeltest.ru/away/schemas.android.com/apk/res/android"    xmlns:app="http://personeltest.ru/away/schemas.android.com/apk/res-auto"    xmlns:tools="http://personeltest.ru/away/schemas.android.com/tools"    android:layout_width="match_parent"    android:layout_height="wrap_content"    android:transitionName="checkoutTransition"    >

Важно: это будет работать, поскольку мы используем REPLACE в транзакции фрагментов. Если вы используете ADD (или используете ADD и скрываете предыдущий фрагмент с помощью previousFragment.hide() [не надо так делать]), то transitionName придётся задавать динамически и очищать после завершения анимации. Так приходится делать, потому что в один момент времени в текущей иерархии View не может быть две View с одинаковым transitionName. Осуществить это можно, но будет лучше, если вы сможете обойтись без такого хака. Если вам всё-таки очень нужно использовать ADD, вдохновение для реализации можно найти в этой статье.

newFragment.sharedElementEnterTransition = AutoTransition()

fragmentManager    .beginTransaction()    .apply{      if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) {        addSharedElement(currentFragment.requireView(), currentFragment.requireView().transitionName)        setReorderingAllowed(true)      }    }    .replace(containerId, newFragment)    .addToBackStack(newFragment.tag)    .commit()

Важно: обратите внимание, что transitionName (как и весь Transition API) доступен начиная с версии Android Lollipop.

Пишем свой Transition

• Scene это расположение элементов на экране в определённый момент времени (layout) и ViewGroup, в которой происходит анимация (sceneRoot).
• Начальная сцена (Start Scene) это Scene в начальный момент времени.
• Конечная сцена (End Scene) это Scene в конечный момент времени.
• Transition класс, который собирает свойства начальной и конечной сцены и создаёт аниматор для анимации между ними.

• fun getTransitionProperties(): Array. Данный метод должен вернуть набор свойств, которые будут анимироваться. Из этого метода нужно вернуть массив строк (ключей) в свободном виде, главное, чтобы методы captureStartValues и captureEndValues (описанные далее) записали свойства с этими ключами. Пример будет далее.
• fun captureStartValues(transitionValues: TransitionValues). В данном методе мы получаем нужные свойства layout'а начальной сцены. Например, мы можем получить начальное расположение элементов, высоту, прозрачность и так далее.
• fun captureEndValues(transitionValues: TransitionValues). Такой же метод, только для получения свойств layout'а конечной сцены.
• fun createAnimator(sceneRoot: ViewGroup?, startValues: TransitionValues?, endValues: TransitionValues?): Animator?. Этот метод должен использовать свойства начальной и конечной сцены, собранные ранее, чтобы создать анимацию между этими свойствами. Обратите внимание, что если свойства между начальной и конечной сценой не поменялись, то данный метод не вызовется вовсе.

Реализуем свой Transition за девять шагов

1. Создаём класс, который представляет Transition.
   
   

   @TargetApi(VERSION_CODES.LOLLIPOP)class BottomSheetSharedTransition : Transition {@Suppress("unused")constructor() : super() @Suppress("unused")constructor(      context: Context?,       attrs: AttributeSet?) : super(context, attrs)}
   

   Напоминаю, что Transition API доступен с версии Android Lollipop.
2. Реализуем getTransitionProperties.
   
   Поскольку мы хотим анимировать высоту View, заведём константу PROP_HEIGHT, соответствующую этому свойству (значение может быть любым) и вернём массив с этой константой:
   
   

   companion object {  private const val PROP_HEIGHT = "heightTransition:height"   private val TransitionProperties = arrayOf(PROP_HEIGHT)} override fun getTransitionProperties(): Array<String> = TransitionProperties
   

3. Реализуем captureStartValues.
   
   Нам нужно запомнить высоту той View, которая хранится в параметре transitionValues. Значение высоты нам нужно записать в поле transitionValues.values (он имеет тип Map) c ключом PROP_HEIGHT:
   
   

   override fun captureStartValues(transitionValues: TransitionValues) {  transitionValues.values[PROP_HEIGHT] = transitionValues.view.height}
   

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

   override fun captureStartValues(transitionValues: TransitionValues) {  // Запоминаем начальную высоту View...  transitionValues.values[PROP_HEIGHT] = transitionValues.view.height   // ... и затем закрепляем высоту контейнера фрагмента  transitionValues.view.parent    .let { it as? View }    ?.also { view ->        view.updateLayoutParams<ViewGroup.LayoutParams> {            height = view.height        }    } }
   

4. Реализуем captureEndValues.
   
   Аналогично предыдущему методу, нужно запомнить высоту View. Но не всё так просто. На предыдущем шаге мы зафиксировали высоту контейнера. Новый фрагмент по высоте может быть меньше, равным или больше предыдущего фрагмента. В первых двух случаях мы можем просто взять высоту нового фрагмента. Однако в случае, когда новый фрагмент должен занять больше места, чем старый, значение высоты будет ограничено высотой контейнера. Поэтому придётся пойти на небольшую хитрость мы просто измерим view, чтобы определить, сколько места на самом деле ей требуется. Реализация будет выглядеть так:
   
   

   override fun captureEndValues(transitionValues: TransitionValues) {  // Измеряем и запоминаем высоту View  transitionValues.values[PROP_HEIGHT] = getViewHeight(transitionValues.view.parent as View)}
   

   
   И метод getViewHeight:
   
   

   private fun getViewHeight(view: View): Int {  // Получаем ширину экрана  val deviceWidth = getScreenWidth(view)   // Попросим View измерить себя при указанной ширине экрана  val widthMeasureSpec = MeasureSpec.makeMeasureSpec(deviceWidth, MeasureSpec.EXACTLY)  val heightMeasureSpec = MeasureSpec.makeMeasureSpec(0, MeasureSpec.UNSPECIFIED)   return view      // измеряем      .apply { measure(widthMeasureSpec, heightMeasureSpec) }      // получаем измеренную высоту      .measuredHeight      // если View хочет занять высоту больше доступной высоты экрана, мы должны вернуть высоту экрана      .coerceAtMost(getScreenHeight(view))} private fun getScreenHeight(view: View) =  getDisplaySize(view).y - getStatusBarHeight(view.context) private fun getScreenWidth(view: View) =  getDisplaySize(view).x private fun getDisplaySize(view: View) =  Point().also {    (view.context.getSystemService(        Context.WINDOW_SERVICE    ) as WindowManager).defaultDisplay.getSize(it)  } private fun getStatusBarHeight(context: Context): Int =  context.resources      .getIdentifier("status_bar_height", "dimen", "android")      .takeIf { resourceId -> resourceId > 0 }      ?.let { resourceId -> context.resources.getDimensionPixelSize(resourceId) }      ?: 0
   

   
   Таким образом, мы знаем начальную и конечную высоту контейнера, и теперь дело за малым создать анимацию.
5. Реализация анимации. Fade in.
   
   Начальный фрагмент нам анимировать не нужно, так как при старте транзакции он удалится из иерархии. Будем показывать конечный фрагмент с фэйдом. Добавляем метод в класс BottomSheetSharedTransition, ничего хитрого:
   
   

   private fun prepareFadeInAnimator(view: View): Animator =   ObjectAnimator.ofFloat(view, "alpha", 0f, 1f) 
   

6. Реализация анимации. Анимация высоты.
   
   Ранее мы запомнили начальную и конечную высоту, теперь мы можем анимировать высоту контейнера фрагментов:
   
   

   private fun prepareHeightAnimator(    startHeight: Int,    endHeight: Int,    view: View) = ValueAnimator.ofInt(startHeight, endHeight)    .apply {        val container = view.parent.let { it as View }                // изменяем высоту контейнера фрагментов        addUpdateListener { animation ->            container.updateLayoutParams<ViewGroup.LayoutParams> {                height = animation.animatedValue as Int            }        }    }
   

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

   private fun prepareHeightAnimator(    startHeight: Int,    endHeight: Int,    view: View) = ValueAnimator.ofInt(startHeight, endHeight)    .apply {        val container = view.parent.let { it as View }                // изменяем высоту контейнера фрагментов        addUpdateListener { animation ->            container.updateLayoutParams<ViewGroup.LayoutParams> {                height = animation.animatedValue as Int            }        }                // окончании анимации устанавливаем высоту контейнера WRAP_CONTENT         doOnEnd {            container.updateLayoutParams<ViewGroup.LayoutParams> {                height = ViewGroup.LayoutParams.WRAP_CONTENT            }        }    }
   

   
   Теперь всего лишь нужно использовать аниматоры, созданные этими функциями.
7. Реализация анимации. createAnimator.
   
   

   override fun createAnimator(    sceneRoot: ViewGroup?,    startValues: TransitionValues?,    endValues: TransitionValues?): Animator? {    if (startValues == null || endValues == null) {        return null    }     val animators = listOf<Animator>(        prepareHeightAnimator(            startValues.values[PROP_HEIGHT] as Int,            endValues.values[PROP_HEIGHT] as Int,            endValues.view        ),        prepareFadeInAnimator(endValues.view)    )     return AnimatorSet()        .apply {            interpolator = FastOutSlowInInterpolator()            duration = ANIMATION_DURATION            playTogether(animators)        }}
   

8. Всегда анимируем переход.
   
   Последний нюанс касательно реализации данного Transititon'а. Звёзды могут сойтись таким образом, что высота начального фрагмента будет точно равна высоте конечного фрагмента. Такое вполне может быть, если оба фрагмента занимают всю высоту экрана. В таком случае метод createAnimator не будет вызван совсем. Что же произойдёт?
   
   
   • Не будет Fade'а нового фрагмента, он просто резко появится на экране.
   • Поскольку в методе captureStartValues мы зафиксировали высоту контейнера, а анимации не произойдёт, высота контейнера никогда не станет равной WRAP_CONTENT.
   
   Неприятно, но не смертельно. Можно обойти это поведение простым трюком: нужно добавить любое значение, которое будет отличаться для начальной сцены и конечной сцены, в список свойств Transition'а. Можно просто добавить строки с разными значениями:
   
   

   companion object {    private const val PROP_HEIGHT = "heightTransition:height"    private const val PROP_VIEW_TYPE = "heightTransition:viewType"     private val TransitionProperties = arrayOf(PROP_HEIGHT, PROP_VIEW_TYPE)} override fun getTransitionProperties(): Array<String> = TransitionProperties override fun captureStartValues(transitionValues: TransitionValues) {    // Запоминаем начальную высоту View...    transitionValues.values[PROP_HEIGHT] = transitionValues.view.height    transitionValues.values[PROP_VIEW_TYPE] = "start"     // ... и затем закрепляем высоту контейнера фрагмента    transitionValues.view.parent        .let { it as? View }        ?.also { view ->            view.updateLayoutParams<ViewGroup.LayoutParams> {                height = view.height            }        } } override fun captureEndValues(transitionValues: TransitionValues) {    // Измеряем и запоминаем высоту View    transitionValues.values[PROP_HEIGHT] = getViewHeight(transitionValues.view.parent as View)    transitionValues.values[PROP_VIEW_TYPE] = "end"}
   

   
   Обратите внимание, добавилось свойство PROP_VIEW_TYPE, и в методах captureStartValues и captureEndValues записываем разные значения этого свойства. Всё, транзишн готов!
9. Применяем Transition.
   
   

   newFragment.sharedElementEnterTransition = BottomSheetSharedTransition()
   

Асинхронная загрузка данных

Всё вместе: что в итоге получилось

package com.maleev.bottomsheetanimation import android.animation.Animatorimport android.animation.AnimatorSetimport android.animation.ObjectAnimatorimport android.animation.ValueAnimatorimport android.annotation.TargetApiimport android.content.Contextimport android.graphics.Pointimport android.os.Buildimport android.transition.Transitionimport android.transition.TransitionValuesimport android.util.AttributeSetimport android.view.Viewimport android.view.ViewGroupimport android.view.WindowManagerimport android.view.animation.AccelerateInterpolatorimport androidx.core.animation.doOnEndimport androidx.core.view.updateLayoutParams @TargetApi(Build.VERSION_CODES.LOLLIPOP)class BottomSheetSharedTransition : Transition {     @Suppress("unused")    constructor() : super()     @Suppress("unused")    constructor(        context: Context?,        attrs: AttributeSet?    ) : super(context, attrs)     companion object {        private const val PROP_HEIGHT = "heightTransition:height"         // the property PROP_VIEW_TYPE is workaround that allows to run transition always        // even if height was not changed. It's required as we should set container height        // to WRAP_CONTENT after animation complete        private const val PROP_VIEW_TYPE = "heightTransition:viewType"        private const val ANIMATION_DURATION = 400L         private val TransitionProperties = arrayOf(PROP_HEIGHT, PROP_VIEW_TYPE)    }     override fun getTransitionProperties(): Array<String> = TransitionProperties     override fun captureStartValues(transitionValues: TransitionValues) {        // Запоминаем начальную высоту View...        transitionValues.values[PROP_HEIGHT] = transitionValues.view.height        transitionValues.values[PROP_VIEW_TYPE] = "start"         // ... и затем закрепляем высоту контейнера фрагмента        transitionValues.view.parent            .let { it as? View }            ?.also { view ->                view.updateLayoutParams<ViewGroup.LayoutParams> {                    height = view.height                }            }     }     override fun captureEndValues(transitionValues: TransitionValues) {        // Измеряем и запоминаем высоту View        transitionValues.values[PROP_HEIGHT] = getViewHeight(transitionValues.view.parent as View)        transitionValues.values[PROP_VIEW_TYPE] = "end"    }     override fun createAnimator(        sceneRoot: ViewGroup?,        startValues: TransitionValues?,        endValues: TransitionValues?    ): Animator? {        if (startValues == null || endValues == null) {            return null        }         val animators = listOf<Animator>(            prepareHeightAnimator(                startValues.values[PROP_HEIGHT] as Int,                endValues.values[PROP_HEIGHT] as Int,                endValues.view            ),            prepareFadeInAnimator(endValues.view)        )         return AnimatorSet()            .apply {                duration = ANIMATION_DURATION                playTogether(animators)            }    }     private fun prepareFadeInAnimator(view: View): Animator =        ObjectAnimator            .ofFloat(view, "alpha", 0f, 1f)            .apply { interpolator = AccelerateInterpolator() }     private fun prepareHeightAnimator(        startHeight: Int,        endHeight: Int,        view: View    ) = ValueAnimator.ofInt(startHeight, endHeight)        .apply {            val container = view.parent.let { it as View }             // изменяем высоту контейнера фрагментов            addUpdateListener { animation ->                container.updateLayoutParams<ViewGroup.LayoutParams> {                    height = animation.animatedValue as Int                }            }             // окончании анимации устанавливаем высоту контейнера WRAP_CONTENT            doOnEnd {                container.updateLayoutParams<ViewGroup.LayoutParams> {                    height = ViewGroup.LayoutParams.WRAP_CONTENT                }            }        }     private fun getViewHeight(view: View): Int {        // Получаем ширину экрана        val deviceWidth = getScreenWidth(view)         // Попросим View измерить себя при указанной ширине экрана        val widthMeasureSpec =            View.MeasureSpec.makeMeasureSpec(deviceWidth, View.MeasureSpec.EXACTLY)        val heightMeasureSpec =            View.MeasureSpec.makeMeasureSpec(0, View.MeasureSpec.UNSPECIFIED)         return view            // измеряем:            .apply { measure(widthMeasureSpec, heightMeasureSpec) }            // получаем измеренную высоту:            .measuredHeight            // если View хочет занять высоту больше доступной высоты экрана, мы должны вернуть высоту экрана:            .coerceAtMost(getScreenHeight(view))    }     private fun getScreenHeight(view: View) =        getDisplaySize(view).y - getStatusBarHeight(view.context)     private fun getScreenWidth(view: View) =        getDisplaySize(view).x     private fun getDisplaySize(view: View) =        Point().also { point ->            view.context.getSystemService(Context.WINDOW_SERVICE)                .let { it as WindowManager }                .defaultDisplay                .getSize(point)        }     private fun getStatusBarHeight(context: Context): Int =        context.resources            .getIdentifier("status_bar_height", "dimen", "android")            .takeIf { resourceId -> resourceId > 0 }            ?.let { resourceId -> context.resources.getDimensionPixelSize(resourceId) }            ?: 0}

private fun transitToFragment(newFragment: Fragment) {    val currentFragmentRoot = childFragmentManager.fragments[0].requireView()     childFragmentManager        .beginTransaction()        .apply {            if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) {                addSharedElement(currentFragmentRoot, currentFragmentRoot.transitionName)                setReorderingAllowed(true)                 newFragment.sharedElementEnterTransition = BottomSheetSharedTransition()            }        }        .replace(R.id.container, newFragment)        .addToBackStack(newFragment.javaClass.name)        .commit()}

<?xml version="1.0" encoding="utf-8"?><androidx.constraintlayout.widget.ConstraintLayout     xmlns:android="http://personeltest.ru/away/schemas.android.com/apk/res/android"    xmlns:app="http://personeltest.ru/away/schemas.android.com/apk/res-auto"    xmlns:tools="http://personeltest.ru/away/schemas.android.com/tools"    android:layout_width="match_parent"    android:layout_height="wrap_content"    android:transitionName="checkoutTransition"    >

А можно было сделать всё иначе?

• Отказаться от фрагментов, использовать один фрагмент с множеством View и анимировать конкретные View. Так вы получите больший контроль над анимацией, но потеряете преимущества фрагментов: нативную поддержку навигации и готовую обработку жизненного цикла (придётся реализовывать это самостоятельно).
• Использовать MotionLayout. Технология MotionLayout на данный момент всё ещё находится на стадии бета, но выглядит очень многообещающе, и уже есть официальные примеры, демонстрирующие красивые переходы между фрагментами.
• Не использовать анимацию. Да, наш дизайн является частным случаем, и вы вполне можете счесть анимацию в данном случае избыточной. Вместо этого можно показывать один Bottom Sheet поверх другого или скрывать один Bottom Sheet и следом показывать другой.
• Отказаться от Bottom Sheet совсем. Нет изменения высоты контейнера фрагментов нет проблем.

Демо проект можно найти вот тут на GitHub. А вакансию Android-разработчика (Нижний Новгород) вот здесь на Хабр Карьера.

---

Автор статьи: Максим Качинкин Android-разработчик в Додо Пицце.

---

Поиск и анализ проблемы

• Время запуска у пользователей выше 95-го процентиля составляет почти 20 секунд (у некоторых и больше), несмотря на то, что медианное время холодного запуска менее 5 секунд.
• Время запуска величина не постоянная, а растущая со временем. Но иногда наблюдаются падения. Эту закономерность мы нашли, когда увеличили масштаб анализа до 90 дней.

1. Что-то утекает.
2. Это что-то после релиза сбрасывается и потом утекает вновь.

Что не так с базой данных Realm

adb exec-out run-as ${PACKAGE_NAME} cat files/${DB_NAME}

Связь роста базы данных с временем запуска

• Запуск процесса.
• Инициализация объектов.
• Создание и инициализация активити.
• Создание лейаута.
• Отрисовка приложения.

adb shell am start -S -W ru.dodopizza.app/.MainActivity -c android.intent.category.LAUNCHER -a android.intent.action.MAIN

Причины бесконечного роста базы данных

Утечка данных без каскадного удаления

@RealmClassclass CartItemEntity( @PrimaryKey override var id: String? = null, ... var name: String = "", var description: String = "", var image: ImageEntity? = null, var category: String = MENU_CATEGORY_UNKNOWN_ID, var customizationEntity: CustomizationEntity? = null, var cartComboProducts: RealmList<CartProductEntity> = RealmList(), ...) : RealmObject()

val entity = realm.where(CartItemEntity::class.java).equalTo("id", id).findFirst()if (first != null) { deleteFromRealm(first.image) deleteFromRealm(first.customizationEntity) for(cartProductEntity in first.cartComboProducts) {   deleteFromRealm(cartProductEntity) } first.deleteFromRealm()}// и потом уже сохраняем

Решение по-быстрому

interface NestedEntityAware { fun getNestedEntities(): Collection<RealmObject?>}

@RealmClassclass DataPizzeriaEntity( @PrimaryKey var id: String? = null, var name: String? = null, var coordinates: CoordinatesEntity? = null, var deliverySchedule: ScheduleEntity? = null, var restaurantSchedule: ScheduleEntity? = null, ...) : RealmObject(), NestedEntityAware { override fun getNestedEntities(): Collection<RealmObject?> {   return listOf(       coordinates,       deliverySchedule,       restaurantSchedule   ) }}

@RealmClassclass ScheduleEntity( var monday: DayOfWeekEntity? = null, var tuesday: DayOfWeekEntity? = null, var wednesday: DayOfWeekEntity? = null, var thursday: DayOfWeekEntity? = null, var friday: DayOfWeekEntity? = null, var saturday: DayOfWeekEntity? = null, var sunday: DayOfWeekEntity? = null) : RealmObject(), NestedEntityAware { override fun getNestedEntities(): Collection<RealmObject?> {   return listOf(       monday, tuesday, wednesday, thursday, friday, saturday, sunday   ) }}

fun <T> Realm.deleteAllNestedEntities(entities: Collection<T>, entityClass: Class<out RealmObject>, idMapper: (T) -> String, idFieldName : String = "id" ) { val existedObjects = where(entityClass)     .`in`(idFieldName, entities.map(idMapper).toTypedArray())     .findAll() deleteNestedRecursively(existedObjects)}private fun Realm.deleteNestedRecursively(entities: Collection<RealmObject?>) { for(entity in entities) {   entity?.let { realmObject ->     if (realmObject is NestedEntityAware) {       deleteNestedRecursively((realmObject as NestedEntityAware).getNestedEntities())     }     realmObject.deleteFromRealm()   } }}

Решение по-нормальному

RealmModel::class.java.isAssignableFrom(field.type)RealmList::class.java.isAssignableFrom(field.type)

fun <T : Any> Realm.cascadeDelete(entities: Collection<T?>) { if(entities.isEmpty()) {   return } entities.filterNotNull().let { notNullEntities ->   notNullEntities       .filterRealmObject()       .flatMap { realmObject -> getNestedRealmObjects(realmObject) }       .also { realmObjects -> cascadeDelete(realmObjects) }   notNullEntities       .forEach { entity ->         if((entity is RealmObject) && entity.isValid) {           entity.deleteFromRealm()         }       } }}

private fun getNestedRealmObjects(realmObject: RealmObject) : List<RealmObject> { val nestedObjects = mutableListOf<RealmObject>() val fields = realmObject.javaClass.superclass.declaredFields// Проверяем каждое поле, не является ли оно RealmModel или списком RealmList fields.forEach { field ->   when {     RealmModel::class.java.isAssignableFrom(field.type) -> {       try {         val child = getChildObjectByField(realmObject, field)         child?.let {           if (isInstanceOfRealmObject(it)) {             nestedObjects.add(child as RealmObject)           }         }       } catch (e: Exception) { ... }     }     RealmList::class.java.isAssignableFrom(field.type) -> {       try {         val childList = getChildObjectByField(realmObject, field)         childList?.let { list ->           (list as RealmList<*>).forEach {             if (isInstanceOfRealmObject(it)) {               nestedObjects.add(it as RealmObject)             }           }         }       } catch (e: Exception) { ... }     }   } } return nestedObjects}private fun getChildObjectByField(realmObject: RealmObject, field: Field): Any? { val methodName = "get${field.name.capitalize()}" val method = realmObject.javaClass.getMethod(methodName) return method.invoke(realmObject)}

override fun <T : Entity> insert( entityInformation: EntityInformation, entities: Collection<T>): Collection<T> = entities.apply { realmInstance.cascadeDelete(getManagedEntities(entityInformation, this)) realmInstance.copyFromRealm(     realmInstance         .copyToRealmOrUpdate(this.map { entity -> entity as RealmModel } ))}

Результаты и выводы

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

Трудности запуска для бизнеса

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

Технические трудности

Как решили бизнес-проблемы

• разворачивать систему как есть;
  
• проверять, что все сценарии работают: заказы принимаются и готовятся, чеки печатаются, отчёты строятся;
  
• отдавать систему партнёрам, бизнес-девелоперам, маркетологам и всем остальным для донастройки под конкретную страну.
  

Как решили технические проблемы

• Запускаешь мастер начальной настройки страны.
  
• Говоришь: Запускаю Нигерию.
  
• Выбираешь язык, валюту, вводишь маску телефона, типы улиц и типы населенных пунктов.
  
• Вводишь логин и пароль для временного пользователя (для первого входа в систему).
  
• Next, next, next и готово заходишь в свежеразвёртную копию системы для Нигерии и создаёшь маркетологам и бизнес-девелоперам их персональные учётки.

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

• не надо было ничего выгружать в сторонние файлы;
  
• получать оповещения, что добавилась новая строка для переводов;
  
• было видно какие строки и в каком языке ещё не переведены.
  

Больше никакого Excel.

Что в итоге

Планы

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

Напоследок

• писать трекинг заказа в UK;
  
• адаптировать адресную систему;
  
• допиливать систему напильником под региональные особенности;
  
• помогать выходить на азиатский рынок.