DEV Community: GameOptim

When Should You Call Resources.UnloadUnusedAssets in Unity Open-World Games? Verify Asset Reclamation Before Optimizing Timing

GameOptim — Thu, 16 Jul 2026 11:04:25 +0000

Many Unity projects encounter the same dilemma.

Calling Resources.UnloadUnusedAssets too frequently introduces visible frame stalls, while delaying cleanup allows memory usage to continue growing. This becomes especially challenging in open-world games where seamless streaming removes the natural cleanup opportunities provided by scene transitions.

The first instinct is often to keep adjusting the execution timing. In practice, however, the more important question is whether the cleanup actually releases any assets.

A practical way to verify this is to examine the Asset Count before and after every Resources.UnloadUnusedAssets execution.

If the Asset Count drops noticeably, the cleanup is working as expected.
If the curve barely changes, the cleanup likely became an "empty run".

One of the most common reasons is that the corresponding AssetBundle is still loaded. Since the assets remain referenced by the loaded AssetBundle, Unity cannot reclaim them even though Resources.UnloadUnusedAssets executes successfully.

The engine still performs a resource scan, causing additional main-thread work without reducing memory usage.

Because of this, the troubleshooting order is often more effective when reversed:

Verify whether Resources.UnloadUnusedAssets actually reclaimed assets.
If it did not, investigate the AssetBundle unloading strategy.
Only after confirming successful reclamation should execution timing be further optimized.

Some projects intentionally keep AssetBundles resident to reduce loading stalls. In these cases, repeated Resources.UnloadUnusedAssets calls are unlikely to produce meaningful memory savings.

A more scalable approach is to implement a tiered AssetBundle cache, allowing bundle lifetime to be managed according to factors such as:

LRU (Least Recently Used)
Player location
Distance from the player
Memory pressure conditions

Lower-priority bundles can then be unloaded together when memory pressure occurs—for example, after Application.lowMemory is triggered—before executing resource cleanup.

Timing Strategies

As for execution timing itself, two strategies are commonly used:

1. Periodic Cleanup

Run Resources.UnloadUnusedAssets periodically, such as every 5–10 minutes.

2. Memory Pressure Cleanup

Execute cleanup only after receiving the Application.lowMemory callback.

Running Resources.UnloadUnusedAssets while opening full-screen interfaces like an inventory or map is also a valid option, since players generally tolerate a brief pause in these contexts.

However, this approach only provides value if the cleanup actually reclaims memory.

Key Takeaway

Before spending time optimizing when Resources.UnloadUnusedAssets runs, first verify that each execution is genuinely releasing resources.

Otherwise, every cleanup may simply become another expensive "empty run".

Unity Animation Optimization Guide: Reduce Memory Usage, Lower CPU Overhead, and Improve Runtime Performance

GameOptim — Tue, 14 Jul 2026 04:24:24 +0000

Unity Animation Optimization: Best Practices for Mobile Games

Animation systems consume both memory and CPU resources. Poor configuration choices—such as unnecessary precision, uncompressed clips, or duplicated animation assets—can quickly become a performance bottleneck in large Unity projects.

This guide summarizes practical techniques for optimizing animation resources while maintaining visual quality.

1. Select the Appropriate Animation Type

Choosing the correct animation system is the first optimization step.

Generic (Recommended)

Best suited for skeletal character animation.

Advantages:

Multithreaded evaluation
Better runtime scalability
Lower overhead than Legacy for complex character animation

Legacy

Although older, Legacy remains suitable for lightweight scenarios such as:

UI animation
Simple object movement
Effects with minimal animation complexity

Humanoid

Use Humanoid only when animation retargeting is required.

Although powerful, it introduces additional processing and should not replace Generic unnecessarily.

2. Configure Animation Compression Properly

Animation Compression has a significant impact on memory usage.

For Low-Priority Animations

Use Keyframe Reduction with a Reduction Tolerance between 0.01 and 0.1.

Suitable for:

Background characters
Ambient animation
Secondary effects

Avoid

Leaving compression Off, since animation clips remain fully uncompressed and consume significantly more memory.

3. Simplify Animation Data

Animation clips frequently include unnecessary data.

Remove:

Unused Scale curves
Empty animation channels
Redundant keyframes
Excessively long animation sequences

For mobile games, keeping individual clips below 200 KB is generally a practical recommendation.

Large animations can be divided into multiple clips and streamed when needed.

4. Optimize Sampling Rate

Animation quality depends more on consistency than extremely high frame rates.

Recommended sampling rates:

Scenario	Recommended FPS
Mobile gameplay	15–30 FPS
High-precision animation	60 FPS only when necessary

Looping animations such as idle and breathing can use fewer keyframes while maintaining smooth playback through interpolation.

Additional optimization can be achieved by preprocessing animation curves and merging nearly identical keyframes.

5. Maximize Animation Reuse

Duplicate animation clips increase memory usage unnecessarily.

Instead:

Create shared Idle, Walk, Run, and Attack clips
Reuse animations through Animator Controllers
Use Humanoid Retargeting for compatible character rigs

Shared animation libraries improve both memory efficiency and content scalability.

6. Balance Memory and CPU Performance

Compression introduces minor precision loss.

Always validate critical animations—including player characters and combat skills—on real devices.

For lower-end hardware, consider disabling expensive runtime features such as:

Root Motion
Inverse Kinematics (IK)
Secondary animation systems for non-essential characters

This significantly reduces CPU workload during animation evaluation.

7. Detect Oversized Animation Assets

Regular asset audits help identify inefficient animation resources.

Focus on clips with:

Excessive precision
Redundant keyframes
Unusually large file size
Animation duration inconsistent with gameplay requirements

As a practical guideline, non-critical animation clips larger than 500 KB should be reviewed for optimization or divided into smaller clips.

8. Implement Device-Tiered Animation Quality

Different hardware should use different animation complexity.

High-End Devices

Full skeleton
High sampling rate
Maximum animation precision

Mid- and Low-End Devices

Simplified skeleton
Lower frame rate
Reduced animation precision
Disabled expensive runtime features where appropriate

A scalable animation pipeline improves both runtime performance and battery efficiency without noticeably affecting gameplay.

Best Practices Checklist

