CN111625431B

CN111625431B - Log information generation method and device and electronic equipment

Info

Publication number: CN111625431B
Application number: CN201910151968.7A
Authority: CN
Inventors: 张烽; 张瑞荣; 李翠琴
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2019-02-28
Filing date: 2019-02-28
Publication date: 2022-04-22
Anticipated expiration: 2039-02-28
Also published as: WO2020173377A1; CN111625431A

Abstract

The embodiment of the application provides a log information generation method, a log information generation device and electronic equipment, wherein the method comprises the following steps: the electronic equipment receives a first operation of a user; in response to the first operation, the electronic equipment generates a unique tracking identifier corresponding to a service, transmits the tracking identifier in the whole calling link of the service, and finally stores the tracking identifier in a calling record of each thread of each process of the calling link to generate log information comprising the tracking identifier.

Description

Log information generation method and device and electronic equipment

Technical Field

The present application relates to the field of terminal technologies, and in particular, to a log information generation method and apparatus, and an electronic device.

Background

At present, in the android operating system development process of a smart phone, the analysis and the solution of the function class and the performance class problems depend on information output by logs and performance tracking logs (sysstrace). In the prior art, the flow log of the android system outputs information in service processing through a log system. For example, the log output format of the android system includes timestamp, process ID, thread ID, level, content. In practical application, problems (such as slow photographing) can occur, and multiple services and multiple layers of the android system are often involved, so that log information comprises different services, different processes and different threads, and therefore, parts related to a certain service are difficult to distinguish and can only be distinguished manually. Since the android system designs a plurality of layers, which is complex, a developer is generally familiar with only one service or one layer of the service. Therefore, in order to troubleshoot a problem, developers often need to manually filter useful information from a large amount of log information, that is, extract a part related to the business processing flow of the problem, the requirement on the capability of the developers is high, and the problem solving efficiency of the method is low.

Disclosure of Invention

The application provides a log information generation method, a log information generation device and electronic equipment, which are used for generating log information comprising tracking identifiers, so that developers can conveniently screen information related to each service according to the tracking identifier of each service, the capability requirement on the developers is reduced, and the problem solving efficiency is improved.

In a first aspect, an embodiment of the present application provides a log information generating method, where the method is applied to an electronic device, and the method includes: the electronic equipment receives a first operation of a user, in response to the first operation, the electronic equipment adds a unique tracking identifier corresponding to a service at a service starting inlet and transmits the tracking identifier in the whole calling link of the service, and then the electronic equipment stores the tracking identifier in a calling record of each thread of each process of the calling link and generates log information comprising the tracking identifier. Wherein the tracking identifier may be generated from an identifier of the electronic device and an occurrence time of the first operation.

According to the embodiment of the application, the calling link of one service can carry the only one tracking identifier, so that a developer can quickly locate a thread consuming longer time by calling the log information corresponding to the tracking identifier, and the reason of the fault is located.

In one possible design, the log information includes a call timestamp of the thread, a call service name, and a call relationship of other threads, and the electronic device may further generate a report causing an exception to the call link according to the call timestamp, the call service name, and the call relationship in the log information. Therefore, the analysis process of developers can be saved, and the problem solving efficiency is improved.

In one possible design, after the electronic device generates a unique trace identifier corresponding to a transaction, the trace identifier is written to the context of a first thread corresponding to a transaction entry, and then the trace identifier is passed from the first thread to a second thread via a communication message and written to the context of the second thread. If the second thread is not the last thread of the calling link, the tracking identification is transmitted from the second thread to the third thread through the communication message, and the tracking identification is written into the context of the third thread until the last thread of the calling link is executed repeatedly. It can be seen that this method can enable trace identification to be passed in the call link.

In one possible design, the electronic device obtains the tracking identifier from the context of each thread of the call link; and then writing the character string obtained by converting the tracking identifier into a call record of each thread in each process of a call link, and finally generating log information comprising the tracking identifier. Wherein the log comprises at least one of a running log, a kernel log, and a performance tracking log.

In a second aspect, an embodiment of the present application provides an electronic device, which includes a processor and a memory. Wherein the memory is used to store one or more computer programs; the one or more computer programs stored in the memory, when executed by the processor, enable the electronic device to implement any of the possible design methodologies of any of the aspects described above.

In a third aspect, the present application further provides an apparatus including a module/unit for performing the method of any one of the possible designs of any one of the above aspects. These modules/units may be implemented by hardware, or by hardware executing corresponding software.

In a fourth aspect, this embodiment also provides a computer-readable storage medium, which includes a computer program and when the computer program runs on an electronic device, causes the electronic device to execute any one of the possible design methods of any one of the above aspects.

In a fifth aspect, the present application further provides a computer program product, which when run on a terminal, causes the electronic device to execute any one of the possible design methods of any one of the above aspects.

These and other aspects of the present application will be more readily apparent from the following description of the embodiments.

Drawings

Fig. 1 is a schematic diagram of a conventional log screening method according to an embodiment of the present application;

fig. 2 is a schematic view of an application scenario provided in an embodiment of the present application;

fig. 3 is a schematic structural diagram of a mobile phone according to an embodiment of the present application;

fig. 4 is a schematic structural diagram of an android operating system provided in the embodiment of the present application;

