فایل کوچک لزوماً حافظهٔ کم نیست
تصویر، صدا و آبجکت اجرایی حافظه می‌گیرندد، حتی اگر فایل روی دیسک کوچک دیده بشه. میز موبایلی بودجهٔ بصری متناسب با دستگاه هدف می‌خواهد. نخست دارایی‌های حاضر در دست معمولی و دارایی‌های مخصوص صفحهٔ اختیاری را بررسی کن.
یک تصویر پس‌زمینه ممکنه روی دیسک حجم کمی داشته باشد، اما هزینهٔ آن هنگام استفاده به شکل وارد شدن و تنظیمات دارایی نیز مربوط هست. برای میز موبایل، ابتدا تصاویر روی کارت، پشت کارت، پس‌زمینه و پیش‌نمایش‌های فروشگاه را فهرست کن. بپرس کدام‌ها در دست عادی واقعاً لازم‌اند و کدوم فقط در صفحهٔ اختیاری استفاده می‌شوند. این پرسش پیش از پایین آوردن کورکورانهٔ کیفیت کمک می‌کنه علت هزینه را بفهمی. هدف این نیست که همه چیز را کوچک کنی؛ اطلاعات قابل خواندن کارت‌ها باید در اندازهٔ واقعی حفظ بشه.
آنچه هنگام دست در حافظه هست
دارایی حاضر هنگام دست معمولی را فهرست کن. روی کارت را از پیش‌نمایش اختیاری فروشگاه و گونه‌های پس‌زمینه جدا کن. حافظهٔ دستگاه هدف را ببین و یک دارایی پرهزینه را عمدی کاهش دهید. دست را در اندازهٔ واقعی نمایش مقایسه کن. سؤال حفظ اطلاعات لازم هست، نه فقط کوچک شدن خوشایند درصد فایل واردشده.
برای مقایسه یک دارایی پرهزینه را انتخاب کن، تنظیم آن را در یک نسخه تغییر بده و همان دست را روی دستگاه هدف ببین. حجم فایل خروجی، حافظهٔ گزارش‌شده و کیفیت دیداری سه چیز متفاوت‌اند. اگر حروف رتبه یا نماد خال نرم و مبهم شدند، فقط کم شدن عدد کافی نیست. همچنین فروشگاه را باز کن و برگرد؛ ببین مصرف در این رفت‌وبرگشت چگونه تغییر می‌کنه. از روی نام پوشه نمی‌توان فهمید چه دارایی در حافظه مانده هست. ابزار اندازه‌گیری لازم هست تا حدس دربارهٔ بارگذاری با آنچه واقعاً رخ داده مقایسه بشه.
کاهش اندازه بدون حذف اطلاعات
بودجه را با محدودهٔ دستگاه‌های مورد نظر بنویس، نه عددی که از پروژهٔ دیگری شنیده‌ای. برای نمونهٔ اولیه می‌توانی محدودیت ساده‌ای بگذاری و بعد با دادهٔ واقعی اصلاحش کنی. هر تصمیم کاهش کیفیت را با دلیل نگه دار: این تصویر کوچک‌تر شد چون در این اندازه تفاوتش دیده نشد، نه چون هر تصویر بزرگ بد هست. اگر پیش‌نمایش فروشگاه نیاز دیگری داره، همان را جدا بررسی کن. چنین یادداشتی به طراح و برنامه‌نویس کمک می‌کنه دربارهٔ یک هزینهٔ مشخص حرف بزنند و کیفیت لازم برای بازی را قربانی درصدهای مبهم نکنند.
مطالعهٔ بیشتر: Unity: Profiler Unity: Asset workflow
برای یک مثال مرتبط، استخر آبجکت؛ استفادهٔ دوباره با مسئولیت روشن را هم بخون.
مثال عملی بودجهٔ حافظهٔ بازی
یک روش کاربردی برای بررسی بودجهٔ حافظهٔ بازی این است که به جای چند تغییر هم‌زمان، تنها یک مسیر کوتاه بسازی. چند اسکین کارت و پس‌زمینه هم‌زمان بارگذاری می‌شوند و مصرف حافظه بالا می‌رود. سپس وضعیت قبل و بعد را کنار هم قرار بده. چه بخشی از داده تغییر کرده و کدام بخش فقط ظاهر تازه‌ای پیدا کرده است؟ پاسخ باید از همان تعریف موضوع بیاید. این موقعیت یک مثال آموزشی است و آمار واقعی محصول یا وعدهٔ قابلیت جدید محسوب نمی‌شود.
خطای رایج و علت آن
حجم فایل فشرده روی دیسک با حافظهٔ بافت و مصرف زمان اجرا برابر نیست. این خطا معمولاً وقتی پنهان می‌ماند که فقط مسیر موفق و ظاهر نهایی را ببینیم. برای پیدا کردن علت، آخرین وضعیت درست را از نخستین وضعیت نادرست جدا کن و ببین تغییر دقیقاً در کدام مرز رخ داده است. کاهش کیفیت باید با خوانایی کارت و خطای بصری مقایسه شود. اگر این تفاوت در قرارداد مشخص نباشد، اصلاح یک نشانه ممکن است همان مسئله را در بخش دیگری دوباره ایجاد کند.
چطور نتیجه را بررسی کنیم؟
اندازهٔ بافت، قالب فشرده‌سازی و طول عمر دارایی را روی دستگاه هدف بررسی کن. اجرای یک‌باره برای نتیجه‌گیری کافی نیست؛ یک بار مسیر معمول و بار دیگر همان موقعیت را با ورودی مرزی یا تکرار اقدام بررسی کن. اگر نتیجه فرق دارد، ورودی و شرایط اجرا را همراه خروجی نگه دار تا مقایسه قابل بازسازی باشد. جدول زیر خلاصهٔ مشخصات همین سناریو است و برای ثبت نتیجهٔ بررسی به کار می‌آید.
| بخش بررسی | آنچه باید ثبت شود |
|---|---|
| موقعیت آزمایشی | چند اسکین کارت و پس‌زمینه هم‌زمان بارگذاری می‌شوند و مصرف حافظه بالا می‌رود. |
| ریسک اصلی | حجم فایل فشرده روی دیسک با حافظهٔ بافت و مصرف زمان اجرا برابر نیست. |
| روش بررسی | اندازهٔ بافت، قالب فشرده‌سازی و طول عمر دارایی را روی دستگاه هدف بررسی کن. |
| مرز نتیجه‌گیری | کاهش کیفیت باید با خوانایی کارت و خطای بصری مقایسه شود. |
پرسش‌های کاربردی دربارهٔ بودجهٔ حافظهٔ بازی
از کجا شروع کنم؟
از همان موقعیت محدود این مطلب شروع کن: چند اسکین کارت و پس‌زمینه هم‌زمان بارگذاری می‌شوند و مصرف حافظه بالا می‌رود. ابتدا نتیجهٔ مورد انتظار را مشخص کن و بعد سراغ پیاده‌سازی یا ابزار برو. وقتی مسیر پایه قابل توضیح و بررسی شد، می‌توان حالت‌های بیشتری اضافه کرد. ساخت همهٔ حالت‌ها از ابتدا، فهم علت خطا را سخت‌تر می‌کند.
چه زمانی می‌توانم بگویم این بخش درست کار می‌کند؟
زمانی که رفتار در موقعیت تعریف‌شده با قرارداد سازگار باشد و محدودیت‌های آن روشن بمانند. اندازهٔ بافت، قالب فشرده‌سازی و طول عمر دارایی را روی دستگاه هدف بررسی کن. موفقیت در این آزمون دربارهٔ همان سناریو شاهد می‌دهد؛ از آن نمی‌توان بدون بررسی دربارهٔ همهٔ دستگاه‌ها، همهٔ قوانین محلی یا همهٔ حجم‌های داده نتیجه گرفت. کاهش کیفیت باید با خوانایی کارت و خطای بصری مقایسه شود.
برای ادامهٔ همین موضوع، نمونهٔ اولیهٔ بازی؛ چه چیزی را باید زود امتحان کنیم؟ را ببین. زمینهٔ ساخت این پروژه‌ها و معرفی سازنده در صفحهٔ کیان پاک نعمت آمده است.
جزئیات ابزار ثبت عملکرد در راهنمای رسمی Profiler یونیتی ۶ آمده است. قابلیت‌های نسخهٔ مورد استفاده و دستگاه هدف را هنگام اجرای آزمایش جدا بررسی کن.
