CN114077575A

CN114077575A - Format conversion method, equipment and system for memory snapshot file

Info

Publication number: CN114077575A
Application number: CN202010836787.0A
Authority: CN
Inventors: 徐睿祺; 楚培林; 陈强; 陈瑞坤
Original assignee: Tencent Technology Chengdu Co Ltd
Current assignee: Tencent Technology Chengdu Co Ltd
Priority date: 2020-08-19
Filing date: 2020-08-19
Publication date: 2022-02-22

Abstract

A format conversion method, equipment and system for a memory snapshot file are disclosed. The format conversion method for the memory snapshot file comprises the following steps: acquiring a memory snapshot file of a first storage format of a target application; converting the memory snapshot file in the first storage format into the memory snapshot file in the second storage format by using a first memory analyzer, wherein the converting the memory snapshot file in the first storage format into the memory snapshot file in the second storage format by using the first memory analyzer comprises: analyzing the memory snapshot file in the first storage format to acquire snapshot information of a memory object of the target application; and storing the snapshot information of the memory object to a preset storage space in a second storage format to generate a memory snapshot file in the second storage format.

Description

Format conversion method, equipment and system for memory snapshot file

Technical Field

The present invention relates to the field of computers, and in particular, to a format conversion method, device, and system for a memory snapshot file.

Background

With the popularization of mobile terminal devices such as smart phones and tablet computers, mobile phone-like applications and games have been rapidly developed. In the development process of the mobile phone application or the game, the mobile phone application developer pays attention to the analysis of the memory to optimize the memory occupied by the mobile phone application or the game during running and reduce the memory occupancy rate.

Taking an application or a game in which Unity is taken as a development engine and IL2CPP is taken as a compiling tool platform as an example, in the current IL2CPP memory analysis for Unity applications or games, the memory analysis information in the memory snapshot obtained by using a plug-in unit memory profiler (unit memory analyzer) in a Unity engine editor given by an official party is relatively comprehensive. However, the Unity memory analyzer includes two versions, namely a first version (denoted as V1) supporting applications or games developed by the Unity engine of 5.3-2017 (old version) and a second version (denoted as V2) supporting applications or games developed by 2018.3 and the Unity engine of the above (new version), and the corresponding memory snapshot files are in the V1 format and the V2 format, respectively. Compared with the V1 format, the memory snapshot file in the V2 format has more reasonable data layout and can display memory information more intuitively and effectively, but because a considerable part of the existing application or game items are developed by using the Unity engine of 5.3 to 2017 (old version), the memory snapshot file in the V1 format can only be obtained by using the Unity memory analyzer of the first generation version for such items. Therefore, it is usually necessary to convert the V1 format memory snapshot file into the V2 format.

In the related art, the second-generation (i.e. V2, higher version) unit memory analyzer can be generally used to convert the V1 format (i.e. lower version) memory snapshot file into the V2 format (higher version) without loss, and parse and display the file, but such operations of format conversion, parsing and display must be performed in the second-generation unit memory analyzer, while the acquisition of the V1 format snapshot file needs to be performed in the first-generation unit memory analyzer, so there are considerable time and economic costs in the acquisition, format conversion, parsing and display processes of the related art memory snapshot file.

Disclosure of Invention

It is an object of the present invention to overcome at least one of the disadvantages of the related art.

According to an aspect of the present invention, a format conversion method for a memory snapshot file is provided, including: acquiring a memory snapshot file of a target application in a first storage format, wherein the first storage format is a default memory snapshot file format of a first memory analyzer; converting the memory snapshot file in the first storage format into the memory snapshot file in the second storage format by using a first memory analyzer, where the second storage format is a default memory snapshot file format of the second memory analyzer, and the second memory analyzer is an upgraded version of the first memory analyzer, and the converting the memory snapshot file in the first storage format into the memory snapshot file in the second storage format by using the first memory analyzer includes: analyzing the memory snapshot file in the first storage format to acquire snapshot information of a memory object of the target application, wherein the snapshot information of the memory object comprises data content of the memory object; and storing the snapshot information of the memory object to a preset storage space in a second storage format to generate a memory snapshot file in the second storage format.

In some embodiments, the first memory analyzer is for a first engine based application, the second memory analyzer is for a second engine based application, and the second engine is an upgraded version of the first engine.

In some embodiments, storing the snapshot information of the memory object of the target application in a second storage format to a preset storage space to generate a memory snapshot file in the second storage format includes: dividing a preset storage space to enable the preset storage space to comprise a first storage area, a second storage area, a third storage area, a fourth storage area, a fifth storage area and a sixth storage area; dividing the data content of the memory object into one or more data blocks according to the difference of a first data type of the memory object, wherein each data block in the one or more data blocks comprises the data content of the memory object of a first data type, and the first data type is a default data type of a memory snapshot file of a first storage format; dividing each data block in the one or more data blocks into one or more segments, sequentially writing the one or more segments of each data block into a first storage area in a segment-by-segment writing mode, and recording the position of each segment of each data block in the first storage area and the offset position of the data content of each memory object in each data block in the data block; sequentially writing the position of each segment of each data block in the first storage area as the head information of each data block into the second storage area, and recording the position of the head information of each data block in the second storage area; the position of the head information of each data block in the second storage area is used as a directory of each data block to be sequentially written into a third storage area, and the position of the directory of each data block in the third storage area is recorded; sequentially writing one or more description information blocks respectively composed of description information for describing each of the one or more data blocks into a fourth storage area, and recording the position of each of the one or more description information blocks in the fourth storage area, wherein the description information of each data block comprises a first data type or a second data type of each memory object in the data block, and an offset position of the data content of each memory object in the data block, and the second data type is a default data type of the memory snapshot file in the second storage format; sequentially writing the position of the directory of each data block in the third storage area and the position of each description information block in the fourth storage area as the directory of each description information block in the fifth storage area; and sequentially writing the position of the directory of each description information block in the fifth storage area as the head information of each description information block into the sixth storage area and writing the file tail information into the sixth storage area.

In some embodiments, the first data type includes at least one of 58 data types, and the second data type includes at least one of a constant, a fixed size array, and a dynamic size array.

In some embodiments, the data content of a memory object includes reference chain information for the memory object.

In some embodiments, obtaining the memory snapshot file of the target application in the first storage format includes: sending a memory snapshot obtaining request to the terminal equipment to instruct the terminal equipment to generate a memory snapshot file of a first storage format of the target application in the following mode: searching direct reference relation information of each memory object in all memory objects when the target application runs; determining reference chain information of each memory object according to the direct reference relation information of each memory object; generating a memory snapshot file of a first storage format of the target application according to the reference chain information of each memory object of the target application, and,

and receiving the memory snapshot file of the first storage format of the target application from the terminal equipment.

In some embodiments, the format conversion method for the memory snapshot file according to the present invention further includes: and analyzing and displaying the memory snapshot file in the first storage format, wherein the memory snapshot file comprises reference chain information of at least one of all memory objects displayed in a tree structure.

In some embodiments, all memory objects include at least one of managed objects and native objects.

In some embodiments, the direct reference relationship information for each memory object includes meta-information for the directly referenced object and/or the directly referenced object of the memory object.

In some embodiments, receiving the memory snapshot file in the first storage format from the terminal device includes: receiving a file path of a memory snapshot file in a first storage format from terminal equipment; and receiving the memory snapshot file in the first storage format from the terminal equipment according to the file path.

In some embodiments, the format conversion method for the memory snapshot file according to the present invention further includes: and analyzing and displaying the memory snapshot file in the second storage format by using the first memory analyzer.

In some embodiments, parsing and presenting the memory snapshot file in the second storage format using the first memory analyzer includes: and reading the memory snapshot file in the second storage format according to the sequence of the sixth storage area, the fifth storage area, the fourth storage area, the third storage area, the second storage area and the first storage area to acquire snapshot information of the memory object of the target application.

In some embodiments, parsing and presenting the memory snapshot file in the second storage format using the first memory analyzer includes: and displaying the reference chain information of the memory object in a tree structure.

According to another aspect of the present invention, there is provided a format conversion apparatus for a memory snapshot file, including: the acquisition module is configured to acquire a memory snapshot file of a target application in a first storage format, wherein the first storage format is a default memory snapshot file format of the first memory analyzer; a conversion module configured to convert the memory snapshot file in the first storage format into the memory snapshot file in the second storage format by using a first memory analyzer, where the second storage format is a default memory snapshot file format of the second memory analyzer, and the second memory analyzer is an upgraded version of the first memory analyzer, and the converting the memory snapshot file in the first storage format into the memory snapshot file in the second storage format by using the first memory analyzer includes: analyzing the memory snapshot file in the first storage format to acquire snapshot information of a memory object of the target application, wherein the snapshot information of the memory object comprises data content of the memory object; and storing the snapshot information of the memory object to a preset storage space in a second storage format to generate a memory snapshot file in the second storage format.

According to another aspect of the present invention, a format conversion system for a memory snapshot file is provided, including a terminal device and a server, where the terminal device includes: a first receiving module configured to receive a memory snapshot file acquisition request for a target application from a server; the searching module is configured to search the direct reference relation information of each memory object in all the memory objects when the target application runs; the determining module is configured to determine reference chain information of each memory object of the target application according to the direct reference relation information of each memory object; the snapshot generating module is configured to generate a memory snapshot file of a first storage format of the target application according to the reference chain information of each memory object of the target application, wherein the first storage format is a memory snapshot file format which is default by the first memory analyzer; a first sending module configured to send a memory snapshot file in a first storage format to a server, and the server includes: the second sending module is configured to send a memory snapshot file acquisition request for the target application to the terminal device; the second receiving module is configured to receive the memory snapshot file in the first storage format from the terminal equipment; a format conversion module configured to convert the memory snapshot file in the first storage format into the memory snapshot file in the second storage format by using a first memory analyzer, where the second storage format is a default memory snapshot file format of the second memory analyzer, and the second memory analyzer is an upgraded version of the first memory analyzer, and where the converting the memory snapshot file in the first storage format into the memory snapshot file in the second storage format by using the first memory analyzer includes: analyzing the memory snapshot file in the first storage format to obtain snapshot information of a memory object of a target application, wherein the snapshot information of the memory object comprises data content of the memory object, and storing the snapshot information of the memory object in a second storage format to a preset storage space to generate the memory snapshot file in the second storage format; and the analysis display module is configured to analyze and display the memory snapshot file in the second storage format.

According to another aspect of the present invention, there is provided a computing device comprising: a processor; and a memory having instructions stored thereon, the instructions, when executed on the processor, causing the processor to perform a method of format conversion of a memory snapshot file according to some embodiments of the present invention.

According to another aspect of the present invention, there is provided one or more computer-readable storage media having stored thereon computer-readable instructions that, when executed, implement a format conversion method for a memory snapshot file according to some embodiments of the present invention.

