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

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

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

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

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

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

ওয়েক লক নাম

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

সুপারিশ

অ্যালার্মের কার্যকারিতা উন্নত করার জন্য আমরা নিম্নলিখিত পদ্ধতিগুলো সুপারিশ করি:

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

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

অডিও রেকর্ড বা প্লে করার সময় মিডিয়া এপিআইগুলো ওয়েক লক অর্জন করতে পারে। এই ওয়েক লকগুলো কলিং অ্যাপের নামে আরোপিত হয়।

ওয়েক লক নাম

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

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

সুপারিশ

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

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

ব্লুটুথ

প্ল্যাটফর্মের ব্লুটুথ এপিআইগুলো মূলত ব্লুটুথ কার্যক্রম চলাকালীন কার্নেল ওয়েক লক ধরে রাখে, যার জন্য অ্যাপ্লিকেশনটিকে দায়ী করা যায় না।

সুপারিশ

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

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

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

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

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

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

সুপারিশ

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

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

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

অ্যাপে একটি ফায়ারবেস ক্লাউড মেসেজ (FCM) ব্রডকাস্ট ডেলিভার করার সময় একটি ওয়েক লক অর্জিত হয়। FCM ব্রডকাস্টের onMessageReceived() মেথডটির এক্সিকিউশন শেষ হলে ওয়েক লকটি রিলিজ হয়ে যায়।

ওয়েক লক নাম

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

সুপারিশ

এফসিএম-এর আচরণ উন্নত করার জন্য আমরা নিম্নলিখিত পদ্ধতিগুলো সুপারিশ করি:

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

জবশিডিউলার

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

ওয়েক লক নাম

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>
উদাহরণ

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

অবস্থান

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

ওয়েক লক নাম

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

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

সুপারিশ

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

রিমোট মেসেজিং

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

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

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

সুপারিশ

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

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

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

ওয়েক লক নাম

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

উদাহরণ

ধরা যাক, BackupFileWorker নামে একটি এক্সপেডিটেড ওয়ার্কার আছে। এর প্যাকেজ নেম হলো com.example.app ।

অ্যান্ড্রয়েড ১৫ বা তার নিম্নতর সংস্করণে চালিত ডিভাইসগুলিতে, ওয়েক লকটির নাম হবে: 

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

Android 16 QPR2 বা তার চেয়ে উচ্চতর সংস্করণে চালিত এবং WorkManager 2.10.0+ ব্যবহৃত ডিভাইসগুলিতে, ওয়েক লকটির নাম হবে: 

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

সুপারিশ

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

অজানা

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

সুপারিশ

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