Finally here comes the iOS memory and performance optimization guide for small games! Recommended collection

Preface

Since the WeChat mini-game normal mode is a solution based on the C++ rendering layer and JS compilation engine to simulate the rendering capabilities of HTMLCanvas on the native platform, the compilation and execution efficiency of the JS code will greatly affect the performance of the game.

Usually JS engines provide JIT capabilities to improve compilation speed, which enables small games to achieve excellent performance on the Android side. However, due to the system security policy on the iOS side that restricts the JS engine from using the JIT function, the performance of small games on the iOS side has always been unsatisfactory.

The high-performance mode provided by WeChat mini games allows mini games on iOS to also have JIT capabilities by switching to WeChat's internal Webkit to run games, greatly improving running performance.

From the aquarium test in the official document of WeChat Mini Games, we can see that in the same scene, on iPhone11 Pro Max, it reached 49 FPS in high-performance mode, but only 13 FPS in normal mode.

This article will explain from the following four aspects:

High performance mode
Runtime memory structure
Diagnosing memory problems
Memory optimization tips

Because memory issues perform well on the Android side and receive more feedback on the iOS side, this article only introduces memory optimization on the iOS side.

High performance mode

For the introduction and usage of high-performance mode, please read the WeChat Mini Game Development Document in detail: High-Performance Mode (you can long press the QR code at the end of the article).

Italiano

Log in to the WeChat public platform -> Home page capability map module -> Click to enter the "Production Improvement Package" -> Click to activate high-performance mode.
After successful activation, you can enter high-performance mode by configuring iOSHighPerformance in game.json to true.
After Cocos Creator 3.7, you can check the high-performance mode directly on the Project- > Build Release panel .

By removing this switch, you can return to normal mode normally for comparison between the two modes.

Pay attention to the problem

In high-performance mode, the game will have better rendering performance and performance, but it has stricter memory requirements for the game.
In high-performance mode, mini-games run in the browser kernel environment, so aspects such as compatibility, memory consumption, and stability need to be tested separately, and test results in normal mode cannot be reused.
In iOS devices, the memory limit of 2G RAM models such as iphone 6s/7/8 is 1G, and the memory limit of 3G RAM models such as iphone 7P/8P/iPhoneX/XR/XSAMX/11 is 1.4G. Once the application If the memory usage exceeds this threshold, the process will be killed by the system. Therefore, developers must ensure that the peak memory does not exceed this value.
If the game has not been optimized for memory, it is not recommended to turn on the high-performance mode, otherwise it is easy to exit abnormally on low-end iOS machines. If there are memory problems, you can refer to the memory optimization tips in this article to fully optimize the memory.

runtime memory

As you can see from the figure above, the runtime memory consists of 6 parts.

JavaScript Heap

In high-performance mode, the mini-game runs in the browser kernel environment, so the JavaScript Heap contains the game logic code memory. Usually we can package the web-mobile side and use the debugging tool of the Safari browser on the Mac platform to remotely debug the memory status of mobile safari. It should be noted that JavaScript Heap usually cannot see the specific physical memory usage.

WASM resources

In order to improve the execution performance of JS modules, such as physics engine calculations, we will directly compile some C++ codes into WASM code snippets to achieve optimized performance requirements. For example, the third-party physics library referenced by Cocos Creator is the WASM version.

Basic libraries and Canvas

The basic library can be understood as the API package exposed by the black box environment of WeChat mini-games, which can prevent the browser kernel environment API from being exposed to developers. The actual test basic library memory occupied about 70M. The first Canvas created in the mini-game environment is the main Canvas, and it is also the only Canvas that can synchronize the rendering surface to the main interface, that is, to present the rendering performance of our game. The memory footprint of the Canvas is proportional to the width and height of the Canvas.

audio file

Audio file memory refers to audio instances loaded into memory.

GPU resources

Such as vertex data cache, index data cache, texture cache and rendering surface cache, etc.

Diagnosing memory problems

Here are some commonly used iOS memory diagnostic tools that can help us quickly locate memory problems and find solutions.

Commonly used iOS device memory viewing tools

Instrument analysis tool that comes with Xcode
Perfdog tools
WeChat Developer Tools

Note: The process names of iOS mini-games are different in different modes.

High performance mode: with WebContent

Normal mode: Contains WeChat

XCode Instruments

XCode Instruments is XCode's own application runtime analysis tool, which is also applicable to WeChat mini game processes.