The format conversion method for the memory snapshot file focuses on realizing the format conversion process from the low-version memory snapshot file to the high-version memory snapshot file by using a memory analyzer (V1) supporting low-version engine application or games. Specifically, in the format conversion method for the memory snapshot file according to some embodiments of the present invention, after the memory snapshot file of the first storage format (low version format) of the target application is obtained and analyzed, the conversion of the memory snapshot file from the first storage format to the second storage format is achieved by using the first memory analyzer (V1) to store the snapshot information of the analyzed memory object in the second storage format to the preset storage space to generate the memory snapshot file of the second storage format (high version format), so as to solve the problem in the related art that the low version memory analyzer (V1) is simultaneously used to obtain the low version memory snapshot file in the memory detection and analysis process for the low version engine application or game, and the high version memory analyzer (V2) is used to implement the format conversion, thereby simplifying the work flow of game development and testers, simplifying the complicated operation of the format conversion, The working efficiency is improved, and therefore the use cost of the memory analyzer in the memory detection and analysis process is reduced.

Drawings

Various aspects, features and advantages of the present invention will become more readily appreciated from the following detailed description and accompanying drawings, in which:

FIG. 1 schematically illustrates an example application environment for a format conversion method for memory snapshot files, in accordance with some embodiments of the present invention;

FIG. 2 schematically illustrates an example interaction diagram of a format conversion method for a memory snapshot file in the example application environment of FIG. 1, in accordance with some embodiments of the present invention;

FIG. 3A schematically illustrates a flow diagram of a format conversion method for a memory snapshot file, in accordance with some embodiments of the present invention;

FIG. 3B schematically illustrates an example presentation interface for a memory snapshot file in a first storage format, in accordance with some embodiments of the present invention;

FIG. 3C schematically illustrates an example presentation interface for a memory snapshot file in a second storage format, in accordance with some embodiments of the present invention;

FIGS. 4A and 4B illustrate an exemplary flow and an interactive flow, respectively, of steps of a format conversion method for a memory snapshot file, shown in FIG. 3A, in accordance with some embodiments of the present invention;

4C-4D illustrate example interfaces of a memory snapshot file in a second storage format presented by format conversion methods for memory snapshot files in accordance with some embodiments of the present invention;

fig. 4E illustrates an example interface of a memory snapshot file in a first storage format exposed by a format conversion method for the memory snapshot file according to some embodiments of the invention;

fig. 5A and 5B schematically illustrate storage structures of a memory snapshot file in a first storage format and a memory snapshot file in a second storage format, respectively;

FIG. 6 schematically illustrates a flow diagram of a format conversion method for a memory snapshot file, in accordance with some embodiments of the present invention;

FIG. 7 is a block diagram that schematically illustrates a format conversion device for memory snapshot files, in accordance with some embodiments of the present invention;

FIG. 8 schematically illustrates a block diagram of a format conversion system for memory snapshot files, in accordance with some embodiments of the present invention; and

FIG. 9 schematically illustrates a computing device according to some embodiments of the inventions.

It is to be noted that the figures are diagrammatic and explanatory only and are not necessarily drawn to scale.

Detailed Description

Several embodiments of the present invention will be described in more detail below with reference to the accompanying drawings in order to enable those skilled in the art to practice the invention. This invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. The examples do not limit the invention.

It will be understood that, although the terms first, second, third, etc. may be used herein to describe various elements, components and/or sections, these elements, components and/or sections should not be limited by these terms. These terms are only used to distinguish one element, component or section from another element, component or section. Thus, a first element, component, or section discussed below could be termed a second element, component, or section without departing from the teachings of the present invention.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and/or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. As used herein, the term "and/or" includes any and all combinations of one or more of the associated listed items.

Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of the relevant art and/or the present specification and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.

For an application or game developed by a Unity engine and compiled to run through an IL2CPP, IL2CPP memory snapshot files in two formats given by the Unity authority, namely a V1 format and a V2 format respectively support the engine in versions between Unity5.3-2017 and the application or game developed by the engine in the versions 2018 and above. Compared with the memory snapshot file in the V1 format, the memory snapshot file in the V2 format is more intuitive and effective in memory analysis and information display. However, most of the existing application or game items developed by the unit engine still use the engine with the version between the unit 5.3 and 2017, so for these items, the snapshot file (for example, with the extension of. memmsnap 3) in the V1 format can only be obtained through the component unit memory profiler (V1) (unit memory analyzer) in the low-version engine editor. If the memory snapshot of the applications or the game items in the V2 format is required to be obtained, a snapshot file in the V1 format must be opened in an engine editor of the unit 2018.3 and above versions by using a unit memory profiler (V2) plug-in, converted into a snapshot file in the V2 format (such as a file with the extension of @ snap), and then analyzed and shown.

Although the above-mentioned solution of the related art can solve the problem that the unit memory profiler (V2) in the high-version engine editor cannot be used to obtain the memory snapshot file in the V2 format in the application or game developed by the low-version unit engine, such a solution takes a very long time and must be performed in two versions of the engine editor (especially two versions of the unit memory analyzer), which further increases the use cost.

In order to solve at least one of the above problems, the format conversion method for the memory snapshot file provided by the invention focuses on the whole memory detection analysis process of realizing acquisition of the V1 format snapshot file, format conversion from the V1 format to the V2 format, and analysis and display of the V2 format snapshot file by using the memory analyzer (V1) supporting the application of the low version engine (such as the unity5.3-2017 version engine) or the game, so that the problem that the complicated operations of simultaneously using the low version memory analyzer (V1) and the high version memory analyzer (V2) in the memory detection and analysis process of the low version engine application or the game in the related art are required is solved, the work flow of game development and testers is simplified, the work efficiency is improved, and the use cost of the memory analyzer in the memory detection and analysis process is reduced.

In the format conversion method for the memory snapshot file according to the present invention, the memory analysis or detection is mainly performed on an application or a game developed by a cross-platform-based game engine (e.g., Unity) and compiled to run by a compiling tool based on a common language architecture (e.g., IL2 CPP). Hereinafter, generally, Unity will be used as an example of an application or game engine, and an IL2CPP platform will be used as an example of a compiling tool. For the remaining types of game engines and/or the remaining types of compilation tools, similar descriptions are omitted.

Before describing in detail embodiments of the present invention, for the sake of clarity, some concepts related thereto are first explained:

1. unity: a multi-platform, integrated game development tool that can be used to create types of interactive content such as three-dimensional video games, building visualizations, real-time three-dimensional animations, etc., is a fully integrated professional game engine.

2. IL2 CPP: a new script post-processing (Scripting Back) mode aiming at the Unity engine game processes the IL (intermediate language) compiled and output by the Net platform. IL2CPP is mainly composed of two parts: AOT static compilation compilers and runtime libraries. The AOT converts the IL into a C + + source code, and then the C + + source code is sent to a C + + compiler of each platform for compiling, so that the purpose of platform compatibility is achieved; runtime libraries provide services and abstractions such as garbage collection, thread/file fetching, internal calls to directly modify the native code of managed data structures.

3. Object: the method refers to an instance inside a program set loaded in a corresponding memory during the running process of an application or a game, such as a class object in object-oriented programming languages C + +, C #, Java, wherein a class is a set of things or events having common characteristics to a group, and a class object is an instantiation of a class. Objects may include various instantiated variables such as value type variables (e.g., int, float, struct, etc.) and reference type variables (class type, array type, string type, etc.), and may also include other instances of occupied memory.

