تحسين استخدام البطارية في واجهات برمجة التطبيقات الخاصة بجدولة المهام
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
تقترح هذه الصفحة بعض أفضل الممارسات لإعداد مهام خلفية ذات سلوك جيد. تهدف أفضل الممارسات هذه بشكل خاص إلى تقليل استهلاك البطارية،
ولكن يمكنها أيضًا تحسين أداء الجهاز بطرق أخرى، مثل تقليل
استخدام الشبكة.
اختيار القيود المثلى ودمج المهام
لتقليل تحميل مهامك على الجهاز، من المهم تحديد
القيود المثلى. (بالنسبة إلى مهام JobScheduler، يُرجى الاطّلاع على JobInfo.Builder
للاطّلاع على قائمة القيود). كمثال على ذلك، إذا كنت تريد التأكد من أنّ تطبيقك لا ينفد شحن البطارية، ننصحك بتحديد القيد RequiresCharging. يطلب هذا القيد من النظام عدم تشغيل المهمة ما لم يتزايد مستوى شحن البطارية بالفعل. وبالمثل، يتطلّب استخدام شبكة Wi-Fi بشكل عام طاقة أقل مقارنةً ببيانات الجوّال، لذلك إذا كانت مهمتك بحاجة إلى اتصال بالشبكة ولكن ليس بإمكانها الانتظار حتى تتوفّر شبكة لا تفرض تكلفة استخدام، ننصحك بفرض قيد على NetworkType.UNMETERED.
بالإضافة إلى ذلك، إذا كان لديك العديد من المهام المتشابهة التي قد تندرج تحت نفس القيود، فسيكون من الجيد عادةً دمجها في مهمة واحدة، حتى يتم تنشيط الجهاز مرة واحدة فقط. على سبيل المثال، لنفترض أن تطبيقك يحتوي على ثلاث
مجموعات بيانات مختلفة يحتاج إلى مزامنتها مع التخزين في السحابة الإلكترونية. فبدلاً من جدولة ثلاث مهام مختلفة - مهمة لكل مجموعة بيانات - من الأفضل عادةً جدولة مهمة واحدة "لمزامنة البيانات" وتحديد القيود المناسبة والسماح لهذه المهمة بإجراء جميع عمليات مزامنة البيانات المعلّقة عند تشغيلها.
مع ذلك، يجب ألّا تحاول دمج المهام غير ذات الصلة في مهمة
واحدة كاملة. بدلاً من ذلك، فقط تأكد من إعطاء كل مهمة
القيود المناسبة. على سبيل المثال، إذا كانت المهام ذات أولوية منخفضة، فتأكد من تحديد
أنها يجب أن تعمل عندما يكون الجهاز في وضع عدم النشاط وقيد الشحن. وبهذه الطريقة، حتى إذا تم تنشيط الجهاز عدة مرات، لن يضر ذلك بتجربة المستخدم أو يؤثر على عمر البطارية.
وضع علامة على المهام على أنّها مُسرَّعة فقط عندما تكون حساسة للوقت
إذا كانت إحدى المهام عاجلة بشكل خاص، يمكنك وضع علامة عليها على أنّها عاجلة. (بالنسبة إلى
وظائف JobScheduler، اتصِل بالرقم JobInfo.Builder.setExpedited(true).) يؤدي ذلك
إلى منح الأولوية للمهمة بعدة طرق. على سبيل المثال، يقوم النظام بتشغيل تلك المهام على الفور عندما يكون ذلك ممكنًا، ومن غير المرجح أن تؤثر قيود إدارة الطاقة على المهام المُعجلة.
لهذه الأسباب، عليك توخي الحذر فقط لوضع علامة على مهمة باعتبارها مُعجلة عندما تحتاج إلى ذلك. نظرًا لأن المهام السريعة يمكن أن تتجاوز بعض كفاءات النظام،
فيمكن أن تستنزف المهام السريعة المزيد من الطاقة أكثر مما لو لم يتم تمييزها بهذه الطريقة.
يجب عدم وضع علامة على مهمة على أنها مُعجلة إلا إذا كانت حساسة للوقت، وستتأثر تجربة المستخدم إذا استغرق تنفيذ المهمة وقتًا أطول. على سبيل المثال، إذا كان تطبيقك يشغِّل مهمة للتعامل مع رسالة ذات أولوية عالية من خلال "المراسلة عبر السحابة الإلكترونية من Firebase"، سيكون هذا سببًا مناسبًا لوضع علامة على المهمة باعتبارها مُسرَّعة. ولكن يجب ألا تضع علامة على
مهمة على أنها عاجلة فقط لتجاوز تحسينات النظام.
التحقّق من سبب إيقاف مهامك
إذا توقفت مهامك قبل انتهائها، يمكنك التحقّق من سبب إيقافها من خلال الاتصال بـ WorkInfo.getStopReason(). (بالنسبة إلى وظائف JobScheduler، اتصِل بـ
JobParameters.getStopReason(). من المهم إجراء ذلك لسببين. بادئ ذي بدء، بالطبع، تريد إنهاء مهامك. يساعدك معرفة سبب توقف
مهامك في تجنب المواقف المماثلة. ولكن من المحتمل أيضًا أن يوقف النظام المهام بسبب السلوك الذي يفرط في استخدام موارد النظام. ينبغي ألا يكون تطبيقك مواطنًا سيئًا، إذ يستخدم البطارية أو الشبكة بدون داعٍ.
على سبيل المثال، إذا تم إيقاف مهامك بشكل متكرر بسبب STOP_REASON_TIMEOUT، قد تكون هناك حالة هامشية تؤدي في بعض الأحيان إلى أن تستغرق مهامك وقتًا أطول مما تتوقع.
ننصحك باستخدام محرك الإحصاءات الخاص بك لتتبّع ما إذا كانت مهام تطبيقك متوقفة لأي سبب كان، ولأي أسباب ذلك.
يخضع كل من المحتوى وعيّنات التعليمات البرمجية في هذه الصفحة للتراخيص الموضحّة في ترخيص استخدام المحتوى. إنّ 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,["# Optimize battery use for task scheduling APIs\n\nThis page suggests a few best practices for setting up well-behaved background\ntasks. These best practices are specifically aimed at reducing battery\nconsumption, but they can also improve device performance in other ways, like\nreducing network use.\n| **Note:** This page focuses on how to optimize tasks created with [WorkManager](/develop/background-work/background-tasks/persistent), our preferred library for scheduling tasks. In many cases, these suggestions also apply to [`JobScheduler`](/reference/android/app/job/JobScheduler) jobs, though the APIs you use are slightly different. Where appropriate, we've called out some corresponding `JobScheduler` APIs.\n\nChoose optimal constraints and combine tasks\n--------------------------------------------\n\nTo minimize the load your tasks place on the device, it's important to [specify\noptimal constraints](/develop/background-work/background-tasks/persistent/getting-started/define-work#work-constraints). (For JobScheduler jobs, see [`JobInfo.Builder`](/reference/android/app/job/JobInfo.Builder#setExpedited(boolean)) for\nthe list of constraints.) To take one example, if you want to make sure your app\ndoesn't run down the battery, it's a good idea to specify the `RequiresCharging`\nconstraint. This constraint tells the system not to run the job unless the\nbattery level is actually increasing. Similarly, using Wi-Fi generally requires\nless power than mobile data, so if your task needs a network connection but can\nwait until an unmetered network is available, it's a good idea to set a\n[`NetworkType.UNMETERED`](/reference/androidx/work/NetworkType#UNMETERED) constraint.\n\nAlso, if you have several similar tasks that would fall under the same\nconstraints, it's usually a good idea to combine them into a single task, so the\ndevice only gets woken up once. For example, suppose your app has three\ndifferent data sets it needs to sync with cloud storage. Instead of scheduling\nthree different tasks--one for each data set--it's usually a better idea to just\nschedule a single \"synchronize the data\" task, define appropriate constraints,\nand let that task do all the pending data synchronization when it runs.\n\nThat said, you shouldn't try to combine *unrelated* tasks into a single\ndo-it-all task. Instead, just make sure to give each task appropriate\nconstraints. For example, if tasks are low priority, make sure to specify that\nthey should run when the device is idle and charging. That way, even if the\ndevice gets woken up several times, it won't hurt the user experience or impact\nbattery life.\n\nOnly mark tasks as expedited when they're time-sensitive\n--------------------------------------------------------\n\nIf a task is particularly urgent, you can [mark it as expedited](/develop/background-work/background-tasks/persistent/getting-started/define-work#expedited). (For\nJobScheduler jobs, call [`JobInfo.Builder.setExpedited(true)`](/reference/android/app/job/JobInfo.Builder#setExpedited(boolean)).) Doing so\nprioritizes the task in a number of ways. For example, the system runs those\ntasks immediately when it can, and power management restrictions are less likely\nto affect expedited tasks.\n\nFor these reasons, you should be careful to *only* mark a task as expedited when\nyou need to. Because expedited tasks can override some system efficiencies,\nexpedited tasks can drain more power than they would if they weren't marked that\nway.\n\nYou should only mark a task as expedited if it's time-sensitive, and the user\nexperience would be impaired if the task took longer to execute. For example, if\nyour app runs a task to handle a high-priority FCM message, that's an\nappropriate reason to mark the task as expedited. But you shouldn't mark a task\nas expedited just to override system optimizations.\n\nCheck why your tasks were stopped\n---------------------------------\n\nIf your tasks stop before they finish, you can check why they were stopped by\ncalling [`WorkInfo.getStopReason()`](/reference/androidx/work/WorkInfo#getStopReason()). (For JobScheduler jobs, call\n[`JobParameters.getStopReason()`](/reference/android/app/job/JobParameters#getStopReason()) It's important to do this for a couple of\nreasons. First of all, of course, you want your tasks to finish. Finding out why\nyour tasks stopped helps you avoid similar situations. But also, the system is\nlikely to stop tasks because of behavior that overuses system resources. You\ndon't want your app to be a bad citizen, using the battery or network\nunnecessarily.\n\nFor example, if your tasks frequently get stopped with the reason\n[`STOP_REASON_TIMEOUT`](/reference/androidx/work/WorkInfo#STOP_REASON_TIMEOUT()), there might be an edge case that sometimes causes\nyour tasks to take much longer than you're expecting.\n\nWe recommend that you use your analytics engine to track whether your app's\ntasks are stopped, and for what reasons.\n| **Important:** On Android 14 or higher, if an app's tasks time out too often, the system can [put the app in the restricted standby bucket](/about/versions/14/behavior-changes-all#triggers-to-restricted-bucket)."]]
