Напишите один раз, разверните везде: когда переходить на натив?

Написать один раз, развернуть везде (WODE) было обещанием многих сред разработки за последнее десятилетие, цель которых — облегчить боль при написании нескольких собственных приложений. Определение того, какой путь выбрать, является одним из наиболее важных решений, которое должен принять руководитель проекта, из-за его высокой начальной стоимости, влияния на команду разработчиков и потенциальной невозможности отменить.

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

Однако в последнее время даже термин «нативный» затуманен фреймворками, которые компилируются в нативный код (например, React Native, Xamarin и т. д.).

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

Напишите один раз, внедряйте везде

Концепция Write Once, Deploy Everywhere относится к способности команды разработчиков написать приложение один раз, используя единый стек разработки, абстрагированный от платформ, на которых будет развернуто приложение, и при этом поддерживать возможность развертывания. приложение для всех желаемых платформ, например Android, iOS, Windows и т. д. В идеале это достигается без ущерба для удобства сопровождения, производительности или взаимодействия с пользователем (UX).

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

В целом, факторы, которые следует учитывать при выборе пути развития, включают:

• Возраст проекта
• Состав и размер команды разработчиков
• Желаемая платформа(ы) для распространения
• Требуемые сроки выхода на рынок
• Доступная пропускная способность для перехода на другой путь, если необходимо

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

На высоком уровне различные пути мобильной разработки можно разделить на две категории: нативные или WODE, т. е. нативные или все остальное. Проще говоря, либо пишут собственное приложение, либо нет. Категория WODE далее разбита на две группы:

• Гибридные фреймворки — те, которые используют веб-технологии для рендеринга приложений на нескольких платформах.
• Негибридные фреймворки — те, которые используют собственные компоненты пользовательского интерфейса (например, кнопки, текстовые поля и даже менеджеры компоновки) вместо рендеринга веб-представления внутри приложения, как это делают гибридные фреймворки.

Большинство фреймворков WODE являются гибридными ; однако, чтобы улучшить как производительность, так и ограничения UX гибридных фреймворков, сохраняя при этом преимущества фреймворка WODE, текущая тенденция направлена ​​на негибридный . Благодаря этой тенденции набирают популярность такие фреймворки, как React Native, Xamarin и Appcelerator.

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

В целом применима поговорка « вы получаете то, за что платите », поэтому, если стоимость важнее, чем качество обслуживания клиентов, нативный интерфейс может оказаться неправильным выбором. Однако, как только UX становится жизненно важным, нативные приложения становятся очевидным выбором, поскольку для улучшения UX приложения на основе WODE несут значительные затраты в виде времени или собственного опыта, что противоречит цели выбора неродного приложения. пути развития в первую очередь.

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

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

Нативные приложения написаны на основном языке данной платформы. Например, приложения для Android написаны на Java, а приложения для iOS — на Obj-C или Swift. Они требуют от инженера-разработчика понимания языка, а также нюансов, специфичных для платформы, которые включают, например, интеграцию сторонних пакетов, управление компоновкой, взаимодействие с операционной системой (ОС) и так далее.

Плюсы

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

Простое доказательство этой идеи можно найти, просмотрев сообщества поддержки для данной платформы. Можно найти множество примеров того, как выполнить задачу, которая может быть «неоговорочной», несмотря на ограничения лежащих в основе фреймворков.

Конкретным примером такой, казалось бы, простой задачи для iOS может быть отображение полноэкранного наложения поверх всех внешних элементов пользовательского интерфейса, например панели вкладок, панели навигации и т. д. Как показано на рис. 1 , обычно это выходит за рамки в настоящее время представлен обычный слой пользовательского интерфейса. Таким образом, для полноэкранного наложения его необходимо добавить в скрытый слой над панелью вкладок в стеке просмотра. Такая настройка обычно возможна только в собственных приложениях.

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

