DEV Community: GameOptim

Mobile Game Power Optimization: Why 30 FPS vs 60 FPS Can Double Energy Usage (Real Data Breakdown)

GameOptim — Fri, 12 Jun 2026 11:24:50 +0000

Introduction

Real-world mobile game power consumption varies significantly across rendering complexity, frame rate, and device workload distribution. Based on collected production data from multiple live games, we analyzed how frame rate and system-level workloads influence overall energy usage.

This article summarizes observed power consumption patterns, provides empirical reference ranges, and outlines key practices for stable and reliable power profiling.

1. Frame Rate Has a Significant Impact on Power Consumption

One of the most consistent findings across multiple games is that frame rate directly affects power consumption.

Observed data shows:

At 30 FPS, power consumption is approximately 1600 mW
At 60 FPS, power consumption typically increases to 2800 mW or higher

In combat or visually complex scenes, power consumption can increase further beyond these values.

This confirms that frame rate scaling has a strong and direct correlation with energy usage in mobile games.

2. Empirical Power Budget Reference (Not a Strict Standard)

Based on large-scale collected data, we derived a practical reference breakdown of power distribution. These values are not strict recommendations, but serve as comparison baselines:

GPU power: ~400 mW
CPU (three cores combined): ~1000 mW
Bandwidth-related power: ≤ 500 mW
Screen display: ≤ 200 mW
Other components: ~400 mW

If total system power consumption is kept within:

~2500 mW

It is generally considered a relatively healthy operating range.

However, actual values vary significantly between projects and must be evaluated per case.

3. Key Considerations for Power Measurement and Analysis

1) Use a consistent 30 FPS test baseline

Using a unified frame rate (30 FPS) is recommended for profiling.

If frame rate is too high:

Device temperature increases
Thermal throttling may occur
Test conditions become unstable
Comparison results become unreliable

2) Keep screen settings consistent

Screen brightness and refresh rate must remain constant during tests.

Both factors directly affect power consumption and can introduce measurement inconsistencies if not controlled.

3) Perform extensive A/B testing

A/B testing is essential for identifying power-related changes.

For example, on the GPU side:

Disable post-processing effects
Disable shadows
Compare power consumption before and after changes

This helps validate whether optimizations produce expected results.

4. CPU Power Analysis: Focus on Thread Distribution

If CPU power consumption is unusually high:

Analyze task execution time distribution
Check for abnormal load on main thread or subthreads

For heavy computation workloads:

Use Job System
Distribute workloads across multiple cores

This reduces sustained high-frequency operation on big CPU cores, which significantly impacts power usage.

5. GPU Power Analysis: Use Counters and Profiling Tools

When GPU power consumption is high:

Use tools such as GOT Online or Gears
Inspect GPU counters

Key areas to investigate include:

Fragment shader workload
Bandwidth pressure
Pipeline bottlenecks

If the issue is shader-related:

Use RenderDoc for frame capture analysis
Identify the most expensive draw calls through GPU timing data

This workflow helps quickly locate performance bottlenecks at the rendering level.

6. Frame Capture Tools for Debugging

RenderDoc-based workflows (and similar tools such as Xcode frame capture) allow:

Frame-by-frame inspection
Cost-based draw call ranking
Shader-level bottleneck analysis

This is one of the most effective approaches for GPU-side debugging.

7. Power Optimization Is an Iterative Process

Power optimization is not a one-time task.

It requires:

Continuous measurement
Repeated comparison experiments
Data-driven analysis
Gradual isolation of root causes

Each subsystem (GPU, CPU, bandwidth, rendering, and logic) must be validated independently through controlled experiments.

8. Ongoing Work

We are continuously researching more advanced power analysis workflows and exploring deeper integration of quantitative power tools such as Power Rails into future toolchains.

Conclusion

Mobile game power consumption is the result of multiple interacting systems rather than a single dominant factor.

Key influences include:

Frame rate
GPU workload
CPU thread distribution
Memory bandwidth
Screen configuration

Effective optimization requires structured profiling, consistent test conditions, and iterative A/B validation.

Mobile Game Power Optimization: GPU vs CPU vs Bandwidth vs Screen vs Network (Real Profiling Data Breakdown)

GameOptim — Thu, 11 Jun 2026 12:25:27 +0000

Introduction

As mobile games continue to increase in visual complexity and gameplay intensity, power consumption has become a critical performance constraint. Based on collected profiling data, we analyzed several core factors that influence energy usage in real game scenarios.

Using Perfetto-based metrics and supporting profiling tools, we categorize power consumption into five main areas: CPU, GPU, bandwidth (memory traffic), screen, and network activity.

This article summarizes observed relationships between these factors and real-world power behavior in mobile games.

1. GPU: The Most Direct Driver of Power Consumption

