Tăng Hiệu Suất

Trang này mô tả các vấn đề hiệu suất thông thường và tốt nhất để giải quyết chúng.

Tính toán kịch bản

Các hoạt động đắt tiền trong mã Lua mất nhiều thời gian hơn để xử lý và do đó có thể ảnh hưởng đến tỷ lệ khung hình. Ngay cả khi nó được thi hành song song, mã Lua vẫn chạy song song và khối chủ đề chính cho đến khi nó gặp một chức năng tạo ra chủ đề.

Những vấn đề thông thường

• Các hoạt động chủ động trên cấu trúc bảng - Các hoạt động phức tạp như serialization, deserialization và deep cloning có chi phí hiệu suất cao, đặc biệt là trên các cấu trúc bảng lớn. Điều này đặc biệt đúng nếu các hoạt động này là recursive hoặc liên quan đến itereating trên các cấu trúc d

• Sự kiện频率 cao - Kết nối các hoạt động đắt tiền với các sự kiện RunService để không giới hạn thời gian thực hiện các hoạt động này, dẫn đến một lượng thời gian thực hiện không cần thiết. Các sự kiện này bao gồm:

  • RunService.PreAnimation
  • RunService.PreRender
  • RunService.PreSimulation
  • RunService.PostSimulation
  • RunService.Heartbeat

Giải pháp

• Gọi mã ở RunService sự kiện, tối ưu hóa sử dụng cho các trường hợp sử dụng cao tần (ví dụ, cập nhật máy ảnh). Bạn có thể thi hành hầu hết mã khác trong các sự kiện khác hoặc ít thường xuyên hơn trong một chuỗi.
• Phân tách các nhiệm vụ lớn hoặc đắt tiền bằng cách sử dụng task.wait() để phân tán công việc trên nhiều khung.
• Xác định và tối ưu hóa các hoạt động không cần thiết và sử dụng multithreading cho các nhiệm vụ tính toán có giá trị cao mà không cần phải truy cập vào mô hình dữ liệu.
• Một số trang bị phía máy chủ có thể hưởng lợi từ 生成机器代码, một biểu tượng đơn giản là máy chủ tổ hợp một script thành một mã máy chủ chứ không phải là một mã máy chủ.

Bộ lọc MicroProfiler

Để biết thêm thông tin về việc débog script bằng MicroProfiler, hãy xem thư viện debug, bao gồm các chức năng cho việc gắn nhãn các mã cụ thể và tăng độ chính xác, chẳng hạn như Library. debug.profileben

Sử dụng bộ nhớ

Lỗi bộ nhớ có thể xảy ra khi bạn viết các script sử dụng bộ nhớ mà thu thập rác không thể phát hành một cách hợp lý khi nó không còn được sử dụng. Lỗi là phổ biến đặc biệt trên máy chủ, vì chúng có thể liên tục trực tuyến trong nhiều ngày, trong khi một phiên đăng nhập khách hàng là rấ

Các giá trị bộ nhớ được đề cập ở dưới đây trong Developer Console có thể cho thấy một vấn đề cần thêm điều tra:

• LuaHeap - Thời gian tiêu thụ cao hơn hoặc tăng trưởng có thể cho thấy một rò rỉ bộ nhớ.
• InstCount - Tăng đếm số lần lượt các instanti đều có thể cho thấy một số instanti trong mã của bạn không được thu thập rác.
• PlaceScriptMemory - Cung cấp một script bằng cách phân tích sử dụng bộ nhớ.

Những vấn đề thông thường

• Rời kết nối đã kết nối - Động cơ không bao giờ thu thập sự kiện kết nối đến một instan và bất kỳ giá trị nào được tham chiếu trong hàm chuỗi kết nối. Do đó, các kết nối chủ động của các sự kiện và mã trong các instan kết nối, hàm ch

  Mặc dù sự kiện bị mất kết nối khi instância mà chúng thuộc về bị phá hủy, một lỗi thông thường là để cho rằng điều này á

