Shulou(Shulou.com)06/03 Report--

Background confession

Recently, in the process of running the game, QC students found that the game would flicker after playing for a long time. After collecting information, they excluded the functional bug.

one。 Determine if it is a memory leak

Get the real machine, USB connection, kill extra background processes, open Perfdog, the next operation is as fierce as a tiger, the specific operation of Perfdog is not described in detail, you can refer to the tutorial on how to use perfdog

Perfdog usage tutorial

Get the memory trend chart

Use a mobile phone

As soon as this figure comes out, we can basically conclude that there is a memory leak. This is a memory trend chart in which the game has been running for 30 minutes.

Conclusion: memory continues to rise and there is a memory leak.

In a good game, memory usually goes up and down, and running the same function many times will not cause the memory function to continue to rise.

Showing ups and downs, such as:

Knowing that there is a memory leak, let's start to analyze where the memory leak may have been caused.

two。 Analyze the cause of the leak

Generally speaking, for unity games, memory bottlenecks are resources and Mono heap memory.

The following is an overview of the memory allocation of unity game programs at runtime

Let's briefly introduce that Mono,unity uses Mono mechanism to complete cross-platform operations, just as JAVA uses virtual machines to complete cross-platform operations. Mono is also a cross-platform implementation. The principle of cross-platform implementation lies in the use of a code instruction set called CIL (Common Intermediate Language Universal Intermediate language, also known as MSIL Microsoft Intermediate language). CIL can run in any environment that supports CLI (Universal language Infrastructure), just as .NET is Microsoft's implementation of this standard, and Mono is another implementation of CLI. Because CIL can run in all environments that support CLI, such as the .NET runtime and Mono runtime just mentioned, that is to say, it is independent of the specific platform or CPU.

Generally speaking, for games developed by unity, the memory overhead revolves around the following three aspects:

1. Occupation of resource memory

two。 Engine module's own memory footprint

3. Managed heap memory usage.

Mono manages memory through the garbage collection mechanism (GarbageCollect, referred to as GC), which can automatically change the size of the heap to adapt to the memory you need, and can timely call garbage collection (GarbageCollection) operations to free memory that is no longer needed. In other words, Mono automatically frees some memory, but it is important to note that the memory released by GC is only left to mono and will not be returned to the operating system, so mono heap memory is increased rather than decreased.

Here is a brief introduction to the principle of Mono recycling:

Mono tracks the action of each memory allocation and maintains a table of allocated objects. When GC, it traverses according to the reference relationship with the objects in the global data area and the current register as the root node, and marks each object traversed as alive. The tagging of all objects means that the object can be accessed through the global object or the current context, while the unmarked object means that the object cannot be accessed in any way, that is, the object is "lost" and GC will eventually reclaim all the "missing" object memory.

Memory leak definition

We refer to an object that is no longer needed but is not reclaimed by GC as a mono memory leak. Mono memory leaks will reduce free memory, GC frequently, mono heap continues to expand, and eventually lead to an increase in game memory footprint. Eventually, the memory is too high and the process is Kill or crashed by the operating system. To put it simply, some objects are not released after they are instantiated, one is stored in memory, and the new objects need to apply for new memory space, resulting in rising memory.

Key concerns

Use of profiles, textures, meshes, RenderTexture, and particle systems

For example, whether frequent creation and destruction of objects use object pooling, or whether resources such as particles and textures are released from memory in time after display, and so on.

three。 Test means

1. First of all, run the test to determine the problem and determine the cause. For example, I determined that there is a memory leak through the running game above.

two。 Narrow the scope. Because the scene in the running process of a game is relatively complex, the same running above can not accurately locate the problem, so we need to divide the scenario test. For example, I included the following scenarios in the above running game, opening and closing the UI interface, battle scenes, switching maps, upgrading weapons, and so on. If there is no obvious data, we should test the following scenarios respectively. For example, the UI scene can repeatedly open and close the UI interface, the battle scene can continue to fight and hang up, repeatedly switch maps, etc., in short, it is to reduce the behavior in the game and refine the scene to be detected.

3. Positioning problem

If a memory leak occurs in a scene, locate the scene to run the game, and while the game is running, the corresponding engine also has some tools to check the specific code usage, such as unity's Profiler.

If memory leaks occur in multiple scenarios, it is necessary to find the intersecting parts of these scenarios, such as communication frameworks, etc., and this time, tests in multiple scenarios have found that there are leaks. Finally, it is found that there is a leak in the communication framework used.

Fourth, a brief introduction to Perfdog memory

Usually, there are four kinds of data that Android can easily access to memory, and we can also get them through ADB.

VSS-Virtual Set Size virtual memory consumption (including memory occupied by shared libraries)

RSS-Resident Set Size actually uses physical memory (including memory occupied by shared libraries)

Physical memory actually used by PSS-Proportional Set Size (proportional allocation of memory occupied by shared libraries)

Physical memory occupied by USS-Unique Set Size processes alone (excluding memory occupied by shared libraries)

Generally speaking, the memory footprint has the following rules: VSS > = RSS > = PSS > = USS

The Memory of Perfog is also known as Android PSS Memory, which is the data we usually use to represent memory, which is the actual amount of physical memory used.

Swap Memory (Swap Memory, some devices support Swap function. After enabling Swap function, the system will compress PSS memory. When Swap increases, PSS will decrease accordingly, because compression will consume CPU resources and cause FPS to decrease accordingly)

Virtual Memory (VSS) virtual memory is a technology of computer system memory management. It makes the application think that it has continuous available memory (a contiguous and complete address space), when in fact it is usually separated into multiple physical memory fragments, and some are temporarily stored on external disk storage for data exchange when needed.

V. A preliminary study on the new functions of Perfdog

PerfDog 3.5 has just been launched, adding a new value, CPU Usage (Normalized): normalized CPU utilization

The official explanation is:

Traditional calculation method: at the current time CPU frequency, CPU Usage = CPU execution time / CPU total time.

Due to the constant change of the CPU frequency of the mobile device, using the traditional CPU utilization calculation method, it is assumed that the CPU utilization ratio is 30% at the low frequency time, and the CPU utilization ratio is 30% at the CPU high frequency time. It is also 30%, but the performance consumption is completely different, and the high frequency consumption is obviously higher. Traditional CPU utilization can no longer truly reflect performance consumption.

So we need a standardized (quantifiable) statistical method. Take frequency into account.

CPU Usage (Normalized) = (CPU execution time / total CPU time) * (sum of all CPU frequencies at the current time / sum of maximum values of all CPU frequencies).

There are two statistical methods of PerfDog. CPU Usage defaults to normalizing CPU utilization. It is recommended to use normalized CPU utilization as a performance metric.

For a specific description, please see here: standardize CPU utilization

Try something new and experience it. The test usage process is the same as before. Let's take a look at the new data comparison.

Title:

CPU Usage trend chart comparison:

CPU Core Usage trend chart comparison:

From the perspective of the trend chart, in fact, there is not much difference between the two algorithms, but when it is accurate to the utilization rate of specific frames, the difference will be more obvious. purely from the point of view of performance, the traditional CPU utilization can only reflect the CPU utilization of the phone from a numerical point of view, but it can not express the CPU utilization efficiency of the phone from the perspective of performance usefulness. As mentioned earlier, the CPU utilization is calculated to be 30% at low frequency. And calculate the CPU utilization = 30% at the high frequency of CPU. It's also 30%, but the performance consumption is completely different. Normalizing CPU utilization values can make up for this shortcoming. At present, the testing industry is intermingled with the good and the bad, and there are few normative indicators, so it is a good thing if we can really achieve a unified industry standard.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.