GPU behavior shows a strong and direct correlation with power usage.

In tests conducted on a live game under different graphical quality settings, GPU Clocks and GPU power consumption exhibited a clear positive relationship.

When switching from a low-quality (smooth) preset to a higher-quality preset:

GPU Clocks increase significantly
GPU Power Rails increase accordingly
Overall device power consumption rises noticeably

This confirms that GPU load is one of the most sensitive and direct contributors to power consumption in rendering-heavy scenarios.

In practical terms, higher visual quality almost always translates into higher GPU frequency and higher energy usage.

2. Bandwidth: A Major but Often Underestimated Factor

Bandwidth plays a significant role in both memory and GPU-related power consumption.

In a test scenario involving an empty scene with up to 30 layers of transparent objects, we evaluated the impact of texture compression and mipmap usage.

The results show:

Enabling mipmaps reduces bandwidth significantly
The impact of mipmaps on power consumption is even more noticeable than texture compression alone

After enabling mipmaps (up to 50 layers test condition):

Bandwidth dropped from ~6 GB/s to ~1.5 GB/s
Overall power consumption decreased significantly
GPU-related metrics such as GPU Clocks also decreased

This indicates that bandwidth is not only a memory-side cost but also indirectly influences GPU workload.

Empirical Observation

Based on data fitting:

Each additional 1 GB/s bandwidth increase corresponds to approximately 60–70 mW additional power consumption.

This aligns in magnitude with industry observations (~100 mW per 1 GB/s).

Practical Recommendation

In 3D rendering pipelines, enabling mipmaps for all textures is strongly recommended to reduce bandwidth pressure and energy consumption.

3. Screen Power Consumption: Brightness, Refresh Rate, and Content Matter

Screen power usage depends on multiple factors:

Brightness level
Refresh rate
Display content

Test results show:

Higher brightness increases power consumption
Higher refresh rates increase power usage (90 Hz consistently higher than 60 Hz under identical conditions)

An unexpected finding is that screen content itself also affects power consumption significantly:

Black frames consume less power
High-saturation frames consume more power

In most games, screen power consumption typically ranges between:

150–200 mW

Values significantly above this range may indicate abnormal display behavior or configuration issues.

4. Network: Background Communication Still Matters

Network activity contributes measurable power consumption during both Wi-Fi and cellular data transfers.

Key observations:

Network downloads increase both network and CPU power usage
Typical network-related power consumption ranges between 100–200 mW

In production game tests, even under low-interaction or idle conditions (anti-AFK scenarios), network power consumption can remain unexpectedly high.

This suggests unnecessary or excessive background communication should be investigated and optimized.

5. CPU: Frequency and Thread Distribution Are Critical

CPU power consumption is strongly influenced by operating frequency.

Using Gears for profiling, comparisons between main-thread execution and Job System execution show:

Heavy computation on the main thread keeps big CPU cores at high frequency
This leads to significantly increased power consumption
Moving workloads into Job System reduces big-core frequency and lowers overall power usage

This behavior is expected because CPU power consumption increases non-linearly with frequency due to the voltage-frequency relationship.

Key Insight

CPU power is not only frequency-dependent but also strongly affected by voltage scaling, making high-frequency operation disproportionately expensive in terms of energy usage.

Optimization Guidance

Avoid long-term high-frequency usage on big cores
Distribute workloads across threads properly
Monitor abnormal CPU time distribution in subthreads

In real-world cases, fixing an abnormal network subthread alone reduced total power consumption by nearly 1W.

6. Profiling Consistency Issue: Release vs Debug Builds

During analysis using SimplePerf, a discrepancy was observed:

GOT Online reports showed nearly 10× differences in function contribution
SimplePerf results showed similar values

This was traced back to build configuration differences:

GOT Online used Release builds
SimplePerf used Debug builds (for symbol visibility)

Later verification confirmed:

Release builds with IL2CPP still allow function-level visibility in SimplePerf
Results become consistent with expectations when using proper Release configuration

This highlights the importance of consistent build settings in performance analysis.

Conclusion

Game power consumption does not have a single root cause or “silver bullet”.

It is the combined result of multiple interacting factors:

GPU workload
Memory bandwidth
CPU frequency behavior
Screen configuration
Network activity

Only through data-driven analysis can developers accurately identify the dominant sources of power consumption and apply targeted optimizations.

Mobile Game Power Consumption Optimization: Building a Quantitative Analysis Workflow with Perfetto and Power Rails

GameOptim — Wed, 10 Jun 2026 08:24:28 +0000

As mobile game content, gameplay systems, and rendering quality continue to evolve, power consumption optimization has become an increasingly important challenge for development teams.

Over the past year, we conducted extensive research and practical testing around game power consumption and gradually established a relatively quantifiable analysis methodology. The goal is not only to determine whether power consumption is increasing, but also to identify which hardware components or system modules are responsible for the increase.

