Sdílet prostřednictvím


Doporučení k výkonu pro Unity

Tento článek vychází z doporučení k výkonu pro hybridní realitu, ale zaměřuje se na vylepšení specifická pro Unity.

Nedávno jsme vydali aplikaci s názvem Základy kvality, která se zabývá běžnými problémy s výkonem, návrhem a prostředím a řešeními pro aplikace HoloLens 2. Tato aplikace je skvělou vizuální ukázkou pro následující obsah.

Nejdůležitějším prvním krokem při optimalizaci výkonu aplikací hybridní reality v Unity je, abyste měli jistotu , že používáte doporučená nastavení prostředí pro Unity. Tento článek obsahuje obsah s některými z nejdůležitějších konfigurací scén pro vytváření výkonných aplikací hybridní reality. Některá z těchto doporučených nastavení jsou také zvýrazněná níže.

Profilování pomocí Unity

Unity poskytuje integrovaný Unity Profiler , což je skvělý prostředek pro shromažďování cenných přehledů o výkonu pro vaši konkrétní aplikaci. I když můžete spustit profiler v editoru, tyto metriky nepředstavují skutečné běhové prostředí, takže výsledky by se měly používat opatrně. Při spouštění aplikace na zařízení doporučujeme vzdáleně profilovat, abyste měli co nejpřesnější a nejpřesnější přehledy.

Unity poskytuje skvělou dokumentaci pro:

  1. Jak vzdáleně připojit profiler Unity k aplikacím UPW
  2. Jak efektivně diagnostikovat problémy s výkonem pomocí Unity Profileru

Profilace GPU

Profiler Unity

S připojeným profilerem Unity a po přidání profileru GPU (viz Přidání profileru v pravém horním rohu) můžete zjistit, kolik času se stráví na procesoru a GPU uprostřed profileru. Vývojář tak může rychle aproximovat, pokud je jejich aplikace ohraničená procesorem nebo GPU.

Procesor Unity vs. GPU

Poznámka:

Pokud chcete profilaci GPU použít, musíte zakázat grafické úlohy v Nastavení Unity Playeru. Další podrobnosti najdete v modulu Profiler využití GPU Unity.

Ladicí program rámce Unity

Ladicí program Frame Unity je také výkonný a přehledný nástroj, který můžete použít. Poskytne vám dobrý přehled o tom, co GPU provádí každý snímek. Co je potřeba zjistit, jsou další cíle vykreslování a blit příkazy pro kopírování mezi nimi, protože jsou pro HoloLens velmi drahé. V ideálním případě by se na HoloLensu neměly používat žádné cíle vykreslení mimo obrazovku. Obvykle se přidávají při povolování drahých funkcí vykreslování (například MSAA, HDR nebo efekty na celé obrazovce, jako je bloom), kterým byste se měli vyhnout.

Překrytí frekvence snímků HoloLens

Stránka Výkon systému portálu zařízení obsahuje dobrý přehled výkonu procesoru a GPU zařízení. Můžete povolit čítač frekvence snímků zobrazení v náhlavní soupravě a graf frekvence snímků zobrazení v náhlavní soupravě. Tyto možnosti umožní čítač a graf FPS, který vám poskytne okamžitou zpětnou vazbu v libovolné spuštěné aplikaci na vašem zařízení.

PIX

PIX lze použít také k profilování aplikací Unity. Existují také podrobné pokyny k použití a instalaci PIX pro HoloLens 2. Ve vývojovém buildu se stejné obory, které vidíte v ladicím programu Frame Debugger Unity, zobrazí také v PIX a dají se zkontrolovat a profilovat podrobněji.

Poznámka:

Unity poskytuje možnost snadno upravit cílové rozlišení vykreslení aplikace za běhu prostřednictvím XR Nastavení.renderViewportScale vlastnost. Poslední obrázek prezentovaný na zařízení má pevné rozlišení. Platforma vzorek výstupu s nižším rozlišením vytvoří obrázek s vyšším rozlišením pro vykreslení na displejích.

UnityEngine.XR.XRSettings.renderViewportScale = 0.7f;

Doporučení k výkonu procesoru

Níže uvedený obsah obsahuje podrobnější postupy výkonu, zejména zaměřené na vývoj Unity a C#.

Odkazy na mezipaměť

Při inicializaci doporučujeme ukládat odkazy do mezipaměti na všechny relevantní komponenty a objekty GameObject, protože opakující se volání funkcí, jako je GetComponent<T>() a Kamera.main, jsou dražší vzhledem k nákladům na paměť pro uložení ukazatele. . Kamera.main používá metodu FindGameObjectsWithTag() pod ní, která nákladně hledá objekt fotoaparátu se značkou Main Kamera.

using UnityEngine;
using System.Collections;

public class ExampleClass : MonoBehaviour
{
    private Camera cam;
    private CustomComponent comp;

    void Start() 
    {
        cam = Camera.main;
        comp = GetComponent<CustomComponent>();
    }

    void Update()
    {
        // Good
        this.transform.position = cam.transform.position + cam.transform.forward * 10.0f;

        // Bad
        this.transform.position = Camera.main.transform.position + Camera.main.transform.forward * 10.0f;

        // Good
        comp.DoSomethingAwesome();

        // Bad
        GetComponent<CustomComponent>().DoSomethingAwesome();
    }
}

Poznámka:

Vyhněte se getComponent(string)
Při použití GetComponent() existuje několik různých přetížení. Je důležité vždy používat implementace založené na typech a nikdy přetížení vyhledávání založené na řetězci. Hledání podle řetězce ve scéně je výrazně nákladnější než hledání podle typu.
(Dobré) Komponenta GetComponent(Typ)
(Dobré) T GetComponent<T>()
(Špatné) Komponenta GetComponent(string)>

Vyhněte se nákladným operacím

  1. Vyhněte se použití LINQ

    I když linQ může být čistý a snadno čitelný a zapisovatelný, obecně vyžaduje více výpočtů a paměti, než kdybyste algoritmus napsali ručně.

    // Example Code
    using System.Linq;
    
    List<int> data = new List<int>();
    data.Any(x => x > 10);
    
    var result = from x in data
                 where x > 10
                 select x;
    
  2. Běžná rozhraní API Unity

    Některá rozhraní API Unity, i když užitečná, mohou být náročná na spuštění. Většina z nich zahrnuje prohledávání celého grafu scény pro několik odpovídajících seznamů GameObjects. Tyto operace se obecně dají vyhnout ukládáním odkazů do mezipaměti nebo implementací komponenty manažera pro Objekty GameObjects ke sledování odkazů za běhu.

        GameObject.SendMessage()
        GameObject.BroadcastMessage()
        UnityEngine.Object.Find()
        UnityEngine.Object.FindWithTag()
        UnityEngine.Object.FindObjectOfType()
        UnityEngine.Object.FindObjectsOfType()
        UnityEngine.Object.FindGameObjectsWithTag()
        UnityEngine.Object.FindGameObjectsWithTag()
    

Poznámka:

SendMessage() a BroadcastMessage() by se měly eliminovat za všechny náklady. Tyto funkce můžou být v pořadí 1000x pomalejší než volání přímých funkcí.

  1. Pozor na boxování

    Boxing je základní koncept jazyka C# a modulu runtime. Jedná se o proces zabalení proměnných typu hodnoty, jako charjsou , int, boolatd. do proměnných typu odkaz. Pokud je proměnná typu hodnota "zabalená", je zabalená do objektu System.Object, který je uložený ve spravované haldě. Paměť je přidělena a nakonec při uvolnění musí být zpracována uvolňováním paměti. Díky těmto přidělením a uvolněním se účtují náklady na výkon a v mnoha scénářích jsou zbytečné nebo se dají snadno nahradit levnější alternativou.

    Abyste se vyhnuli krabicování, ujistěte se, že proměnné, pole a vlastnosti, do kterých ukládáte číselné typy a struktury (včetně Nullable<T>) silného typu, jako jsou konkrétní typy, například int, float? nebo MyStruct, místo použití objektu. Pokud tyto objekty umístíte do seznamu, nezapomeňte použít seznam silného typu, například List<int> místo List<object> nebo ArrayList.

    Příklad balení v jazyce C#

    // boolean value type is boxed into object boxedMyVar on the heap
    bool myVar = true;
    object boxedMyVar = myVar;
    

Opakující se cesty kódu

Všechny opakující se funkce zpětného volání Unity (tj. Update), které se spouští mnohokrát za sekundu nebo rámec, by se měly zapsat pečlivě. Všechny nákladné operace budou mít obrovský a konzistentní dopad na výkon.

  1. Prázdné funkce zpětného volání

    I když se následující kód může zdát nevinný, aby opustil vaši aplikaci, zejména proto, že každý skript Unity automaticky inicializuje metodu Update, tyto prázdné zpětné volání mohou být nákladné. Unity pracuje mezi nespravovaným a spravovaným hranicemi kódu mezi kódem UnityEngine a kódem vaší aplikace. Přepínání kontextu přes tento most je poměrně nákladné, i když není nic ke spuštění. To se stává obzvláště problematické, pokud má vaše aplikace 100s GameObjects s komponentami, které mají prázdné opakující se zpětná volání Unity.

    void Update()
    {
    }
    

Poznámka:

Update() je nejběžnějším projevem tohoto problému s výkonem, ale jiné opakující se zpětná volání Unity, například následující může být stejně špatná, pokud není horší: FixedUpdate(), LateUpdate(), OnPostRender", OnPreRender(), OnRenderImage() atd.

  1. Operace, které upřednostňují spouštění jednou za rámec

    Následující rozhraní Unity API jsou běžné operace pro mnoho holografických aplikací. I když to není vždy možné, výsledky z těchto funkcí se obvykle dají vypočítat jednou a výsledky se v aplikaci pro daný rámec znovu využívají.

    a) Je vhodné mít vyhrazenou singletonovou třídu nebo službu, aby zvládl váš pohled Raycast na scénu a pak tento výsledek znovu použít ve všech ostatních komponentách scény, namísto provádění opakovaných a identických operací Raycastu jednotlivými komponentami. Některé aplikace mohou vyžadovat raycasty z různých původů nebo pro různé vrstvové masky.

        UnityEngine.Physics.Raycast()
        UnityEngine.Physics.RaycastAll()
    

    b) Vyhněte se operacím GetComponent() v opakovaných zpětných voláních Unity, jako je Update(), ukládáním odkazů do mezipaměti v start() nebo vzhůru()

        UnityEngine.Object.GetComponent()
    

    c) Pokud je to možné, doporučujeme vytvořit instanci všech objektů při inicializaci a používat sdružování objektů k recyklaci a opětovnému použití Objektů GameObjects během běhu aplikace.

        UnityEngine.Object.Instantiate()
    
  2. Vyhněte se rozhraním a virtuálním konstruktorům

    Volání funkcí prostřednictvím rozhraní vs. přímých objektů nebo volání virtuálních funkcí může být často mnohem dražší než použití přímých konstruktorů nebo volání přímých funkcí. Pokud virtuální funkce nebo rozhraní nepotřebujete, měli byste ji odebrat. Dosažení výkonu těchto přístupů ale stojí za kompromis, pokud jejich použití zjednodušuje spolupráci při vývoji, čitelnost kódu a udržovatelnost kódu.

    Obecně platí, že doporučujeme neoznačovat pole a funkce jako virtuální, pokud neexistuje jasné očekávání, že tento člen musí být přepsán. Jedna by měla být obzvláště opatrná ohledně cest kódu s vysokou frekvencí, které se volají mnohokrát na rámec nebo dokonce jednou na rámec, jako UpdateUI() je například metoda.

  3. Vyhněte se předávání struktur podle hodnoty

    Na rozdíl od tříd jsou struktury typy hodnot a při předání přímo funkci se jejich obsah zkopíruje do nově vytvořené instance. Tato kopie přidává náklady na procesor a také další paměť v zásobníku. U malých struktur je účinek minimální a proto přijatelný. U funkcí se však opakovaně vyvolaly všechny rámce a funkce, které přebírají velké struktury, pokud je to možné, upravte definici funkce tak, aby předávala odkaz. Další informace najdete tady.

Různé

  1. Fyzika

    a) Obecně nejjednodušší způsob, jak zlepšit fyziku, je omezit množství času stráveného fyzikou nebo počet iterací za sekundu. Tím se sníží přesnost simulace. Viz TimeManager v Unity

    b) Typy kolidátorů v Unity mají široce odlišné charakteristiky výkonu. V následujícím pořadí jsou uvedeny nejvýkonnější kolidátory s nejmenším výkonem zleva doprava. Je důležité se vyhnout colliderům Mesh, které jsou podstatně dražší než primitivní kolaři.

    Sphere < Capsule < Box <<< Mesh (Konvexní) < Síť (nekonvexní)

    Další informace najdete v tématu Osvědčené postupy pro fyziku Unity

  2. Animace

    Zakažte nečinné animace zakázáním komponenty Animator (zakázání herního objektu nebude mít stejný účinek). Vyhněte se vzorům návrhu, kdy animátor sedí ve smyčce a nastavuje hodnotu na stejnou věc. Pro tuto techniku je značné režijní náklady, které nemají žádný vliv na aplikaci. Další informace najdete tady.

  3. Složité algoritmy

    Pokud vaše aplikace používá složité algoritmy, jako jsou inverzní kinematice, hledání cest atd., vyhledejte jednodušší přístup nebo upravte relevantní nastavení pro jejich výkon.

Doporučení k výkonu procesoru na GPU

Obecně platí, že výkon procesoru na GPU je nižší než volání kreslení odeslaná na grafickou kartu. Aby bylo možné zlepšit výkon, musí být volání kreslení strategicky omezená nebo b) restrukturalizována pro optimální výsledky. Vzhledem k tomu, že volání kreslení jsou náročná na zdroje, sníží se jejich snížení celkové požadované práce. Kromě toho změny stavu mezi voláními kreslení vyžadují nákladné ověření a kroky překladu v grafickém ovladači, a proto restrukturalizace volání kreslení vaší aplikace za účelem omezení změn stavu (tj. různých materiálů atd.) může zvýšit výkon.

Unity má skvělý článek, který poskytuje přehled a podrobně popisuje dávkování volání kreslení pro jejich platformu.

Vykreslování s jednou instancí průchodu

Vykreslování s jednou instancí průchodu v Unity umožňuje snížit volání kreslení pro každé oko dolů na jedno instance volání kreslení. Kvůli koherenci mezi dvěma voláními kreslení mezi mezipamětí je také několik vylepšení výkonu gpu.

Povolení této funkce v projektu Unity

  1. Otevřete Nastavení OpenXR (přejděte na Upravit>Project Nastavení> XR Plugin Management>OpenXR).
  2. V rozevírací nabídce Režim vykreslování vyberte Instance s jedním předáním.

Podrobnosti o tomto přístupu vykreslování najdete v následujících článcích z Unity.

Poznámka:

K jednomu běžnému problému s vykreslováním s jednou instancí dochází v případě, že vývojáři už mají existující vlastní shadery, které nejsou napsané pro vytváření instancí. Po povolení této funkce si vývojáři můžou všimnout, že některé objekty GameObject se vykreslují jenom v jednom oku. Důvodem je to, že přidružené vlastní shadery nemají odpovídající vlastnosti pro vytváření instancí.

Statické dávkování

