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

Most people do not understand the knowledge points of this article "what is the PSS/RSS/USS of Unity?", so the editor summarizes the following content, detailed content, clear steps, and has a certain reference value. I hope you can get something after reading this article. Let's take a look at this "what is the PSS/RSS/USS of Unity" article.

The test results of PSS on different mobile phones are different.

USS = memory exclusive to the process

RSS = USS + shared memory

PSS = USS + shared memory / number of processes sharing this memory

Therefore, due to the addition of shared memory, the value of PSS is very unstable and has something to do with the system and version of the phone. Because shared memory also needs to be divided by the number of processes, it even depends on the number of software you install and the number of runtime daemons.

Therefore, the PSS tested by any mobile phone in your home is likely to be different from the PSS tested by Tencent, so you can't rigidly compare Tencent's standards.

The right thing to do is to prepare a fixed test environment, and then submit a version to Tencent to get the difference between the two PSS. Then subtract this fixed difference from subsequent local tests.

Or, use Tencent's own games as a comparative reference, lower than them.

Tencent's can, why not yours?

Is it scientific to use PSS to determine the memory footprint of an application?

When a process is killed, the amount of memory released is USS.

All memory, stack / stack / texture data, etc., actively requested by the application itself belongs to private dirty, that is, USS. Shared memory is not the concept of a common library. You use a common library to create a new object in the scope of the common library, and that part of the object still belongs to USS.

Shared memory allocation is somewhat similar to "static data" or "code", and applications can only read but not write to it. If you want to write, you must first copy a copy to USS. So according to our conventional understanding of "memory allocation", USS is all the memory occupied by a single process.

Therefore, it is scientific to use USS to determine the memory footprint of an application. I think the extra "share dirty / progress number" part of PSS makes no sense at all.

PSS looks so unscientific, why take it as a limitation?

The Android task manager shows that the app's memory footprint is PSS. It is not certain whether the system uses it as a management benchmark.

USS cannot be obtained by an external process in the case of non-Root. Maybe it was for the convenience of testing.

There is no "why" in many things, you can only accept it. And in an isolated environment, PSS testing is really not a problem, because the game developed by the same engine at the same time, the part of PSS that is more than USS is probably a fixed value, and the standard should add this fixed value accordingly.

How do I get PSS and USS?

Although Unity's own Profiler is fine in most cases when controlling memory--

But Unity does not count all memory usage. We can be sure that all additional C code libraries that apply for unmanaged memory themselves will not be counted, including lua. In addition, the memory requested by the platform channel will not be taken into account.

If you are only in control of memory, it is almost enough to look at the separate memory statistics of Unity's Profiler and Lua. But things like channel code and voice library, although there is nothing we can do about them, after all, they are tied together, and we must spare the corresponding memory for them, so we still have to care about the memory usage of the whole application (but the result of Unity Profiler should also be concerned about, because it is universal).

It is obviously more convenient to be able to present it through the game interface than to view it with adb.

The way to get in-memory data within the application is Debug.getMemoryInfo.

Debug.MemoryInfo localMemoryInfo = new Debug.MemoryInfo (); Debug.getMemoryInfo (localMemoryInfo); localMemoryInfo.getTotalPss (); localMemoryInfo.getTotalPrivateDirty (); / / USS

If you don't program, you can use the adb tool to check

Adb shell dumpsys meminfo process name

(note that privte dirty is USS in the result)

What can the acquired real-time PSS/USS be used for?

It is mainly used for reference when Debug. For operational efficiency, it is best to turn off this feature in the release version.

But... It can also help you ensure that the upper limit of the platform PSS is tested. Instead of worrying about occasionally exceeding the prescribed PSS limit and fearing to reduce the number of resources, let go and forcibly reclaim memory when you are about to reach the PSS limit. When it is not enough, you can even prohibit the loading of new resources and replace them with blank objects, only to ensure that the game logic can be sustained.

Although this is only for testing, in the actual running of the game, if there is a lack of memory, this "give up the game experience" is also a way, after all, it is better than the application crash.

How can we prevent our applications from collapsing due to insufficient memory?

Getting the value of PSS/USS does not help us do this.

Because the operating system does not kill a process because it takes up a fixed amount of memory (let alone the total amount of memory varies from device to device), the operating system will only kill the foreground process in order to ensure system security when there is a serious shortage of memory and there is no background process to kill.

So what we need to do is to try to reduce the memory footprint and even sacrifice the experience when there is really not enough memory. The specific measures are as follows:

Execute GC

Recycle resources, delete cache, delete preloaded content

Lower the level of picture quality

None of the above is valid. The loading of new resources is rejected.

Require users to restart the application

Timing of execution:

One way is to obtain the current system's remaining memory in real time and process it.

The code of a famous game MemoryInfo:

AvailMem current system remaining memory

Standard of threshold "low memory"

LowMemory when availMem

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.