This article focuses on the first stage of that methodology: selecting the right tools and building a reliable power analysis workflow.

The Challenge of Power Consumption Analysis

Many performance analysis tools can show that power consumption is rising during gameplay. However, they often fail to answer a more important question:

What is actually causing the increase?

For example:

Is the power increase caused by GPU workload?
Is CPU processing consuming more energy?
Is the display subsystem responsible?
Are other system components contributing significantly?

Without quantitative data, optimization efforts often rely on guesswork rather than evidence.

The goal of power analysis should be to identify the primary source of power pressure and prioritize optimization efforts accordingly.

Starting with Trend Monitoring

GOT Online

A traditional approach is to use GOT Online to observe overall power consumption trends during gameplay testing.

The tool provides a high-level view of power behavior, making it useful for detecting changes between builds or identifying problematic gameplay scenarios.

However, while it can reveal that power consumption has increased, it cannot explain why.

Gears

Gears also provides power consumption curves that allow developers to:

Observe overall power trends during testing
Compare different test scenarios
View average power consumption results

This makes it useful for measuring optimization effectiveness and tracking power-related regressions.

Like GOT Online, however, Gears primarily focuses on power trends rather than root-cause analysis.

It can indicate that power consumption increased, but it cannot directly identify whether the increase originated from GPU activity, CPU workload, or another subsystem.

Exploring Quantitative Power Analysis Tools

To move beyond trend monitoring, we evaluated several tools capable of providing more detailed power data.

Trepn Profiler

One of the first tools investigated was Trepn Profiler.

Based on its name and positioning, it appears to be designed for power-related analysis. However, practical testing revealed significant limitations.

The available data dimensions are relatively limited and primarily focus on frequency changes for a small number of CPU cores.

While this information can provide some insight into CPU behavior, it offers limited value for detailed power attribution.

As a result, this approach was eventually abandoned.

BatteryStats

The next tool evaluated was Android's BatteryStats, accessed through ADB command-line commands.

BatteryStats can collect power-related information based on process UID and provides metrics for multiple system components, including:

Screen
CPU
Audio
Video
Wi-Fi

After organizing and visualizing the collected data, it becomes possible to observe rough power consumption trends across different modules.

For example, steeper trend lines typically indicate higher power consumption within a specific subsystem.

Advantages

Supports multiple power-related subsystems
Provides process-level attribution
Useful for observing module-level trends

Limitations

Despite these advantages, BatteryStats remains relatively abstract.

It cannot accurately identify which application behaviors are responsible for CPU or GPU power increases, and some important power-related modules are not represented in sufficient detail.

For deeper analysis, additional tooling is required.

Power Rails: Hardware-Level Power Breakdown

A significant improvement came with the discovery of Android Studio's Power Rails functionality.

Power Rails provides a much more detailed breakdown of device power consumption, including:

CPU big cores
CPU middle cores
CPU little cores
GPU
Display

This hardware-level visibility allows developers to understand which processing units contribute most to overall power consumption.

For example:

High GPU power usage often indicates rendering-related optimization opportunities.
High CPU big-core power usage may suggest expensive gameplay logic, animation systems, UI updates, physics calculations, or loading operations.

Compared with BatteryStats, Power Rails provides a much clearer picture of actual hardware power distribution.

Limitations of Power Rails

Although Power Rails offers highly valuable data, it comes with several restrictions.

1. Google Pixel Device Requirement

Power Rails currently works only on supported Google Pixel devices.

2. Debuggable Application Requirement

The target application must be built as a debuggable version.

3. Limited Profiling Duration

Long profiling sessions can generate large volumes of data that become increasingly difficult to analyze.

These limitations reduce its practicality for certain production scenarios.

Perfetto: A Practical Solution for Long-Term Power Analysis

After evaluating multiple approaches, Perfetto became the recommended solution for power data collection.

Using the Perfetto web interface, developers can enable both:

Battery tracing
Power Rails tracing

This combination provides detailed power attribution while also supporting long-duration testing sessions.

For example, one-hour gameplay tests can be captured and analyzed effectively.

Although trace memory size is limited, allocating approximately 64 MB is generally sufficient for most power analysis scenarios.

Collecting Power Data with Perfetto

The basic workflow is straightforward.

Step 1: Connect the Device

Within the Perfetto interface:

Select Record New Trace
Choose WebUSB
Click Connect New Device
Select the connected phone

Once the status indicator turns green, the device connection is successfully established.

Step 2: Record Gameplay

Click Start Tracing
Execute the desired gameplay test
Click Stop when testing is complete

The collected trace data can then be opened for analysis.

Step 3: Analyze Power Distribution