✔ Use Generic animation for most character rigs
✔ Reserve Humanoid for animation retargeting
✔ Enable Optimal Animation Compression
✔ Reduce redundant keyframes and animation curves
✔ Keep mobile animation clips as small as practical
✔ Lower sampling rates where high precision is unnecessary
✔ Reuse shared animation assets across multiple characters
✔ Disable unnecessary runtime features such as Root Motion and IK
✔ Audit oversized animation clips regularly
✔ Apply device-tiered animation quality strategies

Conclusion

Effective animation optimization is not about reducing animation quality—it is about removing unnecessary data and computation.

By combining appropriate animation types, compression, curve simplification, asset reuse, and hardware-aware quality scaling, Unity developers can significantly reduce memory usage, lower CPU overhead, and deliver smoother gameplay across a wide range of mobile devices.

Do Texture Atlases Really Increase OOM Risk on iOS? Understanding the Memory vs. CPU Trade-off

GameOptim — Thu, 09 Jul 2026 02:26:48 +0000

If you're optimizing UI on iOS High-Performance Mode, don't assume that higher texture memory automatically means a higher OOM risk.

Texture atlases typically increase reported memory usage, but they also reduce CPU overhead by improving UI batching and minimizing texture switches.

For most UI-heavy Unity projects, the rendering performance benefits outweigh the additional memory cost.

Many Unity developers optimizing mobile games eventually face the same question when building UI for iOS High-Performance Mode:

At first glance, the answer seems obvious—less memory should mean better performance.

However, on iOS High-Performance Mode, that's often the wrong conclusion.

The real question isn't whether texture atlases use more memory, but whether that additional memory actually increases memory pressure enough to outweigh the CPU and rendering performance benefits.

This article explains why.

Does Higher Texture Memory Mean Higher OOM Risk?

The first step is understanding what your profiling tools are actually measuring.

Many developers compare memory before and after introducing a texture atlas. When the reported value increases, they assume the application is consuming significantly more memory and becoming more prone to Out-of-Memory (OOM) crashes.

Unfortunately, that's not always true.

On iOS, texture resources are managed differently from objects allocated in the Unity Heap. A considerable portion of texture memory is allocated and managed by the graphics subsystem (GPU memory). As a result, increases reported by Unity Profiler or mini-game profiling tools don't necessarily translate into equivalent process-level memory pressure.

In other words:

What Actually Determines OOM on iOS?

When iOS evaluates whether an application should be terminated because of memory pressure, it considers the application's overall memory footprint rather than a single metric.

That includes:

Unity Heap
Native Memory
GPU Texture Memory
WebContent Process RSS
iOS Jetsam memory management

This is why optimizing based solely on Unity Heap or profiler memory numbers can lead to misleading conclusions.

A larger texture atlas may increase reported memory while having only a limited impact on the conditions that trigger an iOS Jetsam termination.

	Individual Textures	Texture Atlases
Memory Usage	Lower (on-demand loading)	Higher (preloaded)
Texture Switches	More	Fewer
UI Batching	Less efficient	More efficient
CPU Rendering Cost	Higher	Lower
Rendering Stability	Lower	Higher

Individual Textures: Lower Memory, Higher CPU Cost

Using separate textures provides one clear advantage:

Assets are loaded only when needed.

Imagine your UI contains 100 icons, but only 20 are visible.

Only those visible textures need to be loaded into memory.

Benefits include:

Lower texture memory consumption
Reduced resource residency
Better memory efficiency for sparse UI usage

From a memory-only perspective, this strategy is attractive.

However, rendering performance tells a different story.

Each independent texture introduces additional texture bindings, reduces UI batching efficiency, and increases CPU work during rendering submission.

This results in:

More texture switches
Reduced batch efficiency
Higher CPU rendering overhead
Increased frame-time instability
Higher device temperature under sustained workloads

For mobile games and mini-games, these CPU costs often have a greater impact on the player experience than the extra memory required by a texture atlas.

Texture Atlases: Higher Memory, Better Rendering Performance

Texture atlases optimize the rendering pipeline by combining many small textures into one larger texture.

Although they require:

Higher initial texture decoding cost
Larger GPU upload cost
More concentrated texture memory

They significantly improve rendering efficiency through:

Fewer texture switches
Better UI batching
Lower CPU submission overhead
More consistent frame times
Improved rendering stability

For icon-heavy interfaces, these benefits are usually substantial.

Recommended Strategy for Unity Projects

For most Unity projects targeting iOS High-Performance Mode, the recommended approach is straightforward:

Continue using texture atlases for UI icons.
Disable Read/Write on atlas textures unless CPU-side texture access is required.
Evaluate optimization using overall memory pressure instead of Unity Heap alone.
Balance memory usage against CPU rendering efficiency rather than optimizing a single metric.

Remember that optimization is rarely about minimizing one number.

It's about improving the overall behavior of the application on real devices.

Key Takeaways

Texture atlases are often criticized because they increase reported memory usage.

However, on iOS, reported memory growth does not necessarily indicate higher memory pressure or increased OOM risk.

While individual textures reduce memory consumption through on-demand loading, they also introduce additional CPU overhead, more texture switches, and poorer UI batching.

For UI-heavy applications, these rendering costs frequently outweigh the memory savings.

In most production Unity projects, texture atlases remain the preferred solution because they deliver better CPU efficiency, more stable frame times, and improved rendering performance throughout gameplay.

The engineering question shouldn't be:

Instead, ask:

For most projects, the answer is still texture atlases.

Decision Summary

If your priority is minimizing texture memory, individual textures can reduce memory usage through on-demand loading.

If your priority is maintaining stable rendering performance on UI-heavy interfaces, texture atlases are generally the better choice because they reduce CPU overhead and improve batching efficiency.

For most production Unity projects running on iOS High-Performance Mode, the performance gains typically outweigh the additional memory cost.

FAQ

Do texture atlases always increase OOM risk on iOS?

No. Higher reported texture memory does not necessarily translate into higher process-level memory pressure because iOS evaluates multiple memory categories when determining whether to terminate an application.

Why do individual textures use less memory?

Individual textures are loaded on demand. If only a subset of icons is displayed, the remaining textures may never be loaded into memory.

Why do texture atlases reduce CPU overhead?

Texture atlases reduce texture switches and improve UI batching, allowing rendering submission to complete with less CPU work.

