با بزرگ شدن پروژه Unity، بارگذاری مستقیم همه Textureها، Prefabها و صحنهها زمان شروع و مصرف حافظه را افزایش میدهد. Resources نیز در پروژههای پیچیده کنترل محدودی روی بستهبندی و وابستگیها دارد. Addressables برای سازماندهی، ساخت و بارگذاری داراییها با یک آدرس منطقی طراحی شده است.
یکی از جذابترین قابلیتها، میزبانی بخشی از محتوا روی سرور یا CDN است. بازی میتواند Catalog جدید را بررسی و Bundleهای لازم را دریافت کند. البته هر تغییری بدون انتشار نسخه جدید ممکن نیست؛ تغییر کد یا ساختار ناسازگار همچنان به Build تازه نیاز دارد.
Addressables در Unity چیست و چگونه کار میکند؟
Addressables در Unity سیستمی برای تعیین آدرس دارایی، مدیریت وابستگی و بارگذاری ناهمگام است. توسعهدهنده Asset را Addressable میکند، آن را در Group قرار میدهد و تنظیمات Build و Load Path را مشخص میسازد. سیستم در زمان Build محتوا را در Bundleها و Catalog سازماندهی میکند.
کد بهجای مسیر مستقیم فایل، از Address یا Label استفاده میکند. Unity محل واقعی دارایی و وابستگیهای آن را پیدا میکند، عملیات دانلود یا بارگذاری را انجام میدهد و یک Handle بازمیگرداند. پس از پایان استفاده باید Handle آزاد شود تا حافظه و Reference Count درست مدیریت شوند.
Local Content و Remote Content
محتوای Local همراه Build اصلی نصب میشود و برای اجرای اولیه یا فایلهای ضروری مناسب است. محتوای Remote روی فضای میزبانی یا CDN قرار میگیرد و هنگام نیاز دانلود میشود. تقسیم درست باعث کاهش حجم نصب اولیه میشود، ولی نباید شروع بازی را به دانلود سنگین وابسته کند.
صفحه ورود، فونت ضروری و رابط خطا بهتر است محلی باشند. مراحل اضافی، رویدادهای فصلی یا بستههای صوتی میتوانند Remote باشند. اگر اینترنت قطع باشد، بازی باید پیام روشن، Retry و در صورت امکان حالت آفلاین ارائه کند.
Catalog و Content Update
Catalog نگاشت آدرسها به محل Bundle و وابستگیها را نگه میدارد. در شروع یا زمان مناسب، برنامه میتواند وجود Catalog جدید را بررسی کند. پس از تأیید کاربر یا سیاست محصول، وابستگیهای مورد نیاز دانلود میشوند و نسخه کششده در دفعات بعد استفاده خواهد شد.
برای Content Update باید وضعیت Build قبلی حفظ شود و فرایند بهروزرسانی بر اساس همان نسخه انجام گیرد. حذف فایلهای state یا ساخت نامنظم میتواند Bundleهای غیرضروری جدید تولید کند. Pipeline تولید محتوا باید نسخهبندی و در CI قابل تکرار باشد.
چه چیزهایی بدون انتشار نسخه جدید تغییر میکنند؟
داراییهایی مانند Texture، Audio، Prefab و ScriptableObject در شرایط مناسب قابل بهروزرسانی هستند. اما اگر Prefab جدید به کلاسی نیاز داشته باشد که در کد نصبشده وجود ندارد، دانلود محتوا مشکل را حل نمیکند. کد C# کامپایلشده معمولاً بخشی از Build برنامه است.
بنابراین قرارداد میان کد و محتوا باید پایدار باشد. میتوان رفتارهای عمومی را از قبل در Build قرار داد و مقادیر یا ترکیب محتوا را از راه دور تغییر داد. برای تغییر منطق بنیادی، نسخه تازه اپلیکیشن و مدیریت سازگاری کاربران قدیمی لازم است.
طراحی Group و Bundle
قرار دادن همه داراییها در یک Bundle باعث میشود تغییر کوچک دانلود بزرگی ایجاد کند. شکستن بیش از حد نیز تعداد درخواستها و سربار Catalog را بالا میبرد. گروهبندی باید بر اساس زمان استفاده، نرخ تغییر، وابستگی مشترک و اندازه فایل انجام شود.
برای مثال محتوای هر فصل میتواند گروه جدا داشته باشد و داراییهای مشترک در Bundle پایدار قرار گیرند. گزینه Pack Together، Pack Separately یا Pack Together By Label بر اندازه و تعداد Bundleها اثر دارد. Build Layout برای مشاهده وابستگی تکراری و اندازه نهایی مفید است.
دانلود و تجربه کاربر
پیش از دانلود میتوان حجم وابستگیها را محاسبه کرد و از کاربر اجازه گرفت. Progress باید واقعی باشد و وضعیتهایی مانند انتظار، توقف و خطا را نشان دهد. دانلود حجیم روی اینترنت موبایل بدون اطلاع کاربر تجربه نامناسب و هزینه ناخواسته ایجاد میکند.
دانلود در پسزمینه باید با محدودیت پلتفرم سازگار باشد. در زمان قطع ارتباط، Retry با فاصله افزایشی بهتر از درخواست پیوسته است. Hash و Catalog تضمین میکنند نسخه درست دریافت شود، اما امنیت میزبانی و دسترسی نوشتن به CDN نیز باید محافظت شود.
مدیریت حافظه
هر بار Load یک Reference ایجاد میکند و Release آن را کاهش میدهد. آزاد کردن زودهنگام میتواند دارایی در حال استفاده را از دسترس خارج کند و فراموش کردن Release باعث رشد حافظه شود. مالکیت Handle باید در معماری مشخص باشد، بهخصوص برای صحنهها و Prefabهای ایجادشده.
Unload صحنه، نابود کردن GameObject و آزاد کردن Asset مفاهیم مرتبط اما یکسان نیستند. تست طولانیمدت روی موبایل میتواند نشتی تدریجی را آشکار کند. Profiler و Event Viewer برای مشاهده عملیات و وابستگیها به کار میروند.
نسخهگذاری و بازگشت
هر انتشار محتوا باید شناسه نسخه و Backup داشته باشد. اگر Bundle خراب منتشر شود، تیم باید بتواند Catalog سالم قبلی را بازیابی کند. بهتر است محتوا ابتدا روی محیط Staging آزمایش و سپس بهتدریج برای درصدی از کاربران فعال شود.
کش CDN ممکن است فایل قبلی را نگه دارد، بنابراین نام فایل مبتنی بر Hash و Headerهای درست اهمیت دارند. حذف فوری Bundle قدیمی نیز خطرناک است، زیرا کاربران نسخه قبلی هنوز ممکن است به آن نیاز داشته باشند. سیاست نگهداری باید با نسخههای پشتیبانیشده هماهنگ شود.
اشتباهات رایج
- Addressable کردن دارایی بدون طراحی Group
- قرار دادن محتوای ضروری شروع بازی روی Remote
- نادیده گرفتن وابستگی تکراری میان Bundleها
- فراموش کردن Release برای Handleها
- از دست دادن فایل state مربوط به Build قبلی
- آزمایش نکردن دانلود ناقص و حالت بدون اینترنت
مراحل اجرای اصولی
- تهیه فهرست محتوا و الگوی مصرف آن
- تقسیم Local و Remote بر اساس نیاز واقعی
- طراحی Group، Label و پروفایل محیطها
- ساخت رابط دانلود و مدیریت خطا
- بررسی Build Layout، حافظه و حجم Patch
- راهاندازی Staging، CDN و فرآیند Rollback
پیادهسازی پایه ممکن است سریع باشد، اما مهاجرت پروژه بزرگ و طراحی بهروزرسانی امن به تحلیل بیشتری نیاز دارد. در JPGames ساختار Addressables بر اساس پلتفرم، اندازه محتوا و چرخه LiveOps طراحی میشود. برای بررسی پروژه میتوان گزارش Build، ساختار فعلی Assetها و نیاز دانلود را ارائه کرد.