fig. 5 is a schematic structural diagram of an improved android operating system according to an embodiment of the present application;

fig. 6 is a schematic flowchart of a log information generating method according to an embodiment of the present application;

fig. 7 is a schematic diagram illustrating trace identifier delivery of a binder communication mechanism according to an embodiment of the present application;

fig. 8 is a schematic diagram illustrating a trace identifier passing of a handler communication mechanism according to an embodiment of the present application;

fig. 9 is a schematic diagram illustrating a tracking identifier delivery interaction flow based on binder synchronization invocation according to an embodiment of the present application;

fig. 10 is a schematic diagram illustrating an automatic log screening method according to an embodiment of the present application;

fig. 11a and 11b are schematic diagrams of a fault location manner of the performance tracking log according to the embodiment of the present application.

FIG. 12 is a schematic view of an apparatus according to an embodiment of the present disclosure;

fig. 13 is a schematic structural diagram of an electronic device according to an embodiment of the present application.

Detailed Description

In the prior art, the flow log of the android system outputs information in service processing through a log system. For example, the log output format of the android system includes timestamp, process ID, thread ID, level, and content, and the output log information includes different services, different processes, and different threads, so that it is difficult to distinguish and extract the parts related to the own service, and only depends on manual distinction, for example, the parts marked by black dots shown in fig. 1 are the parts marked by manual work and related to the own service. Therefore, the information output by the existing journal may relate to cross-process or cross-thread calling relationship, the information of the calling link of a certain service to be acquired depends on manual differentiation, and the fault analysis completely depends on the service capability and the code familiarity of a developer.

Similarly, the performance tracking (sysstrace) log of the android system at present has a similar problem to the flow log, and the sysstrace log can only provide the relationship of processing of each layer inside one thread, and cannot provide the relationship of cross-process or cross-thread call processing. For example, a timeout operation may involve cross-process or cross-thread calls, and if the reason for the timeout is to be found, the timeout operation is completely dependent on the business capability of the developer, which obviously takes time and labor, and the problem is solved with low efficiency.

In order to solve the above problem, an embodiment of the present invention provides a log information generating method, which is mainly executed by an electronic device, and when the electronic device receives a first operation of a user, and responds to the first operation, the electronic device automatically generates a unique tracking identifier corresponding to the service, and the tracking identifier is transmitted in an entire call link of the service, so that the electronic device can store the tracking identifier in a call record of each thread of each process of the call link, and generate log information including the tracking identifier. Therefore, a developer can obtain the log information related to the service by searching the tracking identifier, so that the reason of the fault occurrence is analyzed.

For example, when a mobile phone detects a touch operation of a user on a photographing control in a camera application, the mobile phone responds to the touch operation, that is, a unique tracking identifier is added to a photographing service start entry corresponding to the control, and then the tracking identifier is passed down to a framework layer and a driver layer, and finally log information corresponding to the tracking identifier can be generated. If the mobile phone is stuck in response to the operation of taking a picture, the developer can quickly locate the thread which takes a long time by calling the log information corresponding to the tracking identifier, so as to locate the reason of the fault.

The log information generation method provided by the embodiment of the application can be applied to the scene shown in fig. 2. In fig. 2, when a user operates the electronic device 100, the electronic device generates a log, where the log includes log information corresponding to the tracking identifier, and then the electronic device may upload the log information to the cloud via the communication network, and then a developer operates the terminal device 200 to obtain the log of the electronic device from the cloud, obtain the log information of the target service via the tracking identifier, and analyze a failure cause. In addition, the electronic device 100 and the terminal device 200 may also be directly connected through a development tool, that is, the terminal device 200 directly obtains the log information of the electronic device 100 through the development tool, and analyzes the log information to obtain the failure cause.

In some embodiments of the present application, the electronic device 100 shown in fig. 2 may be a portable electronic device that also includes other functions, such as personal digital assistant and/or music player functions, such as a mobile phone, a tablet computer, a wearable device with wireless communication functions (e.g., a smart watch), and so on. Exemplary embodiments of the portable electronic device include, but are not limited to, a mount

Or other operating system. The terminal device 200 may be a personal computer.

Taking the electronic device as an example of a mobile phone, fig. 3 shows a schematic structural diagram of the mobile phone 100.

The mobile phone 100 may include a processor 110, an external memory interface 120, an internal memory 121, a USB interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, a sensor module 180, a button 190, a motor 191, an indicator 192, a camera 193, a display 194, a SIM card interface 195, and the like.

It is to be understood that the illustrated structure of the embodiment of the present invention does not specifically limit the mobile phone 100. In other embodiments of the present application, the handset 100 may include more or fewer components than shown, or some components may be combined, some components may be separated, or a different arrangement of components may be used. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

Processor 110 may include one or more processing units, such as: the processor 110 may include an Application Processor (AP), a modem processor, a Graphics Processing Unit (GPU), an Image Signal Processor (ISP), a controller, a memory, a video codec, a Digital Signal Processor (DSP), a baseband processor, and/or a Neural-Network Processing Unit (NPU), etc. The different processing units may be separate devices or may be integrated into one or more processors. The controller may be a neural center and a command center of the cell phone 100, among others. The controller can generate an operation control signal according to the instruction operation code and the timing signal to complete the control of instruction fetching and instruction execution.

