Файл: Общая классификация языков программирования.pdf

Принимая во внимание выводы, сделанные выше, можно считать оправданным разделение приложения на бизнес-логику и интерфейс, где бизнес-логика является кроссплатформенной частью. К счастью, для подобного разделения есть несколько доступных решений. Например, язык C# широко используется в программировании для Windows и Web, а также имеет специальную интегрированную среду разработки (IDE) Xamarin для создания приложения для мобильных платформ Android и iOS. Кроме того, с недавнего времени, язык поддерживается на macOS и Unix. Иными словами, бизнес-логика, написанная на языке C#, может быть использована на всех популярных платформах, и, с помощью специальных средств разработки, подключена к родному интерфейсу системы.

Другим языком кроссплатформенного программирования является С++. Так как первая его версия была создана давно (относительно других языков, предлагаемых для разработки на современных платформах), то при выходе более новых языков программирования (Java, Objective-C, C#) создателям приходилось оставлять возможность подключения модулей на С++. Отчасти, это было вызвано тем, что при появлении этих языков большое количество алгоритмов уже были реализованы на С++. К тому же, язык С++ отличается лучшей производительностью, нежели языки с автоматической сборкой мусора, поэтому части программ, требующие высокой производительности, по-прежнему было необходимо разрабатывать на С++.

В результате, сейчас программный код на языке С++ можно использовать на любой популярной платформе, в сочетании с другим языком программирования. Для Windows и Unix это осуществляется через динамически подключаемые библиотеки (.dll и .so), для Android с помощью технологии Java Native Interface (JNI), а для macOS и iOS компилятор языка Objective-C полностью поддерживает компиляцию языка С++. А новый язык Swift для разработки для платформ macOS и iOS поддерживает связь с языком Objective-C. Для подключения С++ к языку JavaScript есть несколько возможных вариантов - инструменты Emscripten и WebAssembly, позволяющие кросскомпилировать язык С++ в JavaScript и родные расширения для Node.js (Native Addons).^[10]

В качестве примера кроссплатформенного использования языка С++ можно привести алгоритмы кодирования и декодирования мультимедиа (JPEG, mp3, ffmpeg), реализованные на языке С++, которые используются почти ежедневно любым человеком, работающим с компьютером.

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

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

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

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

2.4. Выбор средств реализации пользовательского интерфейса

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

Можно выделить 3 основных технологии реализации пользовательского интерфейса:

A. Использование родных для платформы графических элементов.

B. Использование языка JavaScript и технологий HTML и CSS. Для краткости будем их далее называть JavaScript-технологиями.

C. Использование промежуточного графического движка, заменяющего родные графические средства (OpenGL, FireMonkey, Qt).

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

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

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

Использование промежуточного графического движка, в первую очередь, востребовано в приложениях, в которых присутствуют сложные графические объекты, с элементами движения и наличием слоев. В частности, хорошо подходит для подобных целей библиотека OpenGL. Использование же подобных движков для написания общего пользовательского интерфейса хотя и решает задачу переносимости, делает интерфейс приложений непохожим на родной интерфейс устройства. Разработчикам промежуточных движков приходится постоянно успевать за разработчиками операционных систем, реализующих всё новые и новые возможности. Чаще всего поддержка новых функций в промежуточный слой включается с заметным опозданием. Всё это может значительно усложнить разработку и сделать приложение, полностью написанное с использованием промежуточного движка, менее конкурентноспособным.

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

Можно дать следующие рекомендации по средствам для реализации пользовательского интерфейса.

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

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

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

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

2.5. Оценка практического опыта реализации кроссплатформенных приложений

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

Первый опыт применения кроссплатформенных технологий получен при создании мобильного приложения «Шахматная Планета» для платформы Android в 2011 году. Он заключался в применении веб-технологий для создания пользовательского интерфейса приложения. Бизнес- логика была реализована родными средствами на языке Java. В качестве достоинства выбранного подхода следует отметить, что процесс разработки шел относительно быстро, потому что у команды был опыт работы с веб-технологиями, а приложение для Android создавалось впервые, и родные технологии создания интерфейса не были хорошо освоены. Также веб-технологии хорошо себя зарекомендовали для реализации элементов интерфейса, с низким уровнем взаимодействия с пользователем. То есть, те элементы, которые нужны для отображения информации, а не для взаимодействия. Например, в приложени есть элемент «Нотация», необходимый для отображения ходов в шахматной партии, его реализация через веб-технологии не вызывает неудобства у пользователя. Совершенно противоположная ситуация возникла с элементом «Шахматная доска» - пользователю необходимо быстро получать реакцию на свои действия. Например, при игре на время или при перемещении фигуры. Реализация этого элемента с использованием веб-технологий плохо показала себя в плане производительности, после чего данный элемент был сделан с использованием родных средств.

В процессе разработки были выявлены и следующие неудобства:^[11]

1) Основной проблемой стала скорость работы и отзывчивость интерфейса на действия пользователя.

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

2) Другой проблемой стало динамическое изменение информации в процессе работы. При необходимости обновить какой-либо элемент интерфейса, нужно вызывать функции JavaScript программно через веб - терминал (консоль). При изменении нескольких элементов или области большого размера, пользователю были видны различные артефакты. Например, при отображении информации в виде списка, если необходимо добавить элемент в начало, то все последующие необходимо сдвинуть, что происходит заметными скачками.

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

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

Большой опыт кроссплатформенного программирования был получен при создании в 2014 году приложения «Таблицы Ломоносова», используемого для доступа через сервер к таблицам семифигурных шахматных окончаний. У приложения есть реализации для платформ Android, iOS, Web и Windows. В таблицах шахматных окончаний хранятся точные оценки (ничья или выигрыш/проигрыш в указанное число ходов) всех позиций с семью и меньшим количеством шахматных фигур. Особая сложность возникает из-за того, что финальный размер файлов таблиц составляет более 100 терабайт, из-за чего их невозможно предоставить в полном объеме для локального доступа обычным пользователям. Поэтому было принято решение, что часть таблиц может использоваться локально, а часть удаленно через веб-сервер.