গ্রাফিক্স স্ট্যাকে, IPC-এর মাধ্যমে ফাইল
ডেসক্রিপ্টর পাঠানোর সাথে যুক্ত ওভারহেড কমাতে, কম্পোজার HAL এবং
SurfaceFlinger-এর মধ্যে একটি পার-লেয়ার বাফার ক্যাশে থাকে। Android 14-এর আগে, SurfaceFlinger-এর
GraphicBufferConsumer থেকে GraphicBufferProducer ডিসকানেক্ট হয়ে গেলে,
সিস্টেম এই বাফার ক্যাশে মুছে দিত না,
যেমন, SurfaceView থেকে MediaCodec
ডিসকানেক্ট হয়ে গেলে। Android 14 থেকে শুরু করে, গ্রাফিক্স মেমরির ব্যবহার কমাতে আপনি এই বাফার ক্যাশে
জোরপূর্বক মুছে ফেলতে পারবেন।
নিম্নলিখিত দুটি বিকল্পের মধ্যে থেকে একটি বেছে নিন:
- Android 14 ও তার পরবর্তী যেকোনও ভার্সন সহ লঞ্চ করা ডিভাইসের জন্য, আপনাকে অবশ্যই নতুন কম্পোজার HAL API ভার্সন 3.2 প্রয়োগ করতে হবে। এই বিকল্পটি সাধারণত চালু থাকে এবং সর্বাধিক মেমরি সেভ করে। যেসব ডিভাইস 14 বা তার পরবর্তী যেকোনও ভার্সনে আপগ্রেড করা হচ্ছে, সেগুলিও মেমরির সম্পূর্ণ সুবিধা পেতে এই বিকল্প ব্যবহার করতে পারে।
- যেসব ডিভাইস Android 14-এ আপগ্রেড করছে এবং সেগুলির জন্য আপনি Composer HAL 3.2 API প্রয়োগ করতে চান না, সেগুলির ক্ষেত্রে আপনি পুরনো মানানসই বিকল্প চালু করতে পারেন। এই বিকল্পটি আগের বিকল্পের মতোই প্রায় একই পরিমাণ মেমরি সেভ করে।
নিচের দুটি বিভাগে প্রতিটি বিকল্প কীভাবে প্রয়োগ করতে হয় তা ব্যাখ্যা করা হয়েছে।
Composer HAL 3.2 API প্রয়োগ করুন
গ্রাফিক্স বাফার মেমরির সম্পূর্ণ সুবিধা পেতে, আপনাকে অবশ্যই:
- আপনার কম্পোজার HAL ইমপ্লিমেন্টেশনকে ভার্সন 3.2-এ আপডেট করুন।
- তালিকায় পাওয়া স্লট নম্বর দ্বারা চিহ্নিত করা এন্ট্রিগুলি
বাফার ক্যাশ থেকে সরিয়ে
LayerCommand::bufferSlotsToClearপ্রসেস করুন।
গ্রাফিক বাফার মেমরি সম্পর্কিত Composer HAL 3.2 API, যার মধ্যে
LayerCommand::bufferSlotsToClear অন্তর্ভুক্ত, সেগুলি
LayerCommand.aidl ফাইলে রয়েছে।
ব্যাকওয়ার্ড কম্প্যাটিবল বিকল্প চালু করুন
ব্যাকওয়ার্ড-কম্প্যাটিবল মেমরি কমানোর বিকল্পটি ক্যাশে স্লটে
১x১ প্লেসহোল্ডার বাফার দিয়ে আসল বাফারটি পাল্টে দেয়। এর ফলে বর্তমান অ্যাক্টিভ বাফার স্লট ছাড়া
সব মুছে ফেলা স্লটের জন্য মেমরি সাশ্রয় হয়। আংশিক মেমরি সেভিং সুবিধা পেতে, surface_flinger.clear_slots_with_set_layer_buffer sysprop-কে
true হিসেবে সেট করে
ব্যাকওয়ার্ড-কম্প্যাটিবল বিকল্প চালু করুন। এই sysprop
property_contexts ফাইলে পাওয়া যায়।
এই sysprop সেট করার জন্য আপনার Composer HAL প্রয়োগকে সঠিকভাবে
একক প্রেজেন্ট সাইকেলে একই লেয়ারের জন্য একাধিক setLayerBuffer কমান্ড
হ্যান্ডেল করতে হবে।
ব্যাকওয়ার্ড-কম্প্যাটিবল বিকল্প চালু করলে নিম্নলিখিত প্রভাব পড়ে:
AIDL HAL-এর জন্য: SurfaceFlinger একটি লেয়ারের জন্য একাধিক
LayerCommandইনস্ট্যান্স পাঠায়, প্রতিটিতে একটি করেBufferCommandথাকে। প্রতিটিBufferCommand১x১ প্লেসহোল্ডার বাফার হ্যান্ডেল এবং ক্যাশে বাফার স্লটের জন্য একটি স্লট নম্বর থাকে যেটিকে খালি করতে হয়।HIDL HAL-এর জন্য: SurfaceFlinger একাধিক
SELECT_DISPLAY,SELECT_LAYER,SET_BUFFERকমান্ড পাঠায়। এইসব কমান্ডে ১x১ প্লেসহোল্ডার বাফার হ্যান্ডেল এবং ক্যাশে বাফার স্লটের জন্য একটি স্লট নম্বর থাকে যেটি মুছে ফেলতে হবে।
ব্যাকওয়ার্ড কম্প্যাটিবল বিকল্পের কারণে কিছু ডিভাইসে Composer HAL ক্র্যাশ করতে পারে। এই সমস্যার সমাধান করতে, আপনি হয়ত নিজের কম্পোজার HAL পরিবর্তন করতে পারবেন। এই আচরণ নিয়ন্ত্রণকারী কোডটি এখানে পাওয়া যাবে:
গ্রাফিক্স বাফার ক্যাশে মেমরি কনজাম্পশন পরীক্ষা করা
HAL ইমপ্লিমেন্টেশন ক্যাশে স্লট খালি করে কিনা তা টেস্টের মাধ্যমে যাচাই করা যায় না। তবে, গ্রাফিক বাফার ব্যবহার মনিটর করতে আপনি ডিবাগিং টুল ব্যবহার করতে পারেন। মনিটর করার সময়, আপনি হয়ত এমন পরিস্থিতি লক্ষ্য করবেন যেখানে YouTube-এ একাধিক আলাদা আলাদা ভিডিও দ্রুত বন্ধ ও চালু করা হয় এবং এর ফলে মেমরি সংক্রান্ত সমস্যা কম হয়।
VTS টেস্ট উপলভ্য আছে যা যাচাই করে যে HAL ইমপ্লিমেন্টেশন
কার্যকরীভাবে নতুন API কল (HAL ভার্সন ৩.২+) বা
ব্যাকওয়ার্ড-কম্প্যাটিবল ইমপ্লিমেন্টেশনের জন্য একাধিক setLayerBuffer কমান্ড
গ্রহণ করতে সক্ষম। তবে, সঠিক কার্যকারিতার জন্য এটিকে পর্যাপ্ত পরীক্ষা হিসাবে বিবেচনা করা উচিত নয়, কারণ কিছু ডিভাইস এই VTS পরীক্ষায় পাস করে, কিন্তু বাস্তব-জগতের ব্যবহারের ক্ষেত্রে ব্যর্থ হয়।
নতুন VTS পরীক্ষার জন্য, নিম্নলিখিত লিঙ্ক দেখুন: