Performansı artır

Bu sayfa, yaygın performans sorunlarını ve bunları azaltmak için en iyi uygulamaları tanımlar.

Kod hesaplaması

Luau kodundaki pahalı işlemler işlenmesi daha uzun sürer ve böylece çerçeve oranını etkileyebilir.Paralel olarak çalışmıyorsa, Luau kodu senkronik olarak çalışır ve işlemciyi bloke edene kadar ana iş parçasını engeller.

Sıradan sorunlar

• Masa yapıları üzerinde yoğun işlemler - Seri çeviri, çözümleme ve derin kopyalama gibi karmaşık işlemler, özellikle büyük masa yapıları üzerinde yüksek performans maliyeti doğurur.Bu özellikle geçerlidir, eğer bu işlemler recursive ise veya çok büyük veri yapıları üzerinde döngü yapıyorsa.

• Yüksek frekanslı olaylar - Frekansı sınırlamadan pencere tabanlı olaylara pahalı işlemlerin bağlanması, bu işlemlerin her kare tekrarlanması, genellikle hesaplama süresinde gereksiz bir artışa neden olur.Bu olaylar şunları içerir:

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

Hafifletme

• Kodu RunService etkinliklerde dikkatli bir şekilde çağırın, yüksek frekanslı çağrının gerekli olduğu durumlara kullanımı sınırlayın (örneğin, kamerayı güncelleme).Diğer kodların çoğunu diğer etkinliklerde veya döngülerde daha az sıklıkla yürütebilirsiniz.
• Çalışmayı çok sayıda çerçeveye yaymak için task.wait() kullanarak büyük veya pahalı görevleri bölünüz.
• Gereksiz pahalı işlemleri tanımlayın ve optimize edin ve veri modeline erişmesi gerekmeyen yüksek maliyetli görevler için çok iş parçalı kullanın.
• Bazı sunucu tarafı kodları, native kod oluşturma yararlandırabilir, bir kodu bytecode yerine makine koduna derleyen basit bir bayrak.

MikroProfiler alanları

MicroProfiler kullanarak senaryoları depurmanın daha fazla bilgisi için, belirli kodları etiketleme ve daha fazla özelleştirme için fonksiyonları içeren debug kütüphanesine bakın, ki bunlar arasında debug.profilebegin ve debug.profileend gibi özelleştirme artışı da bulunmaktadır.Scriptler tarafından çağrılan birçok Roblox API yöntemi de yararlı sinyal sağlayabilen kendi ilişkili MikroProfiler etiketlerine sahiptir.

Senaryo hafıza kullanımı

Hafıza sızıntıları, çöp toplayıcısının artık kullanımda olmadığında doğru bir şekilde serbest bırakamayacağı hafızayı tüketen senaryolar yazarken meydana gelebilir.Sızıntılar, sunucuda özellikle yaygındır, çünkü bir müşteri oturumu çok daha kısa sürerken, sürekli olarak birçok gün boyunca çevrimiçi olabilirler.

Aşağıdaki hafıza değerleri Geliştirici Konsolu içinde, daha fazla araştırmaya ihtiyaç duyan bir sorunu gösterebilir:

• LuaHeap - Yüksek veya büyüyen tüketim bir bellek sızıntısı önerir.
• İstisna sayısı - Tutarlı bir şekilde büyüyen birçok istisna sayısı, kodunuzdaki bazı istisnalara referans verilmediğini göstermektedir.
• PlaceScriptMemory - Hafıza kullanımının kırılımına göre bir senaryo sağlar.

Sıradan sorunlar

• Bağlantıları bağlı bırakmak - Motor, bağlantılı geri çağrıya bağlı bir instansa ve bağlantı içinde referans edilen herhangi bir değere asla çöp toplaymaz.Bu nedenle, bağlı örnekler, bağlantılı işlevler ve referans edilen değerler içindeki etkin bağlantılar ve kodlar, olaylar ateş edildikten sonra bile hafıza toplucusunun kapsamı dışındadır.

  Bağlı oldukları örnek yok edildiğinde etkinlikler bağlantı kesilmiş olsa da, yaygın bir hata bu durumun Player nesneler için geçerli olduğunu varsaymaktır.Bir kullanıcı deneyimden ayrıldıktan sonra, motor otomatik olarak temsilcisinin nesne ve karakter modelinin objesini ve karakter modeli altındaki bağlantıları yok etmez, örneğin , sen onlara senaryolarında bağlantı kesmediğiniz sürece hala bellek tüketir.Bu, yüzlerce kullanıcının deneyime katılıp ayrılmasıyla sunucudaki çok önemli bellek sızıntılarına yol açabilir, çünkü zamanla.

