Шаг за шагом — для того, что дорого.

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

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

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

Переключатель ниже лишь показывает уже готовый прозрачный материал на разных фонах. Он не загружает и не обрабатывает ваши фотографии заново в браузере.

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

Теперь список использует атласы прозрачных кадров, созданные из видео движений: 18 кадров на превью и бюджет кэша 32 МиБ. Все видимые карточки воспроизводятся; при прокрутке воспроизведение приостанавливается, за пределами экрана останавливается. Это похоже на GIF, но на деле представляет собой атлас кадров с альфа-каналом.

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

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

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

Исправленный редактор хранит стабильную копию черновика. Сначала завершается сохранение, затем родительская страница получает результат и закрывает преобразование и подробности через обратные вызовы закрытия. При отмене или ошибке сохранения введённое остаётся.

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

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

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

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

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

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