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

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

১ মার্চ, ২০২৬ থেকে, যে অ্যাপগুলো নির্ধারিত মান পূরণ করতে ব্যর্থ হবে, সেগুলোকে গুগল প্লে-তে খুঁজে পাওয়ার তালিকা থেকে বাদ দেওয়া হতে পারে। এছাড়াও, গুগল প্লে স্টোরের তালিকায় একটি সতর্কবার্তা যুক্ত করা হতে পারে, যা থেকে বোঝা যাবে যে অ্যাপটি প্রত্যাশার চেয়ে বেশি ব্যাটারি ব্যবহার করতে পারে।

WHOOP-এর সিনিয়র অ্যান্ড্রয়েড ইঞ্জিনিয়ার মায়াঙ্ক সাইনির মতে, অ্যান্ড্রয়েড ভাইটালস অ্যাপটির অতিরিক্ত পার্শিয়াল ওয়েক লক % ১৫% হিসেবে চিহ্নিত করার পর—যা প্রস্তাবিত ৫% সীমা অতিক্রম করেছিল—এটি “টিমকে অ্যান্ড্রয়েডের কার্যকারিতার মান উন্নত করার একটি সুযোগ এনে দেয়।”

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

সমস্যাটি চিহ্নিত করা

কোথা থেকে শুরু করতে হবে তা বোঝার জন্য, কোন ওয়েক লকগুলো এই মেট্রিককে প্রভাবিত করছে সে সম্পর্কে আরও অন্তর্দৃষ্টি পেতে দলটি প্রথমে অ্যান্ড্রয়েড ভাইটালস-এর সাহায্য নেয়। অ্যান্ড্রয়েড ভাইটালস-এর অতিরিক্ত আংশিক ওয়েক লক ড্যাশবোর্ডটি দেখে, তারা অতিরিক্ত আংশিক ওয়েক লকের সবচেয়ে বড় কারণ হিসেবে তাদের একটি ওয়ার্কম্যানেজার ওয়ার্কারকে (ড্যাশবোর্ডে যা androidx.work.impl.background.systemjob.SystemJobService হিসেবে চিহ্নিত) শনাক্ত করতে সক্ষম হয়। WHOOP-এর “অলওয়েজ-অন এক্সপেরিয়েন্স” সমর্থন করার জন্য, অ্যাপটি পর্যায়ক্রমিক সিঙ্কিং এবং পরিধানযোগ্য ডিভাইসটিতে নিয়মিত আপডেট পাঠানোর মতো ব্যাকগ্রাউন্ড টাস্কের জন্য ওয়ার্কম্যানেজার ব্যবহার করে।

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

ড্যাশবোর্ডে WorkManager-কে প্রধান অবদানকারী হিসেবে চিহ্নিত করার পর, দলটি তাদের কর্মীদের মধ্যে কে সবচেয়ে বেশি অবদান রাখছে তা শনাক্ত করার দিকে মনোযোগ দিতে এবং সমস্যাটি সমাধানের জন্য কাজ করতে সক্ষম হয়েছিল।

কারণটি আরও ভালোভাবে চিহ্নিত করার জন্য অভ্যন্তরীণ মেট্রিক ও ডেটা ব্যবহার করা।

WHOOP-এর WorkManager মেট্রিক্স নিরীক্ষণের জন্য আগে থেকেই অভ্যন্তরীণ পরিকাঠামো তৈরি ছিল। তারা পর্যায়ক্রমে নিরীক্ষণ করে:

1. গড় রানটাইম: ওয়ার্কারটি কতক্ষণ ধরে চলে?
2. টাইমআউট: কর্মীটি কাজ শেষ করার পরিবর্তে কত ঘন ঘন টাইমআউট হয়ে যাচ্ছে?
3. পুনরায় চেষ্টা: কাজটি টাইম আউট হয়ে গেলে বা ব্যর্থ হলে কর্মীটি কতবার পুনরায় চেষ্টা করে?
4. বাতিলকরণ: কাজটি কতবার বাতিল করা হয়েছিল?

