Megosztás a következőn keresztül:

Teljesítményjavaslatok a Unityhez

  • Cikk

Ez a cikk a vegyes valóság teljesítményjavaslataira épül, de a Unity-specifikus fejlesztésekre összpontosít.

Nemrég megjelent egy Minőségi alapismeretek nevű alkalmazás, amely a HoloLens 2-alkalmazások általános teljesítményével, tervezésével és környezeti problémáival és megoldásával foglalkozik. Ez az alkalmazás nagyszerű vizualizációs bemutató az alábbi tartalmakhoz.

A Minőségi alapismeretek alkalmazás letöltése

A vegyes valóságú alkalmazások teljesítményének a Unityben való optimalizálásának legfontosabb első lépése annak biztosítása, hogy a Unityhez ajánlott környezeti beállításokat használja. Ez a cikk az előadói Mixed Reality-alkalmazások készítésének legfontosabb jelenetkonfigurációit tartalmazó tartalmakat tartalmazza. Az alábbiakban néhány javasolt beállítás is ki van emelve.

Profilkészítés a Unityvel

A Unity beépített Unity Profilerrel rendelkezik, amely nagyszerű erőforrás az adott alkalmazás értékes teljesítményelemzéseinek gyűjtéséhez. Bár a profilkészítőt szerkesztőben is futtathatja, ezek a metrikák nem a valós futtatókörnyezetet jelölik, ezért az eredményeket óvatosan kell használni. Javasoljuk, hogy távolról profilozza az alkalmazást, miközben az eszközön futtatja a legpontosabb és leghatékonyabb elemzéseket.

A Unity nagyszerű dokumentációt nyújt a következő célokra:

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

GPU-profilkészítés

Unity profiler

A Unity Profiler csatlakoztatva van, és a GPU-profilozó hozzáadása után (lásd a profilkészítő hozzáadása a jobb felső sarokban) láthatja, hogy mennyi időt tölt a processzor és a GPU a profiler közepén. Ez lehetővé teszi a fejlesztő számára, hogy gyors közelítést kapjon, ha az alkalmazás cpu-t vagy GPU-t határolt.

Unity CPU és GPU

Feljegyzés

A GPU-profilkészítés használatához le kell tiltania a Grafikus feladatokat a Unity Player Gépház. További részletekért tekintse meg a Unity GPU-használati profiler modulját.

Unity-keret hibakeresője

A Unity Frame Debugger egy hatékony és éleslátó eszköz is. Ez jó áttekintést nyújt arról, hogy mit csinál a GPU az egyes kereteken. A további renderelési célokat és a közöttük másolandó titkos parancsokat érdemes szemügyre tenni, mivel ezek nagyon drágák a HoloLensben. Ideális esetben a HoloLensben nem szabad képernyőn kívüli megjelenítési célokat használni. Ezek általában akkor jelennek meg, ha költséges renderelési funkciókat (például MSAA, HDR vagy teljes képernyős effektusok, például virágzás) engedélyeznek, amelyeket el kell kerülni.

HoloLens-keretsebesség átfedése

Az Eszközportál rendszerteljesítmény lapja jól összefoglalja az eszköz processzor- és GPU-teljesítményét. Engedélyezheti a képkockasebesség-számláló megjelenítését a headsetben , és megjelenítheti a képkockasebesség-grafikont a headsetben. Ezek a beállítások lehetővé teszik az FPS-számlálót és a gráfot, amely azonnali visszajelzést ad az eszközön futó alkalmazásokról.

PIX

A PIX a Unity-alkalmazások profilkészítésére is használható. A HoloLens 2-hez készült PIX használatára és telepítésére vonatkozó részletes utasítások is megtalálhatók. A fejlesztési buildekben ugyanazok a hatókörök jelennek meg a Unity Frame Debuggerben , mint a PIX-ben, és részletesebben is megvizsgálhatók és profilhatók.

Feljegyzés

