Cải thiện hiệu suất

Trang này mô tả các vấn đề hiệu suất phổ biến và tốt nhất cách giảm thiểu chúng.

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

Các hoạt động tốn kém trong mã Luau mất nhiều thời gian để xử lý và do đó có thể ảnh hưởng đến tốc độ khung.Trừ khi nó được thực hiện song song, mã Luau chạy song song và chặn luồng chính cho đến khi nó gặp một chức năng cung cấp luồng.

Vấn đề phổ biến

• Hoạt động dày đặc trên cấu trúc bảng - Các hoạt động phức tạp như serialization, deserialization và deep cloning tốn nhiều chi phí hiệu suất, đặ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à lặp lại hoặc liên quan đến việc lặp lại trên các cấu trúc dữ liệu rất lớn.

• Sự kiện tần suất cao - Kết nối các hoạt động đắt tiền với các sự kiện dựa trên khung của RunService mà không giới hạn tần suất có nghĩa là các hoạt động này được lặp lại mỗi khung, điều này thường dẫn đến sự gia tăng không cần thiết về thời gian xử lý.Các sự kiện này bao gồm:

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

Giảm thiểu

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

Phạm vi của MicroProfiler

Để biết thêm thông tin về việc gỡ lỗi các tập lệnh bằng MicroProfiler, hãy xem thư viện debug, bao gồm các chức năng cho việc đánh dấu các mã cụ thể và tăng độ chính xác, chẳng hạn như debug.profilebegin và debug.profileend.Nhiều phương pháp API Roblox được gọi bởi các kịch bản cũng có các thẻ MicroProfiler liên quan của riêng họ có thể cung cấp tín hiệu hữu ích.

Sử dụng bộ nhớ kịch bản

Rò rỉ bộ nhớ có thể xảy ra khi bạn viết các kịch bản tiêu thụ bộ nhớ mà người thu thập rác không thể giải phóng đúng cách khi không còn sử dụng nữa.Các rò rỉ đặc biệt lan tỏa trên máy chủ, bởi vì chúng có thể liên tục trực tuyến trong nhiều ngày, trong khi phiên khách hàng ngắn hơn nhiều.

Các giá trị bộ nhớ sau đây trong Bảng điều khiển Nhà phát triển có thể chỉ ra một vấn đề cần được điều tra thêm:

• LuaHeap - Tiêu thụ cao hoặc tăng có thể gợi ý về rò rỉ bộ nhớ
• Số lượng instance - Liên tục tăng số lượng instance cho thấy các tham chiếu đến một số instance trong mã của bạn không được thu thập rác.
• PlaceScriptMemory - Cung cấp một kịch bản bằng cách phân tích sử dụng bộ nhớ bởi kịch bản.

Vấn đề phổ biến

• Rời các kết nối được kết nối - Động cơ không bao giờ thu thập rác sự kiện được kết nối với một ví dụ và bất kỳ giá trị nào được tham chiếu bên trong cuộc gọi trả lại kếtDo đó, các kết nối hoạt động của sự kiện và mã bên trong các ví dụ kết nối, chức năng kết nối, và giá trị được tham chiếu, nằm ngoài phạm vi của nhà thu thập rác bộ nhớ, ngay cả sau khi các sự kiện bị kích hoạt.

  Mặc dù sự kiện bị tách khi mẫu thuộc về của nó bị phá hủy, một sai lầm phổ biến là cho rằng điều này áp dụng cho Player đối tượng.Sau khi một người dùng rời khỏi trải nghiệm, động cơ không tự động phá hủy đối tượng và mô hình nhân vật đại diện của họ, do đó các kết nối đến đối tượng và các thực thể dưới mô hình nhân vật, chẳng hạn như , vẫn tiêu thụ bộ nhớ nếu bạn không tách chúng ra khỏi các tập lệnh của bạn.Điều này có thể dẫn đến rò rỉ bộ nhớ rất lớn theo thời gian trên máy chủ khi hàng trăm người dùng tham gia và rời khỏi trải nghiệm.

