Nâng cao hiệu suất

*Nội dung này được dịch bằng AI (Beta) và có thể có lỗi. Để xem trang này bằng tiếng Anh, hãy nhấp vào đây.

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 tiền trong mã Luau mất nhiều thời gian hơn để 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 sản xuất luồng.

Vấn đề thông thường

  • 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 qua 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 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 tính toán.Các sự kiện này bao gồm:

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 mà lời gọi thường xuyên là cần thiết (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 thường xuyên hơn ít 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 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 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 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 MicroProfiler

Phạm viTính toán liên quan
Chạy dịch vụ.PreRenderMã thực thi trên sự kiện PreRender
Chạy dịch vụ.PreSimulationMã thực thi trên sự kiện Stepped
Chạy dịch vụ.PostSimulationMã thực thi trên sự kiện Heartbeat
Chạy dịch vụ.HeartbeatMã thực thi trên sự kiện Heartbeat

Để 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 hơn nữa, 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 riêng của 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 được sử dụng.Các rò rỉ là cụ thể 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 cho thấy 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ởi sự phân tích khối lượng sử dụng bộ nhớ của kịch bản.

Vấn đề thông thường

  • 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 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ết nối.Do đó, 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 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ã mẫu sau đây 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 tốn 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 ngày càng lớn hơn.

Giảm thiểu

Để xóa tất cả các giá trị đã 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 thủ công bằng chức năng Disconnect() .
    • Phá hủy instance thuộc về sự kiện 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, 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 đề thông thường

  • 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 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 độ tác độ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 khố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

  • Phần neo không cần phải mô phỏng - Neo tất cả các 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ý được thực hiện thường xuyên hơn trong một số trường hợp.

  • Giảm phức tạp của cơ chế * Nếu có thể, hãy giảm số lượng hạn chế vật lý hoặc khớp trong một lắp rá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 yêu cầu không 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 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 sự trung thành 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=PreciseConvexDecomposition cho Explorer mà hiển thị số lượng tất cả các phần mesh với độ chính xác 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, xem Set physics and rendering parameters .

Phạm vi MicroProfiler

Phạm viTính toán liên quan
vật lýSteppedTính toán vật lý tổng thể
bước thế giớiCác bước vật lý rời rạc được thực hiện mỗi khung

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 định nghĩa 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 thụ nhiều bộ nhớ hơn hai chế độ khác với hình dạng va chạm chính xác 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 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 thiểu

Để 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 sự trung thành 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 khổng lồ

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 đề thông thường

  • 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 được bật.Vô hiệu hóa bất kỳ thứ nào 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.
  • Kích hoạt, 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 nhiều thời gian 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 khó khăn trong những trải nghiệm mà avatar thường xuất hiện lại.
    • Trong MicroProfiler , các thẻ cập nhậtInvalidatedFastClusters dài (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à chi phí 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.Điều 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 tĩnh, hãy sử dụng một đơn giản AnimationController , bởi 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 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 các 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 tá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ồ NPC không hoạt động.Theo 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ừ hồ bơi.Quá trình này được gọi là gộp, làm giảm số lần các nhân vật cần được khởi tạo.
  • Chỉ sinh NPC khi người dùng ở gần - Không sinh 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ố tối ưu hóa có sẵn:
    • Đối với các hoạt hình 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 như vậy ngoài cấp bậc của avatar Model .

Phạm vi MicroProfiler

Phạm viTính toán liên quan
bướcHumanoidĐiều khiển và vật lý humanoid
bướcAnimationHumanoid và hoạt hình của animator
cập nhậtInvalidatedFastClustersLiên quan đến việc khởi tạo hoặc sửa đổi một avatar

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ập trường

Một cuộc gọi kéo là một bộ hướng dẫn từ động cơ đến GPU để vẽ một cái gì đó.Các cuộc gọi kéo có chi phí lớn.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 chi tiêu để render 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 trong Studio.Bạn có thể xem Thống kê render 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 cho 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 giống nhau 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:

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 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ư decal, 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.Chú ý đặc biệt đến các loại đối tượng này trong một 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 vẽ 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 từng 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.

    Ngay cả một kịch bản đơn giản như thế này cũng có thể giúp bạn xác định các phần mesh có cùng tên sử dụng các ID mesh khác nhau:

    local Workspace = game:GetService("Workspace")

    for _, descendant in Workspace:GetDescendants() do

      if descendant:IsA("MeshPart") then

        print(descendant.Name .. ", " .. descendant.MeshId)

      end

    end

    Kết quả (với Dòng chồng bật) có thể trông giống như thế này.Các dòng lặp lại cho thấy sử dụng lại cùng một lưới, điều này tốt.Các dòng duy nhất không nhất thiết phải xấu, nhưng tùy thuộc vào chế độ đặt tên của bạn, có thể chỉ ra các khối lượng trùng lặp trong trải nghiệm của bạn:

    LargeRock, rbxassetid://106420009602747 (x144) -- good

    LargeRock, rbxassetid://120109824668127

    LargeRock, rbxassetid://134460273008628

    LargeRock, rbxassetid://139288987285823

    LargeRock, rbxassetid://71302144984955

    LargeRock, rbxassetid://90621205713698

    LargeRock, rbxassetid://113160939160788

    LargeRock, rbxassetid://135944592365226 -- all possible duplicates

  • Sự phức tạp của đối tượng vượt quá - Mặc dù không quan trọng như số lượng cuộc gọi vẽ, số lượng tam giác trong một cảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnh ảnhCả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 vào 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 đối tượng phát bóng (hoặc một số lượng lớn và độ mờ của các 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 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 lượng trong bản đồ một lần và sau đó sao chép chúng trong Studio để tái sử dụng chứ không phải 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 lượng giống nhau 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 có yếu tố trong 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 nằm ngoài lĩnh vực 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 đây:
    • Ẩ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 không được chiếm bởi bất kỳ người dùng nào.
  • Giảm độ chính xác render - Đặt độ 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ố polygons 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 tính năng phát bóng bóng trên các đối tượng ánh sáng và bộ phận cụ thể.Điều 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ụ là:

    • Sử dụng thuộc tính BasePart.CastShadow để vô hiệu hóa phát bóng lên các bộ 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 ở xa camera của người dùng.

    • 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 phát ra 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.

    • Xem xét vô hiệu hóa ánh sáng nằm ngoài phạm vi cụ thể hoặc dựa trên cơ sở phòng trong môi trường nội địa.

Phạm vi MicroProfiler

Phạm viTính toán liên quan
Chuẩn bị và thực hiệnXử lý tổng thể
Thực hiện/Cảnh/chiếu sáng thực hiệnCập nhật lưới ánh sáng và bóng tối
Bộ xử lý LightGrid CPUCập nhật lưới ánh sáng Voxel
Hệ thống Bản đồ Bóng tốiBản đổ bóng
Thực hiện/Cảnh/Cập nhật ViewChuẩn bị cho việc render và cập nhật hạt
Thực hiện/Cảnh/RenderViewXử lý và xuất hiện hình ảnh

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

Kết nối và sao chép 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 đề thông thường

  • 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.Các 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 về mặt hàng đã mua.

  • Tạo hoặc xóa cây instance phức tạp - Khi có một thay đổi được thực hiện đố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 biên tập 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 sao chép 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 tween đượ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 sao lưu 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 với 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 chép 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ình , đặc biệt là thư mục hoạt hình của các mô hình, sau khi nhập.
  • Giới hạn sao chép instance 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 instance đang được tạo.Điều này bao括:
    • 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 khách hàng có thể tạo hình ảnh địa phương.
    • Mô hình xem đồ vật 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 MicroProfiler

Phạm viTính toán liên quan
Gói quá trìnhXử lý các gói mạng nhận được, chẳng hạn như lời kêu gọi sự kiện và thay đổi tính chất
Gán băng thông và chạy các máy gửiSự kiện ra ngoài liên quan đến các máy chủ

Sử dụng 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 phát trực tiếp .

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

Phát trực tiếp trường hợp chọn lọc tải các 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ó đến dưới áp lực 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ên cơ sở 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 từ nó.

Nếu phát trực tiếp trường hợp đượ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 trực tuyến **** .

Để 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 cùng một tài sả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 cùng một nội dung được tải vào bộ nhớ nhiều lần.
  • Tăng quá mức 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 khách hàng 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 cũ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 thu nhỏ 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 lượng 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 sả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 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 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 trong 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 của 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 tấm cắt để đả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.

    Bạn cũng có thể xem xét sử dụng các tờ sprite để tải nhiều hình ảnh UI nhỏ hơn là một hình ảnh duy nhất.Bạn có thể sử dụng ImageLabel.ImageRectOffset và ImageLabel.ImageRectSize để hiển thị một phần của tờ bảng.

Thời gian tải

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 cần 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 tồi là tải 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, nó làm tăng đáng kể thời gian tải.

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.
  • 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 .