A Unity lehetővé teszi az alkalmazás renderelési célfelbontásának egyszerű módosítását futásidőben az XR Gépház.renderViewportScale tulajdonságon keresztül. Az eszközön bemutatott végső kép rögzített felbontással rendelkezik. A platform az alacsonyabb felbontású kimenet mintáját fogja mintaként létrehozni egy nagyobb felbontású képet a megjelenítéshez.

UnityEngine.XR.XRSettings.renderViewportScale = 0.7f;

Cpu-teljesítményre vonatkozó javaslatok

Az alábbi tartalom részletesebb teljesítménnyel kapcsolatos eljárásokat mutat be, különösen a Unity &C# fejlesztésével kapcsolatban.

Gyorsítótárhivatkozások

Javasoljuk, hogy inicializáláskor gyorsítótárazza az összes releváns összetevőre és GameObjectre mutató hivatkozást, mert az ismétlődő függvényhívások, például a GetComponent<T>() és a Kamera.main drágábbak a mutató tárolásához szükséges memóriaköltséghez képest. . Kamera.main csak a FindGameObjectsWithTag() objektumot használja alatta, amely költségesen keres a jelenetdiagramon egy kameraobjektumot a "Main Kamera" 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();
    }
}

Feljegyzés

A GetComponent(sztring) elkerülése
A GetComponent() használatakor néhány különböző túlterhelés van. Fontos, hogy mindig a típusalapú implementációkat használja, és soha ne a sztringalapú keresés túlterhelését. A sztring alapján történő keresés a jelenetben jelentősen költségesebb, mint a típus szerinti keresés.
(Jó) Összetevő GetComponent(Típus típusa)
(Jó) T GetComponent<T>()
(Rossz) Összetevő GetComponent(sztring)>

Kerülje a költséges műveleteket

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

    Bár a LINQ lehet tiszta, könnyen olvasható és írható, általában több számítást és memóriát igényel, 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, bár hasznosak, költségesek lehetnek a végrehajtásukhoz. Ezek többsége magában foglalja a teljes jelenetdiagram keresését a GameObjects megfelelő listájához. Ezek a műveletek általában elkerülhetők a hivatkozások gyorsítótárazásával vagy a GameObjects kezelői összetevőjének implementálásával 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()

Feljegyzés

A SendMessage() és a BroadcastMessage() elemet minden áron el kell távolítani. Ezek a függvények 1000-szer lassabb sorrendben lehetnek, mint a közvetlen függvényhívások.

  1. Óvakodj az ökölvívástól

    A boxing a C# nyelv és a futtatókörnyezet alapvető fogalma. Ez az érték típusú változók, például char, int, boolstb. referencia típusú változókba való körbefuttatásának folyamata. Ha egy érték típusú változó "dobozos", a rendszer egy System.Object, a felügyelt halomon tárolt értékbe csomagolja. A rendszer lefoglalja a memóriát, és végül az ártalmatlanításkor a szemétgyűjtőnek kell feldolgoznia. Ezek a kiosztások és felszabadítá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 dobozolás elkerülése érdekében győződjön meg arról, hogy a numerikus típusok és szerkezetek tárolására szolgáló változók, mezők és tulajdonságok (beleértve Nullable<T>a ) erősen vannak begépelve, például intobjektum float?MyStructhasználata helyett. Ha ezeket az objektumokat egy listába helyezi, mindenképpen használjon erősen gépelt listát, például List<int> nem List<object> vagy ArrayListnem.

    Példa a C-ben való ökölvívásra#

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

Ismétlődő kódútvonalak

Minden ismétlődő Unity visszahívási függvényt (pl. Update) gondosan meg kell írni, amely másodpercenként és/vagy keretenként többször fut. Minden költséges műveletnek óriási és konzisztens hatása lesz a teljesítményre.

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

    Bár az alábbi kód ártatlannak tűnhet az alkalmazásban való kilépéshez, 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 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 működik. A hídon való váltás meglehetősen költséges, még akkor is, ha nincs mit végrehajtani. Ez különösen akkor válik problémássá, ha az alkalmazás több mint 100 GameObjects összetevővel rendelkezik, amelyek üres ismétlődő Unity-visszahívásokkal rendelkeznek.

    void Update()
{
}

