Performansı artır

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

Senaryo hesaplamasi

Luau kodundaki pahalı işlemlerin işlenmesi daha uzun sürer ve böylece çerçeve oranını etkileyebilir.Paralel olarak çalışmıyorsa, Luau kodu eşzamanlı olarak çalışır ve işlemciyi içeren bir işlevle karşılaşana kadar ana işlemi engeller.

Sıradan sorunler

• 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 veya çok büyük veri yapıları üzerinde döngüsel olarak gerçekleşirse.

• 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 etkinlikler şunları içerir:

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

Hafifleme

• Kodu RunService etkinliklerde dikkatli bir şekilde çağırın, yüksek frekanslı çağrının gerekli olduğu durumlara kullanımı sınırlandırın (örneğin, kamera güncellenmesi).Diğer kodların çoğunu başka etkinliklerde veya döngülerde daha az sıklıkla yürütebilirsiniz.
• Çalışmayı birden fazla ç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ı yapımı kullanın.
• Bazı sunucu tarafı kodları, native kod oluşturma yararlandırabilir, bir kodu bytecode yerine makine koduna derleyen basit bir bayrak.

MikroProfiler özellikleri

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, örneğin debug.profilebegin ve debug.profileend gibi.Scriptler tarafından çağrılan birçok Roblox API yöntemi de yararlı sinyal sağlayabilen kendi ilişkili MikroProfil 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 yazdığınızda 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 bellek 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 sorunler

• 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 nesneleri 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 , eğer onları senaryolarınızda bağlantı kesmediğiniz takdirde hala bellek tüketir.Bu, yüzlerce kullanıcının deneyime katılıp ayrılmasıyla sunucuda zamanla çok önemli bellek sızıntılarına neden olabilir.

• 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ı bilgilerini ekleyen bir tablo oluşturur:

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

  Bu girişler artık gerekmediğinde bunları kaldırmazsanız, tablo boyutu 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.

Hafifleme

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

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

  • Disconnect() fonksiyonunu kullanarak manuel olarak 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:

  Örnekler
  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 hesaplama

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

Sıradan sorunler

• 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 adım atmasını zorlar (her karede dört kez).Bu, her bir çerçevede önemli ölçüde daha fazla hesaplama yapar.

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

• Aşırı kesin çarpışma tespiti - Mesh parçalarının, performans etkisi farklı seviyelerde çeşitli modları algılayan bir çarpışma tespit etmek için bir CollisionFidelity.Dokuma parçaları için hassas çarpışma algılama modu, en pahalı performans maliyetine sahiptir ve motorun hesaplanması daha uzun sürer.

Hafifleme

• 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ın * Mümkün olduğunda, bir montajdaki fizik kısıtları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 sadakati kullanımını azaltın * Kullanıcılar nadiren farkı fark edecek olan küçük veya etkileşimli olmayan nesneler için, kutu sadakati kullanın.

  • Küçük orta boyutlu nesneler için, şekline bağlı olarak kutu veya gövde sadakatini kullan.

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

  • 3D görüntü penceresinin üst sağ köşesindeki Görselleştirme Seçenekleri düzeneğinden çarpışma sadakati 'yi açarak Studio'da hata ayıklama amaçlı çarpışma geometrisini görüntüleyebilirsiniz.

    Alternatif olarak, tüm doku parçalarının hassas sadakatle bir sayısını gösteren Explorer filtresini uygulayabilir ve bunları kolayca seçebilirsiniz.

  • Doğruluk ve performans 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 özellikleri

Fizik bellek kullanımı

Fizik hareketi ve çarpışma algılaması belleği tüketir.Kafes 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.

Ortak sorun

Varsayılan ve hassas çarpışma algılama 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 azaltılmasını araştırmanız gerekabilir.

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 hafıza üst yüküne sahiptir ve Default ve Precise genellikle daha pahalıdır.

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

İnsansılar

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

Sıradan sorunler

• 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 canlandırma * Bu, motorun işlemesi için yoğun olabilir, özellikle bu modeller Katmanlı kıyafetler kullanırsa .Ayrıca, avatarların sık sık yeniden canlandığı 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'ye animasyon oynatma - Sunucudaki çalışan NPC animasyonlarının sunucuda simüle edilmesi ve müşteriye yeniden yansıtılması gerekir.Bu gereksiz bir üst yük olabilir.

Hafifleme

• 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ü 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'yi basitçe yeniden etkinleştirebilirsiniz.Bu süreç havuzlanma olarak adlandırılır ve karakterlerin uygulanması gereken süre 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 mevcut:

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

MikroProfiler özellikleri

Görüntüleme

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

Çekme çağrıları

Bir çizme çağrısı, motordan GPU'ya bir şeyi görselleştirmek için bir dizi talimatlardır.Çekme çağrıları önemli bir üst yük taşır.Genel olarak, kare başına daha az çekme çağrısı yapılırsa, bir kareyi görselleştirmek 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örüntüleyebilirsiniz istemciye basarak .

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

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