4. Managed and Native objects: a native object (or called an engine object) is an object (such as a C + + object) which occupies a memory and is used in an application or a game engine during the running process of the application or the game; managed objects are memory-occupied objects (e.g., C # objects) in the compilation tool (IL 2 CPP) application domain.

5. Meta information of the object: the information describing the object attribute may include, for example, an object name, an object type, an object value, a memory value, member data of a class to which the object belongs, and the like.

6. Reference chain information of object: the information related to the direct and/or indirect reference relationship of the object may include, for example, meta information of the object directly referenced and/or indirectly referenced by the object, and reference path information referred to by the direct and/or indirect reference relationship of the object. For example, assume that the direct and indirect referencing relationships of object A are: a refers to B and C, B refers to D and E, the reference relationship chain of the object a may include A, B, C, D, E respective meta information, and the reference path referred to by the above reference relationship: A-B-D, A-B-E, A-C.

7. A first memory analyzer and a second memory analyzer: tools for in-memory analysis of running applications or games, such as software or plug-ins, the latter being an upgraded version of the former. For example, the first memory analyzer may refer to a tool for performing memory analysis on an application or a game developed by a low-version engine (e.g., unity 5.3-2017), such as a unity memory profiler (V1) plug-in or a modified plug-in with a custom function embedded therein; the second memory analyzer may refer to a tool for performing memory analysis on an application or game developed by a high-version engine (e.g., unity2018.3 and above), such as unity memory profiler (V2).

8. A first storage format and a second storage format: the storage formats of the default memory snapshot files of the first memory analyzer and the second memory analyzer are respectively represented, for example, the default V1 format of the unity memory profiler (V1), and the default V2 format of the unity memory profiler (V2). Herein, the V1 format may be used interchangeably with the first storage format and the V2 format may be used interchangeably with the second storage format.

9. A first data type and a second data type: for example, the first data type includes 58 data types, for example, including a variable data type in a C # or C + + program language, such as a value type (e.g., int, float, struct, etc.) and a reference type (e.g., a class type, an array type, a string type, etc.); the second data type groups 58 first data types into 3, Constant (Single Value), fixed Size Array (Constant Size Array), and Dynamic Size Array (Dynamic Size Array).

Fig. 1 schematically illustrates an example application scenario of a format conversion method for a memory snapshot file according to some embodiments of the present invention. As shown in fig. 1, the application scenario 100 may include a terminal device 110 and a server 120 and a network 130 for connecting the terminal device 110 and the server 120. In some embodiments, the server 120 may be configured to implement the format conversion method for the memory snapshot file according to some embodiments of the present invention, for example, the server 120 may be deployed with corresponding programs or instructions for executing various methods provided by the present invention. Optionally, terminal device 110 may also be used to implement various methods in accordance with the present invention. In some embodiments, the application scenario 100 may also correspond to the format conversion system 800 for the memory snapshot file according to some embodiments of the present invention shown in fig. 8, please refer to fig. 8 and the corresponding description thereof.

The terminal devices 110 may be any type of mobile computing device, including mobile computers (e.g., Microsoft Surface devices, Personal Digital Assistants (PDA), laptop computers, notebook computers, such as Apple iPad @^TMTablet computer, netbook, etc.), mobile phones (e.g., cellular phones, smart phones such as Microsoft Windows phones, Apple iPhone, Google Android enabled ® Tooth @^TMOperating system's telephone, Palm device, Black berry device, etc.), wearable computing device (for example intelligent watch, head mounted device, including intelligent glasses, for example Google Glass-^TMEtc.) or other types of mobile devices. In some embodiments, terminal device 110 may alsoIs a stationary computing device such as a desktop computer, a game console, a smart television, etc.

The server 120 may be a single server or a cluster of servers or a cluster of cloud servers. It should be understood that the servers referred to herein are typically server computers having a large amount of memory and processor resources, but other embodiments are possible. Alternatively, as shown in FIG. 1, the server 120 may also be a common desktop computer that includes a host computer, a display, and the like.

Examples of network 130 include a Local Area Network (LAN), a Wide Area Network (WAN), a Personal Area Network (PAN), and/or a combination of communication networks such as the Internet. Server 120 and terminal device 110 may include at least one communication interface (not shown) capable of communicating over network 130. Such communication interfaces may be one or more of the following: any type of network interface (e.g., a Network Interface Card (NIC)), wired or wireless (such as IEEE 802.11 Wireless LAN (WLAN)) wireless interface, worldwide interoperability for microwave Access (Wi-MAX) interface, Ethernet interface, Universal Serial Bus (USB) interface, cellular network interface, Bluetooth^TMAn interface, a Near Field Communication (NFC) interface, etc. Further examples of communication interfaces are described elsewhere herein.

Fig. 2 illustrates an example interaction diagram of the example application scenario 100 of the format conversion method for a memory snapshot file illustrated in fig. 1, according to some embodiments of the present invention. The working principle of the format conversion method for the memory snapshot file in the exemplary scenario 100 according to some embodiments of the present invention is briefly described below with reference to an exemplary interaction diagram shown in fig. 2.

As shown in fig. 2, in the application scenario 100 shown in fig. 1, the server 120 is configured to: obtaining a memory snapshot file of a first storage format of a target application from, for example, terminal device 110, where the first storage format is a memory snapshot file format that is default for a first memory analyzer; and converting the memory snapshot file in the first storage format into the memory snapshot file in the second storage format by using the first memory analyzer, wherein the second storage format is a default memory snapshot file format of the second memory analyzer, and the second memory analyzer is an upgraded version of the first memory analyzer, and the converting the memory snapshot file in the first storage format into the memory snapshot file in the second storage format by using the first memory analyzer comprises: analyzing the memory snapshot file in the first storage format to acquire snapshot information of a memory object of the target application, wherein the snapshot information of the memory object comprises data content of the memory object; and storing the snapshot information of the memory object to a preset storage space in a second storage format to generate a memory snapshot file in the second storage format. As shown in fig. 2, optionally, the server 120 may be further configured to: and analyzing and displaying the memory snapshot file in the second storage format by using the first memory analyzer.

As shown in fig. 2, in the application scenario shown in fig. 1, optionally, the terminal device 110 may be configured to: obtaining memory snapshot information of a target application in operation to generate a memory snapshot file in a first storage format; the memory snapshot file in the first storage format is then sent to the server 120 for format conversion and/or parsing and displaying, so that a user (e.g., game development or tester) can browse and query the memory analysis information in the memory snapshot file through an output device such as a display.

In the application scenario 100 shown in fig. 1, optionally, before the terminal device 110 generates the memory snapshot file in the first storage format, the server 120 may be further configured to: first, a memory snapshot obtaining request in a first storage format for a target application is sent to the terminal device 110, so as to trigger the terminal device 110 to start the target application and perform memory analysis during application running, so as to generate a memory snapshot file in the first storage format.

The exemplary environments and workflows of fig. 1 and 2 are merely exemplary, and the format conversion method for the memory snapshot file according to the present invention is not limited to the illustrated exemplary environments. It should be understood that although server 120 and terminal device 110 are shown and described herein as separate structures, they may be different components of the same computing device. For example, optionally, an application scenario or an implementation environment of the format conversion method for the memory snapshot file according to some embodiments of the present invention may also only include the terminal device without involving the server, that is, the terminal device autonomously completes the whole process of memory analysis triggering, object obtaining, snapshot generating, parsing and displaying in the running process of the target application. Optionally, an application scenario or an implementation environment of the format conversion method for the memory snapshot file according to some embodiments of the present invention may also only include the server without involving the terminal device, that is, the terminal device autonomously completes operations such as obtaining, format conversion, parsing and displaying of the memory snapshot file in the first storage format. For example, it may be assumed that the target application is installed and running in the server, and thus the corresponding snapshot file obtaining step may be directly performed in the server; or the memory snapshot file of the first storage format to be converted may already be stored on the server, at this time, the snapshot file may be directly obtained on the local disk, and then the first memory analyzer in the server is used to perform format conversion and/or parsing and displaying steps on the snapshot file.

Fig. 3A schematically illustrates a flow diagram of a format conversion method for a memory snapshot file, in accordance with some embodiments of the present invention.

In some embodiments, the format conversion method for the memory snapshot file may be executed on a server (e.g., the server 120 shown in fig. 1 and 2). In other embodiments, the format conversion method for the memory snapshot file may also be performed by the server 120 and the terminal device 110 shown in fig. 1 and fig. 2 in combination.

In step S310, a memory snapshot file of a first storage format of the target application is obtained, where the first storage format is a memory snapshot file format that is default for the first memory analyzer.

In some embodiments, the target application refers to a target for performing memory analysis or detection to obtain the memory snapshot file in the first storage format, that is, an application or a game to be analyzed or detected. The target application may be a computer application or game based on Windows (Windows operating system), MacOS (apple operating system), Linux platform (Linux operating system) developed by a cross-platform application or game engine (e.g., Unity), or an application or game of ios (apple system), Android (Android system) mobile devices. In some embodiments, a target application developed by a cross-platform engine, such as Unity, may be compiled using a cross-platform compilation tool that supports a common language architecture, such as IL2 CPP. For example, taking an application or game developed by the Unity engine as an example, the target application is usually a low-version engine (e.g., Unity 5.3-2017) game. The first memory analyzer may refer to a tool for performing memory analysis on an application or game developed by a low-version engine (e.g., Unity 5.3-2017), such as an improvement of Unity official plug-in unit memory profiler (V1); the default storage format of the memory snapshot file of the first memory analyzer is the first storage format, for example, a memory snapshot file in a V1 format obtained by a unit memory profiler (V1) plug-in, and the extension of the memory snapshot file may be memscan 3.

In some embodiments, as shown in fig. 2, the memory snapshot file of the first storage format of the target application may be obtained from, for example, a terminal device 110 such as a mobile phone for running the target application. For example, the server 120 may first send an acquisition request for a memory snapshot file in a first storage format of the target application to the terminal device 110, so as to trigger the terminal device 110 to start the target application and perform memory analysis when the target application runs, so as to generate the memory snapshot file in the first storage format; subsequently, as shown in fig. 2, the server 120 may receive the memory snapshot file of the first storage format generated by the server from the terminal device 110. Alternatively, the memory snapshot of the first storage format may also be obtained on the server 120, when the server 120 (e.g., a personal computer comprising a host and a display) itself may also run the target application or game. For example, when the target application runs on the server 120, the memory object and the reference relationship thereof are searched, and the memory snapshot information is obtained, so that the memory snapshot file in the first storage format is generated based on the memory snapshot information. In some embodiments, the memory snapshot file of the first storage format of the target application may already exist on the server 120, and the memory snapshot file may be obtained directly from the storage of the server 120.

In step S320, the memory snapshot file in the first storage format is converted into a memory snapshot file in a second storage format by using the first memory analyzer, where the second storage format is a default memory snapshot file format of the second memory analyzer, and the second memory analyzer is an upgraded version of the first memory analyzer. The converting the memory snapshot file in the first storage format into the memory snapshot file in the second storage format by using the first memory analyzer may include: analyzing the memory snapshot file in the first storage format to acquire memory snapshot information of a memory object of the target application, wherein the snapshot information of the memory object comprises data content of the memory object; and storing the snapshot information of the memory object to a preset storage space in a second storage format to generate a memory snapshot file in the second storage format.

In some embodiments, the second memory analyzer may refer to a tool for performing memory analysis on an application or game developed by a high-version engine (e.g., unity2018.3 and above), such as a unity memory profiler (V2) plug-in. The default storage format of the memory snapshot file of the second memory analyzer is the second storage format, for example, the V2 format memory snapshot file obtained by the unity memory profiler (V2) plug-in, and the extension may be. The second memory analyzer is an updated version or an upgraded version of the first memory analyzer. One innovative aspect of the present invention is to convert a memory snapshot file of a first storage format, which is default to a first memory analyzer, into a memory snapshot file of a second storage format, which is default to a second memory analyzer, which supports a high-version engine, by using, for example, the first memory analyzer supporting a low-version engine game. In some embodiments, custom program code may be injected in advance into a plug-in supporting a low version engine (i.e., forming a first memory analyzer), such as a unit memory profiler (V1), so that it can implement conversion of a memory snapshot file for a low version engine game from a low version format (e.g., V1 format) to a high version (e.g., V2 format).

In step S320, the format conversion of the memory snapshot file may be performed in the following manner: firstly, analyzing a memory snapshot file in a first storage format to acquire memory snapshot information of a memory object of a target application, wherein the snapshot information of the memory object comprises data content of the memory object; and then, utilizing the first memory analyzer to store the snapshot information of the memory object to a preset storage space in a second storage format so as to generate a memory snapshot file in the second storage format. A more detailed description of the above steps regarding the storage format conversion of the memory snapshot file can be found in steps S403 and S404 shown in fig. 4A and 4B.

The format conversion method for the memory snapshot file focuses on realizing a conversion process from a first storage format (such as a V1 format) of the low-version memory snapshot file to a second storage format (such as a V2 format) of the high-version memory snapshot file by using a memory analyzer (V1) supporting application or games of a low-version engine (such as a unity5.3-2017 engine). Specifically, in the format conversion method for the memory snapshot file according to some embodiments of the present invention, after the memory snapshot file in the first storage format (V1 format) of the target application is obtained and parsed, the conversion of the memory snapshot file from the first storage format to the second storage format is achieved by using the first memory parser (V1) to store the snapshot information of the parsed memory object in the second storage format to the preset storage space to generate the memory snapshot file in the second storage format (V2 format), so that the tedious operations of obtaining the low-version memory snapshot file by using the low-version memory parser (V1) and implementing the format conversion by using the high-version memory parser (V2) in the memory detection and analysis process for the low-version engine application or game in the related art are solved, and the workflow of game development and testers is simplified, The working efficiency is improved, and therefore the use cost of the memory analyzer in the memory detection and analysis process is reduced.

Fig. 3B and 3C respectively show exemplary presentation interface diagrams of a memory snapshot file of a first storage format snapshot file acquired by a format conversion method for the memory snapshot file according to some embodiments of the present invention.

When software development or a tester needs to perform memory snapshot on a target application (such as a game developed by a low-version engine), a terminal device (such as a mobile phone) may be connected to a server (such as a (PC), and then a first memory analyzer is used to intercept a snapshot of the target application (i.e., a snapshot interception command or a signal is sent to the terminal device through the first memory analyzer to instruct the terminal device to acquire memory snapshot information of the target application during operation and generate a snapshot file in a first storage format), so that the memory snapshot file in the first storage format (i.e., a memory snapshot format supporting the low-version engine game, i.e., a V1 format) may be stored locally in the server; finally, the memory snapshot information is analyzed by the first memory analyzer and displayed as an interface as shown in fig. 3B. As shown in fig. 3B, the presentation interface of the memory snapshot in the first storage format (i.e., V1 format) shows the current memory usage of the target application, including, for example: allocation information such as Total allocation (Total allocation), Mono allocation (Mono allocation), GC allocation (GC allocation), classification memory information such as Texture memory (Texture memory), mesh memory (mesh memory), and quantity information such as material count (material count), object count (object count), and the like. As shown in fig. 3B, in the memory snapshot presentation interface in the V1 format, the memory occupation information of the resource (asset) object in the Native Objects (Native Objects) is presented, which includes the Name (Name) of the object, the class Name or type Name (ClassName), the class or type id (class id), the memory occupation Size (Size), the Reference object number (Reference Count), the referenced object number (Reference by Count), the Address (Address), and the Detail (Detail). As an example, FIG. 3B shows a resource object named Fx _ Glow, which has a type of particle System, a type ID of 99, a memory footprint size of 7.609375KB, a number of referenced objects of 2, and a number of referenced objects of 0. In addition, the user can view more specific information by clicking on Detail as shown in FIG. 3B. As can be seen from fig. 3B, by browsing the memory snapshot presentation interface in the first storage format (V1), the current information of the memory can be obtained more intuitively. Meanwhile, if further information of the memory is to be acquired, a corresponding detail page including details of the native object, the managed object, the static object, the GCHandle, and the like, such as a class name, an ID, a size, and the like of the object, may be displayed by clicking or tapping a corresponding directory.

Fig. 3C illustrates a display interface of the memory snapshot file in the second storage format obtained by the format conversion method for the memory snapshot file according to some embodiments of the present invention. When snapshot comparison is required or a snapshot in the V1 format needs to be viewed in the V2 format, opening the snapshot in the V1 format as the V2 format in the first memory analyzer will automatically convert the format to store and analyze the snapshot file for display, and the display effect is shown in fig. 3C. In the memory snapshot presentation interface of the second storage format (V2 format) shown in fig. 3C, the presentation of the information of each memory object is more detailed and intuitive than the memory snapshot presentation interface of the first storage format shown in fig. 3B. As shown in fig. 3C, the snapshot information includes, for example, a Name (Name), a Value (Value), a Type (Type), a Data Type (Data Type), a Native Object Name (Native Object Name), a Length (Length), whether or not it belongs to a Static Type (Static), a reference Object number (RefCount), an Address (Address), and the like of the Object. As can be seen from the comparison between fig. 3B and 3C, for an application or game that only supports a low-version engine (e.g., unity 5.3-2017), the snapshot file is converted from the first storage format to the second storage format by the first memory analyzer for display, so that the difficulty in acquiring the memory information by a developer is reduced, the convenience of software development or a tester for observing or browsing the information of each memory object is improved, and the development or testing efficiency is improved.

Fig. 4A and 4B illustrate an example flow and an interactive flow, respectively, of steps of a format conversion method for a memory snapshot file, shown in fig. 3A, according to some embodiments of the present invention.

As shown in fig. 4A and 4B, the step S310 of fig. 3A of obtaining the memory snapshot file in the first storage format of the target application may include the following steps:

s401, sending a snapshot file acquisition request to the terminal device to instruct the terminal device to generate a memory snapshot file in a first storage format of the target application in the following manner:

acquiring direct reference relationship information of each memory object in all memory objects when a target application runs; determining reference chain information of each memory object according to the direct reference relation information of each memory object; generating a memory snapshot file of a first storage format of the target application according to the determined reference chain information of each memory object;

s402, receiving the memory snapshot file of the first storage format of the target application from the terminal equipment.

As shown in fig. 4B, in order to obtain the memory snapshot file in the first storage format of the target application, a command or a signal sent by the server to instruct the terminal device to perform memory analysis or detection may be used, that is, to trigger the terminal device to start a request for obtaining the memory snapshot file in the first storage format for the target application. The request usually includes an identifier of a target application to be analyzed, and is used to inform the terminal device of an application or a game for which memory analysis is performed to obtain a memory snapshot.

In some embodiments, as described in step S401, the memory snapshot request sent by the server includes a specific implementation manner and a step of how to obtain the memory snapshot file in the first storage format. As shown in fig. 4B, obtaining the memory snapshot file in the first storage format at the terminal device may include the following steps: acquiring the direct reference relation of each memory object in all the memory objects when the target application runs; determining a reference chain of each memory object according to the direct reference relation of each memory object; and generating a memory snapshot file of a first storage format of the target application according to the obtained reference chain of each memory object.

In a target application developed by a cross-platform game engine (such as Unity) and compiled to run by a cross-platform compilation tool (such as IL2 CPP), objects in memory can include two broad classes, the first class of objects being Native objects that occupy memory (e.g., Native heap memory of the engine) used in the engine side of the application or game; the second class of objects are managed objects that occupy memory (e.g., managed heap memory) in the compilation tool application domain. Taking an application and a game developed by a Unity engine and adopting an IL2CPP as a compiling tool as an example, the runtime memory of the Unity engine can comprise an IL2CPP Managed Heap (Managed Heap) and a Unity engine Native Heap (Native Heap), wherein the Object in the former is a C # script Managed Object (Managed Object), and the Object in the latter is a script engine C + + Native Object (Native Object). Therefore, when acquiring direct reference relationships of all memory objects, direct reference relationships of managed objects and native objects need to be acquired respectively.

The reference chain information of the memory object may refer to information related to a direct and/or indirect reference relationship of the object, and may include, for example, meta information of the object, meta information of a direct reference object and/or an indirect reference object thereof, and reference path information related to the direct and/or indirect reference relationship of the object. For example, assume that A, B, C, D, E are all reference objects and that the direct and indirect referencing relationships for object A are: a refers to B and C, B refers to D and E, and the reference chain information of the object a may include A, B, C, D, E respective meta information, and the reference path referred by the reference relationship: A-B-D, A-B-E, A-C. The direct reference relationship of the object can represent the first-level reference relationship of the object, that is, no other object exists in the reference path between the original object and the reference object, and the direct reference relationship is between the above A and B; and the indirect reference relationship represents the reference relationship above the second layer, namely other objects exist between the original object and the reference object, such as the indirect reference relationship between the A and the D. The meta-information of the object may be one or more of the following: name (Name) of the object, type (Class) (e.g., Class Name of Class object), Field (Field), object Value (Value) (e.g., the first address of the object to which it refers), and Size of memory usage or memory Value (Size). In some embodiments, the direct reference relationship of a memory object includes meta-information of the direct reference object and/or the directly referenced object of the memory object.

In the related art memory snapshot obtaining process, a step of extremely time-consuming operation is to recursively search a reference chain of each object. Taking a Unity engine game as an example, the step of obtaining the reference relationship of the memory object in the related art is that the Unity engine searches through a function called gc, and recursion is inevitably required in the gc in order to completely release all the sub-objects referenced by the object. Due to the adoption of the mode of traversal and recursion, the memory analysis time is greatly consumed. However, the reference relationships of all memory objects obtained by such recursive-addition traversal are not all necessary. When all memory objects in the running process of the target application are acquired, the complete reference chain of each object is acquired only by knowing the direct reference relation between each object and the object. The operation of recursively searching all reference relationships (including direct and indirect reference relationships) of each memory object in the related art can be known by reading the reference relationship corresponding to the reference or referenced object of each memory object.

Therefore, as shown in fig. 4B, in the process of acquiring the memory snapshot file in the first storage format by the terminal device, the reference chain information (i.e., the memory snapshot information) of the memory object may be determined by only searching and acquiring the direct reference relationship of all the memory objects, so as to generate the memory snapshot file in the first storage format. Therefore, in the memory snapshot obtaining step of the invention, as only the most direct reference relation of each object needs to be obtained, the complicated operation of recursively searching the indirect reference relation is avoided, thereby greatly reducing the time for obtaining the memory snapshot information and generating the memory snapshot file. For example, through testing, the time for memory snapshot file retrieval according to the present invention may be optimized from 30-40 minutes of the related art to about 2 minutes or less.

In some embodiments, in the step of generating the memory snapshot file in the first storage format according to the reference chain information of the memory object as shown in fig. 4B, the reference chain information needs to be further processed to form the memory snapshot file. For example, the reference chain data of the memory object may be transferred to the memory snapshot file in the first storage format through serialization. Serialization is the process of converting the state information of an object into a form that can be stored or transmitted. Serialization is the decomposition of state information of an object into a byte stream for storage in a file or transmission over a network. Deserialization is the opening of a byte stream and the reconstruction of the state information of the object. Object serialization holds not only the data for one object, but also the data for each object referenced by the object recursively. The serialization process may write the entire object hierarchy into the byte stream and may be saved in a file or passed over a network connection. Alternatively, the data conversion, such as serialization, may not be performed, but rather, the resulting memory snapshot file in the first storage format may be directly obtained, although this may require code to be written for each object in order to save and restore fields and attributes to and from disk.

As shown in fig. 4B, in step S402, in the step of receiving the memory snapshot information in the first storage format from the terminal device, the terminal device transmits the generated memory snapshot file to the server for parsing, format conversion and display. In some embodiments, step S402 shown in fig. 4A and 4B may include: receiving a file path of a memory snapshot file in a first storage format from terminal equipment; and receiving the memory snapshot file in the first storage format from the terminal equipment according to the file path. In order to prevent the situation that transmission of the memory snapshot file is interrupted due to overlarge file in the transmission process from the terminal device to the server, data can be directly written into the snapshot file in a C + + layer of the application engine after memory snapshot information (i.e., reference chain information of a memory object) is generated, then a corresponding file path is returned to the server, and the server directly and automatically pulls the memory snapshot file from the server to the server for analysis display or format conversion operation according to the file path information of the memory snapshot in the terminal device by using a tool such as an adb (Android Debug Bridge).

The invention optimizes the acquisition of the memory snapshot object and the file transmission process, thereby reducing the time consumption and the deadlocking phenomenon of the acquisition of the memory snapshot file and avoiding the risk of interruption of the file transmission process.

As shown in fig. 4A and 4B, the step S320 of fig. 3A of converting the memory snapshot file in the first storage format into the memory snapshot file in the second storage format by using the first memory analyzer may include the following steps S403 to S404.

At S403, the memory snapshot file in the first storage format is parsed to obtain the memory snapshot information of the memory object of the target application, where the memory snapshot information of the memory object includes the data content of the memory object.

In some embodiments, to implement format conversion of the memory snapshot file, the memory snapshot file in the first storage format (V1) to be converted needs to be parsed first, so as to read the memory snapshot information therefrom. Specifically, the byte stream of the snapshot file may be restored to the state information of the memory object, that is, the reference chain information of the memory object through an deserialization process, so as to read data and perform a subsequent conversion step. In some embodiments, the snapshot information of the memory objects may include data contents of the memory objects, where the data contents include, for example, reference chain information of the memory objects (i.e., meta information of the memory objects and their reference objects, reference path). For parsing and reading the memory snapshot file in the first storage format (V1), reference may be made to related technologies, such as a parsing process of a unity memory profile (V1) plug-in for the memory snapshot file in the V1 format.

At S404, the snapshot information of the memory object is stored in a second storage format to a preset storage space to generate a memory snapshot file in the second storage format.

In order to use the memory snapshot file of the second storage format (V2) that is not originally supported by the low-version engine in the first memory analyzer supporting the low-version engine, and at the same time, without changing the source code of the low-version engine, it is necessary to first know the structures of the two snapshot files (V1 and V2), and then implement a custom program or code on the Unity memory profiler (V1) plug-in through C # using the scalability of the Unity engine editor, so as to implement the format resolution of the memory snapshot file of the second storage format (V2) of the second memory analyzer (i.e., Unity memory profiler (V2)) supporting the high-version engine (Unity2018), and the format conversion process from V1 to V2. In other words, the first memory analyzer according to the present invention is obtained by improving the unit memory profiler (V1) plug-in.

In fact, after the memory snapshot information in the first storage format is parsed or read, the information may be stored again according to the second storage format to obtain the memory snapshot file in the second storage format, as described in step S404. Specifically, a preset storage space may be applied in advance for storing a memory snapshot file in a second storage format to be generated, then the read snapshot information of the memory object is sequentially written into the preset storage space according to a storage structure defined by the second storage format, and after the writing is completed, data in the preset storage space may form the memory snapshot file in the second storage format. In some embodiments, the second storage format may include a data content storage area of the memory object, a description information storage area of the memory object, and a necessary address index information storage area and version verification information storage area, and so on.

As to the specific structure of the first storage format (V1) and the second storage format (V2), please refer to fig. 5A and 5B; the process of how the memory snapshot information forms the memory snapshot file in the second storage format by writing in the preset storage space can be seen in fig. 6.

As shown in fig. 4A and 4B, the format conversion method for the memory snapshot file shown in fig. 3A according to some embodiments of the present invention may further include:

in step S405, the memory snapshot file in the second storage format is analyzed and displayed by using the first memory analyzer.

When the memory snapshot file in the second storage format (V2) is parsed, the file may be read from the end of the file in the order from the description information storage area to the data content storage area of the memory object, so as to obtain the final memory snapshot information of the memory object. However, it should be noted that in the memory snapshot file of the second storage format (V2), unlike the first storage format (V1), not every metadata is stored in the structure (struct) in a well-resolved manner, but every object data inside it is actually some pointers (offset values) and byte arrays (byte [ ]). Therefore, each data and its field value that we need is really acquired, and further processing is needed. Because the number of fields displayed by the snapshot information in the second storage format is too many, and the processing of the step can be found in the source code of the second memory analyzer, i.e., the unity memory profile (V2) open source plug-in, the judgment and the reading and parsing operation of the byte array are mainly performed according to the object type without much description. More specifically, the reading process can be seen in the analysis of the V2 format structure in FIG. 5B.

The display of the memory snapshot file in the second storage format can be performed through a customized Unity plug-in interface, namely, a display interface of the first memory analyzer, so that the data display of the memory snapshot file in the second storage format is optimized, the memory object and the statistical type information can be analyzed more intuitively, and the snapshot file is compared.

Fig. 4C and 4D illustrate example interfaces of a memory snapshot file in a second storage format presented by a format conversion method for a memory snapshot file according to some embodiments of the present invention.

As shown in fig. 4C, the presentation effect of the memory snapshot information in the second storage format (V2) can be optimized through the interface of the customized first memory analyzer. For example, whether the data details are checked can be determined by clicking the triangle symbol in front of the data, the dependency relationship and the reference relationship of each data can be clearly seen in the data details, a data display mechanism of a memory snapshot interface in a V2 format is perfected, and the visualization degree of the data is improved. The interface shown in fig. 4C is similar to that shown in fig. 3C. In contrast to FIG. 3C, FIG. 4C illustrates not only the V2 snapshot object window, but also a derivative window of the pop-up window that shows a more detailed chain of references, i.e., the recursive chain of references shown in the figure, for one example object in the V2 snapshot object window, i.e., the object "0 x000009b90e 000" shown in FIG. 4C, in response to a user click operation on one example object in the V2 snapshot object window. As shown in fig. 4C, in the derivative window, each object below the object "0 x000009b90e 000" has a direct or indirect reference relationship with the object, and the index (index) field on the left may indicate the depth of each object in the reference chain of the tree structure. For example, the depth of the object "0 x000009b90e 000" is 0, that is, the root node of the reference chain, and other objects are all the child nodes at the lower layer or the child nodes at the lower layer; the triangle on the left of the object indicates that the node has child nodes, namely other objects are referred to; the direction of the triangle represents whether the reference chain of the node is opened, the downward represents the opening, and the rightward represents the non-opening; while objects without triangles represent leaf nodes, i.e. no other objects are referenced. In addition, other fields in the derived window have the same meaning as the fields in the original window and the window shown in fig. 3C, and are not described herein again. As can be seen from the derivative window in fig. 4C, the display of the memory snapshot file in the second storage format is optimized through the customized memory snapshot display interface of the first analyzer, and particularly, the reference chain information of the memory object can be clearly displayed in a tree structure, which is helpful for searching the reference relationship of the memory object, thereby providing necessary support for locating the memory leak.

Fig. 4D shows a comparison of memory snapshot files of two different second storage formats (V2). As shown in fig. 4D, the file names of the two snapshot files in the V2 format are: PVE-verylow-2.snap and 19-11-29-04-48-19. snap. The two snapshot files may be, for example, snapshot files of the same application at different running times, and it can be found out what changes occur in the memory information in the time period between the two running times through comparison, so that the problem of the memory in the running of the application can be found out. As shown in fig. 4D, the fields shown in the interface of the comparison graph are substantially the same as those in fig. 4C and 3C, except that fig. 4D shows a "Diff" field, which is specific to each object being "New", and indicates that the object shown in fig. 4D is a distinguishing object in two snapshot files, that is, a snapshot at a later time is a memory object newly added compared with a previous snapshot. Therefore, through the customized first memory analyzer plug-in, memory snapshot files in different V2 formats can be more clearly and intuitively found out to find out the difference between the two, thereby facilitating the positioning of the memory leakage source and the solving of the memory problem.

As shown in fig. 4A and 4B, optionally, the format conversion method for the memory snapshot file according to some embodiments of the present invention shown in fig. 3A may further include:

s406, the memory snapshot file in the first storage format is analyzed and displayed, wherein the memory snapshot file includes reference chain information of the memory object displayed in a tree structure. As described above, in some embodiments, the byte stream of the snapshot file may be subjected to an deserialization process to restore the state information of the memory object, i.e., the reference chain information of the memory object, so as to perform the subsequent presentation step.

Similar to step S405, the display of the memory snapshot file in the first storage format may also be optimized through a customized Unity plugin interface, that is, a display interface of the first memory analyzer, so that the data display of the memory snapshot file in the first storage format may be optimized, and the memory object and the statistical type information may be analyzed more intuitively.

Fig. 4E illustrates an example interface of a memory snapshot file in a first storage format exposed by a format conversion method for a memory snapshot file according to some embodiments of the present invention. As shown in fig. 4E, the presentation effect of the memory snapshot information in the first storage format (V1) can be optimized through the interface of the customized first memory analyzer. The interface shown in FIG. 4E is similar to that of FIG. 3B, except that, in comparison to FIG. 3B, FIG. 4E not only shows the V1 snapshot object classification presentation window, but also shows a derivative window of the pop-up window that shows a more detailed reference chain for one example object in the V1 snapshot object window, i.e., the V1 object reference chain shown in the figure, in response to a user click operation on one example object in the V1 snapshot object classification presentation window. As shown in fig. 4E, in the derivative window, each object below the example object nuketownttex _ D has a direct or indirect reference relationship with the object, and the Depth (Depth) field on the left may indicate the Depth of each object in the reference chain of the tree structure. For example, the nuketownttex _ D depth of the object is 0, i.e., the root node of the reference chain, and other objects are all the subnodes of the lower layer or subnodes of the lower layer; the triangle on the left of the object indicates that the node has child nodes, namely other objects are referred to; the direction of the triangle represents whether the reference chain of the node is opened, the downward represents the opening, and the rightward represents the non-opening; while objects without triangles represent leaf nodes, i.e. no other objects are referenced. In addition, other fields in the derived window have the same meaning as the fields in the original window and the window shown in fig. 3B, and are not described herein again. As can be seen from the derivative window in fig. 4E, the display of the memory snapshot file in the first storage format is optimized through the customized memory snapshot display interface of the first analyzer, and particularly, the reference chain of the memory object can be clearly displayed in a tree structure, which is helpful for searching the reference relationship of the memory object, thereby providing necessary support for locating the memory leak.

Fig. 5A and 5B show storage structure diagrams of the memory snapshot file in the first storage format (V1 format) and the memory snapshot file in the second storage format (V2 format), respectively.

For the first storage format (V1) snapshot, there are binary and json storage, wherein json storage is recommended by the authorities, because the binary storage is used, and the speed and the convenience in subsequent use are not as good as json file. The storage format of the V1 snapshot is described here by taking the json format as an example. The contents of the memory snapshot file in the format of V1 contain the object and type information in all snapshots, as well as the reference chain description. And (3) analyzing the file by using a unity memory profiler (V1) plug-in to obtain an object of the Snapshot type.

As shown in fig. 5A, the V1 memory snapshot mainly includes 8 data structures, i.e., four memory objects, two types of descriptions, C # heap, and game execution environment information. The four memory objects include: the engine C + + native object (NativeObject), object lifecycle management (GCHandle), C # managed object (managedoobject), static object (statfield). Two types of descriptions include: the engine C + + class descriptions (NativeTypes) for describing native objects and the C # type descriptions (TypeDescriptions) for describing managed objects (managedobjects) and static objects (StaticField). As shown in FIG. 5A, these four memory objects are subclasses of thinningInmemory, so these objects can be stored in the same object array AllObjects in type order. The reference relationship of each object can be identified by the positions of the array type elements. Thus, through these relationships, the content and reference chains of each object can be viewed directly. The two types of descriptions, native types and TypeDescriptions, are type information for describing memory objects.

As shown in fig. 5B, the data storage structure of the memory snapshot file in the second storage format (V2) includes: a Data content storage area Blocks Data 501 of the memory object, a description information storage area Chapters Data 502 of the memory object, a necessary address index information storage area, a Blocks Data Header 503, a Blocks Directory 504, a Chapters Directory 505, a version verification information storage area Foote 506, and the like.

The different storage areas or data structures of the second storage format are described below, respectively. Before the introduction, it is necessary to understand the differences in the data types in the first storage format and the second storage format. The data types of the memory objects in the snapshot file in the first storage format (V1) are referred to as first data types, and the number of the first data types is 58, such as int, float, class type (object), and the like. And the data type in the snapshot file of the second storage format (V2) is referred to as a second data type, which summarizes the above 58 types into three types, namely, constant (SingleValue), fixed size array (constantsizylarray), and dynamic size array (dynamicsizylarray).

As shown in fig. 5B, in the Blocks Data 501, the Data contents of the memory objects are stored in Blocks (Blocks), and the basis of the Blocks is the first Data type of the memory objects, i.e., the Data contents of the memory objects belonging to the same first Data type are grouped into one Data Block (Block), so that each Block contains the Data contents of all the memory objects belonging to the same type. Further, as shown in fig. 5B, in Blocks Data 501, for the purpose of saving memory when storing or writing Data, each Block is further subdivided into one or more Data segments (chunks), the size of which is generally fixed, and for example, may be equal to the size of a memory buffer for which storage is requested. In the process of storing Data of an internal memory object, writing the Data in each Block Data Block into a buffer until the buffer is full, and writing the Data in the buffer (namely, one Data segment of the Block, which is expressed as Block Chunk) into Blocks Data 501; the buffer is then emptied and the Block remaining Data continues to be written, and so on until the Data in the Block Data Block is all written in segments (Blocks) into Blocks Data. Therefore, as shown in fig. 5B, in the Data content storage area Blocks Data 501, the Data segment of each Block is actually stored and is denoted as Block i Chunk j, where i represents the number of Block and j represents the sequence number of Chunk. For example, Block 0 Chunk 0 shown in fig. 5B represents a data segment of the first of the data blocks Block 0.

As shown in fig. 5B, in the descriptor storage area Chapters Data 502 of the memory objects, descriptor blocks Chapter of a plurality of memory objects are stored. Each Chapter corresponds to a first data type, i.e. the number of chapters is the same as the number of first data types, and is 58. Each Chapter is configured to store description information of a memory object stored in a Block of a corresponding first data type, that is, a storage address or a location of the corresponding Block and a data type (the first data type and/or the second data type) of the memory object therein, and an offset location of data content of each memory object in the Block. Note that as shown in fig. 5B, although each Block has a corresponding Chapter, since the number of chapters is fixed (the number of first types is constantly equal to 58), and there may not be some first data type in the memory object in the target application (for example, there is no structure type), the number of blocks should be less than or equal to the number of chapters, that is, less than or equal to 58.

To summarize, for each Chapter, its effect is mainly three: 1. informing the data type of the corresponding Block (i.e. one of 58 in V1, so the number of chapters in the snapshot is equal to 58); 2. the memory object data content of the corresponding type is stored in which Block, namely, which Block corresponds to which memory object data content; 3. the offset location of the data content of each memory object in Block. If an object is stored in Block, the Chapter corresponding to the Block writes the description information of the object, which we refer to as an Entry. It was mentioned above that the V2 snapshot divides objects into three types: a Constant (SingleValue), a fixed Size Array (Constant Size Array), and a Dynamic Size Array (Dynamic Size Array). Therefore, there are three types of Entry structures, and the structures are shown in table 1 below.

TABLE 1 Structure of Entry

SingleValue Entry	ConstantSizeArray Entry	DynamicSizeArray Entry
			Entry size/offset within Block	Entry size	Block internal offset

As shown in fig. 5B, the address index information storage area in the second storage format includes Blocks Data Header 503, Blocks Directory 504, Chapters Directory 505, and the version authentication information storage area is Footer 506. First, the offset position of the Data segment Chunk of each Data Block (which may be referred to as Header information of each Block) is stored in the Blocks Data Header 503, and is used for addressing one or more chunks corresponding to each Block. The Blocks Directory 504 stores the offset position of each Block Header in the Blocks Data Header 503 for addressing the Header of each Block. Chapters Directory 505 stores the addresses of the respective pieces of description information Chapters in the Chapters Data 502 for addressing the respective Chapters; and a Block Directory Header Address (Block Directory Header Address) for addressing Block Directory 504. The font 506 is used for storing a Chapter Directory Header Address (Chapter Directory Header Address) in addition to the file tail information and the version verification information, and is used for addressing the Chapter Directory 505.

As can be seen from the storage structure of the second storage format shown in fig. 5B, in the process of storing or writing the memory snapshot information parsed from the memory snapshot file of the first storage format according to the second storage format, corresponding Data may be written into the memory regions one by one from top to bottom starting from the topmost memory region Blocks Data 501 of the storage structure shown in fig. 5B, so as to form the memory snapshot file of the second storage format. On the contrary, when the memory snapshot file in the second storage format is analyzed, the corresponding data are read from the bottom or the tail of the file one by one in the storage regions according to the sequence from bottom to top, so that the snapshot information is finally analyzed.

Fig. 6 schematically shows an example process of step S404 shown in fig. 4A. As shown in fig. 6, step S404 shown in fig. 4A, storing snapshot information of a memory object of a target application in a second storage format to a preset storage space to generate a memory snapshot file in the second storage format includes the following steps S601 to S608.

At step S601, a preset storage space is divided such that the preset storage space includes a first storage area, a second storage area, a third storage area, a fourth storage area, a fifth storage area, and a sixth storage area. According to the storage structure of the second storage format shown in fig. 5B, to realize the conversion from the first storage format to the second storage format, the preset storage space needs to be divided into a corresponding number of storage areas according to the structure shown in fig. 5B, and then corresponding data is written to form a required file. Therefore, as described in step S601, the preset storage space is divided into six storage areas, i.e., first to sixth storage areas, which may correspond to Blocks Data 501, Blocks Data Header 503, Blocks Directory 504, Chapters Data 502, Chapters Directory 505, and font 506, respectively, in the storage structure of the second storage format shown in fig. 5B. As described above, in the process of storing the snapshot information of the memory object as the memory snapshot file in the second storage format, corresponding data may be written in the sequence of the first to sixth storage areas, respectively, to form the memory snapshot file in the second storage format.

In step S602, the data content of the memory object is divided into one or more data blocks according to a first data type of the memory object, where each of the one or more data blocks includes the data content of the memory object of a first data type, and the first data type is a default data type of the memory snapshot file of the first storage format. Before writing the data content of the corresponding memory object into the first storage area, the data content of the memory object needs to be classified according to the first type according to the second storage format, that is, the memory object of the same first type is classified into one data Block (corresponding to Block shown in fig. 5B), so as to implement the classified storage of the data content of the memory object.

At step S603, each of the plurality of data blocks is divided into one or more segments, and the segments are sequentially written into the first storage area in a segment-by-segment writing manner, and the location of each segment of each data block in the first storage area and the offset location of each memory object in each data block in the data block are recorded. For the purpose of saving the memory, each data Block is further subdivided into one or more data segments (corresponding to Block Chunk in fig. 5B), and then each data Block is written into the first storage area segment by segment, and the offset position and address of each data Block in the first storage area need to be recorded for searching the data Block. The size of each data block is typically fixed and may, for example, be equal to the size of an applied memory buffer. In the process of writing each data block into the first storage area, firstly, sequentially writing the data content of each memory object in each data block into a buffer area until the buffer area is fully written (the data in the buffer area forms a data segment), and writing the data segment into the first storage area; the buffer is then emptied, and the remainder of the data block continues to be written, and so on until all of the data in the data block is written to the first storage area. Furthermore, while writing the data segments, it is necessary to record the location of each data segment in the first storage area for addressing it.

At step S604, the location of the respective segments of each data block in the first storage area is sequentially written into the second storage area as the header information of each data block, and the location of the header information of each data block in the second storage area is recorded. After writing the data content of the memory object, it is necessary to write address index information, i.e. the location of the data segment of the data content of the memory object recorded in step S605 in the first storage area, which may be referred to as header information of each data block, in the second storage area. Meanwhile, the position of each piece of header information in the second storage area is recorded while writing the piece of header information.

At step S605, the location of the header information of each data block in the second storage area is sequentially written into the third storage area as a directory of each data block, and the location of the directory of each data block in the third storage area is recorded. After the data block header information is written, it is necessary to write its index, i.e., the location of each recorded header information in the second storage area as the target of each data block, into the third storage area in turn, while recording the location of each data block directory in the third storage area.

At step S606, one or more description information blocks (corresponding to Chapter shown in fig. 5B) composed of description information for describing each of the one or more data blocks are sequentially written into the fourth storage area, and the position of each description information block in the fourth storage area is recorded, where the description information of each data block includes the first data type or the second data type of each memory object in the data block, and the offset position of each memory object in the data block, where the second data type is a default data type of the memory snapshot file in the second storage format. Each descriptor block may be used to describe the data type (first data type and/or second data type) of the memory object in the corresponding data block and other related information of the memory object therein.

At step S607, the location of the directory of each data block in the third storage area and the location of each description information block in the fourth storage area are sequentially written as the directory of each description information block in the fifth storage area. In this step, two kinds of index information are written into the fifth storage area, i.e. the location of the data block directory and the location of the description information block directory, respectively, for addressing the data block and the description information block, respectively.

At step S608, the location of the directory of each descriptive information block in the fifth storage area is written into the sixth storage area in turn as the header information of each descriptive information block and the trailer information is written into the sixth storage area. In some embodiments, the sixth storage area as the last storage area needs to write the file end information (e.g. including the version check information) and also needs to write the address index of the data in the fifth storage area, i.e. the header information of the description information block (used for searching the location of the directory of each description information block in the fifth storage area).

In the process of storing or writing the memory snapshot information parsed from the memory snapshot file in the first storage format according to the second storage format shown in fig. 6, corresponding Data is written into the first storage area (corresponding to Blocks Data 501) from the first storage area one by one according to the sequence of the first, second, third, fourth, fifth, and sixth storage areas, according to the storage structure in the second storage format shown in fig. 5B, so that the memory snapshot file in the second storage format can be formed.

In some embodiments, in contrast to the above process of forming the second storage format, in the process of parsing the memory snapshot file in the second storage format, corresponding data may be read from the tail of the memory snapshot file in the second storage format, and according to the order of the sixth storage, the fifth storage area, the fourth storage area, the third storage area, the second storage area, and the first storage area, the corresponding data may be read from the sixth storage area, the fifth storage area, the fourth storage area, the third storage area, the second storage area, and the first storage area, so as to obtain snapshot information of the memory object of the target application, thereby finally parsing the snapshot information.

Fig. 7 schematically illustrates an example block diagram of a format conversion device 700 for a memory snapshot file in accordance with some embodiments of the present invention. The format conversion device 700 for the memory snapshot file may correspond to the server 120 shown in fig. 1. The format conversion apparatus 700 for the memory snapshot file may include an obtaining module 710 and a converting module 720.

The receiving module 710 is configured to obtain a memory snapshot file of a first storage format of the target application, where the first storage format is a memory snapshot file format that is default for the first memory analyzer. The conversion module 720 is configured to convert the memory snapshot file in the first storage format into the memory snapshot file in the second storage format using the first memory analyzer, where the second storage format is a default memory snapshot file format of the second memory analyzer, and the second memory analyzer is an upgraded version of the first memory analyzer. The converting, by using the first memory analyzer, the memory snapshot file in the first storage format into the memory snapshot file in the second storage format may include: analyzing the memory snapshot file in the first storage format to acquire snapshot information of a memory object of the target application, wherein the snapshot information of the memory object comprises data content of the memory object; and storing the snapshot information of the memory object to a preset storage space in a second storage format to generate a memory snapshot file in the second storage format.

The format conversion device for the memory snapshot file provided by the invention focuses on realizing the conversion process from the first storage format (such as V1 format) of the low-version memory snapshot file to the second storage format (V2 format) of the high-version memory snapshot file by using a memory analyzer (V1) supporting a low-version engine application or a game. Specifically, in the format conversion apparatus for a memory snapshot file according to some embodiments of the present invention, after the memory snapshot file in the first storage format (V1 format) of the target application is obtained by using the receiving module, the memory snapshot file in the first storage format may be parsed by using the conversion module through the first memory analyzer (V1) to obtain snapshot information of the memory object, and the snapshot information is stored in the second storage format to the preset storage space to generate the memory snapshot file in the second storage format (V2 format), so as to implement conversion of the memory snapshot file from the first storage format to the second storage format. Therefore, the problem that in the related technology, a low-version memory analyzer (V1) is used for obtaining a low-version memory snapshot file in the memory detection and analysis process of a low-version engine application or a game at the same time, and a high-version memory analyzer (V2) is used for realizing format conversion is solved, the working process of game development and testing personnel is simplified, the working efficiency is improved, and the use cost of the memory analyzer in the memory detection and analysis process is reduced.

Fig. 8 schematically illustrates an example block diagram of a format conversion system 800 for a memory snapshot file in accordance with some embodiments of the present invention. The format conversion system 800 for a memory snapshot file may correspond to the example environment 100 shown in fig. 1 for the format conversion method for a memory snapshot file in accordance with the present invention. Format conversion system 800 for memory snapshot files may include a terminal device 810 and a server 820 communicatively connected to each other, which may correspond to terminal device 110 and server 120, respectively, shown in fig. 1. Format conversion system 800 for memory snapshot files may be used to implement format conversion methods for memory snapshot files according to some embodiments of the present invention. The server 820 may also correspond to the format conversion device 700 for the memory snapshot file shown in fig. 7.

As shown in fig. 8, the terminal device 810 includes: a first receiving module 811, a searching module 812, a determining module 813, a snapshot generating module 814, and a first transmitting module 815. The first receiving module 811 is configured to receive a memory snapshot file acquisition request for a target application from a server. The lookup module 812 is configured to lookup the direct reference relationship information of each of all memory objects when the target application is running. The determining module 813 is configured to determine reference chain information of each memory object of the target application according to the direct reference relationship information of each memory object. The snapshot generating module 814 is configured to generate a memory snapshot file of a first storage format of the target application according to the obtained reference chain information of each memory object of the target application, where the first storage format is a default memory snapshot file format of the first memory analyzer. The first sending module 815 is configured to send the memory snapshot file in the first storage format to the server 820.

As shown in fig. 8, the server 820 includes a second sending module 821, a second receiving module 822, a format conversion module 823, and a parsing presentation module 824. The second sending module 821 is configured to send a memory snapshot file obtaining request for the target application to the terminal device. The second receiving module 822 is configured to receive the memory snapshot file in the first storage format from the terminal device, where the first storage format is a memory snapshot file format that is default to the first memory analyzer. Format conversion module 823 is configured to convert, using a first memory analyzer, a memory snapshot file in a first storage format into a memory snapshot file in a second storage format, where the second storage format is a default memory snapshot file format of the second memory analyzer, and the second memory analyzer is an upgraded version of the first memory analyzer. The converting, by using the first memory analyzer, the memory snapshot file in the first storage format into the memory snapshot file in the second storage format may include: analyzing the memory snapshot file in the first storage format to acquire snapshot information of a memory object of the target application, wherein the snapshot information of the memory object comprises data content of the memory object; and storing the snapshot information of the memory object to a preset storage space in a second storage format to generate a memory snapshot file in the second storage format. The parsing presentation module 824 is configured to parse and present the memory snapshot file in the second storage format.

As shown in fig. 8, the format conversion system 800 for the memory snapshot file may, for example, start from the second sending module 821 of the server 820, and perform corresponding actions in sequence according to the arrow direction, so as to implement the format conversion method for the memory snapshot file according to some embodiments of the present invention. Specifically, first, the second sending module 821 sends a memory snapshot file obtaining request to the first receiving module 811 of the terminal device 810; subsequently, the terminal device 810 generates a memory snapshot file in a first storage format according to the memory snapshot file obtaining request by using the searching module 812, the determining module 813, and the snapshot generating module 814; next, the first sending module 815 of the terminal device 810 sends the memory snapshot file in the first storage format to the server 820; after receiving the memory snapshot file in the first storage format, the second receiving module 822 of the server 820 converts the memory snapshot file in the first storage format into the memory snapshot file in the second storage format by using the format conversion module 823, and then analyzes and restores snapshot information of the memory snapshot file in the second format by using the analysis and display module 824 and displays the snapshot information.

It should be noted that the various modules described above may be implemented in software or hardware or a combination of both. Several different modules may be implemented in the same software or hardware configuration, or one module may be implemented by several different software or hardware configurations.

FIG. 9 schematically illustrates an example block diagram of a computing device 900 in accordance with some embodiments of the invention. Computing device 900 may represent a device to implement various means or modules described herein and/or perform various methods described herein. Computing device 900 may be, for example, a server, a desktop computer, a laptop computer, a tablet, a smartphone, a smartwatch, a wearable device, or any other suitable computing device or computing system that may include various levels of devices from full resource devices with substantial storage and processing resources to low-resource devices with limited storage and/or processing resources. In some embodiments, format conversion device 700 for a memory snapshot file and format conversion system 800 for a memory snapshot file described above with respect to fig. 7 and 8 may be implemented in one or more computing devices 900, respectively.

As shown, the example computing device 900 includes a processing system 901, one or more computer-readable media 902, and one or more I/O interfaces 903 communicatively coupled to each other. Although not shown, the computing device 900 may also include a system bus or other data and command transfer system that couples the various components to one another. A system bus can include any one or combination of different bus structures, such as a memory bus or memory controller, a peripheral bus, a universal serial bus, and/or a processor or local bus that utilizes any of a variety of bus architectures. Alternatively, control and data lines, for example, may be included.

Processing system 901 represents functionality to perform one or more operations using hardware. Thus, the processing system 901 is illustrated as including hardware elements 904 that may be configured as processors, functional blocks, and so forth. This may include implementation in hardware as an application specific integrated circuit or other logic device formed using one or more semiconductors. The hardware elements 904 are not limited by the materials from which they are formed or the processing mechanisms employed therein. For example, a processor may be comprised of semiconductor(s) and/or transistors (e.g., electronic Integrated Circuits (ICs)). In such a context, processor-executable instructions may be electronically-executable instructions.

The computer-readable medium 902 is illustrated as including a memory/storage 905. Memory/storage 905 represents memory/storage associated with one or more computer-readable media. The memory/storage 905 may include volatile media (such as Random Access Memory (RAM)) and/or nonvolatile media (such as Read Only Memory (ROM), flash memory, optical disks, magnetic disks, and so forth). The memory/storage 905 may include fixed media (e.g., RAM, ROM, a fixed hard drive, etc.) as well as removable media (e.g., flash memory, a removable hard drive, an optical disk, and so forth). Illustratively, the memory/storage 905 may be used to store the first audio of the first category of users, the requested queuing list, etc. mentioned in the above embodiments. The computer-readable medium 902 may be configured in various other ways as further described below.

One or more I/O (input/output) interfaces 903 represent functionality that allows a user to enter commands and information to computing device 900, and also allows information to be displayed to the user and/or sent to other components or devices using various input/output devices. Examples of input devices include a keyboard, a cursor control device (e.g., a mouse), a microphone (e.g., for voice input), a scanner, touch functionality (e.g., capacitive or other sensors configured to detect physical touch), a camera (e.g., motion that does not involve touch may be detected as gestures using visible or invisible wavelengths such as infrared frequencies), a network card, a receiver, and so forth. Examples of output devices include a display device (e.g., a monitor or projector), speakers, a printer, a haptic response device, a network card, a transmitter, and so forth. Illustratively, in the above-described embodiments, the first category of users and the second category of users may input through input interfaces on their respective terminal devices to initiate requests and enter audio and/or video and the like, and may view various notifications and view video or listen to audio and the like through output interfaces.

Computing device 900 also includes format conversion policies 906. Format conversion policy 906 may be stored as computer program instructions in memory/storage 905. Format conversion policy 906 may implement all functions of the respective modules of format conversion device 700 for a memory snapshot file and format conversion system 800 for a memory snapshot file described with respect to fig. 7 and 8, along with processing system 901 and the like.

Various techniques may be described herein in the general context of software, hardware, elements, or program modules. Generally, these modules include routines, programs, objects, elements, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The terms "module," "functionality," and the like, as used herein generally represent software, firmware, hardware, or a combination thereof. The features of the techniques described herein are platform-independent, meaning that the techniques may be implemented on a variety of computing platforms having a variety of processors.

An implementation of the described modules and techniques may be stored on or transmitted across some form of computer readable media. Computer readable media can include a variety of media that can be accessed by computing device 900. By way of example, and not limitation, computer-readable media may comprise "computer-readable storage media" and "computer-readable signal media".

"computer-readable storage medium" refers to a medium and/or device, and/or a tangible storage apparatus, capable of persistently storing information, as opposed to mere signal transmission, carrier wave, or signal per se. Accordingly, computer-readable storage media refers to non-signal bearing media. Computer-readable storage media include hardware such as volatile and nonvolatile, removable and non-removable media and/or storage devices implemented in a method or technology suitable for storage of information such as computer-readable instructions, data structures, program modules, logic elements/circuits or other data. Examples of computer readable storage media may include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, Digital Versatile Disks (DVD) or other optical storage, hard disks, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or other storage devices, tangible media, or an article of manufacture suitable for storing the desired information and accessible by a computer.

"computer-readable signal medium" refers to a signal-bearing medium configured to transmit instructions to the hardware of computing device 900, such as via a network. Signal media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave, data signal or other transport mechanism. Signal media also includes any information delivery media. By way of example, and not limitation, signal media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media.

As previously described, the hardware element 904 and the computer-readable medium 902 represent instructions, modules, programmable device logic, and/or fixed device logic implemented in hardware form that may be used in some embodiments to implement at least some aspects of the techniques described herein. The hardware elements may include integrated circuits or systems-on-chips, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), Complex Programmable Logic Devices (CPLDs), and other implementations in silicon or components of other hardware devices. In this context, a hardware element may serve as a processing device that performs program tasks defined by instructions, modules, and/or logic embodied by the hardware element, as well as a hardware device for storing instructions for execution, such as the computer-readable storage medium described previously.

Combinations of the foregoing may also be used to implement the various techniques and modules described herein. Thus, software, hardware, or program modules and other program modules may be implemented as one or more instructions and/or logic embodied on some form of computer-readable storage medium and/or by one or more hardware elements 904. Computing device 900 may be configured to implement particular instructions and/or functions corresponding to software and/or hardware modules. Thus, implementing modules as modules executable by computing device 900 as software may be implemented at least partially in hardware, for example, using computer-readable storage media of a processing system and/or hardware elements 904. The instructions and/or functions may be executed/operable by, for example, one or more computing devices 900 and/or processing systems 901 to implement the techniques, modules, and examples described herein.

The techniques described herein may be supported by these various configurations of computing device 900 and are not limited to specific examples of the techniques described herein.

In some embodiments of the present invention, one or more computer-readable storage media are provided having computer-readable instructions stored thereon that, when executed, implement a format conversion method for a memory snapshot file in accordance with some embodiments of the present invention. The steps of the format conversion method for the memory snapshot file according to some embodiments of the present invention may be converted into computer readable instructions through programming, and stored in a computer readable storage medium. When such a computer-readable storage medium is read or accessed by a computing device or computer, the computer-readable instructions therein are executed by a processor on the computing device or computer to implement a format conversion method for a memory snapshot file according to some embodiments of the present invention.

In the description of the present specification, the description of the terms "one embodiment," "some embodiments," "an example," "a specific example," or "some examples" or the like, means that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the present invention. In this specification, the schematic representations of the terms used above are not necessarily intended to refer to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, various embodiments or examples and features of different embodiments or examples described in this specification can be combined and combined by one skilled in the art without contradiction.

Any process or method descriptions in flow charts or otherwise described herein may be understood as representing modules, segments, or portions of code which include one or more executable instructions for implementing steps of a custom logic function or process, and alternate implementations are included within the scope of the preferred embodiment of the present invention in which functions may be executed out of order from that shown or discussed, including substantially concurrently or in reverse order, depending on the functionality involved, as would be understood by those reasonably skilled in the art of the present invention.

The logic and/or steps represented in the flowcharts or otherwise described herein, e.g., an ordered listing of executable instructions that can be considered to implement logical functions, can be embodied in any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor-containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions. For the purposes of this description, a "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.

It should be understood that portions of the present invention may be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, the various steps or methods may be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, any one or a combination of the following techniques, which are well known in the art, may be used: a discrete logic circuit having a logic Gate circuit for realizing a logic function for a data signal, an application specific integrated circuit having an appropriate combinational logic Gate circuit, a Programmable Gate Array (Programmable Gate Array), a Field Programmable Gate Array (Field Programmable Gate Array), or the like.

It will be understood by those skilled in the art that all or part of the steps of the method of the above embodiments may be performed by hardware associated with program instructions, and that the program may be stored in a computer readable storage medium, which when executed, includes performing one or a combination of the steps of the method embodiments.

In addition, functional units in the embodiments of the present invention may be integrated into one processing module, or each unit may exist alone physically, or two or more units are integrated into one module. The integrated module can be realized in a hardware mode, and can also be realized in a software functional module mode. The integrated module, if implemented in the form of a software functional module and sold or used as a stand-alone product, may also be stored in a computer readable storage medium.

Claims

1. A format conversion method for a memory snapshot file comprises the following steps:

acquiring a memory snapshot file of a target application in a first storage format, wherein the first storage format is a default memory snapshot file format of a first memory analyzer;

converting the memory snapshot file in the first storage format into a memory snapshot file in a second storage format by using a first memory analyzer, wherein the second storage format is a default memory snapshot file format of the second memory analyzer, and the second memory analyzer is an upgraded version of the first memory analyzer,

the converting the memory snapshot file in the first storage format into the memory snapshot file in the second storage format by using the first memory analyzer includes:

analyzing the memory snapshot file in the first storage format to acquire snapshot information of a memory object of the target application, wherein the snapshot information of the memory object comprises data content of the memory object; and

and storing the snapshot information of the memory object to a preset storage space in a second storage format to generate a memory snapshot file in the second storage format.

2. The method of claim 1, wherein a first memory analyzer is used for first engine based applications, a second memory analyzer is used for second engine based applications, and the second engine is an upgraded version of the first engine.

3. The method according to claim 1, wherein the storing the snapshot information of the memory object of the target application in a second storage format to a preset storage space to generate a memory snapshot file in the second storage format comprises:

dividing a preset storage space to enable the preset storage space to comprise a first storage area, a second storage area, a third storage area, a fourth storage area, a fifth storage area and a sixth storage area;

dividing the data content of the memory object into one or more data blocks according to the difference of a first data type of the memory object, wherein each data block in the one or more data blocks comprises the data content of the memory object of a first data type, and the first data type is a default data type of a memory snapshot file of a first storage format;

dividing each data block in the one or more data blocks into one or more segments, sequentially writing the one or more segments of each data block into a first storage area in a segment-by-segment writing mode, and recording the position of each segment of each data block in the first storage area and the offset position of the data content of each memory object in each data block in the data block;

sequentially writing the position of each segment of each data block in the first storage area as the head information of each data block into the second storage area, and recording the position of the head information of each data block in the second storage area;

the position of the head information of each data block in the second storage area is used as a directory of each data block to be sequentially written into a third storage area, and the position of the directory of each data block in the third storage area is recorded;

sequentially writing one or more description information blocks respectively composed of description information for describing each of the one or more data blocks into a fourth storage area, and recording the position of each of the one or more description information blocks in the fourth storage area, wherein the description information of each data block comprises a first data type or a second data type of each memory object in the data block, and an offset position of the data content of each memory object in the data block, and the second data type is a default data type of the memory snapshot file in the second storage format;

sequentially writing the position of the directory of each data block in the third storage area and the position of each description information block in the fourth storage area as the directory of each description information block in the fifth storage area;

and sequentially writing the position of the directory of each description information block in the fifth storage area as the head information of each description information block into the sixth storage area and writing the file tail information into the sixth storage area.

4. The method of claim 3, wherein the first data type comprises at least one of 58 data types and the second data type comprises at least one of a constant, a fixed size array, and a dynamic size array.

5. The method of claim 1, wherein the obtaining the memory snapshot file of the target application in the first storage format comprises:

sending a memory snapshot obtaining request to the terminal equipment to instruct the terminal equipment to generate a memory snapshot file of a first storage format of the target application in the following mode:

searching direct reference relation information of each memory object in all memory objects when the target application runs;

determining reference chain information of each memory object according to the direct reference relation information of each memory object;

generating a memory snapshot file of a first storage format of the target application according to the reference chain information of each memory object of the target application,

6. The method of claim 5, further comprising:

and analyzing and displaying the memory snapshot file in the first storage format, wherein the memory snapshot file comprises reference chain information of at least one of all memory objects displayed in a tree structure.

7. The method according to claim 5, wherein the direct reference relationship information of each memory object comprises meta information of a direct reference object and/or a direct referenced object of the memory object.

8. The method of claim 5, wherein the receiving the memory snapshot file of the first storage format from the terminal device comprises:

receiving a file path of a memory snapshot file in a first storage format from terminal equipment;

and receiving the memory snapshot file in the first storage format from the terminal equipment according to the file path.

9. The method of claim 3, further comprising:

and analyzing and displaying the memory snapshot file in the second storage format by using the first memory analyzer.

10. The method of claim 9, wherein the parsing and exposing the memory snapshot file in the second storage format using the first memory analyzer comprises:

and reading the memory snapshot file in the second storage format according to the sequence of the sixth storage area, the fifth storage area, the fourth storage area, the third storage area, the second storage area and the first storage area to acquire snapshot information of the memory object of the target application.

11. The method of claim 10, wherein the parsing and exposing the memory snapshot file in the second storage format using the first memory analyzer further comprises:

and displaying the reference chain information of the memory object in a tree structure.

12. A format conversion device for a memory snapshot file, comprising:

the acquisition module is configured to acquire a memory snapshot file of a target application in a first storage format, wherein the first storage format is a default memory snapshot file format of the first memory analyzer;

a conversion module configured to convert the memory snapshot file in the first storage format into the memory snapshot file in the second storage format by using a first memory analyzer, where the second storage format is a default memory snapshot file format of the second memory analyzer, and the second memory analyzer is an updated version of the first memory analyzer, and where the conversion module converts the memory snapshot file in the first storage format into the memory snapshot file in the second storage format by using the first memory analyzer, the conversion module includes: analyzing the memory snapshot file in the first storage format to acquire snapshot information of a memory object of the target application, wherein the snapshot information of the memory object comprises data content of the memory object; and storing the snapshot information of the memory object to a preset storage space in a second storage format to generate a memory snapshot file in the second storage format.

13. A format conversion system for memory snapshot files comprises a terminal device and a server,

wherein the terminal device includes:

a first receiving module configured to receive a memory snapshot file acquisition request for a target application from a server;

the searching module is configured to search the direct reference relation information of each memory object in all the memory objects when the target application runs;

the determining module is configured to determine reference chain information of each memory object of the target application according to the direct reference relation information of each memory object;

the snapshot generating module is configured to generate a memory snapshot file of a first storage format of the target application according to the reference chain information of each memory object of the target application, wherein the first storage format is a memory snapshot file format which is default by the first memory analyzer;

a first sending module configured to send the memory snapshot file of the first storage format to the server, an

The server includes:

the second sending module is configured to send a memory snapshot file acquisition request for the target application to the terminal device;

the second receiving module is configured to receive the memory snapshot file in the first storage format from the terminal equipment;

a format conversion module configured to convert the memory snapshot file in the first storage format into the memory snapshot file in the second storage format by using a first memory analyzer, where the second storage format is a default memory snapshot file format of the second memory analyzer, and the second memory analyzer is an upgraded version of the first memory analyzer, where the converting the memory snapshot file in the first storage format into the memory snapshot file in the second storage format by using the first memory analyzer includes: analyzing the memory snapshot file in the first storage format to acquire snapshot information of a memory object of the target application, wherein the snapshot information of the memory object comprises data content of the memory object; storing the snapshot information of the memory object to a preset storage space in a second storage format to generate a memory snapshot file in the second storage format;

and the analysis display module is configured to analyze and display the memory snapshot file in the second storage format.

14. A computing device, comprising:

a processor; and

a memory having instructions stored thereon that, when executed on the processor, cause the processor to perform the method of any of claims 1-11.

15. One or more computer-readable storage media having computer-readable instructions stored thereon that, when executed, implement the method of any of claims 1-11.