Teljesítménnyel kapcsolatos javaslatok a Unityhez

Ez a cikk a vegyes valóságra vonatkozó teljesítménnyel kapcsolatos javaslatokra épül,de a Unity-specifikus fejlesztésekkel foglalkozik.

A vegyes valóságon belüli alkalmazások teljesítményének Unityben való optimalizálása során a legfontosabb első lépés az, hogy biztosan a Unity ajánlott környezeti beállításait használja. Ez a cikk olyan tartalmakat tartalmaz, amelyek a legfontosabb jelenetkonfigurációkat tartalmaznak a nagy Mixed Reality érdekében. A javasolt beállítások némelyike is ki van emelve az alábbiakban.

Profil létrehozása a Unityvel

A Unity beépített Unity Profiler-alkalmazást biztosít, amely nagyszerű forrás az adott alkalmazás értékes teljesítményelemzéséhez. Bár a profilkészítőt futtathatja szerkesztőben, ezek a metrikák nem a valódi futásidejű környezetet képviselik, ezért az eredményeket körültekintően kell használni. Javasoljuk, hogy távolról profilt készített az alkalmazásról, miközben az eszközön fut, hogy a legpontosabb és legjavahatóbb elemzéseket nyújtsa. Emellett a Unity Frame Debugger eszköze is egy hatékony és hasznos betekintő eszköz.

A Unity nagyszerű dokumentációt biztosít a következő hez:

  1. A Unity Profiler csatlakoztatása UWP-alkalmazásokhoz távolról
  2. Teljesítményproblémák hatékony diagnosztizálása a Unity Profilerrel

Megjegyzés

Ha a Unity Profiler csatlakoztatva van, és a GPU-profilkészítő hozzáadása után (lásd a jobb felső sarokban található Profilkészítő hozzáadása) látható, hogy mennyi időt tölt a CPU-ra & GPU a profilkészítő közepén. Ez lehetővé teszi, hogy a fejlesztő gyors közelítést kap, ha az alkalmazása PROCESSZORra vagy GPU-ra van kötve.

Unity CPU és GPU

Processzorteljesítményre vonatkozó javaslatok

Az alábbi tartalom részletes teljesítménybeli eljárásokat fed le, különösen Unity és C# & célokra.

Gyorsítótár-hivatkozások

Javasoljuk, hogy az inicializáláskor gyorsítótárazásban tárolja az összes kapcsolódó összetevőre és GameObjectre mutató hivatkozásokat, mert az ismétlődő függvényhívások, például a GetComponent <T> () és a Camera.main drágábbak a mutató tárolására vonatkozó memóriaköltséghez képest. . A Camera.main csak a FindGameObjectsWithTag() címkét használja alatta, amely költségesen keres a jelenetgráfban egy kameraobjektumot a "MainCamera" címkével.

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();
    }
}

Megjegyzés

A GetComponent(sztring) elkerülése
A GetComponent() használata esetén több különböző túlterhelés van. Fontos, hogy mindig a típusalapú implementációkat használja, és soha ne használja a sztringalapú keresés túlterhelését. A sztring alapján való keresés a jelenetben jelentősen költséggel jár, mint a Típus szerint való keresés.
(Jó) Összetevő getComponent(Típus típusa)
(Jó) T GetComponent <T> ()
(Rossz) Összetevő GetComponent(sztring)>

Költséges műveletek elkerülése

  1. A LINQ használatának elkerülése

    Bár a LINQ lehet tiszta és könnyen olvasható és írható, általában több számításra és memóriára van szükség, mint ha manuálisan írta volna az algoritmust.

    // 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. Common Unity API-k

    Bizonyos Unity API-k végrehajtása, bár hasznos lehet, költséges lehet. Ezek nagy része magában foglalja a teljes jelenetgráfban a GameObjects egyező listájának keresését. Ezek a műveletek általában elkerülhetők a hivatkozások gyorsítótárazása vagy a GameObjects kezelőösszetevője segítségével a hivatkozások futásidőben történő nyomon követéséhez.

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

