Parsing method, parsing apparatus, and parsing system

Abstract

The present application provides a parsing method, a parsing apparatus, and a parsing system. The method comprises: in response to out of memory corresponding to a first application program, generating a first file, the first file comprising memory information of the first application program; generating a third file on the basis of the first file and a second file, the second file being a metadata file of the first application program; and sending the third file to a second device. The parsing method, the parsing apparatus, and the parsing system provided in the present application can avoid the process of acquiring memory information from depending on the survival of an application program, thereby reducing the power consumption and memory usage of the process, and improving user experience.

Description

Analysis methods, analysis devices and analysis systems

[0001] This application claims priority to Chinese Patent Application No. 202510103799.5, filed on January 22, 2025, entitled "Analysis Method, Analysis Apparatus and Analysis System", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to computer technology, and more specifically, to a parsing method, parsing apparatus, and parsing system. Background Technology

[0003] To analyze application memory issues, relevant memory information can be obtained through online HeapDump analysis. However, this online analysis method currently requires significant power and memory, and depends on the application's continued operation; applications are often killed due to insufficient memory.

[0004] Therefore, how to avoid the process of obtaining memory information depending on the survival of the application, reduce the power consumption and memory occupation of this process, and thus improve the user experience is an urgent problem to be solved. Summary of the Invention

[0005] This application provides a parsing method, parsing apparatus, and parsing system. The method can avoid the process of obtaining memory information depending on the survival of the application, thereby reducing the power consumption and memory usage of this process.

[0006] In a first aspect, a parsing method is provided, which is applied to a first device. The method includes: generating a first file in response to insufficient memory corresponding to a first application, the first file including memory information of the first application; generating a third file based on the first file and a second file, the second file being metadata files of the first application; and sending the third file to a second device.

[0007] It is understandable that the first device can include multiple applications, and the first application can be any application on the first device. Each time an out-of-memory (OOM) scenario is triggered, a first file is generated. The out-of-memory error corresponding to the first application can be understood as the first application having insufficient available memory.

[0008] For example, the first device can be a terminal device. The first file is a rawheap binary file. When the memory corresponding to the first application is insufficient, a rawheap file is generated first; this process temporarily depends on the survival of the first application. The first file may include the memory information of the first application, which can be information about all objects on the current memory heap of the first application. The process of generating the first file can be understood as the process of collecting the rawheap file.

[0009] For example, the second file could be a metadata.json file, which can be understood as an offline parsing tool used to statically describe the layout of objects in the virtual machine heap. The layout of objects is usually determined at compile time, so it can be represented statically using a metadata.json file.

[0010] For example, the layout of an object can be the storage structure and organization of the object in memory, used to describe how the various components of the object are arranged and stored in memory.

[0011] Alternatively, the metadata.json file is a static configuration file that is automatically generated by a script during compilation.

[0012] For example, the metadata.json file is located in the code repository at: out\generic_generic_arm_64only\general_all_phone_st andard\gen\arkcompiler\ets_runtime.

[0013] For example, the metadata.json file is located in the terminal device at: system / lib64 / module / arkcompiler.

[0014] Optionally, when an application experiences an OOM (Out of Memory) error, a dump process is triggered to generate a rawheap binary file. Additionally, a metadata.json file can be written to the rawheap file, ultimately generating an integrated file, which is the .rawheap result file.

[0015] For example, the third file is a .rawheap result file.

[0016] Understandably, each object has its own metadata.json file, which records the object's layout information. During image compilation, the metadata.json files of all objects can be concatenated into a single file.

[0017] Based on the above scheme, when an application experiences an OOM (Out of Memory) error, the terminal device first generates a rawheap file containing the application's memory information, packages the rawheap file and the application's metadata file into a .rawheap file, and uploads the .rawheap file to the host computer. Even if the application is offline due to an OOM error, a file containing memory information can still be generated so that developers can analyze memory problems and reduce power consumption and memory usage.

[0018] In conjunction with the first aspect, in some implementations of the first aspect, generating a third file based on the first file and the second file includes: generating the third file based on the first file and the second file in response to the first application being closed.

[0019] Understandably, when the first application runs out of memory, it will be killed according to the appfreeze mechanism. Here, the first application being closed can be understood as being killed due to an OutOfMemoryError (OOM).

[0020] Based on the above scheme, the rawheap file and the application's metadata file can be merged into a .rawheap file when the application is offline. This process does not depend on the online status of the application and does not require excessive memory or power consumption.

[0021] In conjunction with the first aspect, in some implementations of the first aspect, generating a first file in response to insufficient memory corresponding to the first application includes: determining a first thread as the thread in the first application experiencing insufficient memory in response to insufficient memory of the first application; scanning objects of the first thread and storing information of the objects in a first memory; and generating the first file based on the information of the objects in the first memory.

[0022] For example, the information about an object may include the object's description and its memory information. The first thread is the thread in the first application where the OutOfMemoryError (OOM) occurred.

[0023] Optionally, the object's description information can be an object header, and the object's content information can be the object's raw data. When the application's corresponding memory is insufficient, the objects on the thread where the OOM occurred are scanned, and the object header (object description information) and object content (object content information) are written to the cache (first memory). The object description information and object content information are first written to the first memory for storage. After all objects have been saved, they are then written to the rawheap file in a unified manner, thereby generating the first file.

[0024] Based on the above scheme, objects on the thread where OOM occurs can be scanned, and the object headers and raw data of the objects can be stored in the first memory. After all objects are saved, they can be written to the first file in a unified manner, which improves the efficiency of this process.

[0025] In conjunction with the first aspect, in some implementations of the first aspect, the object of the first thread includes local heap objects and / or shared heap objects.

[0026] Understandably, an object allocated by a thread within its own heap memory area can only be used and accessed by the thread that created it, and cannot be shared by other threads; this object can be a local heap object. An object in heap memory that is shared by multiple threads can be a shared heap object.

[0027] In conjunction with the first aspect, in some implementations of the first aspect, the second file includes a first field and a second field, wherein the first field is used to represent the type name of the object of the first application, and the second field is used to represent the information of the object of the first application, the information of the object of the first application including one or more of the following: the names of each attribute in the object of the first application, the offset of the object of the first application, the size of the object of the first application, and the inheritance relationship of the object of the first application.

