سکهٔ پاداش برای بار دوم آماده هست؟
استخر آبجکت نمونه‌ها را برای استفادهٔ دوباره نگه می‌دارد، به‌جای ساختن و نابود کردن در هر نمایش کوتاه. یونیتی API استخر داره، اما قرارداد مهم بازنشانی هست. جلوهٔ پاداشِ دوباره‌استفاده‌شده باید جایگاه، نمایش و پاسخ درست داشته باشد.
تصور کن هر پاداش چند تصویر سکه از وسط صفحه به موجودی پرواز می‌دهد. ساخت و حذف مداوم اشیا می‌تواند هزینه داشته باشد؛ استخر چند نمونه را نگه می‌دارد تا دوباره به کار برگردند. اما نمونهٔ استفاده‌شده مثل نمونهٔ تازه نیست. ممکنه در انتهای مسیر قبلی، کوچک، نامرئی یا متصل به callback قبلی مانده باشد. برای هر جلوه بنویس هنگام گرفتن از استخر چه مقدارهایی باید آماده بشن و هنگام برگرداندن چه کارهایی باید متوقف بشن. بدون این قرارداد، استفادهٔ دوباره فقط راهی تازه برای انتقال خطاهای قدیمی هست.
پاک‌سازی پیش از استفادهٔ دوباره
یک جلوهٔ پاداش را چند بار در جای متفاوت استفاده کن. هر بار جایگاه، شفافیت، اندازه و پاسخ فعال را ببین. وسط حرکت برگردانید و دوباره بگیر. این ترتیب دشوار مسئولیت بازنشانی را می‌آزماید، نه فقط مسیر موفق. اگر استخر هزینهٔ اندازه‌گیری‌شده را حل نمی‌کنه، تا داشتن شاهد ارزش مدیریت اضافه، چرخهٔ ساده را نگه داری.
پاداش دوم را بلافاصله بعد از اولی اجرا کن و بعد یکی را در میانهٔ حرکت قطع کن. آیا سکه به جای درست برمی‌گردد؟ آیا تکمیل حرکت قبلی هنوز سکه یا امتیاز اضافه می‌کنه؟ دادن دوبارهٔ یک شیء که هنوز در استفاده هست هم باید در طراحی روشن باشد. APIهای استخر یونیتی بخشی از مدیریت مجموعه را آسان می‌کنند، اما پاک کردن listener، انیمیشن و دادهٔ مربوط به پاداش را به جای منطق تو نمی‌نویسند. رفتار دریافت و آزاد کردن باید با عمر واقعی جلوه هماهنگ باشد، به‌خصوص هنگام خروج از صفحه.
استخر را برای نیاز واقعی بساز
استخر نگه داشتن اشیا را نیز به حافظه تحمیل می‌کنه؛ اندازهٔ نامحدود راه‌حل خودکار نیست. تعداد هم‌زمان مورد نیاز را از رفتار واقعی پیدا کن و در حالت فشار ببین چه اتفاقی می‌افتد. برای یک پنجره که به‌ندرت باز می‌شود، پیچیدگی استخر شاید ارزش نداشته باشد. ابتدا یک جلوهٔ پرتکرار را اندازه بگیر و استفادهٔ دوباره را روی همان محدود کن. پایان تمرین باید هم هزینهٔ بهتر و هم رفتار سالم در بار دوم را نشان دهد. اگر فقط اجرای اول زیباست، قرارداد reset هنوز به اندازهٔ کافی روشن نشده.
مطالعهٔ بیشتر: Unity: Pooling and reusing objects
برای یک مثال مرتبط، زمان فریم؛ چرا میانگین سرعت کافی نیست؟ را هم بخون.
مثال عملی استخر آبجکت یونیتی
اگر بخواهی استخر آبجکت یونیتی را در یک پروژهٔ کوچک بررسی کنی، بهتر است از یک موقعیت محدود شروع کنی. چند نشان پاداش ساخته و دوباره استفاده می‌شوند، اما هر بار رنگ و متن تازه دارند. ورودی را ثابت نگه دار و نتیجهٔ مورد انتظار را پیش از اجرای نسخه بنویس. این کار کمک می‌کند تفاوت میان رفتار منطقی و چیزی که صرفاً روی صفحه دیده می‌شود روشن بماند. سناریوی این بخش آموزشی است و ادعای نتیجهٔ واقعی یک آزمایش روی کاربران دلو ندارد.
خطای رایج و علت آن
آبجکت بازاستفاده‌شده ممکن است callback یا وضعیت دفعهٔ قبل را نگه دارد. این خطا معمولاً وقتی پنهان می‌ماند که فقط مسیر موفق و ظاهر نهایی را ببینیم. برای پیدا کردن علت، آخرین وضعیت درست را از نخستین وضعیت نادرست جدا کن و ببین تغییر دقیقاً در کدام مرز رخ داده است. Pooling فقط وقتی مفید است که هزینهٔ ساخت و حذف واقعاً مسئلهٔ اندازه‌گیری‌شده باشد. اگر این تفاوت در قرارداد مشخص نباشد، اصلاح یک نشانه ممکن است همان مسئله را در بخش دیگری دوباره ایجاد کند.
چطور نتیجه را بررسی کنیم؟
پاک شدن وضعیت، آزاد شدن شنونده و محدودیت ظرفیت را بررسی کن. اجرای یک‌باره برای نتیجه‌گیری کافی نیست؛ یک بار مسیر معمول و بار دیگر همان موقعیت را با ورودی مرزی یا تکرار اقدام بررسی کن. اگر نتیجه فرق دارد، ورودی و شرایط اجرا را همراه خروجی نگه دار تا مقایسه قابل بازسازی باشد. جدول زیر خلاصهٔ مشخصات همین سناریو است و برای ثبت نتیجهٔ بررسی به کار می‌آید.
| بخش بررسی | آنچه باید ثبت شود |
|---|---|
| موقعیت آزمایشی | چند نشان پاداش ساخته و دوباره استفاده می‌شوند، اما هر بار رنگ و متن تازه دارند. |
| ریسک اصلی | آبجکت بازاستفاده‌شده ممکن است callback یا وضعیت دفعهٔ قبل را نگه دارد. |
| روش بررسی | پاک شدن وضعیت، آزاد شدن شنونده و محدودیت ظرفیت را بررسی کن. |
| مرز نتیجه‌گیری | Pooling فقط وقتی مفید است که هزینهٔ ساخت و حذف واقعاً مسئلهٔ اندازه‌گیری‌شده باشد. |
پرسش‌های کاربردی دربارهٔ استخر آبجکت یونیتی
از کجا شروع کنم؟
از همان موقعیت محدود این مطلب شروع کن: چند نشان پاداش ساخته و دوباره استفاده می‌شوند، اما هر بار رنگ و متن تازه دارند. ابتدا نتیجهٔ مورد انتظار را مشخص کن و بعد سراغ پیاده‌سازی یا ابزار برو. وقتی مسیر پایه قابل توضیح و بررسی شد، می‌توان حالت‌های بیشتری اضافه کرد. ساخت همهٔ حالت‌ها از ابتدا، فهم علت خطا را سخت‌تر می‌کند.
چه زمانی می‌توانم بگویم این بخش درست کار می‌کند؟
زمانی که رفتار در موقعیت تعریف‌شده با قرارداد سازگار باشد و محدودیت‌های آن روشن بمانند. پاک شدن وضعیت، آزاد شدن شنونده و محدودیت ظرفیت را بررسی کن. موفقیت در این آزمون دربارهٔ همان سناریو شاهد می‌دهد؛ از آن نمی‌توان بدون بررسی دربارهٔ همهٔ دستگاه‌ها، همهٔ قوانین محلی یا همهٔ حجم‌های داده نتیجه گرفت. Pooling فقط وقتی مفید است که هزینهٔ ساخت و حذف واقعاً مسئلهٔ اندازه‌گیری‌شده باشد.
برای ادامهٔ همین موضوع، نمونهٔ اولیهٔ بازی؛ چه چیزی را باید زود امتحان کنیم؟ را ببین. زمینهٔ ساخت این پروژه‌ها و معرفی سازنده در صفحهٔ کیان پاک نعمت آمده است.