Within the analysis results, modules can be sorted by Average Power in descending order.

This immediately highlights the largest power consumers.

Examples include:

Scenario A: GPU Dominates Power Consumption

If GPU power usage is significantly higher than other modules, GPU optimization should become the primary focus.

Potential investigation areas may include:

Rendering workload
Shader complexity
Overdraw
Bandwidth pressure

Scenario B: CPU Big Cores Dominate Power Consumption

If CPU big cores consume the most power, optimization opportunities may exist in:

Gameplay logic
Animation systems
UI updates
Physics calculations
Asset loading workflows

This makes it possible to prioritize optimization work based on measured power impact rather than assumptions.

A Key Advantage of Perfetto

One of Perfetto's most valuable benefits is that the target application does not need to be debuggable.

This means that even production builds downloaded directly from app stores can be analyzed.

For teams investigating issues in released games, this significantly expands the range of scenarios that can be tested.

Current Limitation

Despite its advantages, Perfetto still inherits one important hardware limitation:

Power tracing currently requires Google Pixel devices.

For teams planning to establish a power optimization workflow, access to a compatible Pixel device remains an important prerequisite.

Conclusion

Power consumption optimization becomes far more effective when supported by quantitative data rather than high-level trends alone.

While tools such as GOT Online and Gears are useful for monitoring overall power behavior, identifying the root cause of power issues requires deeper visibility into hardware-level power distribution.

Among the tools evaluated:

GOT Online and Gears are suitable for trend monitoring.
Trepn Profiler provides limited analytical value.
BatteryStats offers basic module-level attribution.
Power Rails enables detailed hardware power breakdowns.
Perfetto combines detailed power tracing with long-duration recording and support for production applications, making it a practical choice for power consumption analysis.

By leveraging Perfetto and Power Rails data, developers can quickly determine whether power pressure originates from the GPU, CPU, display, or other components, enabling more targeted and efficient optimization efforts.

Unity AssetBundle Memory Spikes: Understanding PSS vs Remapper and Fixing Overloaded Bundles

GameOptim — Tue, 09 Jun 2026 11:25:07 +0000

Summary

This article analyzes a memory spike issue observed in GOT Online using GameOptim reports. Investigation shows that unusually high PSS and Remapper memory is not caused by overly fragmented AssetBundles, but by overly broad bundles containing multiple scenes and excessive dependencies. We explain how Unity’s internal object mapping contributes to Remapper overhead and why oversized bundles increase PSS, followed by optimization strategies such as maintaining one-scene-per-bundle packaging.

Unity AssetBundle Memory Spikes: PSS vs Remapper Analysis and Optimization

Problem Overview

In a GOT Online performance report, significant PSS memory spikes were observed in specific scenes. Memory profiling further revealed unusually high Remapper memory usage, indicating potential issues in resource mapping and loading behavior.

A key question emerged:
Is this caused by AssetBundles being split too finely?

The analysis shows the opposite is true.

Root Cause: Overly Broad AssetBundle Packaging

The issue is not excessive fragmentation, but overly broad bundling.

A critical AssetBundle was identified:

defaultpackage_share_assets_art_prefab_scenes.bundle

Key characteristics:

Size: ~232 MB
No significant concentration of high-volume assets (e.g., textures or meshes)
Resource mode shows ~22 MB attributed directly to AssetBundle overhead

This combination strongly suggests inefficient resource grouping rather than asset-heavy content.

Why This Triggers Memory Spikes

1. Mixed Scene Packaging Increases Load Scope

When multiple scenes are included in a single AssetBundle:

Loading one scene may indirectly load unrelated scene assets
Dependency chains expand unintentionally
Memory footprint grows beyond expected runtime scope

2. Remapper Memory Growth (Internal Mapping Overhead)

Unity must maintain internal structures to:

Map object references
Track dependencies
Manage asset-to-object relationships

As bundle complexity increases:

Object count increases
Dependency graph becomes denser
Remapper memory grows significantly

3. PSS Memory Increase (Physical Memory Impact)

Once assets and dependencies are actually loaded:

They contribute directly to physical memory usage
PSS increases alongside runtime asset residency

Key Insight: Remapper ≠ PSS

Although they often rise together, they represent different layers:

Remapper: Internal Unity memory used for object mapping and reference tracking
PSS (Proportional Set Size): Actual physical memory consumed by the process

They are correlated symptoms of the same structural issue, not identical metrics.

Optimization Recommendations

1. Enforce One-Scene-Per-Bundle Strategy

Where possible:

Package a single scene per AssetBundle
Avoid cross-scene dependency aggregation

This reduces:

Unnecessary asset loading
Dependency chain expansion
Remapper overhead

2. Audit Bundle Composition

For each large bundle, verify:

Are multiple scenes included?
Are unused assets bundled unintentionally?
Are shared resources incorrectly centralized?

3. Validate Against Memory Trends

Use profiling data to correlate:

PSS spikes
Remapper growth
AssetBundle load events

This helps isolate structural packaging issues early.

Conclusion

Memory spikes involving both PSS and Remapper are often not caused by asset quantity alone, but by how assets are grouped and loaded.

In this case, the core issue was an oversized, multi-scene AssetBundle that amplified dependency complexity and internal mapping overhead.

A more granular bundling strategy—especially one-scene-per-bundle—can significantly reduce both runtime memory pressure and internal engine overhead.

Optimizing UI Particle Effects in Mobile Games: Balancing Visual Quality and Performance Across Device Tiers

GameOptim — Mon, 08 Jun 2026 11:40:33 +0000

Q1：Besides startup speed issues, we're also facing performance challenges with UI particle effects. This problem doesn't only affect mini-games; mobile apps encounter it as well.

Our art team is currently using a dedicated UI particle management tool that performs particle simulation and refresh logic every frame. As the number of UI particles in a scene increases, the overall performance cost rises significantly. However, simply reducing particle effects often leads to concerns from the art team that the visual quality no longer meets expectations.

Is there a practical approach to balancing visual quality and performance?

A:To balance the visual impact of particle effects with device performance, simply removing effects is usually not the best solution. A lightweight optimization approach is generally more effective.

When creating UI particle effects, it's recommended to prioritize simple quad-based particles whenever possible and avoid mesh particles or particles based on complex models. This helps reduce rendering overhead at the source. At the same time, the overall particle count should be carefully controlled, and excessive nesting of particle sub-systems should be minimized.

For complex, high-cost effects, frame-by-frame animation sequences can sometimes be used as an alternative to achieve similar visual results with lower runtime computation costs. However, frame animations typically consume more memory and VRAM. When used extensively, they may cause stuttering or even crashes on lower-end devices, so the replacement strategy should be applied selectively and with proper scale control.

Q2：We've tried this approach before, but implementation is still challenging in practice. Once particle effects are simplified, the art team often feels that the visual quality drops noticeably. On the other hand, keeping all effects intact can easily lead to frame drops on some low- and mid-range devices.

For UI visual effects like these, how is the balance typically handled in real production projects?

A:That's a very common situation, especially in mini-game development.

Instead of using a one-size-fits-all approach and disabling effects across all devices, a more practical solution is device-tier adaptation.

High-end devices can retain the full particle effect setup. Mid-range devices can reduce particle counts, refresh frequency, and emission rates. Low-end devices can simplify or disable non-essential UI particle effects altogether.

By applying different configurations based on device performance tiers, teams can preserve as much of the intended visual design as possible while keeping overall performance costs under control. This approach helps achieve a better balance between visual quality and runtime smoothness across a wide range of devices.

Android Memory Usage Looks Safe—What Should We Prepare for Before Releasing on iOS?

GameOptim — Fri, 05 Jun 2026 06:28:56 +0000

Q: We have already tested the Android version using GameOptim GOT Online. Memory peaks around 3GB have not resulted in a significant number of crashes. We plan to release on iOS next. Are there any platform-specific optimization strategies we should consider?

A: Most memory optimization principles are shared across Android and iOS, but in practice iOS often imposes stricter memory constraints.

Why Is iOS Different?
On modern Android devices, especially mid-range and flagship models, physical memory capacities commonly exceed 8GB. A memory peak of around 3GB often leaves enough headroom to avoid immediate process termination.

Although recent iPhone models also typically include 8GB of RAM, iOS uses a much stricter memory management model. The operating system actively controls the memory budget available to each application.

When an application exceeds its permitted memory budget, iOS may trigger the Jetsam mechanism and terminate the process. In many cases, the effective crash threshold is below 3GB, and enforcement tends to be more predictable and aggressive than on Android.

This is a pattern reported by many development teams:

The Android version appears stable, but memory-related crashes become significantly more visible after the game is ported to iOS.
For this reason, memory optimization should be planned before the iOS release rather than treated as a post-launch fix.

Recommended iOS Optimization Strategies

1. Use More Conservative Caching Policies
iOS devices generally offer strong CPU performance and fast storage access. This allows developers to rely more on loading and unloading resources dynamically rather than keeping large amounts of content resident in memory.
Reducing long-lived caches is often one of the most effective ways to lower memory peaks and avoid Jetsam terminations.

2. Evaluate the "Increase Memory Limit" Entitlement
For devices running iOS 15, iOS 16, and later versions, developers can evaluate Apple's Increase Memory Limit entitlement.
In some scenarios, this allows applications to operate with a larger memory budget and may reduce Jetsam-related crashes.
However, the actual benefit varies by device model and operating system version, so testing on real hardware is essential.