Which approach is recommended for UI-heavy projects?

For most production Unity projects running on iOS High-Performance Mode, texture atlases are generally recommended because their rendering performance benefits usually outweigh the additional memory cost.

Unity Mesh Optimization Guide: Reduce Vertex Count, Remove Redundant Vertex Data, and Lower GPU Memory Usage

GameOptim — Tue, 07 Jul 2026 03:44:50 +0000

Unity Mesh Optimization: A Practical Guide for Mobile Games

Mesh resources directly affect rendering performance, GPU memory usage, and CPU workload. While textures often receive the most attention during optimization, inefficient meshes can become equally expensive—especially in large open worlds or scenes with thousands of renderers.

This guide covers three areas that commonly waste rendering resources in Unity projects.

1. Optimize Vertex and Triangle Count

High-poly meshes increase:

Vertex processing cost
Primitive count
GPU memory usage
CPU culling overhead

Recommended optimization strategies include:

Reduce unnecessary geometric detail
Create lower-poly assets for lower device tiers
Design an appropriate LOD pipeline
Split extremely large static meshes into reusable modular assets
Use GPU Instancing, SRP Batcher, or Static Batching to reduce draw call overhead

2. Evaluate Mesh Quality Using Rendered Vertex Density

Polygon count alone is not a reliable optimization metric.

Instead, analyze rendered vertex density.

This metric measures the number of rendered vertices relative to visible screen pixels.

A practical threshold is:

Many triangles become sub-pixel during rendering and contribute almost nothing to the final image.

This recommendation aligns with mobile GPU optimization practices:

Vertex-to-triangle ratio ≈ 1.5 : 1
Triangle size ≥ 10–20 pixels

Rendered vertex density is particularly useful for:

Detecting unnecessarily detailed meshes
Verifying LOD transitions
Finding invisible rendering waste

3. Remove Unused Vertex Attributes

Many imported meshes contain vertex data that shaders never access.

Typical attributes include:

Position
Normal
UV
Tangent
Vertex Color

If the shader only requires Position, UV, and Normal, storing Tangent or Vertex Color increases memory without improving rendering.

Another common issue:

Combined Meshes inherit redundant attributes from every source mesh.

As projects scale, this unnecessary data can significantly increase memory usage.

Unity provides an effective solution:

Player Settings → Optimize Mesh Data

During the build process, Unity removes vertex attributes that are not referenced by shaders.

Important

If materials change at runtime, assign every potential material before building.

Otherwise, Unity may remove vertex attributes required later by dynamically assigned shaders.

4. Disable Read/Write When CPU Access Is Unnecessary

Enabling Read/Write stores an additional CPU copy of every mesh.

Unless runtime mesh modification is required, disable this option.

Projects with thousands of meshes often recover a substantial amount of memory simply by cleaning up unnecessary Read/Write flags.

Batch modification through the Unity Editor API or import settings can automate this process.

Best Practices Checklist

✔ Reduce unnecessary vertex and triangle counts
✔ Validate LOD models using rendered vertex density
✔ Remove unused vertex attributes with Optimize Mesh Data
✔ Disable Read/Write Enabled whenever CPU mesh access is unnecessary
✔ Use GPU Instancing or SRP Batcher for repeated meshes
✔ Split extremely large static meshes into modular assets when appropriate

Conclusion

Effective mesh optimization is about reducing work the GPU performs without affecting what players actually see.

Instead of optimizing by intuition, use measurable metrics such as rendered vertex density, vertex attribute usage, and runtime memory allocation to identify waste and build scalable rendering pipelines for mobile Unity games.

A Practical Guide to Mobile Texture Memory Optimization in Unity: Formats, Mipmaps, Streaming & Atlases

GameOptim — Fri, 03 Jul 2026 10:37:58 +0000

Texture Resources Optimization Overview

Texture memory is one of the largest contributors to GPU memory pressure in mobile games. Most inefficiencies come from format misconfiguration, resolution over-allocation, and incorrect Mipmap/streaming usage.

Texture Format

Incorrect texture formats remain a primary source of memory waste.

Common problematic formats:

RGBA32
ARGB32
RGB24
RGBA Half

Root Causes:

Batch processing misses due to naming inconsistencies
Runtime-created textures without explicit format assignment
Hardware fallback when target format is unsupported

Recommended Formats:

ASTC (mobile standard)
ETC2 (requires width/height multiple of 4)

Critical Notes:

ASTC + Mipmap requires power-of-two dimensions
Otherwise fallback to uncompressed storage may occur silently

Mipmap Behavior

Mipmap does NOT reduce memory. It increases memory usage by approximately 4/3.

Why:

Mipmap chain includes multiple levels:
1 + 1/4 + 1/16 + … ≈ 4/3 total memory

Benefits:

Reduces GPU bandwidth usage
Improves cache efficiency
Enables correct LOD sampling based on camera distance

Best Practices:

Enable for 3D assets (characters, terrain, particles, Spine)
Disable for UI textures with fixed screen-space usage

Resolution Waste Detection

Texture resolution directly correlates with memory usage.

However, high resolution does not always mean high utilization.

Key Metric: Mipmap 0 Sampling Rate

Definition:
Percentage of frames where GPU uses highest-resolution mip level.

Example:

10,000 samples
300 samples use Mipmap 0 → Mipmap 0 rate = 3%

Optimization Rule:

If Mipmap 0 usage < 5%:
→ Texture is likely over-provisioned

Extreme case:
Even Mipmap 0–2 combined usage < 5%
→ Severe memory waste

Practical Example:

1024×1024 texture
0% usage on Mip 0/1
85% usage on Mip 2 → Safe downgrade to 256×256

Global Mipmap Limit & Texture Streaming

Global Mipmap Limit

Forces removal of specific Mipmap levels
Applied per Quality Level or group
Simple but visually destructive if misused

Texture Streaming System

Adaptive runtime system controlling mip levels based on memory budget.

Key Parameters:

Memory Budget (e.g., 200MB mobile target)
Max Level Reduction (controls initial mip stripping)

Execution Flow:

Load non-streaming textures normally
Load streaming textures with reduced mip levels
Evaluate total memory usage
Dynamically adjust mip levels based on budget

Limitations:

High CPU overhead due to continuous evaluation
Requires correct API-level activation (not just Editor toggle)
Ineffective if memory budget is misconfigured or too large

Read/Write Enabled

Enabling Read/Write doubles memory usage:

GPU copy + CPU copy

Most runtime textures do NOT require it and should disable this flag.

Atlas Creation Issues

Common pitfalls:

Atlas exceeds max resolution → multiple pages created
Loading one sprite triggers full atlas load
Poor grouping causes unnecessary memory spikes

Best Practices:

Limit atlas pages to 2–3
Group assets by usage frequency and scene dependency
Avoid partially empty large atlases

TextMeshPro Considerations

TMP introduces hidden memory costs:

Issues:

Large SDF atlas textures (Alpha8 format)
Dynamic fonts retaining .ttf in memory
Default font assets loaded unnecessarily

Optimizations:

Convert to static TMP after character set is finalized
Use Multi-Atlas Textures for better packing
Remove unused default fonts (e.g., LiberationSans, EmojiOne)

⚠️ Note:
Multi-Atlas and static TMP optimization paths are mutually exclusive in many workflows.

Final Takeaway

Texture optimization in Unity is fundamentally a data-driven sampling problem, not just a compression task.

Key levers:

Format correctness
Mipmap utilization efficiency
Resolution-to-usage ratio
Streaming strategy tuning
Atlas grouping strategy

How to Optimize Bloom and Depth of Field (DOF) in Unity URP Without Sacrificing Visual Quality

GameOptim — Tue, 30 Jun 2026 12:34:01 +0000

Bloom and DOF are often the biggest GPU performance killers

When profiling mobile games, Bloom and Depth of Field (DOF) frequently appear among the most expensive post-processing effects.

A recent GOT Online performance report revealed that both effects were generating unnecessary GPU workload and increasing power consumption on mobile devices.

Here are several practical optimization strategies.

Optimize Bloom

According to the performance report, the majority of Bloom's GPU cost comes from the multiple downsampling and upsampling passes performed on high-resolution render textures.

In this case, the game renders at 1920 × 958, which is already a reasonable high-quality rendering resolution.

However, Bloom is currently using a 1/2 downsample ratio.

A better option is to switch to 1/4 downsampling whenever the scene contains relatively few bright highlights and the slight quality difference is acceptable.

This optimization provides several benefits:

Reduces high-resolution render texture read/write operations
Lowers GPU memory bandwidth usage
Decreases render target cache pressure
Reduces overall GPU power consumption

After changing the Bloom settings, compare the results using GOT Online by checking both the power consumption curve and the visual output on real devices. If image quality remains acceptable, keep the lower downsample ratio.

Optimize Depth of Field (DOF)

Depth of Field is one of the most expensive post-processing effects on mobile GPUs because it consumes both GPU compute resources and memory bandwidth.

A practical optimization strategy is:

1. Determine whether DOF is really necessary

Many games enable DOF by default, but in gameplay the visual improvement can be minimal.

If the effect doesn't significantly enhance the player experience, disabling it entirely often provides the largest performance gain.

2. Prefer Gaussian DOF over Bokeh DOF

If DOF must remain enabled, choose Gaussian DOF whenever possible.

Compared with Bokeh DOF, Gaussian DOF produces a much lower GPU workload while still providing acceptable visual quality for most scenes.

3. Disable DOF on lower graphics quality presets

Mid-range and low-end mobile devices generally benefit more from stable frame rates than from cinematic blur effects.

For Low and Medium graphics presets, disabling DOF is usually the recommended approach.

4. Don't use DOF to darken screen edges

Some projects use DOF to create a subtle edge-darkening effect.

Instead, use URP's built-in Vignette post-processing effect.

Vignette produces a similar visual result with significantly lower rendering cost.

Recommended Graphics Quality Configuration

A practical graphics quality strategy could look like this:

Quality Level	Bloom	DOF
High	Enabled (1/4 Downsample Recommended)	Gaussian DOF
Medium	Enabled (1/4 Downsample)	Disabled
Low	Optional	Disabled

This approach maintains image quality on high-end devices while significantly reducing GPU workload and power consumption on mid-range and entry-level hardware.

Conclusion

Bloom and DOF can greatly improve visual quality, but they are also among the most expensive post-processing effects in Unity URP.

Rather than simply disabling them, developers should adjust their quality based on device capability:

Reduce Bloom downsampling resolution when possible.
Use Gaussian DOF instead of Bokeh DOF.
Disable DOF on lower graphics presets.
Use Vignette instead of DOF for simple edge-darkening effects.

Small changes like these can noticeably reduce GPU load, memory bandwidth usage, and battery consumption while preserving a consistent visual experience across a wide range of mobile devices.

GPU Vertex Bottlenecks in Unity Large Scenes: Why Mesh Merging Breaks Culling Efficiency

GameOptim — Mon, 29 Jun 2026 10:55:05 +0000

We observed unusually high GPU vertex processing cost and would like to understand the cause and possible solutions.

From GameOptim’s GOT Online report, the total triangle count of a large open-world scene is approximately 360,000. However, the effectively visible region in the current frame only accounts for around 40,000 triangles.

A:

This is a typical case caused by large-scale mesh merging, which reduces the effectiveness of CPU-side culling.

When multiple small meshes that span large spatial distances are merged into a single oversized mesh, Unity’s CPU visibility culling operates at the Renderer level, using a single bounding box for the entire object. As long as this bounding box intersects with the camera frustum, the entire mesh may be sent into the GPU rendering pipeline.

In this project, there is a clear presence of oversized mesh assets. According to the mesh resource breakdown in the report, one mesh reaches approximately 11MB in size and contains about 210,000 vertices. Combined with scene layout characteristics, this strongly suggests large-scale cross-region mesh merging.

This approach significantly degrades CPU-side culling efficiency. Even if only a small portion of the mesh is visible on screen, a large amount of irrelevant geometry can still be submitted to the GPU pipeline.

Although modern GPUs perform hardware-level culling and may discard some invisible triangles in later stages, the cost has already been paid at earlier stages, including:

Vertex processing overhead
Pipeline scheduling overhead
Memory transfer and bandwidth cost

As a result, both GPU workload and memory bandwidth pressure increase.

Solution

We do not recommend manually merging large numbers of spatially distant objects into a single oversized mesh.