• Masalar - Masalara nesneleri yerleştirmek ancak artık gerekmediğinde onları kaldırmamak, özellikle de kullanıcı verilerini izleyen masalar için gereksiz hafıza tüketimine neden olurÖrneğin, aşağıdaki kod örneği, bir kullanıcı katıldığında her seferinde kullanıcı bilgileri ekleyen bir tablo oluşturur:

  Örnek
  local playerInfo = {}
  Players.PlayerAdded:Connect(function(player)
      playerInfo[player] = {} -- bazı bilgiler
  end)

  Bu girişler artık gerekmediğinde bunları kaldırmazsanız, tablo büyüklüğü artar ve daha fazla kullanıcı oturuma katıldıkça daha fazla bellek tüketir.Bu tablo üzerinde dönen herhangi bir kod, tablo büyüdükçe daha fazla hesapsal olarak pahalı hale gelir.

Hafifletme

Hafıza sızıntılarını önlemek için tüm kullanılan değerleri temizlemek için:

• Tüm bağlantıları koparın - Kod tabanınızda her bağlantının aşağıdaki yolların birinden temizlendiğinden emin olun:

  • Manuel olarak Disconnect() işlevini kullanarak bağlantı kesiliyor.
  • Etkinliğin ait olduğu örneği Destroy() işleviyle yok ediyor.
  • Bağlantının geri gittiği senaryo nesnesini yok ediyor.

• Oyuncu nesnelerini ve karakterlerini çıktıktan sonra kaldırın - Bir kullanıcı ayrıldıktan sonra bağlantıların devam etmediğinden emin olmak için kodu uygulayın, örneğin aşağıdaki örnekte olduğu gibi:

  Örnek
  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)

Fizik hesaplaması

Aşırı fizik simülasyonu, sunucu ve istemci üzerinde her bir karede artan hesaplama süresinin ana nedeni olabilir.

Sıradan sorunlar

• Aşırı fizik zaman adımı frekansı -Varsayılan olarak, adım davranışı fiziğin zaman adımları 60 Hz, 120 Hz veya 240 Hz'de, fiziğin mekanizmasının karmaşıklığına bağlı olarak adaptif modda bulunur.

  Fiziğin geliştirilmiş doğruluğuyla sabit bir mod da mevcuttur, ki bu tüm fizik montajlarını 240 Hz'de (her karede dört kez) adım atmasını zorlar.Bu, her bir çerçevede önemli ölçüde daha fazla hesaplama yapar.

• Simüle edilen nesnelerin karmaşıklığının aşırı sayısı - Daha fazla 3D montaj simüle edilirse, fizik hesaplamaları her karede daha uzun sürer.Genellikle, deneyimlerin simüle edilmesi gereken nesneleri olacak veya ihtiyaç duymadıklarından daha fazla kısıtlayıcı ve eklemeleri olacak mekanizmalara sahip olacaklar.

• Aşırı kesin çarpışma tespiti - Mesh parçalarının çarpışmayı tespit etmek için bir CollisionFidelity özelliği vardır, çeşitli performans etkisi seviyelerine sahip çeşitli modları tespit eden çarpışma özelliği.Dokuma parçaları için kesin çarpışma algılama modu en pahalı performans maliyetine sahiptir ve motorun hesaplanması daha uzun sürer.

Hafifletme

• Simülasyon gerektirmeyen bağlantı parçaları - Statik NPC'ler gibi fiziğin sürülmesi gerekmeyen tüm parçaları sabitleyin

• Adaptif fiziğin adımlarını kullanın - Adaptif adımlar, bazı durumlarda fizik mekanizmaları için fizik hesapları oranını daha az sıklıkla ayarlar, böylece fizik güncellemeleri daha az sıklıkla yapılabilir.