• Bảng - Chèn các đối tượng vào bảng nhưng không xóa chúng khi chúng không còn cần thiết gây tiêu tốn bộ nhớ không cần thiết, đặc biệt là đối với các bảng theo dõi dữ liệu người dùng khi họ tham gia.Ví dụ, mẫu mã code sau tạo ra một bảng thêm thông tin người dùng mỗi khi người dùng tham gia:

  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 mục này khi chúng không còn được cần khi chúng không còn được cần, bảng tiếp tục phát triển về kích thước và tiêu thụ nhiều bộ nhớ hơn khi nhiều người dùng tham gia phiên.Bất kỳ mã nào lặp lại trên bảng này cũng trở nên tốn kém hơn về mặt toán học khi bảng lớn lên về kích thước

Giảm thiểu

Để xóa tất cả các giá trị được sử dụng để ngăn chặn rò rỉ bộ nhớ:

• Tách tất cả các kết nối - Đi qua cơ sở mã của bạn để chắc chắn mỗi kết nối được xóa sạch thông qua một trong các con đường sau:

  • Tách kết nối bằng tay bằng chức năng Disconnect().
  • Phá hủy instance mà sự kiện thuộc với chức năng Destroy().
  • Phá hủy đối tượng kịch bản mà các kết nối theo dõi lại.

• Loại bỏ các đối tượng và nhân vật người chơi sau khi rời khỏ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 dùng rời đi, giống 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ý

Mô phỏng vật lý quá mức có thể là nguyên nhân chính gây tăng thời gian tính toán mỗi khung trên cả máy chủ và khách hàng.

Vấn đề phổ biến

• Tần suất bước thời gian vật lý vượt quá - Mặc định, hành vi bước là trong chế độ thích ứng, nơi các bước vật lý ở 60 Hz, 120 Hz hoặc 240 Hz, tùy thuộc vào độ phức tạp của cơ chế vật lý.

  Một chế độ cố định với độ chính xác cao hơn về vật lý cũng có sẵn, buộc tất cả các tập hợp vật lý phải bước vào 240 Hz (bốn lần mỗi khung).Điều này dẫn đến tính toán nhiều hơn đáng kể mỗi khung.

• Số lượng phức tạp vượt quá của các đối tượng được mô phỏng - Càng có nhiều lắp ráp 3D được mô phỏng, thời gian tính toán vật lý càng lâu cho mỗi khung.Thường xuyên, các trải nghiệm sẽ có các đối tượng được mô phỏng mà không cần phải là hoặc sẽ có các cơ chế có nhiều hạn chế và khớp hơn họ cần.

• Phát hiện va chạm quá chính xác - Các bộ phận lưới có một tính năng CollisionFidelity để phát hiện va chạm cung cấp nhiều chế độ khác nhau với các mức độ ảnh hưởng hiệu suất khác nhau.Chế độ phát hiện va chạm chính xác cho các bộ phận lưới có chi phí hiệu suất đắt nhất và mất nhiều thời gian hơn để tính toán.

Giảm thiểu

• Các bộ phận neo không cần phải mô phỏng - Neo tất cả các bộ phận không cần được lái bởi vật lý, chẳng hạn như cho NPC tĩnh.

• Sử dụng bước thích ứng vật lý - Bước thích ứng điều chỉnh tốc độ tính toán vật lý cho các cơ chế vật lý, cho phép cập nhật vật lý ít thường xuyên hơn trong một số trường hợp.

