নেটওয়ার্ক অ্যাক্সেস অপ্টিমাইজ করুন

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

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

রেডিও স্টেট মেশিন

আপনার ব্যবহারকারীর ডিভাইসের ওয়্যারলেস রেডিওতে অন্তর্নির্মিত শক্তি-সাশ্রয়ী বৈশিষ্ট্য রয়েছে, যা এর ব্যাটারি শক্তি খরচ কমাতে সাহায্য করে। সম্পূর্ণ সক্রিয় অবস্থায় ওয়্যারলেস রেডিওটি উল্লেখযোগ্য পরিমাণে শক্তি খরচ করে, কিন্তু নিষ্ক্রিয় বা স্ট্যান্ডবাই মোডে থাকলে এটি খুব কম শক্তি খরচ করে।

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

একটি সাধারণ 3G নেটওয়ার্ক রেডিওর স্টেট মেশিনে তিনটি শক্তি অবস্থা থাকে:

• পূর্ণ শক্তি : সংযোগ সক্রিয় থাকাকালীন এটি ব্যবহৃত হয়, যা ডিভাইসটিকে তার সর্বোচ্চ সম্ভাব্য হারে ডেটা স্থানান্তর করতে সক্ষম করে।
• স্বল্প শক্তি : একটি অন্তর্বর্তী অবস্থা যা ব্যাটারির শক্তি খরচ প্রায় ৫০% কমিয়ে দেয়।
• স্ট্যান্ডবাই : সর্বনিম্ন শক্তি-খরচের এমন একটি অবস্থা, যে সময়ে কোনো নেটওয়ার্ক সংযোগ সক্রিয় থাকে না।

যদিও লো এবং স্ট্যান্ডবাই অবস্থায় ব্যাটারি অনেক কম খরচ হয়, তবে এই অবস্থাগুলো নেটওয়ার্ক অনুরোধে উল্লেখযোগ্য বিলম্ব ঘটায়। লো অবস্থা থেকে সম্পূর্ণ চার্জে ফিরতে প্রায় ১.৫ সেকেন্ড সময় লাগে এবং স্ট্যান্ডবাই থেকে সম্পূর্ণ চার্জে যেতে ২ সেকেন্ডের বেশি সময় লাগতে পারে।

লেটেন্সি কমানোর জন্য, স্টেট মেশিন নিম্ন শক্তি স্তরে রূপান্তরকে বিলম্বিত করতে একটি ডিলে ব্যবহার করে। চিত্র ১-এ একটি সাধারণ ৩জি রেডিওর জন্য AT&T-এর টাইমিং ব্যবহার করা হয়েছে।

চিত্র ১. একটি সাধারণ ৩জি ওয়্যারলেস রেডিও স্টেট মেশিন।

প্রতিটি ডিভাইসের রেডিও স্টেট মেশিন, বিশেষ করে এর সাথে সম্পর্কিত ট্রানজিশন ডিলে ("টেইল টাইম") এবং স্টার্টআপ ল্যাটেন্সি, ব্যবহৃত ওয়্যারলেস রেডিও প্রযুক্তির (যেমন 3G, LTE, 5G ইত্যাদি) উপর ভিত্তি করে পরিবর্তিত হয় এবং ডিভাইসটি যে ক্যারিয়ার নেটওয়ার্কের মাধ্যমে পরিচালিত হচ্ছে, সেই নেটওয়ার্ক দ্বারা এটি সংজ্ঞায়িত ও কনফিগার করা হয়।

এই পৃষ্ঠায় AT&T কর্তৃক প্রদত্ত তথ্যের উপর ভিত্তি করে একটি সাধারণ 3G ওয়্যারলেস রেডিওর প্রতিনিধিত্বমূলক স্টেট মেশিনের বর্ণনা দেওয়া হয়েছে। তবে, এর সাধারণ নীতি এবং ফলস্বরূপ প্রাপ্ত সর্বোত্তম অনুশীলনসমূহ সকল ওয়্যারলেস রেডিও বাস্তবায়নের ক্ষেত্রেই প্রযোজ্য।

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

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

