تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
قد يؤدي استخدام قفل التنشيط إلى إضعاف أداء الجهاز. إذا كنت بحاجة إلى استخدام قفل تنبيه، من المهم إجراء ذلك بشكل صحيح. يتناول هذا المستند بعض أفضل الممارسات التي يمكن أن تساعدك في تجنُّب المشاكل الشائعة المتعلّقة بأقفال التنشيط.
تسمية قفل التنشيط بشكل صحيح
ننصحك بتضمين اسم الحزمة أو الفئة أو الطريقة في علامة wakelock. بهذه الطريقة، إذا حدث خطأ، سيكون من الأسهل العثور على الموقع في الرمز المصدر الذي تم فيه إنشاء قفل التنشيط. إليك بعض النصائح الإضافية:
لا تُدرِج أي معلومات تكشف الهوية الشخصية في الاسم، مثل عنوان البريد الإلكتروني. إذا رصد الجهاز معلومات تحديد الهوية الشخصية في علامة قفل التنشيط، سيسجّل _UNKNOWN بدلاً من العلامة التي حدّدتها.
لا تستخدِم اسم الفئة أو الطريقة بشكل آلي، مثلاً من خلال استدعاء getName(). إذا حاولت الحصول على الاسم آليًا، قد يتم تشويشه باستخدام أدوات مثل Proguard. بدلاً من ذلك، استخدِم سلسلة
مضمّنة في الرمز.
لا تُضِف عدّادًا أو معرّفات فريدة إلى علامات قفل التنشيط. يجب أن يستخدم الرمز البرمجي الذي ينشئ قفل تنبيه العلامة نفسها في كل مرة يتم تشغيله.
تتيح هذه الممارسة للنظام تجميع استخدام قفل التنشيط لكل طريقة.
التأكّد من أنّ تطبيقك مرئي في المقدّمة
عندما يكون قفل التنشيط نشطًا، يستخدم الجهاز الطاقة. ويجب أن يكون مستخدم الجهاز على علم بذلك. لهذا السبب، إذا كنت تستخدم قفل تنبيه، عليك عرض بعض الإشعارات للمستخدم.
يعني ذلك عمليًا أنّه يجب الحصول على قفل التنشيط والاحتفاظ به في خدمة تعمل في المقدّمة. يجب أن تعرض الخدمات التي تعمل في المقدّمة إشعارًا.
إذا كانت الخدمة التي تعمل في المقدّمة ليست الخيار المناسب لتطبيقك، من المحتمل أنّه لا يجب استخدام قفل التنشيط أيضًا. راجِع مستند
اختيار واجهة برمجة التطبيقات المناسبة لإبقاء الجهاز نشطًا
للتعرّف على الطرق الأخرى التي يمكنك من خلالها تنفيذ المهام عندما لا يكون تطبيقك في المقدّمة.
الحفاظ على بساطة المنطق
احرص على أن تكون طريقة الحصول على أقفال التنشيط وإلغاء قفلها بسيطة قدر الإمكان. عندما تكون منطق قفل التنشيط مرتبطًا بآلات حالات معقّدة أو مهلات أو مجموعات منفّذين أو أحداث ردّ الاتصال، يمكن أن يتسبّب أي خطأ بسيط في هذا المنطق في إبقاء قفل التنشيط نشطًا لفترة أطول من المتوقّع. ويصعب تشخيص هذه الأخطاء وتصحيحها.
التأكّد من إيقاف قفل التنشيط دائمًا
في حال استخدام قفل تنبيه، عليك التأكّد من إيقاف تشغيل كل قفل تنبيه تحصل عليه بشكل صحيح. ليس الأمر سهلاً دائمًا كما يبدو. على سبيل المثال،
تتضمّن التعليمة البرمجية التالية مشكلة:
Kotlin
@Throws(MyException::class)fundoSomethingAndRelease(){wakeLock.apply{acquire()doTheWork()// can potentially throw MyExceptionrelease()// does not run if an exception is thrown}}
Java
voiddoSomethingAndRelease()throwsMyException{wakeLock.acquire();doTheWork();// can potentially throw MyExceptionwakeLock.release();// does not run if an exception is thrown}
المشكلة هنا هي أنّ الطريقة doTheWork() يمكن أن تعرض الاستثناء MyException. وفي حال حدوث ذلك، تنقل الطريقة doSomethingAndRelease() الاستثناء إلى الخارج، ولا تصل أبدًا إلى استدعاء release(). والنتيجة
هي الحصول على قفل التنشيط بدون إطلاقه، وهذا أمر سيئ للغاية.
في الرمز البرمجي المعدَّل، يضمن doSomethingAndRelease() إلغاء قفل التنشيط حتى في حال حدوث استثناء:
يخضع كل من المحتوى وعيّنات التعليمات البرمجية في هذه الصفحة للتراخيص الموضحّة في ترخيص استخدام المحتوى. إنّ Java وOpenJDK هما علامتان تجاريتان مسجَّلتان لشركة Oracle و/أو الشركات التابعة لها.
تاريخ التعديل الأخير: 2025-08-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-08-27 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],null,["Using a wake lock can impair device performance. If you need to use a wake\nlock, it's important to do it properly. This document covers some best practices\nthat can help you avoid common wake lock pitfalls.\n| **Note:** Creating and holding wake locks can have a dramatic impact on the device's battery life. You shouldn't use wake locks if there are any suitable alternatives. For other options, see the [Keep the device awake](/develop/background-work/background-tasks/awake) documentation. If you do need to use a wake lock, make sure to hold it for as short a time as possible.\n\nName the wake lock properly\n\nWe recommend including your package, class, or method name in the wakelock\ntag. That way, if an error occurs, it's easier to find the location in your\nsource code where the wake lock was created. Here are some additional tips:\n\n- Leave out any personally identifying information (PII) in the name, such as an email address. If the device detects PII in the wake lock tag, it logs `_UNKNOWN` instead of the tag you specified.\n- Don't get the class or method name programmatically, for example by calling `getName()`. If you try to get the name programmatically, it might get obfuscated by tools like Proguard. Instead use a hard-coded string.\n- Don't add a counter or unique identifiers to wake lock tags. The code that creates a wake lock should use the same tag every time it runs. This practice enables the system to aggregate each method's wake lock usage.\n\nMake sure your app is visible in the foreground\n\nWhile a wake lock is active, the device is using power. The device's user\nshould be aware that this is going on. For this reason, if you're using a\nwake lock, you should display some notification to the user.\nIn practice, this means you should get and hold the wakelock in a\n[foreground service](/develop/background-work/services/fgs). Foreground services are required to display\na notification.\n\nIf a foreground service isn't the right choice for your app,\nyou probably shouldn't be using a wake lock, either. See the\n[Choose the right API to keep the device awake](/develop/background-work/background-tasks/awake)\ndocumentation for other ways to do work while your app isn't in the foreground.\n\nKeep the logic simple\n\nMake sure the logic for acquiring and releasing wake locks is as simple as\npossible. When your wake lock logic is tied to complex state machines, timeouts,\nexecutor pools, or callback events, any subtle bug in that logic can cause the\nwake lock to be held longer than expected. These bugs are difficult to diagnose\nand debug.\n\nCheck that the wake lock is always released\n\nIf you use a wake lock, you must make sure that every wake lock you acquire\nis properly released. This isn't always as easy as it sounds. For example,\nthe following code has a problem: \n\nKotlin \n\n @Throws(MyException::class)\n fun doSomethingAndRelease() {\n wakeLock.apply {\n acquire()\n doTheWork() // can potentially throw MyException\n release() // does not run if an exception is thrown\n }\n }\n\nJava \n\n void doSomethingAndRelease() throws MyException {\n wakeLock.acquire();\n doTheWork(); // can potentially throw MyException\n wakeLock.release(); // does not run if an exception is thrown\n }\n\nThe problem here is that the method `doTheWork()` can throw the exception\n`MyException`. If it does, the `doSomethingAndRelease()` method propagates\nthe exception outward, and it never reaches the `release()` call. The result\nis that the wake lock is acquired but not released, which is very bad.\n\nIn the corrected code, `doSomethingAndRelease()` makes sure to release the\nwake lock even if an exception is thrown: \n\nKotlin \n\n @Throws(MyException::class)\n fun doSomethingAndRelease() {\n wakeLock.apply {\n try {\n acquire()\n doTheWork()\n } finally {\n release()\n }\n }\n }\n\nJava \n\n void doSomethingAndRelease() throws MyException {\n try {\n wakeLock.acquire();\n doTheWork();\n } finally {\n wakeLock.release();\n }\n }"]]