التخطيط لتجنُّب تقييد المُعدَّل
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
للحفاظ على استقرار النظام وأدائه المثاليين، يفرض تطبيق Health Connect حدودًا على معدّلات الاتصال بالعميل بواجهة برمجة تطبيقات Health Connect.
يوضّح هذا الدليل الحدود المفروضة على عمليات قراءة وكتابة واجهة برمجة التطبيقات في تطبيق Health Connect، وكيفية تجنُّب تحديد معدّل الزحف من خلال تصميم التطبيق الفعّال.
حدود واجهة برمجة التطبيقات
ويتم وضع الحدود في كل من عمليات واجهة برمجة التطبيقات التي تعمل في المقدّمة والخلفية باعتبارها حصصًا ثابتة لمعدّل الطلبات.
تتغير حدود الذاكرة ومعدّل السرعة بناءً على نوع العملية التي ينفّذها تطبيقك، وما إذا كانت هذه العملية تحدث في المقدّمة أو في الخلفية.
حدود القراءة وسجلّ التغييرات
بالنسبة إلى حدود القراءة وسجلّ التغييرات، يفرض تطبيق Health Connect حدَّين على عدد طلبات البيانات من واجهة برمجة التطبيقات المتاحة لتطبيقك:
- حدّ دوري لعدد طلبات البيانات من واجهة برمجة التطبيقات التي يمكن لتطبيقك إجراؤها من واجهة برمجة التطبيقات
- حدّ يومي لعدد طلبات البيانات من واجهة برمجة التطبيقات التي يمكن لتطبيقك إجراؤها.
إدراج الحدود وتعديلها وحذفها
يضع Health Connect أربعة قيود مختلفة على عمليات الإدراج والتحديث والحذف:
- حد دوري لعدد الاتصالات التي يمكن لتطبيقك إجراؤها بواجهة برمجة التطبيقات.
- حدّ يومي لعدد الاتصالات التي يمكن لتطبيقك إجراؤها بواجهة برمجة التطبيقات.
- حد الذاكرة للإدراج المجمَّع.
- حدّ الذاكرة لعمليات إدراج سجلّ واحد
أفضل الممارسات
نقترح أن تتفاعل التطبيقات مع Health Connect API بطريقة تقلّل من استهلاك البطارية وتحافظ على صحة النظام الأمثل وتعزز الإدارة الفعّالة للبيانات في جميع عمليات CRUD.
في ما يلي بعض الإرشادات حول أفضل الممارسات التي يجب التقيّد بها.
طلبات بيانات من واجهة برمجة التطبيقات في الخلفية
يقلل استخدام البطارية للعمليات في الخلفية من تجربة المستخدم ويثير
أسئلة بشأن خصوصية البيانات.
وبالتالي، يكون تقييد معدّل الخلفية أكثر صرامة من تقييد معدّل المقدّمة في المقدّمة.
لذا، من المهم الحدّ من مقدار طلبات البيانات من واجهة برمجة التطبيقات التي يجريها تطبيقك في الخلفية.
التعامل مع الاستثناء
إذا واجه تطبيقك استثناءً عند كتابة البيانات في Health Connect، ننصحك بإعادة المحاولة من مكان الاستثناء.
يجب عدم حذف جميع البيانات المعنيّة وإعادة محاولة طلب الكتابة بالكامل.
يؤثر هذا الأسلوب سلبًا في حصة الإدخال ويقلل من الأداء، كما يؤثر سلبًا في عمر البطارية.
التعامل مع سجلّ التغييرات
للحدّ من خطر فرض قيود على معدّل استخدام تطبيقك، عليك استخدام
معالجة سجلّ التغييرات لمزامنة قاعدة بياناتك مع البيانات من Health
Connect، بدلاً من الاعتماد بشكل مفرط على طلبات القراءة الأولية.
يخضع كل من المحتوى وعيّنات التعليمات البرمجية في هذه الصفحة للتراخيص الموضحّة في ترخيص استخدام المحتوى. إنّ Java وOpenJDK هما علامتان تجاريتان مسجَّلتان لشركة Oracle و/أو الشركات التابعة لها.
تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)
[[["يسهُل فهم المحتوى.","easyToUnderstand","thumb-up"],["ساعَدني المحتوى في حلّ مشكلتي.","solvedMyProblem","thumb-up"],["غير ذلك","otherUp","thumb-up"]],[["لا يحتوي على المعلومات التي أحتاج إليها.","missingTheInformationINeed","thumb-down"],["الخطوات معقدة للغاية / كثيرة جدًا.","tooComplicatedTooManySteps","thumb-down"],["المحتوى قديم.","outOfDate","thumb-down"],["ثمة مشكلة في الترجمة.","translationIssue","thumb-down"],["مشكلة في العيّنات / التعليمات البرمجية","samplesCodeIssue","thumb-down"],["غير ذلك","otherDown","thumb-down"]],["تاريخ التعديل الأخير: 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."]]