A memory may also be provided in processor 110 for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. The memory may hold instructions or data that have just been used or recycled by the processor 110. If the processor 110 needs to reuse the instruction or data, it can be called directly from the memory. Avoiding repeated accesses reduces the latency of the processor 110, thereby increasing the efficiency of the system.

The processor 110 may execute the log information generating method provided by the embodiment of the present application to generate the log information corresponding to the trace identifier. When the processor 110 integrates different devices, such as a CPU and a GPU, the CPU and the GPU may cooperate to perform the method provided by the embodiments of the present application, such as a part of the algorithm is executed by the CPU, and another part of the algorithm is executed by the GPU, so as to obtain faster processing efficiency.

The display screen 194 is used to display images, video, and the like. The display screen 194 includes a display panel. The display panel may adopt a Liquid Crystal Display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (active-matrix organic light-emitting diode, AMOLED), a flexible light-emitting diode (FLED), a miniature, a Micro-oeld, a quantum dot light-emitting diode (QLED), and the like. In some embodiments, the cell phone 100 may include 1 or N display screens 194, with N being a positive integer greater than 1.

In this embodiment, the display screen 194 receives a touch operation of a user, and the processor 110 adds a unique tracking identifier corresponding to the service at the service initiation entry in response to the touch operation.

The cameras 193 (front camera or rear camera, or one camera may be both front camera and rear camera) are used to capture still images or video. In general, the camera 193 may include a photosensitive element such as a lens group including a plurality of lenses (convex lenses or concave lenses) for collecting an optical signal reflected by an object to be photographed and transferring the collected optical signal to an image sensor, and an image sensor. And the image sensor generates an original image of the object to be shot according to the optical signal.

The internal memory 121 may be used to store computer-executable program code, which includes instructions. The processor 110 executes various functional applications of the cellular phone 100 and data processing by executing instructions stored in the internal memory 121. The internal memory 121 may include a program storage area and a data storage area. Wherein the storage program area may store an operating system, codes of application programs (such as a camera application, a WeChat application, etc.), and the like. The data storage area can store data created during the use of the mobile phone 100 (such as images, videos and the like acquired by a camera application), and the like.

The internal memory 121 may further store codes of the anti-false touch algorithm provided in the embodiment of the present application. When the code of the anti-false touch algorithm stored in the internal memory 121 is executed by the processor 110, the touch operation during the folding or unfolding process may be masked.

In addition, the internal memory 121 may include a high-speed random access memory, and may further include a nonvolatile memory, such as at least one magnetic disk storage device, a flash memory device, a universal flash memory (UFS), and the like.

Of course, the codes of the false touch prevention algorithm provided by the embodiment of the present application may also be stored in the external memory. In this case, the processor 110 may execute the code of the anti-false touch algorithm stored in the external memory through the external memory interface 120 to shield the touch operation during the folding or unfolding process.

The sensor module 180 may include a gyroscope sensor, an acceleration sensor, a proximity light sensor, a fingerprint sensor, a touch sensor, a rotation axis sensor, etc., and of course, the mobile phone 100 may further include other sensors, such as a temperature sensor, a pressure sensor, a distance sensor, a magnetic sensor, an ambient light sensor, an air pressure sensor, a bone conduction sensor, etc., which are not shown in the figure).

Illustratively, the display screen 194 of the handset 100 displays a main interface that includes icons for a plurality of applications (e.g., a camera application, a WeChat application, etc.). The user clicks the icon of the camera application in the home interface through the touch sensor 180K, which triggers the processor 110 to start the camera application and open the camera 193. The display screen 194 displays an interface, such as a viewfinder interface, for the camera application.

The wireless communication function of the mobile phone 100 can be realized by the antenna 1, the antenna 2, the mobile communication module 151, the wireless communication module 152, the modem processor, the baseband processor, and the like.

The

antennas

1 and 2 are used for transmitting and receiving electromagnetic wave signals. Each antenna in terminal device 100 may be used to cover a single or multiple communication bands. Different antennas can also be multiplexed to improve the utilization of the antennas. For example: the antenna 1 may be multiplexed as a diversity antenna of a wireless local area network. In other embodiments, the antenna may be used in conjunction with a tuning switch.

The mobile communication module 151 may provide a solution including 2G/3G/4G/5G wireless communication and the like applied to the terminal device 100. The mobile communication module 151 may include at least one filter, a switch, a power amplifier, a Low Noise Amplifier (LNA), and the like. The mobile communication module 151 may receive electromagnetic waves from the antenna 1, filter, amplify, etc. the received electromagnetic waves, and transmit the electromagnetic waves to the modem processor for demodulation. The mobile communication module 150 may also amplify the signal modulated by the modem processor, and convert the signal into electromagnetic wave through the antenna 1 to radiate the electromagnetic wave. In some embodiments, at least some of the functional modules of the mobile communication module 151 may be provided in the processor 110. In some embodiments, at least some of the functional modules of the mobile communication module 151 may be disposed in the same device as at least some of the modules of the processor 110.

