优化指南

本指南从安全性、性能和消耗这三个方面介绍了优化 Google Maps API 用量的几种策略。

安全性

查看安全性最佳做法

API 密钥是以项目为中心的凭据,采取的预防措施应与用户 ID 和密码相同。查看 API 密钥最佳做法,以防密钥被意外使用,这可能导致过度使用配额,使您的帐号产生意料之外的费用。

使用 API 密钥访问 Maps API

API 密钥是访问 Google Maps API 的首选身份验证方法。虽然我们目前仍支持客户端 ID,但 API 密钥支持更精细的安全控制措施,并可进行调整,从而与特定网址、IP 地址和移动 SDK(Android 和 iOS)配合使用。如需了解如何创建及保管 API 密钥,请转到各个 API 或 SDK 对应的“使用 API 密钥”页面(例如,如果您使用的是 Maps JavaScript API,请访问该 API 对应的使用 API 密钥页面)。

性能

使用指数退避算法处理错误

如果您的应用因短时间内多次尝试调用 API 而出现错误(如 QPS 错误),请考虑使用指数退避算法来处理请求。

具体而言,您可以调整查询的速度。在代码中,在查询之间添加 S 秒的等待期。如果查询仍导致 QPS 错误,请将等待期延长一倍,然后再发送另一个查询。继续调整等待期,直到查询不再返回错误。

按需发送用户互动请求

应按需发送向 API 发出包含用户互动的请求。这意味着,需要等到最终用户执行某项操作(例如 on-click)后再发起 API 请求,然后使用结果来加载地图、设置目的地或显示适当的信息。在需要时再发送可避免向 API 发出不必要的请求,从而减少 API 消耗。

不要在地图移动时显示叠加层内容

用户可能在移动地图时,不要使用 Draw() 方法在地图上显示自定义叠加层内容。每次用户移动地图时,系统都会重新绘制地图,因此,在用户移动地图的同时在地图上放置叠加层内容可能会导致延迟或视觉卡顿。请仅在用户停止平移或缩放后,才在地图上添加或移除叠加层内容。

不要通过 Draw 方法执行密集型操作

一般来说,最好不要在 Draw() 方法中添加高性能非绘制操作。例如,Draw() 方法代码中应避免包含以下操作:

  • 将返回大量内容的查询。
  • 对正在显示的数据进行多项更改。
  • 处理多个文档对象模型 (DOM) 元素。

这些操作可能会降低性能,且在地图渲染时会出现延迟或视觉卡顿。

使用光栅图片做标记

在添加标记以标识地图上的位置时,请使用光栅图片(例如 .PNG 或 .JPG 格式的图片)。不要使用可缩放矢量图形 (SVG) 图片,因为在重新绘制地图时,渲染 SVG 图片可能会导致延迟。

创建集群以管理标记显示

为了帮助您管理标记(用于标识地图上的位置)显示,请使用标记聚类器库创建一个标记集群。标记聚类器库包含针对以下各项的选项:

  • 网格大小:可用来指定要组合到一个集群中的标记数量。
  • 最大缩放级别:可用来指定用于显示集群的最大缩放级别。
  • 用作标记图标的图形图片的图片路径。

消耗

为了规划预算并控制费用,您可以执行以下操作:

  • 设置预算提醒,以跟踪费用是如何达到特定金额的。设置预算不会限制 API 的使用,只会在费用接近指定金额时提醒您。
  • 限制每日 API 用量,以管理可计费 API 的费用。通过设置每日请求数上限,您可以限制支出。使用简单的等式即可确定每日请求数上限,上限取决于您希望支出的金额:(每月费用/每个请求的价格)/30 = 每日请求数上限(针对一个 API)。您的具体实现可能会使用多个可计费的 API,因此请根据需要调整该等式。您每月可获得 200 美元的 Google Maps API 赠金,因此计算时务必考虑到这一点。
  • 使用多个项目来隔离、跟踪用量,并确定其优先顺序。例如,假设您要在测试中定期使用 Google Maps Platform API。通过为测试创建单独的项目(具有自己的配额和 API 密钥),您可以进行全面测试,同时防止意外超支。

管理地图中的消耗

因为用户通常一次只会与一个地图互动,所以在每个页面上使用一个地图可以有效优化地图展示。您的应用可以根据客户的互动和需求操作地图以显示不同的数据集。

使用静态图片

使用动态图片(动态地图和动态街景)的请求的费用会高于使用静态图片和静态街景的请求。如果您无法预见用户与地图或街景的互动(缩放或平移),请考虑使用这些 API 的静态版本。

此外,静态地图和静态街景也非常适合用来提供缩略图,以及非常小的地图和照片。使用这两项的请求以较低费率结算,并且可以在用户互动(点击)时生成动态版本,让用户获得完整的 Google 地图体验。

使用 Maps Embed API

您可以使用 Maps Embed API 免费添加带有单个标记的地图或动态地图。对于需要单个标记但不需要地图自定义功能的应用,可以使用 Maps Embed API。现在,使用路线模式、街景模式或搜索模式的 Maps Embed API 请求需要付费(请参阅价格表了解详情)。

为移动应用使用移动地图 SDK

对于移动应用,请在显示地图时使用 Maps SDK for Android 或 Maps SDK for iOS。如果要求不允许使用移动 SDK,请使用 Maps Static API 或 Maps JavaScript API。

管理路线中的消耗

限制 Directions API 航点

如有可能,将查询中的用户条目限制为最多 10 个航点。对于所含航点数超过 10 个的请求,会以较高费率结算。

使用 Directions API 优化提供最佳路线

使用航点优化参数的请求以较高费率结算。如需了解详情,请参阅优化航点

优化参数会对航点进行排序,以确保提供最佳路线,以从 A 到 E 的旅行路线为例,优化后的路线(例如 A-B-C-D-E)比采用随机顺序的未优化路线(例如 A-D-B-C-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 获取地点位置。

不过,如果您得到了确切地址(或相近地址),可以使用地理编码(而非自动补全)来降低费用。如需了解详情,请参阅对地址进行地理编码的最佳做法