[0028] For example, the first field could be a type enumeration field (type_enum) used to enumerate the type names of all objects. The second field could be a type list field (type_list) that can include specific details, such as: the name of each property in the first application ("name":"propertyName1"), the offset of the object in the first application ("offsets":xx), the size of the object in the first application ("end_offset":xx), and the inheritance relationship of the object in the first application ("parents":{"parentObjName1"}).

[0029] Based on the above scheme, the metadata.json files of each object in the first application can be concatenated to obtain the second file.

[0030] In conjunction with the first aspect, in some implementations of the first aspect, the first device is configured with a first file format, wherein generating a third file based on the first file and the second file includes: generating the third file according to the first file format based on the first file and the second file.

[0031] Based on the above scheme, the file format of the third file can be pre-defined, and the third file can be generated according to the first and second files based on the pre-defined file format.

[0032] In conjunction with the first aspect, in some implementations of the first aspect, the first file format includes a third field and a fourth field. The third field is used to determine the beginning of the metadata file of the first application, and the fourth field is used to determine a first region of the first file format. The first region includes first information used to read the root node of the first application. The first region also includes second information used to read a string table. The first region also includes third information used to cyclically read objects of the first application.

[0033] For example, the first information may include a first element and a second element, the second information may include a second element and a third element, and the third information may include a fourth element and a fifth element.

[0034] For example, the third field could be `sectionOffset`, and the fourth field could be `sectionSize`. The `sectionOffset` field determines the start of the metadata, and the `sectionSize` field allows reading the first region (the entire section). The entire section can be defined from `rootOffset` (representing the start of the root node) to `unitSize` (representing the unit size) next to `sectionSize` (representing the number of directories). Specifically, the first element is `rootOffset`, the second element is the size next to `rootOffset`, the third element is `stringTableOffset`, the fourth element is the size next to `stringTableOffset`, the fifth element is `addrTableOffset`, and the sixth element is `unitSize` next to `ddrTableOffset`.

[0035] Secondly, a parsing method is provided, which is applied to a second device. The method includes: receiving a third file from a first device, the third file being generated from a first file and a second file, the first file including memory information of a first application, the second file being metadata file of the first application, and the first application on the first device having insufficient memory; and parsing the third file.

[0036] Based on the above scheme, the host computer receives the .rawheap file from the terminal device and parses the .rawheap file. Even if the application is offline, developers can analyze the application's memory issues by parsing the .rawheap file, and it consumes less power and memory.

[0037] In conjunction with the second aspect, in some implementations of the second aspect, the parsing of the third file includes: parsing the third file to obtain a parsing result; and, based on the parsing result, prompting the user with a memory problem of the first application.

[0038] For example, the parsing result could be a fourth file, which is a .heapsnapshot file. By parsing the .heapsnapshot file with the first file structure, the host computer can determine the memory problem of the first application, which could be the cause of insufficient memory for the first application.

[0039] In conjunction with the second aspect, in some implementations of the second aspect, the second device is configured with a first file format, and the third file has the first file format, which includes a third field and a fourth field. Parsing the third file to obtain a parsing result includes: reading the metadata file of the first application based on the third field; determining a first region of the first file format based on the fourth field, the first region including first information, second information, and third information; reading the root node of the first application based on the first information; reading a string table based on the second information; cyclically reading the objects of the first application based on the third information; and establishing object nodes and object edges for the objects of the first application to obtain the parsing result.

[0040] For example, first read the `sectionOffset` (indicating the beginning of the directory) to determine the metadata file to read, and then determine the size of the metadata file based on the `size` field next to `sectionOffset`. The directory structure from `rootOffset` (indicating the beginning of the root node) to `unitSize` (indicating the unit size) next to `sectionSize` (indicating the number of directories) represents the raw heap file directory. First, read `rootOffset` to determine the offset of `root`, i.e., determine the line containing `rootNum` (indicating the number of root nodes). By reading `rootNum` and the adjacent `unitSize` field, determine the number of root nodes and the size of each root node, and read each root node sequentially, thus reading the entire `rootTable`. Next, read `stringTableOffset` (indicating the beginning of the `stringTable`) to determine the offset of `stringTable`, i.e., determine the line containing `stringNum` (indicating the number of strings). By reading `stringNum`, determine the number of strings. The code sequentially reads `string1Size` (representing the size of the string `string1`), `objNum` (representing the number of objects related to `string1`), and `objAddr` (representing the object address). Based on the number of strings, it reads other strings sequentially, such as `string2`, `string3`, etc., thus reading the entire `stringTable`. Next, it reads `addrTableOffset` (representing the start of `addrTable`) to determine the offset of the table, i.e., to determine the row where the offset table is located at `addrTableNum` (representing the number of tables). By reading `addrTableNum`, it determines the number of tables and reads each table sequentially, such as `table1`, `table2`, etc. It reads from a section loop, reading a block of memory information in each loop and creating a node for each object, thus serializing and outputting the `.heapsnapshot` file.

[0041] Thirdly, a parsing apparatus is provided, comprising: a processing unit configured to generate a first file in response to insufficient memory corresponding to a first application, the first file including memory information of the first application; further configured to generate a third file based on the first file and a second file, the second file being metadata files of the first application; and a transceiver unit configured to send the third file to a second device.

[0042] In conjunction with the third aspect, in some implementations of the third aspect, the processing unit is specifically configured to generate the third file based on the first file and the second file in response to the first application being closed.

[0043] In conjunction with the third aspect, in some implementations of the third aspect, the processing unit is specifically configured to, in response to insufficient memory in the first application, determine that the first thread is the corresponding thread in the first application that is experiencing insufficient memory; further configured to, scan the objects of the first thread and store the information of the objects in the first memory; and further configured to, generate the first file based on the information of the objects in the first memory.

[0044] In conjunction with the third aspect, in some implementations of the third aspect, the object of the first thread includes local heap objects and / or shared heap objects.