The modem processor may include a modulator and a demodulator. The modulator is used for modulating a low-frequency baseband signal to be transmitted into a medium-high frequency signal. The demodulator is used for demodulating the received electromagnetic wave signal into a low-frequency baseband signal. The demodulator then passes the demodulated low frequency baseband signal to a baseband processor for processing. The low frequency baseband signal is processed by the baseband processor and then transferred to the application processor. The application processor outputs a sound signal through an audio device (not limited to the speaker 170A, the receiver 170B, etc.) or displays an image or video through the display screen 194. In some embodiments, the modem processor may be a stand-alone device. In other embodiments, the modem processor may be provided in the same device as the mobile communication module 150 or other functional modules, independent of the processor 110.

The wireless communication module 152 may provide a solution for wireless communication applied to the terminal device 100, including Wireless Local Area Networks (WLANs) (e.g., wireless fidelity (Wi-Fi) networks), bluetooth (bluetooth, BT), Global Navigation Satellite System (GNSS), Frequency Modulation (FM), Near Field Communication (NFC), Infrared (IR), and the like. The wireless communication module 152 may be one or more devices integrating at least one communication processing module. The wireless communication module 152 receives electromagnetic waves via the antenna 2, performs frequency modulation and filtering processing on electromagnetic wave signals, and transmits the processed signals to the processor 110. The wireless communication module 152 may also receive a signal to be transmitted from the processor 110, frequency-modulate it, amplify it, and convert it into electromagnetic waves via the antenna 2 to radiate it.

In addition, the mobile phone 100 can implement an audio function through the audio module 170, the speaker 170A, the receiver 170B, the microphone 170C, the earphone interface 170D, and the application processor. Such as music playing, recording, etc. The handset 100 may receive key 190 inputs, generating key signal inputs relating to user settings and function controls of the handset 100. The handset 100 can generate a vibration alert (e.g., an incoming call vibration alert) using the motor 191. The indicator 192 in the mobile phone 100 may be an indicator light, and may be used to indicate a charging status, a power change, or a message, a missed call, a notification, etc. The SIM card interface 195 in the handset 100 is used to connect a SIM card. The SIM card can be attached to and detached from the cellular phone 100 by being inserted into the SIM card interface 195 or being pulled out from the SIM card interface 195.

It should be understood that in practical applications, the mobile phone 100 may include more or less components than those shown in fig. 1, and the embodiment of the present application is not limited thereto.

The software system of the mobile phone can adopt a layered architecture, an event-driven architecture, a micro-core architecture, a micro-service architecture or a cloud architecture. The embodiment of the invention takes an Android system with a layered architecture as an example, and exemplarily illustrates a software structure of a mobile phone.

The embodiment of the present application takes an Android system with a layered architecture as an example, and exemplarily illustrates a software structure of the electronic device 100. Fig. 4 is a block diagram of a software structure of the electronic device 100 according to the embodiment of the present application.

The layered architecture divides the software into several layers, each layer having a clear role and division of labor. The layers communicate with each other through a software interface. In some embodiments, the Android system is divided into four layers, an application layer, an application framework layer, an Android runtime (Android runtime) and system library, and a kernel layer from top to bottom.

The application layer may include a series of application packages.

As shown in fig. 4, the application package may include applications such as camera, gallery, calendar, phone call, map, navigation, WLAN, bluetooth, music, video, short message, etc.

The application framework layer provides an Application Programming Interface (API) and a programming framework for the application program of the application layer. The application framework layer includes a number of predefined functions.

As shown in FIG. 4, the application framework layers may include a window manager, content provider, view system, phone manager, resource manager, notification manager, and the like.

The window manager is used for managing window programs. The window manager can obtain the size of the display screen, judge whether a status bar exists, lock the screen, intercept the screen and the like.

The content provider is used to store and retrieve data and make it accessible to applications. The data may include video, images, audio, calls made and received, browsing history and bookmarks, phone books, etc.

The view system includes visual controls such as controls to display text, controls to display pictures, and the like. The view system may be used to build applications. The display interface may be composed of one or more views. For example, the display interface including the short message notification icon may include a view for displaying text and a view for displaying pictures.

The telephone manager is used for providing the communication function of the mobile phone. Such as management of call status (including on, off, etc.).

The resource manager provides various resources for the application, such as localized strings, icons, pictures, layout files, video files, and the like.

The notification manager enables the application to display notification information in the status bar, can be used to convey notification-type messages, can disappear automatically after a short dwell, and does not require user interaction. Such as a notification manager used to inform download completion, message alerts, etc. The notification manager may also be a notification that appears in the form of a chart or scroll bar text at the top status bar of the system, such as a notification of a background running application, or a notification that appears on the screen in the form of a dialog window. For example, prompting text information in the status bar, sounding a prompt tone, vibrating the electronic device, flashing an indicator light, etc.

The Android Runtime comprises a core library and a virtual machine. The Android runtime is responsible for scheduling and managing an Android system.

The core library comprises two parts: one part is a function which needs to be called by java language, and the other part is a core library of android.

The application layer and the application framework layer run in a virtual machine. And executing java files of the application program layer and the application program framework layer into a binary file by the virtual machine. The virtual machine is used for performing the functions of object life cycle management, stack management, thread management, safety and exception management, garbage collection and the like.

The system library may include a plurality of functional modules. For example: surface managers (surface managers), Media Libraries (Media Libraries), three-dimensional graphics processing Libraries (e.g., OpenGL ES), 2D graphics engines (e.g., SGL), and the like.

The surface manager is used to manage the display subsystem and provide fusion of 2D and 3D layers for multiple applications.