3. Reuse Existing Android Optimization Work
Many Android-side memory optimizations remain equally valuable on iOS, including:

Shader optimization
AssetBundle cache management
Native memory reduction
Resource lifecycle optimization

In most cases, these improvements can be carried over directly without requiring platform-specific reimplementation. Only certain plugins or third-party integrations may require separate handling.

4. Establish Low-Memory Validation Targets Early
During development, it is advisable to treat a 3GB–4GB memory budget as a stress-testing target rather than relying exclusively on flagship devices.

This approach helps teams identify:

Excessive resource residency
Loading-related memory spikes
Inefficient cache strategies much earlier in the development cycle, reducing the risk of large-scale memory issues emerging after release.

Key Takeaway
Android memory stability does not automatically guarantee iOS stability. While Android devices often tolerate higher memory consumption, iOS enforces memory budgets much more aggressively through Jetsam. Teams planning a cross-platform launch should validate memory usage against stricter targets and optimize peak memory consumption well before iOS release.

Why Does the Same Build Show Higher PSS Memory on a 16GB Device Than on a 6GB Device?

GameOptim — Thu, 04 Jun 2026 12:14:48 +0000

Q: While running compatibility tests with GameOptim GOT Online, we noticed a counterintuitive result: the same game build shows tens of megabytes more PSS Total on a 16GB device than on a 6GB device. Reserved Total is nearly identical on both devices, and the entire difference appears in "Others." What exactly is this "Others" category?

A：This is not a measurement error. The root cause lies in how PSS is calculated.

PSS distributes the memory usage of shared libraries across all processes that use them. Since different Android devices ship with different system services, graphics drivers, ROM customizations, and framework components, the amount of shared library memory present on each device can vary significantly.

As a result, even when running the exact same game build, PSS Total may differ by tens of megabytes—or even more—between devices.

In many cases, high-end devices actually have a more complex software stack, including:

Newer Android framework versions
Additional manufacturer customizations
Larger graphics and driver stacks
More pre-installed system services

These components introduce additional shared libraries, increasing the portion of memory attributed to the game process through PSS accounting. This explains why the same game can report a higher PSS Total on a flagship device than on a lower-end device.

Importantly, this overhead is outside the game engine's direct visibility and typically appears as the gap between PSS Total and Reserved Total.

So what does the engine-level "Others" category represent?

It is different from the additional memory reflected in PSS. Within Reserved Memory, "Others" generally refers to resources that are not classified into dedicated categories, including:

Memory reserved for fragmentation management
Scene Objects (GameObjects, Transforms, MonoBehaviours)
Serialized asset data
Untracked resources such as Cubemaps and similar asset types

Therefore, it is completely normal for the same build to consume several dozen megabytes more PSS memory on a 16GB device than on a 6GB device. This difference is primarily related to the device's software environment rather than the game package itself.

Recommended Memory Analysis Approach

PSS Total reflects overall system memory pressure but can be inflated by shared-library allocation and should be interpreted carefully when comparing different devices.
Reserved Total is a better indicator of memory that is directly managed and controlled by the engine.
If the gap between PSS Total and Reserved Total continues to grow over time, it may indicate increasing usage from engine-untracked memory sources such as:

Native Heap allocations
Graphics driver caches
Third-party SDK memory usage
Memory-mapped files

In these cases, additional investigation with platform-level profiling tools is recommended.

Introduction and Optimization Fundamentals

GameOptim — Wed, 03 Jun 2026 08:33:26 +0000

1. Performance from the Player’s Perspective

From a player’s point of view, performance issues are immediately noticeable and often more impactful than gameplay or visual quality. Common questions arise during gameplay:

Why does the game crash after extended play sessions?
Why does frame rate drop or stutter occur in certain scenes?
Why does my device overheat during gameplay?
Why is battery consumption so high on mobile devices?

Regardless of how polished the visuals or engaging the gameplay may be, persistent performance issues quickly degrade user experience and directly impact retention. In mobile game markets with significant hardware fragmentation, especially across Android devices, this challenge becomes even more critical. For global releases, the performance variance across devices is even wider, making optimization a core requirement rather than an afterthought.

This article focuses on a key objective: ensuring stable and smooth gameplay across a wide range of mobile hardware, including low- and mid-tier devices.

2. Performance from a Developer’s Perspective

In many development pipelines, performance optimization is often deprioritized during early and mid-production phases in favor of feature delivery. As a result, serious performance issues are frequently discovered late in the development cycle or just before launch, when time for resolution is extremely limited. Post-launch, these issues often translate into negative reviews and reduced user retention.

Performance should therefore be treated as a foundational engineering concern rather than a final polish step. A structured optimization mindset is essential to avoid costly late-stage rework.

