Optimering av mobila 3D-spel i Unity 6 år 2026: DOTS, GPU Resident Drawer och nya hybridpipelines

En komplett praktisk guide för att nå stabila 60–120 FPS i krävande mobila 3D-projekt baserade på Unity 6 och URP. Vi går igenom moderna grafikpipelines, överföring av beräkningar till GPU:n med GPU Resident Drawer, DOTS-arkitekturen och de aktuella tekniska kraven från App Store och Google Play för 2026.

Utveckling av högpresterande 3D-spel i Unity 6 under 2026 kräver en tydlig förståelse för de förändringar i den mobila hårdvarustacken som har skett under de senaste åren. Eran för det föråldrade grafik-API:et OpenGL ES 3.x är definitivt över: Google Play och Apple App Store har i praktiken etablerat Vulkan 1.3 och Metal 3 som den självklara standarden för modern grafik. Att försöka upprätthålla föråldrade grafikpipelines i Unity 6 berövar projektet tillgång till kritiska arkitektoniska funktioner – från direkt hantering av buffertsynkronisering till hårdvaruaccelererad kommandoritning på GPU-sidan.

För att utforma målgrafikprofiler och skaleringssystem för 2026–2027 identifieras tre huvudsakliga hårdvarukategorier:

• Low-End (Minimiprofil / Massmarknad 30 FPS): Enheter baserade på kretsuppsättningar på nivån Arm Mali-G610/G710, Snapdragon 6-serien och basala Exynos-processorer. Utrustade med 4–6 GB RAM av typen LPDDR4X/LPDDR5. Grafik-API: Vulkan 1.3 utan stöd för avancerad resurshantering (bindless). Huvudsaklig begränsning: smal minnesbuss (upp till 25–30 GB/s) och hög risk för cachemissar vid användning av tunga PBR-shaders.
• Mid-Tier (Målprofil 60 FPS): Enheter i det övre mellansegmentet med Snapdragon 7-serien (inklusive Gen 4/5), Dimensity 8300/8400 och Apple A16/A17. Kännetecknas av 8–12 GB LPDDR5X samt fullt stöd för Vulkan 1.3 (med obligatoriska `VK_EXT_descriptor_indexing` och `VK_KHR_dynamic_rendering`). Detta segment kan stabilt hantera hybrida pipelines i Unity 6 med hjälp av GPU Resident Drawer och avancerad culling-heuristik.
• High-End / Flaggskepp (High-FPS, 90–120 FPS, hårdvaruaccelererad strålspårning): Flaggskeppslösningar baserade på Apple A19 Pro / M5, Qualcomm Snapdragon 8 Elite / Gen 5 och MediaTek Dimensity 9500+. Utrustade med 12–16 GB ultrasnabbt LPDDR5X/LPDDR6-minne. Stödjer hårdvaruaccelererad Mesh Shading, strålspårning i realtid och inbyggda NPU-enheter för AI-uppskalning (MetalFX Spatial/Temporal, FidelityFX Super Resolution 3.1 Mobile).

En nyckelfaktor vid optimering för mobila GPU:er förblir specifikationen för TBDR-arkitekturen (Tile-Based Deferred Rendering), som används av Arm Immortalis-, Qualcomm Adreno- och Apple GPU-kretsar. Till skillnad från stationära datorers direct rendering-arkitekturer (Immediate Mode) delar TBDR-kretsar upp skärmen i små rutor (tiles, vanligtvis 16x16 eller 32x32 pixlar) och bearbetar geometri och fragment inuti ett snabbt minne på själva chippet (On-Chip SRAM/Tile Memory).

Den viktigaste regeln för optimering för TBDR under 2026 är att förhindra minnesbandbreddsstrypning (bandwidth throttling). Att överföra mellanliggande data från tile-minnet till det huvudsakliga LPDDR-minnet och tillbaka överhettar enheten kritiskt. Till de huvudsakliga arkitektoniska flaskhalserna för TBDR hör avbrott i tile-passet:

• Ooptimerade Render Passes: Användning av ogrupperade eftereffekter och täta växlingar av bildrutebuffertar (Render Targets) utan uttryckligt angivande av `StoreAction.DontCare` eller `LoadAction.Clear` tvingar GPU:n att tömma tile-innehållet till det globala RAM-minnet, vilket förstör prestandan.
• Överdrivet Alpha Blending-djup: Rendering av flera halvtransparenta lager (partiklar, tät vegetation, UI) orsakar stor belastning vid omberäkning av fragment inuti tilen (Overdraw), vilket leder till att bildfrekvensen sjunker.
• Ineffektiv Depth Pre-pass: På TBDR-arkitekturer fungerar den hårdvarubaserade HSR-enheten (Hidden Surface Removal, till exempel i Apple GPU eller Adreno Early-Z) automatiskt på tile-nivå. Att använda en manuell djuppass (Depth Pre-pass) utan behov skapar en onödig belastning på pipelinens vertexsteg och ökar geometritrafiken.

Ytterligare ett hot under 2026 förblir Thermal Throttling (termisk strypning). Moderna 2 nm- och 3 nm-tillverkningsprocesser gör det möjligt för mobila SoC:er att uppvisa en fenomenal topprestanda, men utan sträng kontroll över TDP (Thermal Design Power) överhettas enheten under de första 3–5 minuterna av spelet. GPU-frekvensfallet vid strypning kan nå 40–50 %. Uppgiften för en modern optimeringspipeline i Unity 6 är inte bara att visa stabila 60 FPS på en kall telefon i ett benchmark, utan att bibehålla en jämn Frame Pacing och minimal strömförbrukning under en 45 minuter lång spelsession.

Övergången i Unity 6 till det nya Render Graph API:et i URP och införandet av GPU Resident Drawer är utformade just för hårdvarans egenskaper 2026–2027. De gör det möjligt att radikalt minska CPU-overhead för förberedelse av ritkommandon (Draw Calls), vilket ger möjlighet att överföra resurshanteringen direkt till GPU:n och utnyttja processorns tile-minne för fullt med minimal användning av LPDDR-minnesbussen.

Evolutionen av Universal Render Pipeline (URP) i Unity 6-arkitekturen markerar den slutgiltiga övergången från imperativa renderingsmodeller till en helt deklarativ, grafbaserad pipeline. I dagens mobila utvecklingspraxis uppnås optimering inte så mycket genom att minska antalet polygoner, utan snarare genom effektiv hantering av minnesbandbredden (Memory Bandwidth) och förhindrande av termisk strypning (Thermal Throttling) på mobila SoC:er. Mobila grafikprocessorer med TBDR-arkitektur (Tile-Based Deferred Rendering), såsom ARM Mali, Qualcomm Adreno och Apple Silicon-lösningar, är extremt känsliga för onödiga läs- och skrivoperationer mellan lokalt tile-minne (SRAM) och systemminne (DRAM). Det huvudsakliga arkitektoniska svaret i Unity 6 på dessa begränsningar är den omarbetade och nu obligatoriska mekanismen Render Graph.

I tidigare generationer av motorn kontrollerade ingenjörer temporära texturer manuellt via `RenderTexture.GetTemporary`-anrop, vilket regelbundet ledde till VRAM-fragmentering, otydliga `CopyTexture`-anrop och onödiga `Load/Store`-operationer för framebuffern på mobila GPU:er. I Unity 6 bygger Render Graph API självständigt en riktad acyklisk graf (DAG) av alla renderingspass redan innan kommandona överförs till ett lågnivå-grafik-API (Vulkan 1.3 eller Metal 3). Detta gör att motorn kan utföra heltäckande statisk och dynamisk bildruteoptimering.

Viktiga arkitektoniska nyheter i URP i Unity 6 som direkt påverkar prestandan i mobila 3D-projekt:

• Automatisk hantering av temporära resurser (Transient Resources) och Memory Aliasing: Bildrutebuffertar (djupbuffertar, skuggkartor, MSAA-attachments, intermediära HDR-texturer) allokeras strikt under exekveringen av en specifik nod i grafen. Mekanismen för Memory Aliasing överlappar fysiskt tidsmässigt icke-överlappande buffertar på samma adressområde i GPU-minnet, vilket minskar spelets totala VRAM-fotavtryck.
• Automatisk sammanslagning av pass (Pass Merging) och nativa Subpasses: Render Graph analyserar intilliggande pass och översätter dem automatiskt till nativa Vulkan Subpasses eller Metal Render Command Encoders. Data (till exempel normaler och djup) överförs mellan pass direkt i processorns snabba Tile Memory (SRAM) utan att tömmas till DRAM, vilket minskar chippets energiförbrukning vid rendering med upp till 35–40 %.
• Zero-Allocation på C#-API-nivå: Exekveringen av Render Graph i Unity 6 är helt fri från allokeringar i den hanterade heapen (Managed Heap) under uppbyggnad och validering av bildrutan. Pass och anropskontexter använder snabba datastrukturer baserade på `NativeArray` och specialiserade lågnivå-kommandobuffertar, vilket eliminerar skräpsamlarens (GC) arbete helt under renderingen.
• Direkt integration av beräkningsskuggare (Compute Shaders): Det är nu möjligt att sömlöst bädda in GPU-beräkningar (GPU-culling, partikelsimulering, procedurgenerering) i den övergripande bildrutegrafen med automatisk placering av minnesbarriärer (Execution & Memory Barriers) från Unitys sida.

En viktig del av den uppdaterade arkitekturen är verktyget Frame Debugger. Det visar inte bara en kedja av `DrawCall` utan den faktiska topologin för Render Graph: fysiska gränser för RenderPass/Subpass, minnesaliasing och punkter för oönskade tile-tömningar (Tile Flush). Detta gör det möjligt att upptäcka arkitektoniska fel – som en oavsiktligt utlöst tile-tömning på grund av att en textur lästs från ett skript vid fel tillfälle – redan under profileringsstadiet i editorn.