The media library supports a variety of commonly used audio, video format playback and recording, and still image files, among others. The media library may support a variety of audio-video encoding formats, such as: MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, etc.

The three-dimensional graphic processing library is used for realizing three-dimensional graphic drawing, image rendering, synthesis, layer processing and the like.

The 2D graphics engine is a drawing engine for 2D drawing.

The kernel layer is a layer between hardware and software. The inner core layer at least comprises a display driver, a camera driver, an audio driver and a sensor driver.

In order to realize the purpose of tracking the call link, the embodiment of the application improves the android operating system shown in fig. 4, and as shown in fig. 5, a tracking system (HwTrace) for realizing the call link tracking function is added to the android system. The hwTrace system provides interfaces at an application layer (App), a Framework layer (Framework), a system library (Native) and a Kernel layer (Kernel) to support the functions of starting and stopping tracking of a business process. Then, the current communication mechanisms (including binder, hwbinder, handler, socket and system call) are modified, and after tracking is started, the transmission of the tracking identifier is realized according to the communication mechanisms of the processes, the threads, the user states and the kernel states.

As shown in fig. 5, in the embodiment of the present application, an existing communication mechanism is improved, the improved modules mainly relate to a message (message Java) of a Framework layer, a cross-process communication library (Binder lib) of a Native layer, and a cross-process communication driver (Binder driver) of a message and a Kernel layer, in addition, a tracking system is provided with a tracking system library (HwTrace lib) of Java language in the Framework, a tracking system library (HwTrace lib) of C/C + + language is provided in the Native, and a tracking system library (whtrace lib) of Kernel language is provided in the Kernel layer.

Based on the improved android operating system shown in fig. 5, in the embodiment of the present application, details of the log information generation method provided by the embodiment of the present application will be described below with reference to the accompanying drawings and application scenarios. The following embodiments may be implemented in the electronic device 100 having the above-described hardware structure.

Referring to fig. 6, a flow of a log information generating method provided by an embodiment of the present application is exemplarily shown, and the method is executed by an electronic device.

In step 301, the electronic device receives a first operation of a user, and in response to the first operation, the electronic device generates a unique tracking identifier corresponding to the service, and passes the tracking identifier through an entire call link of the service.

The first operation may be a touch operation, a voice instruction, or the like, and the whole call link includes at least one process, and the at least one process includes at least one thread. When the call link includes more than two processes, the call link includes a cross-process call and a cross-thread call.

Step 302, the electronic device stores the trace identifier in a call record of each thread of each process of the call link, and generates log information including the trace identifier.

For example, the log output format includes a timestamp, a process ID, a thread ID, a level, a trace identifier, and a content, and each piece of information of the finally output log includes the trace identifier.

For example, when the mobile phone detects a touch operation of a user on a photographing control in a camera application, the mobile phone responds to the touch operation, that is, a unique tracking identifier is added to an entry of a photographing service corresponding to the control, and then the tracking identifier is passed down to the framework layer and the driver layer, and finally log information corresponding to the tracking identifier can be generated. Since the calling link may involve different layers and different communication mechanisms, in order to realize that the trace identifier can be accurately passed down, the electronic device generates a unique trace identifier corresponding to the service, writes the trace identifier into the context of the first thread corresponding to the service entry, then passes the trace identifier from the first thread to the second thread through a communication message, and writes the trace identifier into the context of the second thread. If the second thread is not the last thread of the calling link, the tracking identification is transmitted from the second thread to the third thread through the communication message, and the tracking identification is written into the context of the third thread until the last thread of the calling link is executed repeatedly. It should be noted that the first thread, the second thread, and the third thread may be threads of the same process or threads of different processes, and the call link may involve different communication methods.

Step 303, optionally, the electronic device generates a report causing an exception to the call link according to the call timestamp of the thread, the call service name, and the call relationship with other threads in the log information.

Specifically, the electronic device calculates the call time consumption of each thread in the call link according to the call timestamp, and then generates a report causing the call link to be abnormal according to the call time consumption, the call relation and the call server name. For example, if a thread takes a long time, a report is generated that the thread has timed out.

Therefore, the method and the device can realize that the calling link of one service carries the only one tracking identifier, so that a developer can quickly locate a thread consuming longer time by calling the log information corresponding to the tracking identifier, thereby locating the reason of the fault. The above-mentioned method of tracing the call link by the trace identifier is not limited to generating log information, but may be used to generate other output information related to the service, for example, to generate service information including the trace identifier.

For different communication modes, the embodiment of the present application provides a specific delivery mode of a trace identifier, and it should be noted that, hereinafter, a trace identifier is referred to as a trace identifier, where the trace identifier may be generated according to an identifier of an electronic device and an actual operation time of a user, and the identifier of the electronic device may be an identifier of a processor.

First, in the embodiment of the present application, a list of main communication modes, application scenarios, entities, TraceID transfer modes, and context setting and clearing conditions of threads included in an android system is shown in table 1.

TABLE 1

Specifically, for communication method one and communication method two in table 1

A complete Binder communication process is shown in fig. 7, and the following steps are included in fig. 7:

in step 1, the process 1 transmits communication data to the Binder driver through a command word BC _ Transaction.

And step 2, the Binder driver forwards the communication data to the process 2 for processing through the command word BR _ Transaction.

