Когда заходит речь про тени на Android, возникает сразу несколько вопросов. Первый: зачем они нужны? Второй: почему нельзя использовать системные тени и жить счастливо? Третий: если нельзя использовать системные тени, как реализовать кастомные?

Это Сергей Петров, Android-разработчик в команде Design System inDrive, и вместе мы поговорим о тенях на Android.

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

Искренне надеюсь, что ваша стойкость и убедительность позволит вам и дальше использовать elevation для отрисовки теней. Если нет — придется искать ответ на третий вопрос.

Оговорюсь, что изначально я пробовал подобрать нужные значения параметров для системных теней. В Android, начиная с API 21, доступны атрибуты темы ambientShadowAlpha и spotShadowAlpha. С помощью них можно регулировать глобальные настройки прозрачности теней.

А позже в API 28 добавили возможность настраивать цвета теней через атрибуты темы outlineAmbientShadowColor и outlineSpotShadowColor, а также свойства View — outlineAmbientShadowColor и outlineSpotShadowColor.

Elevation

Попробуем подобрать подходящий elevation и прозрачность тени, и посмотрим, что из этого получится.

У нас в дизайне есть три разновидности теней (представлены на картинке ниже):

• S — размер 12dp.

• M — размер 20dp.

• L — размер 32dp.

У каждой тени свои настройки прозрачности и смещения по оси Y. На смещение мы влиять не можем, но хотя бы попробуем подобрать значения прозрачности. Сложность в том, что до API 28 эти значения глобальны в рамках темы. Задать разным по стилю теням разные прозрачности, как в дизайне, возможности нет. К тому же, цвет тени в дизайне не черный, как в дефолтном Android. Что ж, попробуем добиться хотя бы примерного сходства.

Долго и усердно подбираем значения, примерно подходящие всем трем теням сразу.

// тема
<item name="android:ambientShadowAlpha">0.01</item>
<item name="android:spotShadowAlpha">0.08</item>

// настройки elevatiom
<dimen name="elevation_s">12dp</dimen>
<dimen name="elevation_m">24dp</dimen>
<dimen name="elevation_l">30dp</dimen>

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

Получается, задача решена, и можно убеждать дизайнера, что тень S будет слегка отличаться от дизайна. В конце концов, пользователь вряд ли это заметит, да и кто вообще из пользователей Android обращает внимание на такие мелочи.

Но оказалось, что не все так просто. В Android два источника света: ambient light, который светит во все стороны, и key light — светит направленно. Кому интересно, в этой статье очень хорошо и с картинками раскрыта эта тема.

Тот, что светит сверху под углом, и есть key light. Он дает ярко выраженную тень в нижней части объекта. И вот, что происходит с тенью, особенно при больших elevation, по мере отдаления от верхней части экрана.

Как в жизни: чем дальше от источника света, тем длиннее тень. Можно ли на это повлиять? В данной статье в разделе Don’t try this at home утверждается, что да, но у меня не получилось. Но даже если бы и получилось, и на код-ревью закрыли глаза на этот очевидный хак, это не решило проблемы полностью. Где бы не размещался источник света, тени в любом случае были бы неравномерными. Причина тому — большой elevation, необходимый для достижения нужного эффекта.

Изрядно расстроившись, переходим к плану Б — рисовать тень самостоятельно.

MaterialShapeDrawable

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

Заглядываем внутрь MaterialShapeDrawable и видим, что они на пару с неким ShadowRenderer занимаются интересными вещами. По заданным параметрам формы тень отрисовывается при помощи шейдеров LinearGradient и RadialGradient. То есть, тень — это градиент вокруг формы.

Идея интересная, попробуем ее в действии. Для этого сделаем простую кастомную вьюшку и посмотрим, что получится.

val shape = ShapeAppearanceModel.builder()
  .setAllCornerSizes(16.toPx())
  .build()

val drawable = MaterialShapeDrawable(shape)
drawable.fillColor = ColorStateList.valueOf(Color.WHITE)
drawable.shadowVerticalOffset = 8.toPx()
drawable.shadowRadius = 32.toPx()
drawable.shadowCompatibilityMode = MaterialShapeDrawable.SHADOW_COMPAT_MODE_ALWAYS

background = drawable

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

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

Время отрисовки одного кадра — 18 миллисекунд. Это только draw одной вьюшки на экране. А draw — довольно частая операция ????

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

Как еще нарисовать тень

В процессе поиска ответа на этот вопрос нашлись еще 3 способа, помимо указанных выше.

1. Paint.setShadowLayer — самый простой и понятный. Минимум кода, отлично работает при наличии аппаратного ускорения (что для современных устройств — стандарт).

2. BlurMaskFilter — второй по простоте, чуть больше кода, работает также отлично.

3. ScriptIntrinsicBlur — пожалуй, еще сложнее, также смущает статус Deprecated и рекомендации по миграции.

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

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

