最佳化指南

最佳化策略

安全性

查看安全性最佳做法

API 金鑰是以專案為主的憑證,應將其視為使用者 ID 和密碼,採取同等的安全防範措施。請務必詳閱 API 金鑰最佳做法,避免因不小心誤用金鑰而不當耗用配額,導致帳戶產生非預期的費用。

使用 API 金鑰存取 Maps API

我們建議以 API 金鑰做為存取 Google Maps Platform API 時的驗證方式。儘管我們仍支援舊的用戶端 ID,但 API 金鑰能提供更精細的安全控管機制,且可搭配特定網址、IP 位址和 Mobile SDK (Android 和 iOS) 使用。想瞭解如何建立及保護 API 金鑰安全,請參閱各 API 或 SDK 適用的「取得 API 金鑰」說明文件 (例如,Maps JavaScript API 部分可參閱取得 API 金鑰)。

效能

採用指數輪詢策略來處理錯誤

如果您的應用程式在短時間內嘗試呼叫 API 的次數過多,導致發生錯誤 (例如每秒查詢次數錯誤),不妨採用指數輪詢,以便系統處理要求。

具體來說,您可以調整查詢的速度,在程式碼中新增每次查詢的間隔等候時間 (S 秒);如果還是發生每秒查詢次數錯誤,請將等候時間延長一倍,再傳送下一個查詢。繼續按照上述做法來調整等候時間,直到查詢未傳回錯誤為止。

隨需傳送使用者互動要求

內含使用者互動的 API 要求應隨需傳送;也就是說,等候使用者執行特定動作 (例如點擊) 來啟動 API 要求後,才根據結果載入地圖、設定目的地或顯示適當資訊。採用隨需模式可避免對 API 發出不必要的要求,從而降低 API 用量。

避免在地圖移動時顯示重疊內容

避免透過 Draw() 方法在使用者可能會移動地圖的時候,在地圖上顯示自訂疊加層內容。這是因為使用者每次移動地圖,系統就會重新整理;如果在該地圖上疊加內容,可能就會產生動作延遲或視覺效果不流暢的情況。因此,請務必只在使用者已停止平移或縮放地圖時,才新增或移除地圖上的疊加層內容。

避免以 Draw 方法進行大量作業

一般而言,建議盡量避免在 Draw() 方法中使用需要大量效能的非繪圖操作。舉例來說,請避免在 Draw() 方法程式碼中:

  • 進行會傳回大量內容的查詢。
  • 顯示內含許多異動的資料。
  • 操控許多文件物件模型 (DOM) 元素。

這些作業會降低效能,並在地圖算繪時造成延遲或視覺效果不流暢。

針對標記使用光柵圖像

新增標記時,可使用光柵圖像 (例如 .PNG 或 .JPG 格式的圖片) 在地圖上標示位置。避免使用可擴充向量圖形的圖片,因為在重新繪製地圖時,算繪可擴充向量圖形的圖片可能會出現延遲。

建立叢集以管理標記顯示方式

為協助您管理在地圖上用來標示位置的標記,請使用 Marker Clusterer 程式庫建立標記叢集。Marker Clusterer 程式庫提供下列選項:

  • 格線大小 - 指定叢集中標記群組的數量。
  • 最大縮放等級 - 指定顯示叢集時適用的最大縮放等級。
  • 圖片路徑 - 要當做標記圖示使用的圖形圖片所在的路徑。

最佳化耗用量

監控及限制耗用量

為方便您規劃預算及控管費用,建議您執行以下操作:

  • 設定預算快訊,掌握實際支出的累計情況。請注意,設定預算並不會限制 API 的用量,而是只讓您在支出金額接近指定門檻時收到提醒。
  • 限制每日 API 用量,控管可計費 API 的使用費。只要設定「每日要求數」上限,即可限制支出。您可以根據想要支出的金額,利用簡單的公式來算出每日上限。例如:(每月支出/單價) / 30 = 每日要求上限 (單一 API)。請注意,由於您導入的功能可能會使用多個可計費 API,因此請視需要調整上述公式。提醒您,Google 地圖平台每月會提供 $200 美元的抵免額,計算時請務必考量這一點。

地圖介面集

每頁只使用一張地圖有助提升地圖顯示效果。 通常使用者一次只會與一份地圖互動,您可以讓應用程式根據客戶的互動方式與需求,操控地圖以顯示不同的資料集。

建議使用靜態圖片

使用動態圖像 (動態地圖和動態街景服務) 的要求,費用會高於使用靜態地圖和靜態街景服務的要求。如果您認為使用者不會出現與地圖或街景服務互動 (縮放或平移) 的情況,不妨考慮使用靜態版本的 API。

