ওয়েক লকের ব্যবহারের ক্ষেত্রে সনাক্ত করুন এবং অপ্টিমাইজ করুন

এই ডকুমেন্টটি আপনার অ্যাপে ওয়েক লকের ব্যবহারের কেসগুলি সনাক্ত এবং অপ্টিমাইজ করতে সাহায্য করে, এবং এই ব্যবহারের কেসের সাথে সম্পর্কিত অন্যান্য লাইব্রেরি বা সিস্টেম API দ্বারা অর্জিত ওয়েক লকগুলি হাইলাইট করতে সাহায্য করে। যেহেতু এই ওয়েক লকগুলি আপনার অ্যাপের জন্য দায়ী, তাই সমস্যাযুক্ত ওয়েক লকের উৎস চিহ্নিত করা চ্যালেঞ্জিং হতে পারে। ভুল API ব্যবহারের ফলে আপনার অ্যাপটি অতিরিক্ত ওয়েক লক ব্যবহারের জন্য ফ্ল্যাগ করা হতে পারে, এমনকি যদি আপনি স্পষ্টভাবে ওয়েক লকগুলি অর্জন না করেন।

This document lists some common wake lock names you might encounter when using the wake lock debugging tools or in reports from vitals . These names can originate from a library or system API, or they might be obfuscated. By using the debugging tools to identify misbehaving wake locks and then searching for the wake lock name in this document, you can determine which API may be causing the problem and find recommendations on how to optimize its usage.

এই নথিতে ওয়েক লক অর্জনের জন্য সাধারণ ব্যবহারের ধরণগুলি বর্ণনা করা হয়েছে, বিভিন্ন API এবং লাইব্রেরি দ্বারা ব্যবহৃত ওয়েক লকের নামগুলি বিশদভাবে বর্ণনা করা হয়েছে এবং ওয়েক লকের ব্যবহার অপ্টিমাইজ এবং হ্রাস করার জন্য সুপারিশ এবং সর্বোত্তম অনুশীলনগুলি প্রদান করা হয়েছে।

• অ্যালার্ম ম্যানেজার
• অডিও এবং মিডিয়া
• ব্লুটুথ
• ডিভাইস সেন্সর
• ফায়ারবেস ক্লাউড মেসেজ (FCM)
• জবশিডিউলার
• স্থান
• দূরবর্তী বার্তাপ্রেরণ
• ওয়ার্ক ম্যানেজার
• _UNKNOWN : যদি ওয়েক লকের নামটি ব্যক্তিগতভাবে সনাক্তযোগ্য তথ্য (PII) ব্যবহার করে বলে মনে হয় তবে ডিবাগিং টুল দ্বারা দেখানো হয়।

অ্যালার্ম ম্যানেজার

AlarmManager ওয়েক লকগুলি অর্জন করে এবং সেগুলিকে কলিং অ্যাপে অ্যাট্রিবিউট করে। অ্যালার্ম বন্ধ হয়ে গেলে AlarmManager ওয়েক লকটি অর্জন করে এবং অ্যালার্ম সম্প্রচারের onReceive() পদ্ধতিটি কার্যকর করা শেষ হলে লকটি ছেড়ে দেয়।

ওয়েক লকের নাম

AlarmManager *alarm* নামক ওয়েক লক তৈরি করে। (তারকাচিহ্নগুলি ওয়েক লকের নামের অংশ, এগুলি ওয়াইল্ড কার্ডের প্রতিনিধিত্ব করে না।)

সুপারিশ

অ্যালার্ম আচরণকে সর্বোত্তম করার জন্য আমরা নিম্নলিখিত অনুশীলনগুলি সুপারিশ করি:

• সঠিক বা অনির্দিষ্ট অ্যালার্মের মধ্যে একটি বেছে নিতে অ্যালার্মের ধরণটি দেখুন। যদি আপনার অ্যালার্মটি সুনির্দিষ্ট না হওয়ার প্রয়োজন হয়, তাহলে সিস্টেমকে সময়সূচীতে আরও নমনীয়তা দেওয়ার জন্য অনির্দিষ্ট অ্যালার্ম ব্যবহার করুন, যা ব্যাটারির আয়ু উন্নত করতে পারে।
• সিস্টেম-আরোপিত অ্যালার্ম কোটা সম্পর্কে সচেতন থাকুন এবং সেগুলি মেনে আপনার অ্যাপটি ডিজাইন করুন।
• onReceive() পদ্ধতিতে দীর্ঘ কাজ করা এড়িয়ে চলুন এবং অ্যালার্মের পরে অতিরিক্ত প্রক্রিয়াকরণের প্রয়োজন হলে কর্মীদের সময়সূচী নির্ধারণ করুন।

অডিও এবং মিডিয়া

অডিও রেকর্ডিং বা প্লে করার সময় মিডিয়া API গুলি ওয়েক লক অর্জন করতে পারে। ওয়েক লকগুলি কলিং অ্যাপের জন্য দায়ী করা হয়।

ওয়েক লকের নাম

মিডিয়া এপিআইগুলি Audio দিয়ে শুরু হওয়া বিভিন্ন নামের ওয়েক লক অর্জন করে:

• AudioBitPerfect : লসলেস ইউএসবি অডিও প্লেব্যাকের জন্য ব্যবহৃত।
• AudioDirectOut : টিভি বা বিশেষ ডিভাইসে লসলেস অডিও প্লেব্যাকের জন্য ব্যবহৃত হয়।
• AudioDup : ব্লুটুথ বা ইউএসবি ব্যবহার করে সংযুক্ত থাকাকালীন বিজ্ঞপ্তি প্লেব্যাকের জন্য ব্যবহৃত হয়।
• AudioIn : মাইক্রোফোন সক্রিয় থাকাকালীন ক্যামকর্ডার মোডে অডিও ক্যাপচারের জন্য ব্যবহৃত হয়।
• AudioMix : একটি সাধারণ ডিভাইসে অডিও প্লেব্যাকের জন্য ব্যবহৃত হয়।
• AudioOffload : এই মোডটি সমর্থন করে এমন অ্যাপগুলির জন্য দীর্ঘমেয়াদী সঙ্গীত-শুধু প্লেব্যাকের জন্য ব্যবহৃত হয়।
• AudioSpatial : স্পেশিয়াল অডিও সমর্থন করে এমন ডিভাইসগুলিতে মাল্টি-চ্যানেল মুভি বা মিউজিক অডিও প্লেব্যাকের জন্য ব্যবহৃত হয়।
• AudioUnknown : অন্যান্য পরিস্থিতি প্রযোজ্য না হলে ব্যবহৃত হয়।
• MmapCapture : কম লেটেন্সি অডিও ক্যাপচারের জন্য ব্যবহৃত।
• MmapPlayback : কম-বিলম্বিত প্লেব্যাকের জন্য ব্যবহৃত হয়, যেমন গেমিং বা পেশাদার অডিও অ্যাপ্লিকেশনের জন্য।

সুপারিশ

আমরা নিম্নলিখিত অনুশীলনগুলি সুপারিশ করি:

• Audio দিয়ে শুরু হওয়া ওয়েক লকের নাম ঘোষণা করবেন না।
• আপনি যদি মিডিয়া এপিআই ব্যবহার করেন, তাহলে আপনাকে সরাসরি ওয়েক লক কিনতে হবে না; আপনার জন্য প্রয়োজনীয় ওয়েক লকগুলি অর্জনের জন্য আপনি এপিআইগুলির উপর নির্ভর করতে পারেন।
• যখন আপনি মিডিয়া API ব্যবহার করেন, তখন মিডিয়া সেশন এবং সংশ্লিষ্ট ফোরগ্রাউন্ড পরিষেবাটি বন্ধ করুন যখন আপনার আর প্রয়োজন হবে না।