Instead, it is preferable to use Unity’s built-in rendering optimization mechanisms:

Static Batching
GPU Instancing
SRP Batcher

When applying batching, spatial locality must be carefully controlled. Avoid merging objects that span large distances or different visibility regions into a single Renderer.

A more appropriate approach is to maintain reasonable mesh granularity, allowing the engine to perform effective CPU-side culling. This enables early rejection of invisible objects before they enter the GPU pipeline, reducing unnecessary draw submission and GPU workload.

Key Takeaway

Reducing Draw Calls does not necessarily improve GPU performance.

If batching is applied blindly across large spatial ranges, resulting in oversized bounding volumes, CPU culling efficiency is reduced. This can lead to more invisible geometry being processed by the GPU pipeline.

In such cases, the final outcome is often:

Unity Memory Optimization: How to Identify Unused Prewarmed Particle Systems with GOT Online

GameOptim — Fri, 26 Jun 2026 08:57:54 +0000

Why does the GOT Online report show particle system memory continuously increasing to over 100MB, even though no large number of new effects have been added to the scene and no particle effects appear to be playing during runtime? How should this be investigated?

A

Many projects use a particle system prewarming strategy. When entering a battle or gameplay scene, particle effect instances are instantiated in batches and organized into pools based on particle types. When an effect is needed, it can be activated directly from the pool instead of being instantiated at runtime.

The advantage of this approach is that it helps avoid runtime stutters caused by object instantiation. However, it also has a trade-off. If the object pool does not implement a proper recycling mechanism, particle systems and their associated resources may remain resident in memory for a long time—even if they never emit a single particle during gameplay.

GOT Online provides a very useful filter:

Particle System Assets with a Peak Playing Component Count of 0

After enabling this filter, you can quickly identify particle systems that are still occupying memory but whose Peak Playing Component Count remains 0. In other words, these are particle systems that have been prewarmed but have never actually been triggered since the beginning of the profiling session.

In this example, the report shows that particle systems consume more than 100MB of memory. After applying the filter, a significant portion of that memory belongs to particle systems whose Peak Playing Component Count is 0. These assets were preloaded into the object pool but were never actually used.

A recommended investigation workflow consists of three steps:

Step 1: Check the particle system memory trend.

If particle memory increases in clear step-like increments instead of changing smoothly with scene transitions, it is likely that particle systems are being prewarmed in batches.

Step 2: Measure the proportion of particle systems with a Peak Playing Component Count of 0.

If a large percentage of particle systems fall into this category, the current prewarming strategy may be too aggressive.

Step 3: Group assets by their resource paths.

GOT Online allows you to trace resource paths up to five levels. You can categorize particle systems by asset type—such as skill effects, environment effects, or UI effects—to identify those that have never actually been played. Based on the results, you can decide whether they should be loaded on demand or removed from the prewarming list.

It is important to note that a Peak Playing Component Count of 0 does not necessarily mean a particle system will never be used. It simply indicates that it has not been triggered up to the current sampling point. Before modifying your prewarming strategy, you should evaluate each effect based on its actual usage frequency and gameplay requirements to avoid removing low-frequency but mission-critical effects.

Prewarming itself is not the problem. The real issue is when particle systems remain in memory for long periods after prewarming without ever being used. An effective prewarming strategy should always be aligned with the actual frequency at which particle effects are triggered.

Mono Memory Keeps Growing, But Managed Objects Don’t — Is It Really a Memory Leak?

GameOptim — Thu, 25 Jun 2026 09:04:04 +0000

We recently ran into a strange Mono memory issue while profiling a production project.

In the GameOptim GOT Online Mono Mode report, Used Mono memory kept increasing continuously over time.

At first glance, it looked exactly like a classic memory leak.

But there was one detail that didn’t fit:

The total amount of Managed Objects remained almost unchanged.

That raised an important question:

If live objects aren’t increasing, why is Mono memory still growing?

After deeper analysis, the root cause turned out not to be a memory leak at all — but heap fragmentation.

When Mono Memory Grows, It Doesn’t Always Mean Object Growth

A common misunderstanding in Unity memory analysis is assuming:

But in many cases, that’s not true.

In the GOT Online Mono Mode report:

Used Mono = Managed Objects + Heap Fragmentation

These two parts are displayed separately in the Heap Object Snapshot:

Pink = actual live Managed Objects
Blue = fragmented heap space

This distinction is critical.

Because increasing Mono memory can come from either side.

The Suspicious Pattern

In this case, we observed that between frame 15000 and 20000, Used Mono kept rising steadily.

The usual troubleshooting process was straightforward:

Inspect resident objects
Look for object retention
Verify whether allocations are accumulating

At first, this strongly suggested a memory leak.

But after checking the resident object snapshots, the object count remained relatively stable.

There was no growth pattern matching the Mono increase.

That was the first sign that the issue might not be object retention.

Breaking Down the Heap Composition

Once we separated Used Mono into its components, the pattern became much clearer.

The increase was not coming from Managed Objects.

It was coming almost entirely from heap fragmentation.

The diagnosis rule is simple:

If:

Managed Object count remains stable
Used Mono keeps increasing
Fragmentation ratio keeps expanding

Then the issue is very likely heap fragmentation, not a memory leak.

This distinction matters because the optimization direction is completely different.

Why Mono Heap Fragmentation Happens

This behavior comes from how the Mono heap works internally.

Mono usually expands on demand.

But once heap space has been allocated, it typically does not immediately return memory back to the operating system after objects are released.

This creates an important side effect.

If a project repeatedly performs:

Allocate → Release → Allocate → Release

especially with small temporary objects,

it can leave behind many small free regions inside the heap.

These regions may be reusable individually, but often cannot be merged into large continuous blocks.

Over time:

fragmentation increases
allocation efficiency drops
heap expansion continues

Even if actual live objects remain stable.

This is one of the most typical fragmentation patterns in Mono-based Unity projects.

How Severe Can It Get?

In some projects, fragmentation can become almost equal to actual object memory.

For example:

Actual Managed Objects: ~200 MB
Final Used Mono: ~400 MB

That means half of the Mono heap is effectively unusable fragmented space.

At that point, the problem is no longer:

Who forgot to release memory?

But:

Who is allocating too frequently?