• Bảng) - Đang đưa vật thể vào bảng nhưng không phải làm cho chúng khi chúng không còn cần thiết gây ra lượng bộ nhớ không cần thiết, đặc biệt là cho những bảng dữ liệu người dùng khi họ tham gia. Ví dụ, mẫu mã code sau đây tạo một bảng thêm thông tin người dùng mỗ

  Ví dụ
  local playerInfo = {}
  Players.PlayerAdded:Connect(function(player)
      playerInfo[player] = {} -- một số thông tin
  end)

  Nếu bạn không xóa các hàng này khi chúng không còn cần thiết, bảng vẫn tăng lên kích thước và tiêu thụ nhiều bộ nhớ hơn khi nhiều người tham gia phiên đấu. Bất kỳ mã nào tiến hành trên bảng này cũng trở nên đắt hơn khi bảng tăng lên kích thước.

Giải pháp

Để làm sạch tất cả các giá trị đã sử dụng để ngăn chặn bị rò rỉ bộ nhớ:

• Kết nối tất cả các kết nối - Đi qua cơ sở mã của bạn để đảm bảo mỗi kết nối được làm sạch qua một trong những con đường sau đây:

  • Huỷ kết nối bằng cách sử dụng chức năng Disconnect()
  • Phá hủy instância mà sự kiện thuộc về với chức năng Destroy() .
  • Phá huỷ mục đối tượng script mà kết nối được gắn về.

• Loại bỏ những thống kê người chơi và nhân vật sau khi rời đi - Thực hiện mã để đảm bảo không có kết nối tồn tại sau khi một người rời đi, như trong ví dụ sau:

  Ví dụ
  Players.PlayerAdded:Connect(function(player)
    player.CharacterRemoving:Connect(function(character)
      task.defer(character.Destroy, character)
    end)
  end)
  
  Players.PlayerRemoving:Connect(function(player)
      task.defer(player.Destroy, player)
  end)

Tính toán Vật lý

Simulation vật lý dư thừa có thể là nguyên nhân gây ra thời gian tính toán quá dài mỗi khung giữa máy chủ và máy khách.

Những vấn đề thông thường

• Tần số ngày thời gian vật lý dư dật - Bởi mặc định, mức độ bước nhảy là chuyển động ứng nghiệm, nơi mà các bước vật lý ở 60 Hz, 120 Hz hoặc 240 Hz, tùy thuộc vào sự phức tạp của cơ chế vật lý.

  Một chế độ cố định với độ chính xác của vật lý được cải thiện cũng được cung cấp, khiến tất cả các hệ thống vật lý được bước 240 Hz (tương đương 4 lần mỗi khung hình). Điều này dẫn đến sự tính toán nhiều hơn mỗi khung hình.

• Số lượng phức tạp của các đối tượng simulatics quá nhiều - Bạn càng simulatics nhiều hơn, thì bạn sẽ càng cần nhiều tính toán vật lý hơn. Thường, các trải nghiệm sẽ có các đối tượng được simulatics mà không cần phải hoặc sẽ có các mép và mắt

• Phát hiện va chạm quá chính xác - Mesh parts có một CollisionFidelity property để phát hiện va chạm which offers a variety of modes with different levels of performance impact. Precise va chạm đến mode parts có chi phí hiệu suất cao nhất và mất nhiều thời gian hơn để tính toán.

Giải pháp

• Các bộ phận liên kết mà không cần simulatronics - Liên kết tất cả các bộ phận mà không cần được lái bởi vật lý, chẳng hạn như cho NPC tĩnh.

• Sử dụng các bước vật lý thích nhận biến - Các bước vật lý thích nhận biến động tỷ lệ tính toán vật lý cho các mécanism vật lý, cho phép cập nhật tính toán vật lý ít hơn trong một số trường hợp.

• Giảm phức tạp cơ cấu mécanism * Nếu có thể, hãy giảm tối đa số hạn chế hoặc kết nối vật lý trong một bản dịch.

  • Giảm số lượng va chạm chính trong một cơ chế, chẳng hạn như bằng cách áp dụng giới hạn hoặc hạn chế va chạm để giảm bóng rổ limbs để ngăn chặn chúng khỏi việc va chạm với nhau.