Feljegyzés

A teljesítményproblémának az Update() a leggyakoribb megnyilvánulása, de más ismétlődő Unity-visszahívások, például a következők is lehetnek ugyanolyan rosszak, ha nem rosszabbak: FixedUpdate(), LateUpdate(), OnPostRender", OnPreRender(), OnRenderImage(), stb.

  1. A keretenkénti egyszeri futtatás előnyben részesítésére használható műveletek

    Az alábbi Unity API-k számos Holographic-alkalmazás gyakori műveletei. Bár nem mindig lehetséges, az ezekből a függvényekből származó eredményeket általában egyszer lehet kiszámítani, és az eredményeket az alkalmazás egy adott kerethez újra felhasználhatja.

    a) Ajánlott egy dedikált Singleton-osztály vagy szolgáltatás használata a Raycast látványának a jelenetbe való kezeléséhez, majd az összes többi jelenetösszetevőben való ismételt és azonos Raycast-műveletek helyett. Egyes alkalmazásokhoz különböző eredetű raycastok vagy különböző Rétegmaszkok szükségesek.

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

    b) Kerülje a GetComponent() műveleteket az ismétlődő Unity-visszahívásokban, például az Update() szolgáltatásban a Start() vagy az Awake() hivatkozásainak gyorsítótárazásával 

        UnityEngine.Object.GetComponent()

    c) Célszerű az összes objektumot példányosítani, ha lehetséges, inicializáláskor, és objektumkészletezéssel újrahasznosítani és újra felhasználni a GameObjectset az alkalmazás teljes futásidejében

        UnityEngine.Object.Instantiate()

  2. Interfészek és virtuális szerkezetek elkerülése

    A függvényhívások közvetlen objektumok vagy virtuális függvények meghívása gyakran sokkal drágább, mint a közvetlen szerkezetek vagy a 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. Ezeknek a megközelítéseknek a teljesítménybeli értéke azonban akkor éri meg a kompromisszumot, ha ezek használata leegyszerűsíti a fejlesztési együttműködést, a kód olvashatóságát és a kód karbantarthatóságát.

    A javaslat általában az, hogy ne jelöljön meg mezőket és függvényeket virtuálisként, hacsak nincs egyértelmű elvárás, hogy ezt a tagot felül kell írni. Különösen óvatosnak kell lennie a nagy gyakoriságú kódútvonalakkal, amelyeket keretenként vagy keretenként akár csak egyszer is meghívnak, például egy metódust UpdateUI() .

  3. Ne adja át a szerkezeteket érték szerint

    Az osztályoktól eltérően a szerkezetek érték típusúak, és ha közvetlenül egy függvénynek adnak át, a rendszer a tartalmát egy újonnan létrehozott példányba másolja. Ez a másolat processzorköltséget és további memóriát ad hozzá a veremhez. A kis szerkezetek esetében a hatás minimális és így elfogadható. Ha azonban a függvények minden keretet ismételten meghívnak, valamint a nagy szerkezeteket tartalmazó függvényeket, lehetőség szerint módosítsa a függvénydefiníciót hivatkozás útján történő továbbításra. További információ itt

Egyéb

  1. Fizika

    a) A fizika javításának legegyszerűbb módja általában a fizikával töltött idő vagy a másodpercenkénti iterációk számának korlátozása. Ez csökkenti a szimuláció pontosságát. TimeManager megtekintése a Unityben

    b) A Unityben a ütközők típusai jelentősen eltérő teljesítményjellemzőkkel rendelkeznek. Az alábbi sorrendben balról jobbra a legkevésbé teljesíthető ütközők láthatók. Fontos elkerülni a Mesh Colliderst, amelyek lényegesen drágábbak, mint a primitív ütközők.

    Sphere < Capsule < Box <<< Mesh (Convex) < Mesh (nem Convex)

    További információért tekintse meg a Unity Fizika ajánlott eljárásait

  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 ugyanolyan hatással). Kerülje azokat a tervezési mintákat, amelyekben az animátor egy hurokban ül, és ugyanazt az értéket állítja be. Ennek a technikának jelentős többletterhelése van, és nincs hatással az alkalmazásra. További információt itt talál.

  3. Összetett algoritmusok

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

