موارد استفاده از قفل بیدارباش را شناسایی و بهینه کنید

این سند به شما کمک می‌کند تا موارد استفاده از قفل بیداری را در برنامه خود شناسایی و بهینه کنید، و همچنین اگر قفل‌های بیداری توسط سایر کتابخانه‌ها یا APIهای سیستم مرتبط با این مورد استفاده به دست آمده‌اند، آنها را برجسته کنید. از آنجایی که این قفل‌های بیداری به برنامه شما نسبت داده می‌شوند، شناسایی منبع قفل بیداری مشکل‌ساز می‌تواند چالش برانگیز باشد. استفاده نادرست از API می‌تواند باعث شود برنامه شما به دلیل استفاده بیش از حد از قفل بیداری علامت‌گذاری شود، حتی اگر صریحاً قفل‌های بیداری را به دست نیاورید.

این سند برخی از نام‌های رایج قفل بیداری را که ممکن است هنگام استفاده از ابزارهای اشکال‌زدایی قفل بیداری یا در گزارش‌های مربوط به داده‌های حیاتی با آنها مواجه شوید، فهرست می‌کند. این نام‌ها می‌توانند از یک کتابخانه یا API سیستم گرفته شده باشند، یا ممکن است مبهم‌سازی شده باشند. با استفاده از ابزارهای اشکال‌زدایی برای شناسایی قفل‌های بیداری که عملکرد نامناسبی دارند و سپس جستجوی نام قفل بیداری در این سند، می‌توانید تعیین کنید که کدام API ممکن است باعث مشکل شود و توصیه‌هایی در مورد چگونگی بهینه‌سازی استفاده از آن بیابید.

این سند موارد استفاده رایج برای دستیابی به قفل‌های بیداری را شرح می‌دهد، نام‌های قفل بیداری مورد استفاده توسط APIها و کتابخانه‌های مختلف را به تفصیل شرح می‌دهد و توصیه‌ها و بهترین شیوه‌ها را برای بهینه‌سازی و کاهش استفاده از قفل بیداری ارائه می‌دهد.

مدیر هشدار

AlarmManager قفل‌های بیداری را دریافت کرده و آنها را به برنامه فراخوانی کننده نسبت می‌دهد. AlarmManager هنگام به صدا درآمدن زنگ هشدار، قفل بیداری را دریافت می‌کند و هنگامی که اجرای متد onReceive() مربوط به پخش زنگ هشدار به پایان رسید، قفل را آزاد می‌کند.

نام‌های قفل بیدارباش

AlarmManager قفل‌های بیداری با نام *alarm* ایجاد می‌کند. (ستاره‌ها بخشی از نام قفل بیداری هستند، آنها نماد wild card نیستند.)

توصیه

برای بهینه‌سازی رفتار هشدار، روش‌های زیر را توصیه می‌کنیم:

  • برای انتخاب بین آلارم دقیق یا غیردقیق، به بخش انتخاب نوع آلارم مراجعه کنید. اگر نیازی به دقیق بودن آلارم ندارید، از آلارم‌های غیردقیق استفاده کنید تا سیستم انعطاف‌پذیری بیشتری در برنامه‌ریزی داشته باشد که می‌تواند عمر باتری را بهبود بخشد.
  • از سهمیه‌های هشدار اعمال‌شده توسط سیستم آگاه باشید و برنامه خود را طوری طراحی کنید که به آنها احترام بگذارد.
  • از انجام کارهای طولانی در متد onReceive() خودداری کنید و در صورت نیاز به پردازش اضافی پس از هشدار، workerها را زمان‌بندی کنید.

صدا و رسانه

رابط‌های برنامه‌نویسی کاربردی رسانه می‌توانند هنگام ضبط یا پخش صدا، قفل‌های بیداری را به دست آورند. این قفل‌های بیداری به برنامه‌ی فراخوانی نسبت داده می‌شوند.

نام‌های قفل بیدارباش