• Giảm phức tạp cơ chế * Nếu có thể, hãy giảm số hạn chế vật lý hoặc khớp trong một tập hợp.

  • Giảm lượng va chạm tự nội trong một cơ chế, chẳng hạn bằng cách áp dụng giới hạn hoặc hạn chế va chạm để các chi của ragdoll không va chạm với nhau.

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

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

  • Đối với các đối tượng lớn và rất phức tạp, xây dựng các va chạm tùy chỉnh bằng cách sử dụng các bộ phận vô hình khi có thể

  • Đối với các đối tượng không yêu cầu va chạm, vô hiệu hóa va chạm và sử dụng độ trung thành hộp hoặc thân tàu, vì định dạng va chạm vẫn được lưu trong bộ nhớ.

  • Bạn có thể hiển thị địa hình va chạm cho mục đích gỡ lỗi trong Studio bằng cách bật độ trung thực va chạm từ widget Tùy chọn hiển thị ở góc trên bên phải của cửa sổ 3D.

    Ngoài ra, bạn có thể áp dụng bộ lọc CollisionFidelity = Precise cho Explorer hiển thị tổng số các phần mesh với độ chính xác cao và cho phép bạn dễ dàng chọn chúng.

  • Đối với một hướng dẫn chi tiết về cách chọn tùy chọn chính xác va chạm cân bằng các yêu cầu về độ chính xác và hiệu suất của bạn, hãy xem Set Physics and Rendering Parameters.

Phạm vi của MicroProfiler

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

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

Vấn đề phổ biến

Các chế độ phát hiện va chạm mặc định và chính xác tiêu tốn nhiều bộ nhớ hơn hai chế độ khác với các hình dạng va chạm chính xác thấp.

Nếu bạn thấy mức tiêu thụ bộ nhớ cao dưới PhysicsParts , bạn có thể cần khám phá cách giảm độ trung thực va chạm của các đối tượng trong trải nghiệm.

Cách giảm bớt

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

• Đối với các bộ phận không cần va chạm, vô hiệu hóa va chạm của chúng bằng cách đặt BasePart.CanCollide , BasePart.CanTouch và BasePart.CanQuery đến false .
• Giảm độ trung thực của va chạm bằng cách sử dụng cài đặt CollisionFidelity.Box có lượng tiêu thụ bộ nhớ thấp nhất, và Default và Precise thường đắt hơn.

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

Người Nhân Tạo

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 không phải người chơi (NPC).Mặc dù mạnh mẽ, một Humanoid có chi phí tính toán đáng kể.

Vấn đề phổ biến

• Rời tất cả các loại HumanoidStateTypes được bật trên NPC - Có một chi phí hiệu suất khi rời bỏ một số HumanoidStateTypes bị 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í dụ, trừ khi NPC của bạn sẽ leo các thang, thì an toàn khi vô hiệu hóa trạng thái Climbing.
• Tạo, chỉnh sửa và tái sinh mô hình với Humanoids thường xuyên * Điều này có thể gây tốn năng lượng cho động cơ xử lý, đặc biệt nếu các mô hình này sử dụng quần áo lớp .Điều này cũng có thể đặc biệt gây ra vấn đề trong những trải nghiệm mà avatar thường xuyên hồi sinh.

  • Trong MicroProfiler , các thẻ cập nhật dài updateInvalidatedFastClusters (hơn 4 ms) thường là một tín hiệu cho thấy việc triển khai/chỉnh sửa avatar đang gây ra quá nhiều lỗi không hợp lệ.
• Sử dụng Humanoids trong trường hợp không cần thiết - NPC tĩnh không di chuyển thường không cần đến lớp Humanoid.
• Chơi hoạt hình trên một lượng lớn NPC từ máy chủ - Hoạt hình NPC chạy trên máy chủ cần được mô phỏng trên máy chủ và sao chép cho khách hàng.Điều này có thể là tốn kém không cần thiết.

Giảm thiểu

