Reduce Texture Size

Large texture sizes will increase memory consumption and GPU bandwidth usage.

The maximum texture size recommended is 1024x1024 pixels. How can we decide whether to use a large or small texture size, you may ask?

The answer is to consider the object's volume in the World. For example, if it's a small stone in the World, use a smaller texture size (128x128); if it's a large building, use a larger texture size (1024x1024). You can refer to the concept called Texel Density, which is calculated as follows: Texel Density = Texture Resolution/Object Size

Reduce the Number of Meshes

In Unity, each mesh can consist of multiple submeshes, and each submesh generates 1 or more additional draw calls. Draw calls mean that the CPU calls graphics APIs (such as OpenGL) to ask the GPU to draw something. Generally, the higher the number of draw calls per frame, the higher the CPU consumption per frame.

Therefore, we recommend that you use 1 Mesh Renderer and no more than 3 Mesh Renderers for each mesh. You can combine multiple Mesh Renderers into one in your modeling software.

Reduce the Number of Mesh Triangles

Make sure you don't use too many triangles. The SDK will warn you if you try to upload a mesh with triangles that exceed the upper limit (see World Asset Specification). You rarely need too many polygon details. You can consider baking a normal map and simplifying your mesh by decimation or retopology.

Too many mesh triangles will cause poorer rendering performance of the World and affect the user experience of all players. We recommend minimizing the number of triangles in the model in the modeling software.

Use Less Materials

If multiple materials are associated with a mesh, many draw calls will be generated at runtime, and each submesh component used in Unity will correspond to a separate material. We recommend that you merge multiple textures into 1 texture atlas and combine multiple submeshes into 1 mesh to reduce materials.

Use Simpler Shaders

Complex shaders will increase the GPU cost for rendering frames. The more shader instructions per pixel, the longer it takes to render a pixel, resulting in a longer frame duration.

The number of shader instructions increases with that of mathematical functions, and certain operations have higher costs. When you build complex shaders, try to limit the number of instructions as much as possible.

Use Opaque Materials

We recommend that you use opaque materials unless you are sure that transparent materials should be used. Transparent materials often require more GPU computing resources to draw. Using opaque materials will bring your World a better rendering effect.

Set up the side of materials for Culling

You can configure materials to set a component of the model to be visible on the front or back, or both. We recommend that you render one side of the component, as rendering both sides usually requires more GPU computing time.

Reduce the Use of Alpha Tested Materials

We recommend that you use opaque materials unless you are sure that transparent materials should be used (for example: leaves). Moreover, try not to use alpha tested materials as they are incredibly unfriendly to the binning rendering mechanism on mobile terminals and will decrease the efficiency of GPU rendering. Reducing or avoiding the use of alpha tested materials will bring your World a better rendering effect.

Reduce the Number of Particles Emitted

While particle systems can generate a lot of cool effects, excessive particle systems can cause problems on some computers. We recommend that you limit the number of particle systems applied and set an upper limit of particles emitted at any particular moment.
There are some ways to ensure that a particle system has a large number of particles without compromising performance. For example, you can use dynamic batching of sprite particles; don't use collisions, and make sure your particles' motions are simple.
For more information about relevant technology, please refer to Unity's Profiler view to gauge how much CPU time your particle simulations require. In general, we recommend that you use many small and opaque particles rather than large transparent particles. Unity's particle system is quite excellent and runs fast if used appropriately.

Reduce the Use of Real-Time Lights

If lights in your World are in real-time mode, the cost to ensure performance is very high. Adding lights to your World means that everything your lights touch will be rendered with double draw calls. Extra lights will also double the rendering time. This is obviously detrimental to performance. Do not use lights that are always on. You can use an animation override to turn the flashlight on and off, or don't use lights at all.
If you use lights, disable the shadows. Shadows from real-time lights are very expensive and usually won't look very good on moving objects.
Particle systems allow you to turn on lights on only some particles. Never do this! The lighting for every particle is regarded as a real-time light, which is (again) very expensive.
In general, we recommend that you do not use lights of any kind in your World. Not only do they adversely affect the performance of your own World, but they can also multiply the cost of attrition when an object is lit.

Reduce the Use of Dynamic Shadows

Objects in the World can have 2 types of shadow: dynamic shadow and static shadow. Static shadows result from offline baking and do not incur additional costs at runtime, while dynamic shadows are generated during each frame rendering and are very expensive on mobile devices.

Therefore, it is strongly recommended that objects cast static shadows and minimize or avoid the use of dynamic shadows in the World.

Reduce the Number of Post-Processing Effects

Post-processing indicates pixel-level processing of the entire screen, and its cost is closely related to the resolution. Higher resolutions require processing of more pixels, and excessive post-processing effects can result in high GPU overhead. This may become a bottleneck on mobile devices with high resolutions but poor GPU computing capability.

Optimize Physical Efficiency

Avoid using mesh colliders in the World as much as possible because they are less efficient than basic shape colliders (such as box colliders and sphere colliders). If mesh colliders are required in certain cases, try to use convex mesh colliders whenever possible, as non-convex mesh colliders are the least efficient and must be the last choice considered.

Optimize from Day 1

If you want your World to run smoothly at 60 frames per second (FPS) on all mobile devices, aim at this goal throughout the entire development process. You don't have to maintain a constant rate of 60 FPS, but pursue at least 50 FPS for at least 80% of the time, even in the early stage of World development. This will ensure that your World performs well consistently and avoid performance crises near the end of development.