Анализ требований

Допустим, со способом определились. Теперь сформулируем, что в итоге хотим получить. В идеальном мире это должно быть также удобно, как указать elevation.

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

Кроме того, должна быть возможность указать параметры тени в XML (в верстке или в стиле) и, что немаловажно, увидеть результат в превью Android Studio.

Еще нужно уметь отрисовать тень у любых View, вне зависимости от того, есть ли у них фон или elevation. И совсем хорошо, если время отрисовки не будет занимать весь фрейм.

Также определимся, что тень у нас отбрасывает только простая форма: прямоугольник (со скругленными углами или без), овал, и возможно модный squircle, если не удастся отговорить дизайнеров.

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

План решения:

• Создадим Drawable, умеющий рисовать тень определенной формы.

• Напишем View, использующий этот Drawable.

• Измерим производительность решения.

NinePatchDrawable

В одной замечательной статье про тени на Android от этой идеи отказались. Статья действительно замечательная, но почему-то не попалась мне на глаза в тот момент, когда я искал решение.

Итак, что такое 9-patch и зачем он нужен? Тут мне, как старому разработчику игр на Marcomedia Flash (да упокой Господь его душу вместе с душой Стива), нужно смахнуть ностальгическую слезу. Эту технику я впервые повстречал там, а «Википедия» утверждает, что именно там она впервые и была придумана.

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

Таким образом, экономится и память (размер Bitmap минимален), и процессорное время (отдать Bitmap на отрисовку почти ничего не стоит). Ну а GPU только дай Bitmap порисовать.

К счастью, Android дает возможность разработчикам создавать NinePatchDrawable программно. А поскольку и форма фигуры и параметры тени известны — задача тривиальная.

Реализация

Определим параметры и форму тени:

data class ShadowSpec(
  @ColorInt val shadowColor: Int = Color.TRANSPARENT,
  @Px val shadowOffsetX: Float = 0f,
  @Px val shadowOffsetY: Float = 0f,
  @Px val shadowSize: Float = 0f,
  val cornerSize: CornerSize? = null,
  val cornerSizeTopLeft: CornerSize? = null,
  val cornerSizeTopRight: CornerSize? = null,
  val cornerSizeBottomLeft: CornerSize? = null,
  val cornerSizeBottomRight: CornerSize? = null
)

Для построения формы было решено использовать ShapeAppearanceModel, а также ShapeAppearancePathProvider, который на основе этой модели построит Path, используемый для конечной отрисовки.

В коде это выглядит так:

// строим форму - спасибо исходникам Material
val path = Path()
val provider = ShapeAppearancePathProvider()
val model = ShapeAppearanceModel.Builder()
  .setTopLeftCorner(CornerFamily.ROUNDED, topLeftCornerSize)
  .setTopRightCorner(CornerFamily.ROUNDED, topRightCornerSize)
  .setBottomLeftCorner(CornerFamily.ROUNDED, bottomLeftCornerSize)
  .setBottomRightCorner(CornerFamily.ROUNDED, bottomRightCornerSize)
  .build()

provider.calculatePath(model, 1f, RectF(0f, 0f, width, height), path)

Форма есть, теперь посчитаем, сколько займет тень — радиус тени плюс смещение. Есть еще параметр SHADOW_SPREAD_MULTIPLIER, чуть увеличивающий область для того, чтобы все непрозрачные пиксели поместились в итоговый Bitmap.

// на глаз подбираем размер тени при размытии так,
// чтобы все непрозрачные пиксели отрисовывались в итоговой области.
with(spec) {
  val spreadOffset = shadowSize * SHADOW_SPREAD_MULTIPLIER
  spreadBounds.set(
    (spreadOffset - shadowOffsetX).coerceAtLeast(0f),
    (spreadOffset - shadowOffsetY).coerceAtLeast(0f),
    (spreadOffset + shadowOffsetX).coerceAtLeast(0f),
    (spreadOffset + shadowOffsetY).coerceAtLeast(0f)
  )
}

Минимально необходимый же размер Bitmap считается как радиусы скругления углов формы плюс размер самой тени. Границы 9.patch тоже считаются тривиально.

// определяем границы углов
val left = max(topLeftCornerSize, bottomLeftCornerSize)
val top = max(topLeftCornerSize, topRightCornerSize)
val right = max(topRightCornerSize, bottomRightCornerSize)
val bottom = max(bottomLeftCornerSize, bottomRightCornerSize)

// минимальный размер исходя из формы, с некоторым запасом
val width = max(left + right, dp20) + 2 * dp1
val height = max(top + bottom, dp20) + 2 * dp1

// размер Bitmap
val bitmapWidth = width + spreadBounds.left + spreadBounds.right
val bitmapHeight = height + spreadBounds.top + spreadBounds.bottom

