Ubuntu получит быстрый и масштабируемый сервис создания миниатюр.

Постоянно слыша в новостях об улучшениях и ускорениях в thumbnailer, я уже начал подтрунивать над бедным создателем-миниатюр, сравнивая его с ракетой. Оказалось всё настолько серьёзно, что прямо опешил. Мичи Хеннинг (Michi Henning) написал очень интересную статью в своем блоге, где он объясняет в деталях, как он, Джеймс Хенстридж (James Henstridge) и Хави Гарсия Мена (Xavi Garcia Mena), реализовали не просто локальный создатель-миниатюр, а целый комплекс-сервис.

В мобильном секторе, как и на десктопе, приложениям нужно отображать миниатюры различных медиа файлов, таких как фото, песни и видео. Создание таких миниатюр затратно с точки зрения ЦПУ и часто занимает пропускную способность сети, если требуется (к примеру) миниатюра удалённой картинки. Добавьте сюда, что различные типы медиа требуют различный API, а хотелось бы скрыть для сторонних разработчиков всю эту сложность, улучшив при этом быстродействие и обеспечив кэширование миниатюр на диске.

Требования.

Требования, выдвинутые разработчиками к системе:

• Ошибкоустойчивость. В случае аварии, реализация системы должна гарантировать целостность данных на диске. Это очень важно в телефонах, где не стоит ожидать от пользователя ручной уборки повреждённых файлов. Целостность данных должна обеспечиваться даже в условиях разряда батареи устройства.
• Масштабируемость. Обычное явление, когда у человека тысячи песен и фото в устройстве. Кэш миниатюр должен масштабироваться на десятки тысяч записей. Сама миниатюра можеть занимать от килобайт до мегабайт, поэтому кэш должен эффективно работать с большими данными.
• Повторное использование. Постоянное и надёжное хранение на диске определённого количества записей является частым требованием приложений. Но не хотелось бы создавать реализацию кэша специально для миниатюр. Вместо этого, кэш будет предоставлять stand-alone C++ API для различных вариантов использования, например для браузера, HTTP cache или ccache.
• Высокая производительность. Производительность создателя-миниатюр напрямую влияет на UX (user experience). Не приятно видеть "пожалуйста, ждите ...", к примеру, в Галерее изображений, пока иконки миниатюр по одной появляются на экране. Нужна высокопроизводительная реализация, которая извлекает миниатюры за миллисекунды на ARM CPU. Эффективная реализация сохранит так же срок службы батареи.
• Независимость от расположения и расширяемость. Canonical создала dash.ubuntu.com для размещения изображений альбомов и исполнителей. Данные графические материалы будут использованы, к примеру, если музыкальный проигрыватель не находит в медиа файле внедрённых изображений, а есть только ID теги. Thumbnailer должен работать с внедрёнными изображениями так же как и с удалёнными, с возможностью в будущем расширить свою работу над другими форматами медиа без глобальной переделки существующего кода.
• Низкое потребление сетевой полосы. У мобильных телефонов скорость по сети часто не велика. Реализация кэша должна это учитывать.
• Параллелизм и изоляция. Должен быть предоставлен одновременный доступ множеству приложений и множественный доступ из одного приложения. Нужно реализовать потокобезопасную (thread-safe) реализацию и это так же будет означать, что медленный запрос к миниатюре не будет мешать другим запросам.
• Отказоустойчивость. Мобильные устройства часто теряют связь без предупреждения и пользователи могут добавить повреждённые файлы к себе. Реализация должна быть устойчивой к временным отказам, таким как неполные ответы по сети, сброшенные соединения и плохие данные. Более того, стратегия восстановления должна учитывать понятие питание от батареи и избегать повторных запросов на создание миниатюр, которые не могут быть получены или содержат неверные данные.
• Безопасность. Реализация должна гарантировать, что приложения не видят, а что ещё хуже не перезатирают, эскизы друг друга. Не могут вынудить Thumbnailer дать эскиз к файлу, к которому у приложения нет доступа.
• Асинхронный API. Приложения QML или Qt, использующие thumbnailer, не должны блокировать свой UI thread, иначе будут выглядеть зависшими. Thumbnailer должен предоставлять неблокирующий API, что позволит не вынуждать разработчиков приложений порождать потоки.
• Мониторинг. Эффективность кэша нельзя оценить без статистических метрик, типа рейтингов попадания или промахов в кэш, вытеснения из кэша. Должен быть способ предоставления такой информации.
• Отчёт об ошибках. Если что-то идёт не так с системной службой, то обычно единственный способ узнать о проблеме глянуть журнал. Реализация сервиса должна оставить информационное сообщение в случае сбоя.
• Обратная совместимость. Данный проект перезаписал раннюю реализацию. Вместо "большого взрыва", данный проект плавно поддержал существующие приложения, чтобы они продолжили свою работу как обычно.

Архитектура системы.

Извлечение изображений.

Извлечение изображений не зависит от размещения медиа файла и его типа. Текущая реализация позволяет:

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

Извлечение изображений происходит асинхронно и имеет 3 реализации:

• Image downloader. Скачивание artwork с удалённого сервера, с поддержкой одновременного запуска множества запросов и легкостью добавления других поставщиков изображений.
• Photo extractor. Строит миниатюры из локальных файлов картинок типа JPEG или PNG. Основную работу делегирует конвертеру и масштабатору (scaler). Текущая реализация использует Gdk-Pixbuf и проверяет EXIF с помощью libexif.
• Audio and video thumbnail extractor. Для создания эскиза из аудио и видео файлов используется GStreamer. Для предотвращения каких-либо проблем с некоторыми кодеками, задача поручается отдельным vs-thumb. Этот щит vs-thumb защищает от сбоев и позволяет запускать GStreamer раздельно в несколько потоков, чтобы сбой одного не задевал другого.

Дисковый кэш.

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

Служба использует 3 кэша:

• Full-size cache. Здесь хранится изображение в оригинальном разрешении, которое "дорого" снова затребовать с источника. Если оригинал больше 1920px рамок, то его уменьшат до этих значений. По умолчанию размер данного кэша 50 мб, что позволяет вместить примерно 400 картинок 1920×1080. Изображения сохраняются в JPEG формате с настройкой качества 90%.
• Thumbnail cache. Данный кэш хранит эскизы, которые были запрошены, для примера 512×288px. По умолчанию размер данного кэша 100 мб, что позволяет вместить ~11000 эскизов 512×288 или ~25000 - 256×144. Изображения сохраняются в JPEG формате с настройкой качества 75%.
• Failure cache. Данный кэш хранит ключи к изображениям, которые не могли быть получены из-за проблем. Для изображений с удалённых серверов был получен авторитарный ответ о несуществующем файле или получен ответ DNS, что домен не существует и т.д. В отношении локальных изображений, могут быть проблемы из-за поврежденного оригинала или аудио файл не содержит внедрённый рисунок (embedded artwork).

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

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

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

Все кэши используют алгоритм Least recently used (LRU) при вытеснении старых записей.

Выводы.

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

Вот такой новый thumbnailer используется уже в проекте Ubuntu Phone (Touch) в приложениях Gallery, Camera, Music и областях (scope), которым требуются эскизы. Владельцы телефонов получат новшества в OTA-6.

Десктопные пользователи получат создатель-миниатюр в Ubuntu 15.10 Wily Werewolf.

Дата последней правки: 2023-12-27 15:31:37