ব্লুটুথ

প্ল্যাটফর্ম ব্লুটুথ এপিআইগুলি মূলত ব্লুটুথ অ্যাকশনের সময় কার্নেল ওয়েক লক ধারণ করে, যা অ্যাপ্লিকেশনের সাথে সম্পর্কিত নয়।

সুপারিশ

• ব্লুটুথ পেয়ারিংয়ের সময় ম্যানুয়াল ওয়েক লক এড়াতে ব্লুটুথ ডিভাইস পেয়ার করার জন্য কম্প্যানিয়ন ডিভাইস পেয়ারিং ব্যবহার করুন।
• ব্যাকগ্রাউন্ড ব্লুটুথ কমিউনিকেশন কীভাবে করবেন তা বুঝতে ব্যাকগ্রাউন্ড গাইডেন্সে থাকা কমিউনিকেশনটি দেখুন।
• বিলম্বিত যোগাযোগের ক্ষেত্রে ব্যবহারকারীর কোনও প্রভাব না থাকলে WorkManager ব্যবহার করা প্রায়শই যথেষ্ট। যদি ম্যানুয়াল ওয়েক লক প্রয়োজন বলে মনে করা হয়, তাহলে শুধুমাত্র ব্লুটুথ কার্যকলাপ বা কার্যকলাপ ডেটা প্রক্রিয়াকরণের সময়কালের জন্য ওয়েক লকটি ধরে রাখুন।

ডিভাইস সেন্সর

ডিভাইস সেন্সর ডেটা ট্র্যাক করার জন্য বিভিন্ন পদ্ধতি রয়েছে যেমন ধাপ গণনা, অ্যাক্সিলোমিটার বা জাইরোস্কোপ ডেটা।

Wear OS-এ, উচ্চতা, হৃদস্পন্দন এবং ভ্রমণের দূরত্বের মতো ডিভাইসের ডেটা সংগ্রহ করতে Wear Health Services ব্যবহার করুন।

যদি অন্য অ্যাপ্লিকেশন দ্বারা ডেটা সংগ্রহ করা হয়, তাহলে আপনি পর্যায়ক্রমে ডেটা পুনরুদ্ধার করতে WorkManager এর সাথে Health Connect ব্যবহার করতে পারেন।

ধাপের ডেল্টা ট্র্যাকিং বা ভ্রমণ করা দূরত্বের মতো পরিস্থিতিতে, আপনি পর্যায়ক্রমে ডেটা পুনরুদ্ধার করতে WorkManager-এর সাথে মিলিত মোবাইলে রেকর্ডিং API ব্যবহার করতে পারেন। ঐতিহাসিক পদক্ষেপের ডেটা (যেমন দৈনিক মোট ধাপ, বা গত 6 ঘন্টার ধাপ) অ্যাক্সেস করতে, Health Connect Android 14 বা উচ্চতর ভার্সন চালানো ডিভাইসগুলির জন্য অন-ডিভাইস ধাপ ট্র্যাকিং সমর্থন করে।

কিছু পরিস্থিতিতে, SensorManager ব্যবহার করে কাস্টম ডিভাইস সেন্সর ট্র্যাকিংয়ের প্রয়োজন হতে পারে। SensorManager অ্যাপের পক্ষ থেকে ওয়েক লক অর্জন করে না, যদি না সেন্সরটি একটি ওয়েক আপ সেন্সর হয়, যা isWakeUpSensor API ব্যবহার করে সনাক্ত করা যায়।

সুপারিশ

উচ্চ স্যাম্পলিং হারে রেকর্ড করার জন্য সেন্সর ব্যবহার করলে ব্যাটারি উল্লেখযোগ্যভাবে নিষ্কাশন হতে পারে, ব্যাটারি নিষ্কাশন এবং ওয়েক লকের ব্যবহার কমাতে এখানে সুপারিশ দেওয়া হল:

• যদি ধাপের সংখ্যা বা ভ্রমণের দূরত্ব ট্র্যাক করা হয়, তাহলে ব্যাটারি-সাশ্রয়ী পদ্ধতিতে ডেটা রেকর্ড করতে রেকর্ডিং API ব্যবহার করুন। Android 14 বা তার উচ্চতর সংস্করণে চলমান ডিভাইসগুলির জন্য, ঐতিহাসিক ডিভাইস এবং সমষ্টিগত ধাপের সংখ্যা অ্যাক্সেস করার জন্য Health Connect বিবেচনা করুন।
• Wear OS-এ প্যাসিভ সেন্সর ট্র্যাকিংয়ের জন্য, ব্যাটারি ব্যবহার অপ্টিমাইজ করতে Wear Health Services ব্যবহার করুন।
• SensorManager এ একটি সেন্সর নিবন্ধন করার সময়, সেন্সর ব্যাচিং লজিক ব্যবহার করতে এবং অ্যাপ্লিকেশনটি যে পরিমাণ ইন্টারাপ্ট গ্রহণ করে তা কমাতে 30 সেকেন্ডের বেশি সময় ধরে maxReportLatencyUs নির্ধারণ করুন। যখন ডিভাইসটি পরবর্তীতে অন্য কোনও ট্রিগার যেমন ব্যবহারকারীর ইন্টারঅ্যাকশন, অবস্থান পুনরুদ্ধার, বা একটি নির্ধারিত কাজের মাধ্যমে জাগ্রত হয়, তখন সিস্টেমটি তাৎক্ষণিকভাবে ক্যাশেড সেন্সর ডেটা প্রেরণ করবে।
• যদি আপনার অ্যাপের লোকেশন এবং সেন্সর ডেটা উভয়েরই প্রয়োজন হয়, তাহলে তাদের ইভেন্ট পুনরুদ্ধার এবং প্রক্রিয়াকরণ সিঙ্ক্রোনাইজ করুন। লোকেশন আপডেটের জন্য সিস্টেমের ধারণ করা সংক্ষিপ্ত ওয়েক লকের সাথে সেন্সর রিডিং একত্রিত করে, আপনি CPU-কে জাগ্রত রাখার জন্য একটি ওয়েক লকের প্রয়োজন এড়াতে পারেন। এই সম্মিলিত ডেটা আপলোড এবং প্রক্রিয়াকরণ পরিচালনা করার জন্য একটি ওয়ার্কার বা একটি স্বল্প-মেয়াদী ওয়েক লক ব্যবহার করুন।

ফায়ারবেস ক্লাউড মেসেজ (FCM)

অ্যাপে একটি Firebase Cloud Message (FCM) সম্প্রচার সরবরাহ করার সময় একটি ওয়েক লক অর্জিত হয়। FCM সম্প্রচার onMessageReceived() পদ্ধতি কার্যকর করা শেষ হলে ওয়েক লকটি প্রকাশ করা হয়।

ওয়েক লকের নাম

যখন ডিভাইসে একটি FCM বার্তা আসে, তখন GOOGLE_C2DM নামে একটি সংক্ষিপ্ত ওয়েক লক ধরে রাখা হয়, Android 16+ এ ওয়েক লকের নাম GCM_MESSAGE ।

সুপারিশ

FCM আচরণ অপ্টিমাইজ করার জন্য আমরা নিম্নলিখিত অনুশীলনগুলি সুপারিশ করি:

• FCM ডেলিভারির ফ্রিকোয়েন্সি অপ্টিমাইজ করুন।
• বার্তাটি তাৎক্ষণিকভাবে পৌঁছে দেওয়ার প্রয়োজন না হলে উচ্চ-অগ্রাধিকার FCM ব্যবহার করবেন না।
• onMessageReceived() পদ্ধতিটি যত তাড়াতাড়ি সম্ভব সম্পন্ন করুন অথবা অতিরিক্ত প্রক্রিয়াকরণের প্রয়োজন হলে কাজটি চালিয়ে যাওয়ার জন্য একজন কর্মীকে সময়সূচী করুন। আরও তথ্যের জন্য firebase নির্দেশিকা দেখুন।