رابط‌های برنامه‌نویسی رسانه، قفل‌های بیداری را با نام‌های مختلفی که با Audio شروع می‌شوند، به دست می‌آورند:

  • AudioBitPerfect : برای پخش بدون افت کیفیت صدای USB استفاده می‌شود.
  • AudioDirectOut : برای پخش بدون افت کیفیت صدا در تلویزیون یا دستگاه‌های خاص استفاده می‌شود.
  • AudioDup : برای پخش اعلان‌ها هنگام اتصال از طریق بلوتوث یا USB استفاده می‌شود.
  • AudioIn : برای ضبط صدا در حالت دوربین فیلمبرداری و فعال بودن میکروفون استفاده می‌شود.
  • AudioMix : برای پخش صدا در یک دستگاه مشترک استفاده می‌شود.
  • AudioOffload : برای پخش طولانی مدت فقط موسیقی، برای برنامه‌هایی که از این حالت پشتیبانی می‌کنند، استفاده می‌شود.
  • AudioSpatial : برای پخش صدای فیلم یا موسیقی چند کاناله در دستگاه‌هایی که از صدای فضایی پشتیبانی می‌کنند، استفاده می‌شود.
  • AudioUnknown : زمانی استفاده می‌شود که سایر شرایط صدق نمی‌کنند.
  • MmapCapture : برای ضبط صدا با تأخیر کم استفاده می‌شود.
  • MmapPlayback : برای پخش با تأخیر کم، مانند بازی یا برنامه‌های صوتی حرفه‌ای، استفاده می‌شود.

توصیه

ما روش‌های عملی زیر را توصیه می‌کنیم:

  • نام‌هایی برای قفل بیداری که با Audio شروع می‌شوند، تعیین نکنید.
  • اگر از APIهای رسانه استفاده می‌کنید، نیازی به دریافت مستقیم قفل‌های بیداری ندارید؛ می‌توانید برای دریافت قفل‌های بیداری لازم به APIها تکیه کنید.
  • هنگام استفاده از رابط‌های برنامه‌نویسی کاربردی رسانه، زمانی که دیگر به آن نیازی ندارید، جلسه رسانه و سرویس پیش‌زمینه مرتبط را پایان دهید.

بلوتوث

رابط‌های برنامه‌نویسی کاربردی (API) بلوتوث پلتفرم، عمدتاً قفل‌های بیداری هسته را در حین انجام اقدامات بلوتوث نگه می‌دارند، که به برنامه کاربردی مربوط نمی‌شوند.

توصیه

  • برای جلوگیری از قفل بیدارباش دستی هنگام جفت‌سازی بلوتوث، از جفت‌سازی دستگاه همراه برای جفت‌سازی دستگاه‌های بلوتوث استفاده کنید.
  • برای آشنایی با نحوه برقراری ارتباط بلوتوث در پس‌زمینه، به راهنمای «ارتباط در پس‌زمینه» مراجعه کنید.
  • استفاده از WorkManager اغلب در صورتی کافی است که هیچ تأثیری بر کاربر در تأخیر ارتباط وجود نداشته باشد. اگر قفل بیدارباش دستی ضروری تشخیص داده شود، قفل بیدارباش را فقط برای مدت زمان فعالیت بلوتوث یا پردازش داده‌های فعالیت نگه دارید.

سنسورهای دستگاه

روش‌های مختلفی برای ردیابی داده‌های حسگر دستگاه مانند شمارش گام، داده‌های شتاب‌سنج یا ژیروسکوپ وجود دارد.

در Wear OS، از Wear Health Services برای دریافت داده‌های دستگاه مانند ارتفاع، ضربان قلب و مسافت طی شده استفاده کنید.

اگر داده‌ها توسط برنامه‌های دیگر جمع‌آوری می‌شوند، می‌توانید از Health Connect همراه با WorkManager برای بازیابی دوره‌ای داده‌ها استفاده کنید.