• Mekanizma karmaşıklığını azalt * Mümkün olduğunda, bir montajdaki fizik sınırlarının veya bağların sayısını azaltın.

  • Kendi aralarında çarpışmalarını engellemek için sınırlar veya çarpışma kısıtlamaları uygulayarak bir mekanizmanın içindeki kendi çarpışma miktarını azaltın, örneğin ragdoll uzuvlarına.

• Dokular için hassas çarpışma sadakatinin kullanımını azaltın * Kullanıcılar nadiren farkı fark edecekleri küçük veya etkileşimli olmayan nesneler için, kutu sadakati kullanın.

  • Küçük orta boyutlu nesneler için, şekil göre kutu veya gövde sadakatini kullanın.

  • Büyük ve çok karmaşık nesneler için, mümkün olduğunda görünmez parçalar kullanarak özel çarpışmalar oluşturun.

  • Çarpışma gerektirmeyen nesneler için, çarpışmaları devre dışı bırakın ve kutu veya gövde sadakati kullanın, çünkü çarpışma geometrisi hala hafızada saklıdır.

  • 3B görüntü penceresinin üst sağ köşesindeki Görüntüleme seçenekleri düzeneğinden çarpışma sadakati açarak Studio'da sorun giderme için çarpışma geometrisini renderlayabilirsiniz.

    Alternatif olarak, tüm doku parçalarının hassas sadakati ile bir sayı gösteren CollisionFidelity = Precise 'e filtre uygulayabilirsiniz ve bunları kolayca seçebilirsiniz.

  • Precision ve performance gereksinimlerinizi dengeleyen bir çarpışma sadakat seçeneği seçme konusunda derin bir bakış için, Fizik ve renderleme parametlerini ayarla bakın.

MikroProfiler alanları

Fizik bellek kullanımı

Fizik hareketi ve çarpışma algılaması belleği tüketir.Dokuma parçalarının CollisionFidelity bir özelliği vardır, çarpışma sınırlarını değerlendirmek için kullanılan yaklaşımı belirler.

Sıradan sorun

Varsayılan ve hassas çarpışma tespit modları, daha düşük sadakat çarpışma şekillerine sahip diğer iki moddan önemli ölçüde daha fazla bellek tüketir. FizikParçaları altında yüksek düzeyde hafıza tüketimi görürseniz, deneyiminizdeki nesnelerin çarpışma sadakati azaltmasını araştırmanız gerekebilir.

Nasıl azaltılır

Çarpışma sadakati için kullanılan belleği azaltmak için:

• Çarpışmaya ihtiyaç duymayan parçalar için, çarpışmalarını BasePart.CanCollide , BasePart.CanTouch ve BasePart.CanQuery 'e ayarlayarak devre dışı bırakın false .
• CollisionFidelity ayarını kullanarak çarpışma sadakatini azaltın.Box en düşük bellek üzerini vardır ve Default ve Precise genellikle daha pahalıdır.

  • Genellikle herhangi bir küçük sabitlenmiş parçanın çarpışma sadakati Box 'ye ayarlanması güvenlidir.
  • Çok karmaşık büyük meshlar için, kutu çarpışma sadakati ile daha küçük nesnelerden kendi çarpışma meshenizi oluşturmak isteyebilirsiniz.

İnsansılar

