W tym przewodniku opisujemy kilka strategii optymalizacji wykorzystania interfejsów API Map Google pod kątem bezpieczeństwa, wydajności i wykorzystania.
Bezpieczeństwo
Sprawdzanie sprawdzonych metod zapewniania bezpieczeństwa
Klucze interfejsu API to dane uwierzytelniające związane z projektami, które podlegają takim samym środkom ostrożności co identyfikatory użytkowników i hasła. Zapoznaj się ze sprawdzonymi metodami zapewniania bezpieczeństwa interfejsów API, aby zabezpieczyć klucze przed niezamierzonym użyciem, które może spowodować nadmierne wykorzystanie limitu i nieoczekiwane opłaty na koncie.
Dostęp do interfejsów API Map Google za pomocą kluczy interfejsu API
Klucze interfejsu API są preferowaną metodą uwierzytelniania przy dostępie do interfejsów API Map Google. Chociaż korzystanie z identyfikatorów klienta jest nadal obsługiwane, klucze interfejsu API obsługują bardziej szczegółową kontrolę bezpieczeństwa i można je skonfigurować pod kątem działania z określonymi adresami internetowymi, adresami IP oraz mobilnymi pakietami SDK (na Androida i iOS). Informacje o tworzeniu i zabezpieczaniu klucza interfejsu API znajdziesz na stronie „Używanie klucza interfejsu API” w przypadku każdego interfejsu API lub pakietu SDK. W przypadku interfejsu Maps JavaScript API odwiedź jego stronę Używanie klucza interfejsu API.
Wydajność
Używanie wykładniczego czasu do ponowienia do obsługi błędów
Jeśli w aplikacjach występują błędy (np. błędy zapytań na sekundę) wynikające z nadmiernych prób wywołania interfejsu API w krótkim czasie, rozważ zastosowanie wykładniczego ponowienia, aby umożliwić przetwarzanie żą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 artykule Obsługa kodów stanu zwrotu HTTP.
a w szczególności o dostosowaniu tempa zapytań. Dodaj w kodzie okres oczekiwania wynoszący S s między zapytaniami. Jeśli zapytanie nadal będzie powodować błąd zapytań na sekundę, dwukrotnie wydłuż okres oczekiwania i wyślij kolejne zapytanie. Kontynuuj dostosowywanie okresu oczekiwania, aż zapytanie zwróci się bez błędu.
wysyłanie na żądanie żądań dotyczących interakcji z użytkownikiem;
Żądania do interfejsów API, które obejmują interakcję użytkownika, powinny być wysyłane tylko na żądanie.
Oznacza to oczekiwanie na wykonanie przez użytkownika działania (takiego jak on-click), aby zainicjować żądanie do interfejsu API, a następnie wykorzystanie wyników do wczytania mapy, ustawienia miejsca docelowego lub wyświetlenia odpowiednich informacji. Korzystanie z usługi na żądanie pozwala uniknąć zbędnych żądań wysyłanych do interfejsów API, co zmniejsza wykorzystanie tych interfejsów.
Unikanie wyświetlania zawartości nakładki, gdy mapa jest ruchoma
Nie używaj elementu Draw() do wyświetlania na mapie niestandardowej zawartości nakładki, gdy użytkownik może przesuwać mapę. Mapa jest rysowana ponownie za każdym razem, gdy użytkownik przesuwa mapę, więc jednoczesne umieszczenie na niej nakładki z danymi może wywołać opóźnienie lub zacinanie się. Zawartość nakładki z mapą możesz dodawać i usuwać dopiero wtedy, gdy użytkownik przestanie przesuwać i powiększać mapę.
Unikam intensywnych operacji w metodach Draw
Ogólnie w metodzie Draw() należy unikać operacji, które nie wymagają dużego wydajności i nie są rysowane. Unikaj na przykład tych elementów w kodzie metody Draw():
- Zapytania, które zwracają dużą ilość treści.
- Wiele zmian w wyświetlanych danych.
- manipulowanie wieloma elementami DOM (Document Object Model).
Operacje te mogą spowolnić działanie i wprowadzić opóźnienia lub zacinanie się podczas renderowania mapy.
Używanie obrazów rastrowych w znacznikach
Dodając znaczniki do określania lokalizacji na mapie, używaj obrazów rastrowych, np. obrazów w formacie PNG lub JPG. Unikaj korzystania z obrazów SVG (Scalable Vector Graphics), ponieważ renderowanie obrazów SVG może powodować opóźnienia podczas ponownego renderowania mapy.
Optymalizowanie znaczników
Optymalizacja zwiększa wydajność, renderując wiele znaczników jako pojedynczy element statyczny. Jest to przydatne, gdy wymagana jest duża liczba znaczników. Domyślnie to, czy znacznik zostanie zoptymalizowany, decyduje interfejs Maps JavaScript API. W przypadku dużej liczby znaczników interfejs Maps JavaScript API spróbuje renderować 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 animowanych GIF-ów lub plików PNG albo gdy każdy znacznik musi być renderowany jako oddzielny element DOM.
Tworzenie klastrów w celu zarządzania wyświetlaniem znaczników
Aby łatwiej zarządzać wyświetlaniem znaczników w celu identyfikowania lokalizacji na mapie, utwórz klaster znaczników za pomocą biblioteki Marker Clusterer. Biblioteka znaczników Clusterer zawiera opcje dotyczące:
- Rozmiar siatki określający liczbę znaczników do zgrupowania w klastrze.
- Maksymalne powiększenie, aby określić maksymalny poziom powiększenia, przy którym będzie wyświetlany klaster.
- Ścieżki obrazów – obrazy grafiki używane jako ikony znaczników.
Oglądanie treści
Aby zaplanować budżet i kontrolować koszty, wykonaj następujące czynności:
- Ustaw alert dotyczący budżetu, aby śledzić wzrost kosztów do określonej kwoty. Ustawienie budżetu nie ogranicza wykorzystania interfejsu API – powiadamia on tylko wtedy, gdy koszty zbliżą się do określonej kwoty.
- Ogranicz dzienne korzystanie z interfejsów API, aby zarządzać kosztami interfejsów API podlegających rozliczeniu. Ustawiając limity liczby żądań dziennie, możesz ograniczyć koszty. Użyj prostego równania, aby określić dzienny limit w zależności od tego, ile chcesz wydać: (miesięczny koszt/cena za sztukę)/30 = limit żądań dziennie (w przypadku 1 interfejsu API). Twoja implementacja może korzystać z wielu płatnych interfejsów API, więc dostosuj równanie według potrzeb. Co miesiąc otrzymujesz środki na interfejs API Map Google o wartości 200 USD, więc uwzględnij je w swoich obliczeniach.
- Używaj wielu projektów, aby izolować i śledzić wykorzystanie zasobów oraz ustalać ich priorytety. Załóżmy na przykład, że regularnie używasz interfejsów Google Maps Platform API w testach. Tworząc do testowania oddzielny projekt z własnymi limitami i kluczami interfejsu API, możesz przeprowadzać dokładne testy, chroniąc się jednocześnie przed niespodziewanymi nadmiernymi wydatkami.
Zarządzanie wykorzystaniem w Mapach
Użycie 1 mapy na stronę to dobry sposób na optymalizację wyświetlania map, ponieważ użytkownicy zwykle korzystają z jednej mapy naraz. Aplikacja może manipulować mapą, aby wyświetlać różne zbiory danych w zależności od interakcji i potrzeb klienta.
Korzystanie z obrazów statycznych
Żądania korzystające ze zdjęć dynamicznych (dynamiczne mapy i dynamiczne Street View) kosztują więcej niż Mapy statyczne i statyczne Street View. Jeśli nie przewidujesz interakcji użytkowników z Mapami lub Street View (powiększanie lub przesuwanie), użyj statycznych wersji tych interfejsów API.
Miniatury – bardzo małe mapy i zdjęcia – również dobrze się sprawdzają w statycznych mapach i statycznych zdjęciach Street View. Te elementy są rozliczane według niższej stawki i za interakcję użytkownika (po kliknięciu) i mogą przekierowywać użytkowników do wersji dynamicznej umożliwiającej korzystanie z pełnej wersji 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ą. Interfejsu Maps Embed API używaj w aplikacjach, w których wymagane jest używanie pojedynczego znacznika i nie wymaga dostosowywania mapy. Opłaty będą naliczane za żądania interfejsu Maps Embed API korzystające z trybu wskazówek dojazdu, trybu wyświetlania lub trybu wyszukiwania (szczegóły znajdziesz w tabeli cen).
Korzystanie z pakietów SDK map na urządzenia mobilne w aplikacjach mobilnych
W przypadku aplikacji mobilnych użyj pakietu Maps SDK na Androida lub Maps SDK na iOS do wyświetlania mapy. Jeśli wymagania nie wymagają używania mobilnych pakietów SDK, użyj Maps Static API lub Maps JavaScript API.
Zarządzanie wykorzystaniem w trasach
Ograniczanie punktów pośrednich interfejsu Directions API
Jeśli to możliwe, ogranicz wpisy użytkowników w zapytaniu do maksymalnie 10 punktów pośrednich. Żądania zawierające więcej niż 10 punktów pośrednich są rozliczane według wyższej stawki.
Korzystanie z optymalizacji interfejsu Directions API w celu uzyskania optymalnego routingu
Żądania używające argumentu optymalizacji punktu pośredniego są rozliczane według wyższej stawki. Aby dowiedzieć się więcej, poczytaj o optymalizacji punktów pośrednich.
Argument optymalizacji sortuje punkty pośrednie w celu zapewnienia optymalnego wyznaczania trasy. Oznacza to, że podróż z punktu A do E jest wygodniejszy w przypadku optymalizacji (A-B-C-D-E) w porównaniu z losową sekwencją niezoptymalizowanej trasy (np. A-D-B-C-E).
Korzystanie z modeli ruchu w czasie rzeczywistym w interfejsach Directions API i Reach Matrix API
Żądania do interfejsów Directions API i Reach Matrix API, które obejmują modele ruchu w czasie rzeczywistym, są rozliczane według wyższej stawki.
Modele ruchu w czasie rzeczywistym można włączyć, ustawiając czas odjazdu na now.
Jeśli w żądaniu pominiesz modele ruchu, wyniki będą zależeć wyłącznie od czynników fizycznych, takich jak drogi, odległość i ograniczenia prędkości.
Korzystanie z danych dotyczących przebytej trasy i najbliższej drogi w przypadku niedokładności danych GPS
Funkcje interfejsu Maps Roads API, „Przebyta trasa” i „Najbliższa droga” są dostępne w poziomie zaawansowanym i są rozliczane według wyższej stawki. Skorzystaj z tych funkcji, gdy dane GPS są niedokładne, a interfejs Road API pomoże Ci określić właściwą drogę. Ograniczenia prędkości to inna funkcja interfejsu Roads API, która jest dostępna tylko dla klientów Asset Tracking.
Próbkowanie lokalizacji z ograniczeniem prędkości w odstępach 5–15 minut
Aby zminimalizować liczbę wywołań usługi Ograniczenie szybkości interfejsu Maps Roads API, próbkuj lokalizacje swoich zasobów z częstotliwością od 5 do 15 minut. Dokładna wartość zależy od prędkości, z jaką porusza się zasób. Jeśli zasób jest nieruchomy, wystarczy 1 próbka lokalizacji. Nie ma potrzeby nawiązywania wielu połączeń.
Aby zminimalizować ogólny czas oczekiwania, wywołuj usługę ograniczania prędkości po zgromadzeniu pewnej ilości danych, zamiast wywoływać interfejs API za każdym razem, gdy odbierana jest lokalizacja zasobu mobilnego.
Zarządzanie wykorzystaniem w Miejscach
Optymalizowanie implementacji autouzupełniania miejsc
Aby zoptymalizować koszt korzystania z autouzupełniania miejsc:
używać masek pól w widżetach autouzupełniania JavaScript, Android i iOS, aby zwracać tylko potrzebne pola danych miejsc.
Wybór opcji płatności zależy od konkretnego przypadku użycia. W zależności od tego, czy Twoja implementacja korzysta z sesji autouzupełniania, naliczane będą kody SKU Autouzupełnianie – według żądania lub Autouzupełnianie – na sesję.
Więcej informacji i wskazówek dotyczących wyboru odpowiedniej opcji w danym przypadku znajdziesz w artykule Sprawdzone metody optymalizacji kosztów autouzupełniania miejsc.
Zwracanie danych dla określonych pól w żądaniach informacji o miejscu i wyszukiwania miejsc
Żądania dotyczące informacji o miejscach i wyszukiwania miejsc można dostosować tak, aby zwracały dane dotyczące określonych pól użytych w zgłoszeniu. Pola te są podzielone na kategorie: Podstawowe, Kontakt i Atmosfera. Żądania, które nie mają określonych pól, otrzymują dane do wszystkich pól.
Płatności za żądania dotyczące informacji o miejscu są ustalane na podstawie typów 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 można znaleźć w sekcjach Szczegóły miejsca i Wyszukiwanie miejsc.
Zmniejszanie kosztów za pomocą interfejsu Geocoding API
Jeśli aplikacja obsługuje adresy wpisywane przez użytkowników, adresy są czasami niejednoznaczne (niepełne, błędnie napisane lub źle sformatowane). Wyróżnij adresy za pomocą autouzupełniania, a następnie użyj identyfikatorów miejsc, aby określić lokalizację miejsc.
Jeśli jednak masz dokładny adres (lub w pobliżu), możesz zmniejszyć koszty, korzystając z geokodowania zamiast z autouzupełniania. Więcej informacji znajdziesz w artykule Sprawdzone metody dotyczące geokodowania adresów.
Jak działają limity w Google Maps Platform
Wszystkie nasze interfejsy API mają ograniczoną liczbę połączeń, które może wykonać każdy klient. Limity te są konfigurowane co minutę. Gdy w ciągu minuty osiągniesz limit wywołań danego interfejsu API, przyszłe wywołania będą akceptowane dopiero w najbliższej minucie.
Do limitu wliczają się tylko udane żądania i żądania, które powodują błędy serwera. Żądania, które nie przejdą uwierzytelniania, nie są wliczane do limitu.
W przypadku kilku interfejsów API Map Google oprócz egzekwowania limitu na minutę obowiązują także wymagania dotyczące limitu na minutę. To wymuszanie na sekundę nie gwarantuje jednakowego wykorzystania w całej minucie ani nie uniemożliwia osiągnięcia limitu wykorzystania w danej minucie. Zapobiega wykorzystaniu całego limitu w ciągu pierwszej sekundy lub dwóch minut z danej minuty, a także chroni przed przerwami w działaniu usługi w przypadku nagłego zwiększenia wykorzystania. Aby poradzić sobie z tymi różnicami w egzekwowaniu zasad, zaplanuj wykorzystanie limitu i wymagania, uśredniając wykorzystanie QPM w stosunku do zapytań na sekundę.
Interfejsy API GMP, w przypadku których obowiązuje takie egzekwowanie na sekundę, to Directions API, Reach Matrix API, Elevation API, Geocoding API, Places API i Roads API.
Oszacuj koszty dowolnej usługi interfejsu API GMP na podstawie łącznej liczby żądań.