PROCESSZOR–GPU teljesítményjavaslatok

A PROCESSZOR–GPU teljesítmény általában a grafikus kártyára küldött rajzhívásokra csökken. A teljesítmény javítása érdekében a hívásokat stratégiailag a) csökkentenivagy 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ésük csökkenti az általánosan szükséges munkát. Emellett a rajzhívások közötti állapotváltozások költséges érvényesítési és fordítási lépéseket igényelnek a grafikus illesztőprogramban, így az alkalmazás rajzhívásainak átalakítása az állapotváltozások korlátozása érdekében (például különböző anyagok stb.) növelheti a teljesítményt.

A Unity egy nagyszerű cikket kínál, amely áttekintést nyújt, és betekintést nyújt a platformhoz tartozó kötegelési hívásba.

Egybemenő példányos renderelés

A Single Pass Instanced Rendering in Unity lehetővé teszi, hogy minden szem hívása egy példányos hívásra csökkenjen. A két hívás közötti gyorsítótár-kovetkeztetés miatt a GPU-n is van némi teljesítménybeli javulás.

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

  1. Nyissa meg az OpenXR Gépház (nyissa meg a Project Gépház> XR beépülő modulkezelő>OpenXR szerkesztését).>
  2. A Renderelési mód legördülő menüben válassza a Single Pass Instanced lehetőséget.

Ennek a megjelenítési módszernek a részleteiért olvassa el a Unity alábbi cikkeit.

Feljegyzés

A Single Pass Instanced Rendering egyik gyakori problémája akkor fordul elő, ha a fejlesztők már rendelkeznek olyan egyéni árnyékolókkal, amelyeket nem instancingra írtak. A funkció engedélyezése után a fejlesztők észrevehetik, hogy egyes GameObjects-elemek csak egy szemen belül jelennek meg. Ennek az az oka, hogy a társított egyéni árnyékolók nem rendelkeznek a megfelelő tulajdonságokkal az instancinghoz.

Statikus kötegelés

A Unity számos statikus objektumot képes kötegelni, hogy csökkentse a GPU-ra irányuló hívásokat. A statikus kötegelés a Unity legtöbb renderelő objektumához működik, amelyek 1) azonos anyaggalés 2) mind statikusként vannak megjelölve (Jelöljön ki egy objektumot a Unityben, és jelölje be a jelölőnégyzetet az ellenőr jobb felső sarkában). A Statikusként megjelölt GameObjects nem helyezhető át az alkalmazás futásideje alatt. Így a statikus kötegelést nehéz lehet kihasználni a HoloLensben, ahol gyakorlatilag minden objektumot el kell helyezni, áthelyezni, skálázni stb. A modern headsetek esetében a statikus kötegelés jelentősen csökkentheti a híváshívásokat, és ezáltal javíthatja a teljesítményt.

További részletekért olvassa el a Statikus kötegelés szakaszt a Híváskötegelés készítése a Unityben című témakörben.

Dinamikus kötegelés

Mivel a HoloLens-fejlesztéshez problémás az objektumok statikusként való megjelölése, a dinamikus kötegelés kiváló eszköz lehet a hiányzó funkció kompenzálására. A modern fejhallgatókban is hasznos lehet. A Unityben azonban a dinamikus kötegelést nehéz lehet engedélyezni, mert a GameObjectsnek a) azonos anyagból kell rendelkeznie, és b) meg kell felelnie a többi feltétel hosszú listájának.

