Content directories: Beyond the AssetBundle

Sep 22, 2026|6 Min
George Ing
George Ing - Unity Technologies
Senior Engineering Manager
Content directories in Unity 6.6

Trang web này đã được dịch bằng máy để thuận tiện cho bạn. Chúng tôi không thể đảm bảo tính chính xác hoặc độ tin cậy của nội dung được dịch. Nếu bạn có thắc mắc về tính chính xác của nội dung được dịch, vui lòng tham khảo phiên bản tiếng Anh chính thức của trang web.

Một chút về nội dung trong Unity ngày nay

Kể từ Unity 2.1, AssetBundle khiêm tốn đã hỗ trợ nội dung Unity được phân phối bên ngoài tệp nhị phân Player. Trong hai mươi năm qua, một số lượng trò chơi phi thường đã sử dụng AssetBundles làm phương thức biểu diễn dữ liệu, bao gồm cả một số tựa game lớn nhất trên thế giới.

Ở mức cơ bản, mỗi AssetBundle là một đơn vị không thể chia cắt để phân phối, lưu trữ và tải. Các AssetBundle theo dõi các phụ thuộc của chúng ở cấp độ gói, tạo thành một đơn vị nguyên khối lớn hơn mà, vì hiệu quả, cần được tải xuống, tải và dỡ tải cùng nhau.

Do thông số kỹ thuật này, cách một tiêu đề xác định bố cục AssetBundle là một yếu tố chính trong mọi thứ, từ hiệu suất thời gian chạy đến kích thước tải xuống của nó. Điều này đúng dù sử dụng AssetBundles trực tiếp hay thông qua gói Addressables.

Hôm nay, chúng ta sẽ nói về một điều khác đối với runtime của Unity.

Giới thiệu các thư mục nội dung

Các thư mục nội dung là sự thay thế cơ bản, hiệu suất cao hơn và chi tiết hơn cho AssetBundles. Chúng có sẵn hôm nay trong Unity 6.6 như một giải pháp thay thế cho AssetBundles được gửi kèm với Player. Trong quá trình tạo Unity 7, ngăn xếp công nghệ sẽ mở rộng để xử lý việc phân phối qua mạng không dây (OTA) đầy đủ và chi tiết (sẽ nói thêm về điều này sau - nó rất tuyệt).

Thay vì nướng các tài sản vào các đơn vị tải lớn, các thư mục nội dung cung cấp cho runtime của Unity khả năng tự xác định, tải và dỡ bỏ các tạo phẩm riêng lẻ(các lưới, kết cấu, v.v.) với sự bão hòa đầy đủ của tài nguyên phần cứng và loại bỏ trùng lặp nội dung ngầm định.

Sơ đồ cho thấy cách các tài sản của Unity được tải từ bộ nhớ cục bộ vào bộ nhớ làm việc. Ở bên trái, một bảng "Lưu trữ cục bộ" chứa chín biểu tượng tài nguyên Unity (các lưới 3D, bộ sưu tập sprite, tệp âm thanh và prefab). Một mũi tên có nhãn "Tải từng cái" chỉ sang phải đến một bảng "Bộ nhớ làm việc" chỉ chứa ba trong số các tài sản đó, với không gian trống bên dưới được dán nhãn "Sẵn có cho công việc khác." Bên dưới mũi tên, một phụ đề ghi "Tải → sử dụng → nhả."

Quản lý nội dung trong các dự án Unity giờ đây dễ dàng hơn bao giờ hết, với các bản dựng nhanh hơn và ít lo lắng hơn về việc đặt tài nguyên và bố cục AssetBundle.

Các trò chơi bạn xây dựng nhỏ hơn, nhanh hơn, tự động loại bỏ trùng lặp và có quyền truy cập vào quản lý bộ nhớ động đầy đủ thông qua một kiểu tham chiếu có thể tải. Đối với những người sử dụng Addressables cho nội dung được đóng gói với Player, bạn có thể chuyển sang thư mục nội dung mà không cần thay đổi mã zero-code.

Chúng ta đã làm điều này như thế nào? Hãy cùng xem bên trong từng giai đoạn của quy trình.

Một nền tảng quen thuộc: Build

