Engineering & performance / DIJION
How to set a visual asset budget for mobile products
An inventory separating file size, resolution, memory and visible use so that visual quality can be assessed against device conditions.
A small image file does not necessarily use little memory at runtime. Package size, transfer time, decoded image memory and rendering cost are different concerns. A budget defined only as Compress all images leaves the problem being solved unclear.
Start with a usage inventory
Record where an asset appears, its displayed size and how many instances are visible together. A list thumbnail and a full-screen game background have different needs. If duplicated files exist, measure how reuse affects both package size and memory.
Scroll the table horizontally to see all columns.
| Field | Information to record |
|---|---|
| Identity and purpose | Screen or scene using the asset |
| Source size | Pixel dimensions and file size |
| Display | Rendered dimensions and density needs |
| Runtime | Measured memory and loading behavior |
| Concurrency | Copies visible at the same time |
| Quality boundary | Unacceptable blur or distortion |
Separate the file from the decoded image
Android’s bitmap guidance discusses loading large images at a suitable target size. A compressed file and its in-memory representation differ. In a game engine, texture format, additional levels and platform support can change the cost. Avoid applying one file-size limit to every engine.
Choose a format for the actual use
Flat interface artwork, photographs and transparent characters need different decisions. Inspect edges, embedded text and transparent transitions against the real background. A smaller file does not always mean better loading or decoding on every device; evaluate support and visual quality together.
Connect the limit to an observed problem
Instead of inventing a universal kilobyte target, identify the assets required by the first screen and their behavior on the test device. If a list opens many full-resolution images at once, evaluate appropriate smaller versions. Investigate the lifetime of off-screen resources too.
Compare within the same scene
- Open the same screen with the same data and record starting conditions.
- Change the size or loading policy of one asset group.
- Inspect memory, loading and visible quality together.
- Leave and reopen the scene; resources that should be released must not accumulate.
This is a preparation plan, not a reported performance result. Record which device and quality boundary justified the budget. That makes visual quality and technical cost part of the same decision.