此外,靜態地圖和靜態街景服務也很適合用來提供縮圖,以及非常小的地圖和相片。這些項目的費率較低,且只有在使用者互動時 (點擊時) 才導向動態版本 API,因此能提供完整的 Google 地圖體驗。

建議使用 Maps Embed API

您可以使用 Maps Embed API 加入內含單一標記或動態地圖的地圖,這項功能完全免費。如果只需要單一標記且不用自訂地圖,就可以在應用程式中使用 Maps Embed API。使用路線模式、檢視模式或搜尋模式的 Maps Embed API 要求,從現在起則需要付費 (詳情請參閱價目表)。

針對行動應用程式採用行動地圖 SDK

如要在行動應用程式中顯示地圖,請使用 Maps SDK for Android 或 Maps SDK for iOS。當要求排除使用 Mobile SDK,則採用 Maps Static API 或 Maps JavaScript API。

路徑介面集

限制 Directions API 路線控點

如果可以,請將使用者的單一查詢項目限制在 10 個路線控點以內。針對內含超過 10 個路線控點的要求,系統將以較高的費率計費。

使用 Directions API 最佳化功能規劃最佳路線

使用路線控點最佳化引數的要求,會以較高的費率計費;詳情請參閱最佳化路線控點

最佳化引數會分類路線控點,確保提供最佳路線。舉例來說,比起隨機排序的路徑 (A-D-B-C-E),經過最佳化的 A 到 E 路徑 A-B-C-D-E),能讓使用者獲得較好的體驗。

在 Directions API 和 Distance Matrix API 中使用即時車流量模型

採用即時車流量模型的 Directions API 和 Distance Matrix API 要求會以較高的費率計費;只要將出發時間設為 now 即可啟用。

如果要求省略車流量模型,則系統將單純依據實際因素 (道路、距離和速度限制) 來計算結果。

在 GPS 資料不精確時使用「行經的路徑」和「最近的道路」

Maps Roads API 地圖項目 (「行經的路徑」及「最近的道路」) 現已歸入進階層級,費率也比較高。GPS 資料無法精準定位時可採用這些地圖項目,Roads API 可協助判斷正確的道路。另一個 Roads API 地圖項目「速限」則只提供給資產追蹤客戶使用。

每隔 5 到 15 分鐘對設有速限的地區進行取樣

為盡量減少對 Maps Roads API 速限服務的呼叫量,請將資產位置的取樣時間間隔設為 5 到 15 分鐘;確切的值則取決於資產的移動速度。針對未移動的資產,只要一個位置樣本就夠了,不需要多次呼叫。

建議您在累積到一定的資料量後,才呼叫速限服務,而不是每收到一次行動資產的位置就呼叫 API;這樣有助於減少整體延遲時間。

地點介面集

根據用途採用合適的自動完成選項

請根據您的使用需求,選用合適的自動完成功能。兩種選項的費用一樣,差別只在於應用程式使用者的 API 使用方式。

  • 自動完成 - 按要求計費:只需要傳送單一項目 (例如使用者填寫的郵寄地址表單) 時,適合採用這個選項。
  • 自動完成 - 按工作階段計費:如果需要多個查詢項目 (例如搜尋飯店或餐廳),則適合採用這個選項。

「自動完成 - 按工作階段計費」沒有查詢結果次數限制 (無論用什麼方式導入權杖來確保工作階段有效)。採用「自動完成 - 按要求計費」時,如果發生無效工作階段,則會依按鍵動作計費,這可能導致產生更高的費用。如要進一步瞭解這項功能,請參閱地點自動完成

在地點詳細資料和地點搜尋要求中傳回特定欄位的資料

您可以自訂「地點詳細資料」和「地點搜尋」要求,傳回應用程式中特定欄位的資料。這些欄位可區分為「基本」、「聯絡」和「氣氛」類別。未指定任何欄位的要求則會接收所有欄位的資料。

「地點詳細資料」要求的費用取決於所要求的資料類型和資料量。未指定任何欄位的要求將按完整費率計費。詳情請參閱地點詳細資料地點搜尋

使用 Geocoding API 降低費用成本

假如您的應用程式會處理由使用者輸入的地址,則地址可能會不太明確 (不完整、拼字錯誤或格式錯誤)。如要避免地址含糊不清,建議採用「自動完成」功能,然後再使用地點 ID 來取得地點位置。

如果您已有確切地址 (或接近的地址),就不需要使用自動完成功能,選用 Geocoding API 可減少費用成本。詳情請參閱地理編碼地址最佳做法