برای سناریوهایی مانند ردیابی دلتای گام‌ها یا مسافت طی شده، می‌توانید از Recording API در موبایل همراه با WorkManager برای بازیابی دوره‌ای داده‌ها استفاده کنید. برای دسترسی به داده‌های گام‌های تاریخی (مانند مجموع گام‌های روزانه یا گام‌های ۶ ساعت گذشته)، Health Connect همچنین از ردیابی گام روی دستگاه برای دستگاه‌هایی که اندروید ۱۴ یا بالاتر دارند، پشتیبانی می‌کند.

در شرایط خاص، ممکن است ردیابی حسگر دستگاه سفارشی با استفاده از SensorManager مورد نیاز باشد. SensorManager قفل‌های بیداری را از طرف برنامه دریافت نمی‌کند، مگر اینکه حسگر، حسگر بیدارباش باشد که می‌توان آن را با استفاده از API isWakeUpSensor شناسایی کرد.

توصیه

استفاده از حسگرها برای ضبط با نرخ نمونه‌برداری بالا می‌تواند باتری را به میزان قابل توجهی تخلیه کند، در اینجا توصیه‌هایی برای کاهش تخلیه باتری و استفاده از قفل بیدارباش ارائه شده است:

  • اگر ردیابی شامل شمارش گام‌ها یا مسافت طی شده است، از API ضبط برای ثبت داده‌ها به روشی با مصرف بهینه باتری استفاده کنید. برای دستگاه‌هایی که اندروید ۱۴ یا بالاتر دارند، Health Connect را برای دسترسی به تاریخچه دستگاه و تعداد گام‌های جمع‌آوری‌شده در نظر بگیرید.
  • برای ردیابی غیرفعال حسگر در Wear OS، از Wear Health Services برای بهینه‌سازی مصرف باتری استفاده کنید.
  • هنگام ثبت یک حسگر با SensorManager ، برای استفاده از منطق دسته‌بندی حسگر و کاهش تعداد وقفه‌های دریافتی برنامه، maxReportLatencyUs را بیش از 30 ثانیه تعریف کنید. هنگامی که دستگاه متعاقباً توسط یک محرک دیگر مانند تعامل کاربر، بازیابی موقعیت مکانی یا یک کار برنامه‌ریزی‌شده بیدار می‌شود، سیستم بلافاصله داده‌های حسگر ذخیره‌شده را ارسال می‌کند.
  • اگر برنامه شما به داده‌های موقعیت مکانی و حسگر نیاز دارد، بازیابی و پردازش رویداد آنها را همگام‌سازی کنید. با ادغام داده‌های حسگر در قفل بیداری کوتاه‌مدتی که سیستم برای به‌روزرسانی‌های موقعیت مکانی نگه می‌دارد، از نیاز به قفل بیداری برای بیدار نگه داشتن CPU جلوگیری می‌کنید. از یک worker یا یک قفل بیداری کوتاه‌مدت برای مدیریت آپلود و پردازش این داده‌های ترکیبی استفاده کنید.

پیام ابری فایربیس (FCM)

قفل بیداری هنگام ارسال یک پیام ابری Firebase (FCM) به برنامه ایجاد می‌شود. قفل بیداری پس از اتمام اجرای متد onMessageReceived() در پیام ابری FCM آزاد می‌شود.

نام‌های قفل بیدارباش

وقتی یک پیام FCM روی دستگاه دریافت می‌شود، یک قفل بیداری کوتاه با نام GOOGLE_C2DM ایجاد می‌شود، در اندروید ۱۶+ نام قفل بیداری GCM_MESSAGE است.

توصیه

ما روش‌های زیر را برای بهینه‌سازی رفتار FCM توصیه می‌کنیم:

  • فرکانس تحویل FCM را بهینه کنید.
  • از FCM با اولویت بالا استفاده نکنید، مگر اینکه پیام واقعاً نیاز به ارسال فوری داشته باشد.
  • در صورت نیاز به پردازش بیشتر، متد onMessageReceived() را در اسرع وقت تکمیل کنید یا یک worker را برای ادامه کار برنامه‌ریزی کنید. برای اطلاعات بیشتر به راهنمای firebase مراجعه کنید.

زمانبند کار