[0045] In conjunction with the third aspect, in some implementations of the third aspect, the second file includes a first field and a second field, wherein the first field is used to represent the type name of the object of the first application, and the second field is used to represent the information of the object of the first application, the information of the object of the first application including one or more of the following: the names of each attribute in the object of the first application, the offset of the object of the first application, the size of the object of the first application, and the inheritance relationship of the object of the first application.

[0046] In conjunction with the third aspect, in some implementations of the third aspect, the first device is configured with a first file format, and the processing unit is specifically used to generate the third file according to the first file format based on the first file and the second file.

[0047] In conjunction with the third aspect, in some implementations of the third aspect, the first file format includes a third field and a fourth field. The third field is used to determine the beginning of the metadata file of the first application, and the fourth field is used to determine a first region of the first file format. The first region includes first information used to read the root node of the first application. The first region also includes second information used to read a string table. The first region also includes third information used to cyclically read objects of the first application.

[0048] Fourthly, a parsing apparatus is provided, comprising: a transceiver unit for receiving a third file from a first device, the third file being generated from a first file and a second file, the first file including memory information of a first application, the second file being metadata of the first application, and the first application having insufficient memory on the first device; and a processing unit for parsing the third file.

[0049] In conjunction with the fourth aspect, in some implementations of the fourth aspect, the processing unit is specifically used to parse the third file to obtain the parsing result; it is also used to prompt the user about the memory problem of the first application based on the parsing result.

[0050] In conjunction with the fourth aspect, in some implementations of the fourth aspect, the second device is configured with a first file format, and the third file has the first file format, which includes a third field and a fourth field. Specifically, the processing unit is configured to: read the metadata file of the first application based on the third field; determine a first region of the first file format based on the fourth field, the first region including first information, second information, and third information; read the root node of the first application based on the first information; read a string table based on the second information; cyclically read the objects of the first application based on the third information; and establish object nodes and object edges for the objects of the first application to obtain the parsing result.

[0051] Fifthly, a parsing system is provided, the parsing system comprising a first device and a second device, wherein the first device is configured to perform the method as described in the first aspect and any possible implementation thereof, and the second device is configured to perform the method as described in the second aspect and any possible implementation thereof.

[0052] In a sixth aspect, an electronic device is provided for performing the methods of the first aspect and any possible implementation thereof, or for performing the methods of the second aspect and any possible implementation thereof.

[0053] In a seventh aspect, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a computer, causes the computer to implement the methods of the first aspect and any possible implementation thereof, or to perform the methods of the second aspect and any possible implementation thereof.

[0054] Eighthly, a computer program product comprising instructions is provided, which, when run on a computer, causes the computer to perform the methods of the first aspect and any possible implementation thereof, or to perform the methods of the second aspect and any possible implementation thereof.

[0055] In a ninth aspect, a chip is provided, the chip including a processor and a data interface, the processor reading instructions stored in a memory through the data interface to execute methods as described in the first aspect and any possible implementation thereof, or to execute methods as described in the second aspect and any possible implementation thereof. Attached Figure Description

[0056] Figure 1 is a schematic diagram of a scenario provided by an embodiment of this application.

[0057] Figure 2 is a schematic diagram of an analysis method provided in an embodiment of this application.

[0058] Figure 3 is a schematic diagram of a rawheap file writing process provided in an embodiment of this application.

[0059] Figure 4 is a schematic flowchart of an analysis method provided in an embodiment of this application.

[0060] Figure 5 is a schematic block diagram of a parsing device provided in an embodiment of this application. Detailed Implementation

[0061] The technical solutions in this application will now be described with reference to the accompanying drawings.

[0062] The terminology used in the following embodiments is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. As used in the specification and appended claims of this application, the singular expressions “a,” “an,” “the,” “the,” “the,” and “this” are intended to also include expressions such as “one or more,” unless the context clearly indicates otherwise. It should also be understood that in the following embodiments of this application, “at least one” and “one or more” refer to one, two, or more than two. The term “and / or” is used to describe the relationship between related objects, indicating that three relationships may exist; for example, A and / or B can indicate: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character “ / ” generally indicates that the preceding and following related objects are in an “or” relationship.

[0063] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0064] Before formally introducing the embodiments of this application, some terms that may be used in the following embodiments will be explained and described.

[0065] Heap dump

[0066] It is a memory analysis tool that can obtain the memory state of a program at a certain moment, and is used to detect and optimize memory leaks and memory usage. It helps developers efficiently detect and optimize memory usage, and improve program performance and stability.

[0067] HeapDump files contain detailed information about all objects in the heap memory, including reference relationships between objects and object sizes. Analyzing this information can help understand an application's memory usage or the cause of memory leaks.

[0068] Out of memory (OOM)

[0069] An OutOfMemoryError (OOM) occurs when an application attempts to access more memory than is available on the system. This typically causes the application to terminate abruptly, and related error information will be output to the logs or console.

[0070] The parsing method provided in this application embodiment can be applied to OOM scenarios.

[0071] App Freeze Mechanism

[0072] HarmonyOS provides an application freezing mechanism that kills applications that have been unresponsive for an extended period. The parsing method provided in this application also generates a file containing memory information after an application has been killed due to prolonged inactivity, for use in analyzing memory issues.

[0073] rawheap file

[0074] In the HarmonyOS system, a rawheap file is a file used to record heap memory information when an application experiences an OutOfMemoryError (OOM) in ArkTS (Ark TypeScript). When an OOM occurs, information about all objects on the current heap can be scanned and saved, and a rawheap file can be generated. The rawheap file includes detailed memory usage information, such as object reference relationships and class information.

[0075] metadata.json file

[0076] It is a metadata file, typically used to store configuration information for applications or components.

[0077] .heapsnapshot file

[0078] A .heapsnapshot file is a snapshot file used to record the heap memory state of an application at a certain point in time, and is used to analyze memory usage. In the parsing method provided in this application embodiment, a .heapsnapshot file can be generated, and by parsing the .heapsnapshot file, memory problems in the application can be analyzed.

[0079] Currently, application memory issues can be analyzed using HeapDump parsing. Current HeapDump parsing methods are all online, meaning that HeapDump obtains complete memory information from the device while the application is still running, in order to analyze application memory problems.

