Дизайнеру – о технологиях: мобильные приложения

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

Речь на этот раз пойдёт о технологиях создания мобильных приложений. Я расскажу, какие они бывают и какие накладывают рамки на дизайн (или наоборот, способствуют его развитию).

Мобильные приложения

Итак, приложения бывают нативными и гибридными (их ещё называют кроссплатформенными). Нативные позволяют вытворять вообще всё, но писать их дольше и дороже – под каждую платформу, на своем языке. Гибридные пишутся один раз, а потом компилируются (собираются) под разные платформы.

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

Нативные

Нативные приложения пишутся отдельно для каждой платформы. Для iOS это языки Objective-C и Swift, для Android – Java и Kotlin. Приложения, созданные на таких технологиях, более надёжны и безопасны. Они напрямую обращаются к нативным функциям устройства: камере, отпечатку пальца или сканеру лица, микрофону и так далее.

За счёт этого процесс их создания иногда раза в полтора быстрее, чем гибридных. Однако это, вместе с тем, влечёт за собой некоторые особенности.

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

Гибридные

В одной из предыдущих статей цикла (про фреймворки) я уже писал про фреймворки для кроссплатформенной разработки мобильных приложений. Теперь пришло время остановиться на них чуть поподробнее.

В отличии от нативных, гибридные приложения используют не-нативный код для своего выполнения. Например, вы можете собрать приложение вообще на другом языке программирования, на каком-нибудь Python'е. Или даже вообще на HTML+CSS+JS, как сайт.

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

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

Примеры

Вот вам пример из реальной практики.

Лет пять назад делали гибридное приложение на фреймворке Ionic в стиле Material Design. Как вы наверняка понимаете, в Material тени имеют ключевое значение, они формируют визуальную иерархию, "уровень" элементов.

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

Знали бы заранее – придумали бы немного другой дизайн или вовсе отказались бы от Material.

Итог

Если очень сильно упростить, то получается примерно такой расклад:

Нативные приложения:

• Быстрее разрабатываются и тестируются. За счёт того, что две команды работают параллельно. Но есть и исключения.
• Более надёжные и быстрые. Всё-таки они "ближе" к операционным системам, на которых работают.

Гибридные приложения:

• Дешевле в производстве. Просто потому что вам нужно одна команда, а не две. И пусть она даже будет работать чуть дольше, всё равно вы в итоге сильно экономите.
• Легче поддерживать и развивать (но это не точно). Для добавления новой фичи вам не нужно дёргать две команды. Однако с этим тоже не всё так просто: количество багов в гибридных, как правило, больше.

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

Другие статьи в цикле

Если вы хотели бы почитать о чём-то техническом, но этого нет в цикле – пишите в комментариях. Буду дополнять.

• Вводная статья цикла: зачем дизайнеру всё это.
• Фреймворки – что это такое и какие бывают.
• Коротко об управлении контентом: CMS и CMF.
• Об обмене данными, синхронных и асинхронных запросах.
• Что такое API и зачем об этом знать.
• Основы информационной безопасности в дизайне.
• Почему важно думать о SEO.

--

Все свои посты я аккумулирую в небольшом телеграм-канале, подписывайтесь.