And step 3, the process 2 returns the return result to the Binder driver through the command of the command word BC _ REPLY.

And 4, forwarding the return result to the process 1 by the Binder driver through the command word BR _ REPLY.

For the first communication mode, the basic mode for transmitting the TraceID in the binder communication process is as follows: (1) writing the TraceID into the context of the process when the process 1 sends data; (2) when the process 2 receives data, firstly storing the context of the current thread, then acquiring the TraceID from the context, and writing the TraceID into the context of the process per se; and after the processing is finished, restoring the context of the current process.

Optionally, the first implementation manner: the lib layer and the driver of the binder cooperate to complete the transmission and the clearing

Specifically, a trailer id field is added to a library layer data structure and a driver layer data structure of the binder, wherein the data structure comprises binder _ transaction _ data and binder _ transaction.

1. Passing in binder's lib processing flow: BC _ TRANSACTION/BC _ REPLY is used for acquiring the TraceID from the thread context and writing the TraceID into the binder _ TRANSACTION _ data. BR _ TRANSACTION, used for realizing that the current thread context is saved first, and then the TraceID in the binder _ TRANSACTION _ data is set into the thread context; and restoring the context of the thread after the processing is finished.

2. Passing in binder's driver process flow

BC _ TRANSACTION/BC _ REPLY/BC _ TRANSACTION _ SG/BC _ REPLY _ SG, used for realizing the purpose of saving the TranseID in the lib layer binder _ TRANSACTION _ data into the driver layer binder _ TRANSACTION.

BR _ TRANSACTION/BR _ REPLY, used to save the TraceID in driver layer binder _ TRANSACTION to lib layer binder _ TRANSACTION _ data.

Optionally, the second implementation manner: completing transfer and cleanup at driver

The TraceID field is added in the binder layer data structure binder _ transaction of the binder.

Passing in binder's driver process flow:

BC _ TRANSACTION/BC _ REPLY/BC _ TRANSACTION _ SG/BC _ REPLY _ SG, used for realizing the acquisition of the TraceID from the thread context corresponding to the system call, and storing the TraceID into the binder _ TRANSACTION.

BR _ TRANSACTION/BR _ REPLY, which is used for setting the TraceID in the binder _ TRANSACTION into the thread context corresponding to the system call.

Clearing thread context information in driver processing flow of binder:

BR _ transport _ COMPLETE, to clear the TraceID in the thread context corresponding to the system call (where oneway does not clear).

It should be noted that, when the second implementation needs to support TraceID of the kernel-mode access thread context and transfer, if the opposite process does not have an associated TraceID space, kernel allocation and association are needed, but the second implementation cannot implement kernel allocation and association, so the first implementation may be preferred. And aiming at the second communication mode, the transmission mode of the tracking identifier is the same as the first communication mode.

Communication mode three for watch 1

Handle communication is based on a producer-consumer model, and the basic way to pass the TraceID during Handle communication is: before sending the message: writing the data in the thread context into the message; before message processing: setting data in the message into a thread context; after message processing: clearing thread context

Among them, handle communication needs to be processed in Java and C layers:

for the Java layer, as in fig. 8, in the first step, a TraceID field is added to the Message class Message. Second, when the message is sent to the queue (MessageQueue), the thread context TraceID is written into the msg message. And thirdly, a message processing dispatchHandler entry writes the TraceID in the message into a thread context. And fourthly, a message processing enqueuepost outlet clears the thread context traceID.

For the layer C, in the first step, a TraceID field is added in the structure MessageEnvelope; and secondly, the message sends a Looper, wherein the sendMessageAtTime writes the thread context TraceID into the messageEnvelope message. And thirdly, writing the TraceID in the message into the thread context before processing the handler- > Handlemessage (message). And fourthly, after the message processing handler- > handlemessage (message), clearing the thread context TraceID.

For communication mode four in table 1

The basic way to pass the TraceID during socket communication is: before sending the message: writing data in the context of the thread into a socket sending message; before message processing: setting data in the socket message into the context of the thread; after message processing: the thread's context is cleared.

It should be noted that various calls may be involved in the TraceID passing process, such as Binder synchronous call, nested Hwbinder synchronous call in case of call processing, Binder asynchronous call, Binder synchronous call, and nested msg asynchronous processing in case of call processing.

In the following embodiments of the present application, a detailed description is further made on a specific process of the log information generation method with reference to a process of synchronous call shown in fig. 9, where the specific process of the method process may include:

step a, starting call chain tracking in a certain service flow of application, generating TraceID according to the combination of the CPUID and the time stamp, and setting the TraceID into the context (tls) of the thread.

And b, synchronously calling other processes by the processes in the process through the command word binder transaction.

And step c, the process sending side acquires the current TraceID from the thread context and writes the TraceID into the context.

And d, carrying the TraceID in the transmission of the binder message BC _ TRANSACTION/BR _ TRANSACTION.

Step e, the thread 1 (i.e. Binder receiving side) of the system service acquires the TraceID from the data structure, and sets the transferred TraceID into the current thread context, and processes through the command word Binder onTransact.

Step f, thread 1 of the system service returns a result through the command word BC _ REPLY, and then clears the TraceID in the thread context.

And step g, the App side continues processing until the Trace call chain tracking is finished, and the TraceID in the thread context is cleared.

