Fault positioning method, electronic equipment and readable storage medium

Abstract

The invention relates to the technical field of computers, provides a fault positioning method, electronic equipment and a readable storage medium, and can generate fault information carrying a fault scene identification code uniquely corresponding to a fault scene after the electronic equipment has a performance fault so as to position a performance problem in the fault scene. The method comprises the steps that in response to a system fault occurring in the process that a user operates the electronic equipment, target fault information is generated, the target fault information comprises a fault scene identification code, and the fault scene identification code is used for identifying a fault scene; and the target fault information is uploaded, so that fault positioning can be carried out according to the multiple types of logs corresponding to the fault scene identified by the fault scene identification code in the target fault scene.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of computer technology, and in particular to a fault location method, an electronic device, and a readable storage medium. Background Art

[0002] With the development of terminal technology, electronic devices, such as smart phones, smart watches and other smart devices, have become indispensable daily necessities in people's lives. However, users may encounter performance problems such as freeze, jitter or crash when using electronic devices.

[0003] At present, when electronic devices have performance problems (or performance failures / failures), it is difficult to find the root cause of the problem due to the lack of fault location problem discovery means and problem location means, and thus it is impossible to quickly locate the performance problem, resulting in the performance problems that occur during user use cannot be well resolved, affecting the user experience. Summary of the invention

[0004] The embodiments of the present application provide a fault location method, an electronic device and a readable storage medium, which are intended to generate fault information carrying an identification code uniquely corresponding to a fault scenario after a performance failure occurs in the electronic device, and then identify the fault scenario based on the identification code to locate the performance problem in the fault scenario.

[0005] To achieve the above objectives, the embodiments of the present application adopt the following technical solutions:

[0006] In a first aspect, a fault location method is provided, the method comprising: in response to a system failure occurring during a user operating an electronic device, generating target fault information, the target fault information comprising a fault scenario identification code, the fault scenario identification code being used to identify the fault scenario; uploading the target fault information so as to locate the fault according to multiple types of logs corresponding to the fault scenarios identified by the fault scenario identification codes in the target fault scenarios.

[0007] As can be seen from the above, in the event of a system failure in an electronic device, the target fault information generated by this application may include a fault scenario identification code. Since the fault scenario identification codes corresponding to different system status information are different, the target fault information carries an identification code that can uniquely correspond to the fault scenario. Furthermore, this application will upload the target fault information, which can help developers locate performance problems. For example, developers can locate faults based on multiple types of logs corresponding to the fault scenarios identified by the fault scenario identification codes in the target fault scenarios.

[0008] In one possible implementation, generating target fault information includes: obtaining current system status information of an electronic device; wherein the current system status information is used to reflect the current system status of the electronic device during the user's operation of the electronic device; generating a fault scenario identification code based on the current system status information; adding the fault scenario identification code to initial fault information to obtain target fault information; wherein the initial fault information is used to reflect the type of current fault of the electronic device.

[0009] From the above, it can be seen that in the event of a system failure in an electronic device, the electronic device will not only generate initial fault information, but also obtain current system status information. Usually, the initial fault information contains limited information. Developers can only understand the specific type of the current system fault through the initial fault information, and it is difficult to locate the specific scenario where the fault occurs. The current system status information can reflect the user operations that the system is currently responding to, which helps developers understand the specific scenario of the system failure. Furthermore, the present application generates a fault scenario identification code based on the current system status information, and adds the fault scenario identification code to the initial fault information to obtain the target fault information.

[0010] In one possible implementation, the electronic device includes a log system driver module, and the above method also includes: in response to a user operating the electronic device, writing system status information generated during the user operating the electronic device into the log system driver module in the form of a log file; the system status information is used to reflect the system status of the electronic device during the user operating the electronic device; obtaining the current system status information of the electronic device, including: reading the most recently written system status information in the log system driver module, and using the most recently written system status information as the current system status information.

[0011] As can be seen from the above, whenever the system status of an electronic device changes, corresponding system status information will be generated. This application stores these system status information by creating a log system driver module. Therefore, the electronic device can obtain the latest system status information from the log system driver module.

[0012] In one possible implementation, the electronic device includes multiple system service modules, and different system service modules are used to provide different functional services; a detection pile point is added to a target system service module among the multiple system service modules; the detection pile point is used to detect the change of the system state of the electronic device when the target system service module provides the functional service; in response to the user operating the electronic device, the system state information generated during the user operating the electronic device is written into the log system driver module, including: in response to the user operating the electronic device to implement the functional service provided by the target system service module, the target system service module obtains the system state information through the detection pile point detection; the target system service module writes the obtained system state information into the log system driver module.

[0013] As can be seen from the above, different system service modules record different types of system status. For the system status that the target scenario is concerned about, add stubs at the location where it changes, and send notifications to the outside when the status changes (such as writing system status information to the log system driver module).

[0014] In a possible implementation, the target system service module includes at least one of a view system, an Activity manager, and an input library.

[0015] From the above, we can see that developers can select the target system service module to which detection points need to be added based on the system status that the target scenario is concerned about. For example, if you need to pay attention to the system status corresponding to the screen image when the user uses the APP, you can use the view system and the Activity manager as the target system service module to which detection points need to be added. If you need to pay attention to the system status corresponding to the pop-up window when the user uses the APP, you can use the window manager as the target system service module to which detection points need to be added.

[0016] In a possible implementation, a performance fault detection service module and a log package upload service module are deployed in the electronic device to generate target fault information, including: parsing the log file in the log system driver module through the performance fault detection service module to obtain initial fault information and current system status information, and generating target fault information based on the initial fault information and the current system status information; uploading the target fault information includes: saving the target fault information to the log package upload service module; uploading the target fault information through the log package upload service module.

