Вы открыли четвёртую статью цикла, посвящённого необходимому минимуму технических знаний продуктового дизайнера. Ссылки на следующие и предыдущие посты будут в конце.
Речь на этот раз пойдёт о технологиях создания мобильных приложений. Я расскажу, какие они бывают и какие накладывают рамки на дизайн (или наоборот, способствуют его развитию).
Мобильные приложения
Итак, приложения бывают нативными и гибридными (их ещё называют кроссплатформенными). Нативные позволяют вытворять вообще всё, но писать их дольше и дороже – под каждую платформу, на своем языке. Гибридные пишутся один раз, а потом компилируются (собираются) под разные платформы.
Нативные
Нативные приложения пишутся отдельно для каждой платформы. Для iOS это языки Objective-C и Swift, для Android – Java и Kotlin. Приложения, созданные на таких технологиях, более надёжны и безопасны. Они напрямую обращаются к нативным функциям устройства: камере, отпечатку пальца или сканеру лица, микрофону и так далее.
За счёт этого процесс их создания иногда раза в полтора быстрее, чем гибридных. Однако это, вместе с тем, влечёт за собой некоторые особенности.
Например, если у вашего приложения одинаковый дизайн на обеих платформах, добиться идеального сходства будет непросто – ведь это совершенно разный код, который пишут разные люди. И если попиксельно всё может быть ровно, то вот с анимациями и микровзаимодействиями придётся попотеть. Если, конечно, оно вам надо.
Гибридные
В одной из предыдущих статей цикла (про фреймворки) я уже писал про фреймворки для кроссплатформенной разработки мобильных приложений. Теперь пришло время остановиться на них чуть поподробнее.
В отличии от нативных, гибридные приложения используют не-нативный код для своего выполнения. Например, вы можете собрать приложение вообще на другом языке программирования, на каком-нибудь Python'е. Или даже вообще на HTML+CSS+JS, как сайт.
В связи с тем, что между пользователем и нативным кодом самого устройства появляются вот такая "прослойка", гибридные приложения, как правило, более медленные. Сложная анимация в них не такая плавная, а доступ к некоторым нативным функциям может иногда подтупливать. Хотя, надо признаться, сейчас ситуация меняется в лучшую сторону.
При разработке гибридных приложений часто всё равно приходится писать нативный код – но уже сразу для обеих платформ.
Примеры
Вот вам пример из реальной практики.
Лет пять назад делали гибридное приложение на фреймворке Ionic в стиле Material Design. Как вы наверняка понимаете, в Material тени имеют ключевое значение, они формируют визуальную иерархию, "уровень" элементов.
Так вот главным экраном в том приложении был список вакансий. Довольно внушительный, надо сказать список. И у каждой вакансии было несколько вариантов теней. Когда пользователь долго скролил этот экран, приложение начинало сперва тупить, а потом и вовсе вылетало. Оказалось, что из-за особенностей фреймворка такое количество теней создавало серьёзную нагрузку на процессор и оперативную память смартфона.
Знали бы заранее – придумали бы немного другой дизайн или вовсе отказались бы от Material.
Итог
Если очень сильно упростить, то получается примерно такой расклад:
Нативные приложения:
- Быстрее разрабатываются и тестируются. За счёт того, что две команды работают параллельно. Но есть и исключения.
- Более надёжные и быстрые. Всё-таки они "ближе" к операционным системам, на которых работают.
Гибридные приложения:
- Дешевле в производстве. Просто потому что вам нужно одна команда, а не две. И пусть она даже будет работать чуть дольше, всё равно вы в итоге сильно экономите.
- Легче поддерживать и развивать (но это не точно). Для добавления новой фичи вам не нужно дёргать две команды. Однако с этим тоже не всё так просто: количество багов в гибридных, как правило, больше.
Работая над мобильным приложением, нужно понимать, что за технология ляжет в его основу – и это куда более важно, чем в случае с веб-приложениями. Понимание ограничений и преимуществ технологии позволит отказаться от каких-то сомнительных затей или наоборот, использовать всю мощь девайса.
Другие статьи в цикле
Если вы хотели бы почитать о чём-то техническом, но этого нет в цикле – пишите в комментариях. Буду дополнять.
- Фреймворки – что это такое и какие бывают.
--
Все свои посты я аккумулирую в небольшом телеграм-канале, подписывайтесь.