[0080] HarmonyOS currently supports an automatic memory dump function when an application experiences an OutOfMemoryError (OOM). However, because the application consumes a large amount of memory during an OOM, the online HeapDump parsing process becomes very time-consuming. Furthermore, HarmonyOS provides an appfreeze mechanism that kills applications that have experienced an OOM and have been unresponsive for an extended period. However, online HeapDump parsing relies on the application's surviving process; if the process is killed, a file containing memory information cannot be generated, making it impossible to analyze the application's memory problems.

[0081] Therefore, this application provides a parsing method, parsing device, and parsing system. When an application is OOM (Out of Memory), an offline parsing method is used to generate a file containing memory information. This allows developers to use tools to parse the file to determine the application's memory problem as needed. This parsing method does not depend on the application's liveness, which can reduce the power consumption and memory usage of HeapDump, avoid affecting other applications, and improve the user experience.

[0082] For ease of understanding, Figure 1 illustrates a scenario provided by an embodiment of this application. This scenario includes a terminal device side and a host computer side. The terminal device side may include multiple applications, including application A, application B, application C, and application D. The host computer side may be the developer's personal computer or a big data platform.

[0083] For example, when application C on the terminal device side experiences an OutOfMemoryError (OOM), the current memory of application C can be binary dumped, and the corresponding file can be generated, packaged, and sent to the host computer. Developers can use tools to parse the file as needed to determine the memory problem of application C.

[0084] The analysis method provided in the embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0085] Figure 2 illustrates a schematic diagram of a parsing method provided in an embodiment of this application. This method is applied to a system architecture including both a terminal device side and a host computer side. The method mainly includes the following steps:

[0086] Step 1: When an OOM occurs in the application on the terminal device side, a binary dump process is triggered to generate a rawheap binary file.

[0087] For example, when any application on the terminal device experiences an OOM (Out of Memory) error, a rawheap binary file needs to be generated first.

[0088] Understandably, each time an OOM (Out of Memory) event is triggered, a rawheap binary file is generated. If an OOM occurs in the current application, a rawheap binary file is generated.

[0089] Understandably, the online HeapDump parsing process relies on the application's continued existence. When an application experiences an OutOfMemoryError (OOM), a .heapsnapshot file is directly generated, but this process is very time-consuming. In contrast, the parsing method provided in this application uses offline parsing. When an application experiences an OOM, a rawheap binary file is generated, a process that relies on the application's continued existence. That is, while the application is alive, a rawheap binary file is first generated, containing information about the OOM occurrence. Subsequently, according to the appfreeze mechanism, the application is killed, and the remaining steps can be executed after the application is killed.

[0090] In other words, steps two through four below can be performed offline.

[0091] For ease of understanding, Table 1 below illustrates a rawheap file format. Terminal devices can be pre-configured with the rawheap file format shown in Table 1.

[0092] Table 1 Rawheap file format

[0093] For example, each row in Table 1 can represent 8 bytes. The top of Table 1 is the file header, and the bottom is the file footer. Here, `version` represents the version number, which can be represented using 8 bytes. `rootNum` represents the number of root nodes, `unitSize` represents the unit size, and `addr` represents the address. `stringNum` represents the number of strings, `unused` indicates that the field is not currently used, `string1Size` represents the size of the string `string1`, `objNum` represents the number of objects related to `string1`, `objAddr` represents the object address, and the specific content repeated in `string` is related to `stringNum`. Based on `stringNum`, there may be `string2`, `string3`, etc., and so on, repeating the content from `string1Size` to `string1`. `addrTableNum` represents the number of tables, `unitSize` represents the unit size, and below are `table1`, `table2`, etc., corresponding to N tables. `objMem` represents the object content, that is, the raw data of the object (the content of the rawheap binary file). `rootOffset` represents the start of the root node, `stringTableOffset` represents the start of the `stringTable`, and `addrTableOffset` represents the start of the `addrTable`. `section` represents a directory, and `sectionSize` represents the number of directories.

[0094] Understandably, when an application experiences an OutOfMemoryError (OOM), a rawheap file with the above format can be generated.

[0095] For example, as shown in Figure 3, a schematic diagram of a raw heap file writing process is illustrated. This process mainly includes the following steps:

[0096] 1. The main thread writes the version number.

[0097] 2. The main thread writes to the root node.

[0098] 3. The main thread writes the description information of the cached object.

[0099] It is understandable that the description information written by the main thread is a Table, which is the description information of the object.

[0100] For example, the main thread writes description information for objects A, B, and C. `offset A` represents the offset of object A relative to a reference point. This offset is a relative position, representing the distance from the reference point to the starting address of object A. `address A` represents the actual memory address of object A, which can be used to access object A's data. `offset C = Size(A)` means that the starting position of object C in memory is offset from the starting position of object A by an offset equal to the size of object A. `address C` represents the actual memory address of object C. `offset B` represents the offset of object B relative to the reference point, and `address B` represents the actual memory address of object B.

[0101] 4. Multiple threads can cache the raw data of objects simultaneously.

[0102] For example, multithreading includes thread A and thread B. Thread A caches the raw data of object A and object C, while thread B caches object B.

[0103] For example, raw data of an object typically refers to the raw, unprocessed or uninterpreted data of the object stored in memory. This data reflects the object's internal structure and state. When performing memory analysis, tools can directly access the object's raw data to determine the object's size, memory usage, and so on.

[0104] It is understandable that multiple threads are caching the raw data of the object, i.e., objMem in Table 1.

[0105] For example, the raw data of objects that multiple threads need to cache simultaneously can be determined by using the object description information written by the main thread.

[0106] 5. The main thread writes to the string table.

[0107] 6. The main thread writes the raw data of the object.

[0108] For example, after thread A finishes processing the object, the main thread writes the object.

[0109] For example, offset A = 0 + the size of object A header (50M), offset B = 0 + the size of A-section + the size of object B header.

[0110] 7. The main thread writes to the end of the file.

[0111] It is easy to see that the rawheap file writing process shown in Figure 3 corresponds to the rawheap file format in Table 1.

[0112] It is understandable that the process of generating the rawheap binary file in step one can be understood as the rawheap file acquisition process.

[0113] For example, the process of a terminal device collecting rawheap files may include the following steps:

[0114] (1) Linearly scan all local heap objects and write them to the rawheap file.

[0115] For example, a local heap object can be a local heap object.

[0116] For example, typically in a multithreaded environment, an object allocated by a thread in its own heap memory area is only used and accessed by the thread that created it and is not shared by other threads. This object can be a local heap object.

[0117] Understandably, when an application experiences an OOM (Out of Memory) error, a linear scan is performed on all local heap objects on the thread where the OOM occurred.

[0118] Optionally, the object header and object content can be written to the cache and then to the raw heap file. The object header can be a description of the object (table), and the object content can be the object's raw data. The process of writing to the cache can be understood as a process of dumping into the cache.

[0119] For example, taking ArkTS as an example, when any thread in the ArkTS thread experiences an OutOfMemoryError (OOM), all local heap objects on that thread can be scanned. A linear scan of all local heap objects on the thread where the OOM occurred is performed, and the object header and object content of each object are first written to the cache.

[0120] (2) Scan all shared heap objects by marking the local heap space and write them to the raw heap file.

[0121] For example, a shared heap object can be an object that is shared by multiple threads in heap memory. A shared heap object can be a shared heap object.

[0122] Alternatively, shared heap objects can be written to the cache first, using the object header and object content, and then written to the raw heap file.

[0123] (3) For IsOnlyJSObject and IsJSFunction objects, you need to read the string name in pandafile and write the string name to the file.

[0124] (4) Output the rawheap file according to the rawheap file format.

[0125] Understandably, when an application experiences an OutOfMemoryError (OOM), each object is first written to a cache along with its header and content; that is, it is initially stored in memory. The cache can be understood as a data structure. All objects to be written to the rawheap file are first written to this data structure, and then written to the rawheap file in a unified manner, thus completing the rawheap file acquisition.

[0126] It is understood that the above process of collecting rawheap files is only an illustrative example. In general, when an application experiences an OOM (Out of Memory) error, the terminal device can scan all objects and write them into a rawheap file with a certain format, generating a rawheap binary file.

[0127] Step 2: The terminal device packages the meta data file and the rawheap binary file to generate a .rawheap result file, and then reports the .rawheap result file to the host computer.

[0128] For example, the metadata file can be a metadata.json file.

[0129] It is understood that metadata.json is an offline parsing tool provided in this application embodiment, used to statically describe the layout of objects in the virtual machine heap. The layout of objects is usually determined at compile time, so the layout of objects can be represented by the static description of the metadata.json file.

[0130] For example, object layout can be the storage structure and organization of objects in memory, used to describe how the various components of an object are arranged and stored in memory.

[0131] Alternatively, the metadata.json file is a static configuration file that is automatically generated by a script during compilation.

[0132] For example, the metadata.json file is located in the code repository at: out\generic_generic_arm_64only\general_all_phone_st andard\gen\arkcompiler\ets_runtime.

[0133] For example, the metadata.json file is located in the terminal device at: system / lib64 / module / arkcompiler.

[0134] Optionally, when an application experiences an OutOfMemoryError (OOM), a dump process is triggered to generate a rawheap binary file. Simultaneously, a metadata.json file can be written to the rawheap file, ultimately generating an integrated file, which is the .rawheap result file. This integration process can be the HiView compression and reporting process, and the final integrated file can be the .rawheap result file shown in Figure 2.

[0135] For example, the following shows a schematic of the metadata.json file format configuration:

[0136] This section of the code file represents a type enumeration, used to enumerate all defined JS (JavaScript) types. In other words, it lists all data types, including integer types, floating-point types, character types, etc.

[0137] This section of the code file represents a list of types, which can include layout information for all types. In other words, it describes detailed information through a list of types. For example, the type name "name" is "JS_FUNCTION". "JS_FUNCTION" also includes some data (e.g., "ProtoOrHcalss"), the space occupied by "JS_FUNCTION" (e.g., "end_off_set":72), and "parents" can indicate that "JS_FUNCTION" inherits from the class "JS_FUNCTION_BASE".

[0138] This part of the code file represents type layout information, which is used to define or describe the layout or structure of a certain data structure.

[0139] "verison":"1.0.0"

[0140] This part of the code file is used to represent the version number of the metadata.json file.

[0141] For example, each object has a metadata.json file to record the object's layout information; for instance, the fields also record the object's layout information. For EcmaObject and TaggedObject objects with fixed formats, there is no metadata.json file by default; it is retrieved through a specified method. During image compilation, the metadata.json files of each object can be concatenated into a single file, with a type_enum header added. For example, the following data structure is obtained;

[0142] For example, integrating the rawheap binary file with the metadata.json file yields a .rawheap result file. For ease of understanding, Table 2 below illustrates one .rawheap result file format. Terminal devices can be pre-configured with the .rawheap result file format shown in Table 2.

[0143] Table 2. Rawheap Result File Format

[0144] The file format of the .rawheap result file shown in Table 2 is different from that of the rawheap file shown in Table 1, except that the bolded part has been added.

[0145] For example, meta data refers to the metadata.json file, and sectionOffest refers to the beginning of the directory.

[0146] Understandably, the metadata.json file can be integrated with the rawheap binary file to generate a .rawheap result file with the format shown in Table 2. The terminal device can then report the .rawheap result file to the host computer.

[0147] Step 3: The host computer uses a tool to parse the .rawheap result file and generate a .heapsnapshot file.

[0148] It is understandable that the host computer obtains the .heapsnapshot file by parsing the .rawheap result file with the file structure shown in Table 2.

[0149] For example, referring to Table 2, the file structure shown in Table 2 is read from the end to the top. The parsing process can include the following steps:

[0150] 1. Read the offset and size of the metadata file at the end of Table 2, and read the information of the metadata file based on the offset and size of the metadata file.

[0151] 2. Read sectionSize, and read the entire section based on sectionSize.

[0152] For example, the entire section can be the portion of Table 2 from rootOffset (representing the start of the root node) to unitSize (representing the unit size) next to sectionSize (representing the number of directories).

[0153] 3. Read the entire rootTable based on the first and second elements of the section.