[0017] From the above, it can be seen that through the log packaging and uploading service module, the target fault information with the fault scenario identification code generated by the performance fault detection service module can be successfully uploaded to the server, so that developers can promptly understand the fault scenario identification code and fault type of the system fault.

[0018] In a possible implementation, the fault scenario identification codes generated according to the same system status information under different software versions are the same; the different software versions include a commercial software version and a Beta software version of the same operating system.

[0019] As can be seen from the above, under normal circumstances, the fault information generated in the Beta version is more comprehensive. Setting the same encoding rules as the Beta version can ensure that when the same fault scenario as the Beta version occurs, the generated fault scenario identification code is also consistent with the Beta version. In this way, developers can obtain more comprehensive fault information from the Beta version based on the fault scenario identification code.

[0020] In a possible implementation, the fault scenario corresponds to at least one of the following types of logs: operating system log androidlog, kernel log kernel log, system trace log systrace log, simple performance log simpleperf log; the log corresponding to the fault scenario is obtained during the Beta software version testing.

[0021] In a possible implementation, the method further includes: obtaining target fault information generated at different time points to obtain multiple target fault information; clustering the multiple target fault information according to the fault scenario identification codes included in the multiple target fault information to obtain at least one clustering result; the fault scenario identification codes corresponding to the target fault information in a clustering result are the same; obtaining target clustering results in which the number of target fault information is greater than or equal to a preset number, and determining the fault scenario identified by the fault scenario identification code corresponding to the target clustering result as a high-frequency fault scenario.

[0022] As can be seen from the above, the electronic device can cluster multiple target fault information according to the fault scenario identification code, and can group the same fault scenario identification code together to count the number of the same fault scenario identification code. If the number is large, the electronic device can determine the fault scenario corresponding to this fault scenario identification code as a high-frequency fault scenario, and report the high-frequency fault scenario to the cloud server so that developers can focus on analyzing these scenarios.

[0023] In a second aspect, a fault location device is provided, comprising: a functional unit for executing the fault location method of the first aspect; wherein the actions performed by the functional unit are implemented by hardware or by hardware executing corresponding software implementations.

[0024] In a third aspect, the present application provides an electronic device, including a memory and a processor, wherein the memory is used to store a computer program, and the processor is used to call the computer program to implement the fault location method in the first aspect.

[0025] In a fourth aspect, the present application provides a computer-readable storage medium, comprising computer program instructions, which, when executed by a processor in an electronic device, implement the fault location method of the first aspect.

[0026] In a fifth aspect, the present application provides a computer program product, which, when executed on a computer, enables the computer to execute the fault location method described in the first aspect. The computer may be the electronic device described above.

[0027] It can be understood that the beneficial effects that can be achieved by the second to fifth aspects mentioned above can refer to the beneficial effects of the fault location method described in any manner in the first aspect, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0029] Figure 1 A schematic diagram of the structure of a mobile phone provided in an embodiment of the present application;

[0030] Figure 2 A schematic diagram of an Android operating system architecture provided in an embodiment of the present application;

[0031] Figure 3 A schematic diagram of a fault location method provided in an embodiment of the present application Figure 1 ;

[0032] Figure 4 A schematic diagram of a fault location method provided in an embodiment of the present application Figure 2 ;

[0033] Figure 5 A schematic diagram of a fault location method provided in an embodiment of the present application Figure 3 ;

[0034] Figure 6 A schematic diagram of the composition of a fault locating device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0035] The technical scheme of the embodiment of the present application will be clearly and completely described below in conjunction with the drawings in the embodiment of the present application. Among them, in the description of the embodiment of the present application, the terms used in the following embodiments are only for the purpose of describing a specific embodiment, and are not intended to limit the present application. In addition, in order to facilitate the clear description of the technical scheme of the embodiment of the present application, in the embodiment of the present application, the words "first", "second" and the like are used to distinguish the same items or similar items with substantially the same functions and effects. It can be understood by those skilled in the art that the words "first", "second" and the like do not limit the quantity and execution order, and the words "first", "second" and the like do not limit necessarily different. And, in the description of the embodiment of the present application, unless otherwise specified, the meaning of "multiple" means two or more.

[0036] Before introducing the method provided in the embodiments of the present application in detail, the nouns or terms involved in the embodiments of the present application are first explained.

[0037] Operating System (OS): is a set of programs that manage and control computer operations, apply and run hardware and software resources, and provide users with convenient computer use. Optionally, the operating system can be divided into desktop operating system, mobile operating system, server operating system, embedded operating system, etc. according to the environment in which the operating system runs. Optionally, the operating system can be divided into Android operating system, Windows operating system, Linux operating system, etc. according to the version type of the operating system.

[0038] System failure: refers to the state in which the operating system cannot perform the specified functions. For example, during the operation of the computer, due to some reason, the system stops running, so that the computer cannot normally execute the user's operating instructions.

[0039] System testing: It is a test performed on a complete operating system to evaluate whether the operating system meets its specified requirements.

[0040] System log: used to record events that occur in the operating system. Optionally, the system log can be divided into: operating system log, kernel log, application log, etc. according to the content recorded in the system log. The operating system log can include Android log, Linux log, etc.