অ্যাপগুলি কীভাবে রেডিও স্টেট মেশিনকে প্রভাবিত করে

প্রতিবার যখন আপনি একটি নতুন নেটওয়ার্ক সংযোগ তৈরি করেন, তখন রেডিওটি সম্পূর্ণ শক্তি অবস্থায় চলে যায়। পূর্বে বর্ণিত সাধারণ 3G রেডিও স্টেট মেশিনের ক্ষেত্রে, এটি আপনার ডেটা ট্রান্সফারের পুরো সময়—এবং তার সাথে অতিরিক্ত ৫ সেকেন্ড টেইল টাইম—সম্পূর্ণ শক্তিতে থাকবে, এবং এরপর ১২ সেকেন্ডের জন্য কম শক্তি অবস্থায় থাকবে। সুতরাং একটি সাধারণ 3G ডিভাইসের জন্য, প্রতিটি ডেটা ট্রান্সফার সেশনের কারণে রেডিওটি কমপক্ষে ১৮ সেকেন্ডের জন্য শক্তি খরচ করবে।

কার্যত এর অর্থ হলো, যে অ্যাপটি প্রতি মিনিটে তিনবার এক সেকেন্ডের ডেটা স্থানান্তর করে, সেটি ওয়্যারলেস রেডিওটিকে ক্রমাগত সক্রিয় রাখবে এবং স্ট্যান্ডবাই মোডে যাওয়ার ঠিক মুহূর্তে এটিকে আবার উচ্চ শক্তিতে ফিরিয়ে নিয়ে যাবে।

চিত্র ২। প্রতি মিনিটে তিনবার চালিত এক-সেকেন্ডের স্থানান্তরের জন্য আপেক্ষিক ওয়্যারলেস রেডিও শক্তি ব্যবহার। চিত্রটিতে দুটি চালনার মধ্যবর্তী "পাওয়ার আপ" বিলম্ব অন্তর্ভুক্ত নয়।

তুলনামূলকভাবে, যদি একই অ্যাপ তার ডেটা ট্রান্সফারগুলোকে একত্রিত করে প্রতি মিনিটে একটি তিন-সেকেন্ডের ট্রান্সফার চালাত, তাহলে রেডিওটি প্রতি মিনিটে মোট মাত্র ২০ সেকেন্ডের জন্য হাই-পাওয়ার স্টেটে থাকত। এর ফলে রেডিওটি প্রতি মিনিটে ৪০ সেকেন্ডের জন্য স্ট্যান্ডবাইতে থাকতে পারত, যার পরিণামে ব্যাটারির ব্যবহার উল্লেখযোগ্যভাবে কমে যেত।

চিত্র ৩। প্রতি মিনিটে একবার চালিত তিন সেকেন্ডের ট্রান্সফারের জন্য আপেক্ষিক ওয়্যারলেস রেডিও পাওয়ার ব্যবহার।

অপ্টিমাইজেশন কৌশল

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

বান্ডেল ডেটা স্থানান্তর

পূর্ববর্তী বিভাগে যেমন বলা হয়েছে, ডেটা ট্রান্সফারগুলোকে একত্রিত করে কম সময়ে বেশি ডেটা স্থানান্তর করা ব্যাটারির কার্যকারিতা উন্নত করার অন্যতম সেরা উপায়।

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

ডেটা প্রিফেচ করুন

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

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

কোনো কাজ করার আগে বা ডেটা দেখার আগে ডাউনলোড সম্পূর্ণ হওয়ার জন্য অপেক্ষা করার কারণে অ্যাপের মধ্যে যে বিলম্ব হয়, তা কমিয়ে প্রিফেচিং ব্যবহারকারীর অভিজ্ঞতাও উন্নত করে।