وظایف JobScheduler هنگام اجرای وظایف در پس‌زمینه، قفل‌های بیداری (wake locks) را به دست می‌آورند. این قفل‌های بیداری به برنامه‌ای که workerها را ایجاد کرده است، نسبت داده می‌شوند.

نام‌های قفل بیدارباش

نام‌های قفل بیداری که توسط JobScheduler انتخاب می‌شوند، به نسخه سیستم اندرویدی که روی آن اجرا می‌شوند و هدف کار بستگی دارند.

مواردی که بین دو علامت براکت قرار گرفته‌اند، متغیر هستند. برای مثال، "<package_name>" نام بسته برنامه شماست، نه متن تحت‌اللفظی <package name> . با این حال، *job* دنباله کاراکتری *job* با ستاره است؛ ستاره‌ها به عنوان wild card استفاده نمی‌شوند.

اندروید ۱۵ و پایین‌تر

وظایف آغاز شده توسط کاربر، قفل‌های بیداری را با نام‌هایی مطابق با این الگو ایجاد می‌کنند:

*job*u/@<name_space>@/<package_name>/<classname>

مشاغل دیگر از این الگو استفاده می‌کنند:

*job*/@<name_space>@/<package_name>/<classname>
اندروید ۱۶.۱ و بالاتر

وظایف آغاز شده توسط کاربر، قفل‌های بیداری با نام‌هایی مطابق با این الگو ایجاد می‌کنند:

*job*u/@<name_space>@/#<trace_tag>#/<package_name>/<classname>

کارهای تسریع‌شده از این الگو استفاده می‌کنند:

*job*e/@<name_space>@/#<trace_tag>#/<package_name>/<classname>

مشاغل معمولی از این الگو استفاده می‌کنند:

*job*r/@<name_space>@/#<trace_tag>#/<package_name>/<classname>
مثال

فرض کنید یک کار تسریع‌شده با فضای نام backup وجود دارد و برچسب ردیابی started . نام بسته com.example.app است و کلاسی که کار را ایجاد کرده com.backup.BackupFileService است.

در دستگاه‌هایی که اندروید ۱۵ یا پایین‌تر دارند، قفل بیدارباش به این صورت نامگذاری می‌شود:

*job*/@backup@/com.example.app/com.backup.BackupFileService

در دستگاه‌هایی که اندروید ۱۶.۱ یا بالاتر دارند، قفل بیدارباش به صورت زیر نامگذاری می‌شود:

*job*e/@backup@/#started#/com.example.app/com.backup.BackupFileService

توصیه

  • برای موارد دانلود/آپلود که توسط کاربر آغاز می‌شوند، قفل بیدارباش دستی را انتخاب نکنید. در عوض، از رابط برنامه‌نویسی کاربردی انتقال داده توسط کاربر (UIDT) استفاده کنید. این مسیر تعیین‌شده برای وظایف انتقال داده طولانی‌مدت است که توسط کاربر آغاز می‌شوند.
  • اگر متوجه شدید که wake lock های ایجاد شده توسط JobScheduler استفاده بالایی از wake lock دارند، ممکن است به این دلیل باشد که job خود را به اشتباه پیکربندی کرده‌اید تا در سناریوهای خاصی تکمیل نشود. دلایل توقف job را بررسی کنید، به خصوص اگر موارد زیادی از STOP_REASON_TIMEOUT را مشاهده می‌کنید.
  • میزان استفاده خود از وظایف JobScheduler را بررسی کنید. به طور خاص، از راهنمایی‌های ما برای بهینه‌سازی مصرف باتری برای APIهای زمان‌بندی وظایف پیروی کنید.

مکان

LocationManager و FusedLocationProviderClient از قفل‌های بیداری برای دریافت و ارائه موقعیت مکانی دستگاه استفاده می‌کنند. قفل‌های بیداری به برنامه‌ای که آن APIها را فراخوانی کرده است، نسبت داده می‌شوند.

نام‌های قفل بیدارباش