Unity dokáže dávkot mnoho statických objektů, aby se snížil počet volání kreslení do GPU. Statické dávkování funguje u většiny objektů rendereru v Unity, které 1) sdílejí stejný materiál a 2) jsou všechny označené jako Statické (Vyberte objekt v Unity a zaškrtněte políčko v pravém horním rohu inspektoru). Objekty GameObject označené jako Statické nelze přesunout během modulu runtime vaší aplikace. Statické dávkování proto může být obtížné využít v HoloLens, kde je potřeba umístit, přesunout, škálovat atd. U imerzivních náhlavních souprav může statické dávkování výrazně snížit počet volání kreslení a zvýšit tak výkon.

Další podrobnosti najdete v části Dávkování volání kreslení v Unity pro statickédávkování.

Dynamické dávkování

Vzhledem k tomu, že je problematické označit objekty jako statické pro vývoj HoloLens, může být dynamické dávkování skvělým nástrojem pro kompenzaci této chybějící funkce. Může být také užitečný pro imerzivní náhlavní soupravy. Dynamické dávkování v Unity však může být obtížné, protože GameObjects musí a) sdílet stejný materiál a b) splňovat dlouhý seznam dalších kritérií.

Přečtěte si dynamické dávkování v části Dávkování volání kreslení v Unity pro úplný seznam. Nejčastěji se objekty GameObjects stanou neplatnými pro dynamické dávkování, protože přidružená data sítě nesmí být větší než 300 vrcholů.

Další techniky

Dávkování může nastat pouze v případě, že více objektů GameObject může sdílet stejný materiál. Obvykle to bude blokováno potřebou GameObjects mít jedinečnou texturu pro jejich příslušný materiál. Je běžné kombinovat textury do jedné velké textury, metoda známá jako Texture Atlasing.

Kromě toho je vhodnější zkombinovat sítě do jednoho Objektu GameObject, pokud je to možné a rozumné. Každý renderer v Unity bude mít svá přidružená volání kreslení versus odeslání kombinované sítě pod jedním rendererem.

Poznámka:

Při úpravě vlastností Renderer.material za běhu se vytvoří kopie materiálu a tím se potenciálně přeruší dávkování. K úpravě vlastností sdíleného materiálu v objektech GameObjects použijte Renderer.sharedMaterial.

Doporučení k výkonu GPU

Další informace o optimalizaci vykreslování grafiky v Unity

Šířka pásma a rychlost výplně

Při vykreslování rámce na GPU je aplikace vázána šířkou pásma paměti nebo rychlostí výplně.

  • Šířka pásma paměti je rychlost čtení a zápisů, které může GPU provádět z paměti.
  • Rychlost výplně odkazuje na pixely, které může gpu nakreslit za sekundu.

Optimalizace sdílení hloubkové vyrovnávací paměti

Doporučujeme povolit sdílení vyrovnávací paměti hloubky pro optimalizaci stability hologramu. Při povolování hloubkové reprojektování pozdní fáze pomocí tohoto nastavení doporučujeme místo 24bitového formátu hloubky vybrat 16bitový formát hloubky. Vyrovnávací paměti 16bitové hloubky výrazně snižují šířku pásma (a tím výkon) související s provozem hloubkové vyrovnávací paměti. Může to být velké zlepšení snížení výkonu i výkonu. Existují však dva možné negativní výsledky pomocí 16bitového formátu hloubky.

Z-Boj

Díky věrnosti rozsahu menší hloubky se z-boj s větší pravděpodobností vyskytuje s 16bitovou než 24bitovou verzí. Abyste se těmto artefaktům vyhnuli, upravte roviny blízko/daleko klipů fotoaparátu Unity tak, aby byly nižší přesnosti. U aplikací založených na HoloLensu může vzdálená rovina klipu 50 m místo výchozího 1000 m Unity obecně eliminovat všechny boje proti z.

Zakázaná vyrovnávací paměť vzorníku

Když Unity vytvoří texturu vykreslení s 16bitovou hloubkou, není vytvořena žádná vyrovnávací paměť vzorníku. Výběrem 24bitového formátu hloubky, jak je popsáno v dokumentaci Unity, se vytvoří 24bitová vyrovnávací paměť z a 8bitová vyrovnávací paměť vzorníku (pokud je 32bitová verze použitelná na zařízení (například HoloLens), což je obecně případ).

