Memory optimization method, device, equipment and storage medium

Abstract

An embodiment of the present application provides a memory optimization method, apparatus, device and storage medium, the method comprising: obtaining an execution path when a program exits abnormally during historical operation, the execution path including at least two hook paths; determining a memory occupancy value of each hook path; determining an execution frequency of each hook path in the program based on the execution path; determining a path to be optimized based on the memory occupancy value and the execution frequency of each hook path; and optimizing the memory occupancy value of the path to be optimized. Through the present application, the path to be optimized can be accurately determined, thereby accurately locating the FOOM problem caused by memory allocation, so that the memory occupancy of the program can be effectively optimized, and the method of the embodiment of the present application can be applicable to the memory optimization processing requirements in any mixed business scenario.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of Internet technology, and relate to but are not limited to a memory optimization method, apparatus, device, and storage medium. Background Art

[0002] The foreground out of memory (FOOM) problem occurs when a foreground application, while running, triggers a memory-related system event when one or more conditions are triggered, causing the system to kill the application and the process to exit abnormally during operation.

[0003] In related technologies, when monitoring the FOOM problem, the main focus is on monitoring the behavior that triggers memory allocation through the memory allocation interface. That is, one entire business corresponds to one memory allocation interface, and by monitoring this interface, we can see how much memory allocation is called by the entire business.

[0004] However, the method of monitoring the FOOM problem that triggers memory allocation behavior based on the memory allocation interface in the related art cannot monitor the FOOM problem of mixed services, and cannot solve the problem of information stack or system stack caused by program tail call optimization. Summary of the Invention

[0005] The embodiments of the present application provide a memory optimization method, apparatus, device and storage medium, which can accurately determine the path to be optimized, thereby accurately locating the FOOM problem caused by memory allocation, so as to effectively optimize the memory usage of the program and is suitable for memory optimization processing needs in any mixed business scenarios.

[0006] The technical solution of the embodiment of the present application is implemented as follows:

[0007] This embodiment of the present application provides a memory optimization method, including:

[0008] Obtaining an execution path of a program when an abnormal exit occurs during a historical running process, wherein the execution path includes at least two hook paths;

[0009] Determine the memory usage of each hook path;

[0010] determining, based on the execution path, an execution frequency of each hook path in the program;

[0011] Determining a path to be optimized according to the memory usage value and the execution frequency of each hook path;

[0012] Optimize the memory usage of the path to be optimized.

[0013] The present invention provides a memory optimization device, including:

[0014] An acquisition module, configured to acquire an execution path of a program when an abnormal exit occurs during a historical running process, wherein the execution path includes at least two hook paths;

[0015] A first determining module is used to determine the memory usage value of each hook path;

[0016] a second determining module, configured to determine, based on the execution path, an execution frequency of each hooking path in the program;

[0017] a third determining module, configured to determine a path to be optimized based on the memory usage value and the execution frequency of each hooked path;

[0018] The processing module is used to optimize the memory usage value of the path to be optimized.

[0019] An embodiment of the present application provides a memory optimization device, including:

[0020] The memory is used to store executable instructions; the processor is used to implement the above method when executing the executable instructions stored in the memory.

[0021] An embodiment of the present application provides a storage medium storing executable instructions for causing a processor to execute the above method.

[0022] The embodiments of the present application have the following beneficial effects: since the execution path of the program when an abnormal exit occurs during the historical operation process includes at least two hook paths, and the path to be optimized is determined by the memory occupancy value and execution frequency of the hook path, thus, analysis is performed based on the memory occupancy value and execution frequency of each hook path within the program, rather than analyzing the memory occupancy of the program as a whole, and therefore, the path to be optimized can be accurately determined, thereby accurately locating the FOOM problem caused by memory allocation, so that the memory occupancy of the program can be effectively optimized, and the method of the embodiments of the present application can be applied to the memory optimization processing needs in any mixed business scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Figure 1 It is a schematic diagram of the implementation process of the memory optimization method in the related art;

[0024] Figure 2A This is an optional architectural diagram of the memory optimization system provided in an embodiment of the present application;

[0025] Figure 2B This is an optional structural diagram of the memory optimization system provided in the embodiment of the present application applied to a blockchain system;

[0026] Figure 2C This is an optional schematic diagram of the block structure provided in the embodiment of the present application;

[0027] Figure 3 This is a schematic diagram of the structure of the server provided in the embodiment of the present application;

[0028] Figure 4 This is an optional flowchart of the memory optimization method provided in the embodiment of the present application;

[0029] Figure 5 This is an optional flowchart of the memory optimization method provided in the embodiment of the present application;

[0030] Figure 6 This is an optional flowchart of the memory optimization method provided in the embodiment of the present application;

[0031] Figure 7 This is an optional flowchart of the memory optimization method provided in the embodiment of the present application;

[0032] Figure 8 This is an optional flowchart of the memory optimization method provided in the embodiment of the present application;

[0033] Figure 9 This is an optional flow chart of the path recording method provided in an embodiment of the present application. DETAILED DESCRIPTION

[0034] In order to make the purpose, technical solutions and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limiting this application. All other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0035] In the following description, reference is made to "some embodiments," which describe a subset of all possible embodiments. However, it will be understood that "some embodiments" may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict. Unless otherwise defined, all technical and scientific terms used in the embodiments of this application have the same meaning as commonly understood by those skilled in the art to which the embodiments of this application pertain. The terms used in the embodiments of this application are for the purpose of describing the embodiments of this application only and are not intended to limit this application.

[0036] Before further describing the embodiments of the present application in detail, the nouns and terms involved in the embodiments of the present application are explained. The nouns and terms involved in the embodiments of the present application are subject to the following interpretations.

[0037] 1) Foreground Out of Memory (FOOM): This refers to an application being killed by the system due to excessive memory consumption in the foreground. To the user, it appears as a program crash.

[0038] 2) Hook: This is a platform for the Windows message processing mechanism. Applications can set up subroutines on it to detect certain messages for designated windows, and the detected windows can be created by other processes. When a message arrives, the subroutine set by the hook processes it before the target window's processing function. It can be understood that a hook is actually a program segment that processes messages, which is attached to the process through a system call. Whenever a specific message is sent, before it reaches the destination window, the hook procedure captures the message, which means that the hook function first obtains control. At this point, the hook function can process and change the message processing content, or continue to pass the message without processing, or forcibly terminate the message transmission. The hook mechanism allows applications to intercept and process window messages or specific events.