Vào năm 2019, chúng tôi đã thảo luận về những gì chúng tôi muốn từ một nền tảng xây dựng nghiêm túc trong Unity - song song trên mọi lõi, xác định, được lưu vào bộ nhớ đệm hoàn toàn và có khả năng chia sẻ dữ liệu xây dựng giữa các máy. Hóa ra một số đồng nghiệp của chúng tôi đã cung cấp một API với chính những thuộc tính đó trong nhiều năm, khuôn khổ nhập tài nguyên.

Vì vậy, quy trình xây dựng thư mục nội dung chạy trong khuôn khổ nhập tài nguyên tiêu chuẩn. Mỗi tài nguyên được xây dựng riêng lẻ bởi một trình nhập tài nguyên, được cô lập và chạy ngoài tiến trình. Các bản dựng là xác định, với bộ nhớ đệm cơ sở dữ liệu tài nguyên, bão hòa hoàn toàn tất cả các lõi phần cứng và hỗ trợ bộ tăng tốc gốc cho các bản dựng chia sẻ nhanh.

Đây có thể không phải là lần đầu tiên bạn nghe về hệ thống xây dựng này. Một số bạn có thể nhớ về quy trình xây dựng đa tiến trình mà chúng tôi đã nhá hàng trong Unity 2023.1. Đây là cùng một nền tảng.

Sơ đồ cho thấy cách các tệp nguồn được chuyển đổi thành tài sản Unity thông qua Build Importer. Hai tệp FBX mỗi tệp tạo ra hai đối tượng AssetBundle (hiển thị dưới dạng biểu tượng gói màu xanh lam và xám), trong khi hai tệp PNG mỗi tệp tạo ra một tài nguyên sprite/texture (hiển thị dưới dạng biểu tượng ô vuông bàn cờ). Các mũi tên phân nhánh từ các tệp FBX minh họa rằng một tệp nguồn 3D duy nhất có thể tạo ra nhiều tài sản thời gian chạy.

Đầu ra là một nhóm các tạo phẩm rất chi tiết, một bản kê khai nhỏ theo dõi các phụ thuộc giữa chúng và một bộ tệp chẩn đoán mới để giúp bạn hiểu quá trình xây dựng của mình dễ dàng hơn bao giờ hết.

Nó cực kỳ đơn giản.

Một nền tảng quen thuộc: Addressing

Nếu bạn mở thư mục nội dung build và xem các artifact, bạn sẽ nhận thấy rằng mỗi artifact có một tên được băm khá lạ:

c0152db4dd710be51b2decb997325f34.cf
f0a44ad4a4babd121543fd44032928e7.resS
4226b5c16a50dab6eff0f08dd1253d4b.resource

Đây là điều hay ho - đó không phải là một mã băm ngẫu nhiên. Thay vào đó, hệ thống thư mục nội dung sử dụng mô hình lưu trữ được địa chỉ nội dung giống như các công nghệ như Git. Mỗi tệp nội dung được đặt tên và tham chiếu bằng một hàm băm của nội dung của nó. Mô hình này cực kỳ hữu ích cho thời gian chạy Unity vì nó cho phép nó tự động loại bỏ trùng lặp nội dung như một tính năng gốc.

Nói như vậy, lưu trữ được địa chỉ nội dung với một đồ thị phụ thuộc thực sự có nguy cơ thay đổi cao. Hãy xem xét mối quan hệ đơn giản nhất có thể giữa hai tạo tác:

A → B

Cập nhật B và các thay đổi hash của B. Thật không may, vì A tham chiếu đến B, hash của A cũng thay đổi. Tệ hơn nữa, điều đó lan truyền thẳng lên chuỗi.

Thay vào đó, các tạo tác không tham chiếu lẫn nhau bằng mã băm nội dung, chúng tham chiếu thông qua ID ổn định. Tệp kê khai bản dựng giữ một bảng tra cứu nhỏ ánh xạ các ID ổn định với các giá trị băm nội dung.

Với điều này, thời gian chạy có mọi thứ nó cần để tải!

Một nền tảng quen thuộc: Load

Trong các thư mục nội dung, chúng tôi giới thiệu một hệ thống tải động cực kỳ hiệu suất.

