অসংখ্য পরীক্ষা-নিরীক্ষা, ব্যবহারিক পরামর্শ এবং ব্যাক আপ করার জন্য পারফরম্যান্স পরীক্ষা সহ এই বিশদ নির্দেশিকাটি ব্যবহার করে ইউনিটিতে UI কার্যক্ষমতা কীভাবে অপ্টিমাইজ করা যায় তা দেখুন! নমস্কার! আমি Sergey Begichev, Pixonic (MY.GAMES) এর ক্লায়েন্ট ডেভেলপার। এই পোস্টে, আমি Unity3D-এ UI অপ্টিমাইজেশান নিয়ে আলোচনা করব। টেক্সচারের একটি সেট রেন্ডার করা সহজ মনে হতে পারে, এটি উল্লেখযোগ্য কর্মক্ষমতা সমস্যা হতে পারে। উদাহরণস্বরূপ, আমাদের ওয়ার রোবট প্রকল্পে, মোট সিপিইউ লোডের 30% পর্যন্ত অপ্টিমাইজড UI সংস্করণগুলি দায়ী - একটি বিস্ময়কর চিত্র! সাধারণত, এই সমস্যাটি দুটি অবস্থার অধীনে দেখা দেয়: এক, যখন অসংখ্য গতিশীল বস্তু থাকে এবং দুই, যখন ডিজাইনাররা লেআউট তৈরি করে যা বিভিন্ন রেজোলিউশন জুড়ে নির্ভরযোগ্য স্কেলিংকে অগ্রাধিকার দেয়। এমনকি একটি ছোট UI এই পরিস্থিতিতে একটি লক্ষণীয় লোড তৈরি করতে পারে। আসুন এটি কীভাবে কাজ করে তা অন্বেষণ করি, লোডের কারণগুলি চিহ্নিত করুন এবং সম্ভাব্য সমাধানগুলি নিয়ে আলোচনা করুন। ঐক্যের সুপারিশ প্রথম, এর পর্যালোচনা করা যাক UI অপ্টিমাইজেশানের জন্য, যা আমি ছয়টি মূল পয়েন্টে সংক্ষিপ্ত করেছি: ঐক্যের সুপারিশ আপনার ক্যানভাসগুলিকে সাব-ক্যানভাসে বিভক্ত করুন অপ্রয়োজনীয় Raycast টার্গেট সরান ব্যয়বহুল উপাদান ব্যবহার করা এড়িয়ে চলুন (বড় তালিকা, গ্রিড ভিউ, ইত্যাদি) লেআউট গ্রুপ এড়িয়ে চলুন গেম অবজেক্টের পরিবর্তে ক্যানভাস লুকান (GO) সর্বোত্তমভাবে অ্যানিমেটর ব্যবহার করুন পয়েন্ট 2 এবং 3 স্বজ্ঞাতভাবে পরিষ্কার হলেও, বাকি সুপারিশগুলি অনুশীলনে কল্পনা করা সমস্যাযুক্ত হতে পারে। উদাহরণস্বরূপ, "আপনার ক্যানভাসগুলিকে সাব-ক্যানভাসে বিভক্ত করার" পরামর্শ অবশ্যই মূল্যবান, তবে ইউনিটি এই বিভাজনের পিছনে নীতিগুলির বিষয়ে স্পষ্ট নির্দেশিকা প্রদান করে না। নিজের জন্য বলতে গেলে, ব্যবহারিক পরিপ্রেক্ষিতে, আমি জানতে চাই যে কোথায় সাব-ক্যানভাসগুলি বাস্তবায়ন করা সবচেয়ে বেশি অর্থপূর্ণ। "লেআউট গ্রুপ এড়াতে" পরামর্শটি বিবেচনা করুন। যদিও তারা একটি উচ্চ UI লোডে অবদান রাখতে পারে, অনেক বড় UI একাধিক লেআউট গ্রুপের সাথে আসে এবং সবকিছু পুনরায় কাজ করা সময়সাপেক্ষ হতে পারে। তদুপরি, লেআউট ডিজাইনাররা যারা লেআউট গ্রুপগুলি এড়িয়ে চলেন তারা তাদের কাজগুলিতে উল্লেখযোগ্যভাবে বেশি সময় ব্যয় করতে পারেন। অতএব, এই ধরনের গোষ্ঠীগুলি কখন এড়ানো উচিত, কখন তারা উপকারী হতে পারে এবং যদি আমরা তাদের নির্মূল করতে না পারি তবে কী পদক্ষেপ নেওয়া উচিত তা বোঝা সহায়ক হবে। ইউনিটির সুপারিশগুলিতে এই অস্পষ্টতা একটি মূল সমস্যা - এই পরামর্শগুলিতে আমাদের কোন নীতিগুলি প্রয়োগ করা উচিত তা প্রায়শই অস্পষ্ট। UI নির্মাণের নীতি UI কর্মক্ষমতা অপ্টিমাইজ করার জন্য, ইউনিটি কীভাবে UI তৈরি করে তা বোঝা অপরিহার্য। ইউনিটিতে কার্যকর UI অপ্টিমাইজেশনের জন্য এই ধাপগুলি বোঝা অত্যন্ত গুরুত্বপূর্ণ। আমরা এই প্রক্রিয়ার তিনটি মূল পর্যায়কে বিস্তৃতভাবে চিহ্নিত করতে পারি: প্রাথমিকভাবে, ইউনিটি সমস্ত UI উপাদানগুলিকে তাদের আকার এবং মনোনীত অবস্থানের উপর ভিত্তি করে সাজায়। এই অবস্থানগুলি পর্দার প্রান্ত এবং অন্যান্য উপাদানগুলির সাথে সম্পর্কিত, নির্ভরশীলতার একটি শৃঙ্খল গঠন করে গণনা করা হয়। লেআউট এর পরে, ইউনিটি আরও দক্ষ রেন্ডারিংয়ের জন্য পৃথক উপাদানগুলিকে ব্যাচগুলিতে গ্রুপ করে। একাধিক ছোট উপাদান রেন্ডার করার চেয়ে একটি বড় উপাদান আঁকা সবসময়ই বেশি কার্যকর। (ব্যাচিংয়ের গভীরে ডুব দেওয়ার জন্য, পড়ুন ) ব্যাচিং এই নিবন্ধ. অবশেষে, ইউনিটি সংগৃহীত ব্যাচগুলি আঁকে। যত কম ব্যাচ থাকবে, রেন্ডারিং প্রক্রিয়া তত দ্রুত হবে। রেন্ডারিং যদিও প্রক্রিয়ার সাথে জড়িত অন্যান্য উপাদান রয়েছে, এই তিনটি পর্যায়ে বেশিরভাগ সমস্যার জন্য দায়ী, তাই আপাতত, আসুন সেগুলির উপর ফোকাস করা যাক। আদর্শভাবে, যখন আমাদের UI স্থির থাকে — মানে কিছুই নড়াচড়া বা পরিবর্তন হয় না — আমরা একবার লেআউট তৈরি করতে পারি, একটি বড় ব্যাচ তৈরি করতে পারি এবং দক্ষতার সাথে রেন্ডার করতে পারি। যাইহোক, যদি আমরা এমনকি একটি উপাদানের অবস্থান পরিবর্তন করি, তাহলে আমাদের অবশ্যই এর অবস্থান পুনরায় গণনা করতে হবে এবং প্রভাবিত ব্যাচটি পুনর্নির্মাণ করতে হবে। যদি অন্যান্য উপাদানগুলি এই অবস্থানের উপর নির্ভর করে, তাহলে আমাদেরকে তাদের অবস্থানগুলিকেও পুনরায় গণনা করতে হবে, যার ফলে সমগ্র শ্রেণিবিন্যাস জুড়ে একটি ক্যাসকেডিং প্রভাব সৃষ্টি হবে। এবং যত বেশি উপাদানের সমন্বয় প্রয়োজন, ব্যাচিং লোড তত বেশি হবে। সুতরাং, একটি লেআউটের পরিবর্তনগুলি সমগ্র UI জুড়ে একটি লহরী প্রভাব ট্রিগার করতে পারে এবং আমাদের লক্ষ্য পরিবর্তনের সংখ্যা কমিয়ে আনা। (বিকল্পভাবে, আমরা একটি চেইন প্রতিক্রিয়া প্রতিরোধ করার জন্য পরিবর্তনগুলিকে বিচ্ছিন্ন করার লক্ষ্য রাখতে পারি।) একটি ব্যবহারিক উদাহরণ হিসাবে, লেআউট গ্রুপ ব্যবহার করার সময় এই সমস্যাটি বিশেষভাবে উচ্চারিত হয়। প্রতিবার একটি লেআউট পুনর্নির্মাণ করা হলে, প্রতিটি LayoutElement একটি GetComponent অপারেশন সম্পাদন করে, যা বেশ সম্পদ-নিবিড় হতে পারে। একাধিক পরীক্ষা পারফরম্যান্স ফলাফল তুলনা করার জন্য উদাহরণগুলির একটি সিরিজ পরীক্ষা করা যাক। (সমস্ত পরীক্ষাগুলি Google Pixel 1 ডিভাইসে ইউনিটি সংস্করণ 2022.3.24f1 ব্যবহার করে পরিচালিত হয়েছিল।) এই পরীক্ষায়, আমরা একটি একক উপাদান সমন্বিত একটি বিন্যাস গোষ্ঠী তৈরি করব, এবং আমরা দুটি পরিস্থিতি বিশ্লেষণ করব: একটি যেখানে আমরা উপাদানটির আকার পরিবর্তন করি এবং আরেকটি যেখানে আমরা FillAmount বৈশিষ্ট্যটি ব্যবহার করছি৷ RectTransform পরিবর্তন: FlllAmount পরিবর্তন: দ্বিতীয় উদাহরণে, আমরা একই জিনিস করার চেষ্টা করব, তবে 8টি উপাদান সহ একটি লেআউট গ্রুপে। এই ক্ষেত্রে, আমরা এখনও শুধুমাত্র একটি উপাদান পরিবর্তন করা হবে. RectTransform পরিবর্তন: FlllAmount পরিবর্তন: যদি, আগের উদাহরণে, RectTransform-এ পরিবর্তনের ফলে লেআউটে 0.2 ms লোড হয়, এইবার লোড বেড়ে 0.7 ms হয়। একইভাবে, ব্যাচিং আপডেটের লোড 0.65 ms থেকে বেড়ে 1.10 ms হয়। যদিও আমরা এখনও শুধুমাত্র একটি উপাদান পরিবর্তন করছি, লেআউটের বর্ধিত আকার পুনর্নির্মাণের সময় লোডকে উল্লেখযোগ্যভাবে প্রভাবিত করে। বিপরীতে, যখন আমরা একটি উপাদানের FillAmount সামঞ্জস্য করি, তখন আমরা লোডের কোন বৃদ্ধি লক্ষ্য করি না, এমনকি একটি বড় সংখ্যক উপাদানের সাথেও। এর কারণ হল FillAmount পরিবর্তন করা একটি লেআউট পুনর্নির্মাণকে ট্রিগার করে না, যার ফলে ব্যাচিং আপডেট লোড শুধুমাত্র সামান্য বৃদ্ধি পায়। স্পষ্টতই, এই পরিস্থিতিতে FillAmount ব্যবহার করা আরও দক্ষ পছন্দ। যাইহোক, পরিস্থিতি আরও জটিল হয়ে ওঠে যখন আমরা একটি উপাদানের স্কেল বা অবস্থান পরিবর্তন করি। এই ক্ষেত্রে, ইউনিটির বিল্ট-ইন মেকানিজমগুলি প্রতিস্থাপন করা চ্যালেঞ্জিং যা লেআউট পুনর্নির্মাণকে ট্রিগার করে না। এখানেই সাবক্যানভাসগুলি কার্যকর হয়৷ যখন আমরা একটি সাবক্যানভাসের মধ্যে একটি পরিবর্তনযোগ্য উপাদানকে এনক্যাপসুলেট করি তখন ফলাফলগুলি পরীক্ষা করা যাক। আমরা 8টি উপাদান সহ একটি লেআউট গ্রুপ তৈরি করব, যার মধ্যে একটি সাবক্যানভাসের মধ্যে রাখা হবে এবং তারপরে এর রূপান্তর পরিবর্তন করব। সাবক্যানভাসে RectTransform পরিবর্তন: ফলাফলগুলি ইঙ্গিত করে, একটি সাবক্যানভাসের মধ্যে একটি একক উপাদানকে এনক্যাপসুলেট করা প্রায় লেআউটের লোডকে সরিয়ে দেয়; এর কারণ হল সাবক্যানভাস সমস্ত পরিবর্তনকে বিচ্ছিন্ন করে, উচ্চতর স্তরের শ্রেণীবিন্যাসের পুনর্নির্মাণকে বাধা দেয়। যাইহোক, এটা মনে রাখা গুরুত্বপূর্ণ যে ক্যানভাসের মধ্যে পরিবর্তনগুলি এর বাইরের উপাদানগুলির অবস্থানকে প্রভাবিত করবে না। অতএব, যদি আমরা উপাদানগুলিকে খুব বেশি প্রসারিত করি, তাহলে একটি ঝুঁকি রয়েছে যে তারা প্রতিবেশী উপাদানগুলির সাথে ওভারল্যাপ করতে পারে। একটি সাবক্যানভাসে 8টি লেআউট উপাদান মোড়ানোর মাধ্যমে এগিয়ে যাওয়া যাক: পূর্ববর্তী উদাহরণটি দেখায় যে, লেআউটের লোড কম থাকলেও ব্যাচিং আপডেট দ্বিগুণ হয়েছে। এর মানে হল, যদিও উপাদানগুলিকে একাধিক সাবক্যানভাসে বিভক্ত করা লেআউট বিল্ডের লোড কমাতে সাহায্য করে, এটি ব্যাচ অ্যাসেম্বলিতে লোড বাড়ায়। ফলস্বরূপ, এটি আমাদের সামগ্রিকভাবে নেতিবাচক প্রভাবের দিকে নিয়ে যেতে পারে। এখন, আরেকটি পরীক্ষা করা যাক। প্রথমে, আমরা 8টি উপাদান সহ একটি লেআউট গ্রুপ তৈরি করব এবং তারপর অ্যানিমেটর ব্যবহার করে একটি লেআউট উপাদান পরিবর্তন করব। অ্যানিমেটর রেক্টট্রান্সফর্মকে একটি নতুন মানতে সামঞ্জস্য করবে: এখানে, আমরা দ্বিতীয় উদাহরণের মতো একই ফলাফল দেখতে পাচ্ছি যেখানে আমরা ম্যানুয়ালি সবকিছু পরিবর্তন করেছি। এটি যৌক্তিক কারণ আমরা RectTransform পরিবর্তন করতে যা ব্যবহার করি তাতে কোনো পার্থক্য নেই। অ্যানিমেটর RectTransformকে একই মান পরিবর্তন করে: অ্যানিমেটররা আগে একটি সমস্যার মুখোমুখি হয়েছিল যেখানে তারা ক্রমাগত প্রতিটি ফ্রেমের একই মান ওভাররাইট করবে, এমনকি যদি সেই মান অপরিবর্তিত থাকে। এটি অসাবধানতাবশত একটি লেআউট পুনর্নির্মাণকে ট্রিগার করবে। সৌভাগ্যবশত, ইউনিটির নতুন সংস্করণগুলি এই সমস্যার সমাধান করেছে, বিকল্পে স্যুইচ করার প্রয়োজনীয়তা দূর করে শুধুমাত্র কর্মক্ষমতা উন্নতির জন্য পদ্ধতি। tweening এখন, 8টি উপাদান সহ একটি লেআউট গ্রুপের মধ্যে পাঠ্য মান পরিবর্তন কিভাবে আচরণ করে এবং এটি একটি লেআউট পুনর্নির্মাণকে ট্রিগার করে কিনা তা পরীক্ষা করা যাক: আমরা দেখতে পাচ্ছি যে পুনর্নির্মাণও শুরু হয়েছে। এখন, আমরা 8টি উপাদানের লেআউট গ্রুপে TextMechPro-এর মান পরিবর্তন করব: TextMechPro একটি লেআউট পুনর্নির্মাণকেও ট্রিগার করে এবং এমনকি মনে হচ্ছে এটি নিয়মিত পাঠ্যের চেয়ে ব্যাচিং এবং রেন্ডারিংয়ের উপর বেশি লোড রাখে। 8টি উপাদানের একটি লেআউট গ্রুপে সাবক্যানভাসে TextMechPro মান পরিবর্তন করা হচ্ছে: সাবক্যানভাস কার্যকরভাবে পরিবর্তনগুলিকে বিচ্ছিন্ন করেছে, লেআউট পুনর্নির্মাণ রোধ করেছে। তবুও, ব্যাচিং আপডেটের লোড কমে গেলেও, এটি তুলনামূলকভাবে বেশি থাকে। পাঠ্যের সাথে কাজ করার সময় এটি একটি উদ্বেগ হয়ে ওঠে, কারণ প্রতিটি অক্ষর একটি পৃথক টেক্সচার হিসাবে বিবেচিত হয়। টেক্সট পরিবর্তন ফলস্বরূপ একাধিক টেক্সচার প্রভাবিত করে। এখন, লেআউট গ্রুপের মধ্যে একটি GameObject (GO) চালু এবং বন্ধ করার সময় লোডের মূল্যায়ন করা যাক। 8টি উপাদানের একটি লেআউট গ্রুপের মধ্যে একটি গেমঅবজেক্ট চালু এবং বন্ধ করা: আমরা দেখতে পাচ্ছি, একটি GO চালু বা বন্ধ করাও একটি লেআউট পুনর্নির্মাণকে ট্রিগার করে। 8টি উপাদানের একটি লেআউট গ্রুপ সহ একটি সাবক্যানভাসের ভিতরে একটি GO চালু করা: এই ক্ষেত্রে, সাবক্যানভাস লোড উপশম করতেও সাহায্য করে। এখন, আমরা একটি লেআউট গ্রুপের সাথে পুরো GO চালু বা বন্ধ করলে লোডটি কী তা পরীক্ষা করে দেখি: ফলাফল দেখায়, লোড এখনও সর্বোচ্চ স্তরে পৌঁছেছে। মূল উপাদান সক্রিয় করা শিশু উপাদানগুলির জন্য একটি লেআউট পুনর্নির্মাণকে ট্রিগার করে, যার ফলস্বরূপ, ব্যাচিং এবং রেন্ডারিং উভয় ক্ষেত্রেই একটি উল্লেখযোগ্য লোড হয়৷ সুতরাং, অতিরিক্ত লোড তৈরি না করেই যদি আমাদের সম্পূর্ণ UI উপাদানগুলিকে সক্ষম বা নিষ্ক্রিয় করতে হয় তবে আমরা কী করতে পারি? GO নিজেই সক্রিয় এবং নিষ্ক্রিয় করার পরিবর্তে, আপনি কেবল ক্যানভাস বা ক্যানভাস গ্রুপ উপাদানটি নিষ্ক্রিয় করতে পারেন। অতিরিক্তভাবে, ক্যানভাস গ্রুপের আলফা চ্যানেলকে 0-তে সেট করা কর্মক্ষমতা সমস্যা এড়ানোর সময় একই প্রভাব অর্জন করতে পারে। যখন আমরা ক্যানভাস গ্রুপ কম্পোনেন্ট অক্ষম করি তখন লোডের কী হয় তা এখানে। যেহেতু ক্যানভাস নিষ্ক্রিয় থাকা অবস্থায় GO সক্রিয় থাকে, লেআউটটি সংরক্ষিত থাকে তবে কেবল প্রদর্শিত হয় না। এই পদ্ধতির ফলে শুধুমাত্র একটি কম লেআউট লোড হয় না বরং ব্যাচিং এবং রেন্ডারিংয়ের লোড উল্লেখযোগ্যভাবে কমে যায়। এর পরে, লেআউট গ্রুপের মধ্যে SiblingIndex পরিবর্তনের প্রভাব পরীক্ষা করা যাক। 8টি উপাদানের একটি লেআউট গ্রুপের মধ্যে SiblingIndex পরিবর্তন করা: যেমন পর্যবেক্ষণ করা হয়েছে, লেআউট আপডেট করার জন্য 0.7 ms-এ লোড উল্লেখযোগ্য থাকে। এটি স্পষ্টভাবে নির্দেশ করে যে SiblingIndex-এর পরিবর্তনগুলি একটি বিন্যাস পুনর্নির্মাণকেও ট্রিগার করে। এখন, একটি ভিন্ন পদ্ধতির সঙ্গে পরীক্ষা করা যাক. SiblingIndex পরিবর্তন করার পরিবর্তে, আমরা লেআউট গ্রুপের মধ্যে দুটি উপাদানের টেক্সচার অদলবদল করব। 8টি উপাদানের একটি লেআউট গ্রুপে দুটি উপাদানের টেক্সচার অদলবদল করা: আমরা দেখতে পাচ্ছি, পরিস্থিতির উন্নতি হয়নি; আসলে, এটা আরো খারাপ হয়েছে. টেক্সচার প্রতিস্থাপন একটি পুনর্নির্মাণও ট্রিগার করে। এখন, একটি কাস্টম লেআউট গ্রুপ তৈরি করা যাক। আমরা 8টি উপাদান তৈরি করব এবং কেবল তাদের দুটির অবস্থান অদলবদল করব। 8টি উপাদান সহ কাস্টম লেআউট গ্রুপ: লোড প্রকৃতপক্ষে উল্লেখযোগ্যভাবে হ্রাস পেয়েছে - এবং এটি প্রত্যাশিত। এই উদাহরণে, স্ক্রিপ্টটি কেবল দুটি উপাদানের অবস্থান অদলবদল করে, ভারী GetComponent ক্রিয়াকলাপগুলিকে দূর করে এবং সমস্ত উপাদানের অবস্থান পুনঃগণনা করার প্রয়োজন। ফলস্বরূপ, ব্যাচিংয়ের জন্য কম আপডেটের প্রয়োজন হয়। যদিও এই পদ্ধতিটি একটি রূপালী বুলেটের মতো মনে হচ্ছে, এটি মনে রাখা গুরুত্বপূর্ণ যে স্ক্রিপ্টগুলিতে গণনা সম্পাদনও সামগ্রিক লোডের জন্য অবদান রাখে। যেহেতু আমরা আমাদের লেআউট গোষ্ঠীতে আরও জটিলতা প্রবর্তন করি, লোড অনিবার্যভাবে বৃদ্ধি পাবে, কিন্তু এটি অগত্যা লেআউট বিভাগে প্রতিফলিত হবে না যেহেতু গণনাগুলি স্ক্রিপ্টগুলিতে ঘটে। সুতরাং, কোডের দক্ষতা নিজেরাই নিরীক্ষণ করা অত্যন্ত গুরুত্বপূর্ণ। যাইহোক, সাধারণ লেআউট গ্রুপগুলির জন্য, কাস্টম সমাধানগুলি একটি চমৎকার বিকল্প হতে পারে। উপসংহার লেআউট পুনর্নির্মাণ একটি উল্লেখযোগ্য চ্যালেঞ্জ উপস্থাপন করে। এই সমস্যাটি সমাধান করার জন্য, আমাদের অবশ্যই এর মূল কারণগুলি সনাক্ত করতে হবে, যা পরিবর্তিত হতে পারে। লেআউট পুনর্নির্মাণের দিকে পরিচালিত করে এমন প্রাথমিক কারণগুলি এখানে রয়েছে: উপাদানগুলির অ্যানিমেশন: আন্দোলন, স্কেল, ঘূর্ণন (রূপান্তরের যে কোনও পরিবর্তন) sprites প্রতিস্থাপন পাঠ্য পুনর্লিখন GO চালু এবং বন্ধ করা, GO যোগ/সরানো ভাইবোন সূচক পরিবর্তন কয়েকটি দিক হাইলাইট করা গুরুত্বপূর্ণ যেগুলি ইউনিটির নতুন সংস্করণগুলিতে আর সমস্যা তৈরি করে না কিন্তু যা আগের সংস্করণগুলিতে হয়েছিল: একই পাঠ্য ওভাররাইট করা এবং অ্যানিমেটরের সাথে বারবার একই মান সেট করা। এখন যেহেতু আমরা একটি লেআউট পুনর্নির্মাণকে ট্রিগার করে এমন কারণগুলি চিহ্নিত করেছি, আসুন আমাদের সমাধান বিকল্পগুলিকে সংক্ষিপ্ত করা যাক: এই পদ্ধতিটি পরিবর্তনগুলিকে বিচ্ছিন্ন করে, তাদের শ্রেণীবিন্যাসের অন্যান্য উপাদানগুলিকে প্রভাবিত করতে বাধা দেয়। যাইহোক, সতর্ক থাকুন — অনেকগুলি সাবক্যানভাস ব্যাচিংয়ের লোডকে উল্লেখযোগ্যভাবে বাড়িয়ে তুলতে পারে। একটি গেমঅবজেক্ট (GO) মোড়ানো যা একটি সাবক্যানভাসে পুনর্নির্মাণকে ট্রিগার করে। নতুন GO তৈরি করার পরিবর্তে একটি অবজেক্ট পুল ব্যবহার করুন। এই পদ্ধতিটি মেমরিতে বিন্যাস সংরক্ষণ করে, পুনর্নির্মাণের প্রয়োজন ছাড়াই উপাদানগুলির দ্রুত সক্রিয়করণের অনুমতি দেয়। GO এর পরিবর্তে SubCanvas বা Canvas Group চালু এবং বন্ধ করুন। শেডার ব্যবহার করে টেক্সচার পরিবর্তন করা একটি লেআউট পুনর্নির্মাণকে ট্রিগার করবে না। যাইহোক, মনে রাখবেন যে টেক্সচার অন্যান্য উপাদানের সাথে ওভারল্যাপ হতে পারে। এই পদ্ধতিটি কার্যকরভাবে সাবক্যানভাসেস ব্যবহার করার মতো একই উদ্দেশ্যে কাজ করে, তবে এটির জন্য একটি শেডার লেখার প্রয়োজন হয়। শেডার অ্যানিমেশন ব্যবহার করুন। ইউনিটির লেআউট গ্রুপগুলির একটি মূল সমস্যা হল যে প্রতিটি লেআউট এলিমেন্ট পুনর্নির্মাণের সময় GetComponent কল করে, যা সম্পদ-নিবিড়। একটি কাস্টম লেআউট গ্রুপ তৈরি করা এই সমস্যাটির সমাধান করতে পারে, তবে এর নিজস্ব চ্যালেঞ্জ রয়েছে। কাস্টম উপাদানগুলির নির্দিষ্ট অপারেশনাল প্রয়োজনীয়তা থাকতে পারে যা কার্যকর ব্যবহারের জন্য আপনাকে বুঝতে হবে। তবুও, এই পদ্ধতিটি আরও দক্ষ হতে পারে, বিশেষ করে সহজ লেআউট গ্রুপ পরিস্থিতিগুলির জন্য। ইউনিটির লেআউট গ্রুপকে একটি কাস্টম লেআউট গ্রুপ দিয়ে প্রতিস্থাপন করুন।