سرویس‌های موقعیت مکانی از نام‌های زیر استفاده می‌کنند:

  • CollectionLib-SigCollector
  • NetworkLocationLocator
  • NetworkLocationScanner
  • NlpCollectorWakeLock
  • NlpWakeLock
  • *location*

توصیه

  • برای بهینه‌سازی استفاده از موقعیت مکانی ، به راهنمایی‌های ما مراجعه کنید. پیاده‌سازی وقفه‌های زمانی، استفاده از دسته‌بندی درخواست‌های موقعیت مکانی یا استفاده از به‌روزرسانی‌های غیرفعال موقعیت مکانی را در نظر بگیرید.
  • از ایجاد یک قفل بیداری جداگانه و مداوم برای ذخیره‌سازی داده‌های مکان خودداری کنید، زیرا این کار اضافی است و باید حذف شود. هنگام درخواست به‌روزرسانی‌های مکان با استفاده از APIهای FusedLocationProvider یا LocationManager ، سیستم به طور خودکار در طول فراخوانی رویداد مکان، دستگاه را بیدار می‌کند. در عوض، رویدادهای مکان را در حافظه یا فضای ذخیره‌سازی ذخیره کنید و رویدادهای مکان را به صورت دوره‌ای با استفاده WorkManager پردازش کنید.

پیام‌رسانی از راه دور

این بخش سناریوهایی را مورد بحث قرار می‌دهد که شامل پیام‌رسانی از راه دور هستند و در آن‌ها برنامه‌ها ممکن است نیاز به حفظ اتصال یا واکنش به رویدادهای سایر دستگاه‌ها داشته باشند، که به طور بالقوه بر استفاده از قفل بیدارباش تأثیر می‌گذارد. موارد استفاده رایج عبارتند از:

  • برنامه‌های همراه نظارت تصویری یا صوتی که نیاز به نظارت بر رویدادهای رخ داده در یک دستگاه خارجی متصل از طریق شبکه محلی دارند.
  • برنامه‌های پیام‌رسانی که اتصال سوکت شبکه را با نسخه دسکتاپ حفظ می‌کنند.

بیشتر بیدارباش‌ها در این سناریوهای پیام‌رسانی از راه دور، قفل‌های بیدارباش هسته هستند. از آنجایی که قفل‌های بیدارباش هسته به برنامه نسبت داده نمی‌شوند، هیچ نام قفل بیدارباش مرتبطی برای فهرست کردن در اینجا وجود ندارد.

توصیه

  • اگر رویدادهای شبکه می‌توانند در سمت سرور پردازش شوند، از FCM برای دریافت اطلاعات در مورد کلاینت استفاده کنید. در صورت نیاز به پردازش بیشتر داده‌های FCM، می‌توانید یک کارگر تسریع‌شده را برنامه‌ریزی کنید.
  • اگر رویدادها باید در سمت کلاینت با استفاده از اتصال سوکت پردازش شوند، برای گوش دادن به وقفه‌های رویداد نیازی به قفل بیداری نیست. هنگامی که بسته‌های داده به رادیوی Wi-Fi یا تلفن همراه می‌رسند، سخت‌افزار رادیو یک وقفه را به شکل قفل بیداری هسته ایجاد می‌کند. سپس می‌توانید یک کارگر را برنامه‌ریزی کنید یا یک قفل بیداری برای پردازش داده‌ها تهیه کنید.
  • برای مثال، اگر ktor-network برای گوش دادن به بسته‌های داده در یک سوکت شبکه استفاده می‌کنید، فقط زمانی باید قفل بیداری را فعال کنید که بسته‌ها به کلاینت تحویل داده شده باشند.

مدیر کار

Workerهای WorkManager هنگام اجرای وظایف در پس‌زمینه، قفل‌های بیداری (wake locks) را دریافت می‌کنند. این قفل‌های بیداری به برنامه‌ای که Workerها را ایجاد کرده است، نسبت داده می‌شوند.

نام‌های قفل بیدارباش

نام‌های قفل بیداری که توسط WorkManager انتخاب می‌شوند، به نسخه سیستم عامل اندروید که روی آن اجرا می‌شوند بستگی دارند.