[0039] 3) Dynamic memory allocation (malloc, memory allocation) function: This function is used to request a contiguous memory block of a specified size and returns the address of the allocated memory block as a void*. Dynamic memory allocation is used when the specific memory location is unknown and you want to bind to the actual memory space. The allocated size is the size requested by the program. If the allocation is successful, a pointer to the allocated memory is returned (the initial value of this memory block is undefined); otherwise, a null pointer (NULL) is returned.

[0040] 4) Stack: A crucial data structure in computer science, it is used in a variety of numerical computations. It is a data structure in which data items are arranged sequentially, with data items only accessible at one end (called the top of the stack). In microcontroller applications, the stack is a special storage area primarily used to temporarily store data and addresses, often used to protect breakpoints and contexts.

[0041] In order to better understand the memory optimization method provided in the embodiments of the present application, the memory optimization method in the related art is first described:

[0042] The method used in related technologies to solve the FOOM problem requires business reporting or stack-based capture, that is, capturing the memory allocated by the underlying memory allocation interface for statistical analysis to implement clustered reporting stack, where the memory allocation interface is, for example: dynamic memory allocation hook (hook malloc) interface or virtual machine dynamic memory allocation (vm_malloc) interface.

[0043] The related technology mainly relies on the memory allocation interface of the Hook bottom layer to monitor the behavior that triggers memory allocation, and then performs cluster analysis through stack backtracing to collect related large memory allocation stacks and behaviors. Figure 1 This is a schematic diagram of the implementation flow of the memory optimization method in the related technology, such as Figure 1 As shown, the device for implementing the memory optimization method includes a memory allocation stack monitoring module 11 and a memory overflow (OOM, Out Of Memory) monitoring module 12.

[0044] On the one hand, the memory allocation stack monitoring module 11 uses the Hook technology to hook the heap memory allocation method and the virtual machine (VM) memory allocation method, and then performs stack backtracing on the hooked data to obtain memory allocation data. On the other hand, the memory allocation stack monitoring module 11 uses the Hook technology to hook the heap memory release method and the VM memory release method to obtain memory allocation data.

[0045] After obtaining the memory allocation data, the memory allocation stack monitoring module 11 sends the memory allocation data to the OOM monitoring module 12. The OOM monitoring module 12 periodically analyzes the memory to determine whether the memory exceeds the threshold. If the memory exceeds the threshold, the module backs up the data through the backup file system (dump) 121 and sends the backup data to the application performance management unit (APM) 122 to implement OOM monitoring of the application's memory status. If the application is a foreground application, the module monitors the FOOM problem.

[0046] It can be seen from this that the related art clusters the memory allocation information in the main scenarios and reports it. That is, whichever business calls the memory allocation interface, the memory call information is obtained by monitoring the underlying memory allocation interface for that business, and finally the memory call information is summarized and reported, so that the business's FOOM problem can be monitored based on the summarized and reported memory call information. In other words, no matter what business it is, as long as memory allocation is required, it is necessary to call the underlying memory allocation interface. Therefore, the related art can monitor the underlying memory allocation interface to determine the memory size allocated by the business, so that the memory allocation information of the business can be known.

[0047] However, in the related art, most of the underlying monitoring methods use a relatively special interface, the memory allocation interface. Under this interface, memory is allocated as a whole, that is, the memory is allocated in large blocks as a whole, rather than in small or fine granularity. Therefore, it is impossible to solve the FOOM problem of mixed services, because the memory allocation of mixed services follows the JavascriptCore virtual machine. Simply monitoring the underlying memory allocation interface is invalid, and the obtained stack is the same, which has no practical value. In other words, the actual memory allocation usage and mapping do not match.

[0048] In addition, the above-mentioned methods of related technologies cannot solve the problem of missing stack or system stack caused by tail call optimization. That is, when the dynamic memory allocation hook (malloc hook) is used, a lot of stacks are collected, but they are all system stacks. The system stack cannot be used to further analyze what behaviors and scenarios cause the FOOM problem.

[0049] It can be seen from this that the methods in the relevant technology can only monitor the memory allocation of the stack triggered by most of the application's own code, but cannot locate the memory behavior recorded by some system stacks, and cannot locate and solve the memory allocation behavior of system calls such as system objects or some system library interfaces.

[0050] Based on at least one of the above problems existing in the related art, an embodiment of the present application provides a memory optimization method, which obtains the execution path of the program when an abnormal exit occurs during the historical operation process, and the execution path includes at least two hook paths; determines the memory occupancy value of each hook path; and determines the execution frequency of each hook path in the program; determines the path to be optimized based on the memory occupancy value and execution frequency of each hook path; and finally optimizes the memory occupancy value of the path to be optimized. In this way, since the execution path of the program when an abnormal exit occurs during the historical operation process includes at least two hook paths, and the path to be optimized is determined based on the memory occupancy value and execution frequency of the hook path, the analysis is performed based on the memory occupancy value and execution frequency of each hook path within the program, rather than analyzing the memory occupancy of the entire program. Therefore, the path to be optimized can be accurately determined, thereby accurately locating the FOOM problem caused by memory allocation, so that the memory occupancy of the program can be effectively optimized, and the method of the embodiment of the present application can be applied to the memory optimization processing requirements in any mixed business scenario.

[0051] The following describes exemplary applications of the memory optimization device provided in the embodiments of the present application. The memory optimization device provided in the embodiments of the present application can be implemented as various types of terminals, such as laptop computers, tablet computers, desktop computers, mobile devices (e.g., mobile phones, portable music players, personal digital assistants, dedicated messaging devices, portable gaming devices), and can also be implemented as a server. The following describes exemplary applications of the memory optimization device when implemented as a server.

[0052] See also Figure 2A , Figure 2A This is an optional architecture diagram of the memory optimization system 10 provided in the embodiment of the present application. In order to support any foreground application, the memory optimization system 10 includes at least one terminal ( Figure 2A The figure shows a first terminal 100-1 and a second terminal 100-2), and the terminals are connected to a server 300 via a network 200. An application can be run on each terminal, and the application can be exited normally or abnormally during foreground operation. The user interface (UI) of the application can be displayed on the current interface 110-1 of the first terminal 100-1, and the UI interface of the application can also be displayed on the current interface 110-2 of the second terminal 100-2.

