Integration and arrangement of some resource standards and performance optimization points of Unity

Table of contents

zero, total

Eight, mobile terminal performance optimization experience

zero, total

Optimization ideas:

1) Specify the specifications of related resources with art

2) Code framework, reasonable management of resources, use of multithreading, use of object pools, optimization of algorithms, try not to use some APIs frequently in Update, UGUI development rules, etc. in code development

3) Finally, after the development of the application together, use the profiler and frame debugger to analyze the most performance, and optimize the points that were not considered before

Performance analysis tools:

1）Unity ： Profiler、FrameDebugger、PhysicalDebugger

2) Android Studio 、IOS XCode

3) Third party: UWA, etc.

1. Model

Key points: the sole of the character at the origin of the modeling, and the center of other objects according to the situation. The number of faces on the mobile terminal is recommended to be less than 1,500, and the number of faces on the same screen should be less than 50,000. Breakpoints and isolated points should be eliminated. According to the scene, occlusion removal and LOD technology can be used;

1. It is best for all character models to stand at the origin. If there is no specific requirement, the center of the object must be the axis.

2. Control of the number of faces. Controlling each mesh model of mobile devices to 300-1500 polygons will achieve better results. However, if a large number of characters appear on the screen at any one time in the game, then the number of faces per character should be reduced.

General situation: Normally, a single object should be controlled below 1000 faces, and the entire screen should be controlled below 7500 faces. All objects have no more than 20,000 triangular faces.

3. Organize the model file, check the model file carefully, try to optimize it as much as possible, delete unnecessary faces where you cannot see, merge disconnected vertices, remove isolated vertices, and pay attention to the naming convention of the model. A reset transformation must be done before the model can be rigged.

4. Copy the objects that can be copied as much as possible. If a 1000-sided object is baked and copied 100 times, then the resources it consumes are basically the same as the resources consumed by one object.

5. According to the situation, occlusion culling and LOD technology can be used

6. Try to build a model and a material for large scenes, which is convenient for batch processing

7. Multiple single-open models and common materials can be merged with mesh, which is convenient for batching and reduces drawcalls

2. Pictures

The key: the size of the mobile terminal is 1024 and below, turn off unnecessary reading and writing functions, turn off mipmap in the UI, turn on mipmap in the model according to the situation, use the image compression tool to compress the original image properly, and use the atlas reasonably for batch processing, no Use jpg for alpha channel, use png for alpha channel

1. The texture file size must be 2 to the Nth power (8, 16, 32, 64, 128, 256, 512, 1024). The maximum texture size cannot exceed 1024x1024, and the size can be adjusted within these ranges under special circumstances.

2. Turn off unnecessary Read/Write Enabled;

By default, the texture is loaded into the memory, and when submitted to the GPU, a copy is copied to the video memory, and this copy in the memory will be deleted. If you check the Read/Write Eanbled option, the memory corresponding to the texture will not be deleted, and you Texture.GetPixelscan Texture.SetPixelsread and write through APIs such as and , but the problem is that the extra memory is doubled.

3. Close unnecessary Generate Mip Maps according to the situation;

When checked, a multi-level progressive texture Mip Map will be generated to adapt to trilinear sampling and solve the problem of moiré caused by textures being mapped to smaller-sized surfaces. Excess 1/3 memory.
Suggestion
1) UI texture should be turned off; 2) Other textures depend on the situation, such as textures of models that may appear far away from the camera, you can check it to obtain a better display effect when the distance from the camera is far away.

4. Reasonable use of atlas, sprite packer, texture packer ( TexturePacker - Create Sprite Sheets for your game! )

5. Use jpg if there is no alpha channel, use png if alpha is required

3. Audio resources

1. Use wav for short audio, and compressed MP3 for long background music;

If you use any compressed format like MP3 or Vorbis, Unity will decompress it and recompress it at build time. This results in two lossy passes, reducing the final quality.

2. For load type, Decompress on Load should be used for small clips (< 200 kb short audio). Decompressing the sound to raw 16-bit PCM audio data incurs CPU overhead and memory usage, so this only works for short sounds.
Medium clips (>= 200 kb long audio) should be kept Compressed in Memory.