Olvassa el a dinamikus kötegelést a Híváskötegelés rajzolása csoportban a Unityben a teljes listához. A GameObjects leggyakrabban érvénytelenné válik a dinamikus kötegelési művelethez, mivel a társított hálóadatok legfeljebb 300 csúcspontot tartalmazhatnak.

Egyéb technikák

Kötegelés csak akkor fordulhat elő, ha több GameObjects képes megosztani ugyanazt az anyagot. Ezt általában az fogja blokkolni, hogy a GameObjectsnek egyedi anyagmintával kell rendelkeznie a megfelelő anyaghoz. Gyakori, hogy a textúra egy nagy textúra, egy úgynevezett Textúra Atlasing nevű módszer.

Ezenkívül célszerű a hálókat egy GameObjectbe egyesíteni, ahol lehetséges és ésszerű. A Unity minden renderelője rendelkezik a kapcsolódó rajzhívással vagy -hívásokkal, és nem küld el egy kombinált hálót egy Renderer alatt.

Feljegyzés

A Renderer.material tulajdonságainak futásidőben történő módosítása létrehozza az anyag másolatát, és ezáltal megszakítja a kötegelést. A Renderer.sharedMaterial használatával módosíthatja a megosztott anyagok tulajdonságait a GameObjectsben.

GPU-teljesítményjavaslatok

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

Sávszélesség és kitöltési sebesség

A GPU-n lévő keret renderelésekor az alkalmazáshoz memória-sávszélesség vagy kitöltési sebesség van kötve.

  • A memória sávszélessége a GPU memóriából elvégezhető olvasási és írási sebessége
    • A Unityben módosítsa a Textúra minőségét a Project Gépház> Quality Gépház szerkesztésében.>
  • A kitöltési sebesség a GPU által másodpercenként rajzolható képpontokra vonatkozik.

A mélységi puffer megosztásának optimalizálása

Javasoljuk, hogy engedélyezze a mélységi puffermegosztást a hologram stabilitásának optimalizálása érdekében. Ha ezzel a beállítással engedélyezi a mélységalapú késői szakaszos újraprojeciót, javasoljuk, hogy a 24 bites mélységi formátum helyett a 16 bites mélységi formátumot válassza. A 16 bites mélységi pufferek drasztikusan csökkentik a mélységi pufferforgalomhoz társított sávszélességet (és így a teljesítményt). Ez nagy előrelépés lehet mind az energiacsökkentésben, mind a teljesítményben. 16 bites mélységi formátum használatával azonban két lehetséges negatív eredmény érhető el.

Z-Fighting

A csökkentett mélységtartomány hűsége miatt a z-harcok nagyobb valószínűséggel fordulnak elő 16 bites, mint 24 bites. Ezeknek az összetevőknek a elkerülése érdekében módosítsa a Unity kamera közel/messze vágósíkjait, hogy figyelembe vegyék az alacsonyabb pontosságot. A HoloLens-alapú alkalmazások esetében a Unity alapértelmezett 1000 m helyett egy 50 m-nyi távoli klipsík általában kiküszöböli a z-harcokat.

Letiltott rajzsablon puffere

Amikor a Unity 16 bites mélységű renderelési textúrát hoz létre, nem jön létre rajzsablonpuffer. Ha kiválasztja a Unity dokumentációjában leírt 24 bites mélységi formátumot, létrehoz egy 24 bites z-puffert és egy 8 bites rajzsablonpuffert (ha 32 bites alkalmazható egy eszközön (például a HoloLensre), ami általában így van).

A teljes képernyős effektusok elkerülése

A teljes képernyőn működő technikák költségesek lehetnek, mivel nagyságrendjük több millió művelet minden keretben. Javasoljuk, hogy kerülje a feldolgozás utáni hatásokat , például az élsimítást, a virágzást és egyebeket.

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

A Unity valós idejű globális megvilágítása kiváló vizuális eredményeket biztosíthat, de költséges világítási számításokat is magában foglal. Javasoljuk, hogy tiltsa le a valós idejű globális megvilágítást minden Unity-jelenetfájl esetében a Window>Rendering>Lighting Gépház>a valós idejű globális megvilágítás ellenőrzésének megszüntetése érdekében.