Khi một thư mục nội dung được gắn kết, hệ thống tải sẽ đọc manifest và giải quyết các phụ thuộc id ổn định giữa các tạo phẩm. Nó cho phép mỗi tạo phẩm được tải và dỡ tải hoàn toàn độc lập, với không có sự ô nhiễm nào từ các tạo phẩm cùng vị trí (nhớ vấn đề với AssetBundles - một đơn vị nguyên khối, không thể chia cắt?). Gone.)

Đối với người dùng DOTS, định dạng tệp cơ bản của các tạo phẩm cũng có thể trông khá quen thuộc. Các thư mục nội dung tạo và tải định dạng tệp nội dung thế hệ tiếp theo mà chúng tôi đã giới thiệu trong DOTS vào năm 2022, mang công nghệ đã cung cấp việc tải Entities đa luồng trong bốn năm cho tất cả các tài sản.

Đây là một hệ thống tải hoàn toàn bất đồng bộ đối với cả các thao tác đọc và giải tuần tự. Điều này có nghĩa là băng thông tải cao hơn và việc sử dụng các API đọc bất đồng bộ cụ thể của nền tảng.

Sơ đồ so sánh hai quy trình tải tài nguyên Unity. Phần trên cùng, được dán nhãn "AssetBundles," hiển thị một tệp tuần tự được xử lý tuần tự: mỗi tài nguyên được Đọc sau đó Giải tuần tự từng cái một trước bước Awake cuối cùng, với việc tải lên GPU chỉ xảy ra ở cuối. Cái này được dán nhãn "Tuần tự". Phần dưới, được dán nhãn "Các thư mục nội dung", hiển thị một tệp nội dung sử dụng quy trình xử lý theo kiểu jobified: tất cả các tài nguyên được đọc song song trước, sau đó các bước Deserialize và Awake của từng tài nguyên được sắp xếp và chồng lấn, với việc tải lên GPU được phân phối xuyên suốt. Cái này được dán nhãn "Jobified," minh họa lợi thế về hiệu suất của việc tải song song so với phương pháp AssetBundle tuần tự.

Thậm chí còn thú vị hơn, thư mục nội dung foundation cho phép chúng ta mang một kiểu tham chiếu có thể tải hiện đại vào Unity lần đầu tiên, được gọi là Loadable.

bodyMesh có thể tải được;
bodyMesh.Load();

Đây là một tham chiếu có thể tải thực sự, được tích hợp trực tiếp vào engine cho các dự án dựa trên thư mục nội dung. Các đối tượng được tham chiếu bởi Loadable sẽ được kéo vào bản dựng, nhưng sẽ không được tải cho đến khi bạn gọi Loadable. Việc ghép nối các Loadable với giao diện ScriptableObject (rất) quen thuộc cho phép bạn tổ chức nội dung được tải động cực kỳ nhanh chóng.

Đó là một nguyên tắc mà chúng tôi rất hào hứng. Với các thư mục nội dung và Loadables làm nền tảng, bất kỳ tài nguyên nào trong Unity cũng có thể trở thành một đơn vị được tải và dỡ tải độc lập - một khả năng được tích hợp trực tiếp vào engine - từ các thành phần của trình tạo nhân vật cho đến các khối của địa hình được truyền phát, mà không cần các bố cục AssetBundle hay định nghĩa nhóm để thiết kế xung quanh.

Xây dựng trò chơi quy mô lớn trong Unity chưa bao giờ dễ dàng hơn!

Đưa các thư mục nội dung vào thử nghiệm: Slime Rancher 2

Trong vài tháng qua, một vài đối tác của chúng tôi đã tốt bụng cho phép chúng tôi thử nghiệm các thư mục nội dung với các trò chơi của họ.

Ví dụ, hãy xem trò chơi tuyệt vời Slime Rancher 2 của Monomi Park và một số lợi ích mà nó nhận được từ việc chuyển sang các thư mục nội dung. (Slime Rancher có mặt trên Steam!) Slime Rancher, Slime Rancher 2)

<1>Addressables (backend AssetBundle)Addressables (thư mục nội dung backend)
Thời gian xây dựng tăng dần
32 phút, 16 giây
3 phút, 4 giây
Thời gian xây dựng sạch
58 phút, 6 giây
37 phút, 13 giây
Kích thước bản dựng người chơi
4GB
2.88GB
Thời gian tải (khởi động trò chơi -> menu -> lối chơi)
45 giây
30 giây

