Руководство по оптимизации

Оптимизируйте свои подборки Сохраняйте и классифицируйте контент в соответствии со своими настройками.

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

Безопасность

Обзор лучших практик безопасности

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

Использование ключей API для доступа к API Карт

Ключи API являются предпочтительным методом аутентификации для доступа к API API Карт Google. Хотя использование идентификаторов клиентов в настоящее время по-прежнему поддерживается, ключи API поддерживают более тонкие элементы управления безопасностью и могут быть настроены для работы с определенными веб-адресами, IP-адресами и мобильными SDK (Android и iOS). Для получения информации о создании и защите ключа API перейдите на страницу «Использование ключа API» для каждого API или SDK. (Например, чтобы узнать о Maps JavaScript API, посетите его страницу Использование ключа API .)

Спектакль

Использование экспоненциальной отсрочки для обработки ошибок

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

Экспоненциальная отсрочка наиболее полезна для ошибок в 500 с. Дополнительные сведения см. в разделе Обработка кодов состояния возврата HTTP .

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

Отправка запросов взаимодействия с пользователем по запросу

Запросы к API, включающие взаимодействие с пользователем, следует отправлять только по запросу. Это означает ожидание, пока конечный пользователь выполнит действие (например, on-click ), чтобы инициировать запрос API, а затем использовать результаты для загрузки карты, установки пункта назначения или отображения соответствующей информации. Использование подхода по запросу позволяет избежать ненужных запросов к API, сокращая потребление API.

Отказ от отображения содержимого наложения при движении карты

Избегайте использования Draw() для отображения пользовательского содержимого наложения на карте в то время, когда пользователь может перемещать карту. Поскольку карта перерисовывается каждый раз, когда пользователь перемещает карту, одновременное размещение наложенного содержимого на карте может привести к задержке или визуальному заиканию. Добавляйте или удаляйте оверлейный контент с карты только после того, как пользователь прекратит панорамирование или масштабирование.

Избегайте интенсивных операций в методах Draw

Как правило, рекомендуется избегать ресурсоемких операций, не связанных с рисованием, в методе Draw() . Например, избегайте следующего в коде метода Draw() :

  • Запросы, которые возвращают большое количество контента.
  • Много изменений в отображаемых данных.
  • Управление многими элементами объектной модели документа (DOM).

Эти операции могут снизить производительность и привести к задержке или визуальному зависанию при отображении карты.

Использование растровых изображений в качестве маркеров

Используйте растровые изображения, например изображения в формате .PNG или .JPG, при добавлении маркеров для определения местоположения на карте. Избегайте использования изображений масштабируемой векторной графики (SVG), поскольку рендеринг изображений SVG может привести к задержке при перерисовке карты.

Оптимизация маркеров

Оптимизация повышает производительность, отображая множество маркеров как один статический элемент. Это полезно в тех случаях, когда требуется большое количество маркеров. По умолчанию Maps JavaScript API решает, будет ли оптимизирован маркер. При наличии большого количества маркеров Maps JavaScript API попытается отобразить маркеры с оптимизацией. Не все маркеры можно оптимизировать; в некоторых случаях Maps JavaScript API может потребоваться отображать маркеры без оптимизации. Отключите оптимизированный рендеринг для анимированных файлов GIF или PNG или когда каждый маркер должен отображаться как отдельный элемент DOM.

Создание кластеров для управления отображением маркеров

Чтобы упростить управление отображением маркеров для определения местоположений на карте, создайте кластер маркеров с помощью библиотеки Marker Clusterer . Библиотека Marker Clusterer включает опции для:

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

Потребление

Чтобы планировать бюджет и контролировать расходы, сделайте следующее:

  • Установите оповещение о бюджете , чтобы отслеживать, как ваши расходы растут до определенной суммы. Установка бюджета не ограничивает использование API — он только предупреждает вас, когда ваши расходы приближаются к указанной вами сумме.
  • Ограничьте ежедневное использование API, чтобы управлять расходами на оплачиваемые API. Установив ограничение на количество запросов в день , вы можете ограничить свои расходы. Используйте простое уравнение, чтобы определить дневной лимит в зависимости от того, сколько вы хотите потратить: (ежемесячная стоимость/ цена за каждый )/30 = запросы в дневной лимит (для одного API). Ваша конкретная реализация может использовать несколько оплачиваемых API, поэтому при необходимости измените уравнение. Кредит Google Maps API в размере 200 долларов США предоставляется каждый месяц, поэтому учитывайте это при расчетах.
  • Используйте несколько проектов для изоляции, расстановки приоритетов и отслеживания использования. Например, предположим, что вы регулярно используете API платформы Google Maps в своих тестах. Создав для тестирования отдельный проект с собственными квотами и ключами API, вы сможете тщательно протестировать его, не допуская неожиданного перерасхода средств.