এখানে একটি বাস্তব উদাহরণ দেওয়া হলো।

একজন সংবাদ পাঠক

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

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

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

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

অতিরিক্ত বিবেচ্য বিষয়

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

আপনি কতটা জোরালোভাবে ডেটা প্রিফেচ করবেন তা নির্ভর করে ডাউনলোড করা ডেটার আকার এবং এটি ব্যবহৃত হওয়ার সম্ভাবনার উপর। পূর্বে বর্ণিত স্টেট মেশিনের উপর ভিত্তি করে একটি মোটামুটি নির্দেশিকা হিসাবে বলা যায়, যে ডেটার বর্তমান ইউজার সেশনে ব্যবহৃত হওয়ার ৫০% সম্ভাবনা থাকে, সেটির ক্ষেত্রে আপনি সাধারণত প্রায় ৬ সেকেন্ড (আনুমানিক ১-২ মেগাবাইট) পর্যন্ত প্রিফেচ করতে পারেন। এর পরেই অব্যবহৃত ডেটা ডাউনলোড করার সম্ভাব্য খরচ, শুরুতেই সেই ডেটা ডাউনলোড না করার সম্ভাব্য সাশ্রয়ের সমান হয়ে যায়।

সাধারণভাবে বলতে গেলে, ডেটা আগে থেকে এমনভাবে সংগ্রহ করে রাখা ভালো, যাতে আপনাকে প্রতি ২ থেকে ৫ মিনিট পর পর মাত্র ১ থেকে ৫ মেগাবাইটের আরেকটি ডাউনলোড শুরু করতে হয়।

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

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

অনুরোধ করার আগে সংযোগ পরীক্ষা করে নিন।

মোবাইল ডিভাইসে সেল সিগন্যাল খোঁজা সবচেয়ে বেশি শক্তি খরচকারী কাজগুলোর মধ্যে একটি। ব্যবহারকারীর পাঠানো অনুরোধের জন্য একটি উত্তম পদ্ধতি হলো, প্রথমে ConnectivityManager ব্যবহার করে সংযোগ আছে কিনা তা পরীক্ষা করা, যেমনটি 'কানেক্টিভিটি স্ট্যাটাস মনিটর করুন এবং সংযোগ মিটারিং ' (Monitor connectivity status and connection metering) অংশে দেখানো হয়েছে। যদি কোনো নেটওয়ার্ক না থাকে, তাহলে অ্যাপটি মোবাইল রেডিওকে অনুসন্ধানে বাধ্য না করে ব্যাটারি বাঁচাতে পারে। এরপর, সংযোগ স্থাপিত হলে অনুরোধটিকে শিডিউল করে অন্যান্য অনুরোধের সাথে একসাথে সম্পাদন করা যেতে পারে।

পুল সংযোগ

ব্যাচিং এবং প্রিফেচিংয়ের পাশাপাশি সহায়ক একটি অতিরিক্ত কৌশল হলো আপনার অ্যাপের নেটওয়ার্ক সংযোগগুলোকে পুল করা।

নতুন সংযোগ তৈরি করার চেয়ে বিদ্যমান নেটওয়ার্ক সংযোগগুলো পুনরায় ব্যবহার করা সাধারণত বেশি কার্যকর। সংযোগ পুনরায় ব্যবহার করার ফলে নেটওয়ার্কটি যানজট এবং সংশ্লিষ্ট ডেটা সমস্যাগুলোর প্রতি আরও বুদ্ধিমত্তার সাথে প্রতিক্রিয়া জানাতে পারে।

HttpURLConnection এবং OkHttp-এর মতো বেশিরভাগ HTTP ক্লায়েন্ট ডিফল্টরূপে কানেকশন-পুলিং সক্রিয় করে, যার ফলে একাধিক অনুরোধের জন্য একই কানেকশন পুনরায় ব্যবহার করা যায়।

পুনরালোচনা এবং ভবিষ্যৎ পরিকল্পনা

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

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