[0053] Taking the first terminal 100-1 as an example, when the first terminal 100-1 restarts a program, if the program has previously exited abnormally, the server 300 obtains the program's execution path on the first terminal 100-1 and during the program's historical execution, including at least two hook paths, through the network 200. The server 300 determines the memory usage of each hook path, determines the execution frequency of each hook path in the program based on the execution path, determines a path to be optimized based on the memory usage and execution frequency of each hook path, optimizes the memory usage of the path to be optimized, and sends the optimized program to the first terminal 100-1 via the network 200. The network 200 can be a wide area network (WAN), a local area network (LAN), or a combination of the two. Upon obtaining the optimized program, the first terminal 100-1 can run the optimized program to achieve safe and efficient program operation and avoid the FOOM problem.

[0054] The memory optimization system 10 involved in the embodiment of the present application can also be a distributed system 201 of the blockchain system, see Figure 2B , Figure 2BThis is an optional structural diagram of the memory optimization system 10 provided in an embodiment of the present application applied to a blockchain system. The distributed system 201 can be a distributed node formed by multiple nodes 202 (any form of computing device in the access network, such as a server or user terminal) and a client 203. The nodes form a peer-to-peer (P2P) network. The P2P protocol is an application layer protocol running on top of the Transmission Control Protocol (TCP). In a distributed system, any machine, such as a server or terminal, can join and become a node. Nodes include a hardware layer, an intermediate layer, an operating system layer, and an application layer.

[0055] See also Figure 2B The functions of each node in the blockchain system shown include:

[0056] 1) Routing: A basic function of a node, used to support communication between nodes.

[0057] In addition to the routing function, nodes can also have the following functions:

[0058] 2) Applications, deployed in the blockchain, implement specific services based on actual business needs, record data related to the implementation of functions to form record data, carry digital signatures in the record data to indicate the source of the task data, and send the record data to other nodes in the blockchain system for other nodes to add the record data to a temporary block when they successfully verify the source and integrity of the record data.

[0059] For example, the services implemented by the application include:

[0060] 2.1) Wallet: This is used to provide the functionality for conducting electronic currency transactions, including initiating transactions (i.e., sending the transaction record of the current transaction to other nodes in the blockchain system. After successful verification by other nodes, as a response to acknowledge the transaction’s validity, the transaction record data is stored in a temporary block of the blockchain. Of course, the wallet also supports querying the remaining electronic currency in the electronic currency address.

[0061] 2.2) Shared ledgers are used to store, query, and modify account data. Records of operations on account data are sent to other nodes in the blockchain system. After verification, other nodes acknowledge the validity of the account data by storing the recorded data in a temporary block. They can also send a confirmation to the node that initiated the operation.

[0062] 2.3) Smart contracts are computerized protocols that can enforce the terms of a contract. They are implemented through code deployed on a shared ledger that is executed when certain conditions are met. Based on actual business needs, the code is used to complete automated transactions, such as querying the logistics status of a buyer's purchased goods and transferring the buyer's electronic currency to the merchant's address after the buyer signs for the goods. Of course, smart contracts are not limited to executing contracts for transactions, but can also execute contracts that process received information.

[0063] 3) Blockchain, including a series of blocks that are connected to each other in the order of their generation. Once a new block is added to the blockchain, it will not be removed. The block records the record data submitted by the nodes in the blockchain system.

[0064] 4) Consensus is a process in a blockchain network used to reach agreement on transactions in a block among multiple nodes involved. The agreed-upon block will be appended to the end of the blockchain. Mechanisms for achieving consensus include Proof of Work (PoW), Proof of Stake (PoS), Delegated Proof-of-Stake (DPoS), and Proof of Elapsed Time (PoET).

[0065] See also Figure 2C , Figure 2C This is an optional schematic diagram of the block structure provided by an embodiment of the present application. Each block includes the hash value of the transaction record stored in the block (the hash value of the current block) and the hash value of the previous block. The blocks are connected by hash values ​​to form a blockchain. In addition, the block may also include information such as the timestamp when the block was generated. Blockchain is essentially a decentralized database, a series of data blocks generated using cryptographic methods. Each data block contains relevant information used to verify the validity of its information (anti-counterfeiting) and generate the next block.

[0066] See also Figure 3 , Figure 3 is a structural diagram of the server 300 provided in an embodiment of the present application, Figure 3The server 300 shown includes: at least one processor 310, a memory 350, at least one network interface 320, and a user interface 330. The various components in the server 300 are coupled together via a bus system 340. It is understood that the bus system 340 is used to achieve connection and communication between these components. In addition to the data bus, the bus system 340 also includes a power bus, a control bus, and a status signal bus. However, for the sake of clarity, the bus system 340 is not described in detail. Figure 3 Various buses are labeled as bus system 340 .

[0067] The processor 310 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc., where the general-purpose processor can be a microprocessor or any conventional processor, etc.

[0068] The user interface 330 includes one or more output devices 331 that enable presentation of media content, including one or more speakers and / or one or more visual display screens. The user interface 330 also includes one or more input devices 332, including user interface components that facilitate user input, such as a keyboard, mouse, microphone, touch screen display, camera, other input buttons and controls.

[0069] The memory 350 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state memory, hard disk drives, optical disk drives, and the like. The memory 350 may optionally include one or more storage devices physically located away from the processor 310. The memory 350 includes a volatile memory or a non-volatile memory, and may also include both volatile and non-volatile memories. The non-volatile memory may be a read-only memory (ROM), and the volatile memory may be a random access memory (RAM). The memory 350 described in the embodiments of the present application is intended to include any suitable type of memory. In some embodiments, the memory 350 is capable of storing data to support various operations, examples of which include programs, modules, and data structures, or subsets or supersets thereof, as exemplified below.

[0070] Operating system 351, including system programs for processing various basic system services and performing hardware-related tasks, such as the framework layer, core library layer, and driver layer, which are used to implement various basic services and process hardware-based tasks;

[0071] A network communication module 352 for reaching other computing devices via one or more (wired or wireless) network interfaces 320 , exemplary network interfaces 320 including Bluetooth, WiFi, and USB;