Megjegyzés

A SendMessage() és a BroadcastMessage() költségeket minden áron ki kell küszöbölni. Ezek a függvények 1000x lassabbak a közvetlen függvényhívások sorrendjében.

  1. Legyen óvatos a boxolásban

    A boxing a C# nyelv és a futásidő egyik alapfogalma. Ez a folyamat referenciával típusos változókba burkolt értéktípusú változókat (például char , , stb.). int bool Ha egy érték típusú változó "dobozolt", akkor egy fájlba van csomagolva, amely a felügyelt System.Object halomban van tárolva. A memória lefoglalható, és a eldobás után a szemétgyűjtőnek fel kell feldolgoznia. Ezek a lefoglalások és kiosztások teljesítményköltséggel járnak, és sok esetben szükségtelenek, vagy könnyen lecserélhetők egy kevésbé költséges alternatívára.

    A boxolás elkerülése érdekében győződjön meg arról, hogy a numerikus típusok és structok tárolására használt változók, mezők és tulajdonságok (beleértve a típust is) kifejezetten meghatározott típusként vannak begépelve, például , vagy , objektum Nullable<T> int használata float? MyStruct helyett. Ha ezeket az objektumokat listába sorolja, mindenképpen olyan erősen típusos listát használjon, mint a vagy a List<int> List<object> ArrayList .

    Példa boxolásra C-ben #

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

Kódútvonalak ismétlése

Minden ismétlődő Unity-visszahívási függvény (pl. Frissítés) a másodpercenként többször és/vagy keretenként végrehajtott műveleteket körültekintően kell megírni. Az itt költséges műveletek jelentős és konzisztens hatással lesznek a teljesítményre.

  1. Üres visszahívási függvények

    Bár az alábbi kód nem tűnik túl hasznosnak az alkalmazásban, különösen mivel minden Unity-szkript automatikusan inicializál egy Update metódussal, ezek az üres visszahívások költségessé válhatnak. A Unity oda-vissza működik egy nem felügyelt és felügyelt kódhatár között, a UnityEngine-kód és az alkalmazáskód között. A kontextusváltás ezen a hídon meglehetősen drága, még akkor is, ha semmit nem kell végrehajtani. Ez különösen problémássá válik, ha az alkalmazás több 100 GameObject-et tartalmaz olyan összetevőkkel, amelyek üres ismétlődő Unity-visszahívásokkal rendelkezik.

    void Update()
    {
    }
    

Megjegyzés