জবশিডিউলার

জবশিডিউলার জবগুলি ব্যাকগ্রাউন্ডে কাজ সম্পাদন করার সময় ওয়েক লক অর্জন করে। ওয়েক লকগুলি সেই অ্যাপের জন্য দায়ী করা হয় যা কর্মীদের তৈরি করেছিল।

ওয়েক লকের নাম

JobScheduler দ্বারা অর্জিত ওয়েক লকের নামগুলি অ্যান্ড্রয়েড সিস্টেমের কোন সংস্করণে চলছে এবং কাজের উদ্দেশ্যের উপর নির্ভর করে।

কোণ বন্ধনী দ্বারা বেষ্টিত আইটেমগুলি ভেরিয়েবল। উদাহরণস্বরূপ, "<package_name>" হল আপনার অ্যাপের প্যাকেজের নাম, <package name> আক্ষরিক টেক্সট নয়। তবে, *job* হল অক্ষর ক্রম *job* , তারকাচিহ্ন সহ; তারকাচিহ্নগুলি ওয়াইল্ড কার্ড হিসাবে ব্যবহার করা হচ্ছে না।

অ্যান্ড্রয়েড ১৫ এবং তার আগের ভার্সন

ব্যবহারকারীর দ্বারা শুরু করা কাজগুলি এই প্যাটার্ন অনুসরণ করে নাম সহ ওয়েক লক তৈরি করে:

*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>

উদাহরণ

ধরুন namespace backup এবং trace tag দিয়ে একটি expedited কাজ 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) API ব্যবহার করুন। এটি ব্যবহারকারীর দ্বারা শুরু করা দীর্ঘমেয়াদী ডেটা ট্রান্সফার কাজের জন্য নির্ধারিত পথ।
• যদি আপনি JobScheduler দ্বারা তৈরি ওয়েক লকগুলিতে উচ্চ ওয়েক লক ব্যবহারের শনাক্ত করেন, তাহলে এটি হতে পারে কারণ আপনি কিছু পরিস্থিতিতে আপনার কাজটি ভুলভাবে সম্পূর্ণ না করার জন্য কনফিগার করেছেন। কাজ বন্ধ করার কারণগুলি বিশ্লেষণ করার কথা বিবেচনা করুন, বিশেষ করে যদি আপনি STOP_REASON_TIMEOUT এর উচ্চ ঘটনা দেখতে পান।
• JobScheduler টাস্কের ব্যবহার নিরীক্ষণ করুন। বিশেষ করে, টাস্ক শিডিউলিং API-এর জন্য ব্যাটারি ব্যবহার অপ্টিমাইজ করার জন্য আমাদের নির্দেশিকা অনুসরণ করুন।

স্থান

LocationManager এবং FusedLocationProviderClient ডিভাইসের অবস্থান অর্জন এবং সরবরাহ করার জন্য ওয়েক লক ব্যবহার করে। ওয়েক লকগুলি সেই অ্যাপের সাথে সম্পর্কিত যা এই API গুলিকে কল করেছিল।

ওয়েক লকের নাম

অবস্থান পরিষেবাগুলি নিম্নলিখিত নামগুলি ব্যবহার করে:

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

সুপারিশ