URP-arkitekturen i Unity 6 flyttar fokuset för mobil optimering från primitiv minskning av antalet ritanrop till att designa en korrekt bildrutegraf. För moderna mobila 3D-spel är en korrekt konfiguration av Render Graph grunden för att uppnå stabila 60 eller 120 FPS utan att batteriet laddas ur snabbt eller att enheten överhettas.

Under många år har den största flaskhalsen vid optimering av mobila 3D-spel varit på CPU-sidan. I arkitekturer med tile-baserad rendering (TBDR), som är typiska för moderna mobila kretsuppsättningar som Snapdragon, Dimensity och Apple A-serien, kan grafikprocessorn hantera geometri med hög effektivitet, men scenförberedelsen på CPU skapar en kritisk flaskhals. Varje bildruta tvingas processorn utföra Frustum Culling, sortera transparenta och opaka objekt, skapa listor över draw calls samt överföra transformationsmatriser till GPU VRAM. I Unity 6 förändrar tekniken GPU Resident Drawer (GRD), som är inbyggd i den uppdaterade Universal Render Pipeline (URP), detta paradigm helt genom att flytta geometrihanteringen och förberedelsen av draw calls helt och hållet till grafikchippet.

I grunden bygger GPU Resident Drawer på evolutionen av det lågnivå-API:et BatchRendererGroup (BRG). I traditionella pipelines (inklusive den klassiska SRP Batcher) fortsatte CPU:n att iterera över varje registrerat objekt, även om det inte ändrat sin position i rummet, för att bekräfta dess synlighet och uppdatera Uniform-buffertar. GPU Resident Drawer överför transformationsmatriser, material- och instansdata till en persistent (permanent) lagring i grafikminnet – en så kallad GPU Resident Data Buffer (implementerad via StructuredBuffers eller SSBO). Nu läses transformer in i VRAM en enda gång när objektet spawnas eller instansieras, och när de ändras uppdateras de punktvis via Compute Shaders eller asynkrona skrivkommandon.

Det största genombrottet för GRD år 2026 är att steget GPU Frustum & Occlusion Culling helt överlämnats till beräkningsshaders (Compute Shaders). Renderingen av en bildruta med GPU Resident Drawer bygger på följande högpresterande algoritm:

• Datapersistens: Scenen lagrar geometri, LOD-nivåer och materialdata direkt i grafikminnet som kompakta datastrukturer, vilket eliminerar överföring från host-to-device i varje bildruta.
• GPU-Culling: Beräkningsshadern körs före geometrirenderingsfasen. Den kontrollerar parallellt tusentals Bounding Boxes för objekt mot kamerans siktsyta (Frustum) och skär bort skymda objekt (Occlusion) om Hierarchical Z-Buffer (Hi-Z) är aktiverat.
• Skapande av Indirect Buffers: Istället för att överföra listor med Draw Calls från CPU:n skapar Compute Shader själv kommandona i GPU-minnet (Count och Offset) och förbereder argument för indirekta draw calls.
• Indirect Drawing Execution: Grafikprocessorn exekverar kommandon via hårdvaruinstruktioner som vkCmdDrawIndexedIndirect i Vulkan 1.3/1.4 eller `drawIndexedPrimitives` i Metal 3. Bildrutan samlas ihop helt utan ingrepp från CPU:ns huvudtråd (Main Thread) eller renderingstråd (Render Thread).

På mobila grafikarkitekturer (ARM Mali-G720/G820, Qualcomm Adreno 750/800-serien, Apple Graphics) ger detta en fundamentalt lägre energiförbrukning och minskad termisk strypning (thermal throttling). Tidigare, vid rendering av komplexa öppna miljöer med tiotusentals miljöelement (vegetation, klippor, mindre rekvisita, byggnader), tillbringade CPU Render Thread 6 till 12 millisekunder enbart på att förbereda anrop. Med GPU Resident Drawer minskar belastningen på CPU:ns renderingstråd till en bråkdel av en millisekund (ofta ner till ~0,2–0,5 ms), eftersom CPU:n endast skickar ett enda övergripande styrningsanrop för renderingsfasen till GPU:n.

För att låsa upp den fulla potentialen hos GPU Resident Drawer i Unity 6 måste utvecklare följa specifika krav på shaders och datastrukturer. Grafiska material måste stödja DOTS Instancing. I Shader Graph ställs detta in genom att aktivera rutan Enable DOTS Instancing i Target Settings-egenskaperna. Om du använder handskrivna HLSL-shaders krävs implementering av makron som UNITY_DOTS_INSTANCING_START och UNITY_DOTS_INSTANCED_PROP, vilka omdirigerar matrisanrop korrekt via byte-adressbuffertar (ByteAddressBuffer).

En jämförande prestandaanalys vid rendering av en krävande mobil miljö (50 000 statiska och halvdynamiska objekt) visar följande resultat:

• SRP Batcher (klassiskt tillvägagångssätt): CPU Render Thread: 8,4 ms | Draw Calls: ~4 200 | CPU-bound strypning efter 4 minuters spelande.
• GPU Resident Drawer (Unity 6 URP): CPU Render Thread: 0,3 ms | Instanced Draw Calls: ~18 (grupperade efter materialtyp) | GPU-bound stabila 60 FPS på mellansegmentets enheter.

Trots sin tekniska överlägsenhet kräver användningen av GPU Resident Drawer i en mobil pipeline hänsyn till specifika begränsningar. För det första ställs stränga krav på minnesarkitekturen: strukturerade buffertar måste linjeras längs 16-bytesgränser för att undvika prestandastraff vid felaktig VRAM-åtkomst på Mali-kretsar. För det andra, även om Unity 6 avsevärt har utökat stödet för Skinned Mesh Renderers inom GRD genom att köra skinning via Compute Shaders (Compute Skinning), krävs noggrann konfiguration av GPU Allocator-minnesbudgeten för karaktärer med hög ben-densitet och blendshapes.

I en praktisk pipeline för 2026–2027 betraktas ett hybridtillvägagångssätt som branschstandard: miljöer, rekvisita, interaktiv förstörbar geometri och storskaliga ECS-baserade enheter flyttas helt till GPU Resident Drawer, medan unika hero-karaktärer med komplex materiallogik och transparenseffekter kan renderas via det vanliga Render Graph-flödet. Detta garanterar maximal besparing av CPU-cykler och förhindrar att mobila enheter överhettas under långa spelsessioner.

Övergången till hybrida renderingspipeliner och det fullständiga utnyttjandet av GPU Resident Drawer-teknologin i Unity 6 förändrar fundamentalt kraven på förberedelse av spelassets. I traditionell CPU-orienterad rendering utför CPU:n Frustum- och Occlusion Culling före varje bildruta, sorterar objekt efter material och skapar kommandopaket (Draw Calls). När GPU Driven Rendering aktiveras överförs denna belastning helt till grafikchippets Compute-shaders. GPU:n bearbetar dock endast data effektivt när geometri och material är strängt strukturerade, monolitiska och förutsägbara för de parallella strömmarna i det mobila chippets exekveringsenheter (Apple Silicon, Snapdragon, Dimensity).

1. Strikt geometri: standardisering av vertexbuffertar och submeshar
Det primära kravet för GPU Resident Drawer i Unity 6 är att minimera antalet submeshar på 3D-modellnivå. Varje enskild undersektion av en mesh med ett unikt material genererar en oberoende instansdeskriptor i GPU:ns strukturerade buffert. Om en 3D-asset för en byggnad innehåller 8 submeshar med olika texturmappning förlorar GPU Driven-hybriden upp till 70 % av sin urvalseffektivitet (Occlusion Culling utförs för varje submesh separat, vilket belastar grafikprocessorns L2-cache).

• Geometrisk monolitilitet: En mesh — en submesh. Alla miljöelement, props och till och med komplexa arkitektoniska block måste slås samman vid export från DCC-programvaror (Blender, Maya) till en enda mesh med ett enda material.
• Optimering av vertex-layout (Vertex Stream Packing): Unity 6 kräver strikt linjering av vertexdata längs 16-byte-gränser. På mobila chip från 2026 med ARM TBDR-arkitektur måste oanvända kanaler tas bort (UV3, UV4, Vertex Colors, Tangents, om meshen använder en maskerad shader utan normal-maps). Användning av `FP16`-formatdata (half-precision) för UV-koordinater och komprimerade normaler via `Octahedral Vector Encoding` minskar vertexbuffertens storlek i VRAM med 40–50 %.
• 16-bitars indexbuffertar: Håll om möjligt antalet vertexar för en mobil prop under 65 535 (Index Format: `UInt16`). Övergången till `UInt32` fördubblar mängden minne som läses av GPU:ns vertex-pipeline under en enda fetch-cykel.

2. Shaderarkitektur för DOTS Instancing och GPU Resident Drawer
Anpassade shaders, skrivna för hand eller skapade via Shader Graph i URP Unity 6, måste hålla full kompatibilitet med `BatchRendererGroup`-arkitekturen (BRG). Det största misstaget vid övergången till GPU-orienterad rendering är att använda individuella materialinstanser (`MaterialPropertyBlock` eller dynamisk ändring av parametrar via CPU-skript i `Update`), vilket leder till att instansbatchar tvingas brytas (break).

För att bibehålla en enda Draw Call vid hundratals olika objekt i scenen bör följande shader-metod användas:

• Shader Graph: Obligatorisk aktivering av flaggan `DOTS Instancing` i Master Node-inställningarna. Shadern översätter automatiskt egenskaper (färger, skrovlighetskoefficienter, förskjutningar) till en enda global konstant buffert `StructuredBuffer` som är läsbar för GPU:n.
• Användning av Texture Arrays (Texture2DArray): I stället för att svälla antalet material med individuella albedo-maps kombinerar tekniska artister texturer i enhetliga matriser (Texture Arrays). Endast ett heltalsindex för texturen `TextureIndex` skickas till objektets instansdata via vertexattribut eller instansbuffert. Shadern läser rätt textur direkt via indexet utan att växla shader-tillstånd på Vulkan 1.3 / Metal 3-drivrutinsnivå.

3. GPU-drivna LOD-system och dynamisk dithering
Standardkomponenten `LODGroup`, som styrs via CPU:n, skapar betydande overhead vid hantering av tusentals instanser. I Unity 6 förlitar sig en optimerad art-pipeline på GPU-driven urval av detaljnivåer, där culling-compute-shadern själv beräknar avståndet från kameran till objektet och skriver det synliga LOD-indexet till den genererade kommandobufferten `DrawIndexedInstancedIndirect`.

För att undvika plötsliga "geometri-hopp" (popping) vid LOD-växling och undvika att skapa material med standardmässig Alpha Blend (som förstör prestandan på mobila GPU:er på grund av inaktiverad Early-Z), används en gradvis transparent utjämning — Dithered Cross-Fade:

• En fragment-brusmask (Screen-space Dither Pattern) läggs till i shadern, vilken styrs av en global koefficient `FadeValue` som skickas från GPU:ns culling-buffert.
• Vid växling från LOD0 till LOD1 renderas båda meshar kortvarigt samtidigt och uttonas i varandra via en pixelmask utan att skriva till Alpha-bufferten, vilket bevarar funktionen hos Early-Z / Tile-Based Deferred Rendering.
• LOD-budgetering för mobila enheter: För mobila projekt 2026 är den gyllene standarden geometri med följande progression: LOD0 (100 % detaljrikedom), LOD1 (40–50 % triangulering, borttagning av små element), LOD2 (15–20 % geometri, inga normal-maps, användning av aggressivt bakade maps).

Att implementera dessa strikta regler på modellerings- och texturerings-pipelinenivå gör det möjligt att krama ur maximalt ur GPU Resident Drawer i Unity 6: att reducera tusentals unika draw calls till ett fåtal buffrade kommandon, avlasta den mobila CPU:n från synlighetsberäkningar och helt eliminera bildruteryckningar orsakade av ändringar i grafik-tillstånd.

Med lanseringen av Unity 6 har arkitekturen Universal Render Pipeline (URP) slutgiltigt fullbordat övergången till Render Graph API-paradigmen. I moderna mobila projekt från 2026 anses användningen av föråldrade metoder för att arbeta med `ScriptableRenderPass` utan en uttrycklig beskrivning av render-grafen vara ett kritiskt tekniskt misstag. Mobila GPU:er (inklusive moderna chipp som Apple A18/M4, Qualcomm Snapdragon 8 Gen 4/5 och ARM Immortalis) fungerar baserat på en kakelbaserad arkitektur (TBDR — Tile-Based Deferred Rendering). För att nå målet på 60–120 FPS på mobila enheter är det avgörande att minimera dataöverföringen mellan det snabba SRAM-minnet på chippet (Tile SRAM) och det primära arbetsminnet (LPDDR5X/LPDDR6). Render Graph API i Unity 6 ger utvecklaren ett direkt verktyg för att exakt isolera anpassade pass och hantera grafikresursernas livslängd.

Det huvudsakliga problemet med den klassiska pipelinen var okontrollerade export- och importoperationer av texturer. Om ett anpassat pass (till exempel beräkning av spekulära högdagar för stylat vatten eller beräkning av en dimvolym) inte är isolerat i grafen, tvingas grafikdrivrutinen för Vulkan eller Metal att tömma kaklets innehåll till global VRAM (StoreAction) och sedan läsa in det igen (LoadAction). På mobila enheter leder dessa tur-och-retur-resor ("Tile till DRAM") omedelbart till bildfallsförluster (frame drops) på grund av att minnesbussens bandbredd blir överbelastad, vilket orsakar termisk strypning av processorn. Render Graph löser detta problem genom en deklarativ beskrivning av resursernas beroenden och bygger automatiskt upp en optimal kommandokedja för grafik-API:et.

Struktureringen av ett anpassat pass i Unity 6 bygger på uppdelningen mellan grafinspelningsfasen (Record Phase) och exekveringsfasen (Execute Phase). Istället för att allokera temporära texturer via föråldrade `CommandBuffer.GetTemporaryRT`-anrop måste utvecklaren använda deklarationer av temporära grafikresurser (Transient Resources) inom Render Graph Context:

• Deklaration av resurser och beroenden: I grafbyggfasen anropar du `builder.UseColorBuffer()` eller `builder.UseDepthBuffer()` och anger tydligt dataflödets riktning (`AccessFlags.Read`, `AccessFlags.Write` eller `AccessFlags.ReadWrite`). Detta gör att Unity 6-grafkompilatorn kan slå samman oberoende pass eller tillämpa Resource Aliasing-teknik, där samma minnesområde används av olika temporära texturer vid olika tidpunkter.
• Uttryckliga Load- och Store-åtgärder: För varje ansluten buffert måste du strikt ange laddnings- och sparflaggor. Om ett anpassat pass ritar om hela sin skärmbuffert ska `LoadOp.Clear` eller `LoadOp.Discard` (DontCare) anges så att GPU:n inte slösar cykler på att läsa in föregående bildruta från DRAM. När passet är klart, och om texturen endast behövs inom detta pass (till exempel en mellanliggande Bloom-suddighetsbuffert), ställs `StoreOp.Discard` in.
• Transient Attachments (Memory-Less): På iOS (Metal) och Android (Vulkan) gör Render Graph i Unity 6 det möjligt att markera mellanliggande render target-objekt som `Transient`. Sådana buffertar allokeras fysiskt endast i kaklets SRAM-minne och tar inte upp något fysiskt arbetsminne alls (VRAM-kostnad = 0 MB). Detta är idealiskt för Render Graph MSAA resolve-buffertar eller mellanliggande djupkartor.

Särskild uppmärksamhet i Unity 6 har ägnats åt stödet för Native Render Passes i Vulkan och Metal. Vid korrekt utformning av anpassade pass via API:et `RasterRenderPassData` kan Render Graph-kompilatorn fysiskt slå samman (Subpass Merging) flera efterföljande pass till ett enda sammanhängande RenderPass på lågnivå-API-nivå. Till exempel kan ett anpassat dekompositions-pass för subsurface scattering (SSS) och ett efterföljande efterbehandlings-pass exekveras inom ett och samma kakelbuffertpass utan en enda läsning eller skrivning till det externa minnet.

För garanterad isolering och optimering av anpassade pass rekommenderas följande arkitektoniska tillvägagångssätt:

• Undvik UnsafePass helt om möjligt: I Unity 6 har det mer precisa kontraktet `AddRasterRenderPass` introducerats. Användning av föråldrade `AddUnsafePass` bryter den automatiska grafanalysen och tvingar pipelinen att sätta upp konservativa (och långsamma) minnessynkroniseringsbarriärer.
• Graferprofilering via Frame Debugger och RenderDoc: Den uppdaterade Frame Debugger i Unity 6 innehåller nu visualisering av minnesbarriärer. Kontrollera att det inte finns några `Global Memory Barrier`-flaggor mellan dina anpassade pass och att det inte sker några oavsiktliga byten av pixelformat som leder till en återställning av kakelkontexten.
• Kontroll av buffertars bitdjup: På mobila pipeliner 2026 bör du undvika att använda 16-bitars float-buffertar där `R8G8B8A8_UNorm` eller komprimerade mellanliggande format är tillräckliga. Ju mindre storleken på varje pixel är, desto fler pixlar ryms i den mobila grafikprocessorns kakelcache på chippet.

En väl genomförd övergång till Render Graph API med avseende på passisolering gör det möjligt att spara upp till 30–40 % av minnesbandbredden på mobila enheter. Detta minskar enhetens strömförbrukning direkt, förhindrar överhettning och garanterar en stabil bildfrekvens i krävande mobila 3D-projekt.

Att helt migrera ett mobilprojekt till en ”ren” Data-Oriented Technology Stack (DOTS/ECS) är en uppgift som även år 2026 inte alltid är motiverad, på grund av komplexiteten i att integrera tredjeparts-SDK:er, UI-system (som UI Toolkit eller Canvas) och specifika plugins. I Unity 6-miljön har dock en hybridansats (Hybrid DOTS) blivit standarden för medelstora och storskaliga 3D-spel. Den gör det möjligt att kombinera traditionella GameObjects – för smidig layout, karaktärsanimering och gränssnittslogik – med den kompromisslösa prestandan hos rena komponentsystem (Entities) och Burst-kompilatorn för beräkning av matematiskt tunga system.

Det primära målet med en hybridarkitektur i moderna mobilprojekt är att utnyttja 100 % av beräkningskraften hos flerkärniga ARM-processorer (ARMv9.2-A-arkitektur och nyare), samtidigt som man undviker mobilspelsutvecklingens två största problem: throttling på grund av överhettad SoC och fördröjningar från skräpsamlaren (GC Spikes). För att uppnå detta i Unity 6 används en uppdaterad baking-pipeline (Baking API), ISystem-gränssnitt och datasynkroniseringsköer på låg nivå.