Vyhněte se efektům na celé obrazovce

Techniky, které pracují na celé obrazovce, mohou být nákladné, protože jejich řád je miliony operací každý rámec. Doporučuje se vyhnout účinkům po zpracování, jako je anti-aliasing, květ a další.

Optimální nastavení osvětlení

Globální osvětlení v reálném čase v Unity může poskytovat vynikající vizuální výsledky, ale zahrnuje nákladné výpočty osvětlení. Doporučujeme zakázat globální osvětlení v reálném čase pro každý soubor scény Unity prostřednictvím okna>Rendering>Lighting Nastavení> zrušit zaškrtnutí globálního osvětlení v reálném čase.

Kromě toho se doporučuje zakázat veškeré stínové přetypování, protože také přidávají nákladné průchody GPU do scény Unity. Stíny můžou být zakázány na světlo, ale dají se ovládat holisticky prostřednictvím nastavení kvality.

Upravte>projekt Nastavení a pak vyberte kategorii > Kvalita Vyberte pro platformu UPW nízkou kvalitu. Můžete také nastavit vlastnost Shadows na Disable Shadows.

Doporučujeme používat pečené osvětlení s vašimi modely v Unity.

Snížení počtu poly

Počet mnohoúhelníku se zmenší

  1. Odebrání objektů ze scény
  2. Decimace aktiv, což snižuje počet mnohoúhelníku pro danou síť
  3. Implementace systému podrobností (LOD) do aplikace, který vykreslí daleko od objektů s nižším mnohoúhelníkem stejné geometrie

Principy shaderů v Unity

Snadnou aproximací porovnání shaderů v výkonu je identifikace průměrného počtu operací, které se spouští za běhu. To je možné snadno provést v Unity.

  1. Vyberte prostředek shaderu nebo vyberte materiál a pak v pravém horním rohu okna inspektoru vyberte ikonu ozubeného kola a pak vyberte Shader.

    Výběr shaderu v Unity

  2. S vybraným assetem shaderu vyberte v okně inspektoru tlačítko Zkompilovat a zobrazit kód .

    Kód kompilátoru shaderu v Unity

  3. Po kompilaci vyhledejte ve výsledcích oddíl statistiky s počtem různých operací pro vrchol i pixel shader (Poznámka: shadery pixelů se často označují také jako shadery fragmentů).

    Standardní operace shaderu Unity

Optimalizace pixelových shaderů

Při pohledu na zkompilované výsledky statistiky pomocí výše uvedené metody bude shader fragmentu obecně provádět více operací než shader vrcholů v průměru. Shader fragmentu, označovaný také jako shader pixelů, se spouští na pixel na výstupu obrazovky, zatímco shader vrcholů se provádí pouze na vrchol všech sítí, které jsou nakreslené na obrazovku.

Shadery fragmentů proto mají více instrukcí než shadery vrcholů kvůli všem výpočtům osvětlení, shadery fragmentů se téměř vždy spouští u větší datové sady. Pokud je výstupem obrazovky například 2k o 2k obrázku, může se shader fragmentu spustit 2 000*2 000 = 4 000 000krát. Při vykreslování dvou očí se toto číslo zdvojnásobí, protože existují dvě obrazovky. Pokud má aplikace hybridní reality více průchodů, efekty následného zpracování na celé obrazovce nebo vykreslování více sítí na stejný pixel, toto číslo se výrazně zvýší.

Proto snížení počtu operací v shaderu fragmentů může obecně poskytovat mnohem vyšší zvýšení výkonu při optimalizacích v shaderu vrcholů.

Alternativy shaderu Unity Standard

Místo použití fyzicky založeného vykreslování (PBR) nebo jiného vysoce kvalitního shaderu se podívejte na využití výkonnějšího a levnějšího shaderu. Sada nástrojů Mixed Reality poskytuje standardní shader MRTK optimalizovaný pro projekty hybridní reality.