That’s a very different investigation.

Common Sources of Heap Fragmentation

In production Unity projects, common sources include:

1. LINQ allocations

Frequent use of:

.Where()
.Select()
.ToList()

can create many temporary enumerators and collections.

2. String concatenation

Especially inside Update loops:

text = "HP: " + currentHP;

This generates temporary strings constantly.

3. Boxing / Unboxing

Value types converted to object:

object obj = intValue;

can silently allocate.

4. Coroutine closures

Captured variables inside coroutines may allocate hidden objects.

5. Temporary Lists

Repeated:

new List<T>()

inside hot paths can become fragmentation hotspots.

6. Frequent delegate creation

Lambda expressions and temporary delegates can generate short-lived allocations.

Quick Diagnosis Checklist

When Mono memory keeps growing, check these first:

✔ Is Managed Object count growing?

✔ Is fragmentation ratio growing faster than objects?

✔ Do heap snapshots show stable live objects?

✔ Are temporary allocations happening in hot loops?

If the answer matches this pattern, you’re likely dealing with fragmentation.

Not a leak.

Final Thoughts

When analyzing Mono memory issues, the first instinct is often to search for unreleased objects.

That’s reasonable.

But not every memory increase means object retention.

Sometimes the real issue is simply allocation frequency.

Before deciding how to optimize:

Always break down Used Mono into:

actual object growth
fragmentation growth

That distinction determines whether you should optimize:

object lifetime

allocation behavior

And in performance optimization, that difference can save a lot of time.

Why Is Your Unity Game Using So Much Memory? Hidden Redundant Assets May Be the Real Problem

GameOptim — Wed, 24 Jun 2026 06:28:29 +0000

Summary

Resource redundancy in Unity is primarily caused by duplicated AssetBundle packaging without dependency sharing.
Peak Count > 1 indicates potential runtime duplication of identical assets in memory.
Unnamed resources (N/A) are typically dynamically instantiated objects without explicit naming, reducing traceability.
Persistent resources that are never unloaded lead to cumulative memory growth and increased peak memory usage.
Rendering Utilization is a key metric to identify unused textures and meshes in GPU execution pipelines.
Resources with 0% rendering utilization are strong indicators of memory waste or incorrect asset lifecycle design.

1. Suspected Redundancy

Peak Count (Redundancy Indicator)

Peak Count represents the maximum number of simultaneous instances of the same resource within a single frame.

When Peak Count > 1:

Resource is flagged as suspected redundant
Highlighted in red in Resource List
Indicates potential duplicate memory allocation

Technical Interpretation

In theory:

Each resource should exist as a single instance in memory

When duplication occurs:
→ Multiple copies of the same asset exist simultaneously
→ Memory usage increases unnecessarily
→ GPU/CPU memory pressure increases

Visual Reference

Root Cause Analysis

1. AssetBundle Packaging Duplication (Primary Cause)

Most redundancy originates from AssetBundle structure issues:

Shared assets (Texture / Mesh / Material) included in multiple bundles
Missing dependency-based packaging strategy
Independent bundle loading creates duplicate runtime instances

2. Detection Limitation (Important Constraint)

Detected redundancy is classified as “suspected” because:

Detection rule is based on: → Same name + same memory attributes

However:

Different assets may share identical metadata
False positives may occur in complex projects

Validation Strategy

To confirm redundancy:

Use AssetBundle dependency analysis tools
Compare bundle-level asset inclusion
Prioritize optimization based on memory impact size

GameOptim Insight

Redundancy is often not visible in code logic but originates from packaging architecture, making it one of the most overlooked memory inefficiency sources in Unity projects.

Key Takeaways

Peak Count > 1 indicates potential runtime duplication risk
AssetBundle dependency design is the primary control point
Suspected redundancy requires validation before optimization
High-memory duplicated assets should be prioritized first

2. Unnamed Resources

Core Concept

Unnamed resources (N/A) refer to runtime-generated assets without explicit identifiers.

These are typically created via:
new keyword instantiation
Runtime procedural generation
Temporary object creation without naming

Technical Impact

Unnamed resources reduce:

Traceability in memory profiling
Debugging efficiency
Resource lifecycle tracking accuracy

Visual Reference

Engineering Recommendation

To improve traceability:

Assign explicit .name values to runtime objects
Standardize naming conventions for dynamically created assets
Monitor N/A resources with high memory footprint or redundancy

Key Takeaways

N/A resources are dynamically created but unnamed assets
They reduce visibility in memory analysis tools
Naming improves debugging and lifecycle tracking
High-memory N/A resources should be prioritized for inspection

3. Persistent Resource Overload

Core Concept

Persistent resources refer to assets that:

Are loaded into memory
Remain resident across multiple scenes
Are never explicitly unloaded

Over time, they accumulate and increase total memory pressure.

Technical Behavior

At runtime:

Resources are loaded at specific game stages
Some assets remain cached until process termination
Improper unloading causes cumulative memory growth

Visual Reference

Memory vs CPU Trade-off

Resource residency strategy involves balancing:

Memory pressure (RAM usage)
CPU overhead (reload cost)

Optimization principle:

High memory pressure + low CPU cost switching → Prefer unloading and reloading strategy

Advanced Analysis (GameOptim GPU Mode)

Rendering Utilization Concept

Rendering Utilization measures:

Example

Texture A exists in 6,000 frames
Used in rendering in 3,000 frames

→ Rendering Utilization = 50%

Practical Interpretation

100% utilization → always used
Low utilization → partially used
0% utilization → likely wasted resource

Visual Reference

Root Cause Patterns

Persistent waste is usually caused by:

Cross-scene caching without cleanup
Legacy development assets still included in build
Coarse-grained packaging strategy (no per-scene control)
Invisible or rarely visible scene objects
High-resolution UI assets retained in non-UI scenes

Real-World Example (GameOptim Observation)

Many projects retain:

Login UI textures
Loading screen assets

into:

Battle scenes

→ Leading to unnecessary memory retention

Detection Strategy (GPU Mode)

Resources with:

0% rendering utilization

should be treated as:

→ High-probability memory waste candidates

Engineering Workflow

Use Rendering Resource Analysis panel
Filter resources with 0% utilization
Cross-check scene usage logic
Validate with runtime scene transitions
Remove or reassign asset lifecycle ownership

