Here is a brief introduction to the basics of common client performance:
1. Memory
The bottleneck of memory is generally caused by excessive memory, which causes APP to crash on low-end devices, and memory leaks that cause memory to skyrocket.
In response to these two problems, the first problem is to ensure that the APP is compatible with lower-end devices and can run healthily, so the running memory of the APP is as low as possible, which is more friendly to low-end devices. There is generally a threshold for this, and it is best not to have too much memory. If the threshold is exceeded (generally according to the situation of the APP itself, for example, the 2D game of the game generally does not exceed 550M), why is it set this way? Because considering low-end devices such as 2G running memory devices, the available running memory is almost 1G. If the running memory of the APP is too large, for example, if the running memory of an APP is 8~900M, then this The APP is easy to crash on low-end devices, because there is a security mechanism in the Android or iOS operating system. When the running memory of the APP is too high and the available memory of the system is too low, in order not to affect the operation of the mobile phone system, the operation The system will directly kill the currently running APP to ensure the normal operation of the phone. That is to say, the flashback caused by too much memory. Generally, running is a relatively long period of time to see if the peak value of memory is very high, and whether the average value is within a relatively stable expected range.
The second problem is memory leaks, the severity of which is self-evident. So how do you generally judge whether there is a memory leak? The first method is to use the adb command to check the memory status. For details, please refer to: Android performance analysis memory black box analysis method
The second method is a little more difficult. It is to use the profiler of Android studio to check whether there is a memory leak. For the use of Android studio profile, please refer to: hprof analysis of memory leaks
Another point that needs to be paid attention to is that the memory recovery strategy needs to be clarified. The so-called knowing yourself and the enemy is invincible. To measure the memory well, you must understand its principle. The memory recovery strategy cannot be ignored. In order to run faster, general programs will do some caching, so when will the cache be released and what data should be cached? This requires measuring the cost-effectiveness of safe operation and stalling. Under the condition of ensuring safe operation, run and cache some core data to improve the re-access speed.
2、CPU
The analysis of the CPU is mainly to analyze the logic processing performance of the APP. This is generally a bottleneck in the code logic, which causes the APP to run stuck, ANR, stuck, etc. To analyze which functions have bottlenecks in the code logic, you can use Android studio to profile and view the flame graph of the CPU process. As for how to profile Android studio, I won’t say much here, just check it out on the Internet.
3. Frame rate (fluency)
The frame rate mainly affects the fluency of the APP, and the general frame rate cannot be lower than 60 frames. Most of the devices on the market now have a full frame rate of 60 frames. If the frame rate is low, what is the reason? Under normal circumstances, the bottleneck of the APP is the CPU bottleneck, which leads to a low frame rate. In terms of CPU, in addition to the above point 2, there is another thing that cannot be ignored is frequent GC calls. We know that the memory recovery process needs to call GC. If GC is called frequently, the CPU usage will be too high, which is also very easy to cause The phenomenon of frame dropping. Generally, you can see if there are frequent GC calls by typing the log and watching adblogcat.
4. Network
Networking is also a factor that can affect performance. The network may cause delays in data requests, error reporting, setting flashbacks, etc. The conventional weak network test is a better method.
For weak network related information reference: weak network test exploration , use Network Emulator for weak network test