[0154] For example, the first element of a section is `rootOffset` (representing the start of the root node), and the second element is the `size` field next to `rootOffset`. That is, the entire `rootTable` is read based on the section's `rootOffset` and `size`.

[0155] 4. Read the entire stringTable based on the third and fourth elements of the section.

[0156] For example, the third element of the section is stringTableOffset (indicating the start of the stringTable), and the fourth element is the size field next to stringTableOffset. That is, the entire stringTable is read based on the section's stringTableOffset and size.

[0157] 5. Read two elements from the section in a loop, read a block of memory information in each loop, and create a node for each object.

[0158] 6. Traverse the content of each object according to the meta data file, find the corresponding child nodes, and create an edge based on the two nodes.

[0159] 7. Serialize and output the .heapsnapshot file.

[0160] In other words, first read the sectionOffset at the end (indicating the beginning of the directory) to determine the meta data file to be read, and then determine the size of the meta data file based on the size field next to sectionOffset.

[0161] The range from rootOffset (representing the start of the root node) to unitSize (representing the unit size) next to sectionSize (representing the number of directories) indicates the directory structure of the raw heap files.

[0162] First, read `rootOffset` to determine the offset of the root node, which in turn determines the row of `rootNum` (representing the number of root nodes) in Table 2. Then, by reading `rootNum` and the adjacent `unitSize` field, determine the number of root nodes and the size of each root node. Read each root node sequentially to read the entire `rootTable`.

[0163] Next, read `stringTabletOffset` (representing the start of `stringTable`) to determine the offset of `stringTable`, which in turn determines the row of `stringNum` (representing the number of strings) in Table 2. By reading `stringNum`, the number of strings is determined. Then, sequentially read `string1Size` (representing the size of string1), `objNum` (representing the number of objects related to string1), and `objAddr` (representing the object address). Based on the number of strings, read other strings sequentially, such as `string2`, `string3`, etc., thus reading the entire `stringTable`.

[0164] Then, `addrTableOffset` (representing the start of `addrTable`) is read to determine the offset of the table, which in turn determines the row of `addrTableNum` (representing the number of tables) in table 2. The number of tables is determined by reading `addrTableNum`, and each table, such as `table1`, `table2`, etc., is read sequentially.

[0165] By parsing the .rawheap file according to the above reading order, the .heapsnapshot file can be obtained.

[0166] Step 4: Developers determine the application's memory issues by parsing the .heapsnapshot file.

[0167] For example, when an application experiences an OutOfMemoryError (OOM), a binary dump of the application's current memory can be performed, generating a corresponding file which is then packaged and sent to the host computer. Even if the application is killed due to an OOM and enters an offline state, the developer can use tools on the host computer to parse the .heapsnapshot file as needed to determine the application's memory problem.

[0168] The parsing method, parsing device, and parsing system provided in this application generate a file containing memory information through offline parsing when an application experiences an OutOfMemoryError (OOM). This allows developers to parse the file as needed to determine the application's memory issues. This parsing method does not depend on the application's liveness, reducing the power consumption and memory usage of HeapDump, avoiding impact on other applications, and improving the user experience.

[0169] Figure 4 shows a schematic flowchart of a parsing method provided in an embodiment of this application. This method can be applied to a parsing system including a first device and a second device. The first device can be understood as the terminal device side mentioned above, and the second device can be understood as the host computer side mentioned above. The method will be described in detail below.

[0170] S401, in response to insufficient memory corresponding to the first application, the first device generates a first file, which includes memory information of the first application.

[0171] It's understandable that the first device can include multiple applications, and the first application can be any application on the first device. Each time an OOM (Out of Memory) scenario is triggered, a first file is generated. Insufficient memory for the first application can be understood as insufficient available memory for the first application.

[0172] For example, the first file is a rawheap binary file. When the memory corresponding to the first application is insufficient, a rawheap file is generated first, a process that temporarily depends on the survival of the first application. The first file may include the memory information of the first application, which may be information about all objects on the current memory heap of the first application.

[0173] In one implementation, the process of generating the first file can be understood as the process of collecting rawheap files.

[0174] For example, in response to insufficient memory corresponding to the first application, the first thread is determined to be the thread with insufficient memory corresponding to the first application; the objects of the first thread are scanned and the information of the objects is stored in the first memory; and a first file is generated based on the information of the objects in the first memory.

[0175] For example, the information about an object may include the object's description and its memory information. The first thread is the thread in the first application where the OutOfMemoryError (OOM) occurred.

[0176] Optionally, the object's description information can be an object header, and the object's content information can be the object's raw data. When the application's corresponding memory is insufficient, the objects on the thread where the OOM occurred are scanned, and the object header (object description information) and object content (object content information) are written to the cache (first memory). The object description information and object content information are first written to the first memory for storage. After all objects have been saved, they are then written to the rawheap file in a unified manner, thereby generating the first file.

[0177] For example, objects on the first thread may include local heap objects and / or shared heap objects, etc.

[0178] Understandably, an object allocated by a thread within its own heap memory area can only be used and accessed by the thread that created it, and cannot be shared by other threads; this object can be a local heap object. An object in heap memory that is shared by multiple threads can be a shared heap object.

[0179] S402, the first device generates a third file based on the first file and the second file, wherein the second file is the metadata file of the first application.

[0180] Understandably, when the first application runs out of memory, it will be killed according to the appfreeze mechanism.

[0181] Optionally, in response to the first application being closed, the first device generates a third file based on the first and second files.

[0182] Understandably, the first application being closed here can be interpreted as being killed due to an OutOfMemoryError (OOM).

[0183] For example, the second file could be a metadata.json file, which can be understood as an offline parsing tool used to statically describe the layout of objects in the virtual machine heap. The layout of objects is usually determined at compile time, so it can be represented statically using a metadata.json file.

[0184] For example, the layout of an object can be the storage structure and organization of the object in memory, used to describe how the various components of the object are arranged and stored in memory.

[0185] Alternatively, the metadata.json file is a static configuration file that is automatically generated by a script during compilation.

[0186] For example, the metadata.json file is located in the code repository at: out\generic_generic_arm_64only\general_all_phone_st andard\gen\arkcompiler\ets_runtime.

[0187] For example, the metadata.json file is located in the terminal device at: system / lib64 / module / arkcompiler.

