W tym przewodniku opisano kilka strategii optymalizacji 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 logowania skoncentrowane na projektach, które wymagają tych samych środków ostrożności takich jak identyfikatory użytkowników i hasła. Zapoznaj się z Sprawdzone metody zapewniania bezpieczeństwa interfejsów API, aby zabezpieczyć swoje klucze niezamierzone użycie, które może doprowadzić do nadmiernego wykorzystania limitu i nieoczekiwanych opłat; do swojego konta.
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 API. Mimo że korzystanie z identyfikatorów klientów jest obecnie obsługiwane, klucze interfejsu API obsługują bardziej szczegółowe opcje zabezpieczeń i można je dostosować do działania adresów internetowych, adresów IP i mobilnych pakietów SDK (Android i iOS). Informacje na temat dotyczące tworzenia i zabezpieczania klucza interfejsu API, przejdź do sekcji „Używanie klucza interfejsu API” strony dla każdej interfejsu API lub pakietu SDK. (Na przykład w przypadku Maps JavaScript API kliknij Więcej o używaniu klucza interfejsu API).
Wyniki
Używanie wykładniczego czasu do ponowienia do obsługi błędów
Jeśli w aplikacjach występują błędy z powodu nadmiernej liczby prób wywołania interfejsu API w krótkim przedziale czasu, np. w przypadku błędów zapytań na sekundę, wykładniczy czas do 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. Aby dowiedzieć się więcej, Więcej informacji znajdziesz w artykule Obsługa kodów stanu zwrotu HTTP.
a w szczególności o dostosowaniu tempa zapytań. W kodzie dodaj
czas oczekiwania między kolejnymi zapytaniami wynosi S s. Jeśli zapytanie nadal się wyświetla
w przypadku błędu QPS, dwukrotnie wydłuż okres oczekiwania i wyślij kolejne zapytanie. Dalej
dostosować okres 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, aż użytkownik wykona działanie (np. on-click)
w celu zainicjowania żądania do interfejsu API, a następnie za pomocą wyników do wczytania mapy ustaw tag
miejsca docelowego lub wyświetlać odpowiednie informacje. Użycie metody „na żądanie”
pozwala uniknąć niepotrzebnych żądań do interfejsów API, co zmniejsza wykorzystanie interfejsów API.
Unikanie wyświetlania zawartości nakładki, gdy mapa jest ruchoma
Nie używaj Draw() do jednoczesnego wyświetlania na mapie niestandardowej zawartości nakładki.
czas, w którym użytkownik przesuwa mapę. Ponieważ mapa jest rysowana ponownie
użytkownik przesuwa mapę, umieszczenie na mapie nakładki z treściami
wprowadzenie opóźnienia lub zacinania się obrazu. Dodaj lub usuń treść nakładki tylko z
gdy użytkownik przestanie przesuwać lub powiększać mapę.
Unikam intensywnych operacji w metodach Draw
Ogólnie rzecz biorąc, należy unikać wysokich wyników
operacji nierysunkowych w metodzie Draw(). Unikaj na przykład
ten kod 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óźnienie lub zacinanie się obrazu. podczas renderowania mapy.
Używanie obrazów rastrowych w znacznikach
Dodawaj obrazy rastrowe, np .w formacie PNG lub JPG. do identyfikowania lokalizacji na mapie. Unikaj korzystania ze skalowalnego wektora Obrazy graficzne (SVG), ponieważ renderowanie obrazów SVG może powodować opóźnienie, mapa jest ponownie rysowana.
Optymalizowanie znaczników
Optymalizacja zwiększa wydajność dzięki renderowaniu wielu znaczników jako jednego statycznego . Jest to przydatne, gdy wymagana jest duża liczba znaczników. Domyślnie interfejs Maps JavaScript API decyduje, czy zostanie zoptymalizowana. Jeśli jest dużo znaczników, Maps JavaScript API spróbuje renderować znaczniki z optymalizacji. Nie wszystkie znaczniki można zoptymalizować. ale czasami Maps JavaScript API może wymagać renderowania znaczników bez optymalizacji. Wyłącz zoptymalizowane renderowanie animowanych GIF-ów lub plików PNG lub każdy znacznik musi być renderowany jako oddzielny element DOM.
Tworzenie klastrów w celu zarządzania wyświetlaniem znaczników
Aby ułatwić zarządzanie wyświetlaniem znaczników służących do identyfikowania lokalizacji na mapie, utwórz klaster znaczników za pomocą funkcji Biblioteka Marker Clusterer. Biblioteka znaczników Clusterer zawiera opcje dotyczące:
- Rozmiar siatki określający liczbę znaczników do zgrupowania które są w jednym miejscu.
- maksymalne powiększenie, aby określić maksymalny poziom powiększenia, aby wyświetlić 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:
- Skonfiguruj alert dotyczący budżetu
śledzić wzrost kosztów do określonej kwoty. Ustawianie budżetu
nie ogranicza wykorzystania interfejsu API – powiadamia jedynie, kiedy koszty zbliżą się do
określoną kwotę.
- Ograniczenie dziennego wykorzystania interfejsu API w celu zarządzania kosztami interfejsów API podlegających rozliczeniu. Przez ustawienie limitów liczby żądań na dzień, możesz ograniczyć koszty. Za pomocą prostego równania określamy dzienny poziom w zależności od tego, ile chcesz wydać: (miesięcznie koszt/cena za sztukę )/30 = limit żądań dziennie (dla jednego interfejsu API). Twoja implementacja może korzystają z wielu płatnych interfejsów API, więc dostosuj równanie według potrzeb. O Środki w wysokości 200 USD na interfejsy API Map Google jest dostępna każdego miesiąca, więc uwzględnij ją w 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 API Google Maps Platform w swoich testów. Tworząc osobny projekt na potrzeby testowania – z własnymi limitami Klucze interfejsu API – można przeprowadzić dokładne testy, chroniąc się przed zaskoczeniem nadmierne wydatki.
Zarządzanie wykorzystaniem w Mapach
Użycie jednej mapy na stronę jest dobrym sposobem na optymalizację wyświetlania map, użytkownicy zwykle korzystają tylko z jednej mapy w tym samym czasie. Aplikacja może manipulować na mapie tak, aby wyświetlać różne zbiory danych w zależności od interakcji z klientem i potrzeb.
Korzystanie z obrazów statycznych
Koszt żądań, które korzystają z zdjęć dynamicznych (Mapy dynamiczne i dynamiczne Street View) niż statyczne mapy i statyczne zdjęcia Street View. Jeśli nie przewidujesz, aby użytkownik interakcji z mapą lub funkcją Street View (powiększanie lub przesuwanie), użyj obrazu tych interfejsów API.
Miniatury – bardzo małe mapy i zdjęcia – także świetnie nadają się do zdjęć statycznych. Mapy i Statyczny widok Street View. Te produkty są rozliczane według niższej stawki i w dniu interakcji użytkownika (po kliknięciu) i może kierować użytkowników do wersji dynamicznej i korzystania z Map Google.
Korzystanie z interfejsu Maps Embed API
Za pomocą interfejsu Maps Embed API możesz dodać mapę z atrybutem za pomocą jednego znacznika czy dynamicznej mapy. Użyj Maps Embed API dla aplikacji, w których pojedyncza i nie wymaga dostosowania mapy. żądań do interfejsu Maps Embed API korzystających z trybu wskazówek dojazdu; Tryb wyświetlania lub wyszukiwania będą naliczane opłaty (patrz tabela 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 podczas wyświetlania mapy. Używanie statycznego interfejsu API Map Google lub Maps JavaScript API, gdy wymagania nie są spełnione za pomocą mobilnych pakietów SDK.
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, aby zapewnić optymalne Oznacza to, że zoptymalizowanie podróży z punktu A do E jest wygodniejsze. (A-B-C-D-E) a losowa sekwencja niezoptymalizowanej trasy (np. A-D-B-C-E).
Korzystanie z modeli ruchu w czasie rzeczywistym w interfejsach Directions API i Reach Matrix API
Directions API oraz Reach Matrix API
dla żądań, 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 modele ruchu zostaną pominięte w żądaniu, wyniki będą oparte na wyłącznie na podstawie czynników fizycznych: dróg, odległości i ograniczeń prędkości.
Korzystanie z pokonanych tras Najbliższa droga, jeśli dane GPS są niedokładne
funkcje interfejsu API Maps Roads, Przebyte trasy oraz Najbliższa droga, są uwzględnione w poziomie zaawansowanym i są rozliczane według wyższej stawki. Korzystaj z tych funkcji, jeśli dane GPS są nieprecyzyjne, Interfejs Roads API może pomóc w określeniu właściwej drogi. Prędkość Limity, kolejna funkcja interfejsu Roads API, tylko dla klientów korzystających ze śledzenia komponentów.
Próbkowanie lokalizacji z ograniczeniem prędkości w odstępach 5–15 minut
Aby zminimalizować liczbę wywołań interfejsu Maps Roads API Usługa ograniczenia prędkości, próbkowanie lokalizacji zasobów w ciągu 5–15 minut interwały. Dokładna wartość zależy od szybkości, z jaką zasób jest podróżowanie. Jeśli zasób jest nieruchomy, pojedyncza próbka lokalizacji to wystarczająca. Nie ma potrzeby nawiązywania wielu połączeń.
Aby zminimalizować ogólny czas oczekiwania, wywołaj usługę ograniczania prędkości po zebrał część danych, zamiast wywoływać interfejs API za każdym razem, gdy lokalizację komponentu 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
Możesz dostosować żądania dotyczące informacji o miejscach i wyszukiwania miejsc tak, aby zwracały dane dla określonych pól użytych w aplikacji. Te pola są podzielone na: kategorie: Podstawowe, Kontakt i Atmosfera. Żądania, które nie spełniają tego wymogu Określenie, że dowolne pola będą otrzymywać dane do wszystkich pól.
Płatności za żądania dotyczące informacji o miejscu są oparte na typach i kwotach danych, których dotyczy prośba. Żądania, które nie mają określonych pól, będą rozliczane po pełnej cenie. 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, czasami są 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 poznać lokalizację danego miejsca.
Jeśli masz dokładny adres (lub w pobliżu), możesz jednak ograniczyć za pomocą geokodowania zamiast autouzupełniania. Aby dowiedzieć się więcej, zobacz Sprawdzone metody dotyczące adresów geograficznych.
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. Te limity są konfigurowane co minutę. Gdy osiągniesz limit połączeń dla danego interfejsu API w ciągu minuty, przyszłe wywołania będą akceptowane dopiero w ciągu minuty.
Wliczane są tylko udane żądania i żądania, które powodują błędy serwera limit miejsca na dane. Żądania, które nie przejdą uwierzytelniania, nie są wliczane do limitu.
W przypadku niektórych interfejsów API Map Google oprócz limitu na minutę wymuszane jest stosowanie tej zasady w ciągu sekundy dotyczących egzekwowania zasad. To wymuszanie na sekundę nie gwarantuje jednakowego wykorzystania w okresie przez całą minutę, ani nie uniemożliwi osiągnięcia limitu wykorzystania przez w tej minucie. Zapobiega to wykorzystaniu całego limitu w pierwszym okresie sekundę lub dwie w każdej minucie i chroni przed przerwami w działaniu usługi. w przypadku nagłych wzrostów wykorzystania. Aby uwzględnić te różnice, planuj wykorzystanie limitu i wymagania, uśredniając wykorzystanie QPM w poszczególnych zapytaniach na sekundę.
Interfejsy API GMP, które mają takie wymuszanie na sekundę, są Directions API, Odległość Matrix API Elevation API, Geocoding API Places API i Roads API.
Oszacuj koszty dowolnej usługi interfejsu API GMP na podstawie łącznej liczby żądań.