Emellett javasoljuk, hogy tiltsa le az árnyékolást, mivel ezek drága GPU-átadásokat is hozzáadnak a Unity-jelenethez. Az árnyékok fényenként letilthatók, de holisztikusan is szabályozhatók a minőségi beállításokon keresztül.

Szerkessze a Project Gépház, majd válassza az UWP-platform Minőség kategóriát>.> Az Árnyékok tulajdonságot is beállíthatja az Árnyékok letiltása beállításra.

Javasoljuk, hogy a Unityben használjon sütéses világítást a modelljeivel.

Poliszám csökkentése

A sokszögek száma a következővel csökken:

  1. Objektumok eltávolítása egy jelenetből
  2. Eszköz decimációja, amely csökkenti egy adott háló sokszögeinek számát
  3. Részletességi szintű (LOD) rendszer implementálása az alkalmazásba, amely távolról jeleníti meg azokat az objektumokat, amelyek ugyanazon geometria kisebb sokszögű verzióját tartalmazzák

A Unity árnyékolóinak ismertetése

Az árnyékolók teljesítménybeli összehasonlításának egyszerű közelítése, ha azonosítja az egyes futtatások futásidejében végrehajtott műveletek átlagos számát. Ez könnyen elvégezhető a Unityben.

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

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

  2. Ha a shader-objektum ki van jelölve, válassza a "Kód fordítása és megjelenítése" gombot az ellenőr ablakában

    Shader Code fordítása a Unityben

  3. Az összeállí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éppontárnyékolókat gyakran töredékárnyékolóknak is nevezik)

    Unity Standard Shader-műveletek

Képpontárnyékolók optimalizálása

A fenti módszerrel összeállított statisztikai eredményeket tekintve a töredékárnyék-árnyékoló általában több műveletet hajt végre, mint a csúcspont-árnyékoló. A töredékárnyékolót( más néven képpontárnyékolót) a rendszer képpontonként hajtja végre a képernyő kimenetén, míg a csúcsos árnyékoló csak a képernyőre rajzolt összes háló csúcsánként lesz végrehajtva.

Így nem csak a töredékárnyékolók rendelkeznek több utasítással, mint a csúcsárnyékolók az összes világítási számítás miatt, a töredékárnyékolók szinte mindig nagyobb adathalmazon hajthatók végre. Ha például a képernyő kimenete 2k és 2k kép, akkor a töredékárnyékoló 2 000*2 000 = 4 000 000 alkalommal hajtható végre. Ha két szemet jelenít meg, ez a szám megduplázódik, mivel két képernyő van. Ha egy vegyes valóságú alkalmazás több áthaladással, teljes képernyős utófeldolgozási effektusokkal vagy több háló ugyanazon képpontra való megjelenítésével rendelkezik, ez a szám jelentősen megnő.

Ezért a töredékárnyékolóban végzett műveletek számának csökkentése általában sokkal nagyobb teljesítménynövekedést okozhat a csúcspont-árnyékoló optimalizálásával szemben.

Unity Standard shader alternatívák

Fizikai alapú renderelés (PBR) vagy egy másik kiváló minőségű árnyékoló használata helyett tekintse meg a teljesítményesebb és olcsóbb árnyékoló használatát. A Mixed Reality eszközkészlet az MRTK standard árnyékolót biztosítja, amely vegyes valóságú projektekhez lett optimalizálva.

A Unity emellett a Unity Standard árnyékolóhoz képest gyorsabb, kivilágítatlan, csúcsfényes, diffúz és egyéb egyszerűsített árnyékolási lehetőségeket is biztosít. Részletesebb információkért tekintse meg a beépített árnyékolók használatát és teljesítményét.

Shader előzetes betöltése

A Shader előzetes betöltésével és más trükkökkel optimalizálhatja a shader betöltési idejét. A shader előbetöltése különösen azt jelenti, hogy a futtatókörnyezet-árnyékoló fordítása miatt nem jelennek meg a találatok.

