EN

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

15170
30

Украинский стартап 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), если кроме пережитки и кеширования не делать что-то более интеллектуальное.
    Будут ли пользоваться если выглядит все просто? Да, ибо обычно в проекте нету времени на «поиграться с форматами и разрешениями», проще подключить сервис за вменяемую стоимость.
    Ребята молодцы, востребованный, нишевый и простой продукт. Проблема только в легком копировании

  • а что насчет 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?

  • Какой метрикой сравнивали качество JPEG и WebP?
    При правильном сочетании дожатия и постобработки JPEG обеспечивает лучшую степень сжатия при одинаковом качестве, чем JPEG2000 и WebP.

Последние новости
19 сен
Смотреть все
  • Истории компаний
  • НДС для Facebook и Netflix
  • Расследования AIN.UA
  • Спецпроекты
  • Безопасность номера
  • Безпека гаманця
Реклама на AIN.UA

Поиск