Humanoid oyuncuya ve oyuncu olmayan karakterlere (NPC'ler) geniş bir yelpaze sağlayan bir sınıftır.Güçlü olmasına rağmen, bir Humanoid önemli bir hesap maliyeti ile birlikte gelir.

Sıradan sorunlar

• NPC'lerde tüm HumanoidStateTypes türlerinin etkin kalmasını bırakmak - Belirli HumanoidStateTypes etkinleştirilmiş bırakılmasına performans maliyeti var.NPC'leriniz için gerekli olmayanları devre dışı bırakın.Örneğin, NPC'niz merdivenlere tırmanmayacaksa, Climbing durumunu devre dışı bırakmak güvenlidir.
• Sık sık insanoidlerle modelleri oluşturma, değiştirme ve yeniden doğurma * Bu, motorun işlemesi için yoğun olabilir, özellikle bu modeller katmanlı kıyafetler kullanıyorsa .Ayrıca, avatarların sık sık yeniden doğduğu deneyimlerde özellikle sorunlu olabilir.

  • MikroProfiler içinde, uzun updateInvalidatedFastClusters etiketleri (4 ms'den fazla) genellikle avatarın anlıklaştırılması/modifiye edilmesinin aşırı geçersizlikleri tetiklediğine dair bir sinyaldir.
• Gerekmediği durumlarda insanoidleri kullanmak - Genel olarak hareket etmeyen statik NPC'lerin Humanoid sınıfına ihtiyacı yoktur.
• Sunucudan büyük sayıda NPC'de animasyon oynama - Sunucudaki çalışan NPC animasyonlarının sunucuda simüle edilmesi ve müşteriye yeniden yansıtılması gerekir.Bu gereksiz yük olabilir.

Hafifletme

• Müşteride NPC animasyonlarını oynatın - Büyük sayıda NPC'ye sahip deneyimlerde, müşteride Animator oluşturmayı ve animasyonları yerel olarak çalmayı düşünün.Bu, sunucudaki yükü azaltır ve gereksiz yeniden yazma gereksinimini ortadan kaldırır.Ayrıca ek optimizasyonlar da mümkün kılar (örneğin, karakterin yakınındaki NPC'ler için sadece animasyon oynatmak gibi).
• Humanoids'e performans dostu alternatifler kullanın - NPC modellerinin mutlaka bir insansız nesne içermesi gerekmez.

  • Statik NPC'ler için basit bir AnimationController kullanın, çünkü etrafında hareket etmeleri gerekmiyor, sadece animasyon oynatmaları gerekiyor.
  • NPC'leri hareket ettirmek için, kendi hareket kontrolörünüzü uygulayın ve NPC'lerinizin karmaşıklığına bağlı olarak animasyonlar için bir AnimationController kullanın.
• Kullanılmayan insansız durumları devre dışı bırakın - Her insansız için sadece gerekli durumları etkinleştirmek için Humanoid:SetStateEnabled() kullanın
• Sık sıfırlayan havuz NPC modelleri - NPC'yi tamamen yok etmek yerine, NPC'yi aktif olmayan bir NPC havuzuna gönderin.Bu şekilde, yeniden doğmak için yeni bir NPC gerekli olduğunda, havuzdan bir NPC'nin yeniden etkinleştirilmesini sağlayabilirsiniz.Bu süreç, karakterlerin uygulanması gereken süre miktarını azaltan birleştirme olarak adlandırılır ve karakterlerin uygulanmasını azaltır.
• Yalnızca kullanıcılar yakında olduğunda NPC'leri oluşturun - Kullanıcılar menzilde değilken NPC'leri oluşturmayın ve menzillerinden ayrıldıklarında onları toplayın.
• Avatar hiyerarşisine oluşturulduktan sonra değişiklik yapmaktan kaçının - Bir avatar hiyerarşisine yapılan bazı değişiklikler önemli performans etkilerine sahiptir.Bazı optimizasyonlar mevcuttur:

  • Özel prosedürel animasyonlar için, JointInstance.C0 ve JointInstance.C1 özelliklerini güncellemeyin. Bunun yerine, Motor6D.Transform özelliğini güncelleştirin.
  • Avatara herhangi bir BasePart nesneyi bağlamanız gerekiyorsa, bunu avatarın hiyerarşisinin dışında yapın Model .

MikroProfiler alanları

Kare hareketi

Müşterinin her kareyi harcadığı sürenin önemli bir kısmı, sahneleri mevcut çerçevede renderlemedir.Sunucu herhangi bir renderleme yapmaz, bu nedenle bu bölüm müşteriye özeldir.

Çağrıları çizme

Bir çekme çağrısı, motorun GPU'ya bir şeyi görselleştirmek için bir dizi talimat olduğunu.Çekme çağrılarının önemli bir yükü vardır.Genel olarak, çerçeveye daha az çekme çağrısı yapılırsa, bir çerçeveyi renderleme için daha az hesaplama süresi harcanır.

Stüdyoda şu anda kaç çizim çağrısının gerçekleştiğini görebilirsiniz Render İstatistikleri > Zamanlama öğesi ile.Render İstatistiklerini görebilirsiniz istemciye basarak .

Bir sahnede belirli bir çerçevede çizilmesi gereken nesne sayısı arttıkça, GPU'ya daha fazla çizme çağrısı yapılır.Ancak, Roblox Motoru aynı dokuma özellikleri ile aynı meshları tek bir çekme çağrısına katlamak için yerleştirme sürecini kullanır.Özellikle, aynı MeshId ile çok sayıda çizim aynı çekme çağrısında ele alınırken:

• SurfaceAppearances aynıdır. TextureIDs``Class.SurfaceAppearance yok olduğunda aynıdır.
• Malzemeler her ikisi de SurfaceAppearance ve MeshPart.TextureID mevcut olmadığında aynıdır.

Diğer yaygın sorunlar

• Aşırı nesne yoğunluğu - Eğer büyük sayıda nesne yüksek yoğunlukla konsantre edilirse, sahnedeki bu alanın renderlenmesi daha fazla çekme çağrısı gerektirir.Haritanın belirli bir kısmına baktığınızda çerçeve hızınız düşüyorsa, bu alandaki nesne yoğunluğunun çok yüksek olduğu iyi bir sinyal olabilir.

  Resimler, dokular ve parçacıklar gibi nesneler iyi bir şekilde gruplanmaz ve ek çekme çağrıları tanıtır.Bir sahnede bu nesne türlerine ekstra dikkat edin.Özellikle, ParticleEmitters özellik değişiklikleri performans üzerinde dramatik bir etkiye sahip olabilir.

• Kaçırılan yerleştirme fırsatları - Sıklıkla, bir sahne aynı meshi birkaç kez tekrarlayacak, ancak her mesh kopyasının farklı mesh veya doküman kimlikleri vardır.Bu, örneklemeyi engeller ve gereksiz çekme çağrılarına yol açabilir.

  Bu sorunun yaygın bir nedeni, bir seansın bir kerede tümüyle ithal edilmesi, bireysel varlıkların Roblox'a ithal edilmesi ve ardından sahneyi birleştirmek için post-import yapılmasıdır.

• Aşırı nesne karmaşıklığı - Çekme çağı sayısı kadar önemli olmasa da, bir sahnedeki üçgen sayısı, bir çerçevenin renderlanmasının ne kadar süreceğini etkiler.Çok büyük sayıda çok karmaşık meshe sahip sahneler çok yaygın bir sorundur, çünkü çok fazla sayıda meshe üzerinde MeshPart.RenderFidelity özellik seti ile Enum.RenderFidelity.Precise ayarlanmış sahneler de vardır.

• Aşırı gölge atışı - Gölgeleri işlemek pahalı bir süreçtir ve gölgeleri atan yüksek sayı ve yoğunlukta ışık nesneleri bulunduran haritalar (veya gölgelerin etkilediği küçük parçaların yoğunluğu yüksek) performans sorunlarına sahip olma olasılığı yüksektir.

• Yüksek saydamlık aşırı yükleme - Kısmi saydamlıkla nesneler yerleştirmek, motorun aşırı pikselleri birden fazla kez göstermesini zorlar, ki bu performansı zarar verebilir.Bu sorunu tanımlama ve düzeltmeye ilişkin daha fazla bilgi için, Katmanlı saydamlıkları silme bakın.

Hafifletme

• Aynı meshlere yerleştirme ve benzersiz meshelerin miktarını azaltma - Tüm aynı meshelerin aynı temel varlık kimliklerine sahip olduğundan emin olursanız, motor bunları tek bir çekme çağrısında tanıyabilir ve görüntüleyebilir.Her bir meshi bir haritaya yalnızca bir kez yüklediğinizden emin olun ve ardından büyük haritaları bütün olarak ithal etmek yerine Studio'da yeniden kullanmak için onları kopyalayın, böylece benzersiz meshlar ayrı içerik kimliklerine sahip olur ve motor tarafından benzersiz olarak tanınır.Paketler nesne yeniden kullanımı için yararlı bir mekanizmadır.
• Toplama - Toplama, son olarak görüntülenen çerçeveye dahil olmayan nesneler için çekme çağrılarının kaldırılması sürecini tanımlarVarsayılan olarak, motor, kameranın görüş alanının dışındaki nesneler için çekme çağrılarını atlar (frustum kazıcı), ancak diğer nesneler tarafından görüşten kapatılan nesneler için çekme çağrılarını atlamaz (görüş kazıcı).Sahnanızın çok sayıda çekme çağrısı varsa, aşağıdaki yaygın stratejiler gibi dinamik olarak her kare için kendi ek seçiminizi uygulamayı düşünün:

  • Kameradan veya ayarlardan uzak olan MeshPart ve BasePart gizle
  • İç ortamlar için, şu anda hiçbir kullanıcı tarafından kullanılmayan nesneleri gizleyen bir oda veya portal sistemi uygulayın.
• Render sadakati azaltma - Render sadakatini Otomatik veya Performans olarak ayarlayın.Bu, örüntülerin daha az karmaşık alternatiflere geri dönmesine izin verir, bu da çizilmesi gereken poligon sayısını azaltabilir.
• Uygun parçalarda ve ışık nesnelerinde gölge atmayı devre dışı bırakma - Sahnedeki gölgelerin karmaşıklığı, ışık nesneleri ve parçalarda gölge atma özelliklerini seçerek devre dışı bırakarak azaltılabilir.Bu, düzenleme sırasında veya çalışma sırasında dinamik olarak yapılabilir.Bazı örnekler:

  • Gölgelerin görülebileceği olasılığı düşük olan küçük parçalarda gölge atışını devre dışı bırakmak için BasePart.CastShadow özelliğini kullanın.Bu özellikle kullanıcının kamerasından uzakta bulunan parçalara uygulandığında etkili olabilir.

    Bu, gölgeler üzerinde görsel eserlere neden olabilir.

  • Mümkün olduğunda hareket eden nesnelerde gölgeleri devre dışı bırakın.

  • Nesnenin gölge atması gerekmediği hafif örneklerde Light.Shadows kapatın.

  • Işık instanslarının menzilini ve açısını sınırla.

  • Daha az ışık örneği kullanın.

MikroProfiler alanları

Ağ ve yeniden yazma

Ağ ve yeniden yazma, verilerin sunucu ve bağlı istemciler arasında gönderildiği süreci tanımlar.Her karede istemci ve sunucu arasında bilgi gönderilir, ancak daha fazla bilgi daha fazla hesaplama süresi gerektirir.

Sıradan sorunlar

• Aşırı uzaktan trafik - RemoteEvent veya RemoteFunction nesneler aracılığıyla çok miktarda veri göndermek veya onları çok sık çağırmak, her bir çerçevede gelen paketleri işlemek için çok fazla CPU süresi harcanmasına yol açabilir.Sıradan hatalar şunları içerir:

  • Yeniden yapılması gerekmeyen her karede verileri yeniden yapmak.
  • Verileri sınırlandırmak için herhangi bir mekanizma olmadan kullanıcı girişinde yeniden yazmak.
  • Gerekenden fazla veri gönderiliyor.Örneğin, oyuncunun satın aldığı bir öğenin sadece satın alınan öğenin detayları değil tüm envanterini göndermek.

• Karmaşık istemci ağaçlarının oluşturulması veya kaldırılması - Sunucudaki veri modeline bir değişiklik yapıldığında, bağlı müşterilere yeniden yansıtılır.Bu, çalışma sırasında haritalar gibi büyük istemci-sunucu hierarşilerinin oluşturulması ve yok edilmesinin çok ağ yoğun olabileceğini ifade eder.

  Buradaki ortak suçlu, animasyon editörü eklentileri tarafından kaydedilen karmaşık animasyon verileridir.Bu unsurlar oyun yayınlanmadan önce kaldırılmaz ve animasyonlu model düzenli olarak klonlanırsa, çok miktarda veri gereksiz yere yeniden yazılacaktır.

• Sunucu tarafı TweenService - Eğer TweenService bir nesne sunucu tarafında dönüştürülürse, dönüştürülmüş özellik her karede her bir istemciye yeniden yazılır.Sadece bu sonuç, gençlerin müşterilerin gecikme süreleri değiştiğinde gergin olmasına neden olmaz, ayrıca çok fazla gereksiz ağ trafiğine neden olur.

Hafifletme

Gereksiz yeniden yazma azaltmak için aşağıdaki taktikleri kullanabilirsiniz:

• Tek seferde büyük miktarda veri göndermekten uzak olaylar aracılığıyla kaçının .Bunun yerine, sadece gerekli verileri daha düşük frekansla gönderin.Örneğin, bir karakterin durumu için, her kare değişmeden önce onu yeniden yapın.
• Komple istemci ağaçlarını parçalara ayırın ve bunları birden fazla çerçevede yeniden yapma işini dağıtmak için parçalar halinde yükle gibi haritalar ve bunları dağıtın.
• Animasyon metadatlarını temizle , özellikle kıvrımların animasyon dizinini, ithal edildikten sonra.
• Gereksiz istisna örnek yeniden yazma sınırı , özellikle sunucunun oluşturulan örneklerin bilgisine sahip olması gerekmediği durumlardaBuna dahil olanlar:

  • Bir patlama veya sihirli bir büyü patlaması gibi görsel efektler.Sunucunun sadece sonucu belirlemek için konumu bilmesi gerekir, while müşteriler yerel olarak görüntüler oluşturabilir.
  • İlk kişi öğe görüntüleme modelleri.
  • Sunucu yerine istemci üzerindeki genç nesneler.

MikroProfiler alanları

Varlık hafıza kullanımı

Yaratıcıların istemci bellek kullanımını geliştirmek için kullanabileceği en yüksek etki mekanizması, İstemci yayıncılığını etkinleştirmek dir.

Instans yayını

Instans yayını, gerekli olmayan veri modeli parçalarını seçerek yükler, ki bu, daha az yük süresine ve hafıza baskısı altında olduğunda müşterinin çökmeyi engelleme yeteneğinin artmasına yol açabilir.

Hafıza sorunlarıyla karşılaşıyor ve örnek yayını devre dışıysa, deneyiminizi güncelleyerek desteklemeyi düşünün, özellikle 3B dünyanız genişse.Instans yayınları 3B uzaydaki mesafeye dayanır, bu nedenle daha büyük dünyalar doğal olarak bundan daha fazla yararlanır.

Örnek yayını etkinleştirildiğinde, saldırganlığını artırabilirsiniz. Örneğin, şunu düşünün:

• Kalıcı kullanımı azaltmak için Yayın Kalitesi kullanılıyor.
• Yayın yarıçapını azaltmak .

Yayın seçenekleri ve faydaları hakkında daha fazla bilgi için, Yayın özellikleri bakın.

Diğer yaygın sorunlar

• Varlık kopyalanması - Yaygın bir hata, aynı varlığı farklı varlık kimliklerine yüklemekten kaynaklanır.Bu, aynı içeriklerin birden çok kez hafızaya yüklenmesine yol açabilir.
• Aşırı varlık hacmi - Varlıklar aynı olmadığında bile, aynı varlığı yeniden kullanma ve hafızayı kurtarma fırsatları kaçırılır durumlar vardır.
• Ses dosyaları - Ses dosyaları, özellikle deneyimin bir kısmı için ihtiyacınız olan şeyi yüklemeden hepsini müşteriye aynı anda yükleyerek hafıza kullanımına şaşırtıcı bir katkı olabilir.Stratejiler için, Yükleme süreleri görün.
• Yüksek çözünürlüklü dokular - Bir dokunun grafik bellek tüketimi diskteki dokunun boyutuyla ilgili değildir, ancak dokunun piksel sayısıdır.

  • Örneğin, 1024x1024 piksel dokusu, 512x512 dokunun grafik belleğinin dört katını tüketir.
  • Roblox'a yüklenen görüntüler sabit bir biçime dönüştürülür, bu nedenle daha az piksel başına düşen bayt sayısıyla ilişkili bir renk modelinde görüntü yükleme için hafıza avantajı yoktur.Benzer şekilde, yüklemeden önce görüntüleri sıkıştırmak veya alfa kanalına ihtiyaç duymayan görüntülerden alfa kanalını kaldırmak, diskin görüntü boyutunu azaltabilir, ancak ya geliştirmez ya da sadece hafifçe bellek kullanımını artırır.Motor bazı cihazlarda dokunma çözünürlüğünü otomatik olarak düşürse de, küçültmenin ölçeği cihaz özelliklerine bağlıdır ve aşırı dokunma çözünürlüğü hala sorunlara neden olabilir.
  • Belirli bir dokunun grafik bellek tüketimini tanımlayabilirsiniz, Grafik Dokusu kategorisini Geliştirici Konsoluna genişleterek.

Hafifletme

• Sadece bir kez varlıkları yükle - Aynı varlık kimliğini nesneler arasında yeniden kullanın ve aynı varlıklar, özellikle mesheler ve görüntüler, ayrı ayrı birden fazla kez yüklenmediğinden emin olun.
• Aynı özelliklere sahip yinelenen varlıkları bul ve düzelt - Farklı kimliklerle birden fazla kez yüklenen benzer mesh parçalarını ve dokuları arayın.

  • Benzerlikleri otomatik olarak tespit eden bir API olmasa da, yerinizdeki tüm görüntü varlık kimliklerini toplayabilirsiniz (manuel olarak veya bir senaryo ile), indirebilir ve dış karşılaştırma araçlarını kullanarak karşılaştırabilirsiniz.
  • Kafes parçaları için, en iyi strateji benzersiz kafes kimliklerini almak ve bunları boyuta göre düzenlemek, böylece yedekleri manuel olarak tanımlamak için.
  • Farklı renkler için ayrı dokular kullanmak yerine, tek bir dokuyu yükle ve çeşitli tonlar uygulamak için SurfaceAppearance.Color özelliğini kullan.
• Haritaya ayrı olarak varlıkları ithal et - Tek seferde bütün bir haritayı ithal etmek yerine, haritadaki varlıkları bireysel olarak ithal edin ve yeniden yapılandırın.3B ithalatçı, dokuların hiçbir kopyalanmasını yapmaz, bu nedenle eğer büyük bir haritayı birçok ayrı zemin ile ithal ederseniz, bu zeminlerin her biri ayrı bir varlık olarak ithal edilir (yine de bunlar kopyalarsa).Bu, çizgide performans ve hafıza sorunlarına yol açabilir, çünkü her bir mesh bireysel olarak ele alınır ve hafıza ve çekme çağrıları alır.
• Görüntü piksel sayısını gerekli miktardan fazla sınırla görüntülerin piksel sayısını sınırla.Bir görüntü ekranda büyük bir miktar fiziksel alanı kaplıyor olmadığı sürece, genellikle en fazla 512x512 piksel gerekir.En az önemli görüntüler 256x256 pikselden daha küçük olmalıdır.
• 3B haritalarda maksimum doku yeniden kullanımını sağlamak için kenar çizgilerini kullanın Kesme sayfaları nasıl oluşturulacağına dair adımlar ve örnekler için, Kesme sayfaları oluşturma bakın.

Yükleme süreleri

Birçok deneyim özel yükleme ekranları uygular ve varlıkları talep etmek için ContentProvider:PreloadAsync() yöntemini kullanarak görüntüler, sesler ve dokular arka planda indirilir.

Bu yaklaşımın avantajı, deneyiminizin önemli bölümlerinin pop-in olmadan tamamen yüklendiğinden emin olmanıza izin vermesidir.Ancak, yaygın bir hata, aslında gerekli olmayan daha fazla varlık ön yükleme için bu yöntemi aşırı kullanmaktır.

Kötü bir uygulamanın örneği, tüm Workspace 'yi yüklemektir. Doku patlamasını engelleyebilir, ancak yükleme süresini önemli ölçüde artırır.

Bunun yerine, gerekli durumlarda sadece ContentProvider:PreloadAsync() kullanın, bunlar şunları içerir:

• Yükleme ekranındaki görüntüler.
• Buton arka planları ve simgeler gibi deneyim menünüzde önemli görüntüler.
• Başlangıç veya oluşturma alanındaki önemli varlıklar.

Eğer çok sayıda varlık yüklemeniz gerekiyorsa, Yüklemeyi Atla düğmesi sağlamanızı öneririz.