做好規劃，避免頻率限制
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
為了維持最佳系統穩定性和效能，Health Connect 對 Health Connect API 的用戶端連線設有頻率限制。
本指南說明在 Health Connect 中讀取及寫入 API 作業的限制，以及如何透過有效的應用程式設計避免頻率限制。
API 限制
前景及背景 API 作業皆具有固定的要求比率配額限制。
影響頻率和記憶體限制的因素包括應用程式執行的作業類型，以及該作業的執行位置是前景或背景。
讀取和變更記錄限制
針對讀取和變更記錄限制，Health Connect 對應用程式可用的 API 呼叫次數設有兩項限制：
- 應用程式在週期內可對 API 發出 API 呼叫的次數限制。
- 應用程式在一天內可發出的 API 呼叫次數限制。
插入、更新及刪除限制
Health Connect 針對插入、更新及刪除作業設下四種不同的限制：
- 應用程式在週期內可對 API 發出呼叫的次數限制。
- 應用程式在一天內可對 API 發出呼叫的次數限制。
- 插入大量記錄的記憶體限制。
- 插入單筆記錄的記憶體限制。
最佳做法
應用程式與 Health Connect API 互動時，應盡可能減少電池用量、維持最佳系統健康狀態，並促進所有 CRUD 作業採用高效率的資料管理方式。
以下為建議依循的最佳做法。
背景 API 呼叫
背景作業的電池用量會降低使用者體驗，並引發資料隱私權相關問題。
因此，背景頻率限制比前景頻率限制更嚴格。請務必限制應用程式在背景執行的 API 呼叫數量。
例外狀況處理
如果應用程式在將資料寫入 Health Connect 時遇到例外狀況，建議您從例外狀況發生的位置重試。
請勿直接刪除所有與問題相關的資料，然後重試整個寫入要求。這個方法會消耗您的插入配額、降低效能，並對電池續航力產生負面影響。
變更記錄處理
為了盡可能降低應用程式受到頻率限制的風險，您應使用變更記錄處理功能同步處理資料庫與 Health Connect 中的資料，而非過度依賴原始讀取要求。
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。Java 與 OpenJDK 是 Oracle 和/或其關係企業的商標或註冊商標。
上次更新時間：2025-07-27 (世界標準時間)。
[null,null,["上次更新時間：2025-07-27 (世界標準時間)。"],[],[],null,["# Plan to avoid rate limiting\n\nTo maintain optimal system stability and performance, Health Connect imposes\nrate limits on client connections to the Health Connect API.\n\nThis guide outlines the limits imposed on read and write API operations in\nHealth Connect, and how to avoid rate limiting through efficient app design.\n\nAPI limits\n----------\n\nLimits are placed on both foreground and background API operations as **fixed\nrequest rate quotas**.\n\nRate and memory limits are variable based on the type of operation your app is\nperforming, and whether that operation occurs in the foreground or background.\n\n### Read and changelog limits\n\nFor read and changelog limits, Health Connect imposes two limits on the number\nof API calls available to your app:\n\n- A periodic limit on the number of API calls your app can make to the API.\n- A daily limit on the number of API calls your app can make.\n\n### Insert, update and delete limits\n\nHealth Connect places four distinct limits on insertion, update and deletion\noperations:\n\n- A periodic limit on the number of calls your app can make to the API.\n- A daily limit on the number of calls your app can make to the API.\n- A memory limit for bulk insertions.\n- A memory limit for single record insertions.\n\nBest practices\n--------------\n\nWe recommend that apps interact with the Health Connect API in a way that\nminimizes battery use, maintains optimal system health and promotes efficient\ndata management across all CRUD operations.\n\nHere are some best practice guidelines to adhere to.\n\n### Background API calls\n\nBattery usage for background operations reduces the user experience and raises\nquestions regarding [data privacy](/guide/health-and-fitness/health-connect/develop/read-data#foreground-restriction).\n\nAs such, background rate limiting is stricter than foreground rate limiting.\nIt's therefore important to limit the amount of API calls your app carries out\nin the background.\n\n### Exception handling\n\nIf your app experiences an exception when writing data to Health Connect, we\nrecommend retrying from where the exception occurred.\n\nDon't simply delete all the data in question and retry the entire write request.\nThis approach eats into your insert quota, reduces performance, and has a\nnegative impact on battery life.\n\n### Changelog handling\n\nTo minimize the risk of your app being rate limited, you should utilize\n[changelog handling](/guide/health-and-fitness/health-connect/develop/sync-data#pull-data) to synchronize your database with data from Health\nConnect, rather than over-relying on raw read requests."]]