اندروید ۱۵ و پایین‌تر

وظایف WorkManager قفل‌های بیداری با نام‌هایی مطابق با این الگو ایجاد می‌کنند:

*job*/<package_name>/androidx.work.impl.background.systemjob.SystemJobService
اندروید ۱۶.۱ و بالاتر

وظایف تسریع‌شده، قفل‌های بیداری با نام‌هایی مطابق با این الگو ایجاد می‌کنند:

*job*e/#<trace_tag>#/<package_name>/androidx.work.impl.background.systemjob.SystemJobService

وظایف منظم از این الگو پیروی می‌کنند: 

*job*r/#<trace_tag>#/<package_name>/androidx.work.impl.background.systemjob.SystemJobService

به طور پیش‌فرض، <trace_tag> نام worker است.

مثال

فرض کنید یک کارگر تسریع‌شده به نام BackupFileWorker وجود دارد. نام بسته آن com.example.app است.

در دستگاه‌هایی که اندروید ۱۵ یا پایین‌تر دارند، قفل بیدارباش به این صورت نامگذاری می‌شود: 

*job*/com.example.app/androidx.work.impl.background.systemjob.SystemJobService

در دستگاه‌هایی که اندروید ۱۶ یا بالاتر دارند و از WorkManager 2.10.0+ استفاده می‌کنند، قفل بیدارباش به صورت زیر نامگذاری می‌شود: 

*job*e/#BackupFileWorker#/com.example.app/androidx.work.impl.background.systemjob.SystemJobService

توصیه

  • برای اینکه تگ‌های قفل بیداری در اندروید ۱۶.۱ یا بالاتر واضح‌تر شوند، نسخه WorkManager خود را به آخرین نسخه پایدار ارتقا دهید.
  • میزان استفاده خود از Workerهای WorkManager را بررسی کنید. به طور خاص، مطمئن شوید که از دستورالعمل‌های ما برای بهینه‌سازی مصرف باتری برای APIهای زمان‌بندی وظایف پیروی می‌کند. برای اینکه تگ‌های wake lock در اندروید ۱۶.۱ یا بالاتر طولانی‌تر شوند، از متد setTraceTag روی Worker استفاده کنید تا اطلاعات اشکال‌زدایی بیشتری، مانند اینکه کدام کلاس Worker را زمان‌بندی کرده است، اضافه کنید.
  • اگر متوجه شدید که wake lock های ایجاد شده توسط WorkManager از wake lock بالایی استفاده می‌کنند، ممکن است به این دلیل باشد که worker خود را به اشتباه پیکربندی کرده‌اید تا در سناریوهای خاصی کار را تمام نکند. دلایل توقف worker را بررسی کنید، به خصوص اگر موارد زیادی از STOP_REASON_TIMEOUT را مشاهده می‌کنید.
  • علاوه بر ثبت دلایل توقف worker، به مستندات ما در مورد اشکال‌زدایی workerهایتان مراجعه کنید. همچنین، جمع‌آوری و تجزیه و تحلیل ردپاهای سیستم را در نظر بگیرید تا بفهمید چه زمانی wake lockها دریافت و آزاد می‌شوند.

_ناشناس

اگر ابزارهای اشکال‌زدایی فکر کنند که نام قفل بیداری حاوی اطلاعات شخصی قابل شناسایی (PII) است، نام واقعی قفل بیداری را نمایش نمی‌دهند. در عوض، قفل بیداری را با عنوان _UNKNOWN برچسب‌گذاری می‌کنند. برای مثال، اگر نام قفل بیداری حاوی آدرس ایمیل باشد، ابزارها ممکن است این کار را انجام دهند.

توصیه

از بهترین شیوه‌های نامگذاری قفل بیداری پیروی کنید و از استفاده از PII در نام قفل بیداری خودداری کنید. اگر قفل بیداری با نام _UNKNOWN را پیدا کردید که به برنامه شما نسبت داده شده است، سعی کنید آن قفل بیداری را شناسایی کنید و نام دیگری به آن بدهید.