Az Update() a teljesítménybeli probléma leggyakoribb megoldása, de más ismétlődő Unity-visszahívások, például a következők is ugyanolyan rosszak, ha nem rosszabbak: FixedUpdate(), LateUpdate(), OnPostRender", OnPreRender(), OnRenderImage() stb.

  1. A futást előnybenó műveletek keretenként

    Az alábbi Unity API-k számos Holographic Apps-alkalmazás gyakori műveletei. Bár ez nem mindig lehetséges, a függvények eredményei általában csak egyszer számíthatóak ki, és az eredmények újra használhatók az alkalmazásban egy adott képkockához.

    a) Jó gyakorlat, ha van egy dedikált Singleton-osztály vagy -szolgáltatás, amely kezeli a Raycast tekintetét a jelenetben, majd ezt az eredményt újra felhasználja az összes többi jelenetösszetevőben ahelyett, hogy minden összetevő ismétlődő és azonos Raycast-műveleteket hozna létre. Egyes alkalmazások eltérő eredetű vagy különböző layerMasks típusú fénymásokat is megkövetelhetnek.

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

    b) Kerülje a GetComponent() műveleteket az olyan ismétlődő Unity-visszahívások esetén, mint az Update() a Start() vagy az Azúús ()

        UnityEngine.Object.GetComponent()
    

    c) Ha lehetséges, az inicializáláskor az összes objektum példányosítása és az objektumkészletezés használata a GameObjects újrahasznosításához és újbóli felhasználásához az alkalmazás futásidejében

        UnityEngine.Object.Instantiate()
    
  2. Interfészek és virtuális szerkezetek elkerülése

    A függvényhívások felületeken vagy közvetlen objektumokon keresztüli hívása vagy a virtuális függvények hívása gyakran sokkal drágább lehet, mint közvetlen szerkezetek vagy közvetlen függvényhívások használata. Ha a virtuális függvény vagy interfész szükségtelen, akkor el kell távolítani. Az ilyen megközelítések teljesítményével kapcsolatos találatok használata azonban érdemes, ha egyszerűbb a fejlesztési együttműködést, a kód olvashatóságát és a kód karbantarthatóságát.

    Általában azt javasoljuk, hogy a mezőket és a függvényeket ne jelölje meg virtuálisként, kivéve, ha egyértelmű elvárás van a tag felülírásában. Különösen körültekintően kell használni az olyan nagy gyakoriságú kódútvonalaknál, amelyek többször is hívhatóak keretenként, vagy akár keretenként egyszer, például egy UpdateUI() metódussal.

  3. Ne ad át strukturálokat érték alapján

    Az osztályokkal ellentétben a strukturálok értéktípusok, és amikor közvetlenül egy függvénynek vannak átk véve, a tartalmuk egy újonnan létrehozott példányba lesz másolható. Ez a másolat processzorköltségeket és további memóriát ad hozzá a veremhez. Kis strukturálok esetén a hatás minimális, így elfogadható. Ha azonban lehetséges, a függvények minden képkockát, valamint nagy strukturálokat kötő függvényeket is többször meghívtak, ha lehetséges, módosítsa úgy a függvénydefiníciót, hogy hivatkozással adja át a függvényt. További információ itt

Különböző veszélyes anyagok és tárgyak

  1. Fizika

    a) A fizika javítására általában az a legegyszerűbb módszer, ha korlátozza afizikára fordított időt vagy a másodpercenkénti iterációk számát. Ez csökkenti a szimuláció pontosságát. Lásd: TimeManager a Unityben

    b) A Unityben az ütközések típusai nagyban eltérő teljesítményjellemzővel rendelkeznek. Az alábbi sorrend felsorolja a legnagyobb teljesítményű és a legkevésbé teljesítő ütközéseket balról jobbra. Fontos elkerülni a Mesh-collidereket, amelyek lényegesen drágábbak, mint a primitív ütköztetők.

    Sphere < Capsule < Box <<< Mesh (Convex) < Mesh (non-Convex)

    További információ: Unity Fizikai ajánlott eljárások

  2. Animációk

    Tiltsa le az üresjárati animációkat az Animator összetevő letiltásával (a játékobjektum letiltása nem lesz ugyanaz a hatás). Kerülje az olyan tervezési mintákat, amelyekben az animátor egy hurokban van, és ugyanazt a dolgot kell értékkel felbecsülni. Ez a technika jelentős többletterheléssel jár, és nincs hatással az alkalmazásra. További információt itt talál.

  3. Összetett algoritmusok

    Ha az alkalmazás összetett algoritmusokat használ, például inverz kinematikát, útvonalkeresést stb., keressen egyszerűbb megközelítést, vagy módosítsa a teljesítményre vonatkozó beállításokat

Processzorról GPU-ra vonatkozó teljesítményre vonatkozó javaslatok

