Method and apparatus for obtaining in-memory snapshot, and computer readable storage medium
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- TENCENT TECHNOLOGY (SHENZHEN) CO LTD
- Filing Date
- 2021-08-27
- Publication Date
- 2026-07-24
AI Technical Summary
In large-scale front-end projects, the application's memory usage has a significant impact on user experience, and existing technologies struggle to efficiently detect and address issues that may lead to explosive memory growth.
By receiving a memory snapshot request, the target application is triggered to load a specified page. When the page is fully loaded, a memory snapshot retrieval instruction is sent. The data return event is detected, a callback function is used to retrieve the memory snapshot, which is then generated and stored. Abnormal memory usage is flagged, and memory detection is performed through an automated platform.
It simplifies the memory snapshot acquisition process, improves detection efficiency, enhances applicability, and enables timely adjustments to development plans when memory usage is abnormal, thus preventing a decline in user experience.
Smart Images

Figure CN115905738B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of Internet technology, and in particular to a method, apparatus and computer-readable storage medium for obtaining application memory snapshots. Background Technology
[0002] In large-scale front-end projects (or front-end applications, such as World Wide Web (web) applications), memory usage has a significant impact on the user experience. If the application consumes too much memory during use, it can lead to issues such as lag and crashes. Therefore, during application development and before release, it is crucial to assess whether new features will cause a sudden surge in memory usage. This allows for timely adjustments to the development plan to prevent negative impacts on user experience, making it a critical technical challenge. Summary of the Invention
[0003] This application provides a method, apparatus, and computer-readable storage medium for obtaining application memory snapshots, which can improve the efficiency of obtaining memory snapshots of target applications, is simple to operate, and has stronger applicability.
[0004] In a first aspect, embodiments of this application provide a method for obtaining an application memory snapshot, the method comprising: Receive an application memory snapshot retrieval request. The retrieval request is used to request the retrieval of the memory snapshot of the target application when the target application accesses the specified page. Based on the above acquisition request, the target application is triggered to load and display the specified page, and when the specified page is loaded, a memory snapshot acquisition instruction is sent to the target application. Detect the data return events of the target application mentioned above; When the above data return event is detected to include a memory snapshot return event fed back by the target application based on the memory snapshot acquisition instruction, a memory snapshot of the target application running the specified page is obtained based on the memory snapshot return event.
[0005] In one possible implementation, the method for obtaining a memory snapshot of the target application running the specified page based on the memory snapshot postback event includes: Call the callback function associated with the memory snapshot postback event, obtain the page runtime memory data of the specified page as fed back by the target application through the callback function, and generate a memory snapshot of the target application based on the page runtime memory data.
[0006] In one possible implementation, before generating the memory snapshot of the target application based on the page runtime memory data, the method further includes: When the memory snapshot acquisition identifier is obtained from the page runtime memory data of the specified page returned by the target application through the above callback function, it is determined that the acquisition of the page runtime memory data of the target application is complete.
[0007] In one possible implementation, generating a memory snapshot of the target application based on the aforementioned page runtime data includes: Obtain memory usage data for each node in at least one target type from the above page runtime memory data; Integrate memory usage data for all nodes across all target types and generate a memory snapshot of the aforementioned target applications.
[0008] In one possible implementation, after generating the memory snapshot of the target application, the method further includes: The memory usage of the target application when running the specified page is obtained based on the memory snapshot of the target application. When the memory usage exceeds or equals the memory usage threshold, an abnormal increase in memory usage for the specified page will be indicated.
[0009] In one possible implementation, after generating the memory snapshot of the target application, the method further includes: Store the memory snapshot of the target application to the specified storage path; or generate a memory report in the specified data format based on the memory snapshot of the target application.
[0010] In one possible implementation, the aforementioned retrieval request carries a Uniform Resource Locator (URL) address, and the aforementioned triggering of the target application to load and display the specified page based on the aforementioned retrieval request includes: Based on the above acquisition request, the target application is determined, the application driver corresponding to the target application is created and initialized, and the target application is started through the application driver. Calling the aforementioned application-driven application programming interface (API) triggers the target application to load and display the specified page located at the aforementioned URL address.
[0011] In one possible implementation, after generating the memory snapshot of the target application, the method further includes: Call the API mentioned above, which is driven by the application, to close the specified page and the target application.
[0012] Secondly, embodiments of this application provide an apparatus for obtaining application memory snapshots, the apparatus comprising: The request receiving module is used to receive a request to obtain an application memory snapshot, wherein the request is used to request to obtain a memory snapshot of the target application when the target application accesses a specified page; The processing module is used to trigger the target application to load and display the specified page based on the acquisition request received by the request receiving module, and to send a memory snapshot acquisition instruction to the target application when the specified page has finished loading. The page inspection module is used to detect data return events of the target application.
[0013] The processing module is also used to obtain a memory snapshot of the target application running the specified page based on the memory snapshot return event when the page detection module detects that the data return event includes a memory snapshot return event fed back by the target application based on the memory snapshot acquisition instruction.
[0014] Thirdly, embodiments of this application provide a computer device, which includes: a processor, a memory, and a network interface; The processor is connected to a memory and a network interface, wherein the network interface is used to provide data communication functions, the memory is used to store program code, and the processor is used to call the program code to execute the method as described in the first aspect of the embodiments of this application.
[0015] Fourthly, embodiments of this application provide a computer storage medium storing a computer program, the computer program including program instructions, which, when executed by the processor, perform the method as described in the first aspect of embodiments of this application.
[0016] In this embodiment, in response to a received application memory snapshot retrieval request, the target application can be triggered to load and display a specified page. Furthermore, upon detecting that the specified page has finished loading, a memory snapshot retrieval command can be sent to the target application. This command can trigger the target application to return the runtime memory data of the currently specified page. By detecting the target application's data return event, upon detecting a memory snapshot return event based on the memory snapshot retrieval command, the callback function associated with the memory snapshot return event can be called. This callback function retrieves the page runtime memory data of the specified page returned by the target application. This enables automated detection of the target page's memory usage, greatly simplifies the memory snapshot retrieval operation, improves memory snapshot retrieval efficiency, and enhances applicability. Attached Figure Description
[0017] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0018] Figure 1 This is a schematic diagram of the system architecture provided in the embodiments of this application; Figure 2 This is an interactive schematic diagram of the method for obtaining application memory snapshots provided in an embodiment of this application; Figure 3 This is a flowchart illustrating a method for obtaining an application memory snapshot provided in an embodiment of this application; Figure 4 This is another flowchart illustrating the method for obtaining application memory snapshots provided in this application embodiment; Figure 5 This is a schematic diagram illustrating a scenario for obtaining an application memory snapshot provided in an embodiment of this application; Figure 6 This is another scenario illustration of obtaining application memory snapshots provided in the embodiments of this application; Figure 7a This is another scenario illustration of obtaining application memory snapshots provided in the embodiments of this application; Figure 7b This is another scenario illustration of obtaining application memory snapshots provided in the embodiments of this application; Figure 8 This is another flowchart illustrating the method for obtaining application memory snapshots provided in this application embodiment; Figure 9 This is another flowchart illustrating the method for obtaining application memory snapshots provided in this application embodiment; Figure 10 This is a schematic diagram of the application memory snapshot acquisition device provided in an embodiment of this application; Figure 11 This is a schematic diagram of the processing module in the memory snapshot acquisition device according to an embodiment of this application; Figure 12 This is a schematic diagram of the structure of the computer device provided in the embodiments of this application. Detailed Implementation
[0019] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.
[0020] The method for obtaining application memory snapshots provided in this application embodiment is applicable to the automated memory usage detection of a target application (such as a browser, a mini-program, etc.) running and displaying a specified page (such as a web application page). In this method, an automated memory detection platform is built, a memory snapshot acquisition instruction is sent to the browser, and the browser detects the specified page and obtains the memory snapshot returned by the browser by calling a callback function. This method can automatically obtain memory snapshots, is simple to operate, and has high applicability.
[0021] See Figure 1 This is a schematic diagram of the system architecture provided in an embodiment of this application. For example... Figure 1 As shown, the system architecture may include a service server 100 and a terminal cluster. The terminal cluster may include terminal devices 200a, 200b, 200c, ..., 200n. The service server 100 can establish communication connections with each terminal device in the terminal cluster, and the terminal devices in the terminal cluster can also establish communication connections with each other. In other words, the service server 100 can establish communication connections with each terminal device among terminal devices 200a, 200b, 200c, ..., 200n. For example, terminal device 200a can establish a communication connection with the service server 100. Terminal devices 200a and 200b can establish a communication connection, and terminal devices 200a and 200c can also establish a communication connection. The communication connection method is not limited; it can be established directly or indirectly through wired communication or wireless communication, etc., depending on the actual application scenario. This application does not impose any restrictions on this.
[0022] It should be understood that, such as Figure 1 Each terminal device in the terminal cluster shown can have an application client installed. When the application client runs on each terminal device, it can interact with the aforementioned... Figure 1The business servers 100 shown interact with each other, enabling each business server 100 to receive business data from each terminal device. The application client can be a document editing application, browser, mini-program, social application, instant messaging application, live streaming application, game application, short video application, video application, music application, shopping application, novel application, payment application, or any other application client capable of displaying text, images, audio, and video data. This application client can be a standalone client or an embedded sub-client integrated into another client (such as an instant messaging client or social client); no limitation is made here. Taking a browser as an example, the business server 100 can be a collection of multiple servers, including the browser's corresponding backend server and data processing server. Therefore, each terminal device can transmit data with the business server 100 through the application client corresponding to that browser. For example, each terminal device can use the business server 100 to perform operations such as viewing page memory on the same browser with other terminal devices, enabling multi-party online collaboration. For example, terminal devices 200a, 200b, and 200c can jointly view or edit the same information collection form opened in a browser through the business server 100, including filling in personal identification information, contact information, address, etc. During the multi-party collaborative editing process, the editing interface of each terminal device can synchronously display the editing operation performed by any terminal device in real time (such as adding characters, deleting characters, etc.).
[0023] It is understood that the methods provided in this application embodiment can be executed by computer devices, including but not limited to terminal devices or business servers. The business server can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud databases, cloud services, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The terminal device can be a smartphone, tablet, laptop, desktop computer, PDA, mobile internet device (MID), wearable device (e.g., smartwatch, smart bracelet), smart computer, smart vehicle, or other smart terminal capable of running the above applications. The terminal device and the business server can be connected directly or indirectly via wired or wireless means, and this application embodiment does not impose any limitations on this connection.
[0024] In some feasible implementations, Figure 1 Each terminal device in the terminal cluster shown can have one or more browsers installed. When a browser runs on each terminal device, it can interact with the aforementioned browsers. Figure 1 Data interaction occurs between the business servers 100 shown. The browser used includes, but is not limited to, Google Chrome, Firefox, and Microsoft Edge, and the specific browser can be determined based on the actual application scenario; no limitation is imposed here. The application memory snapshot acquisition method provided in this application embodiment can be applied to memory detection when a browser or other application runs a specified page. The specified page can be a page opened by various types of web applications when executing program functions. A web application refers to an application that can be accessed through a browser. The various types of web applications include, but are not limited to, multimedia applications, social applications, educational applications, and utility applications; no limitation is imposed here.
[0025] The method provided in the embodiments of this application can be derived from, for example... Figure 1 The business server 100 shown can execute the service, but it can also be executed by a terminal device (such as...). Figure 1 The execution can be performed by any one of the terminal devices 200a, 200b, ..., 200n shown, or by both the terminal device and the service server. The specific execution method can be determined based on the actual application scenario and is not limited here. This embodiment will use the joint execution by terminal device 200a and service server 100 as an example for illustration, and will not be repeated below.
[0026] Assume that Google Chrome is installed on terminal device 200a and is running and displaying page M. Developer A wants to obtain a memory snapshot of Google Chrome through business server 100. First, developer A can send a memory snapshot retrieval command to terminal device 200a through business server 100. Then, business server 100 can detect data return events from Google Chrome on terminal device 200a. If the detected data return events include a memory snapshot return event fed back by Google Chrome based on the memory snapshot retrieval command, business server 100 can obtain a memory snapshot of the currently running page M in Google Chrome based on this memory snapshot return event.
[0027] Please see also Figure 2 This is an interactive schematic diagram of the application memory snapshot acquisition method provided in the embodiments of this application. For example... Figure 2As shown, assuming a Google Chrome browser is installed on terminal device 200a, to obtain a memory snapshot of the browser when accessing a specified page on terminal device 200a using Google Chrome, an automated memory detection tool platform can be configured on business server 100. This automated memory detection tool platform can be alloyperf. Specifically, business server 100 can send a request to Google Chrome to obtain an application memory snapshot via alloyperf, or obtain the application memory snapshot returned by the browser via alloyperf, thereby achieving automated memory detection of the specified page. This method is simple to operate and highly applicable. For ease of understanding, alloyperf will be used as the execution subject for automated memory detection of the specified page in the application memory snapshot acquisition method provided in this application embodiment for illustrative purposes; further details will not be elaborated upon below.
[0028] Optionally, alloyperf can create a Chromedriver (or Google Chrome driver). When the application server 100 needs to obtain a memory snapshot from the browser in the terminal device 200a, alloyperf can respond to the application's memory snapshot request and communicate with the Google Chrome in the terminal device 200a through a communication connection (or CDPConnection) based on the Chrome devtools protocol (CDP). Specifically, Chromedriver sends a memory snapshot retrieval command to the Google Chrome based on the CDP communication protocol, and detects the memory snapshot return event returned by the browser after the specified page is loaded and run, and obtains the memory snapshot returned by the browser based on the memory snapshot return event.
[0029] Optionally, in this embodiment, alloyperf can create corresponding drivers based on the browser that needs to obtain memory snapshots. For example, when the browser installed on the terminal device 200a is Firefox, alloyperf will create a Firefox driver (or Firefox browser driver). That is, it can send a memory snapshot acquisition command to Firefox via CDPConnection through the Firefox driver, and obtain the memory snapshot returned by the browser after detecting the specified page loaded and running in the browser. When the browser is Microsoft browser, alloyperf will create an Edge driver (or Microsoft browser driver). The method of obtaining memory snapshots is the same as the implementation method of using Google Chrome and Firefox as described above, and will not be repeated here. By automatically creating corresponding drivers for the browser that needs to obtain memory snapshots, alloyperf has stronger applicability to terminal devices with different browsers installed (including but not limited to the browsers mentioned above, and any browser that can communicate and transmit data with the browser driver created by alloyperf based on CDPConnection), that is, the operation of obtaining memory snapshots is more flexible and convenient.
[0030] Please see Figure 3 , Figure 3 This is a flowchart illustrating a method for obtaining application memory snapshots provided in an embodiment of this application, as shown below. Figure 3As shown, alloyperf first receives a request to retrieve an application memory snapshot. This request can carry information about the memory detection object (referred to as detection information), such as the URL of the page to be detected, the browser information running the page, and the snapshot storage path. After receiving the memory snapshot request, alloyperf can create and initialize a browser driver. Then, the browser driver triggers the browser to load and display the specified page. Specifically, the driver can start the browser and call the Application Programming Interface (API) to trigger the browser to load and display the specified page located based on the location information contained in the URL address. When it is detected whether the specified page has finished loading, it can check if a waiting time is set in the application memory snapshot request. If so, it waits for the specified time and then sends a memory snapshot retrieval command to the browser through the browser driver. Otherwise, it directly sends the memory snapshot retrieval command through the browser driver. The above memory snapshot retrieval command can trigger the browser to retrieve the runtime memory data of the currently displayed page. Furthermore, alloyperf can detect browser data postback events based on the browser driver. If, during the detection of browser-based data postback events, alloyperf detects a memory snapshot postback event based on a memory snapshot acquisition command, it acquires a memory snapshot based on that event (i.e., obtains a memory snapshot of the currently displayed page from the browser based on the memory snapshot postback event). Thus, browser drivers enable automated control of the browser, including launching the browser, controlling its access to specified pages, detecting browser events, and acquiring browser memory snapshot data. This allows for automated detection of browser page memory usage, greatly simplifying the memory snapshot acquisition process, improving efficiency, and overcoming the problems of existing technologies that typically require manually opening the application and clicking on a memory snapshot acquisition control during application usage—a cumbersome and inefficient process—enhancing applicability.
[0031] Optionally, in some alternative implementations, such as Figure 3 The method for obtaining application memory snapshots shown can be applied to the feature release pipeline of a front-end project (i.e., a specified page) to automate memory usage detection during the specified page's runtime. This allows the feature release process to automatically terminate when the application memory usage of the specified page is detected to be greater than or equal to an application memory usage threshold. Here, the aforementioned application memory usage threshold can be determined based on the application memory usage of the current version of the specified page. If based on... Figure 3If the application memory snapshot acquisition method shown detects that the application memory usage value is greater than or equal to the application memory usage threshold, it can be determined that there is a significant difference between the current release version and the live version, which can form a performance red line for the front-end project. At this time, the release process can be terminated, and an abnormal increase in runtime memory usage will be issued to inform the developers to take relevant measures to improve the release quality.
[0032] The following example illustrates how alloyperf obtains memory snapshots. Please refer to [link to example]. Figure 4 , Figure 4 This is another flowchart illustrating the method for obtaining application memory snapshots provided in this application embodiment, such as... Figure 4 As shown, the method for obtaining an application memory snapshot includes the following steps: Step S101: Receive an application memory snapshot acquisition request. The acquisition request is used to request the acquisition of a memory snapshot of the target application when the target application accesses a specified page.
[0033] In some feasible implementations, alloyperf (an automated memory testing tool platform) can receive requests for application memory snapshots. These requests can originate from a memory testing triggering application, which can be installed on the same business server configured with alloyperf. Developers use this triggering application to send the application memory snapshot request to alloyperf. This request may contain information about the memory testing object (i.e., testing information), which can be a specified page displayed on Google Chrome. The testing information may include the Uniform Resource Locator (URL) address of the specified page, browser information running the page (including browser name or version, etc.), and the snapshot storage path, etc., which can be determined based on the actual application scenario and are not limited here.
[0034] Please see also Figure 5 , Figure 5 This is a schematic diagram illustrating a scenario for obtaining an application memory snapshot, as provided in an embodiment of this application. Figure 5As shown, multiple applications can be installed on the business server 100, and these applications can be displayed on the user interface of the business server (such as interface 1). A user (e.g., developer A) can view the applications installed on the business server 100 (e.g., application X, application Y, and application Z) based on interface 1, and can also select any application based on interface 1, such as application X, application Y, or application Z in interface 1. Suppose developer A wants to open one of the applications for memory usage detection, such as application X (specifically, the application triggering the memory detection), then the business server 100 can respond to the trigger operation for application X (e.g., a click operation), and the interface displayed on its screen can switch from interface 1 to interface 200a. Specifically, interface 200a can display multiple detection information addition controls, which may include: browser addition control 20a, detection page URL addition control 20b, and snapshot storage path addition control 20c. Developer A can input the corresponding information in each of these relevant information addition controls. For example, assuming the memory snapshot you need to obtain is from Google Chrome, you can enter "Chrome" in the browser add control 20a field to select Google Chrome. Similarly, if the memory snapshot you need to obtain is from Firefox, you can enter "Firefox" in the browser add control 20a field. The information addition operations for adding controls 20b for detecting the page URL and 20c for the snapshot storage path are the same as for adding controls 20a, and will not be repeated here.
[0035] For example, suppose developer A wants to perform memory usage detection on a document page loaded and displayed using Google Chrome. Developer A can launch application X (the application that triggers the memory detection) and add relevant information about the memory detection object (the document page) to the interface of application X. This includes entering "Chrome" in the browser control 20a; entering "https: / / docs.qq.com / sheet / DWlNldllSZk1ua3J2?tab=BB08J2" (the URL address of the document test page) in the detection page URL control 20b; and entering the storage path "C:\Program Files\document" in the snapshot storage path control 20c. After adding the detection information, refer to interface 200b. Developer A can click the launch detection control 20e. After clicking, application X can send a request to obtain an application memory snapshot carrying all the above detection information to alloyperf. alloyperf can receive the application memory snapshot request and determine the target application (i.e., the browser indicated by the browser information carried in the application, such as Google Chrome) and the specified page (such as the document page) based on the request.
[0036] Optionally, in some feasible implementations, the above-mentioned detection information may also include a waiting time. In this case, the interface 200a displayed by the memory detection triggering application after responding to the trigger operation may also include a waiting time addition control, in which developer A can input the required waiting time value (the time unit can be seconds). See also Figure 6 , Figure 6 This is another scenario illustration of obtaining application memory snapshots provided in the embodiments of this application. For example... Figure 6 As shown, interface 201a includes a browser addition control 21a, a detection page URL addition control 21b, a wait time addition control 21c, and a snapshot storage path addition control 21d. For example, suppose that after triggering a browser (such as Google Chrome) to load and display a specified page (such as a document page), a wait time of 5 seconds needs to be set to wait for the page to finish loading. Then, on the operation interface 201a of application X, not only do we need to add browser information, the detection page URL, and the snapshot storage path, but we also need to enter a wait time of 5 seconds in the wait time addition control. After all the detection information is added, click the start detection control 21e to send a memory snapshot acquisition request to alloyperf. alloyperf can receive the above application memory snapshot acquisition request and can determine the target application (i.e., the browser indicated by the browser information carried in the acquisition application, such as Google Chrome), the specified page (such as a document page), and the wait time (such as 5 seconds) for acquiring a memory snapshot after opening the document page, etc., based on the above acquisition request.
[0037] It should be noted that the above Figure 5 and Figure 6 The display location and display format of the memory snapshot information are for illustrative purposes only. In actual applications, they can be adjusted according to product requirements. This application does not impose specific limitations on this.
[0038] Step S102: Based on the acquisition request, the target application is triggered to load and display the specified page, and when the specified page is loaded, a memory snapshot acquisition instruction is sent to the target application.
[0039] Step S103: Detect the data return event of the target application.
[0040] In some feasible implementations, after receiving a memory snapshot retrieval request from developer A based on application X, alloyperf can create and initialize the corresponding browser driver using this request. Specifically, alloyperf can create and initialize the corresponding browser driver based on the detection information carried in the received memory snapshot retrieval request. This browser driver can trigger the corresponding browser to load and display the specified page. For example, if the browser information carried in the memory snapshot retrieval request is Google Chrome, then alloyperf creates Chromedriver (i.e., the Google Chrome driver) and initializes it.
[0041] Furthermore, Chromedriver can launch Google Chrome and call its API to trigger Google Chrome to load and display a specified page. Specifically, Chromedriver calls the corresponding API based on the detection page URL carried in the memory snapshot retrieval request. The detection page URL contains location information to the specified page. For example, developer A triggers the launch of the detection control by adding relevant information about a memory detection object (e.g., a document page, which is loaded and displayed by Google Chrome) to the interface of application X. Alloyperf receives the memory snapshot retrieval request, creates and initializes Chromedriver, Chromedriver launches Google Chrome, and calls the corresponding API based on the obtained detection page URL (which could be "https: / / docs.qq.com / sheet / DWlNldllSZk1ua3J2?tab=BB08J2"), triggering Google Chrome to load and display the page corresponding to the URL.
[0042] Optionally, in some feasible implementations, the memory snapshot acquisition request received by alloyperf may also carry browser information, specifically Firefox. In this case, alloyperf can create and initialize a Firefox driver based on this detection information. Furthermore, the Firefox driver can launch Firefox and call the corresponding API according to the detected page URL in the detection information carried in the memory snapshot acquisition request, triggering Firefox to load and display the page corresponding to the URL.
[0043] Please see Figure 7a This is another scenario illustration of obtaining application memory snapshots provided in the embodiments of this application. For example... Figure 7a As shown, the Chromedriver triggers the Google Chrome browser on the terminal device to open the document page, and Google Chrome displays the document page loading status as shown in interface 300a. Specifically, interface 300a includes a page address bar detection (which could be a URL display box) 301a. The URL displayed in this box can be carried by the memory snapshot acquisition request sent by application X, corresponding to the aforementioned document page. Interface 300a also includes a driver control status box 302a, which can indicate that the current browser is under driver control through text. For example, when Chromedriver controls Google Chrome, Google Chrome can display "Chrome is being controlled by automated testing software" in the driver control status box 302a. Interface 300a also includes a loading status box 303a, which can indicate that the page in the current browser is loading (including loading progress, etc.) through text. For example, when Google Chrome opens the document page, before the page is fully loaded, Google Chrome can display the text "LOADING..." in the loading status box 303a to indicate that the current page has not yet finished loading.
[0044] Please see Figure 7b , Figure 7b This is another scenario illustration of obtaining application memory snapshots provided in the embodiments of this application. For example... Figure 7b As shown, after the page has finished loading, Google Chrome displays a message indicating that the document page has finished loading, as shown in interface 300b. Specifically, interface 300b also includes a page address bar and a driver control status box, and the displayed content can be the same as interface 300a. Furthermore, interface 300b includes all the content of the document page after it has finished loading, as shown in page content display 301b. After the page has finished loading, a text table can be displayed.
[0045] In some feasible implementations, alloyperf can receive a page loading completion notification from the browser. Upon confirming the completion, it sends a memory snapshot retrieval command to the browser via the browser driver (which could be Chromedriver). This command triggers the browser to retrieve the runtime memory data of the currently displayed page. For example, if alloyperf receives a page loading completion notification from Google Chrome and confirms the completion, it sends a memory snapshot retrieval command (which could be HeapProfiler.takeHeapSnapshot) to Google Chrome via Chromedriver. Upon receiving this command, Google Chrome begins retrieving a memory snapshot of the currently displayed page (which could be a document page).
[0046] Furthermore, while sending the memory snapshot fetch command, alloyperf can also detect browser-based data postback events. Specifically, alloyperf can detect all data postback events occurring in the browser being monitored. For example, after confirming that the page has finished loading, alloyperf sends a memory snapshot fetch command to Google Chrome via Chromedriver, and simultaneously detects all data postback events in Google Chrome. Assuming that Google Chrome can have data postback events H1 and H2 during the monitored time period, where data postback event H1 represents the browser transmitting data K1 externally, and data postback event H2 represents the browser transmitting data K2 externally, then alloyperf can detect the occurrence of both of these events.
[0047] Optionally, in some feasible implementations, before alloyperf sends the memory snapshot retrieval command to the browser via the browser driver, alloyperf can also determine page loading completion by waiting time. Specifically, alloyperf obtains the waiting time from the memory snapshot retrieval request. Assuming this waiting time is M seconds, after alloyperf opens the browser and the specified page via the browser driver, it can directly determine that the specified page has finished loading after waiting for M seconds, and then continues to send the memory snapshot retrieval command to the browser via the browser driver. For example, developer A not only adds browser information (such as Google Chrome), the detection page URL (such as the document page URL), and snapshot storage path detection information to the operation interface of application X, but also enters a waiting time of 5 seconds in the waiting time control. Developer A clicks the start detection control to send a memory snapshot retrieval request to alloyperf. alloyperf obtains the waiting time from the memory snapshot retrieval request, opens the Google Chrome browser and the document page via Chrome, waits five seconds to confirm that the page has finished loading, and then sends the memory snapshot retrieval command to the Google Chrome browser via Chromedriver.
[0048] Optionally, in some feasible implementations, page loading can also be achieved by executing JavaScript code through the browser. Specifically, when alloyperf triggers the browser to load a specified page via the browser driver, it can trigger the browser to execute JavaScript code that waits for page loading. Here, the page loading wait time in the JavaScript code can be set to M seconds. This JavaScript code can be deployed in a specified storage space of the browser. alloyperf triggers the browser to call and execute the JavaScript code to achieve page loading waiting. Optionally, this JavaScript code can also be deployed in the browser driver. The browser driver can provide the browser with an interface to call this JavaScript code. alloyperf can trigger the browser to call and execute this JavaScript code to achieve page loading waiting. The specific implementation can be determined according to the actual application scenario and is not limited here.
[0049] Step S104: When the data return event includes a memory snapshot return event fed back by the target application based on the memory snapshot acquisition instruction, obtain a memory snapshot of the target application running the specified page based on the memory snapshot return event.
[0050] In some feasible implementations, if alloyperf detects a memory snapshot postback event (also known as the onmesage event in code implementation) based on a memory snapshot retrieval command during the detection of browser-based data postback events, it can obtain a memory snapshot of the currently displayed page from the browser based on this event. For example, alloyperf detects all data postback events of Google Chrome through the browser driver corresponding to Google Chrome. Assuming that Google Chrome may have data postback events H1 and H2 during the detected time period, if in data postback event H2, the data H2 transmitted by Google Chrome to the outside is the current page's runtime memory data (which could be the runtime memory data of the document page), that is, the event is a response from Google Chrome to sending a memory snapshot retrieval command to the browser based on the aforementioned Chromedriver, then alloyperf can further obtain a memory snapshot of the currently displayed page based on data postback event H2.
[0051] In this embodiment, alloyperf can respond to application memory snapshot retrieval requests. These requests may carry information about the memory detection object (i.e., detection information), such as the URL of the page to be detected, the browser information running the page, and the snapshot storage path. Upon receiving a memory snapshot retrieval request (which may originate from the memory detection triggering application), alloyperf can create and initialize a corresponding browser driver. This browser driver can launch the browser and call its API to trigger the browser to load and display the specified page located based on the location information contained in the URL. Further, when the specified page is detected to have finished loading, a memory snapshot retrieval instruction is sent to the browser via the browser driver. This instruction can trigger the browser to retrieve the runtime memory data of the currently displayed page. Optionally, alloyperf can simultaneously detect browser-based data postback events. If, during the detection of browser-based data postback events, alloyperf detects a memory snapshot postback event fed back by the memory snapshot retrieval instruction, it retrieves the memory snapshot of the currently displayed page from the browser based on this event. Therefore, it is evident that automating browser control by invoking the browser driver includes launching the browser and specified pages, detecting browser events, and acquiring memory snapshot data. This enables automated detection of browser page memory usage, greatly simplifying the memory snapshot acquisition process, improving efficiency, and enhancing applicability.
[0052] Further, please see Figure 8 , Figure 8 This is another flowchart illustrating the method for obtaining application memory snapshots provided in this application embodiment. For example... Figure 8 As shown, the method for obtaining an application memory snapshot includes the following steps: Step S401: Receive an application memory snapshot acquisition request. The acquisition request is used to request the acquisition of a memory snapshot of the target application when the target application accesses a specified page.
[0053] The specific process for this step can be found above. Figure 1 Step S101 in the corresponding embodiment will not be described again here.
[0054] Step S402: Based on the acquisition request, the target application is triggered to load and display the specified page, and when the specified page is loaded, a memory snapshot acquisition instruction is sent to the target application.
[0055] Step S403: Detect the data return event of the target application.
[0056] For details of the above steps, please refer to the above. Figure 1Steps S102 and S103 in the corresponding embodiments will not be described again here.
[0057] Step S404: When the data return event includes a memory snapshot return event based on the memory snapshot acquisition instruction feedback from the target application, the callback function associated with the memory snapshot return event is called, and the page running memory data of the specified page fed back by the target application is obtained through the callback function.
[0058] In some feasible implementations, alloyperf can detect all data postback events occurring in the browser being tested. The platform parses the data sent by the browser, obtaining the name of the detected event, and can then call the corresponding callback function based on that event name. Specifically, during the detection of browser-based data postback events, alloyperf can parse the returned data and obtain event names T1 and T2. Event name T1 is the target detected event, and its associated callback function C1 can be called through event name T1. For example, during alloyperf's detection of Google Chrome (where the browser displays a document page), if parsing the data returned by Google Chrome yields event name T1, and event name T1 represents a memory snapshot postback event based on the browser's memory snapshot acquisition instruction, then alloyperf can call the associated callback function C1 through event name T1. This callback function C1 can obtain the runtime memory data of the currently running document page returned by the detected browser.
[0059] Optionally, in some feasible implementations, when the callback function finishes retrieving the page's runtime memory data, it can receive a callback end indicator from the browser. Specifically, this callback end indicator can be an `id` parameter, which can notify `alloyperf` that the runtime memory data of the specified page being retrieved from the browser has been received. For example, `alloyperf` calls the associated callback function `C1` through event name `T1`. After callback function `C1` finishes retrieving the runtime memory data of the running document page from Google Chrome, it can receive an `id` parameter `D1`. The `id` parameter `D1` can notify `alloyperf` that the runtime memory data from Google Chrome has been received. After receiving the `id` parameter `D1`, `alloyperf` stops calling callback function `C1`.
[0060] Step S405: Obtain a memory snapshot of the target application from the page runtime memory data.
[0061] See some feasible implementation methods Figure 9 , Figure 9This is another flowchart illustrating the method for obtaining application memory snapshots provided in this application embodiment, such as... Figure 9 As shown, `alloyperf` first obtains the page's runtime memory data (i.e., receives the page's runtime memory data from the browser running the specified page by calling the aforementioned callback function). Then, it parses the page's runtime memory data, obtaining memory usage data for various types of nodes. This page's runtime memory data includes at least one target type of node, i.e., a node related to the generation of the specified page's memory snapshot. The memory usage data of all target types of nodes is integrated, and finally, a memory snapshot of the specified page running in the browser is generated. For example, after parsing the received page's runtime memory data (such as the runtime memory data of a document page), memory usage data for types A, B, and C nodes is obtained. Since the memory usage data of types A and B nodes are related to the generation of the document page's memory snapshot, then types A and B nodes are target type nodes. `alloyperf` can parse and integrate the memory usage data of all target types of nodes to generate a memory snapshot of the document page running in the browser.
[0062] Optionally, in some feasible implementations, after alloyperf generates a memory snapshot of the browser, it can save the memory snapshot to a specified storage path (such as a specified folder or database), or generate a memory report in a specified data format based on the memory snapshot. Specifically, the memory report can be an Excel spreadsheet report, which can include the type of terminal device running and installing the browser (such as a computer, smartphone, etc.), and can also include the memory usage of different pages (such as document page A1, document page A2, etc.) tested on the same terminal device. For example, assuming that alloyperf generates a memory snapshot of the browser and then generates a memory report in Excel spreadsheet format based on the memory snapshot, as shown in Table 1 below: Table 1
[0063] Table 1 above is a memory report of browser-running document pages generated by alloyperf. As shown in Table 1, the terminal device type column includes terminal device B1 (e.g., computer) and terminal device B2 (e.g., smartphone); the detected page column shows the types of pages whose memory usage was detected. For example, for both terminal devices B1 and B2, memory usage was detected for document pages A1, A2, and A3, respectively; the memory usage detection value column shows the final page memory usage value. For example, on terminal device B1, when running document page A1 using the browser installed on that terminal device (e.g., Google Chrome), alloyperf can detect that document page A1 occupies 32.9MB of memory.
[0064] Optionally, in some feasible implementations, after generating a memory snapshot of the browser running the specified page, the memory usage value of the browser running the specified page can be obtained based on the received memory snapshot. When the memory usage value is greater than or equal to the memory usage threshold, an abnormal increase in the running memory usage of the specified page is issued. For example, taking document page A1 as an example, before the developers make new modifications to the page (such as adding new features), the memory usage of the browser running the page is tested and found to be N MB. Assuming that the safe range for memory usage growth is 0 MB to 20 MB, the memory usage threshold for this application is N+20 MB. After modifying the page, the memory usage is checked again. If the memory usage value is found to be greater than or equal to N+20 MB, it can be determined that the current release version of the specified page differs significantly from the live version. At this time, an abnormal increase in running memory usage can be issued to inform the developers to take relevant measures. In addition, the release process of the current release version of the specified page can also be terminated to trigger the developers to take relevant measures to adjust the release parameters of the version.
[0065] Optionally, in some feasible implementations, after alloyperf generates a memory snapshot of the browser running a specified page, it can call the browser driver's API to close the specified page and the target application. For example, after generating a memory snapshot of a document page running in Google Chrome, alloyperf can call the corresponding API through Chromedriver to trigger Google Chrome to close the document page and then close Google Chrome. This operation is simple and highly applicable.
[0066] In this embodiment, alloyperf can respond to application memory snapshot retrieval requests. These requests may carry information related to the memory detection object (referred to as detection information), such as the URL of the page to be detected, the browser information running the page, and the snapshot storage path. Upon receiving a memory snapshot retrieval request (which may originate from the memory detection triggering application), alloyperf can create and initialize a corresponding browser driver. This browser driver can launch the browser and call its API to trigger the browser to load and display the specified page located based on the location information contained in the URL. Furthermore, when the specified page is detected to have finished loading, a memory snapshot retrieval instruction is sent to the browser via the browser driver. This instruction triggers the browser to retrieve the runtime memory data of the currently displayed page. Additionally, alloyperf can simultaneously detect browser-based data postback events. If, during the detection of browser-based data postback events, alloyperf detects a memory snapshot postback event fed back by the memory snapshot retrieval instruction, it calls the callback function associated with the memory snapshot postback event and retrieves the page runtime memory data of the specified page from the target application through this callback function. After receiving the aforementioned page runtime memory data, alloyperf can parse and integrate the memory usage data of all target type nodes (i.e., nodes related to the generation of the target page's memory snapshot) within the page runtime memory data, generating a memory snapshot of the target page running in the browser. Therefore, by calling the browser driver to automate browser control—including launching the browser and the specified page, detecting browser events, and calling callback functions to obtain memory snapshot data—automatic detection of browser page memory usage can be achieved, greatly simplifying the memory snapshot acquisition operation, improving memory snapshot acquisition efficiency, and enhancing applicability.
[0067] Based on the description of the above application recommendation method embodiments, this application also discloses an application memory snapshot acquisition device (which can be simply referred to as a memory snapshot acquisition device for convenience). This memory snapshot acquisition device can be a computer program (including program code) running on a terminal. This application recommendation device can be applied to... Figures 1-9 In the application memory snapshot acquisition method of the illustrated embodiment, the steps in the application memory snapshot acquisition method are used for execution. Here, the application memory snapshot acquisition device can be the one described above. Figures 1-9 The business server or terminal device in the illustrated embodiment, i.e., the device for obtaining the application memory snapshot, can be the... Figures 1-9 The embodiment shown is the execution entity of the method for obtaining memory snapshots.
[0068] Please see Figure 10 , Figure 10 This is a schematic diagram of an application memory snapshot acquisition device provided in an embodiment of this application. In this embodiment, the application memory snapshot acquisition device can run the following modules: The request receiving module 51 is used to receive a request to obtain an application memory snapshot, wherein the request is used to request to obtain a memory snapshot of the target application when the target application accesses a specified page.
[0069] Processing module 52 is used to trigger the target application to load and display the specified page, and to send a memory snapshot acquisition instruction to the target application.
[0070] Page detection module 53 is used to detect data return events of the target application (this module can be EventEmiter).
[0071] The processing module 52 is also used to obtain a memory snapshot of the target application running the specified page based on the memory snapshot return event when the page detection module 53 detects that the data return event includes a memory snapshot return event fed back by the target application based on the memory snapshot acquisition instruction.
[0072] In some feasible implementations, the processing module 52 is further configured to: Call the callback function associated with the memory snapshot postback event, obtain the page runtime memory data of the specified page as fed back by the target application through the callback function, and generate a memory snapshot of the target application based on the page runtime memory data.
[0073] In some feasible implementations, before generating the memory snapshot of the target application based on the page runtime memory data, the processing module 52 is further configured to: When the memory snapshot acquisition identifier is obtained from the page runtime memory data of the specified page returned by the target application through the above callback function, it is determined that the acquisition of the page runtime memory data of the target application is complete.
[0074] In some feasible implementations, the processing module 52 is further configured to: Obtain memory usage data for each node in at least one target type from the above page runtime memory data; Integrate memory usage data for all nodes across all target types and generate a memory snapshot of the aforementioned target applications.
[0075] Please see also Figure 10 The aforementioned memory snapshot acquisition device may further include: a memory prompting module 55.
[0076] The memory alert module 55 is used to obtain the memory usage of the target application when running the specified page based on the memory snapshot of the target application obtained from the processing module 52. When the memory usage is greater than or equal to the memory usage threshold, an alert is issued indicating abnormal growth in memory usage when running the specified page.
[0077] Please see also Figure 10 The aforementioned memory snapshot acquisition device may further include: a snapshot processing module 54.
[0078] The snapshot processing module 54 is used to store the memory snapshot of the target application into a specified storage path; or to generate a memory report in a specified data format based on the memory snapshot of the target application.
[0079] In some feasible implementations, the above-mentioned acquisition request carries a Uniform Resource Locator (URL) address, and the above-mentioned processing module 52 is further used for: Based on the above acquisition request, the target application is determined, the application driver corresponding to the target application is created and initialized, and the target application is started through the application driver.
[0080] Calling the application programming interface (API) of the aforementioned application driver triggers the target application to load and display the specified page located at the aforementioned URL address.
[0081] In some feasible implementations, after generating the memory snapshot of the target application, the processing module 52 is further configured to: Call the API mentioned above, which is driven by the application, to close the specified page and the target application.
[0082] According to the above Figure 4 The corresponding implementation, Figure 4 The implementation method described in steps S101 to S104 of the application memory snapshot acquisition method shown can be derived from... Figure 10 The various modules of the illustrated device are executed. For example, the above... Figure 4 The implementation method described in step S101 of the application memory snapshot acquisition method shown can be derived from... Figure 10 In the illustrated device, the request receiving module 51 performs the execution; the implementation described in step S102 can be performed by the processing module 52; the implementation described in step S103 can be performed by the page detection module 53; and the implementation described in step S104 can be performed by the processing module 52. The implementation methods performed by the request receiving module 51, processing module 52, and page detection module 53 are as described above. Figure 4 The implementation methods provided for each step in the corresponding embodiments will not be repeated here.
[0083] According to the above Figure 8The corresponding implementation, Figure 8 The implementation methods described in steps S401 to S405 of the application memory snapshot acquisition method shown can be derived from... Figure 10 The various modules of the illustrated device are executed. For example, the above... Figure 4 The implementation method described in step S401 of the application memory snapshot acquisition method shown can be derived from... Figure 10 In the illustrated device, the request receiving module 51 performs the execution; the implementation described in step S402 can be executed by the processing module 52; the implementation described in step S403 can be executed by the page detection module 53; and the implementations described in steps S404 and S405 can be executed by the processing module 52. The implementation methods executed by the request receiving module 51, processing module 52, and page detection module 53 are as described above. Figure 8 The implementation methods provided for each step in the corresponding embodiments will not be repeated here.
[0084] Alternatively, in some other feasible implementations, please refer to Figure 11 , Figure 11 This is a schematic diagram of the processing module in the memory snapshot acquisition device according to an embodiment of this application. Figure 11 As shown, the processing module may include a snapshot receiving module, a command sending module, and a browser driver module. The browser driver module includes a communication connection module (which may be a module based on the CDPConnection protocol for communication connection), which the browser driver uses to communicate with the corresponding browser (e.g., sending a command to open a specified page). The browser driver module also includes a page processing module (which may be ThenableWebDriver), which the browser driver uses to control the browser to launch or open a specified page.
[0085] In the embodiments of this application, the above Figure 11 The modules in the illustrated device can be individually or entirely combined into one or more other modules, or some of the modules can be further divided into multiple functionally smaller modules. This achieves the same operation without affecting the technical effects of the embodiments of this application. The above modules are based on logical function division. In practical applications, the function of one module can be implemented by multiple modules, or the function of multiple modules can be implemented by one module. In other feasible implementations of this application, the above device may also include other modules. In practical applications, these functions can also be implemented with the assistance of other modules, and can be implemented collaboratively by multiple modules, without limitation.
[0086] In this embodiment, the application memory snapshot acquisition device can respond to an application memory snapshot acquisition request. This request may carry detection information, such as the URL of the page to be detected, the browser information running the page, and the snapshot storage path. Upon receiving the memory snapshot acquisition request, a corresponding browser driver can be created and initialized. This browser driver can launch the browser and call its API to trigger the browser to load and display the specified page located based on the location information contained in the URL. Further, when the specified page is detected to have finished loading, a memory snapshot acquisition instruction is sent to the browser via the browser driver. This instruction can trigger the browser to acquire the runtime memory data of the currently displayed page. Further, the device can simultaneously detect browser-based data return events. If a memory snapshot return event based on the memory snapshot acquisition instruction is detected during the detection of browser-based data return events, the callback function associated with the memory snapshot return event is called, and the page runtime memory data of the specified page returned by the target application is acquired through this callback function. After receiving the aforementioned page runtime memory data, the device can parse and integrate the memory usage data of all target type nodes (i.e., nodes related to the generation of the target page's memory snapshot) within the page runtime memory data, generating a memory snapshot of the browser running the target page. Therefore, by calling the browser driver to automate browser control—including launching the browser and the specified page, detecting browser events, and calling callback functions to obtain memory snapshot data—automatic detection of browser page memory usage can be achieved, greatly simplifying the memory snapshot acquisition operation, improving memory snapshot acquisition efficiency, and enhancing applicability.
[0087] Please see Figure 12 This is a schematic diagram of the structure of the computer device provided in an embodiment of this application. Figure 12 As shown, the computer device 1000 can be the above-mentioned Figure 1The corresponding embodiment includes a business server 100. This computer device 1000 may include a processor 1001, a network interface 1004, and a memory 1005. Furthermore, the computer device 1000 may also include a user interface 1003 and at least one communication bus 1002. The communication bus 1002 is used to enable communication between these components. The user interface 1003 may include a display screen and a keyboard; optionally, the user interface 1003 may also include a standard wired interface or a wireless interface. The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface). The memory 1004 may be high-speed RAM or non-volatile memory, such as at least one disk storage device. The memory 1005 may optionally be at least one storage device located remotely from the aforementioned processor 1001. Figure 12 As shown, the memory 1005, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and a device control application program.
[0088] The network interface 1004 in the computer device 1000 can also be connected to the aforementioned Figure 1 The terminal 200a in the corresponding embodiment connects to the network, and the optional user interface 1003 may further include a display screen and a keyboard. Figure 12 In the computer device 1000 shown, the network interface 1004 provides network communication functionality; the user interface 1003 is mainly used to provide an input interface for users (or developers); and the processor 1001 can be used to call the device control application stored in the memory 1005 to achieve: Receive an application memory snapshot retrieval request. The retrieval request is used to request the retrieval of the memory snapshot of the target application when the target application accesses the specified page. Based on the above acquisition request, the target application is triggered to load and display the specified page, and when the specified page is loaded, a memory snapshot acquisition instruction is sent to the target application. Detect the data return events of the target application mentioned above; When the above data return event is detected to include a memory snapshot return event fed back by the target application based on the memory snapshot acquisition instruction, a memory snapshot of the target application running the specified page is obtained based on the memory snapshot return event.
[0089] It should be understood that the computer device 1000 described in the embodiments of this application can execute the foregoing text. Figure 4 or Figure 8The description of the method for obtaining application memory snapshots in the corresponding embodiments will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated.
[0090] Furthermore, it should be noted that this application embodiment also provides a computer storage medium, which stores a computer program executed by the aforementioned application memory snapshot acquisition device. The computer program includes program instructions, and when the processor executes the program instructions, it can execute the aforementioned... Figure 4 or Figure 8 The description of the method for obtaining application memory snapshots in the corresponding embodiments is already provided and will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated. For technical details not disclosed in the embodiments of the computer storage medium involved in this application, please refer to the description of the method embodiments of this application.
[0091] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.
[0092] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.
Claims
1. A method for obtaining application memory snapshots, characterized in that, The method includes: The system responds to a trigger operation of a memory detection trigger application displayed on the user interface, and displays the operation interface of the memory detection trigger application, on which multiple detection information addition controls are displayed. The application receives a request to obtain an application memory snapshot after the memory detection triggering application has completed the input of the information corresponding to the multiple detection information addition controls. The request carries the target application and the Uniform Resource Locator address based on the input of the multiple detection information addition controls. The request is used to request to obtain the memory snapshot of the target application when the target application accesses the specified page located by the Uniform Resource Locator address. Create and initialize the application driver corresponding to the target application, start the target application through the application driver, call the application programming interface of the application driver to trigger the target application to load and display the specified page, and when the specified page is loaded, send a memory snapshot acquisition instruction to the target application; Detect the data return event of the target application; When the data return event includes a memory snapshot return event fed back by the target application based on the memory snapshot acquisition instruction, a memory snapshot of the target application running the specified page is obtained based on the memory snapshot return event.
2. The method according to claim 1, characterized in that, The step of obtaining a memory snapshot of the target application running the specified page based on the memory snapshot postback event includes: The callback function associated with the memory snapshot postback event is invoked, and the page runtime memory data of the specified page fed back by the target application is obtained through the callback function. Based on the page runtime memory data, a memory snapshot of the target application is generated.
3. The method according to claim 2, characterized in that, Before generating a memory snapshot of the target application based on the page runtime memory data, the method further includes: When the memory snapshot acquisition identifier is obtained from the page runtime memory data of the target application running the specified page, as reported by the callback function, it is determined that the acquisition of the page runtime memory data of the target application is complete.
4. The method according to claim 3, characterized in that, The process of generating a memory snapshot of the target application based on the page runtime data includes: Obtain memory usage data of each node in at least one target type from the page runtime memory data; Integrate memory usage data for all nodes across all target types and generate a memory snapshot of the target application.
5. The method according to claim 4, characterized in that, After generating the memory snapshot of the target application, the method further includes: The memory usage of the target application when running the specified page is obtained based on the memory snapshot of the target application; When the memory usage is greater than or equal to the memory usage threshold, an abnormal increase in memory usage for the specified page is issued.
6. The method according to claim 4, characterized in that, After generating the memory snapshot of the target application, the method further includes: Store a memory snapshot of the target application in a specified storage path; or generate a memory report in a specified data format based on the memory snapshot of the target application.
7. An apparatus for obtaining application memory snapshots, characterized in that, include: The request receiving module is used to respond to the triggering operation of the memory detection triggering application displayed on the user operation interface, and to display the operation interface of the memory detection triggering application, and to display multiple detection information adding controls on the operation interface; The application receives a request to obtain an application memory snapshot after the memory detection triggering application has completed the input of the information corresponding to the multiple detection information addition controls. The request carries the target application and the Uniform Resource Locator address based on the input of the multiple detection information addition controls. The request is used to request to obtain the memory snapshot of the target application when the target application accesses the specified page located by the Uniform Resource Locator address. The processing module is used to create and initialize the application driver corresponding to the target application, start the target application through the application driver, call the application programming interface of the application driver to trigger the target application to load and display the specified page, and send a memory snapshot acquisition instruction to the target application when the specified page has finished loading. The page detection module is used to detect data return events of the target application; The processing module is further configured to, when the page detection module detects that the data return event includes a memory snapshot return event fed back by the target application based on the memory snapshot acquisition instruction, obtain a memory snapshot of the target application running the specified page based on the memory snapshot return event.
8. A computer device, characterized in that, include: Processor, memory, and network interface; The processor is connected to the memory and the network interface, wherein the network interface is used to provide data communication functions, the memory is used to store program code, and the processor is used to call the program code to execute the method according to any one of claims 1-6.
9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program adapted to be loaded by a processor and to execute the method of any one of claims 1-6.
Citation Information
Patent Citations
CN108287781A