• Giảm sự sử dụng của độ chính xác của va chạm để cho mạng lưới * Đối với những thiết bị nhỏ hoặc không tương tác ít khi người dùng nhận thấy sự khác biệt, hãy sử dụng box fidelity.

  • Đối với các đối tượng có kích thước nhỏ đến trung bình, hãy sử dụng hộp hoặc hull fidelity, tùy thuộc vào hình dạng.

  • Đối với các thể hiện lớn và rất phức tạp, hãy tạo ra các va chạm tùy chỉnh bằng cách sử dụng các bộ phận tương tự khi có thể.

  • Đối với những thống nhất không cần thiết, vô hiệu hóa va chạm và sử dụng độ tin cậy của hộp hoặc thân tàu, vì kết cấu va chạm vẫn được lưu trong bộ nhớ.

  • Bạn có thể tạo định dạng va chạm cho mục đích debug trong Studio bằng cách bật Độ chính xác va chạm từ widget Tùy chọn hiển thị ở góc trên cùng bên phải của viewport 3D.

    Alternatively, you can apply the CollisionFidelity = Precise filter to the Explorer which shows a count of all mesh parts with the precise fidelity and allows you to easily select them.

  • Đối với một hướng dẫn chi tiết về cách chọn một tùy chọn độ chính xác va chạm mà cân bằng các yêu cầu chính xác và hiệu suất của bạn, xem Thiết lập các thông số vật lý và hiệu suất .

Bộ lọc MicroProfiler

Sử dụng bộ nhớ vật lý

Sự di chuyển và va chạm vật lý tiêu tốn bộ nhớ. Các bộ phận lưới có một CollisionFidelity tính năng mà xác định phương pháp tiếp cận được sử dụng để đánh giá giới hạn va chạm của lưới.

Trở ngại thông thường

Các chế độ va chạm màu mỡ và chính xác tiêu chuẩn tiêu thụ nhiều bộ nhớ hơn hai chế độ khác với hình dạng va chạm độ tin cậy thấp hơn.

Nếu bạn thấy mức tiêu thụ bộ nhớ cao dưới PhysicsParts , bạn có thể cần phải khám phá giảm độ chính xác va chạm của các ô trong kinh nghiệm của bạn.

Làm thế nào để Mitigate

Để giảm bớt bộ nhớ được sử dụng cho độ chính xác của va chạm:

• Đối với những bộ phận không cần phải va chạm, vô hiệu hóa va chạm của chúng bằng cách thiết lập BasePart.CanCollide , BasePart.CanTouch và BasePart.CanQuery đến 1> force1> .
• Giảm độ chính xác của va chạm bằng cách sử dụng cấu hình CollisionFidelity . Box có độ bộ nhớ thấp nhất và Enum.CollisionFidelity.

  • Thông thường an toàn để đặt sự an toàn của bất kỳ phần nào có khả năng liên quan đến vị trí cố định nào đó đến Box .
  • Đối với những lưới lớn rất phức tạp, bạn có thể muốn xây dựng lưới va chạm của riêng bạn từ những thống nhỏ hơn với sự chính xác va chạm hộp.

Hình người

Humanoid là một lớp cung cấp một loạt các chức năng cho người chơi và nhân vật người chơi (NPC) (NPC). Mặc dù mạnh mẽ, một Humanoid đi kèm với một chi phí tính toán lớn.

Những vấn đề thông thường

• Bỏ mọi loại Hình người được mở trên NPCs - Có một chi phí hiệu suất để bỏ một số HumanoidStateTypes được bật. Vô hiệu hóa bất kỳ thứ gì không cần thiết cho NPC của bạn. V
• Tạo, điều chỉnh và tái tạo các mô hình với Humanoids thường xuyên * Điều này có thể gây ra một lượng lớn công việc cho máy chủ xử lý, đặc biệt là nếu các mô hình này sử dụng Quần áo phủ khắc . Điều này cũng có thể gây ra một số vấn đề đặc biệt trong các trải nghiệm nơi avatar thường xuyên respawn.

  • Trong MicroProfiler , các thẻ dài updateInvalidatedFastClusters (hơn 4 ms) thường là một tín hiệu cho thấy hệ tạo hình ảnh/thay đổi ngay lập tức đang kích hoạt quá nhiều huỷ vô hiệu hóa.
• Sử dụng Humanoids trong các trường hợp khi chúng không cần thiết - NPC tĩnh điện không cần thiết cho lớp Humanoid .
• Chơi hoạt họa trên một lượng lớn các NPC từ máy chủ - Hoạt họa NPC chạy trên máy chủ cần phải được mô phỏng trên máy chủ và sao chép đến client. Điều này có thể là một yếu tố thừa.

Giải pháp

