Unity Hand travel memory optimized sharing

http://blog.csdn.net/flxzs7/article/details/51578223

http://gad.qq.com/college/articledetail?cid=3039

Here we share the memory optimization experience from three latitude: code level, mapping level, frame design level.

A. Code level.

1.foreach.

The use of foreach under mono requires caution. Frequent calls easily hit the heap upper limit, causing the GC to trigger prematurely, and the phenomenon of Kaka.

In particular, do not use foreach if it is not necessary in the update. Use for instead of foreach whenever possible. A GC Alloc is generated, stating that the foreach call GetEnumerator () has heap memory operations, new and Dispose.

2.string modification.

If you are familiar with C + +, you will understand that every time you use a string, you create a new string object in memory and you need to allocate a new space for that new object. In particular, the need to modify the string object in the loop, will be frequently allocated new space, it is recommended to use stringbuilder.append and other operations to deal with. In C + +, it is often an operation to handle strings by assigning a fixed character memory.

3.gameobject.tag

Gameobject.tag will invoke the tag properties of the object assignment and copy additional memory in the internal loop, it is recommended to use Gameobject.comparetag ("XXX") instead. Tag.

4. Use the Objectpool object pool to manage objects and avoid frequent instance,destroy.

Two. Texture level.

The memory optimizations on the code are much less than the optimizations on the map at a large level. Sometimes changing a picture will save you a few megabytes of memory.

1. Adjust the size of the graph by adjusting the texture resources. For example: through the 9 Gongge, partially narrowed after unity in the way of pulling the big.

For example: (mainly adjusted two small elements) to save half of the memory.

Optimized before optimization

The 2.Ios platform uses PVRT to compress textures. The Adroid platform is compressed using the ETC1 format. can be reduced to 1/4 of the memory size. Optimization is very obvious.

Currently, mainstream Android models support ETC1 format compression. However, ETC1 can only support image compression for non-alpha channels. Therefore, the alpha channel diagram is generally separated out, when plotted to GPU memory, a value is obtained from the Alpha graph, no alpha channel diagram can be used ETC1 compression.

While the format compression above ETC2 supports images with alpha channels, the supported models are relatively small. Not recommended for use at this time.

The size of the memory footprint 1024*1024 before using ETC1 compression occupies 10.7M (contains the memory footprint in editor and the MIP Map memory footprint).

Mipmap is an effective way of using memory for performance in 3D games, where cameras are far away from each other in different pictures. It turns a large map into small plots, stored in memory, and when the camera is far away, just use a small map.

UI, 2D scene can remove texure this setting.

In this way, the image of the uncompressed texture 1024x1024 in the actual game occupies 4M in memory. (The Unity Profiler should look at 8M)

With ETC1 compression, the scene picture has a size of only 1.3MB, plus the channel graph 2.6M. It is almost used for 1/4.

Even the size of the file is 1/4 smaller.

3. Reduce the image size by subtractive way. Many UIs actually use very little color, less than 256 colors. This type of image can be subtractive compression.

Three. Frame design level.

A relatively large game, the system is very much. At this time, reasonable and timely release of memory to help the game's normal experience, and even prevent the memory to reach the peak quickly, causing the device crash.

Current main platform models available memory:

Android platform: The following memory consumption indicators (PSS) are required for the minimum configuration of the client:

1) Memory 1G The following models: up to PSS<=150MB

2) Memory 2G models: up to PSS<=200MB

iOS platform: Runs under Iphone4s, consumes memory (real mem) less than 150MB

1. Avoid spikes when switching scenes.

When the current scene is not released, switch to the new scene. At this time, memory spikes are easily achieved due to two memory overlays. The solution is to mask a loading scene in the middle of the screen. After the old release, and after the new initialization is over, hide the loading scene so that it effectively avoids a large overlay of memory over the peak.

2.GUI module joins life cycle management.

Lead, reinforcement, skills, mall, evolution, backpacks, quests, and more. Usually a game has these systems. But if all is open, or at this time point to the world map, plus some logic data memory occupancy and so on. You will find that the memory is also very fast peaking.

The effective management system module life cycle is very necessary. First, the modules are divided:

1) often open cache_10;

2) occasionally open cache_5;

3) open only once cache_0.

Create a Modulemananger class, and the internal render method polls every minute. If it is "cache_0" this type, a close directly destroy free memory, "cache_10" This type of 10 minutes after the automatic release of Memory, "cache_5" This type of 5 minutes after the automatic release of memory. Each time the module is opened, the module will be re-clocked. This makes it possible to allocate memory efficiently and rationally.

Just write it down for the time being. Thank:)