Dữ liệu này dựa trên Unity Editor Phiên bản Unity 6.6 Beta (6000.6.0b10) chạy trên MacBook Pro (M5 Max)

Điều tuyệt vời là lợi ích của hệ thống tải mới được người dùng nhìn thấy ngay lập tức. Điều tuyệt vời hơn nữa là Slime Rancher 2 là một dự án Addressables hiện có đã chuyển sang thư mục nội dung mà không cần thay đổi mã.

Chúng tôi thành thật không thể chờ đợi để xem các trò chơi trong hệ sinh thái Unity sẽ đạt được gì với việc phát hành các thư mục nội dung trong 6.6. Nhưng điều đó đặt ra một câu hỏi, còn nội dung từ xa thì sao?

Tiếp theo là gì: phân phối nội dung từ xa

Những ai tham dự Buổi Trình bày Lộ trình Unite Seoul năm nay có thể nhớ Jason Mann đã nhá hàng rằng nền tảng thư mục nội dung mới của chúng ta sẽ giúp việc phân phối nội dung từ xa dễ dàng hơn nhiều trong quá trình phát triển Unity 7 sắp tới. Hãy nói sơ qua về ý nghĩa thực sự của điều đó, và nó phù hợp với những phần chúng ta đã thảo luận cho đến nay như thế nào.

Tóm lại, với các thư mục nội dung, chúng ta có một bản kê khai nhỏ được điều khiển bằng hash có khả năng xác định duy nhất các tạo phẩm và các phụ thuộc của chúng. Câu hỏi là, tất cả những tạo tác đó có phải được gửi cùng với Người chơi không?

Câu trả lời là một sự từ chối dứt khoát.

Sơ đồ cho thấy một đám mây chứa nhiều biểu tượng khối vuông nhỏ màu xanh lá cây được dán nhãn "Dữ liệu hạt", với nhiều mũi tên đứt nét màu xanh lam (dán nhãn "Yêu cầu nội dung") chảy xuống từ đám mây vào một thiết bị di động ở phía dưới. Các mũi tên hội tụ vào màn hình thiết bị, minh họa rằng một thiết bị duy nhất thực hiện nhiều yêu cầu mạng riêng lẻ để tải xuống các tài sản chi tiết từ đám mây.

Nhờ các tiêu chuẩn HTTP hiện đại, Unity giờ đây có thể đa luồng các khối lượng lớn yêu cầu tài nguyên.

Kết hợp điều đó với nền tảng thư mục nội dung, và thời gian chạy có thể xác định chính xác các tệp tài sản nào mà thiết bị đang thiếu, tải xuống chỉ những tệp đó vào bộ nhớ cục bộ và tải chúng - mà không cần lo lắng về vị trí chung, bố cục dữ liệu hoặc các AssetBundle phụ thuộc. Các bản cập nhật lan truyền ở cấp độ tạo phẩm riêng lẻ, và vì manifest hoạt động bằng cách sử dụng các hàm băm nội dung, thời gian chạy có thể rẻ tiền xác định các tạo phẩm nào đã lỗi thời và chỉ tải xuống sự khác biệt.

Runtime Unity gần tương lai này chỉ tải nội dung nó cần, cắt giảm thời gian phát triển, đưa người chơi vào game nhanh hơn và giảm chi phí CDN.

Chúng tôi sẽ chia sẻ thêm về dự án này vào năm 2027.

Hãy thử các thư mục nội dung trong Unity 6.6 ngay hôm nay

Những gì chúng ta chia sẻ hôm nay là giai đoạn đầu tiên của một hành trình dài để cải tổ nội dung trong Unity, mang lại "hiệu suất mặc định" trên thời gian chạy. Các thư mục nội dung có sẵn trong 6.6 cho nội dung được gửi cùng với Player, và sẽ mở rộng để xử lý nội dung từ xa trong thế hệ Unity 7.

Để bắt đầu với các thư mục nội dung, hãy xem tài liệu của chúng tôi, và nếu bạn có phản hồi, thì vui lòng liên hệ.

Cảm ơn lại những người bạn của chúng tôi tại Monomi Park đã giúp chúng tôi giới thiệu các thư mục nội dung với tiêu đề tuyệt vời của họ! (Slime Rancher, Slime Rancher 2).