W tym przewodniku opisujemy kilka strategii optymalizowania wykorzystania interfejsów API Map Google pod kątem bezpieczeństwa, wydajności i wykorzystania.
Bezpieczeństwo
Przegląd sprawdzonych metod dotyczących bezpieczeństwa
Klucze interfejsu API to dane logowania skoncentrowane na projekcie, które wymagają takich samych środków ostrożności jak identyfikatory użytkowników i hasła. Zapoznaj się ze sprawdzonymi metodami zapewniania bezpieczeństwa interfejsu API, aby zabezpieczyć swoje klucze przed niewłaściwym użyciem, które może doprowadzić do nadmiernego wykorzystania limitu i nieoczekiwanych opłat na koncie.
Korzystanie z kluczy interfejsu API do uzyskiwania dostępu do interfejsów API Map Google
Klucze interfejsu API są preferowaną metodą uwierzytelniania dostępu do interfejsów API Map Google. Chociaż używanie identyfikatorów klientów jest obecnie obsługiwane, klucze interfejsu API obsługują bardziej szczegółowe opcje zabezpieczeń i można je dostroić pod kątem działania z określonymi adresami internetowymi, adresami IP i mobilnymi pakietami SDK (na Androida i iOS). Informacje o tworzeniu i zabezpieczaniu klucza interfejsu API znajdziesz na stronie „Używanie klucza interfejsu API” dla każdego interfejsu API i pakietu SDK. (Na przykład w przypadku interfejsu Maps JavaScript API odwiedź jego stronę poświęconą używaniu klucza interfejsu API).
Występy
Obsługa błędów przy użyciu wykładniczego ponowienia
Jeśli w Twoich aplikacjach występują błędy spowodowane nadmierną próbą wywołania interfejsu API w krótkim czasie (np. błędy zapytań na sekundę), rozważ wykorzystanie wykładniowego ponowienia w celu umożliwienia przetwarzania żądań.
Wykładniczy czas do ponowienia jest najbardziej przydatny w przypadku błędów występujących w pierwszych 500 sekundach. Więcej informacji znajdziesz w sekcji Obsługa kodów stanu zwrotnego HTTP.
W szczególności należy dostosować tempo zapytań. W kodzie dodaj okres oczekiwania między zapytaniami wynoszący S s. Jeśli zapytanie nadal zwraca błąd QPS, wydłuż okres oczekiwania i wyślij kolejne zapytanie. Dostosowuj okres oczekiwania, aż zapytanie zwróci wyniki bez błędów.
Wysyłanie na żądanie próśb o interakcję z użytkownikiem
Żądania do interfejsów API, które obejmują interakcje z użytkownikami, powinny być wysyłane tylko na żądanie.
Polega to na oczekiwaniu na wykonanie działania przez użytkownika (np. on-click) w celu zainicjowania żądania do interfejsu API, a następnie wykorzystanie jego wyników do wczytania mapy, ustawienia miejsca docelowego lub wyświetlenia odpowiednich informacji. Użycie metody na żądanie pozwala uniknąć niepotrzebnych żądań kierowanych do interfejsów API i ograniczyć zużycie przez nie interfejsów API.
Unikanie wyświetlania zawartości nakładki, gdy mapa się porusza
Unikaj używania metody Draw() do wyświetlania na mapie niestandardowej nakładki w momencie, gdy użytkownik może ją przesuwać. Ponieważ mapa jest ponownie rysowana za każdym razem, gdy użytkownik ją przesuwa, jednoczesne umieszczenie na mapie treści nakładki może powodować opóźnienia lub zacinanie się obrazu. Dodaj lub usuń nakładkę z mapy,
gdy użytkownik przestanie przesuwać lub powiększać.
Unikanie intensywnych operacji w metodach Draw
Ogólnie zalecamy unikanie w metodzie Draw() operacji, które nie są zbyt wydajne i nie są rysowania. Na przykład w kodzie metody Draw() unikaj tych elementów:
- Zapytania, które zwracają dużą ilość treści.
- Wiele zmian w wyświetlanych danych.
- Manipulowanie wieloma elementami DOM.
Takie operacje mogą obniżać wydajność i powodować opóźnienie lub zacinanie się obrazu podczas renderowania mapy.
Używanie obrazów rastrowych jako znaczników
Do określania lokalizacji na mapie używaj obrazów rastrowych, np. w formacie PNG lub JPG. Unikaj używania obrazów SVG (Scalable Vector Graphics), ponieważ renderowanie obrazów SVG może powodować opóźnienia podczas ponownego renderowania mapy.
Optymalizacja znaczników
Optymalizacja zwiększa skuteczność, ponieważ renderuje wiele znaczników jako jeden statyczny element. Jest to przydatne, gdy wymagana jest duża liczba znaczników. Domyślnie interfejs Maps JavaScript API decyduje o tym, czy znacznik zostanie zoptymalizowany. W przypadku dużej liczby znaczników interfejs Maps JavaScript API będzie próbował wyrenderować znaczniki z optymalizacją. Nie wszystkie znaczniki można zoptymalizować. W niektórych sytuacjach interfejs Maps JavaScript API może wymagać renderowania znaczników bez optymalizacji. Wyłącz zoptymalizowane renderowanie w przypadku animowanych plików GIF lub PNG albo gdy każdy znacznik musi być renderowany jako osobny element DOM.
Tworzenie klastrów w celu zarządzania wyświetlaniem znaczników
Aby ułatwić sobie zarządzanie wyświetlaniem znaczników w celu identyfikowania lokalizacji na mapie, utwórz klaster znaczników, korzystając z biblioteki Klaster znaczników. Biblioteka klastrów znaczników zawiera opcje tych opcji:
- Rozmiar siatki, który określa liczbę znaczników do zgrupowania w grupie.
- Maksymalne powiększenie, które określa maksymalny poziom powiększenia, przy którym ma się wyświetlać klaster.
- Ścieżki obrazów, które mają być używane jako ikony znaczników.
Oglądanie treści
Aby zaplanować budżet i kontrolować koszty:
- Ustaw alert dotyczący budżetu, aby śledzić wzrost kosztów w ramach danej kwoty. Ustalenie budżetu nie ogranicza wykorzystania interfejsu API – informuje tylko, gdy koszty zbliżą się do określonej kwoty.
- Ogranicz dzienne wykorzystanie interfejsu API, aby zarządzać kosztami interfejsów API podlegających rozliczeniu. Ustawiając limity żądań dziennie, możesz ograniczyć koszty. Użyj prostego równania, aby określić limit dzienny w zależności od tego, ile chcesz wydać: (miesięczny koszt/cena za każdy element)/30 = liczba żądań dziennie (w przypadku jednego interfejsu API). Twoja implementacja może korzystać z wielu płatnych interfejsów API, więc dostosuj równanie odpowiednio do potrzeb. Co miesiąc dodajemy 200 USD do wykorzystania w interfejsach API Map Google, więc uwzględnij to w obliczeniach.
- Korzystaj z wielu projektów, aby izolować, określać priorytety i śledzić wykorzystanie. Załóżmy na przykład, że regularnie w swoich testach używasz interfejsów API Google Maps Platform. Dzięki utworzeniu osobnego projektu na potrzeby testowania – z własnymi limitami i kluczami interfejsu API – możesz przeprowadzić szczegółowe testy, chroniąc jednocześnie przed nadmiernymi wydatkami.
Zarządzanie wykorzystaniem w Mapach
Użycie 1 mapy na stronę jest dobrym sposobem na optymalizację wyświetlania map, ponieważ użytkownicy zwykle korzystają z jednej mapy naraz. Aplikacja może modyfikować mapę, aby wyświetlać różne zbiory danych w zależności od interakcji i potrzeb klienta.
Korzystanie ze statycznych obrazów
Żądania, które wykorzystują zdjęcia dynamiczne (dynamiczne mapy i dynamiczne widoki Street View) kosztują więcej niż statyczne mapy i statyczne widoki Street View. Jeśli nie przewidujesz interakcji użytkowników z mapą lub Street View (powiększeniem lub przesuwaniem), używaj statycznych wersji tych interfejsów API.
Miniatury, czyli bardzo małe mapy i zdjęcia, przydają się też do tworzenia map statycznych i statycznych zdjęć Street View. Elementy te są rozliczane z niższą opłatą i po kliknięciu przez użytkownika. Mogą one przekierowywać użytkowników do wersji dynamicznej, która pozwala w pełni korzystać z Map Google.
Korzystanie z interfejsu Maps Embed API
Za pomocą interfejsu Maps Embed API możesz bezpłatnie dodać mapę z jednym znacznikiem lub mapę dynamiczną. Używaj interfejsu Maps Embed API w aplikacjach, w których nie jest wymagany jeden znacznik i nie trzeba modyfikować mapy. Za żądania do interfejsu Maps Embed API wykorzystujące tryb wskazówek dojazdu, tryb wyświetlania lub tryb wyszukiwania będą naliczane opłaty (szczegóły znajdziesz w cenniku).
Korzystanie z pakietów SDK do map mobilnych w aplikacjach mobilnych
W przypadku aplikacji mobilnych do wyświetlania mapy użyj pakietu Maps SDK na Androida lub Maps SDK na iOS. Jeśli wymagania nie obejmują mobilnych pakietów SDK, użyj interfejsu Maps Static API lub Maps JavaScript API.
Zarządzanie wykorzystaniem na trasach
Ograniczenie punktów na trasie interfejsu Directions API
Jeśli to możliwe, ogranicz wpisy użytkowników w zapytaniu do maksymalnie 10 punktów pośrednich. Żądania obejmujące więcej niż 10 punktów pośrednich są rozliczane według wyższej stawki.
Korzystanie z optymalizacji interfejsu Directions API w celu optymalnego routingu
Żądania używające argumentu optymalizacji punktów pośrednich są rozliczane według wyższej stawki. Więcej informacji znajdziesz w artykule Optymalizacja punktów Waypoints.
Argument optymalizacji sortuje punkty pośrednie, aby zapewnić optymalną trasę. Oznacza to, że podróż z punktu A do E jest wygodniejsza w przypadku zoptymalizowania (A-B-C-D-E) niż losowa sekwencja niezoptymalizowanej trasy (takiej jak A-D-B-C-E).
Używanie modeli ruchu w czasie rzeczywistym w interfejsach Directions API i Distance Matrix API
Żądania do Directions API i Distance Matrix API, które zawierają modele ruchu w czasie rzeczywistym, są rozliczane według wyższej stawki.
Aby włączyć modele ruchu w czasie rzeczywistym, ustaw czas odjazdu na now.
Jeśli w żądaniu pominięto modele ruchu, wyniki zależą wyłącznie od czynników fizycznych: dróg, odległości i ograniczeń prędkości.
Korzystanie z przebytych tras i najbliższej drogi, gdy dane GPS są nieprecyzyjne
Funkcje interfejsu Maps Roads API (Przebyta trasa) i Najbliższa droga są dostępne na poziomie zaawansowanym i są rozliczane według wyższej stawki. Korzystaj z tych funkcji, gdy dane GPS są nieprecyzyjne, a interfejs Roads API może pomóc w określeniu właściwej drogi. Ograniczenia prędkości, czyli kolejna funkcja interfejsu Roads API, są dostępne tylko dla klientów korzystających ze śledzenia zasobów.
Lokalizacje ograniczenia prędkości próbkowania co 5–15 minut
Aby zminimalizować liczbę wywołań usługi ograniczenia prędkości interfejsu Maps Roads API, próbkuj lokalizacje swoich zasobów w odstępach 5–15-minutowych. Dokładna wartość zależy od prędkości, z jaką porusza się zasób. Jeśli zasób jest nieruchomy, wystarczy jedna próbka lokalizacji. Nie trzeba wykonywać wielu połączeń.
Aby zminimalizować ogólny czas oczekiwania, wywołaj usługę limitu prędkości po zgromadzeniu pewnej ilości danych, zamiast wywoływać interfejs API po każdym odebraniu informacji o lokalizacji zasobu mobilnego.
Zarządzanie wykorzystaniem w miejscach
Optymalizacja implementacji autouzupełniania miejsc
Aby zoptymalizować koszt korzystania z autouzupełniania miejsc:
używać masek pól w widżetach autouzupełniania JavaScript, Androida i iOS, aby zwracać tylko potrzebne pola danych miejsc.
zależy od konkretnego przypadku użycia. W zależności od tego, czy Twoja implementacja korzysta z sesji autouzupełniania, czy nie, będziemy naliczać opłaty za autouzupełnianie – na żądanie lub autouzupełnianie – na sesję.
Więcej informacji i wskazówek dotyczących wyboru odpowiedniej opcji w Twoim przypadku znajdziesz w artykule Sprawdzone metody optymalizacji kosztów autouzupełniania miejsc.
Uzyskiwanie danych z określonych pól w żądaniach szczegółów miejsca i wyszukiwań związanych z miejscem
Możesz dostosować szczegóły miejsc i żądania wyszukiwania miejsc, aby zwracać dane dla określonych pól używanych w aplikacji. Te pola są podzielone na kategorie: Podstawowe, Kontakt i Atmosfera. Żądania, które nie mają określonych pól, będą otrzymywać dane we wszystkich polach.
Płatności za prośby o informacje o miejscu zależą od rodzaju i ilości żądanych danych. Żądania, które nie mają określonych pól, będą rozliczane według pełnej stawki. Więcej informacji znajdziesz w artykułach Szczegółowe informacje o miejscu i Wyszukiwanie miejsc.
Zmniejszanie kosztów za pomocą interfejsu Geocoding API
Jeśli aplikacja obsługuje adresy wpisywane przez użytkowników, adresy te są czasami niejednoznaczne (niepełne, błędnie zapisane lub źle sformatowane). Rozpoznawaj adresy, korzystając z autouzupełniania, a potem wybieraj ich lokalizacje na podstawie identyfikatorów miejsc.
Jeśli masz dokładny adres (lub w jego pobliżu), możesz ograniczyć koszty, stosując geokodowanie zamiast autouzupełniania. Więcej informacji znajdziesz w artykule o sprawdzonych metodach dotyczących geokodowania adresów.
Jak działają limity w Google Maps Platform
Wszystkie nasze interfejsy API mają ograniczoną liczbę wywołań, które może wykonać każdy klient. Limity są konfigurowane w poszczególnych minutach. Po osiągnięciu limitu wywołań danego interfejsu API w ciągu minuty przyszłe wywołania nie będą akceptowane aż do następnej minuty.
Do limitu wliczają się tylko udane żądania i żądania, które powodują błędy serwera. Żądania, które nie przejdą uwierzytelniania, nie wliczają się do limitu.
Oprócz wymuszania limitu na minutę kilka interfejsów API Map Google wymaga egzekwowania limitów na sekundę. Wymuszanie na sekundę nie gwarantuje jednolitego wykorzystania w ciągu całej minuty ani nie zapobiegnie osiągnięciu limitu wykorzystania w tej minucie. Zapobiega to wykorzystaniu całego limitu w pierwszej sekundzie lub dwóch minutach i chroni przed przerwami w działaniu usługi w przypadku nagłego zwiększenia wykorzystania. Aby uwzględnić te różnice w egzekwowaniu zasad, zaplanuj wykorzystanie limitu i związane z nim wymagania przez uśrednienie wykorzystania QPM w przypadku zapytań na sekundę.
Interfejsy GMP API, które podlegają wymuszeniu na sekundę, to Directions API, Distance Matrix API, Elevation API, Geocoding API, Places API oraz Roads API.
Oszacuj koszty usług GMP API na podstawie łącznej liczby żądań.