Самый ремонтопригодный . Операционные системы постоянно меняются. Период. Когда они это делают, в зависимости от того, были ли внесены критические изменения, приложение должно своевременно обновляться, чтобы не потерять часть пользовательской базы, которая обновляется до более новой ОС. Очевидно, что чем меньше времени проходит между тем, когда изменение становится доступным для пользователей, и обновлением приложения, тем лучше. Это время сводится к минимуму, когда нет зависимостей, которые необходимо обновить для поддержки этой новой ОС, что имеет место при работе над собственным приложением.

Минусы

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

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

Низкая производительность . Может показаться странным иметь производительность как плюс, так и минус. С одной стороны, нативные приложения дают разработчику достаточно места для создания точно настроенного высокопроизводительного приложения. С другой стороны, однако, они также дают разработчику достаточно веревки, чтобы повеситься. Если они не знают, что делают, в конце концов, в лучшем случае они получат некачественное приложение.

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

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

Гибридные приложения обычно пишутся с использованием HTML/CSS/LESS для разработки пользовательского интерфейса: буква «V» в шаблоне проектирования MVC. Затем «C» или контроллер обычно пишется на JavaScript — в идеале с использованием инфраструктуры JavaScript MVC, такой как AngularJS. Использование такой структуры, как AngularJS, позволяет лучше разделить классы и обязанности, чем это обычно возможно при использовании только jQuery.

Примером этого типа стека гибридных фреймворков может быть уровень представления Ionic, поддерживаемый AngularJS, который в конечном итоге преобразуется и отображается в веб-представлении на желаемой платформе с использованием PhoneGap и Cordova. Очевидно, что этот тип структуры WODE достигается за счет дополнительной сложности.

Кроме того, использование JavaScript влечет за собой собственные ограничения, связанные с дизайном, и проблемы, связанные с языком. Цель этой статьи не в том, чтобы обсудить достоинства или недостатки какого-либо одного языка; однако, как руководитель проекта, выбор использования JavaScript в своем мобильном техническом стеке не должен быть легким. Ниже приведены лишь несколько примеров хорошо написанных статей о том, почему следует по возможности избегать использования JavaScript:

• Проблема JavaScript
  
• Почему я не являюсь разработчиком React Native

Плюсы

Минимальная команда разработчиков . Гибридные фреймворки позволяют небольшой группе разработчиков, особенно той, чья основная база знаний связана с веб-разработкой, быстро создавать простые приложения для различных платформ. Это позволяет руководителю проекта сохранить свою команду небольшой, а также избавляет его команду от необходимости изучать родные языки и фреймворки для нескольких платформ.

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

Минусы

Потенциально плохой UX . Недостатком необходимости писать только один слой представления является то, что остается один слой представления. Это может привести к плохому UX, поскольку универсальный подход к дизайну пользовательского интерфейса не может придать приложению удобный и знакомый пользователям на всех платформах внешний вид. Кроме того, поскольку гибридные приложения по сути представляют собой веб-просмотр, встроенный в пользовательский интерфейс, у пользователей может создаться впечатление, что они на самом деле просматривают веб-страницу, а не взаимодействуют с собственным приложением. Этот опыт почти всегда оказывает негативное влияние на удовлетворенность пользователей и, в конечном итоге, на их удержание.

Дорогой в настройке . Улучшение UX путем разработки настраиваемых пользовательских интерфейсов для каждой платформы приводит к созданию сложных и уникальных фреймворков пользовательского интерфейса, создание которых может быть дорогостоящим и сложным в обслуживании с течением времени. Кроме того, для создания элементов пользовательского интерфейса, которые помогут выделить приложение (например, анимация, настраиваемые представления и т. д.), необходимо создать настраиваемые компоненты моста, чтобы преобразовать высокоуровневый дизайн пользовательского интерфейса во что-то, что будет доступно инфраструктуре более низкого уровня. , такие как Cordova, поймут. В целом, чем больше пользователь настраивает и улучшает UX гибридного приложения, тем больше уменьшается преимущество быстрого и недорогого цикла проектирования.