3. When implementing a mute button, don't just set the volume to 0. The AudioSource component can be destroyed, unloading it from memory so the player doesn't need to toggle the switch too often.

4. Reasonably control the AudioSource component, you can use the object pool technology to control the quantity reasonably

4. Lighting

1. Control the number of real-time lights

2. Use lightmap lightmap

3. Shadows also take up a lot of performance, cancel unnecessary shadow reception and projection

5. Collider

1. Simplify the collision body; use Mesh Collider as a collision body as little as possible

2. Move the physics body in FixedUpdate

3. The default Fixed Timestep in Project Settings is 0.02 (50 Hz). Change this according to your target framerate (eg 0.03 for 30 fps).

Otherwise, if the frame rate drops during runtime, meaning that Unity calls FixedUpdate multiple times per frame, it may cause CPU performance issues due to excessive physics content.

4. Use physical debugger to realize visualization

Six, font

1. Necessary cutting of the font library, keeping commonly used fonts, and removing unnecessary fonts

One, UGUI

1. Separation of static and dynamic. Canvas and child canvas, note that parent and child canvas will not be batched together

In the case of large canvases with tens of thousands of elements, updating a single UI element would have to update the entire canvas, which could cause a CPU spike.

Utilize the function of UGUI to support multiple canvases. Divide UI elements according to their update frequency requirements. Keep static UI elements on separate canvases and dynamic elements that update at the same time on smaller sub-canvases.

Make sure that the UI elements in each canvas have the same Z value, material, and texture.

2. Limit GraphicRaycaster and disable Raycast Target

Input events such as touch or click on the screen require a GraphicRaycaster component. It just loops through each input point on the screen, checking to see if it's within the UI's RectTransform.

Removes the default GraphicRaycaster from the top canvas of the hierarchy view. Only add a GraphicRaycaster to each element that requires interaction (buttons, scroll rectangles, etc.).

Also, disable the Raycast Target on all UI text and images that do not require it. In the case of a complex UI with many elements, all these small changes can reduce unnecessary calculations.

3. Avoid using layout group layout

Updates of layout groups are inefficient and should be used sparingly. If the content is dynamic, avoid it altogether and use anchors for proportional layout instead. Alternatively, create custom code to disable the Layout Group component after it sets the UI.

If dynamic elements do require the use of layout groups (horizontal, vertical, grid), nesting them should be avoided to improve performance.

4. Large list and grid views are expensive. For example, scrollview can reuse the items in it

If you need to create a large list or grid view (such as an inventory screen with hundreds or thousands of items), consider reusing a smaller pool of UI elements instead of creating UI elements for each item.

5. Avoid heavy use of overlapping elements

Layering large numbers of UI elements (such as stacked cards in a card game) can cause overdraw. Custom code merges hierarchical elements into fewer elements and batches at runtime.

6. When using the full-screen UI, hide all other content, and disable 3D scene rendering if necessary.

Disables the camera's rendering of the 3D scene if the pause screen or splash screen obscures everything else in the scene. Likewise, disables any background canvas elements hidden behind the top canvas.

Since you don't need to update at 60 fps, consider lowering Application.targetFrameRate during full screen UI.

Assign cameras to world space canvas and camera space canvas

Leaving the Event or Render Camera fields empty causes Unity to fill Camera.main, which causes unnecessary overhead.

Make the canvas RenderMode use Screen Space - Overlay as much as possible so that no camera is needed.

Eight, mobile terminal performance optimization experience

CPU-side performance optimization