• Chơi hoạt hình NPC trên máy khách - Trong những trải nghiệm với số lượng lớn NPC, hãy xem xét tạo Animator trên máy khách và chạy hoạt hình địa phương.Việc này giảm tải trên máy chủ và nhu cầu sao lưu không cần thiết.Nó cũng làm cho các sự tối ưu hóa bổ sung trở nên khả thi (như chỉ chơi hoạt hình cho NPC gần nhân vật).
• Sử dụng các lựa chọn thân thiện với hiệu suất để thay thế Humanoids - Các mô hình NPC không nhất thiết phải chứa một đối tượng humanoid.

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

  • Đối với các hoạt họa thủ tục tùy chỉnh, đừng cập nhật các thuộc tính JointInstance.C0 và JointInstance.C1. Thay vào đó, cập nhật thuộc tính Motor6D.Transform.
  • Nếu bạn cần gắn bất kỳ đối tượng BasePart nào vào avatar, hãy làm điều đó ngoài cấp bậc của avatar Model .

Phạm vi của MicroProfiler

Hiển thị

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

Gọi lên Draw calls

Một cuộc gọi kéo là một bộ các hướng dẫn từ động cơ đến GPU để vẽ một cái gì đóCác cuộc gọi kéo có tốn nhiều bộ nhớ.Nói chung, càng ít cuộc gọi rút mỗi khung, càng ít thời gian tính toán được dành cho việc hiển thị một khung.

Bạn có thể xem có bao nhiêu cuộc gọi vẽ đang xảy ra hiện tại với mục Thời gian render > Thời gian ở Studio.Bạn có thể xem Thống kê hiển thị trong khách hàng bằng cách nhấn ShiftF2.

Càng có nhiều đối tượng cần được vẽ trong cảnh của bạn trong một khung cụ thể, càng có nhiều cuộc gọi vẽ được thực hiện đến GPU.Tuy nhiên, Roblox Engine sử dụng một quá trình được gọi là triệu hồi để loại bỏ các khối lượng tương tự có cùng đặc điểm kết cấu vào một lần gọi vẽ duy nhất.Cụ thể, nhiều khối có cùng MeshId là được xử lý trong một lần gọi vẽ duy nhất khi:

• 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

• Mật độ đối tượng lớn thừa - Nếu một lượng lớn các đối tượng được tập trung với mật độ cao, thì việc hiển thị khu vực của cảnh này 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 phần nhất định của bản đồ, đây có thể là một tín hiệu tốt cho thấy độ dày của đối tượng trong khu vực này quá cao.

  Các đối tượng như tem, kết cấu và hạt không xếp hàng tốt và giới thiệu thêm cuộc gọi vẽ bổ sung.Hãy chú ý đặc biệt đến các loại đối tượng này trong cảnh.Cụ thể, thay đổi tính chất của ParticleEmitters có thể có tác động lớn đến hiệu suất

• Cơ hội triển khai bị bỏ lỡ - Thường xuyên, một cảnh sẽ bao gồm cùng một khối lượng lặp lại nhiều lần, nhưng mỗi bản sao của khối lượng có ID khối lượng hoặc kết cấu khác nhauĐiều này ngăn chặn việc khởi tạo và có thể dẫn đến các cuộc gọi rút không cần thiết.

  Một nguyên nhân phổ biến của vấn đề này là khi toàn bộ cảnh được nhập một lần, thay vì nhập các tài sản riêng lẻ vào Roblox và sau đó sao chép sau khi nhập để tập hợp cảnh.

• Phức tạp quá mức về đối tượng - Mặc dù không quan trọng bằng số lượng cuộc gọi vẽ, số lượng tam giác trong một cảnh ảnh ảnh hưởng đến thời gian kéo dài bao lâu một khung được render.Cảnh với số lượng rất lớn các khối lượng rất phức tạp là một vấn đề phổ biến, giống như cảnh với bộ đặt tính chất trên quá nhiều khối lượng.

• Phát bóng quá mức - Xử lý bóng là một quá trình tốn kém, và các bản đồ chứa một số lượng lớn và độ mờ của các vật thể phát bóng (hoặc một số lượng lớn và độ mờ của các bộ phận nhỏ bị ảnh hưởng bởi bóng) có thể có vấn đề về hiệu suất.