Arkitekturmönster för interaktion mellan ECS och GameObject

Utvecklingspraxis för 2026–2027 lyfter fram tre nyckelmönster för att koppla ihop komponentsystemet med MonoBehaviour-hierarkin:

• Mönstret ”Entity-Driven Presentation” (Entitetsdriven presentation): All logik – förflyttning, kollisionshantering, pathfinding, AI för fiender eller projektiler – flyttas helt till IComponentData-strukturer och körs i unmanaged-system (ISystem). GameObjects används uteslutande som visuella ”skal” (partiklar, högkvalitativa meshar, ljuskällor) som läser transformationer från ECS med hjälp av job-optimerade TransformAccessArray-matriser eller noden Entities.Graphics.
• Mönstret ”Baking & Hybrid Components”: Nivådesign sker på klassiskt vis i Unity-editorn. Under authoring-processen konverterar bakers (IBaker<T>) tunga data till ECS-komponenter. MonoBehaviours bevaras endast där det krävs en direkt koppling till Animator eller fysikkomponenter från PhysX/Unity Physics.
• Mönstret ”Native Events Bridge”: Kopplingen mellan hanterad C#-kod (UI, analytik, ljudhanterare) och icke-cachade ECS-data implementeras via NativeQueue<T>-köer och EntityCommandBuffer-händelser. Detta eliminerar minnesallokeringar i Managed Heap helt under strider eller intensivt gameplay.

Optimering för flerkärniga ARM-processorer och förebyggande av throttling

Moderna mobila kretsuppsättningar använder en heterogen arkitektur (till exempel en kombination av Cortex-X-, Cortex-A7xx- och Cortex-A5xx-beräkningskärnor). Standard C# Job System i Unity 6 fördelar automatiskt trådar, men utan rätt konfiguration av Burst-kompilatorn kan högbelastade ECS-system överbelasta prestandakärnorna (Super/Big Cores), vilket leder till snabb termisk strypning och sänkta klockfrekvenser.

För att förhindra detta används följande metoder vid skrivning av Burst-kod år 2026:

• Användning av NEON- och SVE2-vektorinstruktioner: Burst-kompilatorn i Unity 6 stöder automatisk vektorisering av kod för ARM SVE2-instruktioner. Vid massberäkningar (till exempel tusentals enheter eller projektiler i en Bullet Hell) gör datastrukturering i form av NativeArray med sekventiell minneslinjering det möjligt att bearbeta upp till 4 eller 8 flyttalsoperationer per klockcykel.
• Dynamisk trådbalansering (Worker Thread Scaling): Användning av JobsUtility.JobWorkerCount API tillsammans med mobila tjänster för termisk hantering (Adaptive Performance / Android Thermal API). När kritiska temperaturer närmar sig kan hybrida ECS-system skala antalet chunks som bearbetas per bildruta, eller tillfälligt sänka uppdateringsfrekvensen för sekundära system (till exempel genom att inaktivera delar av AI-pathfinding på långa avstånd).
• Minimering av Cache Misses: Datastrukturer (IComponentData) utformas strikt utifrån storleken på L1/L2-cachelinjerna i ARM-processorer (vanligtvis 64 byte). Genom att paketera data i smala, täta block (SoA – Structure of Arrays) kan processorn läsa data från minnet utan dröjsmål för väntan på RAM-bussen.

Hantering av arketypförändringar och EntityCommandBuffer (ECB)

Det vanligaste felet vid implementering av Hybrid DOTS i mobilspel är att orsaka så kallade Structural Changes (strukturförändringar). Att lägga till eller ta bort komponenter, eller att skapa och förstöra entiteter under ett Job, leder till tömning av arketyp-cachen, omedelbara trådlåsningar och bildrute-frysningar.

I den nuvarande Unity 6-pipelinen bygger arbetet med dynamiska förändringar på två regler:

1. Användning av optimerade system-uppspelningspunkter (Playback Points):
Alla strukturförändringar läggs i en parallell EntityCommandBuffer.ParallelWriter. Skrivning av kommandon sker inuti flertrådade Execute-funktioner, medan deras tillämpning (Playback) skjuts upp till särskilt avsatta faser i bildrutan – till exempel EndSimulationEntityCommandBufferSystem. Detta minskar antalet omorganiseringar av minnet till en enda fas per bildruta.

2. Användning av Enableable Components i stället för att skapa/ta bort:
I stället för att lägga till en Frozen- eller Poisoned-komponent på en entitet (vilket ändrar dess arketyp och flyttar den från en minnes-chunk till en annan), är standardpraxis år 2026 att använda gränssnittet IEnableableComponent. Att aktivera och inaktivera flaggan sker på O(1)-tid utan ändring av minnesstrukturen och utan att blockera parallella Burst-trådar.

Praktisk fallstudie: Storskaliga system i mobil 3D

Låt oss titta på ett typiskt scenario: simulering av 2 000 aktiva objekt (till exempel en svärm av fiender eller skott i ett mobilactionspel) där deras koordinater överförs till visuella GameObject-komponenter.

Med en klassisk ansats leder 2 000 MonoBehaviour Update() oundvikligen till att FPS faller under 30 även på flaggskeppstelefoner. I hybridmodellen för Unity 6 sker beräkningen av fysik, logik och målsökning i en enda ISystem, kompilerad med Burst:

1. Systemet itererar över chunks av RefRW<LocalTransform> och RefRO<TargetPosition> parallellt i flera trådar.
2. När beräkningarna är klara överförs en native-matris med de nya koordinaterna till TransformAccessArray.Schedule(), som uppdaterar fysiktransformationerna för GameObjects på motor-nivå i C++-kod och kringgår det hanterade C#-lagret.
3. Som ett resultat ökar prestandan 10–15 gånger: bildrutans bearbetningstid på CPU minskar från 18 ms till 1,2 ms, vilket lämnar största delen av bildrutans tidsbudget till rendering och komplexa shaders.

Därmed gör en välutformad Hybrid DOTS-arkitektur år 2026 det möjligt att skapa mobila 3D-spel med en skala och interaktionsdensitet som tidigare bara var möjlig på konsoler och PC, samtidigt som utvecklingsflexibiliteten och kontrollen över mobila enheters strömförbrukning bibehålls.

I moderna mobila 3D-projekt 2026 förblir fysikberäkningar en av de mest resurskrävande uppgifterna för mobila system-on-chip (SoC). Till skillnad från grafikpipelinen belastar fysikberäkningar främst CPU-kärnorna och minnesundersystemet. Vid övergången till Unity 6 lämnar den vanliga PhysX-modulen plats för hybrida och helt DOTS-orienterade lösningar. Paketet Unity Physics, som drivs av Burst Compiler, gör det möjligt att flytta fysiksimuleringsloopen till en ström av SIMD-beräkningar, men utan sträng kontroll över datastrukturen och korrekt isolering av kollisioner kommer även en deterministisk motor snabbt att förbruka bildrutebudgeten på mobila chip på Snapdragon- och Apple A-serienivå.

Den huvudsakliga metodologiska utmaningen vid konfiguration av Unity Physics på mobila enheter är att maximera användningen av vektorinstruktioner (NEON för ARM64) samtidigt som kollisionsprecisionen (Collision Accuracy) bibehålls. För att uppnå detta delas fysikpipelinen upp i tre kritiska faser: optimering av fasen för att hitta potentiella kontakter (Broadphase), SIMD-vektorisering av fasen för exakt beräkning (Narrowphase) och implementering av hierarkiska culling-zoner.

1. Vektorisering och SIMD via Burst Compiler
Standardkoden för kollisionshantering lider ofta av hanterat minne (managed memory) och GC-allokeringar. I Unity 6 börjar fysikoptimeringen med ett fullständigt övergivande av klassiska `OnCollisionEnter` till förmån för parallella jobb som `ICollisionEventsJob` och `ITriggerEventsJob`. Burst Compiler kompilerar fysiksolverns matematiska kärnor till maskinkod med stöd för 128-bitars ARM NEON-register. För att Burst ska kunna autovektorisera flaskhalsar så effektivt som möjligt:

• Använd förenklade primitiver: Ersätt `MeshCollider` med en kombination av kapslar, sfärer och boxar (`BoxCollider`, `SphereCollider`). I Unity Physics beräknas kollisioner mellan primitiver analytiskt via SIMD på en bråkdel av en nanosekund.
• Optimera datastrukturen: Skicka matriser med positioner och orienteringar som kontinuerliga buffertar (`NativeArray`) och undvik utspridda pekare. Detta minimerar Cache Misses i processorn.
• Justera Solver Iterations: För mobila enheter sänks värdet för `Physics Step Solver Iterations` till 2–4 iterationer. Precisionen kompenseras genom att använda kontaktförutsägelsealgoritmer.

2. Rumslig beskärning: Dynamiska culling-zoner
Det saknar mening att beräkna fysik för objekt som befinner sig utanför spelarens synfält eller utanför dess interaktionsradie. År 2026 har rumslig hashning (Spatial Hashing) och avståndsbaserad beskärning (Physics Distance Culling) blivit standard i mobilutveckling:

• Hierarki för culling-zoner: Scenen delas in i ett regelbundet rutnät eller ett Octree-träd. Objekt i inaktiva sektorer flyttas från kategorin dynamiska kroppar till statisk topologi eller exkluderas helt från simuleringen (komponenten `PhysicsBody` inaktiveras).
• Hybrid simuleringsfrekvens (Physics Tick LOD): För objekt i den första zonen (inom 15 meters radie från kameran) utförs simuleringen varje `FixedUpdate` (t.ex. 50 Hz). För avlägsna objekt sänks frekvensen till 10–25 Hz med hjälp av temporär interpolering av mellanliggande bildrutor på GPU:n.

