Сегодня мы запустили новую версию веб-интерфейса сервиса Яндекс.
Метро .
Карты метро пяти городов теперь доступны в новом «островном» дизайне.
Но мы обновили не только визуальную часть, но и перенесли всю логику с серверной части на клиентскую.
В этом посте мы хотели бы рассказать вам, как именно мы это сделали, какие решения выбрали и почему.
Сервис Яндекс.
Метро был запущен еще в 2007 году.
С тех пор веб-интерфейс практически не развивался; дизайн выглядел откровенно устаревшим.
Почтенный возраст сервиса сказался и на технической стороне.
Все диаграммы представляли собой наборы изображений в формате GIF, на которых с помощью координат размещались объекты.
Из-за этого возникли трудности с обновлением графика; самостоятельно внести изменения в схему было невозможно (пришлось привлекать аутсорсеров и заказывать у них картинки).
Поскольку названия станций также были встроены в изображения, локализация шаблонов потребовала бы создания полных наборов изображений в формате GIF. Никто из серверных разработчиков в настоящее время не работает над этим сервисом, и он очень плохо документирован.
Так что бэкенд старого Яндекс.
Метро — это в некотором роде черный ящик, который мог принимать параметры и возвращать маршруты.
Однако сохранить его было крайне сложно.
Сервис однозначно нуждался в обновлении, и главный вопрос заключался в том, как максимально приблизить его к технологическому уровню мобильных приложений.
Нельзя сказать, что Яндекс.
Метро вообще забросили; у него довольно широкая аудитория.
Веб-интерфейс ежедневно посещают около 220 тысяч человек, приложение для Android скачано 3 миллиона раз, а для iOS – 1 миллион загрузок.
Стоит отметить, что мобильные приложения были разработаны несколько позже веб-версии и лишены большинства ее недостатков.
При разработке пришлось учесть несколько важных изменений, произошедших с момента запуска Метро:
- Технологии браузерного рендеринга прошли долгий путь; рендеринг карты на стороне клиента больше не является проблемой.
- Производительность движков JavaScript была значительно улучшена.
Многие задачи, которые раньше можно было выполнить только на сервере, теперь полностью выполнимы на стороне клиента.
- Доля устаревших браузеров снизилась.
IE6 и IE8 практически отсутствуют, а это означает, что нет смысла использовать GIF-файлы.
Как разрабатывалась новая версия
Для воспроизведения графика использовались те же данные, что и для мобильных приложений.Они уже собрали базу XML-файлов, каждый из которых содержал одну схему и данные о связности графа.
Это также упростит локализацию: в ближайшее время все схемы будут переведены на разные языки.
В самом начале разработки встал вопрос о том, какую технологию использовать для отрисовки диаграммы: Canvas, SVG или CSS3. Также был рассмотрен метод рендеринга через библиотеку визуализации RaphaelJS. Эта библиотека рисует в SVG, но если она обнаруживает IE8, рендеринг происходит в VML, что обеспечивает максимальную кроссбраузерность.
Сначала были написаны три прототипа схемы на основе XML-файлов: в Canvas, SVG и RaphaelJS. Все три варианта были протестированы с помощью тестов.
По результатам самой быстрой оказалась SVG-версия, за ней с не очень существенным отставанием следует Canvas, а самая медленная версия — на основе RaphaelJS. Слишком много времени тратится на загрузку и выполнение кода, который проверяет, какие функции доступны в используемом вами браузере.
После ста итераций рендеринга мы получили следующие результаты в Chrome и Firefox соответственно:
| технологии | time_to_download | time_to_draw | общее_время |
| холст | 34,58 мс | 181,72 мс | 216,30 мс |
| SVG | 28,02 мс | 74,02 мс | 102,07 мс |
| SVG-Рафаэль | 45,87 мс | 1147,58 мс | 1193,45 мс |
| технологии | time_to_download | time_to_draw | общее_время |
| холст | 55,26 мс | 769,16 мс | 824,42 мс |
| SVG | 102,60 мс | 136,51 мс | 239,11 мс |
| SVG-Рафаэль | 148,40 мс | 2369,88 мс | 2518,28 мс |
Дело в том, что элементы SVG хорошо вписываются в DOM страницы.
Это означает, что вы можете обращаться к ним как к обычным узлам DOM со знакомым интерфейсом, перехватывать события и т. д. Кроме того, в векторном формате нет необходимости перерисовывать диаграмму при изменении масштаба.
Чтобы иметь возможность выделять маршруты на схеме, необходимо было разделить ее на слои.
Самый нижний слой предназначен для статичных объектов, помогающих ориентироваться.
В будущих версиях там будут отображаться реки и другие важные объекты ландшафта.
Вся схема нарисована на среднем слое.
Самый верхний слой — это слой маршрута.
Чтобы можно было его выделить, между ним и слоем общей схемы есть еще один слой: соединяя его, мы добиваемся размытия общей схемы.
Позже для удобства разработки и назначения стилей CSS слой с общей схемой был разделен на три: с этапами, станциями и переходами.
Новая схема имеет неоспоримые преимущества: она векторная, ее можно масштабировать без написания дополнительного кода, ее проще поддерживать и добавлять дополнительные возможности.
К сожалению, изменения в схеме по-прежнему вносятся вручную через XML-файлы, но даже это проще, чем было в исходной версии.
Нахождение путей на графе
Вся логика планирования маршрута в старой версии Metro выполнялась на стороне сервера.На каждое действие пользователя отправлялся запрос на сервер, рассчитывался новый вариант и отправлялся ответ. Для расчетов использовался алгоритм Дейкстры с небольшими модификациями для поддержки поиска нескольких маршрутов, например, можно отрезать последнее ребро и продолжить поиск путей.
Примерно тот же алгоритм использовался при создании мобильных приложений, но поскольку они были разработаны несколько позже, в них использовались более современные технологии и подходы.
Там вся логика уже перенесена в клиентскую часть.
В версии для iOS граф представлен в виде матрицы смежности; в Android-клиенте реализована объектно-ориентированная модель.
Станции представлены в виде JS-объектов, каждый из которых имеет массив ссылок — этапов.
Эти связи также являются объектами.
При выборе основы веб-интерфейса рассматривались оба варианта.
Но модель из Android-приложения нам показалась более оптимальной.
Фильтрация результатов поиска
На каждый запрос маршрутизатор возвращает около 30 маршрутов.Актуальных очень мало – не более 10%.
Но проблема в том, что многие пользователи по-разному понимают «оптимальный маршрут».
Кто-то предпочитает скорость, кто-то комфорт. Девушка на каблуках будет готова потратить лишние 10 минут, чтобы не идти по длинному переходу, но для человека, опаздывающего на самолет, эта разница будет критичной.
Это означает, что маршруты необходимо оценивать по разным критериям.
Чтобы не усложнять всю систему, были разработаны специальные фильтры: класс объектов, интерфейс которого состоит из одного метода, выполняющего одно простое действие.
Также были добавлены составные фильтры, содержащие несколько фильтров.
Они применяются к массиву маршрутов в порядке, указанном разработчиком.
Теперь фильтрация вынесена в отдельный модуль.
Это позволит нам в ближайшем будущем унифицировать процесс фильтрации на всех платформах.
Таким образом, выбор маршрута не будет зависеть от того, с какого устройства был введен запрос.
Архитектура клиентского приложения
При разработке MVC мы воспользовались уже имеющимися в Яндексе наработками: JS-библиотеками, отвечающими за дизайн острова, логику, хранение данных и оповещение компонентов о действиях пользователя и изменении состояния.
Планы
Сразу после запуска новой версии сервиса мы планируем привести нашу схему в соответствие с официальной.Далее мы представим некоторые функции, которые уже существуют в мобильных приложениях.
Например, информация о том, с каких автомобилей удобнее пересаживаться.
Также мы реализуем уже заложенные в архитектуру возможности: возможность выбора маршрутов и перевод схем на несколько языков.
Кроме того, планируется разработать визуальный инструмент для внесения изменений в схему.
На данный момент любые изменения вносятся путем редактирования XML-файлов.
Если появится визуальный редактор, один контент-менеджер сможет быстро вносить изменения одновременно для всех платформ.
Теги: #Разработка сайтов #JavaScript #Яндекс.
метро
-
Кризис Сообщества Ddd
19 Oct, 24 -
История Goldeneye 007
19 Oct, 24 -
Победа Над Openoffice?
19 Oct, 24