[0041] Software version cycle: The software version cycle refers to the development and release process of computer software. For example, computer software can develop from a quasi-preview version (Pre-alpha) to a preview version (Alpha), a test version (Beta), a final test version (Released candidate) to a finished version (Gold). A quasi-preview version may refer to a version released before an Alpha or Beta version. Compared to an Alpha or Beta version, a Pre-alpha version is an incomplete version. The preview version represents the earliest internal test version, which is generally not released to the outside world. It has many bugs and incomplete functions. It is usually used by testers. The test version refers to the version in the public beta stage, that is, the test version open to all users. The final test version refers to a candidate version that has been modified to become officially released. The finished version refers to the officially released version. It should be understood that the naming and division of each version in this application is for exemplary purposes. Optionally, other versions can be divided or the existing versions can be named with other names without limitation.

[0042] When the computer software is in a test version (such as a Beta version), the developer can install the test version of the computer software on a test machine or integrate it into a test system to perform system testing on the test version. During the system testing process, if a performance problem occurs, the system will usually report performance fault management information to remind users or operation and maintenance personnel that the system has a fault. In addition, the fault management information will also be accompanied by various system logs, such as Android log, kernel log, systrace, simpleperf, etc. After receiving the performance fault management information reported by the system, the operation and maintenance personnel can use the attached system logs to locate the performance problem.

[0043] When the computer software is in a formal version such as the Gold version, the computer software can be installed in commercial electronic devices for users to use. For example, with the rapid development of terminal technology, the popularity of electronic devices such as mobile phones and tablets is increasing, and the functions of these electronic devices are becoming more and more powerful. The formal version of computer software can be installed in these electronic devices to bring users more convenient experience. However, in the process of using these electronic devices, users will inevitably encounter some performance problems, such as freezes, jitters, or flashbacks. At this time, considering the performance overhead, server capacity, user security or privacy issues introduced by capturing system logs, it is usually restricted (or even prohibited) to capture various system logs. In this way, the operation and maintenance personnel can only know that a performance failure has occurred based on the performance fault management information, but cannot obtain more content related to the failure based on the performance fault management information, so fault location is more difficult.

[0044] In response to the above problems, the embodiments of the present application provide a fault location method, an electronic device and a readable storage medium, which are intended to generate fault information carrying a fault scenario identification code uniquely corresponding to the fault scenario after a performance failure occurs in the electronic device, so that operation and maintenance personnel can quickly locate the performance problem based on the fault scenario identification code.

[0045] The fault location method provided by the embodiment of the present application is described in detail below in conjunction with the accompanying drawings. It should be noted that the embodiments of the present application can refer to each other, for example, the same or similar steps, method embodiments, system embodiments and device embodiments can refer to each other without limitation.

[0046] The fault location method provided in the present application can be applied to electronic devices. In some embodiments, the electronic device can be a mobile phone, a tablet computer, a desktop, a laptop, a notebook computer, an ultra-mobile personal computer (UMPC), a handheld computer, a netbook, a personal digital assistant (PDA), a wearable electronic device, a smart watch, and the like. The present application does not specifically limit the specific form of the electronic device. Figure 1 As shown, the electronic device in the embodiment of the present application may be a mobile phone 100.

