重要資訊：我們目前不接受新的 Play EMM API 註冊。
瞭解詳情。
使用限制
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
Google Play EMM API 的預設上限為每個 EMM 每秒 60,000 次查詢。
如果超出配額，Google Play EMM API 會傳回 HTTP 429 Too Many Requests。為確保您不會超過規定的使用限制，並為使用者提供最佳體驗，建議您採用下文所述的部分最佳做法。
建議您如何避免超過 API 用量限制
使用 Google Play EMM API 時，您可以採行一些最佳做法來發布要求，降低超過用量限制的風險。
隨機產生開始時間和間隔
如果同時進行同步或簽到等活動，要求量可能會大幅增加。您可以隨機化這些間隔，以便分散要求負載，而非依照定期排程間隔執行這些活動。舉例來說，您可以在 23 到 25 小時之間隨機選定的時間範圍內同步處理每部裝置，而不必每 24 小時一次同步處理一次。這有助於分散請求數量。
同樣地，如果您執行的每日工作會快速連續發出多次 API 呼叫，請考慮每天隨機啟動工作，避免同時對所有企業客戶提出大量要求。
使用指數輪詢重試要求
如果您執行的工作是由多個 API 呼叫組成，請採用指數輪詢策略來回應配額上限。指數輪詢是一種演算法，會以指數方式重試要求。實作簡單指數輪詢的流程範例如下：
- 向 Google Play EMM API 提出要求。
- 接收
HTTP 429 回應。
- 等待 2 秒又
random_time，然後重試要求。
- 收到
HTTP 429 回應。
- 等待 4 秒 +
random_time，然後重試要求。
- 接收
HTTP 429 回應。
- 等待 8 秒鐘 +
random_time，然後重試要求。
random_time 通常是介於 -0.5 * 等待時間 和 +0.5 * 等待時間 之間的隨機數字。每次重試要求時，請重新定義新的 random_time。完成面向使用者的動作所需的 API 呼叫，可按更頻繁的時間表 (例如 0.5 秒、1 秒和 2 秒) 重試。
批次處理作業的頻率限制
每當批次處理程序達到配額，呼叫 API 的使用者動作延遲時間就會增加。在這類情況下，指數輪詢等策略可能不足以降低使用者動作的延遲時間。
為避免重複達到 API 用量限制，並增加使用者操作的延遲時間，建議您針對批次程序使用頻率限制器 (請參閱 Google 的 RateLimiter 限制)。您可以使用頻率限制器調整 API 要求的頻率，確保持續低於用量限制。
舉例來說，啟動批次處理程序時，預設速率限制為 50 QPS。只要 API 不會傳回錯誤，請慢慢提高頻率限制 (每分鐘 1%)。每次達到配額時，要求比率降低 20%。這種自適應方法可產生更理想的要求率，同時縮短面向使用者的動作延遲時間。
除非另有註明，否則本頁面中的內容是採用創用 CC 姓名標示 4.0 授權，程式碼範例則為阿帕契 2.0 授權。詳情請參閱《Google Developers 網站政策》。Java 是 Oracle 和/或其關聯企業的註冊商標。
上次更新時間：2024-11-09 (世界標準時間)。
[null,null,["上次更新時間：2024-11-09 (世界標準時間)。"],[[["\u003cp\u003eThe Google Play EMM API has a default limit of 60,000 queries per minute per EMM, exceeding which results in an HTTP 429 Too Many Requests error.\u003c/p\u003e\n"],["\u003cp\u003eTo avoid exceeding the usage limit, randomize device sync intervals and job start times to distribute the request load.\u003c/p\u003e\n"],["\u003cp\u003eImplement exponential backoff to retry requests with increasing wait times after receiving HTTP 429 errors.\u003c/p\u003e\n"],["\u003cp\u003eFor batch processes, utilize a rate limiter to adjust the request rate dynamically and prevent consistently hitting the usage limit, ensuring low latency for user actions.\u003c/p\u003e\n"]]],[],null,["# Usage Limits\n\nThe Google Play EMM API has a default limit of 60,000 queries per minute for each EMM.\n\nIf you exceed the quota, then the Google Play EMM API returns `HTTP 429 Too Many Requests`.\nTo help ensure that you don't exceed the stated usage limits and offer an optimal experience for\nyour users, consider implementing some of the best practices described in the section below.\n\nRecommendations for staying below the API usage limits\n------------------------------------------------------\n\nWhen using the Google Play EMM API, there are some best practices that you can implement to\ndistribute requests and reduce your risk of exceeding the usage limits.\n\n### Randomize start times and intervals\n\nActivities such as syncing or checking-in devices at the same time are likely to result in a\nsignificant increase in request volume. Instead of performing these activities at regularly\nscheduled intervals, you can distribute your request load by randomizing these intervals. For\nexample, rather than syncing each device every 24 hours, you can sync each device at a randomly\nchosen time period between 23 and 25 hours. This helps spread out the number of requests.\n\nSimilarly, if you run a daily job that makes many API calls in quick succession, consider\nstarting the job at a random time each day to prevent making a high volume of requests for all\nyour enterprise customers at the same time.\n\n### Use exponential backoff to retry requests\n\nIf you run jobs that consists of many API calls, use an exponential backoff strategy in\nresponse to reaching the quota. Exponential backoff is an algorithm that retries requests\nexponentially. An example flow for implementing simple exponential backoff is as follows:\n\n1. Make a request to the Google Play EMM API.\n2. Receive an `HTTP 429` response.\n3. Wait 2 seconds + `random_time`, then retry the request.\n4. Receive an `HTTP 429` response.\n5. Wait 4 seconds + `random_time`, then retry the request.\n6. Receive an `HTTP 429` response.\n7. Wait 8 seconds + `random_time`, then retry the request.\n\nThe `random_time` is typically a random number ranging from ***-0.5 \\* wait time***\nto ***+0.5 \\* wait time*** . Redefine a new `random_time` each time you retry your\nrequest. API calls that are required to complete user-facing actions can be retried on a more\nfrequent schedule (0.5s, 1s, and 2s, for example).\n\n### Rate-limit batch processes\n\nEach time a batched process reaches the quota, the latency of user actions that call the API\nincreases. In situations like these, strategies such as exponential backoff may not be effective\nenough in maintaining low latency for user actions.\n\nTo avoid reaching the API's usage limits repeatedly and increasing latency for user-facing\nactions, consider using a rate limiter for your batched processes (see [Google's RateLimiter](https://google.github.io/guava/releases/19.0/api/docs/index.html?com/google/common/util/concurrent/RateLimiter.html)).\nWith a rate limiter you can adjust the rate of your API requests so that you consistently remain\nbelow the usage limits.\n\nFor example, start a batched process with a default rate limit of 50 QPS. As long as the API\ndoesn't return an error, increase the rate limit slowly (1% every minute). Each time you reach\nthe quota, reduce your request rate by 20%. This adaptive approach results in a more optimal\nrequest rate while reducing latency for user-facing actions."]]