Более низкая производительность . Поскольку гибридные приложения отображают представления приложения в веб-представлении, существует большая вероятность ошибок реализации при работе с платформами ОС (например, сетью, Bluetooth, контактами на устройстве и т. д.), что приводит к значительному снижению производительности. Стоит также отметить, что даже если уделять большое внимание производительности, поскольку все отображается через веб-просмотр, максимальная производительность гибридных приложений всегда будет немного меньше, чем у их родных аналогов.

Нетривиальное управление плагинами . Помните те пользовательские функции, на полировку которых команда дизайнеров потратила недели, а затем еще несколько недель, пока команда разработчиков создавала необходимые компоненты моста, чтобы Cordova могла с ними работать? Что ж, они не будут работать, если не будет поддерживающего плагина Cordova для того, чего пытается достичь команда. Это означает одно из двух: либо команда создает его сама, либо необходимо найти подходящий сторонний плагин, который выполняет эту работу. К сожалению, чаще всего второго варианта не существует. В результате требуется дополнительное время на разработку для создания пользовательских подключаемых модулей, за которыми следуют усилия по поддержке сборки — с течением времени — для управления растущей библиотекой подключаемых модулей Cordova, необходимых приложению. Конечно, когда происходят обновления Cordova, высока вероятность того, что эти плагины также необходимо будет обновить.

Отставание поддержки ОС . Вышеупомянутая проблема с каскадным компонентом моста/плагином Cordova еще более усугубляется, когда ОС изменяет базовую функциональность. После того, как Cordova, PhoneGap и Ionic будут обновлены для поддержки изменений, возможно, потребуется также обновить пользовательские плагины и компоненты моста. Независимо от порядка величины этой работы, это приводит к дополнительному времени, в течение которого приложение не поддерживает конечных пользователей, обновившихся до новой ОС. Это, конечно, наихудший сценарий, когда Apple или Google вносят критические, несовместимые с предыдущими версиями изменения, чего никогда не происходит… верно? В общем, любая промежуточная структура, которая находится вне контроля разработчика и которую необходимо обновить в первую очередь, только задерживает процесс. Наконец, полагаться на промежуточную структуру может быть головной болью для менеджеров проектов при планировании, поскольку сроки этих сред неизвестны.

Негибридные приложения

Негибридные приложения начинают свою жизнь так же, как и их гибридные аналоги — уровень пользовательского интерфейса, разработанный на неродном языке платформы: React Native использует HTML/CSS, поддерживаемый JavaScript или Xamarin, который основан на C# из-за его корней .NET.

Однако на этом сходство заканчивается. Негибридные приложения компилируются в собственный код и визуализируют приложение с использованием собственных компонентов платформы, а не через веб-представление. В результате получается структура WODE, которая, по крайней мере на первый взгляд, сочетает в себе лучшее из обоих миров.

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

Плюсы

Более высокая производительность, чем у гибридов . Как и следовало ожидать, негибридные приложения по своей природе имеют более высокую производительность, чем гибридные приложения, благодаря их способности отображать приложение с использованием собственных компонентов пользовательского интерфейса (кнопок, представлений, менеджеров компоновки и т. д.) вместо того, чтобы полагаться на встроенное веб-представление. Конечно, разработчики по-прежнему вольны написать приложение, которое работает замечательно или ужасно. Преимущество негибридных приложений заключается просто в том, что они имеют более высокую базовую производительность по сравнению с аналогичными гибридными приложениями.

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

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

Более быстрые итерации (React) . Фреймворк React предоставляет мощную функцию, которая позволяет отображать изменения в приложении в режиме реального времени: нет необходимости перекомпилировать, перестраивать и т. д. В результате эмулятор React является невероятно мощным инструментом разработки, который значительно сокращает продолжительность каждой реализации. цикл.

Минусы