// области для 9.patch
val leftChunk = left + spreadBounds.left
val topChunk = top + spreadBounds.top
val rightChunk = bitmapWidth - right - spreadBounds.right
val bottomChunk = bitmapHeight - bottom - spreadBounds.bottom

Приступим к отрисовке. Мы используем Paint.setShadowLayer и после вырезаем форму, оставляя земле лишь тень на случай, если элемент с тенью решит стать полупрозрачным.

// готовим инструменты для отрисовки
val paint = Paint(Paint.ANTI_ALIAS_FLAG).apply {
  color = spec.shadowColor
  setShadowLayer(spec.shadowSize, spec.shadowOffsetX, spec.shadowOffsetY, spec.shadowColor)
}

val clearPaint = Paint(Paint.ANTI_ALIAS_FLAG).apply {
  xfermode = PorterDuffXfermode(PorterDuff.Mode.CLEAR)
}

val matrix = Matrix()
matrix.postTranslate(spreadBounds.left, spreadBounds.top)
path.transform(matrix)

// отрисовываем форму с тенью и вырезаем саму форму
canvas.drawPath(path, paint)
canvas.drawPath(path, clearPaint)

На выходе получаем такую аккуратную картинку. Зелеными линиями на ней показана сетка, в соответствии с которой будет происходить растяжение. C помощью этой Bitmap можно отрисовать форму любого размера с тенью S и углами 16dp.

Остается лишь «запечатать» ее в NinePatchDrawable. API не самый простой, но StackOverflow не бросит в трудную минуту.

// строим drawable
drawable = NinePatchDrawable(
  context.resources,
  NinePatchUtils.getNinePatch(
    bitmap = bitmap,
    left = leftChunk.roundToInt(),
    top = topChunk.roundToInt(),
    right = rightChink.roundToInt(),
    bottom = bottomChunk.roundToInt()
  )
)

Использование

Поместив всю реализацию в класс ShadowRenderer на 200 строк, можем создать ShadowView и попробовать его в действии. Тут нужно обратить внимание на три момента.

Во-первых, придется отключить outlineProvider для того, чтобы убрать нативную тень, которую дает elevation. Сам elevation мы хотим сохранить по понятным причинам. К тому же, outlineProvider не позволит нам нарисовать тень за пределами собственных границ ShadowView, если вдруг включить clipToOutline.

Во-вторых, нужно отключить clipChildren у родительского контейнера — тень мы хотим снаружи, а не внутри границ View.

Третий момент обнаружился, когда я попробовал применить к ShadowView полупрозрачность (для наглядности сделаю тень красной).

Оказалось, что при alpha меньше единицы клиппинг у View включается автоматически, обрезая тень. Но тут я отделался легким испугом. Достаточно было прочитать документацию к методу View.setAlpha и опять обрести душевный покой.

Starting with Build.VERSION_CODES.M, setting a translucent alpha value will clip a View to its bounds, unless the View returns false fromhasOverlappingRendering().

Посмотрим на наш ShadowView. За минусом конфигурации получаем 3 метода.

override fun hasOverlappingRendering(): Boolean {
  // по умолчанию View не отрисовывает за своими границами,
  // если alpha < 1 (см setAlpha)
  // переопределяем это поведение, если есть видимая тень
  return !shadowSpec.isShadowVisible
}

override fun onSizeChanged(w: Int, h: Int, oldw: Int, oldh: Int) {
  super.onSizeChanged(w, h, oldw, oldh)
  shadowRenderer.setSize(w, h)
}

override fun draw(canvas: Canvas) {
  shadowRenderer.draw(canvas)
  super.draw(canvas)
}

Конечно, методов там чуть больше. Есть еще автоматическое отключение chipChildren у контейнера, отключение outlineProvider, установка параметров тени из стиля/программно — все то, что мы с вами так любим писать в кастомных вьюшках. Но в действительности процесс создания компонента с тенью выглядит просто.

Производительность

Я был практически уверен, что в этом отношении проблем не возникнет по причинам, описанным выше. Так и произошло.

Сценарий тот же самый, что и с MaterialShapeDrawable: один ShadowView на экране и аниматор, меняющий его размеры.

Естественно, процесс создания Bitmap тоже не бесплатен, но визуально в трейсе найти его не удалось — все фреймы коротенькие и ровненькие, как на подбор. Ставить в код метку для трейса и выяснять точное количество миллисекунд было уже лень.

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

Вариантов решения два. Первый — пропускать генерацию Bitmap и рисовать тень на канвасе с помощью Paint напрямую в каждом вызове draw. Второй — указать большие значения радиуса углов, достаточные для отрисовки овала. Так получим большую исходную Bitmap, но зато отрисовка останется мгновенной.

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

Заключение

Стоила ли игра свеч? Определенно да. Тени стали выглядеть гораздо лучше, чем стандартный elevation.

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

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

Что с Compose? С Compose все будет хорошо, скоро, скоро.