A cpu-GPU teljesítmény általában a grafikus kártyára elküldött rajzoláshívásokat használja. A teljesítmény javítása érdekében a hívásokat stratégiailag csökkenteni vagy b) át kell strukturálni az optimális eredmények érdekében. Mivel maguk a híváshívások erőforrás-igényesek, a csökkentése csökkenti a szükséges általános munkát. Emellett a rajzoláshívások közötti állapotváltozások költséges ellenőrzési és fordítási lépéseket igényelnek a grafikus illesztőben, így az alkalmazás híváshívásai átrendeződtek az állapotváltozások korlátozása érdekében (azaz különböző anyagok stb.) növelhetik a teljesítményt.

A Unity rendelkezik egy remek cikkel, amely áttekintést nyújt, és bemutatja a platformra vonatkozó rajzolásos hívások kötegeléssel való feldolgozását.

Egy pass-példány renderelése

A Single Pass Instanced Rendering a Unityben lehetővé teszi, hogy minden szem hívása egy példányos hívásra legyen csökkentve. A két hívás közötti gyorsítótár-koherencia miatt a GPU teljesítménye is javult.

A funkció engedélyezése a Unity-Project

  1. Nyissa meg a Player XR Gépház (nyissa meg az Edit > Project Gépház > Player > XR Gépház)
  2. Válassza ki a Single Pass Instanced elemet a Rendering Method legördülő menüből ( A Virtual Reality támogatott jelölőnégyzet be van jelölve)

Az ezzel a renderelési megközelítéssel kapcsolatos részletekért olvassa el a Unity következő cikkeit.

Megjegyzés

A Single Pass Instanced Rendering egyik gyakori problémája akkor fordul elő, ha a fejlesztők már rendelkezik olyan meglévő egyéni árnyékolókkal, amelyek nem instancálásra vannak írva. A funkció engedélyezése után a fejlesztők észrevehetnek néhány GameObject-et, amelyek csak az egyik szemükön jelennek meg. Ennek az az oka, hogy a társított egyéni árnyékolók nem rendelkeznek a megfelelő tulajdonságokkal az instancáláshoz.

A probléma megoldásához tekintse meg a Unityből HoloLens Single Pass Renderinget.

Statikus kötegek

A Unity számos statikus objektumot képes kötegelni a GPU hívásának csökkentése érdekében. A statikus kötegelés a Unityben a legtöbb olyan renderelő objektum esetén működik, amelyek 1) ugyanazt az anyagot osztják meg, és 2) statikusként vannak megjelölve (Válasszon egy objektumot a Unityben, és jelölje be a jelölőnégyzetet az inspector jobb felső sarokban). A Statikusként megjelölt GameObjects nem mozgatható az alkalmazás futásidejében. Így a statikus kötegek nehezen kihasználhatóak olyan HoloLens ahol gyakorlatilag minden objektumot el kell helyezni, áthelyezni, méretezni stb. Modern headsetek esetén a statikus kötegelés jelentősen csökkentheti a híváshívásokat, ezáltal javítva a teljesítményt.

További részletekért olvassa el a Call Batching in Unity (Hívásköteezés a Unityben) szakasz Static Batching (Statikus kötegezés) szakaszát.

Dinamikus kötegolás

Mivel az objektumok statikusként való megjelölése HoloLens fejlesztéshez, a dinamikus kötegelés remek eszköz lehet ennek a funkciónak a hiányának kompenzálására. Modern headsetek használata is hasznos lehet. A Unityben azonban nehéz lehet engedélyezni a dinamikus kötegeket, mert a GameObjectsnek egy) meg kell osztania ugyanazt a Material és b) a többi feltétel hosszú listáját.

A teljes listáért olvassa el a Dynamic Batching (Dinamikus kötegezés) szakaszt a Call Batching in Unity (Hívásköteezés a Unityben) alatt. Leggyakrabban a GameObjects érvénytelenné válik a dinamikus kötegelésnél, mert a kapcsolódó hálóadatok nem lehet több mint 300 csúcspont.

Egyéb technikák

Kötegelés csak akkor történhet meg, ha több GameObject meg tudja osztani ugyanazt az anyagot. Ezt általában blokkolja, hogy a GameObjectsnek egyedi textúra szükséges a megfelelő Anyaghoz. A textúra gyakran egyetlen nagy textúra, úgynevezett Textúra atlasing nevű metódusban egyesül.