3. Bibehållen kollisionsprecision utan Continuous Collision Detection (CCD)
Höghastighetsobjekt (projektiler, fordon) kräver traditionellt att Speculative CCD aktiveras, vilket vid ett ökat antal objekt orsakar CPU-prestandatapp. I Unity 6-pipelinen löser man detta problem genom matematisk prognostisering baserad på Raycast/Shapecast inom ramen för SIMD-paketet:

Istället för tunga beräkningar av kontinuerlig fysik körs för varje bildruta ett högparallellt Burst-jobb som utför `Physics.CastRay` eller `Physics.CastCapsule` längs objektets hastighetsvektor inför nästa tidssteg. Om ingen skärning upptäcks flyttas objektet med ett vanligt kinematiskt steg. Om en skärning upptäcks hanteras kollisionen i förebyggande syfte. Detta gör det möjligt att bibehålla 100 % träffprecision för höghastighetselement i spelet samtidigt som belastningen på fysikmotorn minskar med upp till 70 % jämfört med standard-CCD.

Under lång tid förknippade utvecklare mobil bakad belysning med komplicerad manuell placering av Light Probe Groups och enorma volymer lightmap-texturer som svällde byggfilen. I och med lanseringen av Unity 6-ekosystemet har systemet Adaptive Probe Volumes (APV) slutgiltigt etablerats som branschstandard för Universal Render Pipeline (URP) och helt ersatt den föråldrade manuella pipelinen. Under moderna mobila arkitekturers förutsättningar (från Snapdragon 8 Gen 3/Gen 4 och Apple A18/M4 till vanliga chip med Mali-G720- och Adreno 750-GPU:er) ger APV en perfekt balans mellan fullvärdig, korrekt global belysning (GI) och en stram prestandabudget.

Den största fördelen med APV på mobila enheter är den automatiska vokseliseringen av rummet och genereringen av prober med adaptiv densitet baserat på scenens geometri. Okontrollerad användning av APV kan dock omedelbart förbruka minnesbandbredden (Memory Bandwidth) hos en mobil GPU. För att uppnå äkta 60 eller 120 FPS på flaggskeppsmodeller och stabila 30 FPS på mellansegmentenheter krävs en finjustering av hybridpipelinen, som kombinerar APV för indirekt ljus och optimala dynamiska källor för direkt belysning.

Tekniska riktlinjer för konfiguration av APV i URP 6 för mobila enheter:

• Val av ordning för sfäriska harmoniska funktioner (Spherical Harmonics): För mobila projekt är det kritiskt att använda L1 Spherical Harmonics istället för L2. Övergången till L1 minskar mängden överförd data per probe från 27 till 9 floats, vilket sparar upp till 66 % VRAM och minskar belastningen avsevärt på mobila tile-baserade renderare (TBDR). Den visuella skillnaden i mjuka indirekta ljusreflektioner på en 6,7 tum stor mobilskärm är praktiskt taget osynlig.
• Begränsning av underindelningsnivåer (Max Subdivision Level): Använd inte maximal probedetaljrikedom över hela miljön. För öppna mobila ytor räcker det att spika parametern Max Subdivision till nivå 3 eller 4, med en grundläggande cellstorlek (Cell Size) på 16–32 meter. Maximal densitet bör endast genereras i områden där spelaren interagerar samt i trånga interiörer.
• Konfiguration av APV Probe Streaming: I Unity 6 finns strömmande inläsning av probedata från disk till minne implementerad. På mobila enheter bör storleken på poolen APV Memory Budget begränsas till intervallet 16–32 MB. Att ställa in strömningen baserat på en virtuell kamera förhindrar hakningar när spelaren rör sig snabbt i en sömlös värld.
• Förebyggande av ljusläckage (Light Leakage): För att åtgärda läckageartefakter på mobila GPU:er bör du inte använda tung strålspårad Virtual Offset i körtid (runtime). Använd bakning av giltighetsmasker (Validity Masks) och parametern Dilation under byggfasen – detta utesluter ogiltiga prober inuti meshes utan att kräva GPU-beräkningar i realtid.

Hybridbelysningsschemat år 2026 bygger på kombinationen APV + Forward+ Rendering. Istället för att försöka baka direkta solstrålar eller glödlampor till statiska texturer överlåts direkt belysning helt till dynamiskt Directional Light med kaskadskuggor (Cascaded Shadow Maps, begränsat till 2 kaskader för mobila enheter), medan allt reflekterat diffus-ljus och indirekt belysning hämtas från APV. För dynamiska objekt (hjältar, fiender, interaktiv miljö) sker samplingsprocessen från APV extremt snabbt via Compute Shaders i ett enda pass.

Implementeringen av dygnscykel utan hårdvarubelastande dynamisk Realtime GI förtjänar särskild uppmärksamhet. Med hjälp av den APV-inbyggda mekanismen Lighting Scenario Blending kan du baka två eller fler belysningstillstånd (till exempel "Dag" och "Natt") i en enda APV-struktur. I körtid utför Unity 6 en lätt lerp mellan probekoefficienterna på GPU:n, vilket bara kräver en liten mängd extra minne för det andra scenariots data och försumbara beräkningar i fragmentshadern, samtidigt som mål-FPS bibehålls helt.

Slutligen integreras APV sömlöst med GPU Resident Drawer (GRD). Vid instansiering av tusentals statiska props i scenen (vegetation, stenar, byggnadselement) begär GPU:n själv belysningsdata från en enda APV-buffert baserat på instansens världskoordinater. Detta avlastar CPU:n helt från att överföra `MaterialPropertyBlock` för varje instans, vilket reducerar bildrute-renderingen till ett minimalt antal Indirect Draw Calls.

År 2026 har mobila GPU-arkitekturer (som Qualcomm Adreno 7xx/8xx-serien och ARM Mali/Immortalis) en imponerande beräkningskraft, men den primära flaskhalsen vid rendering av detaljrika 3D-scener i Unity 6 förblir en effektiv användning av registerfilen (Register File). Grafikpipelinen URP (Universal Render Pipeline) i aktuella Unity 6-versioner erbjuder den flexibla visuella editorn Shader Graph, men okontrollerad generering av HLSL-kod leder ofta till fenomenet Register Pressure — en kritisk överbelastning av allmänna register (GPR). På mobila GPU:er med TBDR-arkitektur (Tile-Based Deferred Rendering) får detta omedelbart en negativ inverkan på parallellismen (occupancy) och orsakar dumpning av temporära data till det externa minnet (register spilling), vilket förstör prestandan.

Den fysiska registerfilen i en mobil strömmande multiprocessor är strängt begränsad och delas mellan alla aktiva trådar (threads/lanes). Ju fler temporära variabler, komplexa matematiknoder och högprecisionsvektorer din shader genererar, desto färre trådar kan GPU:n exekvera samtidigt inom ramen för en warp (Adreno) eller wavefront (Mali). Om shadern kräver för många register minskar GPU:n antalet pixlar som behandlas samtidigt, vilket leder till att de aritmetisk-logiska enheterna (ALU) blir stående i väntan på texturhämtningar från systemminnet.

Optimering av dataprecision och registerprofil

För att förhindra Register Pressure vid arbete med Shader Graph i Unity 6 är det nödvändigt att upprätthålla en sträng disciplin gällande precisionsfördelning och grafstruktur:

• Total precisionskontroll (Precision Control): Konfigurera precisionen både på hela grafens nivå i Graph Settings och för enskilda noder. Alla beräkningar av färg, belysningsvektorer, alfamasker och enkla UV-förskjutningar bör tvingas till Half-läge (FP16). Användningen av Float (FP32) bör vara strängt begränsad till världspositioner (World Position), djupoperationer (Depth) och skalbara UV-koordinater för att eliminera dithering-effekter. På Mali- och Adreno-arkitekturer gör användningen av FP16 det möjligt att packa två variabler i ett enda 32-bitars register (SIMD-exekvering), vilket halverar belastningen på registerfilen och ökar den maximala ALU-genomströmningen.
• Packning av interpolatorer (Varying Packing): Överföring av data från vertex-shadern till fragment-shadern förbrukar värdefulla interpolatorregister. Kombinera isolerade skalära värden och 2D-vektorer till enhetliga half4-strukturer. Exempelvis bör koordinaterna UV0.xy och UV1.xy överföras som en enda vektor half4(uv0.x, uv0.y, uv1.x, uv1.y) och packas upp direkt i fragmentstacken.
• Eliminering av överflödiga noder och duplicering: Håll noggrann koll på kopplingarna mellan undergrafer (Sub-Graphs) i Shader Graph 2026. Om samma komplexa matematiska operation (till exempel vektornormalisering eller beräkning av Fresnel-belysning) används i flera grenar av grafen, bryt ut den till en enskild nod och distribuera resultatet till ingångarna. Unitys automatiska HLSL-optimerare lyckas inte alltid slå ihop komplexa grafkedjor, vilket skapar onödiga temporära variabler.

Dynamisk förgrening och SIMD-prestandabarriärer

Det andra fundamentala problemet med mobila shaders förblir dynamisk förgrening — användningen av if/else-villkor som beror på per-pixel-data, texturkartor eller beräkningsresultat i fragment-shadern. Grafikprocessorer bearbetar pixlar i rutnät (quads 2x2). Om minst en pixel i en warp tar true-grenen medan de övriga 31 tar false-grenen tvingas den mobila GPU:n att sekventiellt exekvera båda kodgrenarna för hela gruppen och helt enkelt maskera inaktiva resultat (warp divergence).