Управление потреблением в Картах

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

Использование статических изображений

Запросы, в которых используются динамические изображения (Динамические карты и Динамический просмотр улиц), стоят дороже, чем Статические карты и Статический просмотр улиц. Если вы не предполагаете взаимодействие пользователя с картой или просмотром улиц (масштабирование или панорамирование), используйте статические версии этих API.

Миниатюры — очень маленькие карты и фотографии — еще одно полезное применение для Static Maps и Static Street View. Плата за эти элементы взимается по более низкой ставке и после взаимодействия с пользователем (по клику). Пользователи могут переходить на динамическую версию для полноценного использования Карт Google.

Использование Maps Embed API

Вы можете использовать Maps Embed API, чтобы бесплатно добавить карту с одним маркером или динамическую карту. Используйте Maps Embed API для приложений, где не требуется один маркер и не требуется настройка карты. За запросы Maps Embed API, использующие режим Directions, View Mode или Search Mode, будет взиматься плата (подробности см. в таблице цен ).

Использование мобильных карт SDK для мобильных приложений

В мобильных приложениях используйте Maps SDK для Android или Maps SDK для iOS при отображении карты. Используйте Maps Static API или Maps JavaScript API, если требования исключают использование мобильных SDK.

Управление потреблением в Routes

Ограничение путевых точек Directions API

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

Использование оптимизации Directions API для оптимальной маршрутизации

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

Аргумент оптимизации сортирует путевые точки для обеспечения оптимального маршрута, а это означает, что путешествие из A в E является более удобным при оптимизации (ABCDE) по сравнению со случайной последовательностью неоптимизированного маршрута (например, ADBCE).

Использование моделей трафика в реальном времени в Directions API и Distance Matrix API

Запросы Directions API и Distance Matrix API, которые включают модели трафика в реальном времени, оплачиваются по более высокой ставке. Модели трафика в реальном времени включаются путем установки времени отправления в now .

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

Использование пройденного маршрута и ближайшей дороги, когда данные GPS неточны

Функции Maps Roads API, «Пройденный маршрут» и «Ближайшая дорога» включены в расширенный уровень и оплачиваются по более высокому тарифу. Используйте эти функции, если данные GPS неточны, а API дорог может помочь определить правильную дорогу. Ограничения скорости, еще одна функция Roads API, доступна только клиентам Asset Tracking.

Семплирование мест ограничения скорости с интервалом от 5 до 15 минут

Чтобы свести к минимуму количество вызовов службы ограничения скорости Maps Roads API, делайте выборку местоположений ваших объектов с интервалом от 5 до 15 минут. Точное значение зависит от скорости, с которой движется актив. Если актив является стационарным, достаточно одного образца местоположения. Нет необходимости делать несколько звонков.

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

Управление потреблением в Places

Оптимизация реализации автозаполнения места

Чтобы оптимизировать расходы на использование автозаполнения места:

  • используйте маски полей в виджетах автозаполнения JavaScript , Android и iOS , чтобы возвращать только нужные вам поля данных места .

  • выбор вариантов выставления счетов зависит от вашего варианта использования. В зависимости от того, использует ли ваша реализация сеансы автозаполнения или нет, с вас будет взиматься плата либо за автозаполнение — за запрос , либо за автозаполнение — за сеанс .

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

Возврат данных для определенных полей в запросах сведений о месте и поиске места

Вы можете настроить запросы Place Details и Place Search, чтобы они возвращали данные для определенных полей, используемых в вашем приложении. Эти поля разбиты на категории: Основные , Контакт и Атмосфера . Запросы, в которых не указаны поля, получат данные для всех полей.

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

Сокращение затрат с помощью API геокодирования

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

Однако, если у вас есть точный адрес (или близкий к нему), вы можете сократить расходы, используя геокодирование вместо автозаполнения. Дополнительные сведения см. в разделе Рекомендации по геокодированию адресов .

Как работают квоты платформы Google Карт

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

Только успешные запросы и запросы, которые вызывают ошибки сервера, учитываются в квоте. Запросы, не прошедшие проверку подлинности, не учитываются в квоте.

Некоторые API Карт имеют посекундное принудительное применение в дополнение к поминутному принудительному применению квоты. Это посекундное принудительное применение не гарантирует равномерного использования в течение всей минуты и не помешает вам достичь квоты использования на эту минуту. Это удерживает вас от использования всей вашей квоты в первую или две секунды любой данной минуты и защищает вас от сбоев в обслуживании в случае внезапного всплеска использования. Чтобы справиться с этими различиями в применении, спланируйте использование квоты и требования, усредняя использование QPM по QPS.

API-интерфейсы GMP, которые имеют эту посекундную принудительную реализацию, — это API направлений, API матрицы расстояний, API высоты, API геокодирования, API мест и API дорог.