Emellett előnyösebb a hálókat egy GameObjectben kombinálni, ahol csak lehetséges és ésszerű. A Unityben minden renderelő a társított rajzolási hívás(okkal) lesz társítva, szemben egy kombinált háló egy renderelőn belüli beküldésével.

Megjegyzés

A Renderer.material tulajdonságainak futásidőben való módosítása másolatot hoz létre a Materialról, és ezáltal megszakíthatja a kötegelést. A Renderer.sharedMaterial használatával módosíthatja a GameObjects megosztott anyagtulajdonságokat.

GPU-teljesítményre vonatkozó javaslatok

További információ a grafikus renderelés optimalizálásáról a Unityben

Mélységi puffermegosztás optimalizálása

Javasoljuk, hogy engedélyezze a Mélységi puffermegosztást a Player XR Gépház a hologram stabilitásának optimalizálása érdekében. Ha azonban ezzel a beállítással engedélyezi a mélységalapú, késői fázisú reprodukálást, javasoljuk, hogy 24 bites formátum helyett 16 bites formátumot válasszon. A 16 bites pufferek jelentősen csökkentik a mélységi pufferforgalomhoz társított sávszélességet (és ezáltal a teljesítményt). Ez nagy teljesítménycsökkenést és teljesítményjavadítást is jelent. A 16 bites formátum használatával azonban két negatív eredmény is lehetséges.

Z-Egyedek

A csökkentett mélységi tartományhűség nagyobb valószínűséggel fordul elő 16 bites, mint 24 bites Z-parancsokkal. Az összetevők elkerülése érdekében módosítsa a Unity-kamera közel/távol clip-síkját, hogy az kisebb pontosságot is figyelembe véve legyen. A HoloLens alkalmazások esetében a Unity alapértelmezett 1000 m-es alapérték helyett egy 50 m-es, távolról elérhető vágólapra általában ki lehet küszöbölni a z-elkenéseket.

A sablonpuffer le van tiltva