Använd följande alternativa lösningar för att förhindra tråddivergens på mobila GPU:er:

• Ersättning av förgreningar med grenfri aritmetik: Använd inbyggda funktioner som step(), saturate(), lerp(), sign() och mad() (Multiply-Add) i stället för Branch- eller Comparison-noder. Moderna mobila ALU:er utför operationer som lerp(a, b, step(threshold, x)) på en enda klockcykel på hårdvarunivå utan pipeline-stopp.
• Användning av multipackade masker: Växling av visuella effekter (som att ändra yttyper eller defekter) utförs effektivare via linjär interpolering (Lerp) över en maskeringstexturs RGBA-kanaler än via logiska villkorskontroller.
• Isolering av Uniform-förgreningar: Om en förgrening verkligen är nödvändig (till exempel växling av skuggningsalgoritm), se till att villkoret baseras på en materialkonstant (Material Property) eller en global bildrutebuffert. I Unity 6 bör sådana förgreningar struktureras via mekanismer för Shader Keywords. Detta gör det möjligt för shader-generatorn att skapa separata varianter (variants), vilket eliminerar dynamiska kontroller under exekveringen av fragment-koden. Kontrollera noggrant antalet varianter med de nya Stripping-reglerna i URP för att undvika att build-storleken sväller (build size).

Praktisk pipeline för shader-analys 2026

Utvecklingen av optimerade shaders för mobila Unity 6 år 2026 bygger på statisk profilering av den genererade koden. Den slutgiltiga bedömningen av shader-effektiviteten bör inte göras i editorns gränssnitt, utan med hjälp av externa analysverktyg för ISA (Instruction Set Architecture). Använd Mali Offline Compiler (från Arm Mobile Studio) eller Adreno GPU Inspector (AGNI). Exportera den genererade HLSL-koden från Shader Graph och kontrollera två kritiska mätvärden: antalet använda GPR (General Purpose Registers, med ett mållimit på högst 16–24 register per tråd för att bibehålla 100 % Occupancy) och förhållandet mellan matematik- och texturinstruktioner (ALU/TEX-ratio). Att minimera användningen av FP32 och eliminera divergerande grenar garanterar en stabil bildfrekvens på 60–120 FPS även på mobila enheter i mellansegmentet.

Inom mobil spelutveckling 2026 har mängden tillgängligt primärminne (RAM) i enheter formellt ökat, men den faktiska VRAM-budgeten för en spelapplikation är fortfarande skarpt begränsad. På moderna smarttelefoner med flaggskepps-chipset begränsar aggressiva OS-algoritmer, termisk strypning (thermal throttling) och bakgrundsprocesser den säkra minnesgränsen för ett 3D-spel till runt 2,5–4 GB. Med tanke på att texturer i det moderna URP-pipelinet i Unity 6 upptar upp till 65–70 % av det totala grafikminnet, blir en genomtänkt strategi för komprimering, leverans och bakgrundsstreaming av texturtillgångar (texture assets) den avgörande faktorn för en stabil bildfrekvens (FPS) och för att undvika OOM-krascher (Out-Of-Memory).

Grundstandarden för komprimering på moderna mobila GPU:er (Apple Silicon A17/A18/M-serien, Qualcomm Adreno 7xx/8xx och ARM Immortalis) är fortfarande formatfamiljen ASTC (Adaptive Scalable Texture Compression). Tillvägagångssätten för dess användning i Unity 6 har dock förändrats avsevärt i och med det breda införandet av ASTC HDR. Tidigare tvingades utvecklare använda okomprimerade RGBA16Float-format eller tunga kompromissalgoritmer för emissiva kartor (Emissive), bakad belysning (Lightmaps) och HDR-texturer med högt dynamiskt omfång, vilket ledde till en enorm minnesförbrukning. År 2026 gör det fullständiga hårdvarustödet för ASTC HDR-profilen i mobila chip det möjligt att komprimera HDR-data med minimal kvalitetsförlust vid samma blockmatris.

Matrisen för komprimeringsprofiler för ett mobilt PBR-material år 2026 ser ut som följer:

• Albedo / Base Color: ASTC 6x6 (i budgetprofiler – 8x8). Detta ger en optimal balans mellan detaljrikedom och storlek.
• Normal Maps: ASTC 4x4 eller ASTC 5x5 med tvingad tilldelning av två kanaler (RG) för att förhindra visuella artefakter på normaler vid dynamisk belysning.
• Mask Maps (Metallic, Roughness, Ambient Occlusion, Smoothness): ASTC 5x5 eller 6x6. Att packa tre till fyra kartor i ett enda RGBA-texturset eliminerar överflödiga Draw Calls och sparar VRAM-överföringar.
• Emissive & Baked Lightmaps: ASTC 4x4 HDR eller 6x6 HDR. Ger mjuka ljusgradienter och korrekt Bloom-funktion utan banding eller överdriven minnesförbrukning.

För leverans av texturer över nätverk (LiveOps, uppdateringspaket) och för att minska byggstorleken i appbutiker blir den hybrida kombinationen av KTX2 och Basis Universal-superkomprimering allt viktigare. Formatet KTX 2.0 gör det möjligt att lagra texturer i ett mellanliggande, superkomprimerat tillstånd. När en asset laddas i runtime transkodar Unity 6 snabbt Basis Universal direkt till GPU:ns målformat (i vårt fall ASTC) "on the fly" via parallella Worker Threads. Detta minskar storleken på nedladdade Addressables-paket med 40–60 % jämfört med standardpaketerade texturer, utan att belasta VRAM med ursprungliga okomprimerade matriser.

Optimering på disken löser inte problemet om alla scenens texturer laddas in i minnet samtidigt. I Unity 6 fungerar integrationen av systemet Texture Streaming (Mipmap Streaming) med ramverket Addressables på motorns kärnnivå och är tätt kopplad till synlighetspipelinet GPU Resident Drawer. Istället för att ladda en högupplöst textur helt och hållet allokerar motorn endast minne för grundläggande Mip-nivåer. Högupplösta Mip-nivåer laddas in asynkront endast när objektet hamnar i kamerans synfält (Frustum Culling) och upptar en betydande yta på skärmen.

Den praktiska arkitekturen för hantering av texturminne omfattar tre regler:

• Ställa in strikta VRAM-budgetgränser: I inställningarna för `QualitySettings.streamingRayscreenBudget` anges minnesgränsen för texturer (till exempel 1000 MB för Mid-tier-enheter). Om tröskelvärdet överskrids tar motorn automatiskt bort de högsta Mip-nivåerna för avlägsna objekt.
• Uppdelning av paket efter synlighetsprioritet: Via Addressables flyttas högupplösta texturer (4K/2K) till en separat grupp med möjlighet till bakgrundsladdning vid behov (On-Demand), medan 512x512-mipmap-kartor ligger kvar i platsens baspaket.
• Aggressiv avladdning via Reference Counting: Användning av `Addressables.Release()` direkt efter att en kartsektor förstörts eller dölts. I kombination med anrop av `Resources.UnloadUnusedAssets()` under pauser mellan spelsessioner förhindrar detta fragmentering av VRAM-minnet och eliminerar mikrofrysningar.

I moderna Unity 6-pipelines handlar prestandadiagnostik för mobila 3D-projekt inte längre om att bara räkna Draw Calls och antalet polygoner i en bildruta. Med det breda införandet av GPU Resident Drawer, hybrid DOTS-exekvering och asynkrona beräkningar på GPU-sidan fungerar inte längre det klassiska tillvägagångssättet för att hitta flaskhalsar: antalet ritanrop i inspektören kan närma sig ett, men bildfrekvensen kan ändå sjunka till 25 FPS på målets SoC. Fullständig optimering år 2026 kräver triangulering av problemet genom en verktygssats i tre steg: Unity Profiler på hög nivå, den strukturella Frame Debugger och Snapdragon Profiler på hårdvarunivå (eller motsvarande för Mali/PowerVR-kretsar).

Var och ett av dessa verktyg ansvarar för sitt eget abstraktionslager. Att försöka diagnostisera överhettning av GPU-hårdvara via Unity Profiler leder till felaktiga slutsatser, på samma sätt som att försöka hitta minnesläckor i C#-skript med hjälp av kretsuppsättningens systemräknare. Nedan visas en beprövad algoritm för att lokalisera CPU/GPU-flaskhalsar, aktuell för dagens Unity 6.x-ekosystem.

Steg 1: Systemanalys på hög nivå i Unity Profiler
Den primära uppgiften i detta steg är att fastställa applikationens belastningsprofil (CPU-bound eller GPU-bound) och säkerställa att det inte finns några fördröjningar i renderingsstråden (RenderThread). I Unity 6 har profileringsmodulen fått en djup integration med det nya Job System samt ett utökat minnesprofilerings-API (Memory Profiler 2.x API):