Оцените свои расходы на любой продукт API GMP на основе общего объема запросов .

,

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

Безопасность

Обзор лучших практик безопасности

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

Использование ключей API для доступа к API Карт

Ключи API являются предпочтительным методом аутентификации для доступа к API API Карт Google. Хотя использование идентификаторов клиентов в настоящее время по-прежнему поддерживается, ключи API поддерживают более тонкие элементы управления безопасностью и могут быть настроены для работы с определенными веб-адресами, IP-адресами и мобильными SDK (Android и iOS). Для получения информации о создании и защите ключа API перейдите на страницу «Использование ключа API» для каждого API или SDK. (Например, чтобы узнать о Maps JavaScript API, посетите его страницу Использование ключа API .)

Спектакль

Использование экспоненциальной отсрочки для обработки ошибок

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

Экспоненциальная отсрочка наиболее полезна для ошибок в 500 с. Дополнительные сведения см. в разделе Обработка кодов состояния возврата HTTP .

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

Отправка запросов взаимодействия с пользователем по запросу

Запросы к API, включающие взаимодействие с пользователем, следует отправлять только по запросу. Это означает ожидание, пока конечный пользователь выполнит действие (например, on-click ), чтобы инициировать запрос API, а затем использовать результаты для загрузки карты, установки пункта назначения или отображения соответствующей информации. Использование подхода по запросу позволяет избежать ненужных запросов к API, сокращая потребление API.

Отказ от отображения содержимого наложения при движении карты

Избегайте использования Draw() для отображения пользовательского содержимого наложения на карте в то время, когда пользователь может перемещать карту. Поскольку карта перерисовывается каждый раз, когда пользователь перемещает карту, одновременное размещение наложенного содержимого на карте может привести к задержке или визуальному заиканию. Добавляйте или удаляйте оверлейный контент с карты только после того, как пользователь прекратит панорамирование или масштабирование.

Избегайте интенсивных операций в методах Draw

Как правило, рекомендуется избегать ресурсоемких операций, не связанных с рисованием, в методе Draw() . Например, избегайте следующего в коде метода Draw() :

  • Запросы, которые возвращают большое количество контента.
  • Много изменений в отображаемых данных.
  • Управление многими элементами объектной модели документа (DOM).

Эти операции могут снизить производительность и привести к задержке или визуальному зависанию при отображении карты.

Использование растровых изображений в качестве маркеров

Используйте растровые изображения, например изображения в формате .PNG или .JPG, при добавлении маркеров для определения местоположения на карте. Избегайте использования изображений масштабируемой векторной графики (SVG), поскольку рендеринг изображений SVG может привести к задержке при перерисовке карты.

Оптимизация маркеров

Оптимизация повышает производительность, отображая множество маркеров как один статический элемент. Это полезно в тех случаях, когда требуется большое количество маркеров. По умолчанию Maps JavaScript API решает, будет ли оптимизирован маркер. При наличии большого количества маркеров Maps JavaScript API попытается отобразить маркеры с оптимизацией. Не все маркеры можно оптимизировать; в некоторых случаях Maps JavaScript API может потребоваться отображать маркеры без оптимизации. Отключите оптимизированный рендеринг для анимированных файлов GIF или PNG или когда каждый маркер должен отображаться как отдельный элемент DOM.

Создание кластеров для управления отображением маркеров

Чтобы упростить управление отображением маркеров для определения местоположений на карте, создайте кластер маркеров с помощью библиотеки Marker Clusterer . Библиотека Marker Clusterer включает опции для:

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

Потребление

Чтобы планировать бюджет и контролировать расходы, сделайте следующее:

  • Установите оповещение о бюджете , чтобы отслеживать, как ваши расходы растут до определенной суммы. Установка бюджета не ограничивает использование API — он только предупреждает вас, когда ваши расходы приближаются к указанной вами сумме.
  • Ограничьте ежедневное использование API, чтобы управлять расходами на оплачиваемые API. Установив ограничение на количество запросов в день , вы можете ограничить свои расходы. Используйте простое уравнение, чтобы определить дневной лимит в зависимости от того, сколько вы хотите потратить: (ежемесячная стоимость/ цена за каждый )/30 = запросы в дневной лимит (для одного API). Ваша конкретная реализация может использовать несколько оплачиваемых API, поэтому при необходимости измените уравнение. Кредит Google Maps API в размере 200 долларов США предоставляется каждый месяц, поэтому учитывайте это при расчетах.
  • Используйте несколько проектов для изоляции, расстановки приоритетов и отслеживания использования. Например, предположим, что вы регулярно используете API платформы Google Maps в своих тестах. Создав для тестирования отдельный проект с собственными квотами и ключами API, вы сможете тщательно протестировать его, не допуская неожиданного перерасхода средств.

Управление потреблением в Картах

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

Использование статических изображений

Запросы, в которых используются динамические изображения (Динамические карты и Динамический просмотр улиц), стоят дороже, чем Статические карты и Статический просмотр улиц. Если вы не предполагаете взаимодействие пользователя с картой или просмотром улиц (масштабирование или панорамирование), используйте статические версии этих API.

Миниатюры — очень маленькие карты и фотографии — еще одно полезное применение для Static Maps и Static Street View. Плата за эти элементы взимается по более низкой ставке и после взаимодействия с пользователем (по клику). Пользователи могут переходить на динамическую версию для полноценного использования Карт Google.

Использование Maps Embed API

Вы можете использовать Maps Embed API, чтобы бесплатно добавить карту с одним маркером или динамическую карту. Используйте Maps Embed API для приложений, где не требуется один маркер и не требуется настройка карты. За запросы Maps Embed API, использующие режим Directions, View Mode или Search Mode, будет взиматься плата (подробности см. в таблице цен ).

Использование мобильных карт SDK для мобильных приложений

В мобильных приложениях используйте Maps SDK для Android или Maps SDK для iOS при отображении карты. Используйте Maps Static API или Maps JavaScript API, если требования исключают использование мобильных SDK.

Управление потреблением в Routes

Ограничение путевых точек Directions API

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

Использование оптимизации Directions API для оптимальной маршрутизации

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

Аргумент оптимизации сортирует путевые точки для обеспечения оптимального маршрута, а это означает, что путешествие из A в E является более удобным при оптимизации (ABCDE) по сравнению со случайной последовательностью неоптимизированного маршрута (например, ADBCE).

Использование моделей трафика в реальном времени в Directions API и Distance Matrix API

Запросы Directions API и Distance Matrix API, которые включают модели трафика в реальном времени, оплачиваются по более высокой ставке. Модели трафика в реальном времени включаются путем установки времени отправления в now .

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

Использование пройденного маршрута и ближайшей дороги, когда данные GPS неточны

Функции Maps Roads API, «Пройденный маршрут» и «Ближайшая дорога» включены в расширенный уровень и оплачиваются по более высокому тарифу. Используйте эти функции, если данные GPS неточны, а API дорог может помочь определить правильную дорогу. Ограничения скорости, еще одна функция Roads API, доступна только клиентам Asset Tracking.

Семплирование мест ограничения скорости с интервалом от 5 до 15 минут

Чтобы свести к минимуму количество вызовов службы ограничения скорости Maps Roads API, делайте выборку местоположений ваших объектов с интервалом от 5 до 15 минут. Точное значение зависит от скорости, с которой движется актив. Если актив является стационарным, достаточно одного образца местоположения. Нет необходимости делать несколько звонков.

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

Управление потреблением в Places

Оптимизация реализации автозаполнения места

Чтобы оптимизировать расходы на использование автозаполнения места:

  • используйте маски полей в виджетах автозаполнения JavaScript , Android и iOS , чтобы возвращать только нужные вам поля данных места .

  • выбор вариантов выставления счетов зависит от вашего варианта использования. В зависимости от того, использует ли ваша реализация сеансы автозаполнения или нет, с вас будет взиматься плата либо за автозаполнение — за запрос , либо за автозаполнение — за сеанс .

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

Возврат данных для определенных полей в запросах сведений о месте и поиске места

Вы можете настроить запросы Place Details и Place Search, чтобы они возвращали данные для определенных полей, используемых в вашем приложении. Эти поля разбиты на категории: Основные , Контакт и Атмосфера . Запросы, в которых не указаны поля, получат данные для всех полей.

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

Сокращение затрат с помощью API геокодирования

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

Однако, если у вас есть точный адрес (или близкий к нему), вы можете сократить расходы, используя геокодирование вместо автозаполнения. Дополнительные сведения см. в разделе Рекомендации по геокодированию адресов .

Как работают квоты платформы Google Карт

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

Только успешные запросы и запросы, которые вызывают ошибки сервера, учитываются в квоте. Запросы, не прошедшие проверку подлинности, не учитываются в квоте.

Некоторые API Карт имеют посекундное принудительное применение в дополнение к поминутному принудительному применению квоты. Это посекундное принудительное применение не гарантирует равномерного использования в течение всей минуты и не помешает вам достичь квоты использования на эту минуту. Это удерживает вас от использования всей вашей квоты в первую или две секунды любой данной минуты и защищает вас от сбоев в обслуживании в случае внезапного всплеска использования. Чтобы справиться с этими различиями в применении, спланируйте использование квоты и требования, усредняя использование QPM по QPS.

API-интерфейсы GMP, которые имеют эту посекундную принудительную реализацию, — это API направлений, API матрицы расстояний, API высоты, API геокодирования, API мест и API дорог.

Оцените свои расходы на любой продукт API GMP на основе общего объема запросов .