Application fault finding method and device, storage medium and electronic equipment
Patent Information
- Application Number
- CN202210368001.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-04-08
- Publication Date
- 2026-08-21
- Estimated Expiration
- 2042-04-08
AI Technical Summary
[0005]本发明实施例提供了一种应用程序的故障查找方法和装置、存储介质及电子设备,以至少解决现有故障查找方法的查找效率低的技术问题
[0010]根据本发明实施例的又一方面,还提供了一种电子设备,包括存储器和处理器,上述存储器中存储有计算机程序,上述处理器被设置为通过所述计算机程序执行上述的应用程序的故障查找方法。
Smart Images

Figure CN116932376B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of computers, and more specifically, to a method and apparatus for troubleshooting applications, a storage medium, and an electronic device. Background Technology
[0002] During daily use of an app, users frequently encounter various problems, such as lag on a specific page or navigation errors during page transitions, severely impacting the user experience. For app developers, resolving these issues encountered by users during daily use is a crucial task.
[0003] Current methods for troubleshooting user-encountered issues typically involve analyzing problem descriptions and screenshots from user feedback, followed by repeated debugging to find the root cause. However, since user-encountered issues are usually sporadic, developers find it difficult to reproduce the problems based solely on descriptions and screenshots. In other words, existing application troubleshooting methods suffer from low efficiency.
[0004] There is currently no effective solution to the above problems. Summary of the Invention
[0005] This invention provides a method and apparatus for troubleshooting applications, a storage medium, and an electronic device, to at least solve the technical problem of low troubleshooting efficiency in existing troubleshooting methods.
[0006] According to one aspect of the present invention, a method for troubleshooting an application is provided, comprising: obtaining an application environment description file sent by a target terminal device where a first application is located, wherein the application environment description file includes: a system description file describing a first system environment of the target terminal device, and a status description file describing the running state of the first application; generating a second system environment in a current virtual machine based on the application environment description file, and running a second application in the second system environment, wherein the environment similarity between the second system environment and the first system environment is greater than a first threshold, and the second application and the first application are applications running in the same state; and troubleshooting faults occurring in the second application.
[0007] According to another aspect of the present invention, an application fault finding apparatus is also provided, comprising: an acquisition unit, configured to acquire an application environment description file sent by a target terminal device where a first application is located, wherein the application environment description file includes: a system description file describing a first system environment of the target terminal device, and a status description file describing the running state of the first application; a generation unit, configured to generate a second system environment in a current virtual machine according to the application environment description file, and run a second application in the second system environment, wherein the environmental difference between the second system environment and the first system environment is less than a first threshold, and the second application and the first application are applications running in the same state; and a finding unit, configured to find faults occurring in the second application.
[0008] According to another aspect of the present invention, a computer-readable storage medium is also provided, wherein a computer program is stored therein, wherein the computer program is configured to execute the fault finding method of the above-described application program at runtime.
[0009] According to another aspect of the embodiments of this application, a computer program product or computer program is provided, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform a fault-finding method as described above in the application.
[0010] According to another aspect of the present invention, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the fault-finding method of the application program described above through the computer program.
[0011] In this embodiment of the invention, an application environment description file sent by the target terminal device where the first application resides is obtained; a second system environment is generated in the current virtual machine according to the application environment description file, and the second application is run in the second system environment, wherein the environmental difference between the second system environment and the first system environment is less than a first threshold, and the second application and the first application are applications running in the same state; faults appearing in the second application are searched, thereby realistically recreating the user's problem scenario on the test end according to the application environment description file fed back by the user, and performing fault search in the recreated problem scenario, thus avoiding the need to perform fault search operations while maintaining a connection with the user end, realizing the technical operation of asynchronous fault search operation remotely, that is, solving the technical problem of low search efficiency in existing fault search methods. Attached Figure Description
[0012] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings:
[0013] Figure 1 This is a schematic diagram of the hardware environment for an optional application fault finding method according to an embodiment of the present invention;
[0014] Figure 2 This is a flowchart of an optional application troubleshooting method according to an embodiment of the present invention;
[0015] Figure 3 This is a schematic diagram of an optional application troubleshooting method according to an embodiment of the present invention;
[0016] Figure 4 This is a schematic diagram of another optional application fault finding method according to an embodiment of the present invention;
[0017] Figure 5 This is a schematic diagram of another optional application troubleshooting method according to an embodiment of the present invention;
[0018] Figure 6 This is a schematic diagram of another optional application troubleshooting method according to an embodiment of the present invention;
[0019] Figure 7 This is a schematic diagram of another optional application troubleshooting method according to an embodiment of the present invention;
[0020] Figure 8 This is a schematic diagram of another optional application troubleshooting method according to an embodiment of the present invention;
[0021] Figure 9 This is a flowchart of another optional application troubleshooting method according to an embodiment of the present invention;
[0022] Figure 10 This is a schematic diagram of the structure of an optional application fault finding device according to an embodiment of the present invention;
[0023] Figure 11 This is a schematic diagram of the structure of an optional electronic device according to an embodiment of the present invention. Detailed Implementation
[0024] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.
[0025] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.
[0026] It is understood that in the specific embodiments of this application, data related to the operation information of the identified object is involved. When the above embodiments of this application are applied to specific products or technologies, it is necessary to obtain the authorization or consent of the identified object, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.
[0027] It should be noted that, in the specific implementation of this application, the above-mentioned operation method can refer to operations such as transfer, extraction, and recharge of virtual resources performed through the platform; the above-mentioned target identifier is an identifier object on the virtual platform used to identify the operator of the above-mentioned behavior, and can be used to determine the operator who actually performs the above-mentioned operation.
[0028] The following explains the technical terms that appear in this application:
[0029] ART (Android Runtime) Virtual Machine: A virtual machine is a complete computer system simulated by software, possessing full hardware system functionality and running in a completely isolated environment. The ART virtual machine is the virtual machine used by the Android system from version 4.4 onwards to run Android mobile phone software.
[0030] Remote users: refers to the group of users who report problems when they encounter unavailable or malfunctioning functions while using the app;
[0031] Cloud Object Storage (COS) is a distributed storage service that has no directory hierarchy, no data format restrictions, can accommodate massive amounts of data, and supports access via HTTP / HTTPS protocols.
[0032] Page stack (Activity stack): In Android, Activity components are used to display pages to the user. When entering the next display page, the next page is placed on top of the previous page, forming a stack structure.
[0033] HProf (Heap Profile) file: A memory snapshot of an Android device, a data file used to record the values of memory objects in the application process at that moment;
[0034] Socket long connection: a point-to-point network protocol stack that maintains the connection between the terminal and the cloud, enabling data / command interaction between the terminal and the cloud;
[0035] JDWP (Java Debug Wire Protocol): It defines the communication protocol between the debugger and the Java Virtual Machine (target VM) being debugged;
[0036] Heap area: The storage space for objects declared by the program in the ART virtual machine and objects escaped from the stack space, which stores references and values of instance objects.
[0037] According to one aspect of the present invention, a method for troubleshooting an application is provided. Optionally, as an optional implementation, the above-described method for troubleshooting an application can be applied to, but is not limited to, applications such as... Figure 1 The system shown is a troubleshooting system for an application program, consisting of server 102, server 108, and terminal devices 104 and 106. Figure 1 As shown, server 102 is connected to terminal device 104 via network 110, and terminal device 106 is also connected to server 108 via network 110. The aforementioned network may include, but is not limited to, wired networks and wireless networks. The wired network includes local area networks (LANs), metropolitan area networks (MANs), and wide area networks (WANs). The wireless network includes Bluetooth, Wi-Fi, and other networks that enable wireless communication.
[0038] The aforementioned terminal devices 106 and 104 may include, but are not limited to, at least one of the following: mobile phones (such as Android phones, iOS phones, etc.), laptops, tablets, PDAs, MIDs (Mobile Internet Devices), PADs, desktop computers, smart TVs, in-vehicle devices, etc. Clients may be installed on the aforementioned terminal devices, such as instant messaging application clients, audio / video application clients, game application clients, etc. The aforementioned terminal devices are also equipped with a display, a processor, and a memory. The processor can be used to process the data acquired by the terminal device, for example, to compress and transmit the acquired application environment description file. The application environment description file includes a system description file describing the first system environment of the terminal device 104, and a status description file describing the running state of the first application running in the aforementioned first system environment. The memory is used to store the compressed application environment description file. It is understood that the terminal device 104 is a terminal that has encountered an application failure. After the application environment description file is compressed in the terminal device 104, the terminal device 104 can send the application environment description file to the server 102 through the network 110. The server 102 receives the application environment description file and stores it.
[0039] The aforementioned terminal device 106 is a terminal for fault debugging control. Terminal device 106 sends debugging commands to server 108 via network 110 to run a virtual machine for debugging on server 108, and controls fault debugging to be performed on server 108 through the debugging commands. During the fault debugging process on server 108, server 108 receives an application environment description file sent by server 102 to restore the fault application environment of terminal device 104 on server 108, and performs fault debugging based on the restored fault application environment. It is understood that server 102 and server 108 can be a single server, a server cluster consisting of multiple servers, or a cloud server. The aforementioned server includes a database and a processing engine.
[0040] The specific steps are as follows: As in step S1, terminal device 104 sends an application environment description file to server 102 via network 110 to store the application environment description file of terminal device 104 in server 102. Then, as in step S2, terminal device 106 sends a debugging command to server 108 via network 110 to control the debugging operation in server 108 as follows: S3, server 102 sends an application environment description file to server 108, that is, server 108 obtains the application environment description file sent by the target terminal device where the first application is located; and generates a second system environment in the current virtual machine according to the application environment description file, and runs the second application in the second system environment; it can be understood that the difference between the second system environment and the first system environment is less than a first threshold, and the second application and the first application are applications in the same running state. The faults appearing in the second application are then located. Then, as in steps S4 and S5, server 108 returns the debugging results to terminal device 106 via network 110; server 108 returns the fault finding results to terminal device 104 via server 102 and network 110.
[0041] According to one aspect of the present invention, the terminal device may further include multiple terminal devices, all of which run the same application, and the versions of the applications are the same. After the server 102 receives the application environment description files returned by each terminal device through the network 110, it can determine various faults occurring in the same version of the application in the multiple terminals, and update the application version based on the determined application faults, so as to overcome the faults occurring in the application in the multiple terminals through the version update.
[0042] It should be noted that in this embodiment, the above-mentioned debugging operation is performed remotely on the server 108 by sending debugging instructions from the terminal device 106 to the server 108. Specifically, this can be achieved by running a virtual machine on the server 108 to simulate a real system environment. In another optional approach, the terminal device 106 is a terminal device with a certain computing power, and the operations that occur on the server 108 can be directly implemented on the terminal device 106. Specifically, a virtual machine for simulating the Android system environment can be run on the terminal device 106, and by receiving the application environment description file sent by the server 102, the application environment of the terminal device 104 can be restored in the virtual machine running on the terminal device 106 for fault finding operations.
[0043] In this embodiment of the invention, an application environment description file sent by the target terminal device where the first application is located is obtained; a second system environment is generated in the current virtual machine according to the application environment description file, and the second application is run in the second system environment, wherein the environmental difference between the second system environment and the first system environment is less than a first threshold, and the second application and the first application are applications in the same running state; faults appearing in the second application are found, thereby realistically recreating the user's problem scenario on the test end according to the application environment description file fed back by the user, and fault finding is performed in the recreated problem scenario, thereby avoiding the fault finding operation while maintaining a connection with the user end, thus solving the technical problem of low finding efficiency of existing fault finding methods.
[0044] The above is merely an example, and no limitation is made in this embodiment.
[0045] As an optional implementation method, such as Figure 2 As shown, the troubleshooting method for the above application includes the following steps:
[0046] S202, obtain the application environment description file sent by the target terminal device where the first application is located, wherein the application environment description file includes: a system description file for describing the first system environment of the target terminal device, and a status description file for describing the running status of the first application;
[0047] It is understood that in this embodiment, the application environment description file may include two parts: a system description file describing the first system environment of the target terminal device, and a status description file describing the running state of the first application. It should be noted that in this application, the system environment refers to the operating system environment (excluding system applications) where no applications are running; the environment in which relevant applications (such as a specified version of an APP) are running within the system environment is the application environment.
[0048] It should be noted that, in this embodiment, the system description file can be used to describe information including, but not limited to, the type of operating system, system running status, and system running parameters of the target terminal. For example, the system type information contained in the system description file can determine the type and version of the operating system running on the target terminal, such as Windows, macOS, Android, iOS, Linux, etc., and Windows 11, Windows 10, Windows 7, etc. Once the system type and version information of the target terminal is obtained, the environment in the virtual machine can be initialized according to the system type and version of the target terminal. For example, if the operating system of the target terminal is determined to be Android, the test environment initialization operation is performed in the ART virtual machine corresponding to the Android system. It should be noted that the ART virtual machine is a system simulation software that can run Android mobile phone software.
[0049] It is understood that the system description file can also be used to describe the operating status and parameters of the target terminal's operating system, such as the current CPU utilization, current RAM utilization, current physical memory utilization, current number of system processes, and current network status. In this embodiment, the functional description of the system description file is merely illustrative and does not limit the specific functions of the system description file.
[0050] Correspondingly, the aforementioned state description file is used to describe the running state of the first application running in the first system environment. It is understood that the running state of the first application may include, but is not limited to, the system memory status occupied by the current first application, such as the size of the occupied running memory and the size of the occupied physical memory; it may also include the stacking state of the page stack of the current first application, such as the number of application pages opened by the current first application, the content of the application pages, and the stacking relationship between application pages; it may also include the memory data values corresponding to the process of the current first application and the data files stored in the physical memory corresponding to the current first application and the topological relationship between the stored data files. In this embodiment, the functional description of the aforementioned state description file is only illustrative and does not limit the specific function of the state description file.
[0051] S204, Generate a second system environment in the current virtual machine according to the application environment description file, and run the second application in the second system environment, wherein the difference between the second system environment and the first system environment is less than a first threshold, and the second application and the first application are applications in the same running state;
[0052] It is understandable that after obtaining the application environment description file sent by the target terminal device where the first application is located on the test end, a second system environment corresponding to the first system environment can be run in the ART virtual machine according to the system description file included in the application environment description file, and a second application corresponding to the first application can be run in the second system environment. Furthermore, the status description file of the first application is loaded in the second system environment, thereby restoring the application environment in the target terminal in the ART virtual machine, and then troubleshooting is performed based on the second application running in the second system environment with the same running status as the first application.
[0053] More specifically, the second system environment corresponding to the first system environment can be a system environment with the same system type and version as the first system environment, and with the same parameters such as system CPU utilization, RAM utilization, and physical memory utilization. For example, assuming the first system environment is an Android system, and its CPU utilization, RAM utilization, and physical memory utilization are 30%, 70%, and 10% respectively, then in a customized ART virtual machine (a Linux system, derived from the Android system), the CPU utilization, RAM utilization, and physical memory utilization of the ART virtual machine can be adjusted to be the same as the first system environment. It is understood that the above-mentioned first and second system environments can be completely restored through debugging, or partially restored as needed; no limit is placed on the degree of system environment restoration here.
[0054] The method for determining the aforementioned environmental similarity can be as follows: First, identify multiple items to characterize environmental features, such as system type, version, network status, CPU utilization, RAM utilization, and physical memory utilization. Assign a weight to each item, and then score the first and second system environments based on their matching degree in these items. Finally, determine the environmental similarity value based on the scores and corresponding weights of each item, and determine that subsequent restoration and testing operations will be performed in the second environment where the environmental similarity is greater than a target threshold. This method for determining environmental similarity is merely an example, and no specific limitations are imposed on the method used.
[0055] Simultaneously, the second application running in the second system environment must be the same type and version as the first application. For example, if the first application is an instant messaging software called "WeChat" with version 3.0, then version 3.0 of "WeChat" must also be running in the aforementioned second system environment to identify faults within the same version of the application. Furthermore, the running status of the second application must be identical; for example, the number of pages opened, their content, stacking relationships, the process memory parameter values, and the files in the application's storage path must all be the same. It is understood that the parameter values indicating the running status mentioned above are merely examples, and no specific restrictions are imposed on the parameter values.
[0056] S206, Locate the fault that occurred in the second application.
[0057] It is understood that by obtaining the application environment description file sent by the target terminal device where the first application resides, a second application with the same running state as the first application can be run in a second system environment corresponding to the first system environment. In other words, by reconstructing the user's fault scenario, the fault occurring in the first application can be accurately determined. In this embodiment, the fault finding method is not limited.
[0058] Specifically, the above debugging method can also take two forms. For example... Figure 3 As shown, in the first approach, this embodiment can be a debugging method for a single user, that is, to restore the application environment of the first application of a single user based on the environment description file related to the first application run by the single user, thereby determining the fault that occurs in the usage scenario of the single user, and directly feeding back the fault handling result.
[0059] like Figure 4 As shown, in the second approach, this embodiment can be a debugging method for the same version of an application. That is, when multiple terminals provide environment description files for the same version of a first application, these files are integrated to identify the problems occurring in the same version of the application, and a version update is used to resolve the faults in the same version of the application.
[0060] It is understood that the above embodiments are merely illustrative examples and do not constitute a limitation on the solutions in this application.
[0061] The following combination Figure 5 , Figure 6 The above method will be illustrated with a specific embodiment:
[0062] like Figure 5As shown, an optional interactive system is illustrated, in which the interactive components include: a user terminal, a cloud storage server, a customized ART virtual machine running on a first server, and a debugging PC. The user terminal is the terminal where the application malfunctions; the cloud storage server is a cloud-based Cos, a distributed storage system without directory hierarchy or data format restrictions, capable of holding massive amounts of data and supporting HTTP / HTTPS access; the customized ART virtual machine can run on the first server; and the debugging PC can remotely connect to the first server, open the customized ART virtual machine on the first server, and control it for debugging operations, allowing direct application debugging on the first server. The specific method is as follows:
[0063] S502, a compressed file containing information such as page stack, memory, and files uploaded by the user terminal;
[0064] Specifically, users can, for example Figure 6 The interface shown displays both a textual description of the software problem and a problem file. It can be understood that the problem file in this embodiment corresponds to the application environment description file mentioned above.
[0065] S504, Open the App and load abnormal user environment resources;
[0066] Understandably, after the user uploads the problem file to the cloud storage server, the developer remotely connects to the first server from the debugging PC, opens the ART virtual machine on the first server, controls the access to the problem file in the cloud storage server, and opens the App with the same version as the user's terminal App based on the problem file.
[0067] S506 loads user-related page stack, memory, and other information, and overwrites the current application environment;
[0068] Understandably, after initializing the virtual machine system environment and opening an application with the same version as the user's application, the initial application environment is obtained. Next, to recreate the problem scenario on the user's terminal, relevant files need to be retrieved from the cloud storage server, and user-related page stacks, memory information, etc., need to be loaded and overwritten with the current initial application environment. This restores the user's terminal's application environment and allows for accurate identification of the application's fault.
[0069] S508, environment restoration complete, starting troubleshooting.
[0070] It is understood that in this embodiment, the debugging operation is performed on the debugging PC. The debugging PC issues debugging instructions to the server running the customized ART virtual machine, thereby enabling the debugging operation to be performed on the server.
[0071] In this embodiment of the invention, an application environment description file sent by the target terminal device where the first application is located is obtained; a second system environment is generated in the current virtual machine according to the application environment description file, and the second application is run in the second system environment, wherein the environmental difference between the second system environment and the first system environment is less than a first threshold, and the second application and the first application are applications in the same running state; faults appearing in the second application are found, thereby realistically recreating the user's problem scenario on the test end according to the application environment description file fed back by the user, and fault finding is performed in the recreated problem scenario, thereby avoiding the fault finding operation while maintaining a connection with the user end, thus solving the technical problem of low finding efficiency of existing fault finding methods.
[0072] As an optional implementation, generating a second system environment within the current virtual machine based on the application environment description file, and running the second application within the second system environment includes:
[0073] S1, adjust the system environment parameters of the current virtual machine according to the system description file in the application environment description file to generate a second system environment;
[0074] S2, based on the status description file in the application environment description file, start the second application that matches the version of the first application, and adjust the running status of the second application to be the same as that of the first application.
[0075] It should be noted that, in this embodiment, the method of adjusting the system environment parameters of the current virtual machine according to the system description file in the application environment description file to generate the second system environment not only requires determining the system version and corresponding operating parameters of the second system environment based on the system version and operating parameters of the first system environment, but also requires performing corresponding configuration operations on the corresponding system environment.
[0076] Specifically, assuming the user terminal is running Android, the corresponding system configuration operations can be performed within the corresponding ART virtual machine. It should be noted that the ART virtual machine runs a Linux system, and a common Linux process memory layout is as follows: Figure 7 As shown. Although the memory layout in Android has been adjusted, a Heap area still exists. The ART virtual machine needs to overwrite the Heap area of the current process based on the variable object types and data saved in HProf (Heap Profile, memory snapshot) to restore the user memory environment.
[0077] Through the above embodiments of this application, the system environment parameters of the current virtual machine are adjusted according to the system description file in the application environment description file to generate a second system environment; a second application matching the version of the first application is started according to the state description file in the application environment description file, and the running state of the second application is adjusted to be the same as that of the first application, thereby restoring the application running state in the user terminal based on the initialized system environment, and then performing debugging operations on the second application based on the restored second system environment, so as to efficiently and accurately determine the application fault.
[0078] In an optional implementation, adjusting the running state of the second application to be the same as that of the first application includes:
[0079] S1, obtain page stack information from the state description file, wherein the page stack information is used to describe the display hierarchy of at least one page in the first application that is in the display state;
[0080] S2, display at least one page from the second application according to the page stack information.
[0081] Let's take the Android system as an example to illustrate the above method. In Android, Activity components are used to display pages to the user. When entering the next displayed page, that page is placed on top of the previous page, forming a stack structure. For example, suppose the pages are opened in a certain order: Page A → Page B → Page C → Page D. The overlapping relationship of the four pages is that Page A is at the bottom, Page B is above Page A, Page C is above Page B, and Page D is above Page C. That is, Page D is at the top of the page stack. Therefore, when closing a page, you need to close Page D, Page C, Page B, and Page A in that order.
[0082] In this embodiment, it is necessary to determine the page content and page stacking relationship of the first application in the target terminal based on the page stack information sent by the target terminal. Then, in the second system environment, when a second application with the same version as the first application is launched, the page stack with the same page content and page stacking relationship as the first application is restored. Specifically, the page stack can be reopened in a customized virtual machine using the startActivity program based on the page stack information uploaded by the user.
[0083] In one optional implementation of the above embodiments of this application, adjusting the running state of the second application to be the same as that of the first application includes: obtaining page stack information from a state description file, wherein the page stack information is used to describe the display hierarchy of at least one page in the first application that is in the display state; displaying at least one page in the second application according to the page stack information, thereby realizing the restoration of the page stack of the first application in the second system environment, thereby accurately knowing in what scenario the user encountered a fault and the display form of the faulty page, that is, accurately determining the specific page environment in the user's environment in which the fault occurred.
[0084] As an optional implementation, adjusting the running state of the second application to be the same as that of the first application includes:
[0085] S1, Obtain a memory snapshot from the status description file, wherein the memory snapshot is a data file that records the values of the process memory objects corresponding to the first application;
[0086] S2, adjust the process memory object value corresponding to the second application based on the memory snapshot.
[0087] It's important to note that a memory snapshot is also known as an HProf (Heap Profile) file. A memory snapshot of an Android device is a data file used to record the values of memory objects in the application process at that moment.
[0088] Once the loading description file is obtained, the included HProf file is parsed to export a mapping table of Class type, member variable, and attribute value. Then, starting from GCROOT, the entire memory is scanned, and the memory values are overwritten based on the variable type matching the above mapping table.
[0089] like Figure 8 As shown, by scanning the Heap memory area, matching the object types in user memory, and overwriting the objects in the Heap heap. For example, if an ActivityA object is found in the Heap area, the system checks if HProf contains both ActivityA and ActivityB objects. If they exist, the values in HProf are used to overwrite the variable values in the Heap area.
[0090] Through the above embodiments of this application, by obtaining a memory snapshot in a status description file, wherein the memory snapshot is a data file that records the process memory object value corresponding to the first application; adjusting the process memory object value corresponding to the second application according to the memory snapshot, thereby restoring the user memory environment, and accurately finding application faults based on the restored user environment.
[0091] As an optional implementation, adjusting the running state of the second application to be the same as that of the first application includes:
[0092] S1, obtain the data file corresponding to the first application and the storage topology of the data file in the first system environment from the status description file;
[0093] S2, saves the data file in the storage path corresponding to the storage topology within the current virtual machine.
[0094] Understandably, when an application with the same version as the user's terminal is opened in the ART virtual machine, the system will create a file path in the memory path corresponding to the application. Based on the created initial file path, the user's data file is moved to the corresponding directory location in the current virtual machine; if a duplicate file exists, the original file is overwritten.
[0095] For example, if / data / data / pkg / files / config.xml exists in the user path, then move it to / data / data / pkg / files / config.xml in the virtual machine.
[0096] Through the above embodiments of this application, by obtaining the data file corresponding to the first application and the storage topology relationship of the data file in the first system environment from the status description file, and saving the data file in the storage path corresponding to the storage topology relationship in the current virtual machine, the physical memory state corresponding to the user application can be accurately restored, and the location and cause of the fault can be accurately determined in the virtual machine based on the restored data file.
[0097] As an optional implementation, the above-mentioned fault detection in the second application includes:
[0098] S1, Obtain the control operation log sent by the target terminal device, wherein the control operation log is a sequence of control instructions received by the target terminal device during the execution of the target task;
[0099] S2, based on the control operation log, finds faults that occur in the second application.
[0100] It should be noted that the aforementioned control operation log can be used to indicate the sequence of control commands received by the target terminal during the execution of the target task, or it can be used to indicate the sequence of control operations performed by the target terminal in response to the control commands during the execution of the target task. No restrictions are placed on the specific content or format of the aforementioned control operation log.
[0101] Understandably, by combining the application environment description file sent by the target terminal with the aforementioned control operation logs, the user's fault scenario can be reconstructed more accurately.
[0102] The following description uses a specific implementation method as an example:
[0103] S1, receives fault feedback from the user terminal;
[0104] It should be noted that, in this embodiment, the user can be prompted to begin collecting the problem file via text. For example, prompts such as "Start collecting problem file" or "Please repeat the fault operation" can be used. This prompts the user to repeat the historical operations based on their experience with the fault, thereby reproducing the fault. During the user's repetition of the fault operation, the control operations performed during this process need to be recorded to form a control operation log. The control operation log can include the sequence of touch operations performed by the user, such as "Operation 1: Swipe right to return, operation position: A; Operation 2: Tap operation, operation position: B; Operation 3: Long press operation, operation position: C".
[0105] When the above data collection process is initiated, the application environment description file at the time of initiation is collected, and while recording the control operation log, the various change values of the application environment description file are also recorded.
[0106] Finally, the application environment description file at startup, the sequence of changes in the environment description file, the application environment description file at the time of fault reproduction, and the aforementioned control operation logs are packaged and uploaded to the cloud server.
[0107] S2 initializes the debugging environment in the virtual machine and opens the App with the same version as the user's terminal;
[0108] S3. Based on the application environment description file at the startup time fed back by the target terminal, the user fault scenario is reconstructed, and the fault occurrence process is reconstructed based on the change value sequence of the environment description file, the application environment description file at the fault reproduction time, and the above-mentioned control operation log.
[0109] S4, based on the process of fault reproduction, find the cause of the fault and debug it.
[0110] By using the above-described embodiments of this application, control operation logs sent by the target terminal device are obtained, and faults occurring in the second application are found based on the control operation logs. This allows for a more accurate reconstruction of the fault environment of the user terminal and an accurate reproduction of the fault occurrence process of the user terminal, thereby efficiently finding application faults and solving the technical problem of low search efficiency in existing fault finding methods.
[0111] As an optional implementation, after searching for faults in the second application, the method further includes:
[0112] S1, take the fault that appears in the second application as the target fault found in the first application in the target terminal device;
[0113] S2, obtain reference faults found from the first application running on each of at least one reference terminal device;
[0114] S3, based on the target fault and the reference fault, updates the version of the first application.
[0115] It should be noted that in scenarios where a user terminal is troubleshooting an application failure, such as... Figure 3 As shown, based on recreating the problem scenario of the application running on the user terminal in the virtual machine, the system can specifically identify the fault and its cause on the user terminal. After debugging and resolving the issue, the system can send feedback to the user terminal via the network. For example, if the fault is caused by the user's incorrect operation, the feedback would be "Your fault is caused by your incorrect operation; the correct operation should be...". If the fault is caused by system incompatibility, the feedback would be "Your fault is caused by system incompatibility; the following steps can resolve the fault...". If the fault is caused by a bug in the application itself, a patch file to fix the bug can be directly requested. No restrictions are placed on the specific feedback format here.
[0116] In this embodiment, in a scenario where application faults are found in multiple user terminals, such as Figure 4 As shown, given application environment description files from multiple identical application versions, the problem scenarios of these applications can be reconstructed sequentially to determine the cause of the failure. It's understandable that the reported failures from multiple applications may be the same or different. For multiple identical problems, the cause is determined by combining the application environment description files from multiple applications, and then targeted debugging and resolution are implemented. For multiple different problems, each problem is debugged and resolved individually.
[0117] Developers can use application environment description files based on feedback from multiple identical application versions to determine fault fixes for that version or develop an application with faults overcome. Then, by releasing a new version of the application simultaneously, the existing problems can be resolved through version updates on multiple user terminals.
[0118] By using the above-described embodiments described in this application, a fault occurring in the second application is used as a target fault found in the first application in the target terminal device; a reference fault is obtained from the first application running in at least one reference terminal device; and the first application is updated based on the target fault and the reference fault, thereby improving the efficiency of problem solving for the application by combining the problems occurring in multiple terminals and updating the application at the same time.
[0119] The following combination Figure 9 The following flowchart illustrates the complete process of the fault finding method for the application provided in this application:
[0120] It should be noted that in the specific embodiments of this application, data such as system description files and control operation logs are involved. When the above embodiments of this application are applied to specific products or technologies, the corresponding authorization or consent is required, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.
[0121] S902, the user opens the feedback page and clicks to submit feedback;
[0122] Specifically, in this embodiment, the user terminal runs on the Android system. When a user encounters an application malfunction, they can report the problem through the application's problem feedback function. The specific feedback interface can be as follows: Figure 6 As shown, users need to describe the problem they are encountering and upload a compressed version of the description file in the "Please upload problem file" field.
[0123] When the user clicks Figure 6 When the "+" control is used, current system resources, process memory, user files, and page stack can be collected, trimmed, compressed, and then uploaded to Cos. In this embodiment, the user terminal runs on Android. The specific implementation of the aforementioned feedback file can be as follows: the terminal obtains Activity stack information through the dumpsys command and obtains user memory information through Debug.dumpHpr ofData(). Then, after local trimming and filtering, the Activity stack, memory information, and files are GZIP compressed. After compression, the compressed file is uploaded to Tencent Cloud Storage Server (Cos) via the HTTP protocol.
[0124] S904, open the APP in the cloud virtual machine;
[0125] It should be noted that before performing this step, the cloud-based ART virtual machine needs to be configured to restore the user's problem environment within the virtual environment. Specifically, the configuration involves adding the ability for the ART virtual machine to overwrite the current process's memory data based on the user memory data stored in the HProf file, thereby restoring the user's environment.
[0126] It should be noted that common Linux system process memory layouts are as follows: Figure 7 As shown, although the memory layout in the Android system has been adjusted, the Heap area still exists. The virtual machine needs to overwrite the Heap area of the current process according to the variable object type and data stored in HPROF to restore the user memory environment.
[0127] After performing the appropriate configuration operations on the ART virtual machine Figure 5 As shown, the debugging PC sends commands to a remote, customized ART virtual machine to run a specified version of the app. It then locates the compressed file returned by the target terminal on the cloud storage server and decompresses it. Once the configured virtual machine environment and the corresponding app version are established, the application environment initialization is complete.
[0128] S906, restore the user page stack;
[0129] This step involves opening the corresponding application pages according to the page stack order provided in the feedback. Specifically, the debugging PC sends control commands, and based on the Activity stack information obtained from the decompression, reopens the page stack in the customized ART virtual machine using startActivity.
[0130] S908, overwrites process memory;
[0131] Specifically, the uploaded process memory is loaded, overwriting the process memory in the virtual machine, while the user terminal files are overwritten with the files in the corresponding directory of the virtual machine.
[0132] More specifically, the debugging PC sends control commands to parse the HProf file and export a mapping table of Class types, member variables, and attribute values; then, starting from GCROOT, it scans the entire memory, matches the variable types to the above mapping table, and overwrites the memory values. For example... Figure 8 As shown, by scanning the Heap memory area of the ART virtual machine, matching the object types in user memory, and overwriting the objects in the Heap heap. For example, if an ActivityA object is found in the Heap area, the system checks if HProf contains both ActivityA and ActivityB objects. If they exist, the values in HProf are used to overwrite the variable values in the Heap area.
[0133] At the same time, the user's data file is moved to the corresponding directory location in the current virtual machine. If a duplicate file exists, the original file is overwritten. For example, if the user's path contains ` / data / data / pkg / files / config.xml`, then it is moved to ` / data / data / pkg / files / config.xml` in the virtual machine.
[0134] S910, local debugging revealed the cause;
[0135] This step allows you to simulate the user environment by overlaying it on a remote environment, thus enabling you to analyze application faults remotely.
[0136] S912, issue fixed.
[0137] There are two ways to fix the problem. In a scenario where you're troubleshooting an application failure on a user's terminal, such as... Figure 3 As shown, based on recreating the problem scenario of the application running on the user terminal in the virtual machine, the system can specifically identify the fault and its cause on the user terminal. After debugging and resolving the issue, the system can send feedback to the user terminal via the network. For example, if the fault is caused by the user's incorrect operation, the feedback would be "Your fault is caused by your incorrect operation; the correct operation should be..."; if the fault is caused by system incompatibility, the feedback would be "Your fault is caused by system incompatibility; the following steps can resolve the fault..."; and if the fault is caused by a bug in the application itself, a patch file to fix the bug can be directly requested.
[0138] In scenarios where application faults are found across multiple user terminals, such as Figure 4 As shown, given compressed files from multiple applications of the same version, the problem scenarios of these applications can be reconstructed sequentially to determine the cause of the failure. It's understandable that the reported failures from multiple applications may be the same or different. For multiple identical problems, the cause is determined by comprehensively analyzing the application environment description files from multiple applications, and then targeted debugging and resolution are implemented. For multiple different problems, each problem is debugged and resolved individually.
[0139] Developers can use compressed issue files from multiple identical application versions to determine bug fixes for that version or develop an application with the bugs resolved. Then, a new version of the application is released simultaneously, allowing version updates on multiple user devices to resolve the previous issues.
[0140] In this embodiment of the invention, an application environment description file sent by the target terminal device where the first application is located is obtained; a second system environment is generated in the current virtual machine according to the application environment description file, and the second application is run in the second system environment, wherein the environmental difference between the second system environment and the first system environment is less than a first threshold, and the second application and the first application are applications in the same running state; faults appearing in the second application are found, thereby realistically recreating the user's problem scenario on the test end according to the application environment description file fed back by the user, and fault finding is performed in the recreated problem scenario, thereby avoiding the fault finding operation while maintaining a connection with the user end, thus solving the technical problem of low finding efficiency of existing fault finding methods.
[0141] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the present invention is not limited to the described order of actions, because according to the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to the present invention.
[0142] According to another aspect of the present invention, a fault-finding apparatus for an application implementing the fault-finding method of the above-described application is also provided. For example... Figure 10 As shown, the device includes:
[0143] The acquisition unit 1002 is used to acquire an application environment description file sent by the target terminal device where the first application is located. The application environment description file includes: a system description file for describing the first system environment of the target terminal device, and a status description file for describing the running status of the first application.
[0144] The generation unit 1004 is used to generate a second system environment in the current virtual machine according to the application environment description file, and run a second application in the second system environment, wherein the difference between the second system environment and the first system environment is less than a first threshold, and the second application and the first application are applications in the same running state.
[0145] The lookup unit 1006 is used to look for faults that occur in the second application.
[0146] Optionally, in this embodiment, the implementation of each of the above-mentioned unit modules can be referred to the above-mentioned method embodiments, which will not be repeated here.
[0147] According to another aspect of the present invention, an electronic device for implementing the fault finding method of the above-described application is also provided, the electronic device being... Figure 11 The terminal device or server shown. This embodiment uses this electronic device as an example for illustration. Figure 11 As shown, the electronic device includes a memory 1102 and a processor 1104. The memory 1102 stores a computer program, and the processor 1104 is configured to execute the steps of any of the above method embodiments via the computer program.
[0148] Optionally, in this embodiment, the aforementioned electronic device may be located in at least one of a plurality of network devices in a computer network.
[0149] Optionally, in this embodiment, the processor can be configured to perform the following steps via a computer program:
[0150] S1, obtain the application environment description file sent by the target terminal device where the first application is located, wherein the application environment description file includes: a system description file for describing the first system environment of the target terminal device, and a status description file for describing the running status of the first application;
[0151] S2, Generate a second system environment in the current virtual machine according to the application environment description file, and run the second application in the second system environment, wherein the difference between the second system environment and the first system environment is less than a first threshold, and the second application and the first application are applications in the same running state;
[0152] S3, locate the fault that occurred in the second application.
[0153] Alternatively, as those skilled in the art will understand, Figure 11 The structure shown is for illustrative purposes only. Electronic devices can also be in-vehicle terminals, smartphones (such as Android phones, iOS phones, etc.), tablets, handheld computers, mobile internet devices (MIDs), PADs, and other terminal devices. Figure 11 This does not limit the structure of the aforementioned electronic devices. For example, the electronic device may also include components that are more... Figure 11 The more or fewer components shown (such as network interfaces, etc.), or having the same Figure 11 The different configurations shown.
[0154] The memory 1102 can be used to store software programs and modules, such as the program instructions / modules corresponding to the application troubleshooting method and apparatus in this embodiment of the invention. The processor 1104 executes various functional applications and data processing by running the software programs and modules stored in the memory 1102, thereby realizing the aforementioned application troubleshooting method. The memory 1102 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 1102 may further include memory remotely located relative to the processor 1104, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof. Specifically, the memory 1102 may be used, but is not limited to, to store information such as application troubleshooting information. As an example, such as... Figure 11 As shown, the memory 1102 may include, but is not limited to, the acquisition unit 1002, generation unit 1004, and search unit 1006 of the fault finding device for the application described above. Furthermore, it may include, but is not limited to, other module units of the fault finding device for the application described above, which will not be elaborated upon in this example.
[0155] Optionally, the transmission device 1106 described above is used to receive or send data via a network. Specific examples of the network described above may include wired networks and wireless networks. In one example, the transmission device 1106 includes a Network Interface Controller (NIC), which can be connected to other network devices and a router via a network cable to communicate with the Internet or a local area network. In another example, the transmission device 1106 is a radio frequency (RF) module, used for wireless communication with the Internet.
[0156] In addition, the aforementioned electronic device also includes: a display 1108 for displaying a fault finding interface; and a connection bus 1110 for connecting various module components in the aforementioned electronic device.
[0157] In other embodiments, the aforementioned terminal device or server can be a node in a distributed system, wherein the distributed system can be a blockchain system, which is a distributed system formed by connecting multiple nodes through network communication. The nodes can form a peer-to-peer (P2P) network, and any form of computing device, such as a server, terminal, or other electronic device, can become a node in the blockchain system by joining this peer-to-peer network.
[0158] According to one aspect of this application, a computer program product is provided, comprising a computer program / instructions containing program code for performing the methods shown in the flowchart. In such embodiments, the computer program can be downloaded and installed from a network via a communication component, and / or installed from a removable medium. When the computer program is executed by a central processing unit, it performs various functions provided in embodiments of this application.
[0159] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.
[0160] According to one aspect of this application, a computer-readable storage medium is provided, wherein a processor of a computer device reads computer instructions from the computer-readable storage medium, and executes the computer instructions, causing the computer device to perform the fault-finding method of the aforementioned application.
[0161] Optionally, in this embodiment, the computer-readable storage medium may be configured to store a computer program for performing the following steps:
[0162] S1, obtain the application environment description file sent by the target terminal device where the first application is located, wherein the application environment description file includes: a system description file for describing the first system environment of the target terminal device, and a status description file for describing the running status of the first application;
[0163] S2, Generate a second system environment in the current virtual machine according to the application environment description file, and run the second application in the second system environment, wherein the difference between the second system environment and the first system environment is less than a first threshold, and the second application and the first application are applications in the same running state;
[0164] S3, locate the fault that occurred in the second application.
[0165] Optionally, in this embodiment, those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.
[0166] If the integrated units in the above embodiments are implemented as software functional units and sold or used as independent products, they can be stored in the aforementioned computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause one or more computer devices (which may be personal computers, servers, or network devices, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention.
[0167] In the above embodiments of the present invention, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.
[0168] In the several embodiments provided in this application, it should be understood that the disclosed client can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between units or modules, and may be electrical or other forms.
[0169] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0170] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.
[0171] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.
Claims
1. A method for troubleshooting an application, characterized in that, include: Obtain the application environment description file sent by the target terminal device where the first application is located; Based on the system description file in the application environment description file used to describe the first system environment of the target terminal device, a second system environment is generated in the current virtual machine, wherein the environment similarity between the second system environment and the first system environment is greater than a first threshold. Identify a second application process in the second system environment that matches the first application process in the first application, wherein the second application process belongs to the second application in the second system environment; The first parameter value, which matches the first application process as indicated by the state description file in the application environment description file, is used as the second parameter value to match the second application process. The second application process that matches the second application process is then run so that the second application and the first application are in the same running state. In response to a debugging instruction, perform debugging operations on the second application within the current virtual machine; The fault that occurred in the second application was determined based on the debugging results.
2. The method according to claim 1, characterized in that, Generating a second system environment within the current virtual machine based on the application environment description file, and running a second application in the second system environment includes: Adjust the system environment parameters of the current virtual machine according to the system description file in the application environment description file to generate the second system environment; The second application, matching the version of the first application, is launched according to the status description file in the application environment description file, and the running status of the second application is adjusted to be the same as that of the first application.
3. The method according to claim 2, characterized in that, Adjusting the running state of the second application to be the same as that of the first application includes: Obtain page stack information from the state description file, wherein the page stack information is used to describe the display hierarchy of at least one page in the first application that is in the display state; At least one page from the second application is displayed according to the page stack information.
4. The method according to claim 2, characterized in that, Adjusting the running state of the second application to be the same as that of the first application includes: Obtain a memory snapshot from the status description file, wherein the memory snapshot is a data file that records the process memory object values corresponding to the first application; Adjust the process memory object value corresponding to the second application based on the memory snapshot.
5. The method according to claim 2, characterized in that, Adjusting the running state of the second application to be the same as that of the first application includes: Obtain the data file corresponding to the first application from the status description file, and the storage topology of the data file in the first system environment; The data file is saved in the storage path corresponding to the storage topology within the current virtual machine.
6. The method according to any one of claims 1 to 5, characterized in that, The troubleshooting process in the second application includes: Obtain the control operation log sent by the target terminal device, wherein the control operation log is a sequence of control instructions received by the target terminal device during the execution of the target task; The faults that occurred in the second application were located based on the control operation log.
7. The method according to any one of claims 1 to 5, characterized in that, After identifying the faults in the second application, the process also includes: The fault that occurs in the second application is taken as the target fault found from the first application in the target terminal device; Retrieve reference faults identified from a first application running on at least one reference terminal device; Based on the target fault and the reference fault, the first application is updated.
8. A fault-finding device for an application, characterized in that, include: The acquisition unit is used to acquire the application environment description file sent by the target terminal device where the first application is located; Based on the system description file in the application environment description file used to describe the first system environment of the target terminal device, a second system environment is generated in the current virtual machine, wherein the environment similarity between the second system environment and the first system environment is greater than a first threshold. The generation unit is configured to determine a second application process in the second system environment that matches a first application process in the first application, wherein the second application process belongs to a second application in the second system environment; take the first parameter value indicated by the state description file in the application environment description file that matches the first application process as the second parameter value that matches the second application process, and run the second application that matches the second application process so that the second application and the first application are in the same running state; The lookup unit is configured to perform a debugging operation on the second application within the current virtual machine in response to a debugging instruction; and to determine the fault that occurs in the second application based on the debugging results.
9. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored program, wherein the program, when executed, performs the method described in any one of claims 1 to 7.
10. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to execute the method described in any one of claims 1 to 7 through the computer program.
Citation Information
Patent Citations
Method and device for performing remote problem positioning on application program
CN104331372A
Dichotomy online simulation and debugging method based on virtual machine snapshots
CN107844420A