做好规划，避免速率限制
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
为了保持最佳的系统稳定性和性能，Health Connect 会对客户端与 Health Connect API 的连接强加速率限制。
本指南概述了 Health Connect 中对读取和写入 API 操作强加的限制，以及如何通过高效的应用设计来避免速率限制。
API 限制
前台和后台 API 操作都会被施加固定请求速率配额限制。
速率和内存限制不尽相同，具体取决于应用所执行操作的类型以及该操作是发生在前台还是后台。
读取方面的限制和更新日志限制
对于读取方面的限制和更新日志限制，Health Connect 对应用可用的 API 调用次数强加了 2 项限制：
- 对应用能向 API 发出的 API 调用次数的定期限制。
- 对应用可进行的 API 调用次数的每日限制。
插入、更新和删除方面的限制
Health Connect 在插入、更新和删除操作方面施加了 4 项各不相同的限制：
- 对应用能向 API 发出的调用次数的定期限制。
- 对应用可向 API 发出的调用次数的每日限制。
- 对批量插入操作的内存限制。
- 对单记录插入操作的内存限制。
最佳实践
我们建议，应用与 Health Connect API 的交互方式应能最大程度减少电池用量、维持最佳系统运行状况并促进所有 CRUD 操作中的高效数据管理。
下面是一些最佳实践指南。
后台 API 调用
后台操作的电池用量会降低用户体验质量，还会引发有关数据隐私权的问题。
所以，后台速率限制比前台速率限制更严格。有鉴于此，限制应用在后台执行的 API 调用次数非常重要。
异常情况处理
如果应用在向 Health Connect 写入数据时遇到异常情况，我们建议从发生异常情况的位置重试。
不要直接删除所有相关数据并重试整个写入请求。此方法会占用您的插入配额、会降低性能，并会对电池续航时间产生负面影响。
更新日志处理
为了尽可能降低应用速率受限的风险，您应该利用更新日志处理功能将您的数据库与 Health Connect 中的数据同步，而不是过度依赖于原始读取请求。
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC)：2025-07-27。
[null,null,["最后更新时间 (UTC)：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."]]