[0188] Optionally, when an application experiences an OOM (Out of Memory) error, a dump process is triggered to generate a rawheap binary file. Additionally, a metadata.json file can be written to the rawheap file, ultimately generating an integrated file, which is the .rawheap result file.

[0189] For example, the third file is a .rawheap result file.

[0190] Understandably, each object has its own metadata.json file, which records the object's layout information. During image compilation, the metadata.json files of all objects can be concatenated into a single file.

[0191] For example, the second file includes a first field and a second field, wherein the first field is used to represent the type name of the object of the first application, and the second field is used to represent the information of the object of the first application. The information of the object of the first application includes one or more of the following: the name of each attribute in the object of the first application, the offset of the object of the first application, the size of the object of the first application, and the inheritance relationship of the object of the first application.

[0192] For example, the first field could be a type enumeration field (type_enum) used to enumerate the type names of all objects. The second field could be a type list field (type_list) that can include specific details, such as: the name of each property in the first application ("name":"propertyName1"), the offset of the object in the first application ("offsets":xx), the size of the object in the first application ("end_offset":xx), and the inheritance relationship of the object in the first application ("parents":{"parentObjName1"}).

[0193] It is understandable that the file format of the third file can be pre-configured.

[0194] For example, the first device is configured with a first file format, and the first device can generate a third file according to the first file and the second file in accordance with the first file format.

[0195] Optionally, the first file format can be the file format shown in Table 2.

[0196] For example, the first file format includes a third field and a fourth field. The third field is used to determine the beginning of the metadata file of the first application, and the fourth field is used to determine a first region of the first file format. The first region includes first information, which is used to read the root node of the first application. The first region also includes second information, which is used to read a string table. The first region also includes third information, which is used to read objects of the first application in a loop.

[0197] For example, the first information may include a first element and a second element, the second information may include a second element and a third element, and the third information may include a fourth element and a fifth element.

[0198] For example, referring to Figure 2, the third field can be the `sectionOffset` field, and the fourth field can be the `sectionSize` field. The `sectionOffset` field determines the start of the metadata, and the `sectionSize` field allows reading the first region (the entire section). The entire section can be defined from `rootOffset` (representing the start of the root node) to `unitSize` (representing the unit size) next to `sectionSize` (representing the number of directories). Specifically, the first element is `rootOffset`, the second element is the size next to `rootOffset`, the third element is `stringTableOffset`, the fourth element is the size next to `stringTableOffset`, the fifth element is `addrTableOffset`, and the sixth element is `unitSize` next to `ddrTableOffset`.

[0199] S403, the first device sends the third file, and correspondingly, the second device receives the third file.

[0200] Understandably, when an application experiences an OutOfMemoryError (OOM), a rawheap file containing the application's memory information is first generated. Then, the rawheap file is integrated with the metadata.json file to obtain a .rawheap file with a first file format. This .rawheap file is then reported to the host computer so that it can parse the .rawheap file offline to obtain a .heapsnapshot file for analyzing the application's memory issues.

[0201] S404, the second device parses the third file.

[0202] For example, the second device parses the third file and obtains the parsing result; based on the parsing result, it prompts the user with a memory problem of the first application, which could be due to insufficient memory for the first application. The user could be the developer.

[0203] For example, the second device can be a host computer, and the parsing result can be a fourth file, which is a .heapsnapshot file. The host computer can obtain the .heapsnapshot file by parsing the .rawheap file with the file structure shown in Table 2.

[0204] It is understandable that the process of the host computer reading from the end to the top of the file structure shown in Table 2 can represent the process of parsing the .rawheap file.

[0205] For example, the second device is configured with a first file format, and the third file has the first file format, which includes a third field and a fourth field. The second device can read the metadata file of the first application based on the third field; determine a first region based on the fourth field, the first region including first information, second information, and third information; read the root node of the first application based on the first information; read a string table based on the second information; cyclically read the objects of the first application based on the third information; and establish object nodes and object edges for the objects of the first application to obtain the parsing results.

[0206] For example, the first information may include a first element and a second element, the second information may include a second element and a third element, and the third information may include a fourth element and a fifth element.

[0207] For example, referring to Table 2, first read the `sectionOffset` at the end (indicating the beginning of the directory) to determine the metadata file to be read, and determine the size of the metadata file based on the `size` field next to `sectionOffset`. The directory structure from `rootOffset` (indicating the beginning of the root node) to `unitSize` (indicating the unit size) next to `sectionSize` (indicating the number of directories) represents the raw heap file directory. First, read `rootOffset` to determine the offset of `root`, i.e., determine the row in Table 2 where `rootNum` (indicating the number of root nodes) is located. By reading `rootNum` and the adjacent `unitSize` field, determine the number of root nodes and the size of each root node, and read each root node sequentially, thus reading the entire `rootTable`. Next, read `stringTableOffset` (indicating the beginning of the `stringTable`) to determine the offset of `stringTable`, i.e., determine the row in Table 2 where `stringNum` (indicating the number of strings) is located. By reading `stringNum`, determine the number of strings. The code sequentially reads `string1Size` (representing the size of the string `string1`), `objNum` (representing the number of objects related to `string1`), and `objAddr` (representing the object address). Based on the number of strings, it sequentially reads other strings, such as `string2`, `string3`, etc., thus reading the entire `stringTable`. Next, it reads `addrTableOffset` (representing the start of `addrTable`) to determine the offset of a table, i.e., to determine the row in `table2` where the offset table is located (where `addrTableNum` represents the number of tables). By reading `addrTableNum`, it determines the number of tables and reads each table sequentially, such as `table1`, `table2`, etc. It reads from a section loop, reading a block of memory information in each loop and creating a node for each object, thus serializing and outputting the `.heapsnapshot` file.

[0208] The parsing method, parsing device, and parsing system provided in this application generate a file containing memory information through offline parsing when an application experiences an OutOfMemoryError (OOM). This allows developers to parse the file as needed to determine the application's memory issues. This parsing method does not depend on the application's liveness, reducing the power consumption and memory usage of HeapDump, avoiding impact on other applications, and improving the user experience.