Key Takeaways

Persistent resources must be explicitly managed across scenes
Rendering Utilization is a key metric for identifying waste
0% utilization strongly indicates memory inefficiency
Scene-level asset lifecycle design is critical
GPU sampling enables visibility into real usage behavior

Final Section Summary (Cross-Issue Insight)

Across all three categories:

Redundancy → Packaging-level issue (AssetBundle structure)
N/A resources → Runtime naming / traceability issue
Persistent waste → Lifecycle management issue

Together, they form the core structural causes of Unity mobile memory inefficiency.

Continue reading the series

Why Do Unity Games Crash After Running for a While? How to Find and Fix Memory Bottlenecks

GameOptim — Tue, 23 Jun 2026 09:44:09 +0000

Summary

Runtime memory issues in Unity are primarily reflected in PSS Total, which represents actual physical memory usage of a process.
RSS Total tends to overestimate memory usage due to full inclusion of shared libraries, making it less reliable for diagnosis.
Android OOM crashes occur when system memory pressure forces termination of low-priority processes such as games.
Unity Memory Profiler alone is insufficient; system-level tools like adb dumpsys meminfo are required for full memory analysis.
Memory issues should be decomposed into Tracked Memory, Untracked Memory, and system-level Native Heap usage.
Safe PSS memory usage should remain below 50–60% of total device RAM to avoid crash risk.

1. Runtime Memory Usage Analysis

PSS Total (Primary Runtime Metric)

PSS Total represents the actual physical memory usage of a process, where shared memory is proportionally distributed across processes.

It is the most accurate metric for evaluating Unity runtime memory footprint.

RSS Total(Secondary Reference Metric)

RSS Total includes full shared library memory in each process.

This leads to inflated memory values and reduces its diagnostic reliability compared to PSS.

Runtime Memory Risk Mechanism

When system memory usage reaches a high threshold:

Android OS triggers memory pressure recovery
Low-priority processes (including games) are terminated first
This leads to Out-of-Memory (OOM) crashes in crash logs

1. Unity Memory Profiler Analysis

Unity Memory Profiler provides two major versions with structural differences:

Memory Profiler 0.7.1

Key characteristics:

Clear separation of In use vs Reserved memory
Summary view divides memory into three main categories
Reserved memory reflects engine allocation overhead

Limitation:

Inconsistent category hierarchy
Requires manual filtering for meaningful breakdown (e.g., Manager, SerializedFile)

Memory Profiler 1.1.0

Improvements:
Simplified summary structure
Expanded classification into five asset types
Improved usability for diagnosis

Limitation:
Reserved memory is merged into Native
IL2CPP VM memory appears as Unknown

Key observation:

Large Unknown memory often originates from:
- AssetBundle compression (e.g., LZMA)
- VM / system-level allocations
Not all Unknown memory indicates leakage

2. System-Level Memory Analysis (ADB)

Unity profiling must be validated at system level:
adb shell dumpsys meminfo package_name/pid

Key memory components:

Native Heap
Gfx dev / EGL mtrack / GL mtrack
Unknown

Memory Attribution Rules

Unity rendering memory → Gfx / EGL / GL mtrack
External libraries/plugins → Native Heap / Unknown
System-level allocations → Unknown

Diagnostic Conditions

Memory risk is likely when:

Gfx + EGL + GL + Unknown >> Unity Tracked Memory
Native Heap shows continuous growth trend

Engineering Strategy

Use A/B builds to isolate plugin memory impact
Use plugin-native profilers (e.g., Wwise)
Use GOT Online Lua Mode for Lua-heavy projects
Use Perfetto for deep Native Heap tracing

GameOptim Insight

Native Heap growth is one of the most common hidden memory issues in production Unity projects and cannot be fully diagnosed using Unity tools alone.

Best Practices

Always prioritize PSS Total over RSS Total for crash analysis
Combine Unity Profiler + adb + Perfetto for full-stack memory tracing
Monitor Unknown memory as a diagnostic signal, not a final conclusion
Separate asset memory and runtime heap memory in analysis
Validate plugin memory behavior using A/B builds
Avoid relying on single-frame snapshots for memory diagnosis

Key Takeaways (Runtime Memory)

PSS Total is the most reliable runtime memory metric in Unity mobile games
RSS Total overestimates memory due to full shared library accounting
Android OOM is triggered by system memory pressure, not just app usage
Unity Memory Profiler must be combined with system-level tools for accuracy
Unknown memory is not always a leak signal
Native Heap growth is a key indicator of external memory issues

2. Memory Parameter Standards

Safe Memory Threshold Principle

Game crash risk increases significantly when PSS exceeds:
→ 50%–60% of total device RAM

This threshold reflects Android system memory pressure behavior.

Mono Heap Sensitivity

Mono heap affects:

GC pause duration
Runtime allocation stability
Memory fragmentation risk

It requires stricter monitoring than other memory types.

Device-Level Memory Safety Limits

2GB devices → PSS ≤ 1GB
3GB devices → PSS ≤ 1.5GB
4GB devices → PSS ≤ 2GB

Memory Type		Recommended Value
Memory Type		2G	3G	4G
Total Memory	PSS Total	1 GB	1.5 GB	2 GB
Total Memory	Reserved Total	700 MB	1.2 GB	1.5 GB
Resources Memory	Texture	140 MB	210 MB	280 MB
	Mesh	60 MB	100 MB	140 MB
	Shader	40 MB	50 MB	60 MB
	Animation Clip	40 MB	60 MB	80 MB
Mono Heap Memory		80 MB	100 MB	120 MB
Lua Memory		100 MB	100 MB	100 MB

Asset & Pipeline Standards

Define memory budgets early in production
Translate budgets into art production constraints
Enforce compliance via automated validation tools
Segment assets into quality tiers when needed
Maintain alignment between engineering and art teams

Best Practices

Set memory ceilings based on device tiers early in development
Prioritize PSS reduction over Reserved optimization
Treat Mono heap as a high-risk GC factor
Automate asset compliance checking in pipelines
Validate memory impact using real device testing
Adjust standards based on project type (2D vs 3D)

Key Takeaways (Memory Standards)