In summary, the embodiment of the present application can implement transmission of the TraceID in an Android communication mechanism (binder, hwbinder, message, socket, syscall, etc.), and can implement high performance access based on a context technology of a thread, that is, the TraceID is stored in the thread context in the process, and the related output information can be obtained from the thread context and stored in the content. Therefore, the embodiment of the application can realize the passing of the TraceID in the calling link.

Further, after the trace identifier is transferred in the call link, the electronic device obtains the trace identifier from the context of each thread, converts the trace identifier into a character string, writes the character string into the print information, generates log information, and filters the log information including the trace identifier.

Specifically, for the running water log, in order to obtain the log information corresponding to the tracking identifier through the tracking identifier, the running water log needs to be associated with the tracking system in the following manner: and in the user-state log printing interface, judging whether the TraceID in the current thread context is valid or not and whether a user-state log association switch is set or not, if so, converting the TraceID into a character string and inserting the character string into printing information. The flow log is mainly modified uniformly at the bottom layer, so that the influence on the performance is small. The current flow log bottom layer is written into logd through a socket, and a vector write writeev interface (a plurality of buffers) is adopted, so that a TraceID character string buffer is added before an information character string buffer during writing, and the socket at a receiving side is automatically spliced.

For the kernel log, in order to obtain the log information corresponding to the tracking identifier through the tracking identifier, the kernel log needs to be associated with the tracking system first, and the association method is as follows: in the kernel mode printing interface, judging whether the current system calling context (non-interrupt context) is in, whether the TraceID in the current thread context is valid or not, and whether a kernel mode log related switch is set or not, if so, converting the TraceID into a character string and inserting the character string into printing information. The kernel-mode log is uniformly modified on a bottom-layer interface, and mainly relates to the modification of a printk function.

For a performance trace log (sysstrace), the sysstrace acquires a TraceID from a thread context, and concatenates the sysstraces of the whole business process through the TraceID. In order to acquire log information corresponding to a tracking identifier through the tracking identifier, the sysstem needs to be associated with a tracking system, and the association method is as follows: in the user state sysstrace printing process, whether the TraceID in the current thread context is valid or not and whether a sysstrace associated switch is set or not are judged, and if yes, the TraceID parameter is added into output contents according to the sysstrace format specification. Wherein the sysstrace output is uniformly modified at the bottom layer as much as possible, and the efficiency is considered at the same time. At the bottom layer of the current systar output, a plurality of trace interfaces are used for writing/sys/kernel/debug/tracing/trace _ marker interfaces, a WRITE _ MSG macro interface is adopted for converting parameters into character strings, and therefore during output, according to the format required by systar, the TraceID is used as an increased args parameter and is inserted into the tail of the character strings.

Therefore, the problem of log output information association in a business process can be solved by adopting the call link tracking technology provided by the embodiment of the application. As shown in fig. 10, the identifier corresponding to the black shadow is TraceID93921d2463, and the electronic device can automatically identify log output information of a complete business process by searching the TraceID, that is, output information of a cross-process, cross-thread, and multi-level business process flow can be automatically filtered and extracted by the TraceID. The ability dependence on developers is reduced, the fault analysis efficiency is improved, and fault positioning is rapidly carried out.

In addition, the problem of relationship of sysstrace output information in a business process can be solved by adopting the call link tracking technology provided by the embodiment of the application. As in FIG. 11a, the UI Thread Binder calls transaction [35] to add the tags of Args parameter "3 f0fca1a 13", which is the same as the tags of Binder:1060_4 Thread in FIG. 11b, directly defining the cross-process Binder call relationship. That is, it can be determined by TraceID that the UI Thread binder call is mainly time consuming because of the blocking of the called process.

An embodiment of the present application further provides a log information generating method and apparatus, as shown in fig. 12, the apparatus includes a receiving module 1201 and a processing module 1202.

In a possible embodiment, the receiving module 1201 is configured to receive a first operation of a user. Relevant contents related to the embodiments of the methods in fig. 6 to 11b may be referred to the functional description of the receiving module 1101, and are not repeated herein.

A processing module 1202, configured to, in response to the first operation, add a unique trace identifier corresponding to the service at a service start entry, and pass the trace identifier through an entire call link of the service, where the entire call link includes at least one process, and the at least one process includes at least one thread; and storing the tracking identifier into a call record of each thread of each process of the call link, and generating log information comprising the tracking identifier. Relevant contents related to the embodiments of the methods in fig. 6 to 11b may be referred to the functional description of the processing module 1202, and are not repeated herein.

The switching device for the application icon of the electronic device has a function of implementing the electronic device designed by the method. The unit modules may be implemented by hardware in the terminal, or may be implemented by executing corresponding software by hardware in the terminal, which is not limited in this embodiment of the application.

Therefore, the log information including the tracking identification can be generated, so that developers can extract information related to problems conveniently, the capability requirement on the developers is reduced, and the problem solving efficiency is improved.

An embodiment of the present application further provides a computer-readable storage medium, where the computer-readable storage medium includes a computer program, and when the computer program runs on an electronic device, the electronic device is caused to execute any one of the possible implementations of the information processing method.

An embodiment of the present application further provides a computer program product, which, when running on an electronic device, enables the electronic device to execute any one of the possible implementations of the information processing method.