[0209] Figure 5 is a schematic block diagram of a parsing apparatus according to an embodiment of this application. The parsing apparatus 500 shown in Figure 5 may include a processor 510, a transceiver 520, and a memory 530. The processor 510, transceiver 520, and memory 530 are connected via internal interconnection paths. The memory 530 is used to store instructions, and the processor 510 is used to execute the instructions stored in the memory 530 to receive / send some parameters via the transceiver 520. Optionally, the memory 530 may be coupled to the processor 510 via an interface or integrated with the processor 510.

[0210] It should be noted that the transceiver 520 described above may include, but is not limited to, transceiver devices such as input / output interfaces, to realize communication between the parsing device 500 and other devices (e.g., the terminal device side or the host computer side). The parsing device 500 can be used to implement the various steps executed by the terminal device side or the host computer side.

[0211] In implementation, each step of the above method can be completed by the integrated logic circuits in the hardware of the processor 510 or by instructions in software form. The method disclosed in the embodiments of this application can be directly implemented by the hardware processor, or by a combination of hardware and software modules in the processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory 530, and the processor 510 reads the information in memory 530 and, in conjunction with its hardware, completes the steps of the above method. To avoid repetition, detailed descriptions are not provided here.

[0212] It should also be understood that, in embodiments of this application, the memory may include read-only memory and random access memory, and provides instructions and data to the processor. A portion of the processor may also include non-volatile random access memory. For example, the processor may also store device type information.

[0213] This application provides a computer program product that, when run on a device, causes the device to execute the technical solutions described in the above embodiments. Its implementation principle and technical effects are similar to those of the related embodiments described above, and will not be repeated here.

[0214] This application provides a readable storage medium containing instructions that, when executed on a device, cause the device to perform the technical solutions described in the above embodiments. The implementation principle and technical effects are similar and will not be repeated here.

[0215] This application provides a chip for executing instructions. When the chip is running, it executes the technical solutions described in the above embodiments. Its implementation principle and technical effects are similar and will not be repeated here.

[0216] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the embodiments of this application.

[0217] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working process of the above-described apparatus and unit (module) can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0218] In the several embodiments provided in this application, it should be understood that the disclosed devices, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0219] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0220] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0221] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, or the parts that contribute to the prior art, or parts of the technical solutions, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0222] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. An analytical method, characterized in that, The method is applied to a first device, and the method includes: In response to insufficient memory for the first application, a first file is generated, the first file including the memory information of the first application; A third file is generated based on the first file and the second file, wherein the second file is the metadata file of the first application; Send the third file to the second device.

2. The method according to claim 1, characterized in that, The step of generating a third file based on the first and second files includes: In response to the first application being closed, the third file is generated based on the first file and the second file.

3. The method according to claim 1 or 2, characterized in that, The step of generating a first file in response to insufficient memory corresponding to the first application includes: In response to insufficient memory in the first application, the first thread is determined to be the thread in the first application that is experiencing insufficient memory. Scan the objects of the first thread and store the information of the objects in the first memory; The first file is generated based on the information of the object in the first memory.

4. The method according to claim 3, characterized in that, The objects of the first thread include local heap objects and / or shared heap objects.

5. The method according to any one of claims 1 to 4, characterized in that, The second file includes a first field and a second field. The first field is used to represent the type name of the object in the first application. The second field is used to represent information about the object of the first application, and the information about the object of the first application includes one or more of the following: The names of the various attributes in the object of the first application, the offset of the object of the first application, the size of the object of the first application, and the inheritance relationship of the object of the first application.

6. The method according to any one of claims 1 to 5, characterized in that, The first device is configured with a first file format. The step of generating a third file based on the first and second files includes: The third file is generated according to the first file format based on the first file and the second file.

7. The method according to claim 6, characterized in that, The first file format includes a third field and a fourth field. The third field is used to determine the beginning of the metadata file of the first application, and the fourth field is used to determine a first region of the first file format. The first region includes first information, which is used to read the root node of the first application; The first area also includes second information, which is used to read a string table; The first region also includes third information, which is used to cyclically read objects from the first application.

8. An analytical method, characterized in that, The method is applied to a second device, and the method includes: A third file is received from a first device, the third file being generated from a first file and a second file, the first file including memory information of a first application, the second file being metadata of the first application, and the first application on the first device having insufficient memory. The third file is parsed.

9. The method according to claim 8, characterized in that, The parsing of the third file includes: The third file is parsed to obtain the parsing result; Based on the analysis results, the user is alerted to a memory problem in the first application.

10. The method according to claim 9, characterized in that, The second device is configured with a first file format, and the third file has the first file format, wherein the first file format includes a third field and a fourth field. The parsing of the third file to obtain the parsing result includes: The metadata file of the first application is read according to the third field; The first region of the first file format is determined based on the fourth field, and the first region includes first information, second information and third information; Read the root node of the first application based on the first information; Read the string table based on the second information; The objects of the first application are read in a loop according to the third information; Object nodes and object edges are created for the objects of the first application to obtain the parsing results.

11. A parsing system, characterized in that, The parsing system includes a first device and a second device, wherein the first device is used to perform the method as described in any one of claims 1 to 7, and the second device is used to perform the method as described in any one of claims 8 to 10.

12. An electronic device, characterized in that, The electronic device is used to perform the method as described in any one of claims 1 to 7, or to perform the method as described in any one of claims 8 to 10.

13. An analytical apparatus, characterized in that, The analytical apparatus is used to perform the method as described in any one of claims 1 to 7, or to perform the method as described in any one of claims 8 to 10.

14. A computer-readable storage medium, characterized in that, It stores a computer program thereon, which, when executed by a computer, causes the computer to implement the method as described in any one of claims 1 to 7, or to perform the method as described in any one of claims 8 to 10.

15. A computer program product containing instructions, characterized in that, When the computer program product is run on a computer, it causes the computer to perform the method as described in any one of claims 1 to 7, or to perform the method as described in any one of claims 8 to 10.

16. A chip, characterized in that, The chip includes a processor and a data interface. The processor reads instructions stored in the memory through the data interface to execute the method as described in any one of claims 1 to 7, or to execute the method as described in any one of claims 8 to 10.

Images