• অবস্থানের ব্যবহার অপ্টিমাইজ করার জন্য আমাদের নির্দেশিকা দেখুন। টাইমআউট বাস্তবায়ন, অবস্থান অনুরোধ ব্যাচিং ব্যবহার, অথবা প্যাসিভ অবস্থান আপডেট ব্যবহার করার কথা বিবেচনা করুন।
• লোকেশন ডেটা ক্যাশ করার জন্য আলাদা, একটানা ওয়েক লক নেওয়া এড়িয়ে চলুন, কারণ এটি অপ্রয়োজনীয় এবং এটি অপসারণ করা উচিত। FusedLocationProvider বা LocationManager API ব্যবহার করে লোকেশন আপডেটের অনুরোধ করার সময়, লোকেশন ইভেন্ট কলব্যাকের সময় সিস্টেম স্বয়ংক্রিয়ভাবে একটি ডিভাইস ওয়েক-আপ ট্রিগার করে। পরিবর্তে, লোকেশন ইভেন্টগুলি মেমরি বা স্টোরেজে সংরক্ষণ করুন এবং WorkManager ব্যবহার করে পর্যায়ক্রমে লোকেশন ইভেন্টগুলি প্রক্রিয়া করুন।

দূরবর্তী বার্তাপ্রেরণ

এই বিভাগে রিমোট মেসেজিং সম্পর্কিত পরিস্থিতি নিয়ে আলোচনা করা হয়েছে যেখানে অ্যাপগুলিকে সংযোগ বজায় রাখতে হতে পারে বা অন্যান্য ডিভাইস থেকে ইভেন্টগুলিতে প্রতিক্রিয়া জানাতে হতে পারে, যা সম্ভাব্যভাবে ওয়েক লকের ব্যবহারকে প্রভাবিত করতে পারে। সাধারণ ব্যবহারের ক্ষেত্রে অন্তর্ভুক্ত:

• ভিডিও বা শব্দ পর্যবেক্ষণকারী সহচর অ্যাপ যা স্থানীয় নেটওয়ার্কের মাধ্যমে সংযুক্ত একটি বহিরাগত ডিভাইসে ঘটে যাওয়া ঘটনাগুলি পর্যবেক্ষণ করতে প্রয়োজন।
• মেসেজিং অ্যাপ যা ডেস্কটপ ভেরিয়েন্টের সাথে নেটওয়ার্ক সকেট সংযোগ বজায় রাখে।

এই দূরবর্তী বার্তাপ্রেরণের ক্ষেত্রে বেশিরভাগ ওয়েকআপই কার্নেল ওয়েক লক। যেহেতু কার্নেল ওয়েক লকগুলি অ্যাপের সাথে সম্পর্কিত নয়, তাই এখানে তালিকাভুক্ত করার জন্য কোনও সম্পর্কিত ওয়েক লকের নাম নেই।

সুপারিশ

• যদি নেটওয়ার্ক ইভেন্টগুলি সার্ভার সাইডে প্রক্রিয়া করা যায়, তাহলে ক্লায়েন্ট সম্পর্কে তথ্য পেতে FCM ব্যবহার করুন। FCM ডেটার অতিরিক্ত প্রক্রিয়াকরণের প্রয়োজন হলে আপনি একজন দ্রুত কর্মীর সময়সূচী নির্ধারণ করতে পারেন।
• যদি ইভেন্টগুলি ক্লায়েন্ট সাইডে সকেট সংযোগ ব্যবহার করে প্রক্রিয়া করতে হয়, তাহলে ইভেন্ট ইন্টারাপ্ট শোনার জন্য ওয়েক লকের প্রয়োজন হয় না। যখন ডেটা প্যাকেটগুলি ওয়াই-ফাই বা সেলুলার রেডিওতে পৌঁছায়, তখন রেডিও হার্ডওয়্যার কার্নেল ওয়েক লকের আকারে একটি ইন্টারাপ্ট ট্রিগার করে। এরপর আপনি একজন কর্মীকে সময়সূচী করতে পারেন অথবা ডেটা প্রসেস করার জন্য একটি ওয়েক লক কিনতে পারেন।
• উদাহরণস্বরূপ, যদি আপনি নেটওয়ার্ক সকেটে ডেটা প্যাকেট শোনার জন্য ktor-network ব্যবহার করেন, তাহলে ক্লায়েন্টের কাছে প্যাকেট সরবরাহ করা হয়ে গেলেই কেবল একটি ওয়েক লক ব্যবহার করা উচিত।

ওয়ার্ক ম্যানেজার