Дорогой в настройке . Как и в случае с гибридным аналогом, когда негибридные приложения требуют улучшения UX путем разработки настраиваемых пользовательских интерфейсов для каждой платформы, это приводит к созданию сложных и уникальных компонентов пользовательского интерфейса, создание которых может быть дорогостоящим и трудным в обслуживании с течением времени. Это также означает написание настраиваемых компонентов моста для восполнения пробелов в поддержке собственных элементов фреймворка. Подобно гибридам, эта стоимость снижает преимущества быстрого и недорогого цикла проектирования, но, в отличие от гибридных приложений, компоненты моста пишутся для каждой желаемой платформы на их родном языке . Это означает, что вместо того, чтобы негибридные приложения были гибкой альтернативой команде, состоящей в основном из веб-разработчиков, команды, выбирающие негибридный путь, должны изучать не только конкретный язык фреймворка (например, JSX или C#), но и также родной язык каждой платформы (Java, Obj-C или Swift).

Сторонние зависимости . Это ограничение принимает две различные формы. В случае React Native это принимает форму многочисленных зависимостей, т. е. примерно 650. В результате существует очень большая вероятность того, что в любой конкретный момент времени одна или несколько из этих зависимостей устарели. Это также означает, что в случае значительного изменения уровня ОС существует высокая вероятность того, что большинство или все эти зависимости необходимо будет обновить. Потенциальная экономия заключается в том, что Facebook использует React, поэтому у каждого будет 300-фунтовая горилла в углу.

В случае с Xamarin проблема сторонних зависимостей заключается просто в том, что их крайне сложно интегрировать в первую очередь. Xamarin знает об этой проблеме и предоставляет утилиту под названием Sharpie. Цель инструмента — помочь с некоторой интеграцией, но, к сожалению, Sharpie часто пытается скомпилировать и связать неверные ресурсы, что вынуждает разработчика выполнять кропотливую и трудоемкую задачу по ручному изменению низкоуровневых параметров компиляции для успешного завершения. интеграция.

Отставание поддержки ОС . Негибридные приложения страдают от той же проблемы, что и гибридные. Любая промежуточная структура, которая находится вне контроля разработчика и которую необходимо обновить в первую очередь, только задерживает процесс обновления приложения для поддержки передовых пользователей. Кроме того, как указывалось ранее, полагаться на промежуточную структуру может быть головной болью для менеджеров проектов при планировании, поскольку сроки этих сред неизвестны.

Долгосрочная поддержка (React Native) . Эта проблема характерна для React Native и связана с тем странным фактом, что на сегодняшний день Facebook не принял долгосрочного плана поддержки своего фреймворка. Можно сказать, что это низкий риск, поскольку компания использует собственную структуру для своих мобильных приложений, но любому менеджеру проекта стоит задуматься, почему Facebook отказался комментировать эту тему.

Выбор правильного подхода

Когда стоимость не является главным соображением, рис. 2 показывает, что написание нативных приложений почти всегда является лучшим выбором при использовании состава команды разработчиков в соответствии с требованиями приложения. Когда инженеров-разработчиков меньше, чем желаемых платформ, становится немного интереснее. В этом случае использование React — правильный выбор, если у команды очень плотный график выпуска; в противном случае переход на исходный код по-прежнему является лучшим вариантом.

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

Однако, если пользовательский UX не требуется, то, в зависимости от графика выпуска, может быть лучше использовать Ionic или React. Если у вашей команды нет времени на изучение JSX, то Ionic — правильный выбор. В противном случае лучше выбрать React, так как он уже требует множества сторонних зависимостей, а добавление дополнительных не повлияет на цикл разработки.

Как только стоимость проекта становится основной проблемой, как правило, существующий состав команды становится менее приоритетным, поскольку первым шагом будет создание надлежащей команды для выполнения плана проекта с прогнозируемой стоимостью. Как показано на рисунке 3 , нативные приложения имеют более высокую начальную стоимость, чем их аналоги WODE, но также и более высокий потенциальный UX. Более того, приложения WODE всегда будут ограничены в своем UX, независимо от того, сколько денег и ресурсов вложено в проект.

Я надеюсь, что эта статья пролила свет на плюсы и минусы различных путей мобильной разработки, а также помогла сопоставить состав команды с требованиями приложения и стоимостью проекта. Его идея заключалась не в том, чтобы сообщить, что фреймворки WODE хуже и их никогда не следует искать, а скорее в том, что, несмотря на то, что существуют допустимые варианты использования для отказа от нативного использования, следует полностью понимать последствия этого.