• Thông suốt cao vượt quá - Đặt các đối tượng có độ trong suốt một phần gần nhau buộc động cơ phải hiển thị các điểm chồng lấp nhiều lần, có thể làm hỏng hiệu suất.Để biết thêm thông tin về việc xác định và khắc phục vấn đề này, hãy xem Xóa khối trong suốt lớp.

Giảm thiểu

• Triệu hồi các khối lượng giống nhau và giảm số lượng khối lượng duy nhất - Nếu bạn đảm bảo tất cả các khối lượng giống nhau có cùng ID tài sản cơ sở, động cơ có thể nhận dạng và hiển thị chúng trong một lần gọi vẽ duy nhất.Hãy chắc chắn chỉ tải mỗi khối trong bản đồ một lần và sau đó sao chép chúng trong Studio để tái sử dụng thay vì nhập lại các bản đồ lớn như một tổng thể, có thể gây ra các khối tương tự có ID nội dung riêng biệt và được công nhận là tài sản duy nhất bởi động cơ.Gói là một cơ chế hữu ích để tái sử dụng đối tượng.
• Loại bỏ - Loại bỏ mô tả quá trình loại bỏ các cuộc gọi kéo cho các đối tượng không thuộc vào khung hiển thị cuối cùng.Mặc định, động cơ bỏ qua các cuộc gọi vẽ cho các đối tượng ngoài tầm nhìn của máy ảnh (frustum culling), nhưng không bỏ qua các cuộc gọi vẽ cho các đối tượng bị che khỏi tầm nhìn bởi các đối tượng khác (occlusion culling).Nếu cảnh của bạn có số lượng lớn các cuộc gọi rút, hãy xem xét triển khai thêm loại bỏ của riêng bạn tại thời gian thực một cách dinamik cho mỗi khung, chẳng hạn như áp dụng các chiến lược phổ biến sau:

  • Ẩn MeshPart và BasePart những thứ ở xa camera hoặc cài đặt
  • Đối với môi trường trong nhà, triển khai một hệ thống phòng hoặc cổng không hiển thị các đối tượng hiện đang không được sử dụng bởi bất kỳ người dùng.
• Giảm độ chính xác render - Thiết lập độ chính xác render thành Tự động hoặc Hiệu suất .Điều này cho phép lưới quay lại các lựa chọn ít phức tạp hơn, có thể giảm số lượng đường cong cần phải vẽ.
• Vô hiệu hóa phát bóng bóng trên các bộ phận và đối tượng ánh sáng thích hợp - Sự phức tạp của bóng trong một cảnh có thể được giảm bằng cách vô hiệu hóa bộ phận phát bóng bóng trên đối tượng ánh sáng và bộ phận một cách có chọn lọc.Việc này có thể được thực hiện tại thời điểm chỉnh sửa hoặc năng động trong thời gian thực.Một số ví dụ:

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

    Điều này có thể dẫn đến các hiện vật hình họa trên bóng tối.

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

  • Vô hiệu hóa Light.Shadows trên các ví dụ ánh sáng nơi mà đối tượng không cần phải tạo bóng tối.

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

  • Sử dụng ít ví dụ ánh sáng hơn.

Phạm vi của MicroProfiler

Kết nối và sao chép

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

Vấn đề phổ biến

• Giao thông từ xa vượt mức - Gửi một lượng lớn dữ liệu thông qua RemoteEvent hoặc RemoteFunction đối tượng hoặc kích hoạt chúng rất thường xuyên có thể dẫn đến một lượng lớn thời gian xử lý CPU được chi tiêu xử lý các gói nhận được mỗi khung.Những sai lầm phổ biến bao gồm:

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

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

  Một tội phạm phổ biến ở đây là dữ liệu hoạt hình phức tạp được lưu bởi các plugin Trình chỉnh sửa hoạt hình trong các khối.Nếu chúng không bị xóa trước khi trò chơi được xuất bản và mô hình hoạt hình được nhân bản thường xuyên, một lượng lớn dữ liệu sẽ bị sao chép không cần thiết