[0072] The input processing module 353 is configured to detect one or more user inputs or interactions from one of the one or more input devices 332 and to translate the detected inputs or interactions.

[0073] In some embodiments, the apparatus provided in the embodiments of the present application may be implemented in software. Figure 3 A memory optimization device 354 stored in memory 350 is shown. This memory optimization device 354 may be a memory optimization device in server 300 and may be software in the form of a program or plug-in. The device 354 includes the following software modules: an acquisition module 3541, a first determination module 3542, a second determination module 3543, a third determination module 3544, and a processing module 3545. These modules are logical and can be arbitrarily combined or further separated according to the functions they implement. The functions of each module will be described below.

[0074] In other embodiments, the apparatus provided in the embodiments of the present application may be implemented in hardware. As an example, the apparatus provided in the embodiments of the present application may be a processor in the form of a hardware decoding processor, which is programmed to execute the memory optimization method provided in the embodiments of the present application. For example, the processor in the form of a hardware decoding processor may be one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components.

[0075] The memory optimization method provided by the embodiment of the present application will be described below in conjunction with the exemplary application and implementation of the server 300 provided by the embodiment of the present application. Figure 4 , Figure 4 This is an optional flow chart of the memory optimization method provided in the embodiment of the present application, which will be combined with Figure 4 The steps shown are explained.

[0076] Step S401: Obtain the execution path of the program when an abnormal exit occurs during the historical running process.

[0077] Here, the program may include normal exit situations or abnormal exit situations during its historical running process. If the program has an abnormal exit situation during its historical running process, the execution path at the time of the abnormal exit is obtained. In the embodiment of the present application, the historical running process may be a program running process before the current program is started. That is, if the program abnormally exited during the previous program running process, the execution path of the program during the previous running process is obtained.

[0078] The execution path includes at least two hook paths. The hook path refers to the path after the hook processing (Hook). The execution path includes path information. The hook path corresponds to the key steps and key functions in the program running process. The path information can be, for example, the operation information and switching information corresponding to the UI switching.

[0079] In the embodiment of the present application, the obtained execution path includes not only the hook path, but also the user's related operations under each hook path, memory usage information corresponding to the application operation, and other information.

[0080] Step S402: Determine the memory usage value of each hook path.

[0081] Here, the memory usage value of each hook path refers to the memory size occupied by the program when the program runs in the key step corresponding to the hook path. In the embodiment of the present application, each hook path corresponds to a memory usage value, and the memory usage values ​​between each two hook paths are different, or the memory usage values ​​between each two hook paths are unrelated.

[0082] For example, when the user switches from the first UI interface to the second UI interface, it corresponds to the first hook path, and when the user switches from the second UI interface to the third UI interface, it corresponds to the second hook path. Among them, the memory usage value when switching from the first UI interface to the second UI interface is K1, and the memory usage value when switching from the second UI interface to the third UI interface is K2, and the sizes of K1 and K2 are different.

[0083] Step S403: determining the execution frequency of each hook path in the program according to the execution path.

[0084] Here, determining the execution frequency of each hook path in the program can be based on the execution path, and determining the number of times each hook path appears in the execution path. The higher the number of times the hook path appears in the execution path, the higher the corresponding execution frequency, and the lower the number of times the hook path appears in the execution path, the lower the corresponding execution frequency.

[0085] Step S404 : determining the path to be optimized based on the memory usage value and execution frequency of each hooked path.

[0086] Here, since hook paths with higher memory usage values ​​occupy more memory during program execution, these hook paths need to be optimized. Furthermore, since hook paths with higher execution frequencies appear more frequently in the entire execution path, if these hook paths have higher memory usage values, the memory usage value of the entire execution path will be higher, which can easily cause a FOOM problem. Therefore, these hook paths need to be optimized. In this embodiment of the present application, based on the memory usage value and execution frequency of each hook path, hook paths with higher memory usage values ​​and higher execution frequencies can be identified as paths to be optimized.

[0087] The path to be optimized is a path that requires memory optimization. The path to be optimized may include one high-frequency path or multiple paths. The number of paths to be optimized can be determined based on the actual program running conditions, and the embodiments of this application do not limit this.

[0088] Step S405: Optimize the memory usage value of the path to be optimized.

[0089] Here, the memory usage value of the path to be optimized can be optimized by optimizing the program code of the path to be optimized to obtain a program with a lower memory usage value, or it can be optimized according to the path to be optimized, and some hook paths with higher memory usage values ​​in the execution path can be deleted.

[0090] The memory optimization method provided in the embodiment of the present application includes at least two hook paths in the execution path when the program exits abnormally during historical operation, and the path to be optimized is determined by the memory occupancy value and execution frequency of the hook path. In this way, analysis is performed based on the memory occupancy value and execution frequency of each hook path within the program, rather than analyzing the memory occupancy of the program as a whole. Therefore, the path to be optimized can be accurately determined, thereby accurately locating the FOOM problem caused by memory allocation, so that the memory occupancy of the program can be effectively optimized, and the method of the embodiment of the present application can be applied to the memory optimization processing needs in any mixed business scenarios.

[0091] In some embodiments, the hook path in the execution path is obtained through hook processing during the historical operation of the program. During the historical operation, the execution of the program includes normal exit and abnormal exit. If there is an abnormal exit during the historical operation, the execution path at the time of abnormal exit is obtained to achieve the above Figure 4 Memory optimization methods in .

[0092] based on Figure 4 , Figure 5 This is an optional flow chart of the memory optimization method provided in the embodiment of the present application, such as Figure 5 As shown, the program exits normally and abnormally during historical operation. The method includes the following steps:

[0093] Step S501 : During the historical running process of the program when it exits normally, a specific function of the program is hooked to form at least two hook paths.

[0094] Here, specific functions refer to key functions during the program running process, and specific functions include at least one of the following: UI switching function, program life cycle change function and custom function; correspondingly, the specific functions of the program are hooked to form at least one of the following: UI switching path, program life cycle change path and custom path.

[0095] Step S502: determining the execution order of at least two hook paths in the program.

[0096] Here, since the program implements each key function in sequence during operation, each key function has an execution order with other key functions. Correspondingly, the hook path corresponding to each key function also has an execution order.

[0097] Step S503: splice the hook paths into a first execution path according to the execution order.