Unity také poskytuje nesvícenou, rozsvícenou, difuzní a další zjednodušené možnosti shaderu, které jsou rychlejší v porovnání se standardním shaderem Unity. Podrobnější informace najdete v tématu Využití a výkon integrovaných shaderů .

Předběžné načtení shaderu

Pomocí předběžného načítání shaderu a dalších triků optimalizujte dobu načítání shaderu. Konkrétně preloading shaderu znamená, že kvůli kompilaci shaderu za běhu neuvidíte žádné hitchy.

Omezení překreslení

V Unity se dá zobrazit překreslení scény přepnutím nabídky režimu kreslení v levém horním rohu zobrazení scény a výběrem možnosti Překreslit.

Obecně platí, že překreslení lze před odesláním do GPU zmírnit přeskakováním objektů předem. Unity poskytuje podrobnosti o implementaci occlusion Culling pro svůj modul.

Doporučení k paměti

Nadměrné přidělení paměti a operace uvolnění mohou mít nepříznivý vliv na holografickou aplikaci, což vede k nekonzistentnímu výkonu, ukotveným snímkům a dalšímu škodlivému chování. Je zvlášť důležité porozumět aspektům paměti při vývoji v Unity, protože správa paměti je řízena uvolňováním paměti.

Uvolnění paměti

Při aktivaci uvolňování paměti dojde ke ztrátě výpočetní doby zpracování holografických aplikací, aby analyzovaly objekty, které už nejsou v oboru během provádění, a jejich paměť je potřeba uvolnit, aby bylo možné ho znovu použít. Konstantní přidělení a zrušení přidělení obecně vyžadují, aby se uvolňování paměti spouštělo častěji, což snižuje výkon a uživatelské prostředí.

Unity poskytla vynikající stránku, která podrobně vysvětluje, jak systém uvolňování paměti funguje, a tipy pro zápis efektivnějšího kódu, pokud jde o správu paměti.

Jedním z nejběžnějších postupů, které vedou k nadměrnému uvolňování paměti, není ukládání odkazů do mezipaměti na komponenty a třídy ve vývoji Unity. Všechny odkazy by měly být zachyceny během start() nebo Probuzení() a znovu je použít v pozdějších funkcích, jako jsou Update() nebo LateUpdate().

Další rychlé tipy:

  • Použití třídy StringBuilder C# k dynamickému sestavování složitých řetězců za běhu
  • Odeberte volání do debug.Log(), pokud už je nepotřebujete, protože se stále spouštějí ve všech verzích sestavení aplikace.
  • Pokud vaše holografická aplikace obecně vyžaduje hodně paměti, zvažte volání System.GC.Collect() během fází načítání, jako je například při prezentování načítání nebo přechodové obrazovky.

Sdružování objektů

Sdružování objektů je oblíbená technika pro snížení nákladů na průběžné přidělování objektů a uvolnění. To se provádí přidělením velkého fondu identických objektů a opětovným použitím neaktivních dostupných instancí z tohoto fondu místo neustálého vytváření a zničení objektů v průběhu času. Fondy objektů jsou skvělé pro opakovaně použitelné komponenty, které mají během aplikace životnost proměnné.

Výkonnost spouštění

Zvažte spuštění aplikace s menší scénou a pak pomocí nástroje SceneManager.LoadSceneAsync načtěte zbytek scény. Díky tomu se vaše aplikace co nejrychleji dostane do interaktivního stavu. Při aktivaci nové scény může dojít k velkému nárůstu využití procesoru a že jakýkoli vykreslený obsah může zakroužkovat nebo zadržovat. Jedním ze způsobů, jak to obejít, je nastavit vlastnost AsyncOperation.allowSceneActivation na hodnotu false ve scéně, která se načítá, počkat na načtení scény, vymazat obrazovku na černou a pak ji nastavit zpět na true pro dokončení aktivace scény.

Nezapomeňte, že při načítání spouštěcí scény se uživateli zobrazí holografická úvodní obrazovka.

Viz také