• Dịch vụ Tween bên máy chủ - Nếu TweenService được sử dụng để tween một máy chủ đối tượng, thuộc tính được tween sẽ được sao chép cho mỗi khách hàng mỗi khung.Không chỉ có kết quả này dẫn đến tween bị lo lắng khi độ trễ của khách hàng thay đổi, mà nó cũng gây ra rất nhiều lưu lượng mạng không cần thiết.

Giảm thiểu

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

• Tránh gửi một lượng lớn dữ liệu cùng một lúc thông qua sự kiện điều khiển từ xa .Thay vào đó, chỉ gửi dữ liệu cần thiết ở tần suất thấp hơn.Ví dụ, đối với trạng thái của một nhân vật, sao lưu nó khi nó thay đổi thay vì mỗi khung.
• Phân tích các cây instance phức tạp như bản đồ và tải chúng thành từng mảnh để phân phối công việc sao lưu những thứ này trên nhiều khung.
• Làm sạch metadata hoạt họa , đặc biệt là thư mục hoạt họa của các mô hình, sau khi nhập.
• Giới hạn sao lưu phiên bản không cần thiết , đặc biệt là trong trường hợp máy chủ không cần phải có kiến thức về các phiên bản được tạo.Bao gồm:

  • Hiệu ứng hình ảnh như một vụ nổ hoặc một đòn đánh phép thuật.Máy chủ chỉ cần biết vị trí để xác định kết quả, trong khi các khách hàng có thể tạo hình ảnh trực tiếp.
  • Mô hình xem mục người thứ nhất.
  • Các đối tượng Tween trên máy khách thay vì trên máy chủ

Phạm vi của MicroProfiler

Tiêu thụ bộ nhớ tài sản

Cơ chế tác động cao nhất có sẵn cho các nhà sáng tạo để cải thiện sử dụng bộ nhớ khách hàng là bật Chuyển phát Instance.

Phát trực tiếp các ví dụ

Phát trực tiếp trường hợp lựa chọn tải một phần của mô hình dữ liệu không cần thiết, có thể dẫn đến thời gian tải giảm đáng kể và tăng khả năng ngăn chặn sự cố khi nó bị áp lực bởi bộ nhớ.

Nếu bạn đang gặp phải vấn đề về bộ nhớ và có trường hợp phát trực tiếp bị vô hiệu hóa, hãy 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.Phát trực tiếp trường hợp dựa trên khoảng cách trong không gian 3D, vì vậy các thế giới lớn tự nhiên được hưởng lợi nhiều hơn.

Nếu phát trực tiếp của ví dụ được bật, bạn có thể tăng mức độ hung hăng của nó. Ví dụ:

• Giảm sử dụng bền vững StreamingIntegrity .
• Giảm bán kính phát sóng .

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

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

• Sao chép tài sản - Một sai lầm phổ biến là tải lên cùng một tài sản nhiều lần dẫn đến các ID tài sản khác nhauViệc này có thể dẫn đến cùng một nội dung được tải vào bộ nhớ nhiều lần.
• Tăng quá mức khối lượng tài sản - Ngay cả khi tài sả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 sản và lưu trữ bộ nhớ bị bỏ lỡ.
• Tập tin âm thanh - Các tập tin âm thanh có thể là một đóng góp bất ngờ vào việc sử dụng bộ nhớ, đặc biệt nếu bạn tải tất cả chúng vào máy khách cùng một lúc thay vì chỉ tải những gì bạn cần cho một phần trong trải nghiệm.Đối với các chiến lược, xem Thời gian tải.
• Kết cấu có độ phân giải cao - Tiêu thụ bộ nhớ đồ họa cho một kết cấu không liên quan đến kích thước của kết cấu trên đĩa, mà là số lượng pixel trong kết cấu.

  • Ví dụ, một kết cấu 1024x1024 pixel tiêu thụ bốn lần bộ nhớ đồ họa của một kết cấu 512x512.
  • Hình ảnh được tải lên Roblox được giải mã sang một định dạng cố định, vì vậy không có lợi ích về bộ nhớ khi tải hình ảnh trong một mô hình màu có ít hơn các bit mỗi pixel.Tương tự, nén hình ảnh trước khi tải lên hoặc loại bỏ kênh alpha khỏi hình ảnh không cần nó có thể làm giảm kích thước hình ảnh trên đĩa, nhưng không cải thiện hoặc chỉ cải thiện một phần nhỏ bộ nhớ sử dụng.Mặc dù động cơ tự động giảm độ phân giải kết cấu trên một số thiết bị, phạm vi của việc giảm độ phân giải phụ thuộc vào các tính năng của thiết bị, và việc giảm quá mức độ phân giải kết cấu vẫn có thể gây ra vấn đề
  • Bạn có thể xác định lượng tiêu thụ bộ nhớ đồ họa cho một kết cấu cụ thể bằng cách mở rộng danh mục Bộ nhớ đồ họa trong Bảng điều khiển nhà phát triển .

