Украинская команда запустила сервис, который вчетверо ускоряет загрузку картинок в мобильных приложениях
Украинский стартап Pixpie разработал технологию, которая ускоряет загрузку изображений в мобильных приложениях примерно в четыре раза. На днях выпустили «коробочную» версию сервиса, который ставится на оборудовании компаний, но вскоре команда обещает и бету облачной версии. Те, кто хочет ее протестировать, могут записаться в список на сайте компании. До конца года в Pixpie планируют добавить также оптимизацию аудио и видео.
Стартап начал работу в Киеве в октябре 2015 года. Его основатели — Дмитрий Осипа, Владимир Усыченко и Валерий Горячкин. В середине апреля этого года представители Deutsche Telekom и польского бизнес-акселератора hub:raum выбрали команду Pixpie победителем акселерационной программы miniWARP Ukraine.
Сервис ориентирован на B2B, среди потенциальных клиентов команда видит как разработчиков отдельных приложений, так и мобильных операторов. К примеру, телеком-оператору может понадобиться оптимизировать мобильный трафик на больших мероприятиях или же для безлимитных предложений (например, украинские операторы не тарифицируют 3G-трафик для соцсетей).
Среди первых клиентов стартапа — третья по величине в Украине IT-компания Luxoft. В рамках интеграции с ее приложением команда тестировала сервис: 10 000 загружаемых картинок до оптимизации весили 2,1 ГБ, после нее — 0,3 ГБ. Это больше, чем вчетверо, но в выборке были очень различные изображения — как по несколько КБ, так и до 10 МБ.
Сервис работает так: разработчик добавляет SDK в свое мобильное приложение, SDK анализирует параметры мобильного устройства (разрешение экрана, интернет-соединение, контекст, в котором отображается картинка) и запрашивает оптимизированную версию с CDN сервиса.
Для примера: на сервере загружен аватар пользователя 1000х1000 пикселей, но при этом на экране iPhone 6 он будет отображаться в блоке размером 200×200, а значит, его можно оптимизировать. Если подключится другой девайс (например, Nexus 5), на котором этот же аватар будет 150×150 пикселей, то будет подготовлена версия еще и под него.
«Плюс к этому всему мы используем WebP и экспериментируем с BPG для картинок. То есть, при том же размере и качестве мы экономим еще где-то до 30% по сравнению с jpeg или png», — рассказывает Дмитрий.
Сейчас сервис Pixpie поддерживает оптимизацию на iOS-устройствах, а в мае запланирован выпуск бета-версии для Android.
Напомним, ранее мы писали о проекте Pibox, который делает одноименный облачный мессенджер. Основное отличие этого сервиса от других подобных – возможность пересылать тяжелые файлы любого веса.
Комментарии | 30
Для примера: на сервере загружен аватар пользователя 1000х1000 пикселей, но при этом на экране iPhone 6 он будет отображаться в блоке размером 200×200, а значит, его можно оптимизировать.
Далек от мобильной разработки, но получается, что всегда загружается 1000х1000 картинка, даже на привью? Частенько видел 2-х метровые фото на сайтах, которые потом width, height = 100px, думал это осталось далеко в прошлом, но оказывается, что нет)
Это пример скорее для наглядности.
В среднем, при разработке делают где-то /- 3-4 версии изображения и thumbnail. Но наше преимущество в том, что мы делаем гораздо большее количество нарезок: под все DPI, разрешения экранов и типы устройств(телефон, планшет). А за счет использования нестандартных форматов для хранения данных, картинки еще где-то на 30-40% процентов меньше их аналогов. А если сравнивать с двухмегабайтными оригиналами, то в десятки раз 😀
Еще мы делаем дополнительное сжатие(с потерей качества) при плохом интернет соединении, потому картинки всегда грузятся быстро, а их содержимое остается хорошо различимым 🙂
Не вижу ничего сверх нового, реально такое можно собрать самому. Возможно это будет востребовано, не знаю. В любом случае удачи.
Спасибо, Александр! Оптимизация медиа-контента — это большой объем работы, который иногда затягивается на несколько месяцев. И не факт, что в конце получится достичь такого же результата. Поэтому мы и создаем инструмент для мобильных разработчиков, мгновенно решающий эту проблему.
Собери
Ок
Решение будет востребовано, хоть по описанию похоже на простое решение в лоб для незадачливых аутсорсеров, которые изначально не заморачиваются оптимизацией.
В целом, подобное делается на коленке за пол часа-час (ios/swift + node.js с quickthumb + кеширующий nginx), если кроме пережитки и кеширования не делать что-то более интеллектуальное.
Будут ли пользоваться если выглядит все просто? Да, ибо обычно в проекте нету времени на «поиграться с форматами и разрешениями», проще подключить сервис за вменяемую стоимость.
Ребята молодцы, востребованный, нишевый и простой продукт. Проблема только в легком копировании
Когда мы засели делать Pixpie, нам тоже показалось что на коленке за полчаса. Не буду описывать все нюансы и проблемы, с которыми мы столкнулись, но некоторые из интересных задач, это поиск и масштабирование.
Да, ещё фикс webp-либы под iOS, так как она «течет».
Сейчас готовим докер-контейнеры, что бы при разворачивании на стороне клиента всё поднималось за 5 минут.
+ 5 минут на интеграцию SDK на мобильной стороне.
В «на коленке за пол часа» ключевое было: «не делать что-то более интеллектуальное».
Там почвы для копания рыть не перекрыть.
Кстати, а насколько iOS пакет раздувается с вашим SDK против?
У нас очень легкое мобильное SDK: где-то 1.4 мб, против 6.8 мб у той же Гугл Аналитики, основная обработка и подготовка контента производится со стороны сервера. Соответственно, аппсторовский бинарник после интеграции нашей либы вырастет очень незначительно.
а можно поподробнее про подтекание webp? А то мы юзаем у себя в проекте, вроде не замечали hiboo.co
На самом деле, там враппер на Obj-C для нее тек(один из популярных). Пришлось свой сделать
https://github.com/seanooi/iOS-WebP или https://github.com/rs/SDWebImage ?
Первая. Экстеншен Веб для второй вроде тоже на ней базируется
жаль, что pull request не отправили
как руки дойдут – обязательно отправим)
Это правильно, удачи 🙂
Интересно было бы протестить на Этом веб-сайта http://impulse-design.com.ua/
а что насчет cdn, частоты апдейтов и антидос
На текущий момент мы тестируем наше cloud-решение, которое включает в себя существующий CDN.
Вероятно, могло сложится неверное мнение: мы не разработали новый CDN, если говорить точнее, наш сервис можно поставить поверх любого CDN(если он у вас уже есть, или мы поможем помочь подобрать, если разработка с нуля), при этом решение будет прибавлять ускорение к тому, что даёт CDN изначально.
Антидос можно взять у любой компании, которая специализируется именно на этом, наше решение без проблем интегрируется с любым CDN и системой защиты от DDoS(можно совместить CDN + Anti DDoS).
Я тогда если честно не понимаю что конкретно сделали вы на проекте? написать динамик конвертер не трабл. я даже больше скажу писали и динамик конвертер для видео в риалтайме и ок(ну сложновато немного, но впринципе за недельку вдвоем реально все поднять).
Я к тому, что в чем у вас защита перед тем что вот завтра какойто дядя возьмет и сделает точно тоже(технологически это не сложно). А у дяди может быть денег намного больше. В итоге это довольно большой риск для вас. Посему интересно как вы думаете от него защищаться и думаете ли?
Спасибо
«Я к тому, что в чем у вас защита перед тем что вот завтра какойто дядя возьмет и сделает точно тоже(технологически это не сложно).»
Технологически можно сделать прототип фейсбука с урезанным функционалом за пару недель, это действительно не сложно.
У нас есть определенные конкурентные преимущества внутри самой технологии, которые мы не разглашаем и которые, в свою очередь, являются killer-фичей.
Могу сказать что мы не стоим на месте и тестируем возможность использования machine learning-a для оценки потенциальной степени сжатия.
Картинка обычная, в ней нет ничего ужасного.
ФБ сложно очень сделать ибо там очень много всего как в юай так и бекенда. Можно сделать Твиттер по быстрому это да.
Но суть в том что Твиттер и ФБ уже гиганты и их врядли задавят, вы же начинающий стартап с урезанным финансированием. И вас задавить легко.
Про машин лернинг. Я конечно понимаю что сейчас тренд и все такое. Но будьте акуратней с такими высказываниями.
Что касаеться киллер фичи, то на мой взгляд этто разве что уникальный протокол сжатия, который может сжимать лучше остальных.
Еще рекомендую пообщаться с Лизой https://www.facebook.com/lis.dziuba из проекта Flawless вы в одном ключе работаете, сотрудничество может быть полезным.
Вообщем успехов, но киллер фичу пилите быстрее.
Спасибо.
Мы работаем над оптимизацией и networking уровня. В случае с on-prem решением у нас есть гораздо больше гибкости и мы экспериментируем с модификацией nginx, что бы выжать из него больше перформанса.
Более того, я дам схему для «дяди», из одной из наших презентаций:
Как этот функционал будет интегрирован с библиотеками для загрузки изображений (Glide, Picasso) под Android?
Пока мы делаем форк Glide, прикручивая к нему наше АПИ
Какой метрикой сравнивали качество JPEG и WebP?
При правильном сочетании дожатия и постобработки JPEG обеспечивает лучшую степень сжатия при одинаковом качестве, чем JPEG2000 и WebP.
Да, возможно, это так и есть. Но:
1. Каковы потери качества вследствии «дожатия» и постобработки?
2. В каком проценте случаев это оказывается лучше webp? 🙂
На самом деле, мы ориентировались на
https://developers.google.com/speed/webp/docs/webp_study#experiment_2_ssim_vs_bpp_plots_for_webp_and_jpeg
Со своей стороны делали замеры размера файла для jpg, png Vs WebP с одинаковыми значениями качества. SSIM пока не считали и ориентировались на стади Гугла, но, я думаю, что в ближайшее время сделаем на данных какого-нибудь бета-кастомера. Это было бы интересно для первого поста в наш бложик.