• Chơi hoạt họa NPC trên client - Trong các trải nghiệm với một lượng lớn các NPC, xem xét tạo ra Animator trên client và chạy hoạt họa tại chỗ. Điều này giảm tải trên máy chủ và yêu cầu không cần thiết phả
• Sử dụng các tùy chọn thân thiện với hiệu suất cho người dùng cuối cùng. - NPC không nhất thiết phải chứa một đối tượng người dùng.

  • Đối với NPC statische, hãy sử dụng một AnimationController đơn giản, vì chúng không cần phải di chuyển nhưng chỉ cần phải chơi hoạt họa.
  • Đối với NPC di chuyển, xem xét việc thực hiện điều khiển di chuyển của riêng bạn và sử dụng một AnimationController cho hoạt họa, tùy thuộc vào sự phức tạp của NPC của bạn.
• Vô hiệu hóa các trạng thái người lớn không cần thiết - Sử dụng Humanoid:SetStateEnabled() để chỉ kích hoạt các trạng thái cần thiết cho mỗi người lớn.
• Mô hình NPC hồ bơi với tần suất phục hồi thường xuyên hơn - Thay vì phải tiêu diệt một NPC hoàn toàn, gửi NPC đến một hồ bơi của NPC tạm thời. Điều này cho phép bạn chỉ cần kích hoạt lại một trong những NPC t
• Chỉ gọi NPC khi người dùng ở gần đó - Đừng gọi NPC khi người dùng không ở gần và xóa chúng khi người dùng rời khỏi vùng.
• Tránh đổi chỉnh sửa lớp hiệp hội avatar sau khi nó được khởi tạo - Một số thay đổi lớp hiệp hội avatar có ảnh hưởng hiệu suất lớn. Một số hợi ích tối ưu hóa có sẵn:

  • Đối với hoạt họa mô phỏng, không cập nhật các thuộc tính JointInstance.C0 và JointInstance.C1 mà thay vào đó là thuộc tính Motor6D.Transform.
  • Nếu bạn cần kết hợp bất kỳ BasePart đối tượng với avatar, thực hiện nó ngoài cấp độ hierarch của avatar Model .

Bộ lọc MicroProfiler

Đang tạo

Một phần lớn thời gian mà khách hàng dành cho mỗi khung hình là trên render cảnh đang diễn ra trong khung hình hiện tại. Máy chủ không thực hiện bất kỳ render nào, vì vậy mục này dành riêng cho khách hàng.

Rút gọi

Một hàm gọi là một bộ hướng dẫn từ máy chủ đếnGPU để render bất cứ thứ gì. Hàm gọi có một lượng lớn bộ nhớ. Thông thường, càng ít hàm gọi mỗi khung, thì càng ít thời gian dành cho việc render một khung.

Bạn có thể thấy số lần gọi xử lý hình ảnh hiện đang xảy ra với Timing > Thời gian mục trong Studio. Bạn có thể xem Timing trên client bằng cách nhấn 1> Shift1> 3> F23> .

Theo cách nào đối với những thứ cần phải được vẽ trong một khung của bạn trong một khoảnh khắc nào đó, thì nhiều lần gọi vẽ hơn đối với nút instancing để thu nhỏ các thứ tương tự với cùng một chất độ

• SurfaceAppearances giống nhau. TextureIDs giống nhau khi SurfaceAppearance không tồn tại.
• Các vật liệu giống nhau khi cả SurfaceAppearance và MeshPart.TextureID không tồn tại.

Các vấn đề thông thường khác

• Độ dày vật thể vượt mức - Nếu một lượng lớn vật thể được tập trung với một độ dày cao, thì việc hiển thị khu vực này của cảnh yêu cầu nhiều lần vẽ hơn. Nếu bạn đang tìm thấy tỷ lệ khung của bạn giảm khi nhìn vào một s

  Các thể hiện như decal, textures và hạt như được tạo tốt và giới thiệu thêm các cuộc gọi vẽ. Để tập trung vào những thể hiện này những thể hiện này như ParticleEmitters có thể có tác động lớn lên hiệu lực.

• Cơ hội bị mất khi tạo hình ảnh - Thường, một cảnh sẽ bao gồm cùng một mắt lưới được sao chép nhiều lần, nhưng mỗi bản sao của mắt lưới có các ID mắt lưới hoặc thuộc tính khác nhau. Điều này ngăn chặn sự tạo hình và có thể dẫn đến các cuộc g

  Nguyên nhân chính xác của vấn đề này là khi toàn bộ một cảnh được nhập từ một lúc, thay vì các tài nguyên cục bộ được nhập vào Roblox và sau đó sao chép post-import để tập hợp cảnh.

