W tym przewodniku opisano kilka strategii optymalizacji interfejsów Map Google pod kątem bezpieczeństwa, wydajności i zużycia.
Bezpieczeństwo
Sprawdzone metody zapewniania bezpieczeństwa
Klucze interfejsu API to dane logowania związane z projektem, które wymagają takich samych środków ostrożności co identyfikatory użytkowników i hasła. Zapoznaj się ze sprawdzonymi metodami dotyczącymi bezpieczeństwa interfejsu API, aby zabezpieczyć klucze przed nieumyślnym użyciem, które może prowadzić do nieuzasadnionego wykorzystania limitu i nieoczekiwanych obciążeń na Twoim koncie.
Korzystanie z kluczy interfejsu API do uzyskiwania dostępu do interfejsów API Map Google
Klucze interfejsu API to preferowana metoda uwierzytelniania umożliwiająca dostęp do interfejsów API Map Google. Identyfikatory klienta są nadal obsługiwane, ale klucze API umożliwiają bardziej szczegółowe kontrolowanie zabezpieczeń i można je dostosować do działania z określonymi adresami internetowymi, adresami IP i pakietami SDK na urządzenia mobilne (na Androida i iOS). Informacje o tworzeniu i ochranianiu klucza interfejsu API znajdziesz na stronie „Korzystanie z klucza interfejsu API” w przypadku każdego interfejsu API lub pakietu SDK. (np. w przypadku interfejsu Maps JavaScript API otwórz stronę Korzystanie z klucza interfejsu API).
Wyniki
Obsługa błędów za pomocą wzrastającego czasu do ponowienia
Jeśli w Twoich aplikacjach występują błędy spowodowane nadmierną liczbą prób wywołania interfejsu API w krótkim czasie, np. błędy dotyczące limitu, rozważ użycie wykładniczego wycofywania, aby umożliwić przetwarzanie żądań.
Wzrost opóźnienia jest najbardziej przydatny w przypadku błędów 500. Więcej informacji znajdziesz w artykule Praca z kodami stanu HTTP.
W szczególności dostosuj tempo swoich zapytań. W kodzie dodaj okres oczekiwania S sekund między zapytaniami. Jeśli zapytanie nadal powoduje błąd związany z kwotą, podwójnie wydłuż czas oczekiwania, a potem prześlij kolejne zapytanie. Kontynuuj dostosowywanie czasu oczekiwania, aż zapytanie zwróci wynik bez błędu.
Wysyłanie żądań interakcji z użytkownikiem na żądanie
Żądania do interfejsów API, które wymagają interakcji z użytkownikiem, powinny być wysyłane tylko na żądanie.
Oznacza to, że musisz poczekać, aż użytkownik wykona jakieś działanie (np. on-click), aby zainicjować żądanie interfejsu API, a potem użyć wyników do załadowania mapy, ustawienia miejsca docelowego lub wyświetlenia odpowiednich informacji. Korzystanie z metody na żądanie pozwala uniknąć niepotrzebnych żądań do interfejsów API, co zmniejsza ich zużycie.
Unikanie wyświetlania nakładki podczas poruszania mapy
Unikaj używania Draw() do wyświetlania niestandardowych treści nakładki na mapie w tym samym czasie, gdy użytkownik może przemieszczać mapę. Mapa jest odtwarzana za każdym razem, gdy użytkownik ją przesuwa, więc umieszczanie na niej nakładki w tym samym momencie może powodować opóźnienia lub zacinanie się obrazu. Dodawaj i usuwaj na mapie elementy nakładki dopiero wtedy, gdy użytkownik przestanie przewijać mapę lub powiększać jej widok.
Unikaj intensywnych operacji w metodach Draw
Ogólnie rzecz biorąc, w metodzie Draw() należy unikać operacji niewymagających rysowania, które mają duży wpływ na wydajność. Na przykład w kodzie metody Draw() unikaj tych elementów:
- zapytania zwracające dużą ilość treści;
- wiele zmian w wyświetlanych danych.
- manipulowanie wieloma elementami modelu DOM;
Te operacje mogą spowolnić działanie aplikacji i spowodować opóźnienia lub zacinanie się mapy podczas renderowania.
Używanie obrazów rastrowych jako znaczników
Podczas dodawania znaczników, które mają identyfikować lokalizację na mapie, używaj obrazów rastrowych, takich jak pliki PNG lub JPG. Unikaj używania obrazów w formacie SVG, ponieważ renderowanie obrazów SVG może powodować opóźnienia podczas ponownego rysowania mapy.
znaczniki optymalizacji,
Optymalizacja zwiększa wydajność, renderując wiele znaczników jako pojedynczy element statyczny. Jest to przydatne w przypadku, gdy wymagana jest duża liczba znaczników. Domyślnie interfejs Maps JavaScript API sam decyduje, czy dany znacznik ma być optymalizowany. Jeśli jest duża liczba znaczników, interfejs Maps JavaScript API spróbuje je wyrenderować z optymalizacją. Nie wszystkie znaczniki można zoptymalizować. W niektórych sytuacjach interfejs Maps JavaScript API może być zmuszony do renderowania znaczników bez optymalizacji. Wyłącz optymalizowane renderowanie animowanych GIF-ów lub plików 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 służących do identyfikowania lokalizacji na mapie, utwórz klaster znaczników za pomocą biblioteki MarkerClusterer. Biblioteka Marker Clusterer zawiera opcje:
- Rozmiar siatki, aby określić liczbę znaczników do zgrupowania w klastrze.
- Maksymalne powiększenie, aby określić maksymalny poziom powiększenia, w którym ma być wyświetlany klaster.
- Ścieżki obrazów, które mają służyć jako ikony znaczników.
Oglądanie treści
Aby zaplanować budżet i kontrolować koszty:
- Ustaw alert dotyczący budżetu, aby śledzić, jak rosną Twoje koszty w stosunku do określonej kwoty. Ustawienie budżetu nie ogranicza możliwości korzystania z interfejsu API – tylko wysyła powiadomienie, gdy koszty zbliżają się do określonej kwoty.
- Ogranicz dzienne zużycie interfejsu API, aby zarządzać kosztami interfejsów płatnych. Możesz ograniczyć koszty, ustawiając limit żądań na dzień. Aby określić dzienny limit, użyj prostego wzoru, który zależy od tego, ile chcesz wydać: (miesięczny koszt/cena za sztukę)/30 = limit żądań na dzień (dla jednego interfejsu API). Wdrożenie może używać wielu płatnych interfejsów API, dlatego dostosuj obliczenia zgodnie z potrzebami. Każdego miesiąca możesz korzystać z 200 USD środków na interfejsy API Map Google, więc uwzględnij to w swoich obliczeniach.
- Używaj wielu projektów, aby izolować, ustalać priorytety i śledzić wykorzystanie. Załóżmy na przykład, że regularnie używasz interfejsów API Google Maps Platform w swoich testach. Utworzenie osobnego projektu do testowania (z własnymi limitami i kluczami interfejsu API) pozwoli Ci dokładnie przetestować kampanię, a zarazem uniknąć niespodziewanego przekroczenia wydatków.
Zarządzanie zużyciem w Mapach
Używanie na stronie jednej mapy jest dobrym sposobem na optymalizację wyświetlania map, ponieważ użytkownicy zwykle korzystają tylko z jednej mapy naraz. Aplikacja może manipulować mapą, aby wyświetlać różne zbiory danych w zależności od interakcji z klientem i jego potrzeb.
Używanie obrazów statycznych
Prośby o zdjęcia dynamiczne (dynamiczne mapy i dynamiczne Street View) są droższe niż prośby o zdjęcia statyczne (statyczne mapy i statyczne Street View). Jeśli nie przewidujesz interakcji użytkownika z Mapami Google ani Street View (powiększania ani przesuwania), użyj statycznej wersji tych interfejsów API.
Miniatury – bardzo małe mapy i zdjęcia – to kolejne zastosowanie Map Statycznych i Statycznego Street View. Te elementy są rozliczane po niższej stawce i po interakcji użytkownika (po kliknięciu), a użytkownicy mogą przejść do wersji dynamicznej, aby uzyskać pełną wersję Map Google.
Korzystanie z interfejsu Maps Embed API
Za pomocą interfejsu Maps Embed API możesz bezpłatnie dodać mapę z pojedynczym znacznikiem lub mapę dynamiczną. Używaj interfejsu Maps Embed API w przypadku aplikacji, w których potrzebny jest tylko 1 znacznik i nie jest wymagana żadna personalizacja mapy. Żądania interfejsu Maps Embed API korzystające z trybu Wskazówki dojazdu, Trybu wyświetlania lub Trybu wyszukiwania będą rozliczane (szczegóły znajdziesz w tabeli cen).
Korzystanie z pakietów SDK map mobilnych w przypadku aplikacji mobilnych
W przypadku aplikacji mobilnych, podczas wyświetlania mapy użyj pakietu Maps SDK na Androida lub Maps SDK na iOS. Używaj interfejsu Maps Static API lub Maps JavaScript API, gdy wymagania wykluczają użycie pakietów SDK na urządzenia mobilne.
Zarządzanie zużyciem w programie Routes
Ograniczanie punktów pośrednich interfejsu Directions API
Jeśli to możliwe, ogranicz liczbę wpisów użytkownika w zapytaniu do maksymalnie 10 punktów drogi. Zapytania zawierające więcej niż 10 punktów drogi są rozliczane według wyższej stawki.
Korzystanie z optymalizacji interfejsu Directions API w celu uzyskania optymalnej trasy
Za żądania korzystające z argumentu optymalizacji punktu kontrolnego naliczana jest wyższa stawka. Więcej informacji znajdziesz w artykule Optymalizowanie punktów drogi.
Argument optymalizacji sortuje punkty pośrednie, aby zapewnić optymalne trasy. Oznacza to, że podróż z A do E będzie bardziej płynna, jeśli zostanie zoptymalizowana (A-B-C-D-E), a nie będzie miała losowej sekwencji nieoptymalizowanej trasy (np. A-D-B-C-E).
Korzystanie z modeli natężenia ruchu w czasie rzeczywistym w interfejsach Directions API i Distance Matrix API
Żądania interfejsu Directions API i interfejsu Distance Matrix API, które obejmują modele ruchu w czasie rzeczywistym, są obciążane wyższą stawką.
Modele natężenia ruchu w czasie rzeczywistym są włączane przez ustawienie czasu wyjazdu na now.
Jeśli w prośbie pominięto modele ruchu, wyniki będą zależeć wyłącznie od czynników fizycznych: dróg, odległości i ograniczeń prędkości.
Używanie opcji Przebyta trasa i Najbliższa droga, gdy dane GPS są niedokładne
Funkcje interfejsu Maps Roads API, czyli Przebyta trasa i Najbliższa droga, są dostępne w pakiecie zaawansowanym i obliczane według wyższej stawki. Używaj tych funkcji, gdy dane GPS są niedokładne, a interfejs Roads API może pomóc w określeniu właściwej drogi. Limity prędkości, kolejna funkcja interfejsu Roads API, jest dostępna tylko dla klientów korzystających z usługi Asset Tracking.
próbkowanie lokalizacji ograniczeń prędkości w odstępach 5–15 minut;
Aby zminimalizować liczbę wywołań interfejsu Maps Roads API w usłudze Limit prędkości, pobieraj próbki lokalizacji zasobów w odstępach 5–15 minut. Dokładna wartość zależy od prędkości, z jaką porusza się zasób. Jeśli zasób jest nieruchomy, wystarczy próbka z jednej lokalizacji. Nie musisz wykonywać wielu połączeń.
Aby zminimalizować ogólny czas oczekiwania, wywołaj usługę Limit prędkości po zebraniu pewnych danych, a nie wywołuj interfejsu API za każdym razem, gdy otrzymasz lokalizację zasobu mobilnego.
Zarządzanie konsumpcją w Miejscach
Optymalizowanie implementacji autouzupełniania miejsc
Aby zoptymalizować koszty korzystania z autouzupełniania miejsc:
używać masek pól w widżetach autouzupełniania w JavaScript, Android i iOS, aby zwracać tylko potrzebne pola danych o miejscach.
Wybór opcji płatności zależy od przypadku użycia. W zależności od tego, czy Twoja implementacja korzysta z sesji Autocomplete, zostaniesz obciążony opłatą za SKU Autocomplete – za żądanie lub Autocomplete – za sesję.
Więcej informacji i wskazówki dotyczące wyboru odpowiedniej opcji znajdziesz w artykule Sprawdzone metody optymalizacji kosztów autouzupełniania miejsc.
Zwracanie danych dotyczących określonych pól w żądaniach informacji o miejscu i wyszukiwania miejsc
Możesz dostosowywać żądania dotyczące szczegółów miejsca i wyszukiwania miejsca, aby zwracać dane z 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, otrzymają dane dla wszystkich pól.
Opłaty za żądania dotyczące szczegółów miejsca są naliczane na podstawie typów i ilości danych. Za żądania, które nie zawierają żadnych pól, zostanie naliczona pełna opłata. Więcej informacji znajdziesz w artykułach Szczegóły miejsca i Wyszukiwanie miejsc.
Obniżanie kosztów za pomocą interfejsu Geocoding API
Jeśli Twoja aplikacja obsługuje adresy wpisywane przez użytkownika, adresy te są czasami niejednoznaczne (niekompletne, z błędami ortograficznymi lub źle sformatowane). Wyodrębnij adresy za pomocą autouzupełniania, a potem użyj identyfikatorów miejsc, aby uzyskać ich lokalizacje.
Jeśli masz dokładny adres (lub adres zbliżony do dokładnego), 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 Google Maps Platform
Wszystkie nasze interfejsy API mają limity dotyczące liczby wywołań, które może wykonać każdy klient. Te limity są konfigurowane na poziomie minuty. Gdy osiągniesz limit połączeń w danym interfejsie API w ciągu minuty, kolejne połączenia nie będą akceptowane do następnej minuty.
Do limitu wliczane są tylko żądania, które zostały zrealizowane, oraz żądania, które spowodowały błędy serwera. Prośby, które nie przeszły uwierzytelniania, nie są wliczane do limitu.
Szacowanie kosztów korzystania z dowolnego interfejsu GMP API na podstawie łącznej liczby żądań.