Giảm thiểu

• Chỉ tải tài sản một lần - Tái sử dụng cùng ID tài sản giữa các đối tượng và đảm bảo các tài sản tương tự, đặc biệt là khối và hình ảnh, không được tải riêng lẻ nhiều lần.
• Tìm và sửa các tài nguyên trùng lặp - Tìm các phần khối và kết cấu giống hệt được tải lên 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 sản tự động, bạn có thể thu thập tất cả các ID tài sản hình ảnh ở nơi của bạn (hoặc thủ công hoặc bằng một kịch 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 ngoài.
  • Đối với các bộ phận lưới, chiến lược tốt nhất là lấy các ID lưới duy nhất và sắp xếp chúng theo kích thước để xác định bản sao bằng tay.
  • Thay vì sử dụng các kết cấu riêng biệt cho các màu khác nhau, tải lên một kết cấu 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 tài sản vào bản đồ riêng biệt - Thay vì nhập toàn bộ bản đồ cùng một lúc, nhập và tái xây dựng tài sản trong bản đồ riêng lẻ và tái xây dựng chúng.Nhập khẩu 3D không thực hiện bất kỳ sao chép lặp lại khối lượng, vì vậy nếu bạn nhập khẩu một bản đồ lớn với nhiều tấm sàn riêng biệt, mỗi tấm sàn sẽ được nhập như một tài sản riêng (ngay cả khi chúng là bản sao).Điều này có thể dẫn đến các vấn đề về hiệu suất và bộ nhớ xuống dòng, vì mỗi mesh được xử lý như cá nhân và chiếm bộ nhớ và thực hiện cuộc gọi kéo.
• Giới hạn số пиксел của hình ảnh không quá số lượng cần thiết.Trừ khi hình ảnh chiếm một lượng lớn không gian vật lý trên màn hình, nó thường cần tối đa 512x512像素.Hầu hết các hình ảnh nhỏ hơn nên nhỏ hơn 256x256像素.
• Sử dụng Trim Sheets để đảm bảo tái sử dụng tối đa kết cấu trong bản đồ 3D.Đối với các bước và ví dụ về cách tạo bảng cắt, xem Tạo bảng cắt.

Thời gian tải lên

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

Lợi thế của phương pháp này là nó cho phép bạn đảm bảo các phần quan trọng của trải nghiệm của bạn được tải đầy đủ mà không bị bật lên.Tuy nhiên, một sai lầm phổ biến là lạm dụng phương pháp này để tải trước nhiều tài nguyên hơn là thực sự cần thiết.

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

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

• Hình ảnh trong màn hình tải.
• Hình ảnh quan trọng trong menu trải nghiệm của bạn, chẳng hạn như nền nút và biểu tượng.
• Tài sản quan trọng trong khu vực khởi động hoặc sinh sản.

Nếu bạn phải tải một lượng lớn tài sản, chúng tôi khuyên bạn nên cung cấp một nút Bỏ tải .