First of all, for large projects, a certain UGUI is the preferred UI, and there is currently no room for choice. A little more is a burden on performance. The bottom layer of UGUI is based on multi-threading technology, which can effectively share the pressure, and it is almost insensitive to some panels that are not so heavy.
No matter other panels are only modified on this basis, but every additional layer, the computer will inevitably have to calculate one more, so the current optimal solution must be UGUI.
In the past two days, I have been frequently asked about panel optimization. I have done everything that should be done but it still doesn’t work. What should I do if I can’t meet the requirements?
UGUI performance problems are generally divided into four types:
- Canvas batch-build is too long, usually a drawcall problem
- Canvas Over-dirty too many times, frequently destroyed and created
- Generating UI mesh vertices takes too long
- GPU fragment shader utilization is too high
UGUI's drawcall is done by c++, so we should use batching as much as possible for the pictures under the same canvas, no matter it is static batching or dynamic batching, to reduce drawcall and improve efficiency
Batch process:
Sort according to the depth of the UI panel
Check the covering relationship of UI panel pictures
Check the material for batching of the same material
The above is completed in the c++ part of unity, so for lightweight panels, it is generally insensitive to open, and can be opened very smoothly
Usually, UGUI drawing atlas is a technical solution to cover up all ugliness. It is easy to use and very efficient.
In order to avoid the problem of panel stuck and optimize the UI , it is necessary to establish rules before building the panel:
1. Separation of static and dynamic. Creating two Canvas panels will be drawn dynamically, possibly triggering a refactoring of the panels separated from the static panels
2. Move all the panels that may interrupt the batching to the bottom layer, and make the panels mutually exclusive, so as to avoid overlapping of useless UI panels
3. Instead of using the Layout component, it is best to use the code to manage it yourself
4. Try to use the Overlay mode in RenderMode of Canvas
5. Instead of using the Text component, use the TMP (TextMeshPro) component instead
6. Close the useless component system on the panel as much as possible (such as closing Raycast Target, try to open it only on the bottom panel)
7. For nested Canvas, the OverrideSorting attribute will interrupt the ray, which can reduce the level of traversal
8. Try not to use Find to search for UI objects, and do a good job of labeling to search
9. Art pictures should not have transparent parts as much as possible, and the picture format should be divisible by 2
10. At least a simple understanding of UGUI features and font issues
11. The font should not be too small, otherwise it may cause frequent rebuilding
12. Use Font.RequestCharacterInTexture to preload fonts to reduce startup time
13. For the invisible UI, do not use the transparency of the UI to switch the display, because it is actually still drawing
14. Reasonably use the OnDemandRendering interface in the non-full-screen dialogue mode, and reduce the frequency reasonably
15. Optimize UI Shader clipping, and remove redundant parts reasonably as needed
16. Reasonable use of object pools and dynamic atlases for the backpack mall, and reasonable caching
17. Load the backpack mall by frame
18. Reasonably design the opening method of the panel, and cache the heavy interface in advance
19. Use the RectMask2D component to clip, remove unnecessary parts for rendering, and use a regular sliding list
20. The ultimate trick is to look for art to reduce the quality of the picture, and to find the planner to reduce the function (the only way to do it if there is no cure)
21. Appropriately redesign the opening method of the panel to reduce pressure and burden
22. You can also change your own UI management mode framework according to the UGUI source code
The above are the rules and the main points of UGUI optimization
If all of these are done, it may be necessary to rule out whether the design of other parts is reasonable, whether it affects the panel, and there is a lag
Non-combat, if it does not affect the user experience, you don’t need to optimize it. Generally, the number of frames is not less than 20-30 (it’s fine if the user doesn’t feel it)