W tym przewodniku opisano kilka strategii optymalizacji wykorzystania interfejsów API Map Google pod względem bezpieczeństwa, wydajności i użytkowania.
Zabezpieczenia
Sprawdzanie sprawdzonych metod zapewniania bezpieczeństwa
Klucze interfejsu API to dane logowania do konkretnych projektów, które zasługują na te same środki ostrożności co identyfikatory użytkowników i hasła. Zapoznaj się ze sprawdzonymi metodami dotyczącymi zabezpieczeń interfejsu API, aby zabezpieczyć swoje klucze przed niezamierzonym użyciem. Może to doprowadzić do nadmiernego wykorzystania limitów i nieoczekiwanych opłat na Twoim koncie.
Korzystanie z kluczy 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ż identyfikatory klientów są nadal obsługiwane, klucze interfejsu API obsługują szczegółową kontrolę bezpieczeństwa. Możesz je dostosować do działania z określonymi adresami internetowymi, adresami IP i pakietami SDK do urządzeń mobilnych (Android i iOS). Informacje o tworzeniu i zabezpieczaniu klucza interfejsu API znajdziesz na stronie „Używanie klucza interfejsu API” dla każdego interfejsu API lub pakietu SDK. (Na przykład w przypadku interfejsu API JavaScript Map Google przejdź na stronę Używanie klucza interfejsu API).
Wydajność
Postępowanie wykładnicze przy użyciu błędów do ponowienia
Jeśli w Twoich aplikacjach występują błędy w wyniku nadmiernej liczby prób wywołania interfejsu API w krótkim czasie, takich jak błędy zapytań na sekundę, rozważ użycie wykładniczego ponawiania, aby umożliwić żądania.
Wykładniczy czas do ponowienia jest najbardziej przydatny w przypadku błędów 500. Więcej informacji znajdziesz w sekcji Obsługa kodów stanu zwrotu HTTP.
W szczególności dostosuj tempo zapytań. W kodzie dodaj czas oczekiwania między zapytaniami wynoszący S s. Jeśli zapytanie nadal zwraca błąd QPS, podwój okres oczekiwania i wyślij kolejne. Kontynuuj dostosowywanie okresu oczekiwania, aż zapytanie nie zwróci błędu.
Wysyłanie na żądanie próśb o interakcję z użytkownikiem
Żądania do interfejsów API, które obejmują interakcję użytkownika, należy wysyłać tylko na żądanie.
Oznacza to, że użytkownik musi poczekać na wykonanie działania (np. on-click) w celu zainicjowania żądania do interfejsu API, a potem użyć wyników do wczytania mapy, ustawienia miejsca docelowego lub wyświetlenia odpowiednich informacji. Podejście na żądanie pozwala uniknąć niepotrzebnych żądań do interfejsów API, zmniejszając wykorzystanie interfejsów API.
Unikanie wyświetlania treści nakładki, gdy mapa się porusza
Unikaj używania metody Draw() do wyświetlania treści mapy niestandardowej w tym samym czasie, w którym użytkownik może ją przesuwać. Mapa jest rysowana ponownie po każdym przesunięciu przez użytkownika, więc jednoczesne umieszczenie na niej treści może powodować opóźnienia lub wizualne opóźnienia. Dodawaj i usuwaj nakładki na mapie tylko wtedy, gdy użytkownik przestanie przesuwać lub powiększać.
Unikam intensywnych operacji w metodach Draw
Ogólnie sprawdzoną metodą jest unikanie intensywnych operacji niewymagających rysowania w metodzie Draw(). Unikaj na przykład takich instrukcji w kodzie metody Draw():
- Zapytania zwracające dużą ilość treści.
- Wiele zmian w wyświetlanych danych.
- manipulowanie wieloma elementami modelu dokumentu (DOM);
Operacje te mogą spowalniać działanie i powodować opóźnienie lub wizualne zacinanie się podczas renderowania mapy.
Używanie obrazów rastrowych do oznaczania danych
Dodając znaczniki w celu identyfikacji lokalizacji na mapie, używaj obrazów rastrowych, np. w formacie PNG lub JPG. Unikaj stosowania obrazów SVG (Scalable Vector Graphics), ponieważ renderowanie obrazów SVG może powodować opóźnienia po ponownym narysowaniu mapy.
Znaczniki optymalizacji
Optymalizacja zwiększa skuteczność, ponieważ renderuje wiele znaczników jako pojedynczy element statyczny. Jest to przydatne w przypadkach, 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 próbuje renderować znaczniki z użyciem optymalizacji. Nie wszystkie znaczniki można zoptymalizować. W niektórych przypadkach interfejs Maps JavaScript API może wymagać renderowania bez ich stosowania. Wyłącz renderowanie zoptymalizowane dla animowanych GIF-ów lub plików PNG albo wtedy, gdy każdy znacznik musi być renderowany jako osobny element DOM.
Tworzenie klastrów do zarządzania wyświetlaniem znaczników
Aby zarządzać wyświetlaniem znaczników w celu identyfikowania lokalizacji na mapie, utwórz klaster znaczników za pomocą biblioteki Analizatora. Biblioteka klasyfikatorów znaczników zawiera następujące opcje:
- Rozmiar siatki, aby określić liczbę znaczników do zgrupowania w klastrze.
- Maksymalne powiększenie, aby określić maksymalny poziom powiększenia klastra.
- Ścieżki obrazu – obrazy przeznaczone do użycia jako ikony znaczników.
Konsumpcja
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 możliwości korzystania z interfejsu API – informuje tylko o tym, że koszty zbliżają się do określonej kwoty.
- Ogranicz dzienne wykorzystanie interfejsu API, aby zarządzać kosztami płatnych interfejsów API. 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))/30 = żądania na dzień (w przypadku jednego interfejsu API). W swojej implementacji możesz korzystać z wielu płatnych interfejsów API, więc odpowiednio dostosuj równanie. W każdym miesiącu dostępny jest środek do wykorzystania w interfejsach API Map Google w wysokości 200 USD. Pamiętaj o tym, jeśli chcesz mieć taką możliwość w obliczeniach.
- Używaj wielu projektów, aby izolować, ustalać priorytety i śledzić wykorzystanie. Załóżmy na przykład, że regularnie testujesz interfejsy API Google Maps Platform. Dzięki utworzeniu osobnego projektu na potrzeby testów – z własnymi limitami i kluczami interfejsu API – możesz dokonać gruntownych testów i jednocześnie zabezpieczyć się przed niespodziewanymi wydatkami.
Zarządzanie zużyciem w Mapach
Użycie jednej mapy na stronę jest dobrym sposobem na optymalizację wyświetlania map, ponieważ użytkownicy zwykle wchodzą w interakcję tylko z jedną mapą naraz. Twoja aplikacja może zmieniać mapę, aby wyświetlać różne zbiory danych w zależności od interakcji i potrzeb klientów.
Używanie obrazów statycznych
Żądania korzystające z dynamicznych zdjęć (dynamicznych map i dynamicznego widoku ulicy) kosztują więcej niż mapy statyczne i statyczne zdjęcia Street View. Jeśli nie przewidujesz interakcji użytkowników z mapą lub Street View (powiększeniem lub przesunięciem), użyj statycznych wersji tych interfejsów API.
Miniatury – bardzo małe mapy i zdjęcia – przydają się do zdjęć statycznych i Street View. Te elementy są rozliczane według niższej stawki i po interakcji z użytkownikiem (po kliknięciu). Mogą przejść na wersję dynamiczną, aby w pełni wykorzystać możliwości Map Google.
Korzystanie z interfejsu Maps embed API
Jeśli chcesz dodać mapę z pojedynczym znacznikiem lub mapę dynamiczną, możesz użyć bezpłatnego interfejsu API Map Google do umieszczania. Używaj interfejsu Maps embed API dla aplikacji, w których nie jest wymagane żadne pojedyncze oznaczenie bez konieczności dostosowywania mapy. Opłaty za żądania do używania interfejsu API Map Google są wysyłane w trybie wskazówek dojazdu, w trybie widoku lub w trybie wyszukiwania (szczegóły znajdziesz w tabeli cen.
Korzystanie z pakietów SDK Map Google dla aplikacji mobilnych
W przypadku aplikacji mobilnych do wyświetlania mapy użyj pakietu SDK Maps na Androida lub Maps SDK na iOS. Używaj interfejsu statycznego interfejsu API Map Google lub interfejsu API JavaScript JavaScript, gdy wymagania wykluczają Cię za pomocą mobilnych pakietów SDK.
Zarządzanie zużyciem na trasach
Ograniczenie punktów na trasie do interfejsu Route API
Gdy to możliwe, ograniczaj wpisy użytkowników w zapytaniu do maksymalnie 10 punktów pośrednich. Żądania, które zawierają więcej niż 10 punktów pośrednich, są rozliczane według wyższej stawki.
Optymalizowanie routingu za pomocą optymalizacji interfejsu Route API
Żądania używające argumentu optymalizacji punktu pośredniego są rozliczane według wyższej stawki. Więcej informacji znajdziesz w artykule Optymalizowanie punktów końcowych.
Argument optymalizacji sortuje punkty pośrednie, aby zapewnić optymalne kierowanie. W przypadku optymalizacji z A–B-C-D-E lepiej sprawdza się podróż z A do E, a nie losowa sekwencja niezoptymalizowanej trasy (np. A-D-B-C-E).
Korzystanie z modeli ruchu w czasie rzeczywistym w interfejsie Route API i Odległość Matrix API
Żądania do Route API i Odległość między interfejsami API macierzy, które obejmują modele ruchu w czasie rzeczywistym, są rozliczane według wyższej stawki.
Modele ruchu w czasie rzeczywistym są włączone, ustawiając godzinę wyjazdu na now.
Jeśli modele ruchu zostaną pominięte w żądaniu, wyniki opierają się wyłącznie na czynnikach fizycznych: drogach, odległości i ograniczeniach prędkości.
Korzystanie z przebytej trasy i najbliższej drogi, gdy dane GPS są niedokładne
Funkcje interfejsu Maps Roads API, Trasa przebyta i Najbliższa droga są zawarte w abonamencie zaawansowanym i rozliczane według wyższej stawki. Użyj tych funkcji, gdy dane GPS są niedokładne, a interfejs API Roads pomoże Ci określić właściwą drogę. Ograniczenia prędkości to kolejna funkcja dostępna w interfejsie Roads API, która jest dostępna tylko dla klientów korzystających ze śledzenia zasobów.
Próbkowanie w 5 do 15 minut w różnych lokalizacjach z ograniczeniami prędkości
Aby zminimalizować liczbę wywołań funkcji ograniczenia prędkości interfejsu Maps Roads API, próbkuj lokalizacje swoich zasobów w interwałach 5–15 min. Dokładna wartość zależy od szybkości poruszania się zasobu. Jeśli zasób jest nieruchomy, wystarczy jedna próbka lokalizacji. Nie trzeba wykonywać wielu połączeń.
Aby zminimalizować ogólne opóźnienia, wywołaj usługę ograniczenia prędkości po nagromadzeniu części danych, zamiast wywoływać interfejs API za każdym razem, gdy odbierasz lokalizację zasobu mobilnego.
Zarządzanie konsumpcją w Miejscach
Optymalizacja implementacji autouzupełniania miejsc
Aby zoptymalizować koszty korzystania z funkcji autouzupełniania miejsc:
użyj masek pól w widżetach autouzupełniania w JavaScript, Android i iOS, aby zwracać tylko potrzebne pola danych miejsca.
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, opłaty za SKU Autouzupełnianie – na żądanie lub Autouzupełnianie – na sesję.
Więcej informacji i wskazówek dotyczących wyboru odpowiedniej opcji znajdziesz w artykule Sprawdzone metody optymalizowania kosztów autouzupełniania.
Zwracanie danych dotyczących konkretnych pól w szczegółach miejsca i żądaniach wyszukiwania
Możesz dostosować szczegóły dotyczące miejsc i żądania wyszukiwania miejsc, tak aby zwracały dane dotyczące konkretnych pól używanych w aplikacji. Te pola są podzielone na kategorie: Podstawowe, Kontakt i atmosfera. Żądania, które nie określają żadnych pól, będą otrzymywać dane dotyczące wszystkich pól.
Płatności za szczegóły dotyczące miejsc zależą od typów i ilości żądanych danych. Żądania, które nie zawierają żadnych pól, będą rozliczane według pełnej stawki. Więcej informacji znajdziesz w artykułach Informacje o miejscach i Wyszukiwanie miejsc.
Obniżenie kosztów za pomocą interfejsu Geocoding API
Jeśli aplikacja obsługuje adresy wpisywane przez użytkowników, ich adresy mogą być niejednoznaczne (niepełne, błędnie zapisane lub źle sformatowane). Rozpoznaj adresy za pomocą autouzupełniania, a następnie użyj identyfikatorów miejsc, aby poznać ich lokalizację.
Jeśli masz dokładny adres (lub zbliżony do niego), możesz obniżyć koszty, korzystając z geokodowania zamiast autouzupełniania. Więcej informacji znajdziesz w artykule Sprawdzone metody geokodowania adresów.
Jak działają limity w Google Maps Platform
Wszystkie nasze interfejsy API mają ograniczoną liczbę wywołań. Limity są konfigurowane w ciągu minuty. Jeśli w ciągu minuty osiągniesz limit wywołań danego interfejsu API, przyszłe wywołania nie będą przyjmowane aż do następnej minuty.
Do limitu wliczają się tylko te żądania, które zakończyły się powodzeniem i powodują błędy serwera. Żądania, które nie przejdą uwierzytelniania, nie wliczają się do limitu.
Oprócz interfejsów API Map Google oprócz interfejsu API obowiązuje też limit sekundowy. Egzekwowanie tej zasady na sekundę nie gwarantuje jednolitego wykorzystania w ciągu całej minuty ani nie powoduje przekroczenia limitu wykorzystania na tę minutę. Funkcja ta nie zużywa całego limitu w ciągu pierwszej lub dwóch minut w dowolnym momencie i chroni Cię przed przerwami w działaniu w przypadku gwałtownego skoku zużycia. Aby poradzić sobie z tymi różnicami w sposobie egzekwowania zasad, zaplanuj wykorzystanie limitu i związane z nim wymagania, uśredniając wykorzystanie QPM na przestrzeni QPS.
Interfejsy API GMP, które korzystają z tej wymuszania sekundowej to Route API, Odległość, Matryca API, Elevation API, Geocoding API, Places API i Roads API.
Oszacuj koszty na podstawie usługi GMP API na podstawie całkowitej liczby żądań.