Safe PSS usage should remain within 50–60% of device RAM
Mono heap has a direct impact on GC performance and stability
Texture memory is the dominant contributor in most Unity projects
Memory budgets must be enforced through pipeline automation
Standards must be adapted to project architecture and device targets
Engineering and art alignment is critical for memory stability

FAQ

What is the safest memory limit for Unity mobile games?
Typically 50–60% of device RAM based on Android memory pressure behavior.

Why is PSS more important than RSS?
Because it reflects proportional real memory usage instead of overcounting shared libraries.

What causes most Unity memory crashes?
Excessive PSS usage and uncontrolled Native Heap growth.

Why does Unknown memory appear in profiling tools?
It often includes system allocations, IL2CPP memory, or compressed asset bundles.

How can memory issues be reliably diagnosed?
By combining Unity Memory Profiler, adb dumpsys meminfo, and Perfetto tracing.

Why is Mono heap critical?
Because it directly impacts GC pauses and runtime stability.

Should memory limits be fixed across all projects?
No, they must be adjusted based on project type and platform.

How can memory standards be enforced in production?
Through automated asset validation and engineering pipelines (e.g., GameOptim tooling).

Continue reading the series

How Can Unity Developers Find and Fix Performance Bottlenecks Before Launch?

GameOptim — Mon, 22 Jun 2026 10:53:20 +0000

Summary

Performance issues (crash, lag, overheating, battery drain) lower retention; they must be mapped to Memory, CPU, or GPU root causes.
Identify the root cause: e.g., memory leaks vs. high triangle count vs. heavy UI updates.
Use tools: Unity Profiler, Frame Debugger, Memory Profiler, Xcode Instruments, Snapdragon Profiler, and GameOptim GOT Online (real-device analytics) + Gears (local debugging).
Prioritize fixes by importance (main bottleneck) and ease of implementation (quick wins).
Balance performance vs. visual quality dynamically per scene (combat vs. cutscene).
Apply device tiering: high-end devices get full visuals; low-end devices use reduced settings.
Continuously monitor performance via DevOps pipelines and post-launch telemetry.

Core Concepts

Memory

Problem: Poor caching strategies, redundant resources, continuous memory leakage, oversized art assets.
Impact: Game crashes after prolonged play.

CPU

Problem: Excessive triangle count, high Draw Calls causing high rendering pressure; complex and frequently updated UI.
Impact: Severe lag, low frame rate.

GPU

Problem: Excessive GPU load in the current scene.
Impact: Significant device overheating.

Profiling Tools

Problem: Without direct and accurate performance data, identifying root causes becomes a major challenge.
Solution: Use engine tools (Unity Profiler, Frame Debugger, Memory Profiler), IDE tools (Xcode Instruments, Android Studio Profiler), hardware tools (Snapdragon Profiler), and GameOptim GOT Online (real-device analytics) + Gears (local debugging).

Device Tiering

Problem: A single set of visual standards cannot suit all hardware.
Solution: Enable post-processing, high resolution, and high-poly models on high-end devices; use reduced settings on low-end devices. Adjust tiering based on game genre.

Continuous Monitoring

Problem: Many teams stop optimizing after launch, leading to performance regressions.
Solution: Assign dedicated optimization engineers, build custom DevOps tools, and carry experience forward to new projects.

Technical Framework

Layer	Role	Key Tools / Methods
Diagnosis	Identify root cause (Memory/CPU/GPU)	Unity Profiler, Frame Debugger, Memory Profiler, Xcode Instruments, Snapdragon Profiler
Real-Device Analytics	Cross-device trend monitoring	GameOptim GOT Online (SDK integration, auto-visualization, performance scores)
Local Debugging	Lightweight per-build analysis	GameOptim Gears (free toolset)
Prioritization	Rank issues by importance & ease	Impact vs. effort matrix
Optimization Execution	Apply fixes (trade-offs, tiering)	Balance visuals vs. performance; device-specific settings
Continuous Monitoring	Post-launch & CI/CD	Dedicated DevOps, internal profiling pipelines

Best Practices

1. Priority Strategy (Impact vs. Effort)

High importance: Fix the main bottleneck first (e.g., memory leak causing crashes).
High ease: Implement quick wins (e.g., toggle an engine setting with low effort).
Sort optimization list by these two factors, not by order of discovery.

2. Performance vs. Visual Quality Trade-off

Dynamically adjust per scene: combat → prioritize performance; cutscenes/character views → prioritize visuals.
Eliminate completely useless overhead (non-contributory issues) before sacrificing quality.

3. Device Tiering

Define separate standards for low-end, mid-range, and high-end/flagship devices.
Example: high-end → post-processing, high resolution, high-poly models; low-end → reduced settings, baked shadows.
Adjust tiering based on game genre (battle royale vs. collection-oriented).

4. Continuous Monitoring (Post-Launch & DevOps)

Assign dedicated optimization engineers.
Build custom DevOps tools to automate performance regression detection.
Carry experience forward to new projects.

Key Takeaways

Game performance optimization is a systematic process: identify root cause (Memory/CPU/GPU) with proper tools → prioritize by importance and ease → trade off visual quality where needed → apply device tiering → monitor continuously. Using real-device analytics (GameOptim's GOT Online) and local debugging (Gears) alongside built‑in engine profilers drastically reduces guesswork. The ultimate goal is stable gameplay across all target devices; sacrificing non‑essential visuals is acceptable, but eliminating useless overhead should come first.

FAQ

Q1: Why does my Unity game crash after playing for a while?

A: Likely a memory issue: poor caching, redundant resources, or memory leak. Use Memory Profiler and GameOptim GOT Online to track PSS growth.

Q2: What causes low FPS in a specific scene?

A: Could be high triangle count/Draw Calls (rendering), complex UI updates, or heavy CPU logic. Use Unity Profiler to identify the bottleneck module.

Q3: How do I prevent device overheating in mobile games?

A: Usually GPU overload. Reduce triangle count, simplify shaders, limit shadows and post-processing, and apply device tiering.

Q4: Should I optimize performance early or late in development?

A: Early and often. Delaying until late stage leaves little time to fix severe issues, harming retention. Integrate profiling from early milestones.

Q5: How to handle performance across low-end and high-end devices?

A: Use device tiering. Define different settings (resolution, shadows, effects) per tier. Test on real devices with GameOptim GOT Online.