קל לארגן דפים בעזרת אוספים
אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.
שימוש ב-wake lock עלול לפגוע בביצועי המכשיר. אם אתם צריכים להשתמש ב-wake lock, חשוב לעשות זאת בצורה נכונה. במסמך הזה מפורטות כמה שיטות מומלצות שיעזרו לכם להימנע מטעויות נפוצות שקשורות לנעילת השהיה.
לתת שם לחסימת מצב השינה בצורה נכונה
מומלץ לכלול את שם החבילה, המחלקה או השיטה בתג wakelock. כך, אם מתרחשת שגיאה, קל יותר למצוא במיקום בקוד המקור שבו נוצרת נעילת ההשכמה. ריכזנו כאן כמה טיפים נוספים:
לא לכלול בשם פרטים אישיים מזהים (PII), כמו כתובת אימייל. אם המכשיר מזהה מידע אישי מזהה (PII) בתג של מניעת הכניסה למצב שינה, הוא רושם ביומן את הערך _UNKNOWN במקום התג שציינתם.
אל תקבלו את שם המחלקה או ה-method באופן פרוגרמטי, למשל על ידי קריאה ל-getName(). אם מנסים לקבל את השם באופן פרוגרמטי, יכול להיות שהוא יוסתר על ידי כלים כמו Proguard. במקום זאת, צריך להשתמש במחרוזת עם קידוד קשיח.
אל תוסיפו מונה או מזהים ייחודיים לתגי נעילת השהיה. הקוד
שיוצר נעילת השכמה צריך להשתמש באותו תג בכל פעם שהוא מופעל.
השיטה הזו מאפשרת למערכת לצבור את השימוש ב-wake lock של כל שיטה.
מוודאים שהאפליקציה גלויה בחזית
בזמן שהתכונה 'מניעת שינה' פעילה, המכשיר צורך חשמל. המשתמש במכשיר צריך לדעת שהפעולה הזו מתבצעת. לכן, אם אתם משתמשים ב-wake lock, כדאי להציג למשתמש התראה כלשהי.
בפועל, המשמעות היא שצריך לקבל את נעילת ההשכמה ולהחזיק אותה בשירות בחזית. שירותים שפועלים בחזית נדרשים כדי להציג התראה.
אם שירות שפועל בחזית הוא לא הבחירה הנכונה לאפליקציה שלכם, כנראה שגם לא כדאי להשתמש בנעילת השהיה. במסמכי התיעוד בנושא בחירת ה-API הנכון כדי למנוע את מצב השינה של המכשיר מוסבר על דרכים אחרות לבצע פעולות כשהאפליקציה לא פועלת בחזית.
שומרים על לוגיקה פשוטה
חשוב לוודא שהלוגיקה של קבלת נעילות השכמה ושחרורן פשוטה ככל האפשר. אם הלוגיקה של נעילת ההשכמה קשורה למכונות מצב מורכבות, לזמני קצובה, למאגרי ביצוע או לאירועי קריאה חוזרת, כל באג קטן בלוגיקה הזו עלול לגרום לנעילת ההשכמה להימשך זמן רב יותר מהצפוי. קשה לאבחן ולנפות באגים כאלה.
בודקים שה-wake lock תמיד משוחרר
אם משתמשים ב-wake lock, צריך לוודא שכל wake lock שמוגדר
משוחרר בצורה תקינה. זה לא תמיד פשוט כמו שזה נשמע. לדוגמה,
יש בעיה בקוד הבא:
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(). התוצאה היא שה-wake lock נרכש אבל לא משוחרר, וזה מצב גרוע מאוד.
בקוד המתוקן, doSomethingAndRelease() מוודא שנעילת ההשכמה תבוטל גם אם נוצר חריג:
דוגמאות התוכן והקוד שבדף הזה כפופות לרישיונות המפורטים בקטע רישיון לתוכן. Java ו-OpenJDK הם סימנים מסחריים או סימנים מסחריים רשומים של חברת Oracle ו/או של השותפים העצמאיים שלה.
עדכון אחרון: 2025-08-27 (שעון UTC).
[[["התוכן קל להבנה","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 (שעון UTC)."],[],[],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 }"]]