Файл: Эволюция языков программирования.pdf

Из недостатков, в первую очередь, отметим, что язык 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 терабайт, из-за чего их невозможно предоставить в полном объеме для локального доступа обычным пользователям. Поэтому было принято решение, что часть таблиц может использоваться локально, а часть удаленно через веб-сервер.

Шахматные таблицы хранятся в особом формате, алгоритм чтения которого был реализован на языке С++. Алгоритм был подключен к родным приложениям для платформ разработки Android, iOS и Windows, а также к веб-серверу для удаленного доступа. При этом, приложение для Android было реализовано на языке Java, для iOS на Objective-C, для Windows на Delphi, а веб-сервер на C#. Подключение кроссплатформенного модуля к родному приложению для Android было реализовано с помощью технологии JNI, для iOS - Objective-C++, для Windows код на языке С++ был скомпилирован в виде dll библиотеки и подключен к программе на языке Delphi с помощью метода статического связывания, и к веб-серверу на языке C# с помощью метода динамического связывания. Приложения могли работать как с локальными файлами таблиц, так и с веб-сервером, протокол общения с которым был реализован с использованием формата XML. Таким образом, приложение «Таблицы Ломоносова» получило наибольшее количество реализаций для нескольких платформ и подтвердило оправданность использования языка С++ в качестве базового для кроссплатформенной части проекта.

Другим примером является шахматная обучающая программа «Пешка», имеющая реализации для платформ Android, iOS, Web и Windows. Программа предоставляет пользователю возможность решать шахматные задачи, а также читать теоретические уроки в удобном интерактивном виде. База задач и уроков хранится в программе в особом формате cke. Алгоритм чтения этого формата реализован на языке С++, а визуальное представление - с помощью родных средств для каждой платформы. Технология подключения кроссплатформенного модуля к родным приложениям такая же, что и при локальном доступе к файлам в «Таблицах Ломоносова». Но показательным примером использования кроссплатформенного кода в этой программе является компонент "XMLPlayer". Данный компонент предоставляет возможность разыгрывания обучающих сценариев по шахматной партии. В его функции входит: автоматическое проигрывание ходов в партии, запрос правильного хода в позиции, отображение подсказок при ошибках, подсчет набранных очков, разыгрывание нескольких вариантов ходов в партии. Все эти функции требуют показа информации пользователю, а некоторые (вопросы) еще и непосредственного взаимодействия.

Получается, что необходимо реализовать механизм асинхронного общения кроссплатформенного модуля с программным кодом на родных средствах. Данная задача была решена путем введения протокола общения между модулями и стандартизации интерфейсов доступа к ним. При необходимости отображения инфрмации, XMLPlayer вызывает метод интерфейса в реализации визуальной части. А при получении ответа от пользователя, визуальная часть вызывает необходимый метод XMLPlayer. Таким образом, визуальная часть была реализована отдельно для платформ Android, iOS, Web и Windows, но все реализации работают с кроссплатформенной реализацией XMLPlayer.

Кроссплатформенные средства также были использованы в веб-приложении «Игровая зона Chess King», с помощью них была реализована игра в шахматы против компьютера. Алгоритм игры в шахматы написан на языке C++ и используется в приложениях для платформ Android и iOS с использованием технологий, описанных выше. Чтобы подключить его к веб-приложению был использован инструмент Emscripten, также известный как WebAssembly, являющийся кросс - компилятором языка C++ в подмножество языка JavaScript. Для вызова функций, реализованных на C++, из кода на языке JavaScript, необходимо добавить в C++ проект отдельный модуль с перечислением внешних функций, никаких особых преобразований в коде C++ при этом делать не нужно. Единственной проблемой такого способа является высокая сложность отладки полученного веб-модуля, потому что он является результатом автоматического преобразования программы на языке C++.

Также к кроссплатформенным технологиям можно отнести вынесение части бизнес-логики программы на сторону сервера. Причем, благодаря единому стандарту доступа к веб-приложениям, реализацию программы можно делать практически на любом языке программирования. Эту особенность можно использовать для подключения готовой кодовой базы команды программистов, написанной на другом языке программирования. Например, в веб-приложении «Игровая зона Chess King» используются модули, написанные на языке Delphi, использовавшиеся в более ранних продуктах. Одним модулем является "Игровая компонента", реализующая алгоритм онлайн-игры в шахматы двух соперников. Общение с "Игровой компонентой" реализуется через веб-сокеты, а информация передается в формате JSON.

Другим модулем, реализованным на языке Delphi, является алгоритм жеребьевки игроков турнира по швейцарской системе. Алгоритм был реализован на языке Delphi много лет назад, и активно используется в программе "Шахматная Планета". Так как в нем довольно много тонких моментов, а программа использует много особенностей языка и информацию о низкоуровневом представлении структур данных, то было принято решение использовать готовый модуль, добавив в него специальные функции для веб-доступа по технологии ISAPI.

Заключение

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