In other embodiments of the present application, an embodiment of the present application discloses an electronic device, which may include, as shown in fig. 13: a processor 1301; a memory 1302; and one or more computer programs 1303, which may be connected via one or more communication buses 1304.

Wherein the one or more computer programs 1303 are stored in the memory 1302 and configured to be invoked by the processor 1301 for execution, the one or more computer programs 1303 include instructions that may be used to perform the steps in the respective embodiments of fig. 6 to 11 b.

Through the above description of the embodiments, it is clear to those skilled in the art that, for convenience and simplicity of description, the foregoing division of the functional modules is merely used as an example, and in practical applications, the above function distribution may be completed by different functional modules according to needs, that is, the internal structure of the device may be divided into different functional modules to complete all or part of the above described functions. For the specific working processes of the system, the apparatus and the unit described above, reference may be made to the corresponding processes in the foregoing method embodiments, and details are not described here again.

Each functional unit in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, and can also be realized in a form of a software functional unit.

The integrated unit, if implemented in the form of a software functional unit and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solutions of the embodiments of the present application may be essentially implemented or make a contribution to the prior art, or all or part of the technical solutions may be implemented in the form of a software product stored in a storage medium and including several instructions for causing a computer device (which may be a personal computer, a server, or a network device) or a processor to execute all or part of the steps of the methods described in the embodiments of the present application. And the aforementioned storage medium includes: flash memory, removable hard drive, read only memory, random access memory, magnetic or optical disk, and the like.

The above description is only a specific implementation of the embodiments of the present application, but the scope of the embodiments of the present application is not limited thereto, and any changes or substitutions within the technical scope disclosed in the embodiments of the present application should be covered by the scope of the embodiments of the present application. Therefore, the protection scope of the embodiments of the present application shall be subject to the protection scope of the claims.

Claims

1. A log information generation method is applied to electronic equipment and is characterized by comprising the following steps:

receiving a first operation of a user;

generating a unique trace identification corresponding to a service in response to the first operation, and passing the trace identification through an entire call link of the service, wherein the entire call link includes at least one process for executing the service, the at least one process including at least one thread;

storing the tracking identifier into a call record of each thread of each process of the call link, and generating log information comprising the tracking identifier; the log information comprises at least one of a running log, a kernel log and a performance tracking log;

wherein the electronic device generates a unique trace identifier corresponding to the service and passes the trace identifier throughout the invocation link, including:

generating a unique tracking identifier corresponding to the service, and writing the tracking identifier into the context of a first thread corresponding to the service starting entrance;

communicating the trace identification from the first thread to a second thread via a communication message and writing the trace identification to a context of the second thread;

if the second thread is not the last thread of the calling link, the tracking identification is transmitted from the second thread to a third thread through a communication message, and the tracking identification is written into the context of the third thread until the tracking identification is written into the context of the last thread of the calling link.

2. The method of claim 1, wherein storing the trace identification in a call record for each thread of each process of the call chain comprises:

and storing the character string obtained by converting the tracking identifier into a calling record of each thread of each process of the calling link, and generating log information comprising the tracking identifier.

3. The method according to claim 2, wherein the electronic device stores the character string converted from the trace identifier into a call record of each process of the call link, and generates log information including the trace identifier, including:

acquiring the tracking identification from the context of each thread of the calling link;

writing the character string obtained by the conversion of the tracking identifier into a call record of each thread in each process of the call link, and generating log information including the tracking identifier.

4. The method according to any one of claims 1 to 3, wherein the log information includes a call timestamp of the thread, a call service name, and a call relationship of other threads;

the method further comprises the following steps:

calculating the calling time consumption of each thread in the calling link according to the calling time stamp;

and generating a report causing the exception of the calling link according to the calling time, the calling relation and the calling server name.

5. The method of any of claims 1 to 3, wherein the tracking identifier is generated based on an identifier of the electronic device and an occurrence time of the first operation.

6. An electronic device, characterized in that the electronic device comprises:

the receiving module is used for receiving a first operation of a user;

a processing module, configured to generate a unique trace identifier corresponding to a service in response to the first operation, and pass the trace identifier through an entire call link of the service, where the entire call link includes at least one process for executing the service, and the at least one process includes at least one thread;

the generating module is used for storing the tracking identifier into a calling record of each thread of each process of the calling link and generating log information comprising the tracking identifier; the log information comprises at least one of a running log, a kernel log and a performance tracking log;

wherein the processing module is specifically configured to:

7. The electronic device of claim 6, wherein the processing module is specifically configured to:

8. The electronic device of claim 7, wherein the generation module is specifically configured to:

9. The electronic device according to any one of claims 6 to 8, wherein the log information includes a call timestamp of the thread, a call service name, and a call relationship of other threads;

the device further comprises:

10. The electronic device of any of claims 6-8, wherein the tracking identifier is generated based on an identifier of the electronic device and an occurrence time of the first operation.

11. An electronic device comprising one or more processors and one or more memories;

the one or more memories coupled with the one or more processors for storing computer program code comprising computer instructions which, when executed by the one or more processors, cause the electronic device to perform the log information generation method of any of claims 1 to 5.

12. A computer-readable storage medium, characterized in that the computer-readable storage medium includes a computer program which, when run on an electronic device, causes the electronic device to execute the log information generating method according to any one of claims 1 to 5.