• Analys av Main Thread vs Render Thread: Om markören Gfx.WaitForPresentOnExecute tar mer än 40 % av bildrutetiden är spelet GPU-begränsat. Om WaitForTargetFPS eller JobSystem.Execute dominerar ligger problemet på CPU-sidan.
• Kontroll av hanterat minne (C#-allokeringar): År 2026 krävs noll dynamiska minnesallokeringar i Update()-sektionen. Med hjälp av modulen GC Alloc identifieras dold packning (boxing), LINQ-anrop eller allokeringar av lambda-uttryck i DOTS-system.
• Inspektion av Job Worker-trådar: Vid aktiv användning av Hybrid DOTS är det kritiskt att övervaka arbetstrådarna. Långa synkroniseringspauser (stalls) vid JobHandle.Complete() tyder på icke-optimal parallellisering eller felaktig planering av beroenden.

Steg 2: Strukturell granskning av geometri och batching via Frame Debugger
När belastningen på grafiksubsystemet har fastställts behöver bildrutans struktur analyseras i detalj. Frame Debugger i Unity 6 är anpassad för att arbeta med nya pipeline-funktioner i URP, inklusive automatisk sammanslagning av meshar via GPU Resident Drawer.

En optimeringsingenjör måste övervaka GPU Culling & Occlusion Pass. I Frame Debugger är det viktigt att säkerställa att DrawMeshInstancedIndirect-anrop korrekt kombinerar objekt i gemensamma buffertar. Om instansieringskedjan bryts visar verktyget den specifika orsaken (Break Reason): skillnader i unika materialparametrar, dynamiska ändringar av Lightmap Index eller att gränserna för konstanta buffertar (CBUFFER) överskrids. Särskild uppmärksamhet bör ägnas åt Shadow Caster-fasen. Okontrollerad skugggeometri för högupplösta mobilskärmar (WQHDP+) fördubblar ofta vertexbelastningen utan någon synlig kvalitetsvinst.

Steg 3: Hårdvaruprofilering på låg nivå i Snapdragon Profiler
Unity-verktygen ger en god inblick i motorns arkitektur, men döljer de fysiska processerna inuti den mobila grafikprocessorn (t.ex. Qualcomm Adreno 700/800-serien). I detta steg ansluts mobilenheten via ADB i Low-Level Trace-läge till Snapdragon Profiler (Layout: Real-Time System Trace / Graph Debugger).

• Analys av minnesbandbredd (Memory Bandwidth): Den mobila prestandans största fiende är överdriven överföring av texturer och buffertar över DRAM-bussen. Räknarna Read/Write Bytes Per Second får inte överskrida den tillåtna termiska budgeten. Användningen av UBWC-komprimering (Universal Bandwidth Compression) och ASTC-texturer kontrolleras just här.
• Belastning ALU vs Texture Units (Fragment Bound): Mätvärdet % Shaders Busy tillsammans med % ALU Capacity Utilized visar om fragment-shadern begränsas av matematiska beräkningar eller av texturhämtningar (Sampler Fetch Stalls).
• Överbelastning av Tile Memory (GMEM Stalls): Eftersom mobila GPU:er använder en tile-baserad arkitektur (TBDR) leder tömning av tile-innehållet till huvudminnet (Flush GMEM to System Memory) till att bildfrekvensen sjunker. Profileraren markerar direkt onödiga Discard/Store-operationer vid felaktigt konfigurerad Clear Flag i URP Render Pass.
• Dynamik för Thermal Throttling: Genom att spela in en profil under 15 minuter kan man se kurvan för hur klockfrekvenserna (GPU Clocks) sjunker på grund av överhettning, vilket hjälper till att hitta balansen mellan topp-FPS och stabil energiförbrukning på målenheten.

Steg-för-steg-algoritm för att åtgärda flaskhalsar (Diagnostic Pipeline 2026):

1. Mät värden i Unity Profiler på målenheten (inte i editorn!). Identifiera det styrande systemet: CPU (Main/Jobs) eller GPU.
2. Om flaskhalsen ligger på CPU: profilera C#-anrop, leta efter överflödig synkronisering i Job System, optimera koden i komponentsystem (ECS/DOTS) och minska overhead för TransformChangeDispatch.
3. Om flaskhalsen ligger på GPU: öppna Frame Debugger, kontrollera effektiviteten hos GPU Resident Drawer, åtgärda orsakerna till att SRP Batcher bryts och minska Overdraw (överlappande pixlar) i transparenta heterogena shaders.
4. Kör Snapdragon Profiler i hårdvaruräknarläge. Hitta orsaken till GPU-fördröjningarna: hög belastning på texturhämtning, för komplexa beräkningar i Compute Shaders eller GMEM-tömningar.
5. Gör riktade ändringar i LOD Group, material eller URP-grafikinställningar och upprepa profileringscykeln för att verifiera hypotesen.

Genom att införa denna regelbundna pipeline i CI/CD för automatiserad testning kan prestandaregressioner upptäckas innan builden når QA-avdelningen, vilket säkerställer stabila 60/120 FPS även i de mest krävande spelscenarierna.

Inom mobil spelutveckling år 2026 avgörs prestanda inte bara av den högsta bilduppdateringsfrekvensen under de första sekunderna av ett test, utan av hur stabil bildfrekvensen är under en kontinuerlig session på 20–30 minuter. Den höga transistortätheten i moderna mobila kretsuppsättningar leder till snabb upphettning vid toppbelastning. Om spelet aktivt allokerar minne i den hanterade heapen (Managed Heap) och överbelastar chippet med ooptimerade beräkningar, tvingar operativsystemet ner klockfrekvenserna för CPU och GPU (Thermal Throttling). Frekvensfallet kan vara mellan 30 % och 50 %, vilket förvandlar mjuka 60 FPS till ett ryckigt rendreringsresultat. Att motverka throttling i Unity 6 kräver ett helhetsgrepp: en fullständig eliminering av skräpsamling (GC) i runtime-loopen och införande av dynamisk strömhantering.

Zero-Allocation (GC-Free)-arkitektur i hanterad och icke-invasiv kod

Trots utvecklingen av Incremental Garbage Collector i Unity 6 skapar alla anrop till skräpsamlaren mikrofrysningar på mobila enheter på grund av trådsynkronisering. Huvudregeln vid utveckling av krävande 3D-projekt är noll minnesallokering i den hanterade heapen under gameplay (Zero-Allocation on Frame).

För att uppnå ett GC-fritt tillstånd år 2026 används följande praktiska mönster:

• Användning av Span<T> och ReadOnlySpan<T>: C#-runtime-miljön som är inbyggd i Unity 6 gör det möjligt att beskära delar av arrayer och strängar utan att skapa mellanliggande objekt på heapen. Detta ersätter helt föråldrade allokeringar med `substring` eller temporära arrayer vid bearbetning av binärdata och strängar.
• Unity.Collections-containrar i stället för System.Collections.Generic: Användning av NativeArray, NativeParallelHashMap och UnsafeList tar bort belastningen från C#-skräpsamlaren. Minnet allokeras i ohanterade (unmanaged) områden och kontrolleras manuellt via allokeringstyper (Allocator.Temp, Allocator.TempJob, Allocator.Persistent).
• Eliminering av implicit boxning (Boxing): Att skicka strukturer via gränssnitt eller göra anrop till enum.ToString() leder till att värdetyper packas i ett hanterat objekt. Användning av generic-begränsningar som where T : struct, IComponentData gör det möjligt för Burst-kompilatorn att generera högoptimerad maskinkod utan boxning.
• FixedString-strängbuffertar: Att ersätta vanliga C#-string med fixerade typer från `Unity.Collections` (till exempel FixedString32Bytes, FixedString64Bytes) garanterar att arbete med textetiketter, entitetsnamn och UI-element sker helt på stacken eller i native-minne.

Effekten av DOTS cache-lokalitet på minskad värmeutveckling

En mindre känd men kritisk faktor för termisk throttling är minnesbussens energiförbrukning (RAM Bus Energy). Frekventa cache-missar tvingar CPU:n att ständigt anropa LPDDR-minnet. Varje transaktion över bussen alstrar värme. Data som är organiserad enligt Data-Oriented Design (DOD) i DOTS ligger i minnet i sekventiella block (Chunks). Vid bearbetning läser systemstyrenheten in data i L1/L2/L3-cachen med maximal effektivitet. En lägre frekvens av anrop till det externa RAM-chippet minskar direkt upphettningen av mobila SoC:er och skjuter fram tröskeln för throttling.

Adaptiv temperaturkontroll via Adaptive Performance SDK

Även med en perfekt GC-fri kod kan spelet värma upp enheten på grund av tung grafik. I Unity 6 bygger optimeringen av strömförbrukningen på integrationen av Adaptive Performance SDK, som kommunicerar med operativsystemens lågnivå-API:er (Android Adaptive Performance Framework / AAPF och Apple Thermal State API).

I stället för att köras på fixerade maxinställningar tar spelmotorn emot mätvärden från OS om enhetens aktuella tillstånd (`ThermalStatus`) och temperaturmarginal (`Thermal Trend`). Utifrån dessa data implementeras en gradvis nedgradering av belastningen innan systemet tillämpar hård hårdvaruthrottling:

• Hantering av targetFrameRate och pacing: Om systemflaggan signalerar en övergång till statusen `Throttling.Warning` begränsar spelet dynamiskt bildfrekvensen (till exempel från 120/60 FPS till stabila 45 eller 30 FPS). Det gör att chippet kan svalna utan visuella bildhack.
• Dynamisk upplösningsskalning (Dynamic Resolution & Upscaling): I kombination med URP minskar rendreringsskalningen den interna bildupplösningen med 10–25 % följt av uppskalning via Spatial Upscaling (FSR/STP), vilket avlastar den mobila GPU:n.
• Stegvis inaktivering av grafikeffekter: Automatisk minskning av skuggritavstånd, avstängning av sekundära partiklar i Visual Effect Graph och sänkt kvalitet på Bloom/SSAO beroende på chassits upphettning.

Arkitekturen för minnes- och värmehantering år 2026 handlar inte bara om att anropa `System.GC.Collect()` på laddningsskärmar, utan om en helt styrd pipeline. Att flytta data till native-minne, minimera cache-missar via DOTS och använda återkoppling från hårdvaran via Adaptive Performance gör det möjligt att bibehålla en stabil bildfrekvens i mobila 3D-spel även under långa spelsessioner.

Hög prestanda i ett 3D-spel i Unity 6, uppnådd tack vare GPU Resident Drawer eller DOTS, garanterar inte kommersiell framgång om projektet inte uppfyller de aktuella stränga reglerna från de mobila plattformarnas operatörer. År 2026 ställer både Google Play och Apple App Store kompromisslösa krav på teknisk optimering, binärfilsarkitektur och enhetsövervakning i realtid. Att inte följa dessa regelverk leder antingen till att bygget automatiskt avvisas under den automatiserade granskningen, eller till en artificiell sänkning av featurings och organisk synlighet i butikernas algoritmer på grund av mätvärden från Android Vitals och Apple Energy Impact.

För att publicera appar i Google Play 2026 är den centrala standarden en obligatorisk övergång till Target API Level 35 (Android 15) med förberedelse för att rikta in sig på Target SDK 36. I Unity 6 kräver inställningarna i Player Settings att ingenjörerna överger alla kvarvarande 32-bitarsbibliotek. Stödet för `armeabi-v7a` har slutgiltigt förklarats föråldrat för modern mobil 3D-grafik. Byggena kompileras strikt för 64-bitarsarkitektur (`arm64-v8a`) med IL2CPP-backend och full optimering för instruktionsuppsättningen ARMv8.4-A och högre. Detta gör att mobila processorer mer effektivt kan fördela resurser mellan prestandakärnor (P-cores) och energieffektiva kärnor (E-cores), vilket sparar upp till 12 % bildrutetid på systemanropsnivå.

Det primära verktyget för att integrera adaptiv profilering i Android-ekosystemet har blivit modulen Android Performance Tuner (APT), som ingår i det aktuella paketet Google AGDK (Android Game Development Kit) 2026 och är helt integrerad med Unity Adaptive Performance 5.0+. Integrationen av APT gör det möjligt för utvecklare att dela upp målgruppen inte efter abstrakta telefonmodeller, utan efter faktiska grafikprofiler (Quality Tiers). Frametime-signaturer skickas till Google Play Console, där de utgör underlag för detaljerad analys:

• Frame Time Disruption Rate: Andelen bildrutor som överskrider målbudgeten (33,3 ms för 30 FPS eller 16,6 ms för 60 FPS).
• GPU/CPU Boundness ratios: Förhållandet mellan flaskhalsar i prestandan beroende på aktiva URP-tekniker (till exempel belastning från ett stort antal Draw Calls jämfört med tunga shaders).
• Thermal Throttling Events: Registrering av tillfällen då operativsystemet sänker chipfrekvenserna för att förhindra överhettning.

Kombinationen av paketet Adaptive Performance (Unity 6) och drivrutiner för Android och iOS öppnar möjligheter för hybridoptimering "i farten". När systemet tar emot en signal om att enheten närmar sig en temperaturtröskel (`ThermalStatus.Serious`) kan spelets runtime-skript dynamiskt minska belastningen utan någon synbar försämring av bildkvaliteten. I Unity 6-pipelinen implementeras detta genom att prenumerera på händelser i den adaptiva kontexten:

// Exempel på dynamisk anpassning till plattformskrav i Unity 6
var thermalStatus = AdaptivePerformanceRenderScaler.ThermalStatus;
if (thermalStatus == ThermalStatus.Throttling) 
{
    // Dynamisk sänkning av URP Render Scale-upplösning
    UniversalRenderPipeline.asset.renderScale = 0.85f;
    // Begränsning av maximal bildfrekvens
    Application.targetFrameRate = 30;
    // Inaktivering av tunga post-effekter (Motion Blur, Depth of Field)
    VolumeManager.instance.stack.GetComponent<DepthOfField>().active = false;
}

Från Apple App Stores sida är det under 2026 obligatoriskt att använda iOS 19 SDK och bygga projekt i Xcode 17+. Apple har helt uteslutit möjligheten att använda föråldrade grafik-API:er och gjort Metal 3 till det enda tillåtna lågnivågränssnittet. Unity 6 kompilerar som standard shaders till Metal Shading Language (MSL) 3.1, vilket kräver korrekt konfiguration av buffertlayouter i URP:s materialfiler. Dessutom lägger Apple särskilt stor vikt vid att kontrollera batteriurladdning: appar med högt Energy Impact-index tappar placeringar i sökresultaten. Användningen av Adaptive Performance Apple Provider gör det möjligt att jämna ut toppbelastningar på Apple A18/A19- och M-serie-chip tack vare exakt fördelning av uppgifter mellan kärnorna via system-API:et `ProcessInfo`.

För att hantera storleken på installationspaketet för storskaliga 3D-spel (som 2026 ligger på mellan 3 och 10 GB på grund av 4K-texturer och polygonrika meshes) är uppdelning av bygget ett obligatoriskt krav. I Google Play används tekniken Play Asset Delivery (PAD) med Android App Bundle-formatet (.aab), där geometri och texturer från DOTS-subscener packas i separerbara tillgångsuppsättningar (`install-time`, `fast-follow` och `on-demand`). I App Store fyller On-Demand Resources (ODR) en motsvarande roll genom att optimera den initiala nedladdningsstorleken från butiken och hämta tungt innehåll efter hand som spelaren tar sig vidare i spelet.

Inom mobil spelutveckling 2026–2027 är en enda fast grafikinställning inte längre hållbar: budgetchipset drabbas omedelbart av termisk throttling, medan ägare av flaggskepp baserade på Snapdragon 8 Gen 4/Gen 5 och Apple A18/A19-serien kräver äkta 120 FPS. För att säkerställa förutsägbar prestanda i Unity 6 krävs en flexibel skalbarhetsmatris (Scalability Matrix) som kombinerar funktionerna i grafik-API:er (Vulkan 1.3, Metal 3) och arkitekturen i Universal Render Pipeline (URP).

Nedan följer en praktisk konfigurationsmatris för grafikstacken i Unity 6 anpassad för tre huvudkategorier av mobila enheter:

• Low-End Tier (Budgetsegment / Äldre ARM Mali & Qualcomm Adreno):
  • Mål bildfrekvens: 30–60 FPS (med fokus på stabilitet i bildtid).
  • Upplösning och uppskalning: Dynamic Resolution 0,7x–0,8x med Spatial-Temporal Post-processing (STP) uppskalning i Performance-läge.
  • GPU Resident Drawer: Inaktiverad eller begränsad till batching av endast statisk miljö (automatisk fallback till SRP Batcher vid avsaknad av maskinvarustöd för Multi-Draw Indirect).
  • Belysning och skuggor: URP Forward+, 1 kaskad av riktat ljus (1024x1024), punktljusskuggor inaktiverade, Hard Shadows.
  • Texturer och minne: ASTC-komprimering 6x6 / 8x8, anisotropisk filtrering inaktiverad, gräns för Texture Streaming — upp till 512 MB.
• Mid-Range Tier (Mainstream / 60 FPS Standard):
  • Mål bildfrekvens: Nativ 60 FPS utan drop och överhettning.
  • Upplösning och uppskalning: Nativ 1,0x (eller adaptiv 0,85x–1,0x + STP Quality Mode).
  • GPU Resident Drawer: Helt aktiverad, compute-shader-baserad GPU Occlusion Culling används.
  • Belysning och skuggor: URP Forward+ / Tile-Based Deferred, 2 skuggkaskader (2048x2048), Medium Soft Shadows, upp till 4 lokala ljuskällor med skuggor.
  • Texturer och minne: ASTC-komprimering 4x4 / 6x6, anisotropisk filtrering 2x–4x, gräns för Texture Streaming — 1024 MB.
• Flagship / High-Refresh Tier (Flaggskepp / 120 FPS Gaming):
  • Mål bildfrekvens: 120 FPS / hög uppdateringsfrekvens nativt.
  • Upplösning och uppskalning: Nativ 1,0x / Supersampling (STP Ultra Quality eller FSR Mobile).
  • GPU Resident Drawer: Maximal användning tillsammans med Entities Graphics och transform instancing.
  • Belysning och skuggor: 4 skuggkaskader (4096x4096), High Quality Soft Shadows, Screen-Space Ambient Occlusion (SSAO) nativt via Render Graph, upp till 8 lokala ljuskällor med dynamiska skuggor.
  • Texturer och minne: ASTC-komprimering 4x4, anisotropisk filtrering 8x–16x, gräns för Texture Streaming — 2048+ MB.

Slutgiltig checklista för slutlig optimering av ett mobilt 3D-projekt i Unity 6:

• C# & DOTS: Har masslogik (AI, partikelfysik, banberäkningar) flyttats över till C# Job System och Entities? Har det verifierats att inga allokeringar sker i den inre loopen (`Update()`) — 0 Bytes/frame i Profiler? Är Safety Checks inaktiverade för Burst Compiler i Release-byggen?
• GPU & Render Graph: Har alla anpassade rendering passes flyttats till Render Graph API utan anrop till `CommandBuffer.Blit` och överflödiga mellanliggande RT:er som orsakar cache-flushing i TBR/TBDR-arkitekturer?
• Geometri & Geometry Streaming: Är GPU Resident Drawer aktiverat för alla kompatibla Mesh Renderers och Instanced Materials? Är avstånden för LOD Groups-växling korrekt inställda?
• Shaders: Har shader keyword stripping genomförts och har högprecisionsmatematik ändrats från `float` till `half` i Shader Graph för alla mobila målplattformar?
• Bild och skärm: Är hybridstyrning av uppdateringsfrekvensen inställd via `Application.targetFrameRate` och Frame Pacing API för Android 15/16 och iOS 18+, vilket förhindrar bilddesynkronisering vid 120 Hz?