Túllépés korlátozása

A Unityben a Jelenet nézet bal felső sarkában a Rajz mód menü összevonásával és a Overdraw (Overdraw) lehetőség kiválasztásával jeleníthető meg a jelenet túlhúzása.

A felülírás általában az objektumoknak a GPU-ba való elküldése előtt történő selejtezésével enyhíthető. A Unity részletesen ismerteti az Occlusion Culling motorhoz való implementálását.

Memóriajavaslatok

A túlzott memóriafoglalási és felszabadítási műveletek kedvezőtlen hatással lehetnek a holografikus alkalmazásra, ami inkonzisztens teljesítményt, befagyott kereteket és egyéb káros viselkedést eredményezhet. Különösen fontos megérteni a memória szempontjait a Unityben való fejlesztéskor, mivel a memóriakezelést a szemétgyűjtő vezérli.

Szemétgyűjtés

A holografikus alkalmazások elveszítik a számítási időt a szemétgyűjtő (GC) számára, amikor a GC aktiválva van az olyan objektumok elemzéséhez, amelyek már nem tartoznak hatókörbe a végrehajtás során, és a memóriájukat ki kell szabadítani, hogy újra felhasználhatók legyenek. Az állandó foglalások és lefoglalások általában megkövetelik, hogy a szemétgyűjtő gyakrabban fusson, ami rontja a teljesítményt és a felhasználói élményt.

A Unity egy kiváló oldalt biztosított, amely részletesen ismerteti a szemétgyűjtő működését, és tippeket nyújt a hatékonyabb kódíráshoz a memóriakezelés terén.

Az egyik leggyakoribb eljárás, amely túlzott szemétgyűjtéshez vezet, nem gyorsítótárazási hivatkozások a Unity-fejlesztés összetevőire és osztályaira. A hivatkozásokat a Start() vagy az Awake() során kell rögzíteni, és a későbbi függvényekben, például az Update() vagy a LateUpdate() függvényben újra fel kell használni.

Egyéb gyors tippek:

  • A StringBuilder C# osztály használatával dinamikusan hozhat létre összetett sztringeket futtatókörnyezetben
  • Ha már nincs rájuk szükség, távolítsa el a Debug.Log() hívásait, mivel továbbra is végrehajtják az 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() meghívását a betöltési fázisokban, például egy betöltési vagy áttűnési képernyő megjelenítésekor

Objektumkészletezés

Az objektumkészletezés egy népszerű módszer a folyamatos objektumfoglalás és felszabadítások költségeinek csökkentésére. Ez egy nagy méretű, azonos objektumokból álló készlet kiosztásával és az inaktív, rendelkezésre álló példányok újrafelhasználásával történik a készletből, nem pedig az objektumok folyamatos ívásával és megsemmisítésével. Az objektumkészletek nagyszerűen használhatók olyan újrafelhasználható összetevőkhöz, amelyek változó élettartammal rendelkeznek egy alkalmazás során.

Indítási teljesítmény

Érdemes lehet kisebb jelenettel elindítani az alkalmazást, majd a SceneManager.LoadSceneAsync használatával betölteni a jelenet többi részét. Ez lehetővé teszi, hogy az alkalmazás a lehető leggyorsabban interaktív állapotba lépjen. Előfordulhat, hogy az új jelenet aktiválása közben nagy cpu-kiugró csúcs jelenik meg, és a renderelt tartalmak akadozhatnak vagy ütközhetnek. Ennek egyik módja, ha az AsyncOperation.allowSceneActivation tulajdonságot "false" értékre állítja a betöltött jeleneten, várja meg, amíg a jelenet betöltődik, törölje a képernyőt feketére, majd állítsa vissza "true" értékre a jelenet aktiválásának befejezéséhez.

Ne feledje, hogy amíg az indítási jelenet betöltődik, a holografikus kezdőképernyő megjelenik a felhasználó számára.

Lásd még