Today, we will share some knowledge points related to resource memory leak. A memory leak is the most common issue that we continuously see and also are afraid of. What is the reason behind it? Because we can’t predict the extent of the leak before we locate the leak bottleneck, we had no idea whether it will burst out at a certain moment on the line. We have received feedback from developers that their players had no problem playing for half an hour, but they would get more and more stuck after 3 to 4 hours of playing, which they never expected before. How can it be solved? Today’s sharing will answer such questions.
UWA’s GOT Online-Assets report has a resource occupancy trend chart. If there is a rising trend like the one below, you must pay special attention.
Or something like this: a phased increase
The specific reason for this situation is likely to be that the R&D team caches the loaded resources (for example, put them in the Container), but does not remove or clear them when the scene is switched, so whether it is the engine itself or manual calls relevant APIs, such as .UnloadUnusedAssets cannot load this part of resources, causing resource leakage. Here, we will introduce our common logic for troubleshooting resource memory leakage.
1. Pay attention to the life cycle of resources
That is to understand the scope of use of each resource during the project running. On the [Resource Details] page of the report, we can see the resource information that appears while running. Check the specified resource, you can see its loading and unloading scene in the life trend chart.
This function is mainly to help you quickly check which resources are “resident” in memory, and to determine whether the resource is a “preloaded” resource or a “leaking” resource. Common Loading images and Login images (as shown in the figure below) often take up a large amount of memory, for which we suggest that there is no need to make resident memory.
2. The specific method of checking the leak>>Scene/frame resource comparison
Under normal circumstances, the number of resources in a project is hundreds or thousands. How to check for leaks more scientifically? We recommend the following ways to compare resources in order to find resources with “leakage” problems more quickly:
1) Comparison of the same type of scene/same scene: focus on different resources
The use of resources in the same type/same scenario is generally relatively fixed. We can compare the resources with differences of the same type/scenario at different times, and only need to judge whether the existence of these different resources is reasonable, and then we can quickly determine whether there is resource leakage and which resource is leaking.
2) Comparison of different types of scenarios: focus on the same resources
In addition to resident resources, the resources used by different types of scenarios are completely different. We can compare the same resources in two different types of scenarios to determine whether it is a resident resource. If it is not, it is likely that the resource is leaking.
3) Comparison between different frames
In addition, we can also check whether the common/difference resource is reasonable between different frames.
As long as you find the right method and accurately locate the problem, the problem can be fixed very quickly.
It is also important to have long-term test cases to avoid leaks. In many cases, some teams only run the test for 10 to 15 minutes for convenience. In fact, these test samples are far from enough. We have to try our best to restore the player’s real scene and do as much testing as possible during the optimization phase.
Of course, the more preferable method is to use some automated scripts to perform regression testing, such as 30 minutes for novices, long hang-ups for dungeons, etc. Most of these can be replaced by automated scripts, and the Pipeline service that UWA has launched supports many Terminal automated testing that can also fit the needs of such long-term testing.
Use cases for pushing pictures in moderate to heavy card games.