অ্যাপ ক্র্যাশ হওয়া আটকানো এবং সিস্টেমের স্থিতিশীলতা ও প্ল্যাটফর্মের স্বাস্থ্য বজায় রাখার জন্য মেমরি অপ্টিমাইজেশন খুবই গুরুত্বপূর্ণ। মেমরি ব্যবহার প্রতিটি অ্যাপে মনিটর ও অপ্টিমাইজ করা উচিত, তবে টিভির জন্য কন্টেন্ট অ্যাপ ডিভাইসে নির্দিষ্ট চ্যালেঞ্জ থাকে যা হ্যান্ডহেল্ড ডিভাইসের সাধারণ Android অ্যাপের থেকে আলাদা।
মেমরির ব্যবহার বেশি হলে অ্যাপ ও সিস্টেমের আচরণে সমস্যা হতে পারে এর মধ্যে এগুলি অন্তর্ভুক্ত:
- অ্যাপটি ধীরে চলতে পারে বা ল্যাগ করতে পারে অথবা সবচেয়ে খারাপ ক্ষেত্রে, বন্ধ হয়ে যেতে পারে।
- ব্যবহারকারীর কাছে দৃশ্যমান সিস্টেম পরিষেবা (ভলিউম কন্ট্রোল, ছবি সেটিংস ড্যাশবোর্ড, ভয়েস অ্যাসিস্ট্যান্ট ইত্যাদি) খুব ধীরে কাজ করে বা একেবারেই কাজ নাও করতে পারে।
- লো মেমরি কিলার (LMK) ডেমোন প্রসেস, বেশি মেমরি প্রেসার হলে সবচেয়ে কম প্রয়োজনীয় প্রসেস বন্ধ করে দিতে পারে; তারপরে এইসব কম্পোনেন্ট শীঘ্রই আবার চালু হতে পারে, এর ফলে আরও বেশি রিসোর্স কনটেনশন ট্রিগার হতে পারে যা সরাসরি ফোরগ্রাউন্ড অ্যাপকে প্রভাবিত করতে পারে।
- লঞ্চারে ট্রানজিশন হতে অনেক দেরি হতে পারে এবং ট্রানজিশন শেষ না হওয়া পর্যন্ত ফোরগ্রাউন্ড অ্যাপটি অনুপযুক্ত হিসেবে দেখা যেতে পারে।
- সিস্টেম সরাসরি রিক্লেইম ব্যবহার করা শুরু করতে পারে, মেমরি অ্যালোকেশনের জন্য অপেক্ষা করার সময় সাময়িকভাবে থ্রেডের এক্সিকিউশন পজ করে। এটি যেকোনও থ্রেডের ক্ষেত্রে হতে পারে, যেমন মূল থ্রেড বা কোডেক-সম্পর্কিত থ্রেড, সম্ভাব্য অডিও ও ভিডিও ফ্রেম ড্রপ এবং UI গ্লিচ।
টিভি ডিভাইসে মেমরি সংক্রান্ত বিষয়
টিভি ডিভাইসে সাধারণত ফোন বা ট্যাবলেটের তুলনায় অনেক কম মেমরি থাকে। যেমন, টিভিতে আমরা যে কনফিগারেশন দেখতে পাই তা হল ১ জিবি RAM এবং 1080p ভিডিও রেজোলিউশন। একই সাথে, বেশিরভাগ টিভি অ্যাপে একই ধরনের ফিচার থাকে; তাই একই ধরনের প্রয়োগ ও সাধারণ চ্যালেঞ্জ। এই দুটি পরিস্থিতিতে এমন সমস্যা দেখা যায় যা অন্যান্য ডিভাইসের ধরন ও অ্যাপে দেখা যায় না:
- সাধারণত, মিডিয়া টিভি অ্যাপে গ্রিড ভিউতে ছবি ও ফুলস্ক্রিন ব্যাকগ্রাউন্ড ছবি থাকে, যার জন্য অল্প সময়ের মধ্যে মেমরিতে অনেক ছবি লোড করতে হয়
- টিভি অ্যাপ মাল্টিমিডিয়া স্ট্রিম চালায় যার জন্য ভিডিও ও অডিও চালানোর জন্য নির্দিষ্ট পরিমাণ মেমরি বরাদ্দ করতে হয় এবং মসৃণ প্লেব্যাক নিশ্চিত করতে যথেষ্ট মিডিয়া বাফার প্রয়োজন হয়।
- অতিরিক্ত মিডিয়া ফিচার (খোঁজা, এপিসোড পরিবর্তন, অডিও ট্র্যাক পরিবর্তন, ইত্যাদি) সঠিকভাবে প্রয়োগ করা না হলে অতিরিক্ত মেমরি প্রেসার নিতে পারে।
টিভি ডিভাইস সম্পর্কে বোঝা
এই নির্দেশিকায় প্রধানত কম RAM থাকা ডিভাইসে অ্যাপের মেমরি ব্যবহার ও মেমরি টার্গেট সম্পর্কে আলোচনা করা হয়েছে।
টিভি ডিভাইসে, এইসব বৈশিষ্ট্য বিবেচনা করুন:
- ডিভাইস মেমরি: ডিভাইসে ইনস্টল করা র্যান্ডম অ্যাক্সেস মেমরি (RAM)-এর পরিমাণ।
- ডিভাইস UI রেজোলিউশন: OS এবং অ্যাপ্লিকেশন UI রেন্ডার করার জন্য ডিভাইস যে রেজোলিউশন ব্যবহার করে; এটি সাধারণত ডিভাইস ভিডিও রেজোলিউশনের চেয়ে কম হয়।
- ভিডিও রেজোলিউশন: ডিভাইসে ভিডিও চালানোর জন্য সর্বাধিক রেজোলিউশন।
এর ফলে বিভিন্ন ধরনের ডিভাইসকে আলাদা আলাদাভাবে শ্রেণীবদ্ধ করা হয় এবং সেগুলিতে কীভাবে মেমরি ব্যবহার করা উচিত তা নির্ধারণ করা হয়।
টিভি ডিভাইসের সারসংক্ষেপ
| ডিভাইস মেমরি | ডিভাইস ভিডিও রেজোলিউশন | ডিভাইস UI রেজোলিউশন | isLowRamDevice() |
|---|---|---|---|
| ১ জিবি | 1080p | 720p | হ্যাঁ |
| ১.৫ জিবি | ২১৬০p | 1080p | হ্যাঁ |
| ≥১.৫ জিবি | 1080p | 720p বা 1080p | না* |
| ≥২ জিবি | ২১৬০p | 1080p | না* |
কম র্যামের টিভি ডিভাইস
এইসব ডিভাইস মেমরি সংক্রান্ত সমস্যায় আছে এবং
ActivityManager.isLowRamDevice()
সত্য হিসেবে রিপোর্ট করবে। কম RAM আছে এমন টিভি ডিভাইসে যেসব অ্যাপ্লিকেশন চলছে সেগুলিকে
অতিরিক্ত মেমরি কন্ট্রোল ব্যবস্থা প্রয়োগ করতে হবে।
আমরা নিম্নলিখিত বৈশিষ্ট্যযুক্ত ডিভাইসগুলিকে এই বিভাগে অন্তর্ভুক্ত করি:
- ১ জিবি ডিভাইস: ১ জিবি RAM, ৭২০p/HD (১২৮০x৭২০) UI রেজোলিউশন, ১০৮০p/FullHD (১৯২০x১০৮০) ভিডিও রেজোলিউশন
- ১.৫ জিবি ডিভাইস: ১.৫ জিবি RAM, ১০৮০p/FullHD (১৯২০x১০৮০) UI রেজোলিউশন, ২১৬০p/UltraHD/4K (৩৮৪০x২১৬০) ভিডিও রেজোলিউশন
- অন্যান্য পরিস্থিতি যেখানে অতিরিক্ত মেমরি সংক্রান্ত সীমাবদ্ধতার কারণে OEM
ActivityManager.isLowRamDevice()ফ্ল্যাগটি নির্ধারণ করেছে।
সাধারণ টিভি ডিভাইস
এইসব ডিভাইসে মেমরি সংক্রান্ত সমস্যা হয় না। আমরা এইসব ডিভাইসের নিম্নলিখিত বৈশিষ্ট্য আছে বলে মনে করি:
- ≥১.৫ জিবি RAM, 720p বা 1080p UI এবং 1080p ভিডিও রেজোলিউশন
- ≥২ জিবি RAM, 1080p UI এবং 1080p বা 2160p ভিডিও রেজোলিউশন
এর অর্থ এই নয় যে অ্যাপগুলিকে এইসব ডিভাইসে মেমরি ব্যবহার সম্পর্কে চিন্তা করতে হবে না, কারণ কিছু নির্দিষ্ট মেমরি অপব্যবহার এখনও উপলভ্য মেমরি শেষ করে দিতে পারে এবং খারাপ পারফর্ম করতে পারে।
কম র্যাম থাকা টিভি ডিভাইসে মেমরি টার্গেট
এইসব ডিভাইসে মেমরি পরিমাপ করার সময়, আমরা Android Studio মেমরি প্রোফাইলার ব্যবহার করে মেমরির প্রতিটি বিভাগ মনিটর করার জন্য জোরালোভাবে সাজেস্ট করি। TV অ্যাপগুলিকে তাদের মেমরি ব্যবহার প্রোফাইল করতে হবে এবং এই বিভাগে আমাদের সংজ্ঞায়িত থ্রেশহোল্ডের নিচে তাদের বিভাগগুলি রাখার জন্য কাজ করতে হবে।

