Chuyển sang Addressables: đừng chỉ thay Resources.Load
Minh Khoa
Tác giả
Dự án ban đầu có vài prefab, bỏ vào Resources rồi load là chạy. Sau này thêm skin, map, event… bộ cài lớn dần, muốn cập nhật một ít nội dung cũng phải phát hành bản game mới.
Đó thường là lúc mình nghĩ tới Addressables.
Nhưng nếu chỉ thay Resources.Load bằng Addressables.LoadAssetAsync, rồi ép chờ kết quả bằng WaitForCompletion(), thì phần khó nhất vẫn chưa được giải quyết.
1. Mỗi cách load giải quyết một bài toán
Resources tiện vì ít phải thiết lập. Đổi lại, asset trong thư mục này được đưa vào Player build dù không có nơi nào tham chiếu. Khi chứa quá nhiều object, dữ liệu chỉ mục cũng làm tăng chi phí khởi động. Resources không có sẵn cơ chế cập nhật nội dung từ server. Unity — Resources.
Một điểm cần nói rõ: Resources có LoadAsync, không phải chỉ nạp đồng bộ. Giới hạn lớn của nó nằm ở cách đóng gói và phân phối nội dung. Resources.LoadAsync.
AssetBundle cho phép tách nội dung khỏi bộ cài, đặt ở local hoặc tải từ xa. Nhưng mình phải quản lý dependency và thời điểm unload.
Ví dụ prefab trong bundle A dùng material ở bundle B: cần bảo đảm B đã được nạp trước khi load asset cần nó. Không bắt buộc phải mở các bundle theo một thứ tự cố định. Unity — Dependencies.
Ngay cả unload cũng cần hiểu đúng: Unload(false) giữ lại asset đã load, không làm mất reference đang dùng ngay lập tức. Nhưng load lại bundle có thể tạo bản sao tài nguyên. Còn Unload(true) có thể phá những object vẫn đang sử dụng asset đó. Unity — AssetBundle loading.
2. Addressables giúp quản lý, không tự quyết định thay mình
Với quy trình dùng AssetBundle, Addressables đứng phía trên để quản lý địa chỉ, dependency và reference count.
Code yêu cầu một asset qua Address hoặc AssetReference. Catalog giúp hệ thống biết cần lấy nội dung ở đâu; mình không phải tự lần theo từng bundle phụ thuộc. Unity — Addressables.
Nhưng vẫn phải quyết định:
-
Asset nào cần có ngay, asset nào tải sau?