Amikor a Unity 16 bites renderelési textúra-thoz létre, akkor nem jön létre sablonpuffer. A Unity-dokumentációk szerint a 24 bites mélységű formátum kiválasztása 24 bites z-puffert és [8 bites rajzsablonpuffert] ( ( (ha 32 bites az eszközön alkalmazható, ami általában így van https://docs.unity3d.com/Manual/SL-Stencil.html) HoloLens).

Teljes képernyős hatások elkerülése

A teljes képernyőn működő technikák költségesek lehetnek, mivel nagyságrendjük minden keretben több millió művelet. Javasoljuk, hogy kerülje az olyan utófeldolgozási hatásokat, mint például az aliasok elleni, Bloom stb. használata.

Optimális megvilágítási beállítások

A Unity valós idejű Global Unity szolgáltatása kiváló vizuális eredményeket nyújt, de költséges megvilágítási számításokat is tartalmaz. Azt javasoljuk, hogy tiltsa le minden Unity-jelenetfájlhoz a valós idejű Global Egyezést a Window Rendering-világítási funkcióval, Gépház > törölje a valós idejű > > Global Egyedjelenség jelölőnégyzetét.

Emellett javasoljuk, hogy tiltsa le az összes árnyékbedobást, mivel ezek költséges GPU-ket is továbbítnak egy Unity-jelenetbe. Az árnyékolást le lehet tiltani fényenként, de holisztikus módon is szabályozhatók a Minőségi beállítások segítségével.

Szerkesztés > Project Gépház válassza a Quality (Minőség) kategóriát, majd válassza > Select Low Quality (Alacsony minőség kiválasztása az UWP-platformhoz) lehetőséget. Az Árnyékok tulajdonságot beállíthatja az Árnyékok letiltása beállításra is.

Javasoljuk, hogy a Unityben használjon begyújtott világítást a modellekhez.

Polik számának csökkentése

A sokszög száma a következővel csökkenthető:

  1. Objektumok eltávolítása egy jelenetből
  2. Objektumcsökkentés, amely csökkenti egy adott háló sokszögeinek számát
  3. Részletességi szint (LOD) rendszer megvalósítása az alkalmazásba, amely távolról renderel objektumokat ugyanazon geometria alacsonyabb sokszögverziójával

A Unity árnyékolóinak ismertetése

A teljesítménybeli árnyékolók összehasonlításának egyszerű megközelítése az egyes futtatáskor futtatott műveletek átlagos számának azonosítása. Ez egyszerűen elvégezhető a Unityben.

  1. Válassza ki az árnyékoló eszközét, vagy válasszon egy anyagot, majd az Inspector ablak jobb felső sarkában válassza a fogaskerék ikont, majd a "Select Shader" (Árnyékolás kiválasztása) lehetőséget.

    Árnyékolás kiválasztása a Unityben

  2. Az árnyékoló objektum kijelölése után válassza a "Kód fordítása és megjelenítése" gombot az Inspector ablak alatt

    A Shader Code fordítása a Unityben

  3. A fordítás után keresse meg az eredmények statisztikai szakaszát a csúcspont és a képpontárnyékoló különböző műveleteinek számával (Megjegyzés: a képpontos árnyékolókat gyakran töredékárnyékoknak is nevezik)

    Unity Standard Shader Operations

Képpontárnyékok optimalizálása

A lefordított statisztikai eredményeknek a fenti módszerrel való vizsgálatával a töredékárnyékoló általában több műveletet hajt végre, mint átlagosan a csúcspontárnyékolója. A töredékárnyékoló, más néven a képpont árnyékoló, képpontonként lesz végrehajtva a képernyőkimeneten, míg a csúcspont árnyékolója csak a képernyőre rajzolt összes háló csúcspontonként lesz végrehajtva.

Így a töredékárnyékolók nem csak a csúcs árnyékolóknál több utasítással rendelkezik, hanem az összes megvilágítási számítás miatt is, a töredékárnyékolók szinte mindig nagyobb adatkészleten vannak végrehajtva. Ha például a képernyőkimenet 2k by 2k kép, akkor a töredékárnyékoló 2 000*2000 = 4 000 000 alkalommal hajthat végre. Két szem megjelenítésekor ez a szám megduplázódik, mivel két képernyő van. Ha egy vegyes valóságú alkalmazás több megfeleltetéssel, teljes képernyős utófeldolgozási effektusokkal vagy több háló ugyanazon képpontra való rendereléssel rendelkezik, ez a szám jelentősen megnő.

Ezért a töredékárnyékolóban a műveletek számának csökkentése általában sokkal nagyobb teljesítménynövekedést eredményez a csúcs árnyékoló optimalizálásainál.

A Unity Standard árnyékoló alternatívái

Fizikai alapú renderelés (PBR) vagy más kiváló minőségű árnyékoló használata helyett inkább egy nagyobb teljesítményű és olcsóbb árnyékolót használ. A Mixed Reality eszközkészlet a vegyes valóságú projektekhez optimalizált MRTK standard árnyékolót biztosítja.

A Unity emellett a Unity Standard árnyékolóhoz képest egy ki nem oszlott, csúcsos, világos és más egyszerűsített árnyékolási lehetőséget is kínál. További információ: A beépített árnyékolók használata és teljesítménye.

Árnyékoló előbetöltése

A Shader előbetöltési és egyéb trükkök használatával optimalizálhatja a shader betöltési idejét. A árnyékolás előbetöltése azt jelenti, hogy a futásidejű árnyékoló fordítása miatt nem fog látni semmilyen tokot.

Korlát túllépte a korlátot

A Unityben megjeleníthető az overdraw a jelenethez, ha a Jelenet nézet bal felső sarkában a rajzolás mód menüjére vált, és az Overdraw lehetőséget használja.

A túlcsatolás általában úgy mérsékelhető, ha előre kiveszi az objektumokat, mielőtt azok el lesznek küldve a GPU-nak. A Unity részletesen beadja az Occlusion Culling a motorhoz való megvalósításának részleteit.

Memória – javaslatok

A túlzott memóriafoglalási & a kiosztási műveletek negatív hatással lehetnek a holografikus alkalmazásra, ami inkonzisztens teljesítményt, lefagyott képkockákat és egyéb káros viselkedést eredményezhet. A Unityben való fejlesztés során különösen fontos a memóriával kapcsolatos szempontokat figyelembe venni, mivel a memóriakezelést a szemétgyűjtő vezérli.

Szemétgyűjtés

A holografikus alkalmazások elveszítik a szemétgyűjtő (GC) feldolgozási idejét, amikor a szemétgyűjtőt aktiválják a végrehajtás során már nem hatókörbe tartozó objektumok elemzéséhez, és ki kell szabadítani a memóriát, hogy újra felhasználható legyen. Az állandó lefoglalások és a delegációk általában megkövetelik, hogy a szemétgyűjtő gyakrabban fusson, ami kihat a teljesítményre és a felhasználói élményre.

A Unity remek oldalt biztosított, amely részletesen ismerteti a szemétgyűjtő működését, és tippeket ad a memóriakezelés hatékonyabb kód írására.

A túlzott szemétgyűjtéshez vezető egyik leggyakoribb eljárás nem a Unity-fejlesztésben használt összetevőkre és osztályokra mutató gyorsítótárazás. Minden hivatkozást a Start() vagy Az úú() alatt kell rögzítettnek lennie, és újra fel kell használni olyan későbbi függvényekben, mint az Update() vagy a LateUpdate().

További gyors tippek:

  • Összetett sztringek dinamikus összeállítása futásidőben a StringBuilder C#-osztály használatával
  • Távolítsa el a Debug.Log() hívásait, ha már nincs rájuk szükség, mivel azok továbbra is futnak egy alkalmazás összes buildverziójában
  • Ha a holografikus alkalmazás általában sok memóriát igényel, fontolja meg a System.GC.Collect() hívását a betöltési fázisok során, például amikor betöltési vagy átváltási képernyőt ad meg

Objektumkészletezés

Az objektumkészletezés egy népszerű technika, amely csökkenti a folyamatos objektumfoglalási és -kiosztási költségeket. Ez az azonos objektumok nagy készletének allokálására és az inaktív, rendelkezésre álló példányok a készletből való újrahasználására történik ahelyett, hogy folyamatosan kiadná és megsemmisíti az objektumokat. Az objektumkészletek nagyszerűen használhatók újrafelhasználható összetevőkhöz, amelyek élettartama változó az alkalmazások során.

Indítási teljesítmény

Fontolja meg, hogy az alkalmazást egy kisebb jelenetben kezdi, majd a SceneManager.LoadSceneAsync használatával betölti a jelenet többi részét. Ez lehetővé teszi, hogy az alkalmazás a lehető leghamarabb interaktív állapotba ássa. Az új jelenet aktiválása közben nagy processzorhasználati csúcs lehet, és minden renderelt tartalom megakhat vagy megakhat. Ennek egyik módja, hogy az AsyncOperation.allowSceneActivation tulajdonságot "false" (hamis) értékre állítsa a betöltött jeleneten, várjon, amíg a jelenet betöltődik, a képernyő túl fekete legyen, majd állítsa vissza "true" (igaz) értékre a jelenet aktiválásának befejezéséhez.

Ne feledje, hogy az indítási jelenet betöltése közben a holografikus kezdőképernyő jelenik meg a felhasználó számára.

Lásd még