• Phức tạp hóa đối tượng quá mức - Mặc dù không quan trọng như số lượng các cuộc gọi kéo nhưng số lượng các hình vuông trong một cảnh có ảnh hưởng đến thời gian render. Các cảnh với

• Phản chiếu các bóng tối quá mức - Quản lý các bóng tối là một quá trình tốn kém, và bản đồ có chứa một lượng lớn và độ dày của các đối tượng ánh sáng mà phản chiếu các bóng tối (hoặc một lượng lớn và độ dày của các bộ phận nhỏ bị ảnh hưởng bởi b

• Cao trong suốt trong suốt trong suốt trong suốt trong suốt trong suốt trong suốt trong suốt trong suốt trong suốt trong suốt trong suốt trong suốt trong suốt trong suốt trong suốt trong suốt trong suốt trong suốt trong suốt trong suốt trong suốt trong suốt trong suốt trong suốt trong suốt trong suốt trong suốt trong suốt trong suốt trong suốt trong

Giải pháp

• Tạo ra các lưới tương tự và giảm bớt số lượng lưới tương tự - Nếu bạn đảm bảo tất cả lưới tương tự để có cùng một ID nguyên tảo, engine có thể nhận ra và render
• Hút bỏ - Hút bỏ mô tả quá trình loại bỏ các cuộn dữ liệu để đối tượng không thuộc vào khung hình cuối cùng. Bởi mặc định, máy chủ bỏ qua các cuộn dữ liệu cho các

  • Ẩn MeshPart và BasePart đang xa camera hoặc cài đặt.
  • Đối với môi trường bên trong, hãy thực hiện một hệ thống phòng hoặc cổng thông thường ẩn các thành phần không được sử dụng bởi bất kỳ người dùng nào hiện tại.
• Giảm chân thực đo vẽ - Đặt chân thực đo vẽ để tự động hoặc hiệu suất . Điều này cho phép các mạng để rơi về các lựa chọn đơn giản hơn, từ đó giảm số lượng các hình ảnh cần được vẽ.
• Vô hiệu hóa bóng tối trên các bộ phận và đối tượng phù hợp - Sự phức tạp của bóng tối trên các bộ phận và đối tượng có thể được giảm bằng cách tắt bóng tối trên các bộ phận và đối tượng. Điều này có thể được thực hiện ở thời điểm chỉnh sửa hoặ

  • Sử dụng thuộc tính BasePart.CastShadow để vô hiệu hóa bóng tối trên các bộ phận nhỏ khi bóng tối không thể nhìn thấy. Điều này có thể đặc biệt hiệu quả khi chỉ áp dụng cho những bộ phận xa xôi khỏi máy ảnh của người dùng.

    Điều này có thể dẫn đến những hiện tượng nghệ thuật địa hình trên bóng tối.

  • Vô hiệu hóa bóng tối trên các thể hiện di chuyển khi có thể.

  • Vô hiệu hóa Light.Shadows trên các instância ánh sáng nơi mà đối tượng không cần phải cast bóng tối.

  • Giới hạn phạm vi và góc của các thành phần ánh sáng.

  • Sử dụng ít hơn các thành phần ánh sáng.

Bộ lọc MicroProfiler

Mạng và sao chép

Mạng và sao chép mô tả quá trình dữ liệu được gửi giữa máy chủ và các kết nối khách hàng. Thông tin được gửi giữa khách hàng và máy chủ mỗi khung, nhưng các khoản thông tin lớn hơn yêu cầu nhiều thời gian xử lý hơn.

Những vấn đề thông thường

• Giao thức truyền dữ liệu quá mức - Gửi một lượng dữ liệu lớn thông qua các thiết bị RemoteEvent hoặc RemoteFunction hoặc gọi chúng rất thường xuyên có thể dẫn đến một lượng thời gian xử lý dữ liệu lớn mỗi khung. Các lỗi

  • Tái tạo dữ liệu mỗi khung không cần thiết phải tái tạo.
  • Tái tạo dữ liệu trên đầu vào của người dùng mà không có cơ chế nào để throttle nó.
  • Đang gửi nhiều dữ liệu hơn là yêu cầu. Ví dụ, gửi toàn bộ kho đồ của người chơi khi họ mua một món đồ thay vì chỉ là các chi tiết của món đồ đã mua.

• Tạo hoặc xóa cây dữ liệu phức tạp - Khi một thay đổi được thực hiện đối với cây dữ liệu trên máy chủ, nó được sao chép đến các khách hàng kết nối. Điều này có nghĩa là tạo và xóa các cấp dữ liệu lớn như bản đồ ở thời điểm thực thi có thể rấ

  Một nguyên nhân thông thường ở đây là dữ liệu hoạt họa phức tạp được lưu bởi các plugin Editor Hoạt Họa trong các thành phần. Nếu những dữ liệu này không được xóa trước khi phát hành game và mô hình hoạt họa được sao chép thường xuyên, một lượng lớn dữ liệu sẽ được sao chép không cần th

• Server-side TweenService - Nếu TweenService được sử dụng để tween một máy chủ bên trong, tính năng tween được sao chép sang mỗi khách hàng mỗi khung. Không chỉ khiến cho tween bị lỗi khi tốc độ truy cập của khách hàng thay đổi, nhưng nó g

Giải pháp

Bạn có thể sử dụng các thuộc tính sau đây để giảm bớt sự sao chép không cần thiết:

• Tránh gửi nhiều dữ liệu lớn cùng một lúc thông qua các sự kiện xa tận . Thay vào đó, chỉ gửi dữ liệu cần thiết ở một tần số thấp hơn. Ví dụ, cho trạng thái của một nhân vật, sao chép nó khi nó thay đổi thay vì mỗi khung.
• Chunk up complex instance trees như bản đồ và tải chúng trong các khối để phân phối công việc này trên nhiều khung.
• Xóa dữ liệu trong công cụ hoạt họa , đặc biệt là dữ liệu trong thư mục hoạt họa của các thiết bị, sau khi nhập.
• Giới hạn việc sao chép nhân bản không cần thiết trong trường hợp mà máy chủ không cần phải có kiến thức về những nhân bản đang được tạo ra. Điều này bao gồm:
• Hiệu ứng thị giác, chẳng hạn như một vụ nổ hoặc một cú phép ma thuật. Server chỉ cần biết vị trí để xác định kết quả, trong khi các client có thể tạo ra các hiệu ứng thị giác ở địa phương.
• Mô hình người dùng đầu tiên.
• Đổi vật thể trên client thay vì trên máy chủ.

Bộ lọc MicroProfiler

Tài sản Công suất lưu trữ

Cơ chế tác động cao nhất để người sáng tạo cải thiện sử dụng bộ nhớ của khách hàng là bật Tương tác Phát sóng trực tiếp.

Tương tác hóa đa phiên

Đối với mô hình dựa trên đám mây, hành vi phát sóng tải trước tải tại chỗ của chúng tôi là tải từ nơi nào đó trong cùng một lúc, tạo ra một lượng lớn dữ liệu để được phục hồi trong một khoảng thời gian ngắn. Korean:Instance streaming selectively loads out parts of the data model that are not required, which can lead to значительно reduced load time and increase the client's ability to prevent crashes when it comes under memory pressure.

Nếu bạn gặp sự cố về lưu trữ và có vấn đề về chuỗi định tuyến, xem xét cập nhật trải nghiệm của bạn để hỗ trợ nó, đặc biệt là nếu thế giới 3D của bạn lớn. Chuỗi định tuyến dựa trên khoảng cách trong không gian 3D, vì vậy các thế giới lớn hơn thường hưởng lợi từ n

Nếu hỗ trợ phát trực tiếp được bật, bạn có thể tăng độ tấn công của nó. Ví dụ, hãy xem xét:

• Giảm sử dụng StreamingIntegrity tồn tại.
• Giảm vòng tròn phát trực tiếp .

Để biết thêm thông tin về các lựa chọn phát và lợi ích của chúng, hãy xem Tính chất phát .

Các vấn đề thông thường khác

• Duplicate tài sản - Một lỗi phổ biến là tải cùng một ID tài sản lên nhiều lần dẫn đến các ID tài sản khác nhau. Điều này có thể dẫn đến việc tải cùng một nội dung lên bộ nhớ nhiều lần.
• Số lượng tài nguyên dư thừa - Ngay cả khi tài nguyên không giống nhau, có những trường hợp khi cơ hội tái sử dụng cùng một tài nguyên và lưu bộ nhớ bị bỏ lỡ.
• Tập tin âm thanh - Tập tin âm thanh có thể là một người đóng góp tuyệt vời cho sử dụng bộ nhớ, đặc biệt là nếu bạn tải tất cả chúng vào client một lúc thay vì chỉ tải những gì bạn cần cho một phần của trải nghiệm. Đối với chiến lược, hãy xem Thời gian tải
• Cao dụng cụ tạo hình textures - Tốn nhiều bộ nhớ hơn cho một texture là không liên quan đến kích thước của texture trên đĩa, nhưng là số lượng của các pixel trong texture.

  • Ví dụ, một lớp chất liệu 1024x1024 sử dụng bốn lần bộ nhớ đồ họa của một lớp chất liệu 512x512.
  • Hình ảnh được tải lên Roblox được mã hóa dưới dạng chuẩn, vì vậy không có lợi ích gì khi tải hình ảnh trong một mô hình màu được liên kết với ít hơn số lượng dữ liệu per pixel. Tư
  • Bạn có thể xác định tốn nhiên năng cho đồ họa bằng cách mở rộng danh mục GraphicsTexture trong Developer Console .

Giải pháp

• Chỉ tải tài nguyên một lần - Tái sử dụng cùng một ID tài nguyên đối với tất cả các đối tượng và đảm bảo cùng một ID tài nguyên, đặc biệt là mạng lưới và hình ảnh, không được tải lên riêng lẻ nhiều lần.
• Tìm và sửa các tài nguyên tương tự nhau - Tìm các bộ phận lưới tương tự và văn bản được tải nhiều lần với các ID khác nhau.

  • Mặc dù không có API để phát hiện sự tương tự của tài nguyên tự động, bạn vẫn có thể thu thập tất cả các ID hình ảnh tài nguyên ở địa điểm của bạn (hoặc bằng tay hoặc bằng cách sử dụng các công cụ so sánh ngoài tầm với của bạn), tải xuống chúng và so sánh chúng bằng các công cụ so sánh bên
  • Đối với các bộ phận mạng, chiến lược tốt nhất là lấy ID mạng độc nhất và tổ chức chúng theo kích thước để tự động xác định những bộ nhân bản.
  • Thay vì sử dụng các chất bôi để tạo các chất bôi cho các màu khác nhau, tải một chất bôi duy nhất và sử dụng thuộc tính SurfaceAppearance.Color để áp dụng các màu sắc khác nhau cho nó.
• Nhập các tài nguyên trên bản đồ riêng tư hơn map để được nhập và tái tạo tài nguyên trên map riêng tư một cách riêng lẻ và tái tạo chúng. 3D importer không thực hiệ
• Giới hạn các pixel của hình ảnh đến không hơn số lượng cần thiết. Ngừy một hình ảnh chiếm tỉ lệ lớn hơn một không gian vật lý trên màn hình, nó thường cần tối đa 512x512 pixels. Most minor images should be smaller than 256x256 pixels.
• Sử dụng Trang tấm Cắt để đảm bảo tối đa sự tái sử dụng chất liệu trong 3D map. Đối với các bước và ví dụ về cách tạo Trang tấm Cắt, hãy xem Tạo Trang tấm Cắt .

Thời gian tải

Nhiều trải nghiệm thực hiện màn hình tải tùy chỉnh và sử dụng phương thức ContentProvider:PreloadAsync() để yêu cầu các tài nguyên để hình ảnh, âm thanh và lưới được tải trong nền.

Điểm mạnh của phương pháp này là cho phép bạn đảm bảo các bộ phận quan trọng của trải nghiệm của bạn được tải đầy đủ mà không bị pop-in. Tuy nhiên, một sai lầm thông thường là sử dụng quá nhiều phương pháp này để tải trước nhiều tài nguyên hơn là thực sự yêu cầu.

Một ví dụ về một thực tế xấu là tải toàn bộ Class.Workspace . Mặc dù điều này có thể ngăn chặn hiện xuất thuộc tính, nó vẫn tăng thời gian tải lên đáng kể.

Thay vào đó, chỉ sử dụng ContentProvider:PreloadAsync() trong những tình huống cần thiết, bao gồm:

• Hình ảnh trên màn hình tải.
• Nhập các hình ảnh quan trọng trong menu kinh nghiệm của bạn, chẳng hạn như hình nền nút và biểu tượng.
• Các tài nguyên quan trọng ở khu vực khởi động hoặc khu vực đẻ trứng.

Nếu bạn phải tải một lượng lớn các tài nguyên, chúng tôi khuyến nghị bạn cung cấp một nút Bỏ qua tải xuống .