From a technical standpoint, most player-facing issues—such as crashes, lag, overheating, and high power consumption—can be categorized into three core systems:

CPU performance
GPU performance
Memory management

This framework provides a structured way to analyze and resolve performance bottlenecks in Unity-based mobile games.

3. Identifying Performance Issues

The first step in optimization is accurate diagnosis—understanding not just what is wrong, but why it is happening.

Typical examples include:

Crashes after long sessions: memory leaks, inefficient caching strategies, or oversized assets consuming excessive memory
Low frame rate in scenes: excessive draw calls, high triangle counts, or expensive UI updates
Device overheating: sustained GPU overload, lack of LOD optimization, or poor device-specific quality scaling

These scenarios represent only a subset of common performance issues. In practice, root-cause analysis is often the most time-consuming and complex stage of optimization.

3.1 Profiling and Debugging Tools

Effective optimization relies heavily on accurate performance profiling. Modern game development ecosystems provide a wide range of tools across engines, IDEs, and hardware platforms.

Engine-Level Tools

Unity provides a robust suite of built-in tools widely used in production environments:

Unity Profiler (CPU, rendering, memory, UI analysis)
Frame Debugger (rendering pipeline inspection)
Memory Profiler (allocation and leak detection)

IDE-Level Tools

Platform-specific profiling tools include:

Visual Studio Profiler (Windows/macOS development)
Xcode Instruments (iOS performance analysis)
Android Studio Profiler (CPU, memory, network tracking)

Hardware-Level Tools

For deeper GPU and device-level analysis:

Snapdragon Profiler
Metal Frame Capture (iOS)
Mali Graphics Debugger (ARM GPUs)

In practice, teams often combine multiple tools or build custom profiling solutions tailored to their pipeline.

3.2 GameOptim Tooling

While general-purpose tools are powerful, they often require significant expertise to interpret correctly. In large-scale projects, dedicated analysis platforms can significantly improve efficiency.

GameOptim provides a unified performance analysis system:

GOT Online: SDK-based real-device performance data collection and visualization
Automated performance dashboards and trend analysis
System-level scoring based on large-scale optimization datasets
Actionable optimization recommendations across CPU, GPU, and memory modules

In addition, Gears (free toolset) supports developers with lightweight performance diagnostics and optimization workflows.

4. Resolving Performance Issues

Once bottlenecks are identified, the next challenge is execution: prioritizing and systematically reducing the optimization workload within limited development time.

4.1 Optimization Prioritization

In real-world projects, performance issues rarely can be addressed simultaneously. Proper prioritization is essential.

Two key dimensions are typically used:

Impact severity: how significantly the issue affects overall performance
Implementation cost: how difficult it is to fix

High-impact, low-effort issues should be addressed first, as they provide the highest return on optimization investment.

4.2 Performance vs Visual Quality Trade-offs

Optimization often involves balancing performance and visual fidelity. This requires close collaboration between engineering, design, and art teams.

Typical trade-offs include:

Reducing post-processing effects or resolution for mid/low-end devices
Simplifying models or shaders in performance-critical scenes
Preserving high fidelity for key visual moments (cutscenes, character showcases)

The optimal balance depends heavily on game genre:

Competitive or real-time games prioritize frame stability
Collection or visual-driven games may prioritize asset quality

In practice, a significant portion of performance gains often comes from eliminating unnecessary overhead rather than sacrificing visual quality.

4.3 Device Tiering Strategy

A scalable optimization approach involves defining device tiers and applying differentiated quality settings:

High-end devices: advanced lighting, high-resolution textures, full post-processing
Mid-range devices: optimized shader complexity and moderate asset scaling
Low-end devices: aggressive LOD reduction and minimal rendering overhead

This system should be continuously adjusted based on genre, user distribution, and performance telemetry.

5. Continuous Performance Monitoring

Performance optimization does not end at launch. Modern game development increasingly relies on continuous performance monitoring through:

Runtime telemetry systems
Custom engine-side analytics
Post-launch DevOps pipelines

Teams that integrate performance tracking into production workflows can reuse optimization knowledge across projects, reduce regression risks, and improve long-term engineering efficiency.

Profiling a Large-Scale 4X Strategy Game: FPS, Memory, GPU and Long-Session Performance Analysis

GameOptim — Tue, 02 Jun 2026 06:50:57 +0000

In the world of 4X strategy games, performance optimization is rarely about a single bottleneck.

Massive battles, persistent world simulations, complex UI systems, large maps, and long play sessions create a combination of CPU, memory, rendering, networking, and power-management challenges that continue to accumulate over time. Unlike many action titles, performance issues in 4X games often emerge gradually as session length, game state complexity, and resource usage increase.