[0098] Here, the hook paths have a certain order, and the first execution path formed is a hook path sequence, in which each hook path is spliced ​​in sequence according to the execution order.

[0099] It should be noted that steps S501 to S503 are the cases where the program exits normally. Since the program eventually exits normally, during the execution of the program, each key function in the entire program will be hooked to obtain the hook path corresponding to each key function, that is, the first execution path obtained in the embodiment of the present application is the execution path during the entire program running process.

[0100] Step S504: During the historical running process of the program when it exits abnormally, a specific function of the program is hooked to form at least two hook paths.

[0101] Step S505 : determining the execution order of at least two hook paths in the program.

[0102] Step S506: splice the hook paths into a second execution path according to the execution order.

[0103] It should be noted that steps S504 to S506 are the cases where the program exits abnormally. Since the program exits abnormally, during the execution of the program, there may be a situation where all key functions of the entire program are not executed. Then, at this time, the second execution path includes hook paths corresponding to some key functions of the program.

[0104] Step S507 : Selecting the second execution path corresponding to the abnormal exit situation from the first execution path and the second execution path as the target execution path for determining the path to be optimized when restarting.

[0105] In the embodiment of the present application, since the second execution path corresponds to an abnormal exit situation, the second execution path is selected as the target execution path.

[0106] Correspondingly, step S401 can be implemented by the following steps:

[0107] Step S508, when the program is restarted, obtaining the execution path of the program when it exits abnormally during its historical running process, wherein the second execution path includes at least two hook paths;

[0108] Here, the execution path when the program exits abnormally during the historical running process is the above-mentioned second execution path.

[0109] The memory optimization method provided by the embodiment of the present application forms at least two hooking paths by hooking specific functions of the program during the program running process. In this way, the key paths corresponding to the key functions can be buried through the hooking process, so that the final execution path includes the operation path corresponding to the key functions. Therefore, during the abnormal analysis, the various hooking paths within the program can be analyzed instead of analyzing the memory occupancy of the program as a whole. Therefore, the path to be optimized can be accurately determined, thereby accurately locating the FOOM problem caused by memory allocation, so that the memory occupancy of the program can be effectively optimized. Moreover, even for mixed business scenarios, since the hooking paths are spliced ​​into the execution path, the multiple hooking paths corresponding to the mixed business can also be spliced ​​into the execution path for analysis. That is, the method of the embodiment of the present application is also applicable to the memory optimization processing requirements under any mixed business scenario.

[0110] In some embodiments, when the program is started again, if the program has exited abnormally during historical operation or exited abnormally during the previous operation, it is also necessary to judge the cause of the abnormal exit to determine whether the abnormal exit is due to a FOOM problem caused by memory usage exceeding a threshold. If it is a FOOM problem, the subsequent memory optimization method is executed.

[0111] based on Figure 4 , Figure 6This is an optional flow chart of the memory optimization method provided in the embodiment of the present application, such as Figure 6 As shown, before step S401, the following steps are also included:

[0112] Step S601: determine whether the program version has changed during the period from the historical running process to the current startup of the program.

[0113] If the judgment result is yes, it indicates that the program version has changed, and the new program version is different from the historical program version. Therefore, it is impossible to optimize the memory usage of the new program version based on the data of the historical program version, so the process ends; if the judgment result is no, execute step S602.

[0114] Step S602: determine whether the system version has changed during the period from the historical running process to the current startup of the program.

[0115] If the judgment result is yes, it indicates that the system version has changed and the new system version is different from the historical system version. Therefore, it is impossible to optimize the memory usage of the new system version based on the data of the historical system version, so the process ends; if the judgment result is no, execute step S603.

[0116] Step S603: determine whether a program termination function is called during the historical running process.

[0117] If the judgment result is yes, it indicates that the program termination function was called to terminate the program during the historical running process. Therefore, it is not an abnormal exit caused by memory usage, so the process ends; if the judgment result is no, execute step S604.

[0118] Step S604 , determining whether a signal abnormality or an operating system kernel abnormality occurs during the historical operation process.

[0119] If the judgment result is yes, it indicates that a signal exception or an operating system kernel exception occurred during the historical operation process. Neither the signal exception nor the operating system kernel exception is an abnormal program exit caused by memory usage, so the process ends; if the judgment result is no, execute step S605.

[0120] Step S605: determine whether a main thread freeze occurs during the historical running process.

[0121] If the judgment result is yes, it indicates that the main thread has been stuck during the historical running process, and the main thread stuck is not caused by abnormal program exit due to memory usage, so the process ends; if the judgment result is no, execute step S606.

[0122] Step S606: Determine whether the program exits to the background during the historical running process.

[0123] If the judgment result is yes, it indicates that the program exited to the background during the historical running process, and the program exiting to the background is not an abnormal program exit caused by memory usage, so the process ends; if the judgment result is no, execute step S607.

[0124] Step S607: determining whether the program exits abnormally due to the memory usage being greater than a threshold value during the historical running process.

[0125] Here, when the above steps S601 to S606 are all judged to be no, that is, the program does not meet all of the following conditions: the program version changes during the time period from the historical running process to the current startup of the program; the system version changes during the time period from the historical running process to the current startup of the program; during the historical running process, the program termination function is called; during the historical running process, a signal exception or an operating system kernel exception occurs; during the historical running process, the main thread freezes; during the historical running process, the program exits to the background; then it is determined that during the historical running process, the program exits abnormally because the memory usage is greater than the threshold.

[0126] It should be noted that the judgment process in step S601 to step S606 can have any order and is not limited to the order given in the above embodiment.

[0127] Correspondingly, step S401 can be implemented by the following steps:

[0128] Step S608: Obtain the execution path of the program when it exits abnormally due to the memory usage being greater than a threshold during the historical running process.

[0129] The memory optimization method provided in the embodiment of the present application first determines whether the program exit is due to memory usage being greater than a threshold, that is, the large memory usage causing the FOOM problem, before analyzing the cause of the program's abnormal exit. If so, the abnormal exit cause analysis of the embodiment of the present application is then performed. In this way, the cause of the FOOM problem can be accurately determined.

[0130] based on Figure 4 , Figure 7 This is an optional flow chart of the memory optimization method provided in the embodiment of the present application, such as Figure 7 As shown, step S404 can be implemented by the following steps:

[0131] Step S701: traverse the execution path in reverse order to obtain at least one target path.

[0132] Here, the target path may be any hook path in the execution path, may be multiple consecutive hook paths in the execution path, or may be a path formed by splicing multiple hook paths in the execution path.

[0133] Step S702 : performing cluster analysis on the target paths according to the memory usage value and execution frequency of each target path to determine the path to be optimized.

[0134] Here, the target paths are clustered and analyzed to determine the paths to be optimized.

[0135] based on Figure 7 , Figure 8 This is an optional flow chart of the memory optimization method provided in the embodiment of the present application, such as Figure 8 As shown, step S701 can be implemented by the following steps:

[0136] Step S801 , traverse the execution path in reverse order, and determine the first UI hook path obtained by the reverse traversal as the target path.

[0137] Step S802: The first application state hooking path obtained by reverse traversal is determined as the target path.

[0138] Step S803 : at least one UI hook path obtained by traversing the execution path in reverse order is spliced ​​into a UI jump path, and the UI jump path is determined as the target path.

[0139] Step S804 , concatenate at least one custom hook path obtained by traversing the execution path in reverse order into a custom execution path, and determine the custom execution path as the target path.

[0140] Correspondingly, step S702 can be implemented by the following steps:

[0141] Step S805 : determining a memory occupancy increment value of the corresponding target path according to the memory occupancy value of each target path and the memory occupancy standard value of the corresponding target path.

[0142] Step S806 : Determine the target path with the highest execution frequency and the highest memory usage increment as the path to be optimized.

[0143] In some embodiments, the path to be optimized may be determined based only on the memory usage value of each hooked path. In this case, step S702 may be implemented by the following steps:

[0144] Step S7021: Determine a memory occupancy increment value of the corresponding target path according to the memory occupancy value of each target path and the memory occupancy standard value of the corresponding target path.

[0145] Step S7022: Determine the target path with the highest memory usage increment as the path to be optimized.

[0146] In some embodiments, the path to be optimized may be determined based solely on the execution frequency of each hooked path. In this case, step S702 may be implemented by the following steps:

[0147] Step S7023: Determine the target path with the highest execution frequency as the path to be optimized.

[0148] The memory optimization method provided in the embodiment of the present application performs cluster analysis on the different target paths obtained, and determines at least one path to be optimized from multiple target paths. Since the target path includes different paths such as the UI hook path, the application status hook path, the UI jump path and the custom execution path, various situations that may cause the FOOM problem are taken into consideration, thereby obtaining a comprehensive target path that may cause the FOOM problem, and then performing cluster analysis based on the comprehensive information to obtain an accurate path to be optimized.

[0149] The following describes an exemplary application of the embodiments of the present application in a practical application scenario.

[0150] The embodiment of the present application provides a memory optimization method, which inserts application key behavior tracking points and records the forward and backward movement of the user interface view controller (UIViewController), view, etc., and combines the hookmalloc underlying memory allocation stack information to collect these key behaviors and store them in the memory mapped file (mmap) data, so as to perform statistical analysis on the behavior of foreground memory flash back, thereby optimizing the application foreground memory flash back in a targeted manner. The method proposed in the embodiment of the present application combines path analysis and monitoring of the underlying memory allocation method to achieve memory optimization of some system stack scenarios or JS hybrid (Java Script hybrid) business scenarios, thereby proposing a new way to optimize the FOOM problem of these scenarios.

[0151] The method of the embodiment of the present application can be applied to any application to help analyze the memory FOOM problem and provide a more comprehensive approach for FOOM optimization.

[0152] In the embodiments of this application, the dynamic characteristics of the object-oriented programming language (ObjC, Objective-C) that extends C are utilized to hook and monitor the key interfaces of UIViewController and the application delegate class (AppDelegate), and key behaviors triggered by system notifications and the application itself are recorded. The storage characteristics of mmap are utilized to store the recorded key application behaviors, ensuring that the corresponding information can still be accurately recorded in the file system during a crash. When the application is next started, the collected key behaviors are aggregated into an operation path and then reported to the server for cluster analysis. Based on the cluster analysis, it is possible to determine in which scenarios or business situations FOOM is likely to occur, so that other auxiliary methods can be combined to locate and solve the FOOM problem.

[0153] Figure 9 This is an optional flow chart of the path recording method provided in the embodiment of the present application, such as Figure 9 As shown, the following steps are included:

[0154] Step S901: After starting the program, the user uses the program normally.

[0155] Step S902: During the execution of the program, it is determined whether the current path is a critical path.

[0156] If the judgment result is yes, execute step S903; if the judgment result is no, return to execute step S901.

[0157] Step S903: record the current path into mmap.

[0158] Step S904: When the program is started next time, it is determined whether the program exited normally during the last operation.

[0159] If the judgment result is yes, step S901 is executed to run the program normally; if the judgment result is no, step S905 is executed.

[0160] Step S905: Obtain the execution path of the last run from mmap.

[0161] Step S906: reporting the execution path of the last run.

[0162] like Figure 9 After the path recording is implemented in the above method, the abnormal path (i.e., the execution path) will be reported at the next startup and cluster analysis will be performed. It can also be combined with memory allocation stack information for analysis to optimize the FOOM problem in specific scenarios.

[0163] In the embodiment of the present application, each subpath in the last run can be hooked to obtain a hook path. Here, the subpaths can be divided into the following types:

[0164] The first is the UI switching path, which involves the forward and backward movement of UIViewController or the behavior path triggered by its life cycle.

[0165] The second type is the path of changes in the application life cycle, including behavioral paths such as switching between the foreground and background applications, screen lock, sending freezes, crashes, and receiving memory warnings.

[0166] The third type is application-defined key paths, which include: the application chooses to perform dot-writing path operations before and after certain key interfaces or suspicious interfaces.

[0167] For the first UI switching path mentioned above, the operation is as follows: Based on the characteristics of the ObjC runtime, hook the jump or forward and backward interfaces of some basic business UI components and make path records. When the corresponding interface is called, write data records to the path file. The UI component interface is as follows:

[0168] -[UIViewController viewDidLoad]

[0169] -[UIViewController viewWillAppear:]

[0170] -[UIViewController viewDidAppear:]

[0171] -[UIViewController viewWillDisappear:]

