«Яндекс Карты» показали проект «сверхподробных» карт — с дорожной разметкой, подземными переходами и деревьями Статьи редакции
Первые изменения внесут в бета-версию после 19 декабря 2022 года.
- «Яндекс Карты» представили новую визуализацию карт на ежегодном мероприятии Yet another Conference, которое в 2022 году компания провела в формате мини-сериала. Вид дорог, зданий, подземных переходов, остановок и других объектов «приблизят» к реальному по форме и цветам.
- Новые детализированные карты помогут водителям и пешеходам лучше ориентироваться на дорогах и улицах. «Читать нынешние схемы бывает тяжело: например, не всегда понятно, решётка — это пешеходный переход или что-то другое. Но делать карту фотореалистичной мы не хотим: из-за обилия подробностей она будет слишком долго загружаться», — рассказал директор продуктовой стратегии сервиса Илья Александров.
- Обновлять карты будут постепенно. Сначала изменят вид автомобильных дорог: добавят разметку полос и островки безопасности, трёхмерными сделают сложные развязки — чтобы водитель сразу видел, где поворот. Ключевые московские магистрали отобразятся по-новому уже после 19 декабря 2022 года в бета-версии «Яндекс Карт».
- Позже отрисуют у зданий окна, крыши, подъезды и пандусы — так будет проще узнать нужный объект. А ещё в деталях покажут остановки общественного транспорта, входы в подземные переходы и деревья, которые расположат там, где они растут на самом деле. Точных сроков компания пока не называет.
- Подробнее о том, как «Яндекс» развивает сервис, можно послушать в отдельной серии YaC 2022 под названием «Карты нового поколения».
- В 2022 году «Яндекс Карты» добавили озвучку велосипедных и самокатных маршрутов и возможность оптимизировать маршруты с несколькими пунктами назначения.
- Улучшили также поиск по организациям, подключив нейросети, доработали JavaScript API, чтобы можно было менять дизайн карт и скрывать лишние объекты, и обновили приложение, из которого теперь можно вызывать такси и арендовать самокат.
435
показов
52K
открытий
10
репостов
Комментарий недоступен
А это уже ко вчерашней новости про Ятаган и сборку Аппа, которая получается быстрее, но несколько тормозит сам апп :)
Комментарий недоступен
React Native - не веб-фреймворк. Он использует нативные компоненты.
и что? Зато прослойка преобразования требовательна к процессору, да и сама бизнес логика на js, которая не имеет доступа к нативным сервисам ОС
Спасибо за уточнение. Почему-то я был уверен, что JS преобразуется в нативный код. Погуглил.
Да, рендеринг приложения React Native происходит с помощью нативных представлений (views).Нет, код JavaScript не компилируется в родной язык платформы.
Источник https://medium.com/nuances-of-programming/%D0%B2%D0%BD%D1%83%D1%82%D1%80%D0%B5%D0%BD%D0%BD%D1%8F%D1%8F-%D0%B6%D0%B8%D0%B7%D0%BD%D1%8C-react-native-75e5244b623e
Простите, проблема не в скрипатовых языках, а в оптимизациях. JS используется во многих приложениях, но тяжелые операции выносятся в нативный код для лучшей производительности. Конечно, если все писать на JS то будет множество батлнеков где основной процесс блокируется тяжелой операцией. Но этому подвержены и другие "нативные" ЯП, тот же C#, Java. Если разработчик сознательно не выносит тяжелую работу в под-процессы - тормозить будет на любом языке. В некоторых языках (или даже точнее платформах), возможно, более простые и доступные инструменты для распараллеливания.
тяжелую работу в под-процессы - так react native сам по себе тяжелая работа, так как оборачивает нативные компоненты в прослойку js, вот в чем проблема. И любая такая прослойка и есть тяжелая работа, речь то не про вычисления или парсинг данных от api. А по сему - только нативный язык и инструменты в мобильной разработке будут производительными, да и на интерфейсе (даже рисованном) выдавать 120 кадров в любом масштабном приложении
Читаю и чую что вы смотрите на архитектуру приложения. Сарказм. Никто не отменял модули которые пишутся на нативных языках. Знаю как минимум одну сильно популярную игру начинающуюся на Т, где интерфейс отрисовывается на реакте. Это не мешает игре выдавать 60 FPS.
воооот, и в итоге мы пришли к тому, что там модуль на нативном написать нужно, еще вот там один и вооон там, а по итогу на 60% приложения написано на нативе, и головная боль поддерживать и натив и React Native, отсюда вопрос - нахера вы брали RN? Я согласен, отец, прототипировать на RN/Flutter - огонь, но вот дальше - жуть.
Брат (раз уж мы используем какие-то криповые обращения), оно работает в продакшине и в очень больших проектах с действительно большим штатом сотрудников. Реакт используют для масштабирования разработки (сделал интерфейс один раз, используешь на нескольких платформах), много програмистов. И любое приложение, даже на JS использует нативный код, ту же V8 Engine. Большие приложения используют винегрет из языков и технологий, потому что каждая технология имеет сильные и слабые стороны.
"Реакт используют для масштабирования разработки (сделал интерфейс один раз, используешь на нескольких платформах)," - ну да, ну да. Я как разработчик на реакте (последних 4-х лет) скажу - это не совсем правда, особенно когда касается поведения кастомных селектов и списков с прокруткой. Для "много программистов" используют микрофронтенды (как и я в нашей компании) и выделенными отдельно переиспользуемыми UI компонентами в сторибуке. Так вот переиспользуемость в React Native не так красиво работает, как ее преподносят.
отец, нативные языки для мобильной разработки более оптимизированы, Swift к примеру жуть как оптимизирован, речь то про мобильную нишу, а не про шапр и джаву как пример, у них своя ниша.
Мой поинт лишь в том, что формулировка "тормозит потому что React Native" как минимум не точна. На Swift, уверен, тоже можно сделать трмознутое поделие. Вопрос в прямоте рук тех, кто разрабатывает.
Не совсем так, но в чем-то согласен с тобой
Переход на веб-приложения - это не проблема. Сделали бы механизм кеширования (создания локальной копии) карт в браузере, тогда не было бы тормозов.
а как инвалидировать такой кэш не думал? (копию карты), а это одна из главных проблем программирования
Если говорить о вебе, то кеширование ресурсов может быть реализовано не через Cache Api, а через indexeddb. Синхронизация - дело техники. У каждого ресурса считайте есть некий updated timestamp. Удаление ресурсов в этом случае - не проблема. Если нужны уточнения, спрашивайте.
Я лишь говорю, что для фронтенда огромной проблемы нет с хранением ресурсов. А вот касается бекенда, то зависит от используемого зоопарка.
Как бэкендер скажу что вообще нет никаких проблем) можно написать свое что-то, можно закрыться например варнишем, да масса способов есть чтобы не гонять трафик к фронту и обратно)
Как вариант - можно кэшировать ответы эндпоинтов и хранить хэш ответа рядом с last-modified в каком-нибудь редисе на сервере, апп стучится каждый раз туда с last-modified в заголовках и если данные в эндпоинте не поменялись - получаем 301 и работаем с локальным кэшем, если поменялись - выкачиваем. На любое изменение в картах вешаем доменный ивент на сервере, который при триггере обновит инфу по last-modified в хранилище, самый простой и не совсем оптимальный вариант, но снимает головняк с инвалидацией
Так ты описал самый простой способ кеширования ответов, а чел выше говорил про кеширование полных данных от приложения на уровне устройства, а теперь прикинь сколько данных у приложения 2Gis к примеру, и какие будут седые программисты поддерживающие такого рода приложения) Мы на фронте в localstorage браузера лишний раз не кидаем простые значения, а тут кеш карты. Я на беке тоже пишу много Go/Node.js/PHP
"мы на фронте" - звучит даже стремно 😄
отец, веб-прилоежения лажа по определению с невозможностью имспользованию нативных сервисов, да и web-view тот еще тормоз.
не не, отец, в яндекс картах нативные языки и апы, как и у всех их сервисов
Комментарий недоступен
что такое нормальный фреймворк вместо React?
нативное приложение
Комментарий недоступен
что за нормальные фреймворки тут имеются ввиду вместо REACT
по-моему довольно простой вопрос
React Native != React
он ошибся, отец, нормальных фреймворков для кросплатформенности нет по определению. Только нативные языки и инструменты. Именно его он имел в виду скорее всего.
Комментарий недоступен
речь про мобильную разработку, отец
Комментарий недоступен
проблема в таких корпорациях в том, что разрабатывать монолит несколькими командами сложно, а микросервисы в нативные апы еще не завезли насколько знаю. Вот и извращаются с билдерами и прочими штуками, лишь бы hot reload нормальный командам обеспечить, в следствие чего упор ставят на скорость оработки вместо качества оптимизации конечного монолитного апа
Можно разрабатывать либы для аппа разными командами, а на финальной стадии отдельная команда просто их подключает в монолит, каждая либа существует и тестируется отдельно, к сборке приходит стабильная версия, но возникает вопрос совместимости этого дела друг с другом
не совсем то, что с микросервисами/микрофронтендами. И это конечно накладывает на монолит проблемы.
Само собой не то, но вариант распарралелить разработку есть и скорее всего там не дураки сидят и делают примерно как я описал
А либы могут быть отдельными экранами приложения? Или либа это набор функций (как пакет для JS/Go/PHP)
Ничто не мешает отдельные фичи в либу вынести, но тут я честно слабоват - мобильные аппы писал мало, на бэке работаю последние лет 7)
Они сейчас в периоде, когда надо занять как можно больше ниш в РФ и дружественных странах, пока мировые вендоры ушли или заточены на крупных рынках. На все ресурсов не хватает. Так у большинства компаний. Тот же Гугл вообще забил на некоторые сервисы из своей системы, например, на поддержание актуальной работы карт в РФ он забил примерно лет 10 назад :)
Да там речь про режим для разработчика была
Но сказывается и на конечных юзерах
Это разные режимы сборки. Цитата из статьи:
В Yatagan есть специальный режим для разработчиков, который связывает модули без генерации кода, — он незначительно замедляет запуск приложения, но сильно ускоряет сборку.
Я понимаю. Но это не отменяет проблемы скорости работы Аппа.
Эта проблема же кроется в разработке,а не появляется из ниоткуда при скачивании аппа в сторе
Но Ятаган к этому отношения не имеет
Не факт