Diğer yaygın sorunlar

• Aşırı nesne yoğunluğu - Eğer büyük bir 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.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ı bir mesh veya dokümanı ID'si vardır.Bu, instans oluşturmayı engeller ve gereksiz çekme çağrılarına yol açabilir.

  Bu sorunun yaygın bir nedeni, bir seansın tümü bir kez ithal edildiğinde, bireysel varlıkların Roblox'a ithal edilmesi ve ardından sahneyi birleştirmek için sonra çoğaltı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 nesneleri birbirine 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.

Hafifleme

• 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 tüm benzersiz mesheleri tanıyabilir ve tek bir çekme çağrısında 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.
• Seçme - Seçme, son olarak görüntülenen çerçeveye dahil olmayan nesneler için çekme çağrılarının kaldırılma 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 gizleyin
  • İç ortamlar için, şu anda herhangi 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, ki 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 yansıtımı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 örneklerinin menzilini ve açısını sınırlandır.

  • Daha az ışık instansı kullanın.

MikroProfiler özellikleri

Ağ ve replikasyon

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 büyük miktarda bilgi daha fazla hesaplama süresi talep eder.

Sıradan sorunler

• Aşırı uzaktan trafik - RemoteEvent veya RemoteFunction nesneler aracılığıyla çok fazla 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:

  • Tekrarlanması gerekmeyen her karede verileri yeniden yazmak.
  • Verileri sınırlandırmak için herhangi bir mekanizma olmadan kullanıcı girişi üzerinde yeniden yazma.
  • 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 örnek ağaçlarının oluşturulması veya kaldırılması - Sunucudaki veri modeline bir değişiklik yapıldığında, bağlı istemcilere yeniden yansıtılır.Bu, çalışma sırasında haritalar gibi büyük istemci-sunucu hierarşileri oluşturmak ve yok etmek çok ağ yoğunluğu gerektirebilir demektir.

  Buradaki ortak suçlu, animasyon editörü eklentileri tarafından kaydedilen karmaşık animasyon verileridir.Bu unsurlar oyun yayınlanmadan önce kaldırılmazsa 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ülen ö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.

Hafifleme

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

• Tek seferde uzaktan büyük miktarda veri göndermekten kaçının .Bunun yerine, sadece gerekli verileri daha düşük bir frekansla gönderin.Örneğin, bir karakterin durumu için, her kare değiştiğinde değil, onu her değiştiğinde yeniden üretin.
• Komple istemci ağaçlarını parçalara ayırın ve bunları çalışmayı yeniden yaymak için çoklu çerçevelere dağıtmak için parçalar halinde yükleyin gibi haritalar ve bunları dağıtmak için bunları parçalara yüklein.
• Animasyon metadatlarını temizle , özellikle kıvrımların animasyon dizinini, ithal edildikten sonra.
• Gereksiz istisna örnek yeniden yaratma sınırı , özellikle sunucunun oluşturulan istisnaların bilgisine sahip olması gerekmediği durumlardaBuna dahil olan şeyler:

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

MikroProfiler özellikleri

Varlık belleği 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ştirme 'yi etkinleştirmektir.

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 3D 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ı Yayın Kalitesi kullanımını azaltmak.
• 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 neden olabilir.
• Aşırı varlık hacmi - Varlıklar aynı olmadığında bile, aynı varlığı yeniden kullanma ve hafızayı kurtarma fırsatları kaçırılan 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 bellek kullanımına şaşırtıcı bir katkı olabilir.Stratejiler için, bakın Yükleme Süreleri.
• Yüksek çözünürlüklü dokular - Bir dokunun grafik bellek tüketimi diskteki dokunun boyutuyla ilgili değildir, ancak dokunun piksel sayısıyla ilgilidir

  • Ö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, diskte 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, düşüşün ö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.

Hafifleme

• 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 algılayan 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 yinelenenleri manuel olarak tanımlamak.
  • Farklı renkler için ayrı dokular kullanmak yerine, tek bir dokuyu yükle ve çeşitli renk tonları uygulamak için SurfaceAppearance.Color özelliğini kullan.
• Haritaya ayrı olarak varlıkları ithal etmek - 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 çoğu kopya olsalar).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ülerin piksel sayısını gerekli miktardan fazla sınırla mayın.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 Düzleştirme Sayfalarını kullanın Kesme sayfaları nasıl oluşturulacağına dair adımlar ve örnekler için, Kesme Sayfaları Oluşturma bakın.

Yük süreleri

Pek ç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 birWorkspace.Doku açılmasını engellemesine rağmen, yükleme süresini önemli ölçüde artırır.

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

• Yüklenme ekranındaki görüntüler.
• Deneyim menünüzde düğme arka planları ve simgeler gibi ö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.