[0172] -[UIViewController viewDidDisappear:]

[0173] In the embodiment of the present application, the UI component interface above the Hook can specifically record which functional scenario the current user has jumped from, thereby helping to analyze what the user did before FOOM and which functional modules were roughly triggered.

[0174] For the second type of application lifecycle change path mentioned above, the operation is as follows: Hook some key UI application interfaces and record the path. When the corresponding interface is called, write the record data to the path file. The interface is as follows:

[0175] -(BOOL)application:willFinishLaunchingWithOptions:

[0176] -(BOOL)application:didFinishLaunchingWithOptions:

[0177] -(void)applicationDidBecomeActive:

[0178] -(void)applicationWillResignActive:

[0179] -(void)applicationDidReceiveMemoryWarning:

[0180] -(void)applicationWillTerminate:

[0181] -(void)applicationDidEnterBackground:

[0182] -(void)applicationWillEnterForeground:

[0183] In the embodiment of the present application, the above UI Application Delegate interface is hooked to record and detect the behavior of some users who are called back by the system, including recording the user's front-end and back-end switching, the time and frequency when the user receives memory alarms, etc.

[0184] For the third type of application-defined key path mentioned above, the operations are as follows: For some other application-defined behaviors or key operations triggered by users, the application also needs to record them by itself, including: For audio and video playback, audio and video related callbacks and play (play), pause (pause) and other interfaces should be hooked and recorded; network requests (for example, NSURLSession) and other network interfaces should be hooked to monitor network operations; behaviors involving key application paths should be recorded; similarly, for mixed services, JS execution and call-related interfaces need to be hooked and recorded.

[0185] In the embodiment of the present application, mmap is used for persistent data storage. Due to the characteristics of mmap, even if the user encounters a FOOM at the moment of recording the path, the last data write can be guaranteed to be successful; data writing is written in the form of tag-length-value (TLV), which facilitates variable-length compression of log data and memory; each record contains two fields: timestamp and record content; after the program is started for the second time, it will determine whether the user has encountered a FOOM based on the following strategies S1 to S7.

[0186] S1: Whether the application version has changed between the last startup and this startup, if so, the program ends.

[0187] S2: Whether the system version has changed between the last startup and this startup, if so, the system ends;

[0188] S3: When the program was last started, whether a program termination function (e.g., abort function, exit function) was called, if so, the program is terminated;

[0189] S4: Whether a process crash occurs during the last startup. If so, the process ends.

[0190] The process interruption here includes the process interruption caused by signal exception or operating system kernel exception.

[0191] S5: When the main thread was stuck during the last startup, if so, the process ends.

[0192] S6, when the runtime was last started, whether it exited to the background, if yes, then it ends;

[0193] S7, otherwise, a FOOM occurred during the last startup and caused the user to crash.

[0194] When a FOOM error is detected during the last startup, the log records written by mmap are read and the corresponding records are arranged in timestamp order to form an abnormal exit path (corresponding to the above execution path). The abnormal exit path is uploaded and cluster analysis is performed.

[0195] Based on the above abnormal exit path, the embodiment of the present application provides an abnormality analysis method, including the following steps:

[0196] S11, traverse the abnormal exit path in reverse order to obtain the first UI path, that is, obtain the function or view interface where the user was at the time of the last abnormal exit;

[0197] S12, traverse the abnormal exit path in reverse order to obtain the first application state path, that is, the application running state when the user last abnormally exited;

[0198] S13, traverse the abnormal exit path in reverse order, count all UI paths, obtain a UI jump directed graph, and perform extended analysis on the directed graph data.

[0199] S14, traverse all application custom paths in reverse order to obtain a custom path directed graph, and analyze the directed graph data.

[0200] S15, cluster analysis is performed on the path data and directed graph obtained above, so as to obtain information such as on which pages the user is most likely to experience FOOM, and after which operations the user is most likely to experience FOOM.

[0201] Combining the above information, you can determine which page and scenario the FOOM occurred in. Combined with key custom operation times, such as targeted key interface checks, this information can be used to roughly identify which interface or behavior triggers the FOOM, and then perform targeted performance tuning on this behavior and related interfaces. This allows you to evaluate and analyze the cause of the application's FOOM even without sufficient stack trace information, and to optimize the FOOM issue accordingly.

[0202] In the embodiments of this application, a path analysis-based method is proposed to optimize memory in some system stack scenarios or JS hybrid business scenarios, thereby providing a new approach to optimizing the FOOM problem in these scenarios. Furthermore, a path analysis and data clustering method is proposed to locate the functions or businesses most prone to FOOM problems, as well as the user operation path behaviors most likely to cause FOOM problems, providing more complete information and data for analyzing FOOM problems.

[0203] The method of the embodiment of the present application has the following beneficial effects: it can optimize and troubleshoot FOOM problems based on user operations and behaviors without relying on the traditional memory allocation call stack aggregation method; it can also be combined with the traditional memory allocation call stack reporting aggregation method to assist in analyzing FOOM problems, which is more scenario-specific; and it indirectly solves the problem of having no way to analyze FOOM when the traditional call stack cannot locate tail call optimization or the stack is missing or the stack is entirely system stack.

[0204] The following continues to describe the exemplary structure of the memory optimization device 354 provided in the embodiment of the present application implemented as a software module. In some embodiments, such as Figure 3 As shown, the software module stored in the memory optimization device 354 of the memory 350 may be the memory optimization device in the server 300, including:

[0205] An acquisition module 3541 is used to acquire an execution path when a program exits abnormally during its historical running process, wherein the execution path includes at least two hook paths;

[0206] A first determining module 3542 is used to determine the memory usage value of each hook path;

[0207] A second determining module 3543 is configured to determine, based on the execution path, the execution frequency of each hooking path in the program;

[0208] A third determining module 3544 is configured to determine a path to be optimized based on the memory usage value and the execution frequency of each hooked path;

[0209] The processing module 3545 is used to optimize the memory usage value of the path to be optimized.

[0210] In some embodiments, the device further includes: a hooking module, used to hook specific functions of the program during the historical running process of the program to form the at least two hooking paths; a fourth determination module, used to determine the execution order corresponding to the at least two hooking paths in the program; and a splicing module, used to splice the hooking paths into the execution path according to the execution order.