Use Activity Monitor, select the corresponding device all processes to capture, wait for the process list to refresh, enter webkit to filter, and you can see the CPU and memory status of all processes.

Perfdog

Perfdog (Perfdog) is a performance testing and analysis tool for iOS/Android/PC/host platforms. For specific usage, please refer to: https://perfdog.qq.com/

Select the corresponding setting-process name to see the relevant performance data.

You can refer to [Memory Tuning in the Development Phase: Control Everything at the Beginning | WeChat Open Document]: https://developers.weixin.qq.com/minigame/dev/guide/performance/perf-action-memory-dev- profile.html

WeChat Developer Tools

WeChat developer tools mainly use its debugger to track memory data. The operation process is as follows:

Enter the debugging developer tools interface
Check [Memory] and then refresh the game
Click the small circle button in the upper left corner of the picture below to start recording
After recording ends, the following interface will be displayed

We mainly focus on two waveforms, one is the Main waveform, used to view the logical frame call stack, and the other is the peak curve of JS Heap, used to observe changes in memory growth. If we observe that the JS Heap value increases at a certain moment, then we can view the logical frame call stack to roughly confirm the source of the data.

Through the above steps, we can analyze the JS memory distribution of the game. Then when we want to determine the source and release of a certain piece of JS memory, we need to use the following memory leak detection tool - real-time memory diagnosis .

The specific steps are as follows:

Click the small circle button in the upper left corner to enter the recording button below. The appearance of the histogram indicates the creation of a certain memory block, and its disappearance indicates that the memory block has been released. The trash can button in the upper left corner is a button that actively triggers the GC of the JS engine. Clicking it can speed up memory recycling.
Click the small red circle button in the upper left corner again to end the recording. At this time, we can select the blue area, and then the objects contained in the memory block will be displayed. These are resources that have not been released in the memory. After selecting an object, you can The Retainers interface sees the memory reference relationship of the object. At this point you can reason about whether the memory object should be released based on the logical relationship at the code layer, thereby confirming whether there is a memory leak.

Memory optimization tips

The memory of common WeChat mini-game projects consists of the following parts:

Mini game basic library
Engine script memory
Business script memory
audio memory
Font memory
Picture memory
Canvas memory

Once we know the memory components, we can do some optimizations for different parts.

Taking iOS high-performance mode as an example, commonly used memory optimization techniques are as follows:

The memory of the basic library of small games is usually ~= 70M, which is resident memory and cannot be optimized.
The engine memory usage is determined when loading. Since the engine loading will initialize the renderer, usually the main Canvas memory usage is also determined at this time. This memory usage can be optimized by configuring a multiple of the rendering resolution. During runtime, some cache memory will be dynamically added according to the needs of the engine module. Developers can reduce engine memory usage through function tailoring in the editor project settings according to functional needs.
The script memory contains engine and business code, and configuration table data. Depending on the development volume of the game, the business code and configuration table data memory will be several hundred M in size, and can only be optimized by the user.
A single dual-channel audio instance may be around 20M. Releasing it after the audio is played will reduce this memory loss. It can also be streamlined into single-channel audio to reduce memory.
In China, Chinese fonts are generally used, and the memory usage after loading is at least greater than 10M, so try to use system fonts and use shared resources within the application. If development conditions permit, Bitmap fonts and SDF font rendering can be used.
Image memory is a commonly used resource. According to loading needs, you can choose to fill the texture and then release it, or cache it in the memory to refill the texture next time. On the iOS side, it is recommended to use the astc compressed texture format and disable dynamic batching, which can free up image resource memory. The compressed texture itself also takes up more than 50% less memory than png, but the file size of astc will be larger than png, so the package size will be increased. Usually in order to reduce the size of the first package, try to put image resources into mini-game subcontracting or remote subcontracting.
A Canvas object will be created when TTF font text is rendered. The Canvas object will be recycled into the cache pool after use. The larger the font size for text rendering, the larger the cache pool. Currently, the engine does not provide a recycling mechanism. If necessary, the engine can be modified to release the Canvas. cache pool. If the memory usage of the game is relatively high, you can use Bitmap fonts instead of TTF fonts.
There are also other JS memory objects, such as JSON files, which are released on demand according to the capabilities provided by the engine.

This article is provided by the Cocos engine official technical support team and has been synchronized to the engine's official open source warehouse: WeChat Mini Game Memory Optimization Guide (IOS). Welcome to Star and Fork.

reference article

Past highlights