শুধু কর্মীদের সাফল্য ও ব্যর্থতার হিসাব রাখার বাইরেও আরও অনেক কিছু নজরে রাখলে দলটি তাদের কাজের দক্ষতা সম্পর্কে স্বচ্ছ ধারণা পায়।

অভ্যন্তরীণ মেট্রিক্স কয়েকটি নির্দিষ্ট ওয়ার্কারের উচ্চ গড় রানটাইম চিহ্নিত করে, যা তাদের তদন্তকে আরও সংকুচিত করতে সক্ষম করে।

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

অনুসন্ধান: কর্মী প্রকারভেদের মধ্যে পার্থক্য নিরূপণ

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

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

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

WHOOP-এর অ্যান্ড্রয়েড ইঞ্জিনিয়ার II, মনমীত তুতেজা বলেছেন, “এই বিভাজনটি আমাদের এটি নিশ্চিত করতেও সাহায্য করেছে যে সমস্যাটি উভয় ভ্যারিয়েন্টেই ঘটছিল, যা শিডিউলিং কনফিগারেশনের পরিবর্তে ওয়ার্কার ইমপ্লিমেন্টেশনের অভ্যন্তরে একটি শেয়ার্ড বিজনেস লজিক সমস্যার দিকে ইঙ্গিত করে।”

শ্রমিকদের আচরণ গভীরভাবে খতিয়ে দেখা এবং মূল কারণের সমাধান করা

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

এই সবকিছুর ফলস্বরূপ অতিরিক্ত ওয়েক লকের মূল কারণটি খুঁজে পাওয়া গেল:

একটি CoroutineWorker, যা কাজ শুরু করার আগে WHOOP সেন্সরের সাথে সংযোগের জন্য অপেক্ষা করার জন্য ডিজাইন করা হয়েছিল।

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

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

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

class SensorWorker(appContext: Context, params: WorkerParameters): CoroutineWorker(appContext, params) {
   override suspend fun doWork(): Result {
      ...
      // Check the sensor state and perform work or return failure
       return whoopSensorFlow.replayCache
            .firstOrNull()
            ?.let { cachedData ->
                processSensorData(cachedData)
                Result.success()
            } ?: run {
                Result.failure()
            }
}

অতিরিক্ত আংশিক ওয়েক লক সহ সেশন ৯০% হ্রাস অর্জন করা

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

অবশেষে, মাত্র ৩০ দিনের মধ্যে WHOOP-এর অতিরিক্ত আংশিক ওয়েক লক শতাংশ ১৫% থেকে কমে ১%-এরও নিচে নেমে আসে।   তাদের কর্মীর উপর পরিবর্তনগুলো প্রয়োগ করার পর।

এই পরিবর্তনগুলোর ফলে, কাজ অসম্পূর্ণ থেকে সময়সীমা অতিক্রম করার ঘটনা কমে গেছে, যার ফলস্বরূপ গড় কার্যকালও হ্রাস পেয়েছে।

যেসব ডেভেলপার তাদের ব্যাকগ্রাউন্ড কাজের দক্ষতা বাড়াতে চান, তাদের জন্য WHOOP টিমের পরামর্শ:

শুরু করুন

আপনি যদি আপনার অ্যাপের অতিরিক্ত পার্শিয়াল ওয়েক লক কমাতে বা ওয়ার্কারের কর্মদক্ষতা বাড়াতে আগ্রহী হন, তাহলে Android vitals- এ আপনার অ্যাপের অতিরিক্ত পার্শিয়াল ওয়েক লক মেট্রিকটি দেখুন এবং আরও সেরা অনুশীলন ও ডিবাগিং কৌশলের জন্য ওয়েক লক ডকুমেন্টেশন পর্যালোচনা করুন।