মেমরি কীভাবে গণনা করা হয় বিভাগে আপনি রিপোর্ট করা মেমরি সংক্রান্ত সংখ্যার বিস্তারিত ব্যাখ্যা পাবেন। টিভিতে অ্যাপের থ্রেশহোল্ডের সংজ্ঞা অনুসারে, আমরা তিনটি মেমরি বিভাগে ফোকাস করব:
- অপরিচিত + অদলবদল: Android Studio-তে Java + Native + Stack allocation memory দিয়ে তৈরি।
- গ্রাফিক্স: প্রোফাইলার টুলে সরাসরি অভিযোগ জানানো হয়েছে। সাধারণত এগুলি গ্রাফিক্স টেক্সচার দিয়ে তৈরি।
- ফাইল: Android Studio-তে "কোড" + "অন্যান্য" বিভাগ হিসেবে রিপোর্ট করা হয়েছে।
এইসব সংজ্ঞা অনুযায়ী, নিম্নলিখিত সারণী থেকে জানা যায় যে প্রতিটি মেমরি গ্রুপের সর্বাধিক কত ভ্যালু ব্যবহার করা উচিত:
| মেমরির ধরন | উদ্দেশ্য | ব্যবহারের টার্গেট (১ জিবি) |
|---|---|---|
| অনামেয়াস + অদলবদল (Java + Native + Stack) | অ্যালোকেশন, মিডিয়া বাফার, ভেরিয়েবল ও অন্যান্য মেমরি-ইনটেনসিভ টাস্কের জন্য ব্যবহার করা হয়। | < ১৬০ এমবি |
| গ্রাফিক্স | টেক্সচার ও ডিসপ্লে সম্পর্কিত বাফার জন্য GPU ব্যবহার করে | ৩০-৪০ এমবি |
| ফাইল | মেমরিতে কোড পৃষ্ঠা ও ফাইলের জন্য ব্যবহার করা হয়। | ৬০-৮০ এমবি |
সর্বাধিক মোট মেমরি (Anon+Swap + Graphics + File) অবশ্যই নিম্নলিখিত সীমা অতিক্রম করা চলবে না:
- ১ জিবি কম র্যাম ডিভাইসের জন্য মোট মেমরি ব্যবহারের ২৮০ এমবি (অ্যানন+সোয়াপ + গ্রাফিক্স + ফাইল)।
এগুলি অতিক্রম না করার জন্য জোরালোভাবে সাজেস্ট করা হয়:
- (Anon+Swap + Graphics)-এ ২০০ এমবি মেমরি ব্যবহার করা হয়েছে।
ফাইল মেমরি
ফাইল ব্যাকড মেমরি সংক্রান্ত সাধারণ নির্দেশিকা হিসেবে মনে রাখবেন যে:
- সাধারণত, OS মেমরি ম্যানেজমেন্টের মাধ্যমে ফাইল মেমরি ভালোভাবে ম্যানেজ করা হয়।
- আমরা এই মুহূর্তে এটিকে মেমরি প্রেসারের প্রধান কারণ হিসেবে খুঁজে পাইনি।
তবে, সাধারণভাবে ফাইল মেমরি ম্যানেজ করার সময়:
- আপনার বিল্ডে অব্যবহৃত লাইব্রেরি অন্তর্ভুক্ত করবেন না এবং সম্ভব হলে সম্পূর্ণ লাইব্রেরির পরিবর্তে লাইব্রেরির ছোট সাবসেট ব্যবহার করুন।
- মেমরিতে বড় ফাইল খোলা রাখবেন না এবং আপনার কাজ হয়ে গেলে সেগুলি বন্ধ করে দিন।
- Java ও Kotlin ক্লাসের জন্য আপনার কম্পাইল করা কোডের সাইজ ছোট করুন, এর জন্য আপনার অ্যাপ ছোট, অস্পষ্ট ও অপ্টিমাইজ করুন গাইড দেখুন।
নির্দিষ্ট টিভি সংক্রান্ত সাজেশন
এই বিভাগে, TV ডিভাইসে মেমরি ব্যবহার অপ্টিমাইজ করার জন্য নির্দিষ্ট সাজেশন দেওয়া হয়েছে।
গ্রাফিক্স মেমরি
উপযুক্ত ছবি ফর্ম্যাট ও রেজোলিউশন ব্যবহার করুন।
- ডিভাইসের UI রেজোলিউশনের চেয়ে বেশি রেজোলিউশনের ছবি লোড করবেন না। যেমন, 720p UI ডিভাইসে 1080p ছবিকে 720p-তে ছোট করে নিতে হবে।
- সম্ভব হলে হার্ডওয়্যার-ব্যাকড বিটম্যাপ ব্যবহার করুন।
- Glide-এর মতো লাইব্রেরিতে, ডিফল্ট হিসেবে বন্ধ থাকা
Downsampler.ALLOW_HARDWARE_CONFIGফিচার চালু করুন। এটি চালু করলে, বিটম্যাপের ডুপ্লিকেট কপি তৈরি হওয়া এড়ানো যায়। অন্যথায়, বিটম্যাপের কপি গ্রাফিক্স মেমরি ও অ্যানোনিমাস মেমরি, দু'টিতেই থাকত।
- Glide-এর মতো লাইব্রেরিতে, ডিফল্ট হিসেবে বন্ধ থাকা
- ইন্টারমিডিয়েট রেন্ডার এড়িয়ে চলুন এবং আবার রেন্ডার করুন
- এগুলি Android GPU Inspector-এর সাহায্যে শনাক্ত করা যেতে পারে:
- "টেক্সচার" বিভাগে এমন ছবি খুঁজুন যা ফাইনাল রেন্ডারের দিকে এগিয়ে যাওয়ার ধাপ, শুধুমাত্র এলিমেন্ট তৈরি করা নয়, এটি সাধারণত "ইন্টারমিডিয়েট রেন্ডার" নামে পরিচিত।
- Android SDK অ্যাপ্লিকেশনের জন্য, এই লেআউটের ইন্টারমিডিয়েট রেন্ডার বন্ধ করতে, আপনি প্রায়ই
লেআউট ফ্ল্যাগ
forceHasOverlappedRendering:falseব্যবহার করে এগুলি সরিয়ে দিতে পারেন। - ওভারল্যাপ করা রেন্ডার সংক্রান্ত সমস্যা সমাধানের জন্য ওভারল্যাপিং রেন্ডার এড়িয়ে চলুন লিঙ্কে গিয়ে আরও জানুন।
- সম্ভব হলে, প্লেসহোল্ডার ছবি লোড করা এড়িয়ে চলুন, প্লেসহোল্ডার টেক্সচারের জন্য
@android:color/বা@colorব্যবহার করুন। - কম্পোজিশন অফলাইনে করা গেলে, ডিভাইসে একাধিক ছবি কম্পোজিট করা এড়িয়ে চলুন। ডাউনলোড করা ছবি থেকে ছবি কম্পোজ করার পরিবর্তে আলাদা ছবি লোড করা পছন্দ করি
- বিম্যাপ আরও ভালোভাবে ম্যানেজ করতে বিম্যাপ ম্যানেজ করা গাইড ফলো করুন।
Anon+Swap মেমরি
Anon+Swap হল Android Studio
মেমরি প্রোফাইলারের মধ্যে নেটিভ + জাভা + স্ট্যাক অ্যালোকেশন। ডিভাইসে মেমরি সংক্রান্ত সমস্যা আছে কিনা তা চেক করতে
ActivityManager.isLowMemoryDevice()
ব্যবহার করুন এবং এইসব নির্দেশিকা মেনে
এই পরিস্থিতির সাথে মানিয়ে নিন।
- মিডিয়া:
- ডিভাইসের RAM ও ভিডিও প্লেব্যাক রেজোলিউশনের উপর নির্ভর করে মিডিয়া বাফারের জন্য পরিবর্তনযোগ্য সাইজ নির্দিষ্ট করুন। এতে ১ মিনিট
ভিডিও প্লেব্যাক থাকতে হবে:
- ১ জিবি / 1080p-এর জন্য ৪০-৬০ এমবি
- ১.৫ জিবি / ১০৮০p-এর জন্য ৬০-৮০ এমবি
- ১.৫ জিবি / ২১৬০p-এর জন্য ৮০-১০০ এমবি
- ২ জিবি / ২১৬০p-এর জন্য ১০০-১২০ এমবি
- কোনও এপিসোড পরিবর্তন করার সময় ফ্রি মিডিয়া মেমরি অ্যালোকেশন যাতে অপরিচিত মেমরির মোট পরিমাণ বৃদ্ধি না পায়।
- আপনার অ্যাপ বন্ধ হয়ে গেলে,
মিডিয়া রিসোর্স অবিলম্বে রিলিজ ও বন্ধ করুন: অডিও ও ভিডিও রিসোর্স ম্যানেজ করতে, অ্যাক্টিভিটি লাইফসাইকেল কলব্যাক
ব্যবহার করুন। আপনার অ্যাপ অডিও অ্যাপ না হলে,
আপনার অ্যাক্টিভিটিতে
onStopহলে প্লেব্যাক বন্ধ করুন, আপনার করা সব কাজ সেভ করুন এবং আপনার রিসোর্স রিলিজ করুন। পরে প্রয়োজন হবে এমন কাজ শিডিউল করতে, জব ও অ্যালার্ম বিভাগ দেখুন।- অ্যাক্টিভিটি লাইফসাইকেল কল ম্যানেজ করতে সাহায্য পেতে, আপনি লাইফসাইকেল সচেতন কম্পোনেন্ট
যেমন
LiveDataওLifecycleOwnerব্যবহার করতে পারেন। - আপনার কাজকে লাইফসাইকেল সচেতন করে তুলতে, আপনি Kotlin coroutines এবং Kotlin flows-ও ব্যবহার করতে পারেন।
- অ্যাক্টিভিটি লাইফসাইকেল কল ম্যানেজ করতে সাহায্য পেতে, আপনি লাইফসাইকেল সচেতন কম্পোনেন্ট
যেমন
- ভিডিও খোঁজার সময় বাফারের মেমরির দিকে নজর দিন: ডেভেলপাররা
ব্যবহারকারীর জন্য ভিডিও রেডি রাখতে খোঁজার সময় প্রায়ই
ভবিষ্যতের কন্টেন্টের জন্য অতিরিক্ত ১৫-৬০ সেকেন্ড বরাদ্দ করেন, কিন্তু এর ফলে অতিরিক্ত মেমরি ওভারহেড তৈরি হয়।
সাধারণত, ব্যবহারকারী নতুন ভিডিও পজিশন বেছে না নেওয়া পর্যন্ত ৫ সেকেন্ডের বেশি
ভবিষ্যতের বাফার নেবেন না। খোঁজার সময় অতিরিক্ত সময় প্রি-বাফার করার প্রয়োজন হলে, এগুলি করতে ভুলবেন না:
- আগে থেকেই সিকিং বাফার বরাদ্দ করুন এবং এটি আবার ব্যবহার করুন।
- বাফার সাইজ ১৫-২৫ এমবি (ডিভাইস মেমরির উপর নির্ভর করে) থেকে বড় হলে চলবে না।
- ডিভাইসের RAM ও ভিডিও প্লেব্যাক রেজোলিউশনের উপর নির্ভর করে মিডিয়া বাফারের জন্য পরিবর্তনযোগ্য সাইজ নির্দিষ্ট করুন। এতে ১ মিনিট
ভিডিও প্লেব্যাক থাকতে হবে:
- বরাদ্দ:
- গ্রাফিক্স মেমরি সংক্রান্ত নির্দেশিকা ব্যবহার করে নিশ্চিত করুন যে
আপনি অ্যাননিমাস মেমরিতে ছবি ডুপ্লিকেট করছেন না
- ছবিগুলি প্রায়শই মেমরির সবচেয়ে বড় ব্যবহারকারী হয়, তাই সেগুলির ডুপ্লিকেট ডিভাইসের উপর অনেক চাপ ফেলতে পারে। এটি বিশেষ করে ইমেজ গ্রিডভিউয়ের মধ্যে দিয়ে অনেক বেশি নেভিগেট করার সময় হয়।
- স্ক্রিন পরিবর্তন করার সময় রেফারেন্স বাদ দিয়ে অ্যাসাইনমেন্ট রিলিজ করুন: নিশ্চিত করুন যে বিটম্যাপ ও অবজেক্টের কোনও রেফারেন্স যেন বাদ না যায়।
- গ্রাফিক্স মেমরি সংক্রান্ত নির্দেশিকা ব্যবহার করে নিশ্চিত করুন যে
আপনি অ্যাননিমাস মেমরিতে ছবি ডুপ্লিকেট করছেন না
- লাইব্রেরি:
- নতুন প্রোফাইল যোগ করার সময় লাইব্রেরি থেকে প্রোফাইল মেমরি অ্যালোকেশন, কারণ সেগুলি অতিরিক্ত লাইব্রেরিও লোড করতে পারে, যা অ্যালোকেশন করতে এবং বাইন্ডিং তৈরি করতে পারে।
- নেটওয়ার্কিং:
- অ্যাপ স্টার্ট-আপের সময় নেটওয়ার্ক কল ব্লক করবেন না। এগুলি অ্যাপ চালু হওয়ার সময়কে ধীর করে দেয় এবং লঞ্চের সময় অতিরিক্ত মেমরি ওভারহেড তৈরি করে, যেখানে অ্যাপ লোডের কারণে মেমরি বিশেষভাবে সীমাবদ্ধ থাকে। প্রথমে লোডিং বা স্প্ল্যাশ স্ক্রিন দেখান এবং UI ঠিকমতো সেট হয়ে যাওয়ার পরে নেটওয়ার্ক অনুরোধ করুন।
বাইন্ডিং
বাইন্ডিং অতিরিক্ত মেমরি ওভারহেড যোগ করে কারণ এটি অন্যান্য অ্যাপ্লিকেশনকে মেমরিতে নিয়ে আসে অথবা বাইন্ড করা অ্যাপের মেমরি কনজাম্পশন বাড়িয়ে দেয় (এটি আগে থেকেই মেমরিতে থাকলে তবেই) যাতে API কল করা যায়। এর ফলে, ফোরগ্রাউন্ড অ্যাপের জন্য উপলভ্য মেমরি কমে যায়। কোনও পরিষেবা বাইন্ড করার সময়, আপনি কখন এবং কতক্ষণ বাইন্ডিং ব্যবহার করছেন সেই বিষয়ে সচেতন থাকুন। প্রয়োজন না হলেই বাইন্ডিং রিলিজ করতে ভুলবেন না।
সাধারণ বাইন্ডিং ও পেশাদার পদ্ধতি:
- Play integrity API: ডিভাইস
ইন্টিগ্রিটি
চেক করতে ব্যবহার করা হয়
- লোডিং স্ক্রিন ও মিডিয়া প্লেব্যাকের আগে ডিভাইস ইন্টিগ্রিটি চেক করা
- কন্টেন্ট চালানোর আগে PlayIntegrity-এর রেফারেন্স রিলিজ করুন
StandardIntegrityManager।
- Play Billing Library: Google Play ব্যবহার করে
সাবস্ক্রিপশন ও কেনাকাটা ম্যানেজ করার জন্য
ব্যবহৃত হয়
- লোডিং স্ক্রিনের পরে লাইব্রেরি ইনিশিয়ালাইজ করুন এবং কোনও মিডিয়া চালানোর আগে সব বিলিং সংক্রান্ত কাজ সামলে নিন।
- লাইব্রেরি ব্যবহার করা হয়ে গেলে এবং ভিডিও বা মিডিয়া চালানোর আগে সবসময়
BillingClient.endConnection()ব্যবহার করুন। - কোনও বিলিং সংক্রান্ত কাজ আবার করার প্রয়োজন হলে, পরিষেবা ডিসকানেক্ট করা হয়েছে কিনা তা চেক করতে
BillingClient.isReady()এবংBillingClient.getConnectionState()ব্যবহার করুন এবং কাজ শেষ হয়ে গেলে আবারBillingClient.endConnection()ব্যবহার করুন।
- GMS FontsProvider
- কম RAM আছে এমন ডিভাইসে ফন্ট প্রদানকারীর পরিবর্তে স্ট্যান্ডঅ্যালোন ফন্ট ব্যবহার করা ভাল, কারণ ফন্ট ডাউনলোড করা ব্যয়বহুল এবং এটি করার জন্য FontsProvider পরিষেবা বাইন্ড করবে।
- Google Assistant লাইব্রেরি: কখনও কখনও
সার্চ ও ইন-অ্যাপ সার্চের জন্য ব্যবহার করা হয়, সম্ভব হলে এই লাইব্রেরি পাল্টে দিন।
- লীনব্যাক অ্যাপের জন্য: Gboard টেক্সট-টু-স্পিচ বা
androidx.leanback লাইব্রেরি ব্যবহার করুন।
- সার্চ প্রয়োগ করার জন্য সার্চ নির্দেশিকা অনুসরণ করুন।
- মনে রাখবেন: leanback আর ব্যবহার করা হয় না এবং অ্যাপগুলিকে TV Compose-এ সরিয়ে দেওয়া উচিত।
- Compose অ্যাপের জন্য:
- ভয়েস সার্চ প্রয়োগ করতে Gboard টেক্সট-টু-স্পিচ ব্যবহার করুন।
- আপনার অ্যাপে মিডিয়া কন্টেন্ট ডিসকভার করার জন্য পরে দেখুন ফিচার প্রয়োগ করুন।
- লীনব্যাক অ্যাপের জন্য: Gboard টেক্সট-টু-স্পিচ বা
androidx.leanback লাইব্রেরি ব্যবহার করুন।
ফোরগ্রাউন্ড পরিষেবা
ফোরগ্রাউন্ড পরিষেবা হল বিশেষ ধরনের পরিষেবা যা বিজ্ঞপ্তির সাথে যুক্ত থাকে। এই বিজ্ঞপ্তি ফোন ও ট্যাবলেটের বিজ্ঞপ্তি ট্রেতে দেখানো হয়, কিন্তু টিভি ডিভাইসে সেই অর্থে কোনও বিজ্ঞপ্তি ট্রে থাকে না। এমনকি, ফোরগ্রাউন্ড পরিষেবা উপযোগী হলেও, কারণ অ্যাপ্লিকেশন ব্যাকগ্রাউন্ডে থাকাকালীন সেগুলি চালু রাখা যায়, TV অ্যাপকে এইসব নির্দেশিকা মেনে চলতে হবে:
Android TV ও Google TV-তে, ব্যবহারকারী অ্যাপ ছেড়ে বেরিয়ে যাওয়ার পরেও সেটি চালু রাখার জন্য ফোরগ্রাউন্ড পরিষেবা শুধুমাত্র অনুমতি দেওয়া হয়:
- অডিও অ্যাপের ক্ষেত্রে: ব্যবহারকারী অ্যাপ থেকে বেরিয়ে গেলেও অডিও ট্র্যাক চালিয়ে যাওয়ার জন্য ফোরগ্রাউন্ড পরিষেবা শুধুমাত্র চালু রাখার অনুমতি দেওয়া হয়। অডিও প্লেব্যাক শেষ হওয়ার সাথে সাথেই পরিষেবা বন্ধ করতে হবে।
- অন্যান্য অ্যাপের ক্ষেত্রে: সব ফোরগ্রাউন্ড পরিষেবা বন্ধ করতে হবে, ব্যবহারকারী আপনার অ্যাপ ছেড়ে বেরিয়ে গেলে, কারণ অ্যাপটি এখনও চলছে এবং রিসোর্স ব্যবহার করছে বলে ব্যবহারকারীকে জানানোর জন্য কোনও বিজ্ঞপ্তি নেই।
- সাজেশন আপডেট করা বা
পরের ভিডিও-এর মতো ব্যাকগ্রাউন্ড জবের জন্য
WorkManagerব্যবহার করুন।
জব ও অ্যালার্ম
WorkManager
হল ব্যাকগ্রাউন্ডে রেকারিং জব শিডিউল করার জন্য অত্যাধুনিক Android API।
WorkManager উপলভ্য থাকলে নতুন
JobScheduler (SDK
23+) এবং উপলভ্য না থাকলে পুরনো AlarmManager ব্যবহার
করবে। টিভিতে শিডিউল করা জব পারফর্ম করার জন্য পেশাদার পদ্ধতি হিসেবে এইসব
সাজেস্ট অনুসরণ করুন:
- SDK 23+ ভার্সনে
AlarmManagerAPI ব্যবহার করা এড়িয়ে চলুন, বিশেষ করেAlarmManager.set(),AlarmManager.setExact()এবং এই ধরনের পদ্ধতি, কারণ এগুলি সিস্টেমকে জব চালানোর সঠিক সময় নির্ধারণ করতে দেয় না (যেমন, ডিভাইস যখন অলস থাকে)। - কম র্যাম থাকা ডিভাইসে, খুব প্রয়োজন না হলে কোনও জব রান করাবেন না। প্রয়োজন হলে,
WorkManager ব্যবহার করুন
WorkRequestশুধুমাত্র প্লেব্যাকের পরে সাজেশন আপডেট করার জন্য এবং অ্যাপটি এখনও খোলা থাকাকালীন এটি করার চেষ্টা করুন। সঠিক সময় হলে সিস্টেমকে আপনার জব রান করতে দিতে, WorkManager
Constraintsনির্ধারণ করুন:
Kotlin
Constraints.Builder() .setRequiredNetworkType(NetworkType.CONNECTED) .setRequiresStorageNotLow(true) .setRequiresDeviceIdle(true) .build()
জাভা
Constraints.Builder()
.setRequiredNetworkType(NetworkType.CONNECTED)
.setRequiresStorageNotLow(true)
.setRequiresDeviceIdle(true)
.build()
- আপনাকে যদি নিয়মিত জব রান করাতে হয় (যেমন, কোনও ব্যবহারকারীর অন্য ডিভাইসে আপনার অ্যাপে কন্টেন্ট দেখার অ্যাক্টিভিটির উপর ভিত্তি করে পরে দেখুন আপডেট করতে), তাহলে জব মেমরি কনজাম্পশন ৩০ এমবি-র নিচে রেখে মেমরি ব্যবহার কম রাখুন।
মেমরি সংক্রান্ত সাধারণ বিবেচ্য বিষয়
Android অ্যাপ ডেভেলপমেন্ট সম্পর্কে নিম্নলিখিত নির্দেশিকা থেকে সাধারণ তথ্য পাবেন:
- অবজেক্ট অ্যালোকেশন কমান, অবজেক্টের আবার ব্যবহার অপ্টিমাইজ করুন এবং কোনও
অব্যবহৃত অবজেক্ট অবিলম্বে ডি-অ্যালোকেট করুন।
- অবজেক্টের, বিশেষ করে বিটম্যাপের রেফারেন্স হোল্ড করবেন না।
System.gc()ও সরাসরি রিলিজ মেমরি কল ব্যবহার করা এড়িয়ে চলুন কারণ এগুলি সিস্টেমের মেমরি ম্যানেজ করার প্রসেসে বাধা দেয়: যেমন, zRAM ব্যবহার করা ডিভাইসে,gc()-এ জোর করে কল করলে সাময়িকভাবে মেমরি ব্যবহারের পরিমাণ বেড়ে যেতে পারে কারণ মেমরি কম্প্রেস ও ডিকম্প্রেস করা হয়।- ভিউ আবার ব্যবহার করতে এবং তালিকা আইটেম আবার তৈরি না করতে, Compose-এ দেখানো
ক্যাটালগ ব্রাউজার বা এখন আর ব্যবহার করা হয় না এমন Leanback UI টুলকিটে
RecyclerView-এর মতোLazyListব্যবহার করুন। - এক্সটার্নাল কন্টেন্ট প্রদানকারীর থেকে পড়া এলিমেন্ট লোকালি ক্যাশে করে যা পরিবর্তন হওয়ার সম্ভাবনা কম এবং আপডেট করার ইন্টারভ্যাল নির্ধারণ করে যা অতিরিক্ত এক্সটার্নাল মেমরি বরাদ্দ করা আটকায়।
- সম্ভাব্য মেমরি লিকেজ চেক করুন।
- অপরিচিত থ্রেডের মধ্যে রেফারেন্স, ভিডিও বাফার আবার অ্যাসাইন করা যা কখনও রিলিজ করা হয় না এবং এই ধরনের অন্যান্য পরিস্থিতি সহ সাধারণ মেমরি লিক সংক্রান্ত ঘটনার দিকে নজর রাখুন।
- মেমরি লিকেজ ডিবাগ করতে হিপ ডাম্প ব্যবহার করুন।
- আপনার অ্যাপ কোল্ড স্টার্টে এক্সিকিউট করার সময় জাস্ট-ইন-টাইম কম্পাইলেশনের প্রয়োজনীয়তা কমাতে বেসলাইন প্রোফাইল তৈরি করুন।
সরাসরি মেমরি রিক্লেইম করা সম্পর্কে বোঝা
কোনও Android TV অ্যাপ্লিকেশন মেমরির জন্য অনুরোধ করলে এবং সিস্টেমের উপর চাপ পড়লে, Android-এর ভিত্তি হিসেবে কাজ করা Linux কার্নেলকে সরাসরি মেমরি রিক্লেইম ব্যবহার করতে হতে পারে।
এই প্রসেসে অ্যালোকেট করা যেকোনও থ্রেড সম্পূর্ণভাবে পজ করা হয় যাতে মেমরি পৃষ্ঠা খালি হওয়ার জন্য অপেক্ষা করা যায়। প্রোঅ্যাক্টিভভাবে পর্যাপ্ত মেমরি পুল ম্যানেজ করতে না পারলে এটি ঘটে।
এর ফলে ব্যবহারকারীর অভিজ্ঞতায় বোঝা যায় এমন পজ বা জ্যাঙ্ক হতে পারে, কারণ
যথেষ্ট মেমরি উপলভ্য না হওয়া পর্যন্ত সিস্টেম থ্রেড অ্যাসাইন করা পজ করে দেয়। এই
অর্থে, থ্রেড বরাদ্দ করা শুধুমাত্র
malloc()-এর মতো অ্যাপ্লিকেশন কোড কলের মধ্যে সীমাবদ্ধ নয়; উদাহরণস্বরূপ, কোড পৃষ্ঠায় পৃষ্ঠায় মেমরি বরাদ্দ করতে হবে।
টুলের সারসংক্ষেপ
- ব্যবহারের সময় মেমরি কতটা খরচ হচ্ছে তা চেক করতে, Android Studio মেমরি প্রোফাইলার টুল
ব্যবহার করুন।
- নির্দিষ্ট অবজেক্ট ও বিটম্যাপ অ্যালোকেশন চেক করতে heapdump ব্যবহার করুন।
- Java বা Kotlin ছাড়া অন্য কোনও অ্যালোকেশন চেক করতে নেটিভ মেমরি প্রোফাইলার ব্যবহার করুন।
- গ্রাফিক্স অ্যালোকেশন চেক করতে Android GPU Inspector ব্যবহার করুন।