ওয়ার্কম্যানেজার কর্মীরা ব্যাকগ্রাউন্ডে কাজ সম্পাদন করার সময় ওয়েক লক অর্জন করে। ওয়েক লকগুলি সেই অ্যাপের জন্য দায়ী করা হয় যা কর্মীদের তৈরি করেছিল।

ওয়েক লকের নাম

ওয়ার্কম্যানেজার কর্তৃক অর্জিত ওয়েক লকের নামগুলি অ্যান্ড্রয়েড সিস্টেমের কোন সংস্করণে চলছে তার উপর নির্ভর করে।

অ্যান্ড্রয়েড ১৫ এবং তার আগের ভার্সন

ওয়ার্কম্যানেজার টাস্কগুলি এই প্যাটার্ন অনুসরণ করে নাম সহ ওয়েক লক তৈরি করে:

*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> হল কর্মীর নাম।

উদাহরণ

ধরুন 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 কর্মীদের আপনার ব্যবহার নিরীক্ষণ করুন। বিশেষ করে, টাস্ক শিডিউলিং API-এর জন্য ব্যাটারি ব্যবহারের অপ্টিমাইজেশনের জন্য আমাদের নির্দেশিকা অনুসরণ করে কিনা তা যাচাই করুন। Android 16.1 বা উচ্চতর সংস্করণে ওয়েক লক ট্যাগগুলিকে আরও স্পষ্ট করে তুলতে, কর্মীর উপর setTraceTag পদ্ধতি ব্যবহার করে আরও ডিবাগ তথ্য যোগ করুন, যেমন কোন শ্রেণী কর্মীকে শিডিউল করেছে।
• যদি আপনি WorkManager দ্বারা তৈরি ওয়েক লকগুলি উচ্চ ওয়েক লক ব্যবহারের সাথে শনাক্ত করেন, তাহলে এটি হতে পারে কারণ আপনি আপনার কর্মীকে ভুলভাবে কনফিগার করেছেন যাতে নির্দিষ্ট পরিস্থিতিতে এটি সম্পূর্ণ না হয়। কর্মী স্টপের কারণগুলি বিশ্লেষণ করার কথা বিবেচনা করুন, বিশেষ করে যদি আপনি STOP_REASON_TIMEOUT এর উচ্চ ঘটনা দেখতে পান।
• কর্মীদের স্টপের কারণ লগ করার পাশাপাশি, আপনার কর্মীদের ডিবাগ করার বিষয়ে আমাদের ডকুমেন্টেশনটি দেখুন। এছাড়াও, ওয়েক লকগুলি কখন অধিগ্রহণ এবং প্রকাশ করা হয় তা বোঝার জন্য সিস্টেম ট্রেস সংগ্রহ এবং বিশ্লেষণ করার কথা বিবেচনা করুন।

_অজানা

যদি ডিবাগিং টুলগুলি মনে করে যে একটি ওয়েক লকের নামটিতে ব্যক্তিগতভাবে সনাক্তযোগ্য তথ্য (PII) রয়েছে, তাহলে তারা প্রকৃত ওয়েক লকের নাম প্রদর্শন করে না। পরিবর্তে, তারা ওয়েক লকটিকে _UNKNOWN হিসাবে লেবেল করে। উদাহরণস্বরূপ, যদি ওয়েক লকের নামটিতে একটি ইমেল ঠিকানা থাকে তবে টুলগুলি এটি করতে পারে।

সুপারিশ

ওয়েক লকের নামকরণের সর্বোত্তম পদ্ধতি অনুসরণ করুন এবং ওয়েক লকের নামে PII ব্যবহার করা এড়িয়ে চলুন। যদি আপনি আপনার অ্যাপে _UNKNOWN নামের একটি ওয়েক লক খুঁজে পান, তাহলে কোন ওয়েক লকটি তা সনাক্ত করার চেষ্টা করুন এবং এটিকে একটি ভিন্ন নাম দিন।