Logic and performance are separated as much as possible, so that the update frequency of the logic layer can be appropriately reduced.
For some hot functions, such as mmo entity update and instantiation, use frame processing to allocate single frame time consumption.
Do a good job of optimizing the number of entities on the same screen, the number of special effects, and the distance between display and hiding.
Improve log output, avoid unnecessary log output, and be wary of log string splicing.
Use bone baking + GPUSkinning + Instance to reduce CPU skinning bone consumption and drawcall.
Turn on the Optimize GameObjects of the model to reduce the number of nodes and skin update consumption.
The UI is prefabricated and separated from static and dynamic. For UIs that change frequently like the name of the blood bar, proper grouping is done.
Reduce the frequent interaction between C# and Lua, and try to simplify the parameter structure passed by the two.
Use stringbuilder to optimize the gc problem of string splicing.
Delete non-essential script functions, especially Update/LateUpdate high-frequency execution functions, because it will generate call overhead from C++ to C# layer. Cache the components and nodes that need to be used in Update in advance.
Do resource reuse and object pooling for frequently used resources or data structures in the scene.
For the UI that is frequently displayed and hidden, it can be moved out of the screen first, and then Deactive if it is not displayed for a long time.
Reasonably split the UI atlas, distinguish shared atlases and non-shared atlases, shared atlases can be resident in memory, and non-shared atlases are preferentially classified by function to avoid resource redundancy.
Using IL2CPP, compiling to C++ version can greatly improve the overall performance.
Avoid using Material.Setxxx/Getxxx and other calls directly, these calls will trigger material instantiation consumption, you can consider using SharedMaterial / MaterialPropertyBlock instead.
Merge Uniform variables in Shader.

Excellent GPU performance

Reasonably plan the rendering order to avoid unnecessary overdraw, such as: terrain (easy to be blocked by other objects), and skybox to be rendered later.
Resolution scaling, which is the simplest and most efficient when there is a bottleneck in the fill rate.
Avoid using GrabPass to capture the screen, not all hardware supports it, and the performance of copying back data and unable to control the resolution is very poor, you can consider using CommandBuffer.blit to optimize.
Control the number of blend layers of the terrain, and control it within 4 layers. Considering that the terrain generally has a large screen area and a large number of texture sampling times, normalmap is not considered for medium and low image quality.
Do a good job of LOD for objects, trees, and characters.
Avoid using the RenderWithShader class to customize DepthTexture, you can consider Camera's public void SetTargetBuffers(RenderBuffer colorBuffer, RenderBuffer depthBuffer); for optimization.
Check whether there is redundant data in Shader's VertexInput and VertexOutput. Such as: vertex color, multiple sets of UV.
Be wary of non-essential double-sided materials in the project, and solve the problem by adding a side where partial double-sided materials are required.
Shader uses fixed and half instead of float. In theory, except for position, uv, and some depth-related calculations that use float, others should use fixed (mainly color values), half.
For less obvious effects such as character skin, consider using a low-cost solution such as pre-integration.
For the calculation process in frag, if it can be extracted and placed in the CPU application layer, the vertex stage is prioritized here for calculation. It is necessary to pay attention to the smooth transition problem caused by putting it in the vertex stage. For example: eyeVec causes highlight transition problems.
Avoid using reflection camera + RT for mirror reflection effects, and consider using SSR and CubeMap classes.
Avoid using real-time shadows, if you do use reasonable control over resolution and shadow distance. Consider using Projector.
Using a unified post-processing framework instead of multiple Image Effects can share blur functions and reduce blit operations. In addition, Unity's own Postprocessing V2 supports Volume, and its performance is still good.
Avoid complex mathematical operations such as branches, loops, sin, tan, pow, and log in Shader.
Unity's built-in occlusion removal is not suitable for mobile platforms because of its high CPU consumption and memory usage, and it cannot be Instancing. You can consider static precomputation (the disadvantage is that it does not support dynamic objects), Hi-Z and other optimization solutions.
Reduce the use of alpha test materials. If you use it, pay attention to reducing the area and controlling the rendering order.

memory optimization

Be wary of the memory footprint of configuration tables.
Check ShaderLab memory usage:
Avoid using Standard materials, and do a corresponding variant skip.
Troubleshoot project redundant Shader.
Use shader_feature instead of multi_compile, so that only the variant combinations actually used in the project are collected to avoid doubling the variants.
Check whether the size, format, compression method, mipmap, and Read & Write options of the texture resource are reasonable.
Check whether the Read & Write option of the Mesh resource and the use of vertex attributes are reasonable.
Code-level inspection, such as Cache pre-allocation space, container Capacity, GC, etc.
Use Profiler to locate GC, especially in Update class functions. Such as: string splicing, abuse of containers, etc.
Reasonably control the size of RenderTexture.
Optimize the animation compression method, floating point precision, and remove the Scale curve data inside.
Reduce the number of GameObject nodes in the scene, and it is best to support tool monitoring.

references:

1. Mobile Game Optimization Guide | Unity Chinese Classroom