ব্যাটারি ও রিসোর্স অপ্টিমাইজেশন
এই পাঠে যা শিখবেন
- একটি সরল "পাওয়ার বাজেট" মডেল কীভাবে বিভিন্ন কাজের খরচকে সংখ্যায়িত করে তুলনাযোগ্য করে তোলে
- একটি বাস্তব ব্যবহার-সিকোয়েন্স থেকে মোট ব্যাটারি খরচ সত্যিকারের গণনা দিয়ে বের করা
- দুটি ভিন্ন GPS-পোলিং নীতির খরচ একই সিকোয়েন্সে তুলনা করে প্রকৃত সাশ্রয়ের পরিমাণ বের করা
- ব্যাটারি সাশ্রয়ের অন্যান্য সাধারণ কৌশল (ব্যাচিং, রিফ্রেশ ইন্টারভাল বাড়ানো, Doze-এর মতো OS পলিসি মেনে চলা)
১ · পাওয়ার বাজেট মডেল কী
একটি মোবাইল ডিভাইসের প্রতিটি হার্ডওয়্যার উপাদান — GPS রিসিভার, স্ক্রিন, নেটওয়ার্ক রেডিও — ভিন্ন পরিমাণ ব্যাটারি খরচ করে। সঠিক মিলিওয়াট-স্তরের হিসাব ছাড়াই, আমরা প্রতিটি কাজকে একটি আপেক্ষিক খরচ ইউনিটRelative Cost Unitপ্রকৃত ওয়াটের বদলে ব্যবহৃত একটি তুলনামূলক সংখ্যা, যা দিয়ে বিভিন্ন কাজের ব্যাটারি-ক্ষুধা একে অপরের সাপেক্ষে তুলনা করা যায়। দিয়ে চিহ্নিত করে একটি ব্যবহারযোগ্য মডেল বানাতে পারি:
সবচেয়ে ব্যয়বহুল — ক্রমাগত অবস্থান খোঁজা রেডিও + প্রসেসর দুটোই ব্যবহার করে।
ডিসপ্লে জ্বালানো একটি স্থির, চলমান খরচ।
সক্রিয় ডেটা আদান-প্রদান রেডিও চালু রাখার খরচ বহন করে।
কিছুই সক্রিয় না থাকলে কোনো অতিরিক্ত খরচ নেই।
২ · একটি বাস্তব ব্যবহার-সিকোয়েন্সে বেসলাইন খরচ হিসাব
নিচে একটি ১২-টিকের ব্যবহার-সিকোয়েন্স দেওয়া আছে — প্রতিটি টিকে স্ক্রিন অন ছিল কি না এবং নেটওয়ার্ক সক্রিয় ছিল কি না তা রেকর্ড করা। প্রথমে GPS বাদ দিয়ে শুধু স্ক্রিন ও নেটওয়ার্কের বেসলাইন খরচ হিসাব করা হচ্ছে।
# প্রতিটি কাজের জন্য আপেক্ষিক ব্যাটারি খরচ ইউনিট (প্রতি টিকে)
COST = {
"gps": 5, # GPS পোলিং
"screen_on": 2, # স্ক্রিন অন থাকা
"network": 3, # নেটওয়ার্ক রেডিও সক্রিয়
"idle": 0, # কিছুই হচ্ছে না
}
# ১২ টিকের একটি বাস্তব ব্যবহার-সিকোয়েন্স
ticks = [
{"screen_on": True, "network_active": True}, # টিক ১: অ্যাপ খুলে সিঙ্ক করা হলো
{"screen_on": True, "network_active": False}, # টিক ২
{"screen_on": True, "network_active": False}, # টিক ৩
{"screen_on": False, "network_active": False}, # টিক ৪: স্ক্রিন লক করা হলো
{"screen_on": False, "network_active": False}, # টিক ৫
{"screen_on": False, "network_active": True}, # টিক ৬: ব্যাকগ্রাউন্ড সিঙ্ক
{"screen_on": False, "network_active": False}, # টিক ৭
{"screen_on": True, "network_active": False}, # টিক ৮: আবার ফোন চেক করা হলো
{"screen_on": True, "network_active": True}, # টিক ৯
{"screen_on": False, "network_active": False}, # টিক ১০
{"screen_on": False, "network_active": False}, # টিক ১১
{"screen_on": True, "network_active": False}, # টিক ১২
]
def baseline_cost(tick):
cost = COST["idle"]
if tick["screen_on"]:
cost += COST["screen_on"]
if tick["network_active"]:
cost += COST["network"]
return cost
total_baseline = 0
for i, tick in enumerate(ticks, start=1):
cost = baseline_cost(tick)
total_baseline += cost
print(f"টিক {i} | screen_on={tick['screen_on']} network_active={tick['network_active']} | GPS ছাড়া খরচ: {cost} ইউনিট")
print(f"\nমোট টিক: {len(ticks)}")
print(f"GPS ছাড়া মোট বেসলাইন খরচ: {total_baseline} ইউনিট")
৩ · দুটি GPS নীতি তুলনা — একই সিকোয়েন্সে
এখন একই ১২-টিক সিকোয়েন্সে দুটি ভিন্ন GPS-পোলিং নীতি প্রয়োগ করে মোট ব্যাটারি খরচ তুলনা করা হচ্ছে — নীতি A: GPS সবসময় চালু থাকে (স্ক্রিন অন থাকুক বা না থাকুক), এবং নীতি B: GPS শুধু তখনই চালু থাকে যখন স্ক্রিন অন থাকে (ধরে নেওয়া হচ্ছে ব্যবহারকারী তখনই সক্রিয়ভাবে অবস্থান দেখছেন)।
# আগের সেলের মতোই COST ও ticks, এবার দুটি ভিন্ন GPS নীতি তুলনা করা হচ্ছে
COST = {"gps": 5, "screen_on": 2, "network": 3, "idle": 0}
ticks = [
{"screen_on": True, "network_active": True},
{"screen_on": True, "network_active": False},
{"screen_on": True, "network_active": False},
{"screen_on": False, "network_active": False},
{"screen_on": False, "network_active": False},
{"screen_on": False, "network_active": True},
{"screen_on": False, "network_active": False},
{"screen_on": True, "network_active": False},
{"screen_on": True, "network_active": True},
{"screen_on": False, "network_active": False},
{"screen_on": False, "network_active": False},
{"screen_on": True, "network_active": False},
]
def baseline_cost(tick):
cost = COST["idle"]
if tick["screen_on"]:
cost += COST["screen_on"]
if tick["network_active"]:
cost += COST["network"]
return cost
def drain_always_on_gps(ticks):
# নীতি A: GPS সবসময় পোল করে, স্ক্রিন অন থাকুক বা না থাকুক
total = 0
for tick in ticks:
total += baseline_cost(tick) + COST["gps"]
return total
def drain_gps_when_screen_on(ticks):
# নীতি B: GPS শুধু তখনই পোল করে যখন স্ক্রিন অন থাকে
total = 0
for tick in ticks:
cost = baseline_cost(tick)
if tick["screen_on"]:
cost += COST["gps"]
total += cost
return total
always_on_total = drain_always_on_gps(ticks)
smart_total = drain_gps_when_screen_on(ticks)
saved_units = always_on_total - smart_total
saved_percent = (saved_units / always_on_total) * 100
print(f"নীতি A (সবসময় GPS পোলিং) -> মোট ব্যাটারি খরচ: {always_on_total} ইউনিট")
print(f"নীতি B (শুধু স্ক্রিন অন থাকলে GPS) -> মোট ব্যাটারি খরচ: {smart_total} ইউনিট")
print(f"\nপার্থক্য: {saved_units} ইউনিট কম খরচ হয় নীতি B-তে ({saved_percent:.2f}% সাশ্রয়)")
একাধিক ছোট রিকোয়েস্টের বদলে একবারে ব্যাচ করে পাঠানো রেডিও বারবার জাগানো এড়ায়।
প্রতি সেকেন্ডের বদলে প্রতি কয়েক সেকেন্ডে GPS/সেন্সর পড়া যথেষ্ট হতে পারে।
Android Doze/App Standby বা iOS-এর ব্যাকগ্রাউন্ড সীমাবদ্ধতার বিরুদ্ধে লড়াই না করে সহযোগিতা করা।
ব্যাটারি অপ্টিমাইজেশন মানে শুধু "কম কাজ করা" নয় — বরং কখন সেই কাজ প্রয়োজন তা যাচাই করা। একটি সরল খরচ-ইউনিট মডেল দিয়ে দুটি নীতির পার্থক্য সংখ্যায় স্পষ্টভাবে দেখা যায় — এখানে GPS-কে স্ক্রিন-অন অবস্থার সাথে শর্তযুক্ত করাই ৩৭% সাশ্রয়ের মূল কারণ, একই কার্যকারিতা বজায় রেখেও।
ভাবনার প্রশ্ন
প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।
প্র ০১ নীতি B বাস্তবে কোন ধরনের অ্যাপের জন্য উপযুক্ত হবে, আর কোন ধরনের অ্যাপের জন্য অনুপযুক্ত?
একটি ম্যাপ/নেভিগেশন অ্যাপ যেখানে ব্যবহারকারী স্ক্রিন দেখেই অবস্থান ট্র্যাক করেন, সেখানে নীতি B যথেষ্ট। কিন্তু একটি ফিটনেস-ট্র্যাকিং অ্যাপ যা ব্যাকগ্রাউন্ডে (স্ক্রিন অফ থাকা অবস্থায়) দৌড়ের পুরো রুট রেকর্ড করতে চায়, সেখানে নীতি B ভুল হবে — GPS বন্ধ থাকলে গুরুত্বপূর্ণ ডেটা হারিয়ে যাবে। নীতি বাছাই নির্ভর করে কোন কাজে GPS আসলে দরকার তার উপর।
প্র ০২
কোড সেলে baseline_cost() ফাংশনটি দুটি ভিন্ন নীতি ফাংশনেই পুনরায় ব্যবহার করা হয়েছে কেন?
কারণ স্ক্রিন ও নেটওয়ার্কের খরচ দুটি নীতিতেই অভিন্ন — শুধু GPS-এর প্রয়োগের শর্তটাই আলাদা। একই
baseline_cost() পুনরায় ব্যবহার করায় নিশ্চিত হয় যে দুই নীতির মধ্যে তুলনাটি ন্যায্য (fair) —
শুধু GPS-নীতির পার্থক্যটাই সংখ্যায় প্রতিফলিত হয়, অন্য কোনো ভুল/অসামঞ্জস্য নয়।
প্র ০৩ যদি GPS-এর খরচ ৫-এর বদলে ১০ ইউনিট হতো, তাহলে দুই নীতির মধ্যে শতাংশ পার্থক্য কি বাড়তো না কমতো?
বাড়তো। GPS যত বেশি ব্যয়বহুল, "সবসময় চালু" রাখা বনাম "শর্তসাপেক্ষে চালু" রাখার মধ্যে পার্থক্য তত বড় হবে — কারণ নীতি A-তে GPS ১২ বার যোগ হয় কিন্তু নীতি B-তে মাত্র ৬ বার, আর সেই "অতিরিক্ত ৬ বার"-এর প্রতিটির মূল্য GPS-এর ইউনিট-খরচের সমান। GPS যত ব্যয়বহুল, অপ্রয়োজনীয় পোলিং এড়ানোর সাশ্রয়ও তত বেশি।
অনুশীলন
-
চিন্তা করুন: আপনার ফোনের কোন অ্যাপ সবচেয়ে বেশি ব্যাটারি খরচ করে বলে আপনার মনে হয়, এবং কেন
— এটি কি GPS, স্ক্রিন, নাকি নেটওয়ার্কের কারণে হতে পারে?
সাধারণত নেভিগেশন অ্যাপ (ক্রমাগত GPS + স্ক্রিন অন), ভিডিও স্ট্রিমিং (স্ক্রিন + নেটওয়ার্ক), বা সোশ্যাল মিডিয়া (ঘন ঘন ব্যাকগ্রাউন্ড রিফ্রেশ + নেটওয়ার্ক) — এই তিন ধরনের অ্যাপ সাধারণত ব্যাটারি সেটিংসে শীর্ষে থাকে, কারণ এগুলো এই পাঠের মডেলের সবচেয়ে ব্যয়বহুল উপাদানগুলো দীর্ঘ সময় ধরে ব্যবহার করে।
-
পরীক্ষা করুন: দ্বিতীয় কোড সেলে
COST["gps"]-এর মান ৫ থেকে ২ করুন (একটি কম নির্ভুল, কম ব্যয়বহুল GPS মোড কল্পনা করুন), তারপর চালিয়ে দেখুনsaved_unitsওsaved_percentকীভাবে বদলায়।নীতি A-এর নতুন মোট: $21 + (12 \times 2) = 45$ ইউনিট। নীতি B-এর নতুন মোট: $21 + (6 \times 2) = 33$ ইউনিট।
saved_unitsহবে $45 - 33 = 12$ ইউনিট, আরsaved_percentহবে $12/45 \times 100 \approx 26.67\%$ — অর্থাৎ GPS সস্তা হলে দুই নীতির মধ্যে শতাংশ পার্থক্য কমে যায় (আগে ছিল প্রায় ৩৭%), কারণ GPS-নির্ভর অংশটাই এখন মোট খরচের একটি ছোট অংশ।
আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ
- কোর্সের সম্পূর্ণ সিলেবাস দেখুন ৫৭টি পাঠ অ্যাপ লাইফসাইকেল, মোবাইল UI/UX, MVVM/MVI আর্কিটেকচার, নেভিগেশন, স্টেট ম্যানেজমেন্ট, লোকাল স্টোরেজ, নেটওয়ার্কিং, ডিভাইস ফিচার, পারফরম্যান্স ও ডিপ্লয়মেন্ট — সব একসাথে।
- পরের পাঠ: অ্যাপ সাইজ ও স্টার্টআপ টাইম অপ্টিমাইজেশন L49 কোল্ড স্টার্ট বনাম ওয়ার্ম স্টার্ট — কেন প্রথমবার অ্যাপ চালু হতে বেশি সময় লাগে, বাস্তব গণনাসহ।
- সব Courses দেখুন ABCL TECH C, C++, Python, Java, JavaScript, DSA, DBMS, Discrete Mathematics, System Design, Cybersecurity, Cloud Computing & DevOps, Computer Networks, Operating Systems, Computer Architecture, Programming Languages & Compiler Design, Software Engineering & Git, Theory of Computation, Engineering Economics, Full-Stack Web Frameworks ও Mobile App Development — সব এক জায়গায়।