To explore how these challenges manifest in practice, we analyzed Total Battle, a long-running mobile strategy title that has remained active in a highly competitive SLG market for nearly a decade. This article demonstrates how GameOptim Gears can be used to profile a complex 4X game, identify key bottlenecks, and uncover potential optimization opportunities.

Test Environment

To better represent real-world player conditions, testing was performed on a Realme 8, a mid-range Android device.
All data was collected using GameOptim Gears, which captures performance metrics without modifying game code or affecting normal gameplay behavior.

The analysis covers:

Frame rate and frame pacing
Memory consumption
GPU workload
Network activity
Power consumption

The goal is not simply to monitor performance, but to connect symptoms with potential root causes and optimization priorities.

1. Frame Rate Performance

FPS remains the most visible performance metric from a player's perspective.

During testing, the game generally maintained a target of around 60 FPS, although frame-time spikes were observed throughout the session.

A closer examination showed that most spikes were associated with UI transitions and interface interactions, with frame times occasionally reaching approximately 100 ms.

While these spikes are relatively short and may be acceptable during menu navigation, similar stalls occurring during combat or intensive gameplay scenarios could negatively affect responsiveness and player decision-making.

Key Observation

Average FPS remained stable.
Frame pacing was less consistent than frame rate.
UI-related operations appeared to be the primary source of frame-time spikes.

2. Memory Usage

Memory management plays a critical role in long-session stability, loading performance, and background app recovery, especially on lower-end devices.

At the beginning of testing, total PSS memory increased rapidly to approximately 1.77 GB before dropping significantly after a major scene transition.

This behavior suggests that resource cleanup mechanisms are functioning correctly and that large portions of memory can be reclaimed when changing game states.

However, detailed memory metrics reveal additional optimization opportunities.

Graphics Memory
The GL mtrack curve closely followed overall PSS growth, indicating that graphical assets such as:

Textures
Meshes
Rendering resources are major contributors to memory consumption.

This highlights the importance of asset loading and unloading strategies.

Native Memory
The Native Heap increased rapidly after launch, reaching roughly 900 MB and remaining at that level throughout the test.
Since little memory reclamation was observed, deeper investigation using tools such as Perfetto may be worthwhile to identify long-lived native allocations.

Key Observation
Resource cleanup appears functional.
Graphics assets account for a significant portion of memory growth.
Native memory persistence deserves further investigation.

3. GPU Performance

GPU utilization directly impacts frame stability, thermal behavior, and battery life.

Overall GPU performance remained healthy throughout testing.

The game's main city scene showed higher GPU clock activity than other gameplay areas, but still remained within a reasonable range.

Bandwidth Peaks
Several scenes exhibited temporary GPU bandwidth spikes.
One possible explanation is the use of volumetric visual effects such as clouds, fog, or atmospheric rendering.

Potential optimization directions include:

LOD adjustments
Effect quality scaling
Dynamic graphics settings
Additional Rendering Analysis

For more complex scenes, GPU Primitive metrics can provide additional visibility into geometry processing and rendering pipeline efficiency.

GameOptim Gears also supports deeper GPU analysis through metrics such as:

GPU Shaded
GPU Shader Cycles
GPU Shader Instructions allowing developers to investigate rendering bottlenecks beyond basic utilization percentages.

Key Observation

GPU workload remained generally balanced.
Certain effects may create avoidable bandwidth pressure.
More detailed shader-level analysis can reveal additional opportunities.

4. Beyond FPS, Memory, and GPU

Many performance issues originate outside traditional rendering metrics.

Network Activity
Network throughput peaked during initial resource downloads and login operations.

Although expected, these spikes can contribute to temporary increases in device power consumption and heat generation, particularly on lower-end devices.

Power Consumption
Average device power usage remained relatively stable throughout testing.

Battery drain curves showed no unusual behavior, suggesting that the title maintains reasonable energy efficiency during extended play sessions.

Key Observation

Startup downloads generate the highest network activity.
Power efficiency remained consistent during testing.
Long-session thermal behavior appears well controlled.

Why Profiling Matters

One of the most difficult aspects of optimizing 4X games is that performance problems are often interconnected.

A memory issue may trigger additional loading stalls.
A rendering bottleneck may increase power consumption.
A UI system may introduce frame-time spikes that players perceive as lag despite stable FPS.

The value of a profiling workflow is not just collecting metrics, but understanding how these systems interact.

In this case study, GameOptim Gears helped transform raw telemetry into actionable insights by:

Capturing performance data without code modification
Monitoring FPS, memory, GPU, network, power, and thermal behavior in one workflow
Visualizing trends and anomalies for faster investigation
Supporting optimization decisions based on real-device data

Notes

All results were collected from a publicly available version of Total Battle under controlled test conditions. Data reflects the behavior of a single device and test scenario and should be considered a reference point rather than a definitive benchmark for all hardware configurations.