[0047] The embodiment is described in detail below by taking the mobile phone 100 as an example. It should be understood that the mobile phone 100 shown in the figure is only an example of an electronic device, and the mobile phone 100 may have more or fewer components than those shown in the figure, may combine two or more components, or may have a different component configuration. Figure 1 As shown, the mobile phone 100 may specifically include: a processor 101, a radio frequency (RF) circuit 102, a memory 103, a touch screen 104, a Bluetooth device 105, one or more sensors 106, a Wi-Fi device 107, a positioning device 108, an audio circuit 109, a peripheral interface 110, and a power system 111. These components can be connected through one or more communication buses or signal lines ( Figure 1 Communicate with the

[0048] The following is a detailed introduction to each component of the mobile phone 100:

[0049] The processor 101 is the control center of the mobile phone 100, and uses various interfaces and lines to connect various parts of the mobile phone 100, and executes various functions of the mobile phone 100 and processes data by running or executing applications (hereinafter referred to as Apps) stored in the memory 103, and calling data stored in the memory 103. In some embodiments, the processor 101 may include one or more processing units; for example, the processor 101 may be a Kirin series chip manufactured by Huawei Technologies Co., Ltd.

[0050] The radio frequency circuit 102 can be used for receiving and sending wireless signals during the process of sending and receiving information or making calls. In particular, the radio frequency circuit 102 can receive the downlink data of the base station and send it to the processor 101 for processing; in addition, the uplink data is sent to the base station. Generally, the radio frequency circuit includes but is not limited to an antenna, at least one amplifier, a transceiver, a coupler, a low noise amplifier, a duplexer, etc. In addition, the radio frequency circuit 102 can also communicate with other devices through wireless communication. The wireless communication can use any communication standard or protocol, including but not limited to the global system for mobile communications, general packet radio service, code division multiple access, wideband code division multiple access, long term evolution, email, short message service, etc.

[0051] The memory 103 is used to store an operating system, applications, and data. The processor 101 executes various functions and data processing of the mobile phone 100 by running the applications and data stored in the memory 103. The memory 103 mainly includes a program storage area and a data storage area. Among them, the program storage area can store an operating system and an application required for at least one function (such as a sound playback function, an image playback function, etc.). The data storage area can store data created when using the mobile phone 100 (such as audio data, a phone book, etc.). In addition, the memory 103 may include a high-speed random access memory, and may also include a non-volatile memory, such as a disk storage device, a flash memory device, or other volatile solid-state storage devices. The memory 103 can store various operating systems, for example, a Linux operating system, an Android operating system, etc.

[0052] The touch screen 104 may include a touch panel 104-1 and a display 104-2. The touch panel 104-1 may collect touch events on or near the user of the mobile phone 100 (for example, the user uses a finger, a stylus, or any other suitable object on or near the touch panel 104-1) and send the collected touch information to other devices such as the processor 101. Figure 1In the embodiment, the touch panel 104-1 and the display screen 104-2 are used as two independent components to realize the input and output functions of the mobile phone 100, but in some embodiments, the touch panel 104-1 and the display screen 104-2 can be integrated to realize the input and output functions of the mobile phone 100. It can be understood that the touch screen 104 is formed by stacking multiple layers of materials. In the embodiment of the present application, only the touch panel (layer) and the display screen (layer) are shown, and other layers are not recorded in the embodiment of the present application. In addition, in some other embodiments of the present application, the touch panel 104-1 can be covered on the display 104-2, and the size of the touch panel 104-1 is larger than the size of the display screen 104-2, so that the display screen 104-2 is completely covered under the touch panel 104-1, or the above-mentioned touch panel 104-1 can be configured on the front of the mobile phone 100 in the form of a full panel, that is, the user's touch on the front of the mobile phone 100 can be sensed by the mobile phone, so that the full touch experience on the front of the mobile phone can be achieved. In some other embodiments, the touch panel 104-1 is configured in the form of a full panel on the front of the mobile phone 100, and the display screen 104-2 can also be configured in the form of a full panel on the front of the mobile phone 100, so that a borderless structure can be achieved on the front of the mobile phone.

[0053] In the embodiment of the present application, the mobile phone 100 may also have a fingerprint recognition function. For example, a fingerprint recognition device 112 may be configured on the back of the mobile phone 100 (e.g., below the rear camera), or on the front of the mobile phone 100 (e.g., below the touch screen 104). For another example, a fingerprint acquisition device 112 may be configured in the touch screen 104 to implement the fingerprint recognition function, that is, the fingerprint acquisition device 112 may be integrated with the touch screen 104 to implement the fingerprint recognition function of the mobile phone 100. In this case, the fingerprint acquisition device 112 is configured in the touch screen 104, may be a part of the touch screen 104, or may be configured in the touch screen 104 in other ways. The main component of the fingerprint acquisition device 112 in the embodiment of the present application is a fingerprint sensor, which may use any type of sensing technology, including but not limited to optical, capacitive, piezoelectric or ultrasonic sensing technology.

[0054] In the embodiment of the present application, the mobile phone 100 may further include a Bluetooth device 105 for implementing data exchange between the mobile phone 100 and other short-range terminals (such as mobile phones, smart watches, etc.). The Bluetooth device in the embodiment of the present application may be an integrated circuit or a Bluetooth chip, etc.

[0055] The Wi-Fi device 107 is used to provide the mobile phone 100 with network access that complies with the Wi-Fi related standard protocols. The mobile phone 100 can access the Wi-Fi access point through the Wi-Fi device 107, thereby helping the user to send and receive emails, browse web pages, and access streaming media, etc. It provides the user with wireless broadband Internet access. In some other embodiments, the Wi-Fi device 107 can also be used as a Wi-Fi wireless access point to provide Wi-Fi network access for other terminals.

[0056] The mobile phone 100 may also include at least one sensor 106, such as a light sensor, a motion sensor, and other sensors. Specifically, the light sensor may include an ambient light sensor and a proximity sensor, wherein the ambient light sensor may adjust the brightness of the display of the touch screen 104 according to the brightness of the ambient light, and the proximity sensor may turn off the power of the display when the mobile phone 100 is moved to the ear. As a type of motion sensor, the accelerometer sensor can detect the magnitude of acceleration in each direction (generally three axes), and can detect the magnitude and direction of gravity when stationary, and can be used for applications that identify the posture of the mobile phone (such as horizontal and vertical screen switching, related games, magnetometer posture calibration), vibration recognition related functions (such as pedometer, tapping), etc.; as for other sensors that can also be configured in the mobile phone 100, such as gyroscopes, barometers, hygrometers, thermometers, infrared sensors, etc., they will not be repeated here.

[0057] The positioning device 108 is used to provide the geographical location for the mobile phone 100. It is understandable that the positioning device 108 can specifically be a receiver of a global positioning system (GPS) or a Beidou satellite navigation system, a Russian GLONASS or other positioning system. After receiving the geographical location sent by the above positioning system, the positioning device 108 sends the information to the processor 101 for processing, or sends it to the memory 103 for storage. In some other embodiments, the positioning device 108 can also be a receiver of an assisted global satellite positioning system (AGPS). The AGPS system assists the positioning device 108 in completing the ranging and positioning services by acting as an auxiliary server. In this case, the auxiliary positioning server communicates with the positioning device 108 (i.e., GPS receiver) of the terminal such as the mobile phone 100 through a wireless communication network to provide positioning assistance. In some other embodiments, the positioning device 108 can also be a positioning technology based on a Wi-Fi access point. Since each Wi-Fi access point has a globally unique MAC address, the terminal can scan and collect the broadcast signals of the surrounding Wi-Fi access points when Wi-Fi is turned on, so the MAC address broadcast by the Wi-Fi access point can be obtained; the terminal sends these data (such as MAC addresses) that can identify the Wi-Fi access point to the location server through the wireless communication network, and the location server retrieves the geographical location of each Wi-Fi access point, and calculates the geographical location of the electronic device based on the strength of the Wi-Fi broadcast signal and sends it to the positioning device 108 of the electronic device.

[0058] The audio circuit 109, the speaker 113, and the microphone 114 can provide an audio interface between the user and the mobile phone 100. The audio circuit 109 can transmit the received audio data to the speaker 113 after converting the received audio data into an electrical signal, which is converted into a sound signal for output by the speaker 113; on the other hand, the microphone 114 converts the collected sound signal into an electrical signal, which is received by the audio circuit 109 and converted into audio data, and then the audio data is output to the RF circuit 102 to be sent to, for example, another mobile phone, or the audio data is output to the memory 103 for further processing.

[0059] The peripheral interface 110 is used to provide various interfaces for external input / output devices (such as keyboard, mouse, external display, external memory, user identification module card, etc.). For example, it is connected to the mouse through a universal serial bus (USB) interface, and is connected to the user identification module card (SIM) card provided by the telecommunications operator through the metal contacts on the user identification module card slot. The peripheral interface 110 can be used to couple the above-mentioned external input / output peripheral devices to the processor 101 and the memory 103.

[0060] The mobile phone 100 may also include a power supply device 111 (such as a battery and a power management chip) for supplying power to various components. The battery may be logically connected to the processor 101 through the power management chip, so that the power supply device 111 can manage charging, discharging, power consumption, and other functions. Figure 1 Not shown, the mobile phone 100 may also include a camera (front camera and / or rear camera), a flash, a micro-projection device, a near field communication (NFC) device, etc., which will not be described in detail here.

[0061] Furthermore, the mobile phone 100 may run on an operating system such as Android or LINUX, and the present application embodiment does not impose any restrictions on this. Taking the Android operating system as an example, Figure 2 As shown, the Android operating system can be divided into four layers, from high to low, namely the application layer 201 (i.e., APP layer), the application framework layer 202 (i.e., Framework layer), the system runtime library layer 203 (i.e., Libraries layer) and the Linux kernel layer 204.

[0062] Among them, the application layer 201 mainly includes APPs written in Java language and running on the virtual machine. When the user operates the operation interface on the APP, by calling the relevant application programming interface (Application Programming Interface, API) in the Framework layer 202, it interacts with the system runtime layer 203 or the Linux kernel layer 204 to implement the functions corresponding to the operation interface.

[0063] Exemplarily, the APPs in the application layer 201 may be APP1, APP2, APP3, APP4, APP5, APP6, and the like.

[0064] The Framework layer 202 provides developers with an API framework that can fully access the APIs used by the application. Specifically, the Framework layer 202 provides a lot of APIs for developing applications, and by calling the corresponding APIs, an APP that meets relevant business needs can be constructed.

[0065] Exemplarily, the Framework layer 202 may include a view system, an Activity manager, a window manager, a location manager, a package manager, a content provider, a resource manager, etc. Among them, the view system may provide view support for the APP, the Activity manager may provide UI component support for the APP, the window manager may provide window management support for the APP, the location manager may provide positioning services for the APP, and the package manager may provide data packet support for the APP.

[0066] The system runtime layer 203 includes some C / C++ libraries, such as media libraries, system C libraries, and display management libraries (Surface Manager), etc. These libraries can be used by different components in the Android system, and the system runtime layer 203 can provide services to developers through the Framework layer 202. The Linux kernel layer 204 can be used to control the security (Securi ty), memory management (Memory Management), program management (Process Management), network stack (Network Stack), driver model (Driver Model) and other functions of the mobile phone 100. The Linux kernel layer 204 also serves as an abstract layer between the hardware (for example, CPU, network card, and memory, etc.) and the software stack, which can hide the specific hardware details to provide unified services for the upper layer (system runtime layer 203, application framework layer 202, and application layer 201).

[0067] For example, the display driver can be used to manage Figure 1 The interaction between the display and the graphics card of the mobile phone 100. The audio driver can ensure the normal operation of the audio circuit of the mobile phone 100. The input device driver is used to transmit the request of the operating system and convert it into a command that can be understood by a specific physical device controller (such as a touchpad). The camera driver is a bridge connecting the mobile phone and the camera, and can realize multiple functions such as video calls, video monitoring, and video acquisition. The WIFI driver can connect the mobile phone and the WiFi device, and can realize the Internet function of the mobile phone.

[0068] In one design, relevant modules can be added to the system architecture of the mobile phone to implement the system fault location method of the embodiment of the present application. The embodiment of the present application can add a performance fault detection service module, a log system driver module or a log package upload service module based on the Android system architecture (such as Figure 2 (shown in the dashed box). Optionally, the performance fault detection service module and the log package upload service module can be deployed in the system runtime layer, and the log system driver module can be deployed in the Linux kernel layer. Among them, the log system driver module is used to store system logs; the performance fault detection service module is used to analyze the system logs to perform system performance fault detection to generate fault information; the log package upload service module is used to upload the fault information to the cloud server.

[0069] In addition, multiple system service modules are also included, and different system service modules are used to provide different functional services. Optionally, in the case of an Android operating system, the target system service modules include a view system, an Activity manager, and an input library.

[0070] Below Figure 1 Taking the mobile phone shown in the figure as an example, the fault location method provided in the embodiment of the present application is introduced. It should be understood that the mobile phone in the following embodiment may have Figure 2 The software architecture is shown in Figure 1. Figure 3 As shown, in one embodiment, the method may include the following steps:

[0071] S301: In response to a system failure occurring during a user's operation of a mobile phone, target failure information is generated.

[0072] The target fault information includes a fault scenario identification code, and the fault scenario identification code is used to identify the fault scenario.

[0073] It should be noted that system failures include, but are not limited to, any one or more failures such as the phone freezing, freezing, not booting up, or crashing. The embodiments of the present application do not limit the specific system failures.

[0074] As a possible implementation method, the mobile phone obtains the current system status information and generates a fault scenario identification code based on the current system status information. The current system status information is used to reflect the current system status of the mobile phone during the user's operation of the mobile phone. Further, the mobile phone generates a fault scenario identification code based on the current system status information, and adds the fault scenario identification code to the initial fault information to obtain the target fault information; wherein the initial fault information is used to reflect the type of the current fault of the mobile phone.

[0075] S302: Upload target fault information so as to locate the fault according to multiple types of logs corresponding to the fault scenarios identified by the fault scenario identification codes in the target fault scenarios.

[0076] As a possible implementation method, the mobile phone can write the fault scenario identification code and the initial fault information into the fault log, and use the fault log as the target fault information. Furthermore, the mobile phone reports the fault log to the cloud server so that developers can promptly understand the specific cause of the mobile phone system failure.

[0077] In one design, in order to obtain target fault information, such as Figure 4 As shown, the fault location method provided in the embodiment of the present application in S301 may specifically include:

[0078] S3011. Obtain current system status information of the electronic device.

[0079] The current system status information is used to reflect the current system status of the electronic device during the user's operation of the electronic device.

[0080] In some embodiments, the operating system of the mobile phone may also provide various system services, which may be integrated in the application framework layer and the system runtime layer, and record different types of system status. Therefore, when a system failure is detected during the user's operation of the mobile phone, the mobile phone can obtain the current system status information of the mobile phone through these system services. Among them, system services generally run in the background. Compared with the programs run by the user, system services usually do not have program windows or dialog boxes to support the operation of other programs. The system status reflects the specific applications supported by the system service and the specific functions supported (for example, helping APP1 to achieve positioning or helping APP1 to achieve page loading, etc.).

[0081] Understandably, usually the initial fault information contains limited information. Developers can only learn the specific type of the current system fault through the initial fault information, and it is difficult to locate the specific scenario where the fault occurred. In actual applications, after developers learn that the current system fault type is stuck, they also want to locate the specific scenario where the stuck occurs so that they can optimize system services in a targeted manner. For example, what operation did the user perform in which APP to cause the system failure. When a fault occurs, the content reflected by the current system status information of the mobile phone can help developers understand the specific fault scenario.

[0082] For example, suppose a user clicks on an APP (such as APP1) on the mobile phone desktop. The mobile phone responds to the user's click on the APP and starts the APP. However, during the startup process, a flash back occurs, which means that the mobile phone has a system failure. At this time, the system service records the current system status information of the mobile phone as follows: receiving the APP1 startup command, starting APP1, and displaying the initialization interface of APP1. In this way, developers can understand through the current system status information that the system flashed back when the user opened APP1.

[0083] S3012. Generate a fault scenario identification code according to the current system status information.

[0084] The fault scenario identification code is used to identify the fault scenario, and different system status information corresponds to different fault scenario identification codes. For example, the fault scenario may be the startup scenario of AAP1, the sliding scenario of the page in APP2, and the like.

[0085] As a possible implementation manner, the mobile phone may encode the current system status information according to a preset encoding rule to obtain a fault scenario identification code corresponding to the current system status information.

[0086] It should be noted that the coding rules can be set in advance in the mobile phone by the developer. For example, the coding rules can be set based on a universally unique identifier (UUID) algorithm or a snowflake algorithm. The embodiments of the present application do not limit the specific coding rules.

[0087] For example, assuming that the current system status information is: receiving an APP1 startup command, and starting APP1, the mobile phone can determine that the current fault scenario is the startup of AAP1, and therefore can edit a fault scenario identification code corresponding to the startup scenario of AAP1 according to the coding rule.

[0088] In another exemplary embodiment, the mobile phone can also encode the text content in the current system status information according to the encoding rule to obtain the fault scenario identification code corresponding to the startup scenario of AAP1. In some embodiments, in order to facilitate developers to locate the fault scenario, the encoding rule set in the current system of the mobile phone is the same as the encoding rule set in the Beta version system of the mobile phone. In this way, it can be ensured that the fault scenario identification code corresponding to the same system status information is the same in the Gold version system and the Beta version system.

[0089] For example, the current system version of the mobile phone is the official version. After adopting the same encoding rules as the Beta version system, for the same system status information, the fault scenario identification code for the Beta version system is 12345, then the fault scenario identification code generated by the mobile phone in the current version system is also 12345.

[0090] It is understandable that the fault information generated in the Beta version is usually more comprehensive (for example, different types of system logs will be uploaded when a system failure occurs in the Beta version). Setting the same encoding rules as the Beta version can ensure that when the same fault scenario as the Beta version occurs, the generated fault scenario identification code is also consistent with the Beta version, so that developers can obtain more comprehensive fault information from the Beta version based on the fault scenario identification code.

[0091] S3013. Add the fault scenario identification code to the initial fault information to obtain target fault information.

[0092] The initial fault information is used to reflect the type of current fault of the electronic device.

[0093] As a possible implementation method, the mobile phone can add the fault scenario identification code to the initial fault information to obtain the target fault information, so that the target fault information not only carries the fault type reflected by the initial fault information, but also carries the fault scenario identification code that can uniquely correspond to the fault scenario.

[0094] As another possible implementation method, the mobile phone can write the fault scenario identification code and the initial fault information into the fault log, and use the fault log as the target fault information. Furthermore, the mobile phone reports the fault log to the cloud server so that the developer can promptly understand the specific cause of the fault in the mobile phone system.

[0095] In some embodiments, in order to facilitate the analysis of developers, the mobile phone can also obtain target fault information generated at different time points, obtain multiple target fault information, and cluster the multiple target fault information according to the fault scenario identification code to obtain at least one clustering result, wherein the fault scenario identification code corresponding to each target fault information in the same clustering result is the same. Further, the mobile phone can determine the fault scenario corresponding to the clustering result with a number of target fault information greater than or equal to a preset number as a high-frequency fault scenario.

[0096] In other embodiments, the cloud server may also cluster the target fault information reported by the mobile phone and extract high-frequency fault scenarios to facilitate R&D personnel to focus on analyzing these scenarios.

[0097] It is understandable that the mobile phone clusters multiple target fault information according to the fault scenario identification code, and can group the same fault scenario identification code together to count the number of the same fault scenario identification code. If the number is large, the mobile phone can determine the fault scenario corresponding to this fault scenario identification code as a high-frequency fault scenario, and report the high-frequency fault scenario to the cloud server so that developers can focus on analyzing these scenarios.

[0098] In one design, relevant modules can be added to the system architecture of the mobile phone to implement the system fault location method of the embodiment of the present application. For example, a performance fault detection service module, a log system driver module, or a log package upload service module, etc. can be added. Optionally, the performance fault detection service module and the log package upload service module can be deployed in the system runtime layer, and the log system driver module can be deployed in the Linux kernel layer. Among them, the log system driver module is used to store system logs; the performance fault detection service module is used to perform system performance fault detection by analyzing the system log to generate fault information; the log package upload service module is used to upload the fault information to the cloud server.

[0099] In addition, multiple system service modules are also included, and different system service modules are used to provide different functional services. Optionally, in the case of an Android operating system, the target system service modules include a view system, an Activity manager, and an input library.

[0100] Combine the following Figure 5, the functions of the above-mentioned performance fault detection service module, log system driver module and log packaging and uploading service module in the system are introduced.

[0101] like Figure 5 As shown, in response to user operations, the state changes, and the service module in the system will generate corresponding system state information. The mobile phone can write the system state information into a pre-created log system driver module.

[0102] In some embodiments, in order to obtain system status information, a detection stub may be added to a target system service module, wherein the target system service module is any one of a plurality of system service modules. Thus, when a user operation includes requesting the target system service module to provide a functional service, the target system service module will generate corresponding system status information, and the target system service module can write the system status information into a pre-created log system driver module through the detection stub.

[0103] It can be understood that different system service modules record different types of system states. For the system states that the target scenario is concerned about, pile points are added at the locations where they change, and notifications can be sent to the outside when the state changes (such as writing system state information into the log system driver module).

[0104] In actual applications, developers can select the target system service module to which detection points need to be added based on the system status that the target scenario is concerned about. For example, if you need to pay attention to the system status corresponding to the screen image when the user uses the APP, you can use the view system and the Activity manager as the target system service module to which detection points need to be added. If you need to pay attention to the system status corresponding to the pop-up window when the user uses the APP, you can use the window manager as the target system service module to which detection points need to be added.

[0105] In some embodiments, the fault location method provided in the embodiments of the present application may further include:

[0106] S1.1, if Figure 5 As shown, when a user clicks on an APP on the system desktop, the input library in the system architecture can sense the user's operation and create a screen window for the user through the view system and Activity manager to place UI components related to the APP.

[0107] S1.2, the system service module senses the system status change, generates system status information, and writes the system status information into the log system driver module.

[0108] It can be understood that the changes in the system status generated by this process can be described by system status information and stored in the log system driver module in the form of logs.

[0109] S1.3. The performance fault detection service module reads and parses the logs in the log system driver module.

[0110] S1.4 The performance fault detection service module updates the system status information according to the analysis results.

[0111] For example, the mobile phone can read the latest system status information written in the log system driver module through the performance fault detection service module, and use the latest system status information written as the current system status information.

[0112] In some embodiments, the fault location method provided in the embodiments of the present application may further include:

[0113] S2.1, such as Figure 5 As shown, a performance failure occurs while the user is operating the mobile phone.

[0114] S2.2. When a system failure is detected during the user's operation of the mobile phone, the system service module may also write the generated performance failure information into the log system driver module.

[0115] S2.3. The performance fault detection service module reads and parses the log in the log system driver module to obtain the initial fault information and the previous system status information.

[0116] S2.4. The performance fault detection service module obtains target fault information according to the initial fault information and the previous system status information.

[0117] S2.5. The mobile phone can save the target fault information to the log package upload service module through the performance fault detection service module.

[0118] S2.6 packages the target fault information and uploads it to the server through the log packaging and uploading service module.

[0119] The above mainly introduces the solution provided by the embodiment of the present application from the perspective of the method. In order to achieve the above functions, it includes hardware structures and / or software modules corresponding to the execution of each function. It should be easy to realize that the technical goals in this field are combined with the units and algorithm steps of each example described in the embodiments disclosed in this article, and the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Professional and technical goals can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0120] In an exemplary embodiment, the present application also provides a fault locating device. Figure 6 A schematic diagram of the components of a fault location device provided in an embodiment of the present application. Figure 6 As shown, the fault location device includes: a processing unit 401 and a sending unit 402 .

[0121] The processing unit 401 is used to generate target fault information in response to a system fault occurring during a user's operation of an electronic device, wherein the target fault information includes a fault scenario identification code, and the fault scenario identification code is used to identify the fault scenario; the sending unit 402 is used to upload the target fault information so as to locate the fault according to multiple types of logs corresponding to the fault scenarios identified by the fault scenario identification codes in the target fault scenarios.

[0122] It should be noted that Figure 6 The division of modules in the example is schematic and is only a logical function division. There may be other division methods in actual implementation. For example, two or more functions may be integrated into one processing module. The above integrated modules may be implemented in the form of hardware or in the form of software functional units.

[0123] In an exemplary embodiment, the embodiment of the present application further provides a readable storage medium, including software instructions, which, when executed on an electronic device, enables the electronic device to execute any one of the methods provided in the above embodiments.

[0124] In an exemplary embodiment, the embodiment of the present application further provides a computer program product including computer-executable instructions, which, when executed on an electronic device, enables the electronic device to execute any one of the methods provided in the above embodiments.

[0125] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using a software program, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer-executable instructions. When the computer-executable instructions are loaded and executed on a computer, the process or function according to the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer-executable instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer-executable instructions can be transmitted from a website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (digital subscriber line, DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, server or data center. The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. that contains one or more servers that can be integrated with the medium. The available medium may be a magnetic medium (eg, a floppy disk, a hard disk, a magnetic tape), an optical medium (eg, a DVD), or a storage medium (eg, a solid state disk (SSD)).

[0126] Although the present application is described herein in conjunction with various embodiments, in the process of implementing the claimed application, those skilled in the art may understand and implement other changes to the disclosed embodiments by viewing the drawings, the disclosure, and the appended claims. In the claims, the word "comprising" does not exclude other components or steps, and "one" or "an" does not exclude multiple situations. A single processor or other unit can implement several functions listed in the claims. Certain measures are recorded in different dependent claims, but this does not mean that these measures cannot be combined to produce good results.

[0127] Although the present application has been described in conjunction with specific features and embodiments thereof, it is obvious that various modifications and combinations may be made thereto without departing from the spirit and scope of the present application. Accordingly, this specification and the drawings are merely exemplary illustrations of the present application as defined by the appended claims, and are deemed to have covered any and all modifications, variations, combinations or equivalents within the scope of the present application. Obviously, those skilled in the art may make various modifications and variations to the present application without departing from the spirit and scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is also intended to include these modifications and variations.

[0128] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions within the technical scope disclosed in the present application should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. A fault location method, characterized in that: The method comprises: In response to a system failure occurring during a user's operation of an electronic device, generating target failure information, the target failure information including a failure scenario identification code, the failure scenario identification code being used to identify a failure scenario; The target fault information is uploaded so as to locate the fault according to multiple types of logs corresponding to the fault scenarios identified by the fault scenario identification codes in the target fault scenarios.

2. The method according to claim 1, characterized in that The generating target fault information comprises: Acquire current system status information of the electronic device; wherein the current system status information is used to reflect the current system status of the electronic device during the user's operation of the electronic device; Generate a fault scenario identification code according to the current system status information; The fault scenario identification code is added to the initial fault information to obtain the target fault information; wherein the initial fault information is used to reflect the type of the current fault of the electronic device.

3. The method according to claim 2, characterized in that The electronic device comprises a log system driving module, The method further comprises: in response to a user operating the electronic device, writing system status information generated during the user operating the electronic device into the log system driver module in the form of a log file; the system status information is used to reflect the system status of the electronic device during the user operating the electronic device; The obtaining of current system status information of the electronic device includes: The system status information most recently written in the log system driver module is read, and the system status information most recently written is used as the current system status information.

4. The method according to claim 3, characterized in that The electronic device comprises a plurality of system service modules, and different system service modules are used to provide different functional services; a detection point is added to a target system service module among the plurality of system service modules; the detection point is used to detect the system state change of the electronic device when the target system service module provides the functional service; In response to the user operating the electronic device, writing the system status information generated during the user operating the electronic device into the log system driver module includes: In response to the user operating the electronic device to implement the functional service provided by the target system service module, the target system service module obtains system status information through the detection point detection; The target system service module writes the obtained system status information into the log system driver module.

5. The method according to claim 3, characterized in that: The target system service module includes at least one of a view system, an Activity manager, and an input library.

6. The method according to claim 3, characterized in that The electronic device is deployed with a performance fault detection service module and a log package upload service module, and the generating target fault information includes: Parsing the log file in the log system driver module through the performance fault detection service module to obtain the initial fault information and the current system status information, and generating the target fault information according to the initial fault information and the current system status information; The uploading of the target fault information includes: saving the target fault information to the log package upload service module; and uploading the target fault information through the log package upload service module.

7. The method according to any one of claims 1 to 6, characterized in that: The fault scenario identification codes generated based on the same system status information under different software versions are the same; Different software versions include commercial software versions and Beta software versions of the same operating system.

8. The method according to claim 7, characterized in that The fault scenario corresponds to at least one of the following types of logs: Operating system log android log, kernel log kernel log, system trace log systrace log, simple performance log simpleperf log; The logs corresponding to the fault scenarios are obtained during the Beta software version testing.

9. The method according to any one of claims 1 to 6, characterized in that: The method further comprises: Acquire the target fault information generated at different time points to obtain a plurality of target fault information; Clustering the plurality of target fault information according to the fault scenario identification codes included in the plurality of target fault information to obtain at least one clustering result; the fault scenario identification codes corresponding to the respective target fault information in one clustering result are the same; A target clustering result in which the number of target fault information is greater than or equal to a preset number is obtained, and a fault scenario identified by a fault scenario identification code corresponding to the target clustering result is determined as a high-frequency fault scenario.

10. A fault location device, characterized in that: include: A functional unit for executing the fault location method according to any one of claims 1 to 9; wherein the actions executed by the functional unit are implemented by hardware or by hardware executing corresponding software implementations.

11. An electronic device, characterized in that: The method comprises a memory and a processor, wherein the memory is used to store a computer program, and the processor is used to call the computer program to implement the fault location method according to any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that: The method comprises computer program instructions, and when the computer program instructions are executed by a processor in an electronic device, the fault location method according to any one of claims 1 to 9 is implemented.

Images