[0211] In some embodiments, the specific functions include at least one of the following: UI switching function, program life cycle change function and custom function; correspondingly, the specific functions of the program are hooked to form at least one of the following: UI switching path, program life cycle change path and custom path.

[0212] In some embodiments, the device also includes: a fifth determination module, which is used to determine in sequence whether the program meets the following conditions: the program version changes within the time period from the historical running process to the current startup of the program; the system version changes within the time period from the historical running process to the current startup of the program; during the historical running process, the program termination function is called; during the historical running process, a signal exception or an operating system kernel exception occurs; during the historical running process, the main thread freezes; during the historical running process, the program exits to the background; if the program does not meet each of the above conditions, it is determined that during the historical running process, the program exits abnormally due to memory usage exceeding a threshold.

[0213] In some embodiments, the third determination module is further used to: traverse the execution path in reverse order to obtain at least one target path; perform cluster analysis on the target path based on the memory usage value and the execution frequency of each target path to determine the path to be optimized.

[0214] In some embodiments, the third determination module is further used to: traverse the execution path in reverse order, and determine the first UI hook path obtained by the reverse traversal as the target path; determine the first application state hook path obtained by the reverse traversal as the target path; splice at least one UI hook path obtained by traversing the execution path in reverse order into a UI jump path, and determine the UI jump path as the target path; splice at least one custom hook path obtained by traversing the execution path in reverse order into a custom execution path, and determine the custom execution path as the target path.

[0215] In some embodiments, the third determination module is also used to: determine the memory occupancy increment value of the corresponding target path based on the memory occupancy value of each target path and the memory occupancy standard value of the corresponding target path; and determine the target path with the highest execution frequency and the highest memory occupancy increment value as the path to be optimized.

[0216] It should be noted that the description of the device embodiment of the present application is similar to the description of the method embodiment described above, and has similar beneficial effects as the method embodiment, so it will not be repeated. For technical details not disclosed in the device embodiment, please refer to the description of the method embodiment of the present application for understanding.

[0217] The embodiment of the present application provides a storage medium storing executable instructions, wherein the executable instructions are stored. When the executable instructions are executed by a processor, the processor will execute the method provided by the embodiment of the present application, for example, Figure 4 The method shown.

[0218] In some embodiments, the storage medium can be a ferroelectric random access memory (FRAM), a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a flash memory, a magnetic surface memory, an optical disc, or a compact disc read-only memory (CD-ROM); it can also be various devices including one or any combination of the above memories.

[0219] In some embodiments, executable instructions may be in the form of a program, software, software module, script, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

[0220] By way of example, executable instructions may, but need not necessarily, correspond to a file in a file system, may be stored as part of a file storing other programs or data, such as one or more scripts in a Hypertext Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple coordinating files (e.g., files storing one or more modules, subroutines, or code portions). By way of example, executable instructions may be deployed for execution on one computing device, or on multiple computing devices located at one site, or on multiple computing devices distributed across multiple sites and interconnected by a communication network.

[0221] The above description is merely an embodiment of the present application and is not intended to limit the scope of protection of the present application. Any modifications, equivalent replacements, and improvements made within the spirit and scope of the present application are included in the scope of protection of the present application.

Claims

1. A memory optimization method, characterized in that: include: Obtaining an execution path of a program when an abnormal exit occurs during a historical running process, wherein the execution path includes at least two hook paths; Determine the memory usage of each hook path; determining, based on the execution path, an execution frequency of each hook path in the program; Traversing the execution path in reverse order to obtain at least one target path; Determine the memory usage increment of the corresponding target path according to the memory usage value of each target path and the memory usage standard value of the corresponding target path; The target path with the highest execution frequency and the highest memory usage increment value is determined as the path to be optimized; Optimize the memory usage of the path to be optimized.

2. The method according to claim 1, characterized in that The method further comprises: During the historical running process of the program, hooking specific functions of the program to form the at least two hooking paths; determining an execution order of the at least two hook paths in the program; The hook paths are spliced ​​into the execution path according to the execution order.

3. The method according to claim 2, characterized in that The specific function includes at least one of the following: UI switching function, program life cycle change function and customization function; Correspondingly, the specific functions of the program are hooked to form at least one of the following: a UI switching path, a program life cycle change path, and a custom path.

4. The method according to claim 1, wherein The method further includes: sequentially determining whether the program satisfies the following conditions: The program version has changed between the previous running process and the current startup of the program; The system version has changed between the historical operation process and the current startup process; During the historical execution, a program termination function is called; During the historical operation, a signal abnormality or an operating system kernel abnormality occurs; During the historical operation, the main thread freezes; During the historical running process, the program exits to the background; If the program does not meet any of the above conditions, it is determined that during the historical running process, the program exited abnormally due to memory usage being greater than a threshold.

5. The method according to claim 1, wherein The reverse traversal of the execution path to obtain at least one target path includes at least one of the following: Traversing the execution path in reverse order, and determining the first UI hook path obtained by the reverse traversal as the target path; The first application state hook path obtained by reverse traversal is determined as the target path; splicing at least one UI hook path obtained by traversing the execution path in reverse order into a UI jump path, and determining the UI jump path as the target path; At least one custom hook path obtained by traversing the execution path in reverse order is spliced ​​into a custom execution path, and the custom execution path is determined as the target path.

6. A memory optimization device, characterized in that: include: An acquisition module, configured to acquire an execution path of a program when an abnormal exit occurs during a historical running process, wherein the execution path includes at least two hook paths; A first determining module is used to determine the memory usage value of each hook path; a second determining module, configured to determine, based on the execution path, an execution frequency of each hooking path in the program; a third determining module, configured to traverse the execution path in reverse order to obtain at least one target path; Determine the memory usage increment of the corresponding target path according to the memory usage value of each target path and the memory usage standard value of the corresponding target path; The target path with the highest execution frequency and the highest memory usage increment value is determined as the path to be optimized; The processing module is used to optimize the memory usage value of the path to be optimized.

7. A memory optimization device, characterized in that: include: a memory for storing executable instructions; A processor, configured to implement the method according to any one of claims 1 to 5 when executing the executable instructions stored in the memory.

8. A storage medium, characterized in that: Executable instructions are stored, which are used to cause a processor to execute and implement the method according to any one of claims 1 to 5.

Images