Log management method and electronic device

Abstract

Embodiments of the present application apply to the technical field of information processing, and provide a log management method and an electronic device. In the case that the electronic device receives a log structure body issued by a log driver, if log information of a first log structure body is the same as log information of a second log structure body in a cache pool, a timestamp of the first log structure body is added to the second log structure body to obtain a merged second log structure body; wherein the first log structure body is any log structure body issued by the log driver, and the second log structure body is any log structure body in the cache pool. Then, in the case that a preset condition is met, multiple log structure bodies in the cache pool are written into a socket buffer. In the present application, repeated log files can be merged into one log file, which can improve the aggregation degree of the log file while saving the storage resources of the electronic device, and further improve the storage efficiency of the log structure body.

Description

Technical Field

[0001] This application relates to the field of information processing technology, and in particular to a log management method and electronic device. Background Technology

[0002] With the continuous development of electronic devices, such as mobile phones, they have gradually become indispensable daily necessities. People can use electronic devices to watch videos, read news, and so on. During the use of electronic devices, a large amount of log data is generated. This log data is generally stored in a log buffer. If the remaining space in the log buffer is insufficient, the electronic device will be unable to store new log data, resulting in log data loss. This may prevent the electronic device from accurately using the log data for problem analysis. Summary of the Invention

[0003] This application provides a log management method and electronic device to solve the problem of some logs being lost due to excessive log printing, thereby reducing the probability of log loss.

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

[0005] Firstly, a log management method is provided, applied to an electronic device equipped with a first application. In this method, the electronic device receives a log structure from a log driver, where the log structure corresponds to the log file generated by the first application. If the log information of the first log structure is identical to the log information of a second log structure in a cache pool, the timestamp of the first log structure is added to the second log structure to obtain a merged second log structure. Here, the first log structure can be any log structure issued by the log driver, and the second log structure can be any log structure in the cache pool. Then, under preset conditions, multiple log structures from the cache pool are written to a socket buffer.

[0006] In this embodiment, if the log information of the first log structure is the same as the log information of the second log structure in the cache pool, it indicates that the first log structure is a duplicate log. Therefore, the timestamp of the first log structure can be added to the second log structure. In this way, duplicate log files can be merged into one log file, which can save electronic device storage resources, improve the aggregation of log files, provide storage space for subsequently generated log files, reduce the occurrence of log loss due to insufficient storage space of electronic devices, reduce the log loss rate, and improve the storage efficiency of log files. In addition, the log structure in the cache pool is only sent to the socket buffer when preset conditions are met. In this way, the storage resources of electronic devices can be saved to the greatest extent and the storage space of logs can be increased.

[0007] In one possible implementation of the first aspect, the method further includes: if the log information of the first log structure is different from the log information of all log structures in the cache pool, storing the first log structure in the cache pool; wherein, during the configuration of the cache pool, the cache pool does not contain log structures.

[0008] In this embodiment, if the log information of the first log structure is different from the log information of all log structures in the cache pool, it indicates that the first log structure is a new log. Therefore, in order to facilitate subsequent log analysis, the electronic device can store the first log structure in the cache pool. This can improve the accuracy of log analysis results and reduce the occurrence of log results being affected by missing log files.

[0009] In one possible implementation of the first aspect, the aforementioned log information includes at least one of the following: log name, process ID / thread ID, log priority, log tag, and log content.

[0010] In one possible implementation of the first aspect, the log information of the merged second log structure includes at least one of the following: log name, process ID / thread ID, log priority, log tag, log content, log repetition count, and a timestamp linked list. The timestamp linked list includes timestamps from log structures with the same log information as the second log structure.

[0011] In one possible implementation of the first aspect, the aforementioned preset conditions include the cache duration of the cache pool reaching a preset cache time; and / or, the data volume of all log structures in the cache pool reaching a preset data volume.

[0012] In this embodiment, if the cache duration of the cache pool reaches the preset cache time, it indicates that the log file has been stored in the cache area for a long time. Therefore, writing multiple log structures from the cache pool into the socket buffer can prevent the logs from being unanalyzable in a timely manner due to excessive log storage time, thus improving the timeliness of log analysis. If the data volume of all log structures in the cache pool reaches the preset data volume, it indicates that the cache area has no remaining memory space. Therefore, writing multiple log structures from the cache pool into the socket buffer can prevent the subsequent loss of log files, maximize the conservation of electronic device storage resources, and increase log storage space.

[0013] In one possible implementation of the first aspect, the above method further includes: if the cache duration of the cache pool has not reached the preset cache time, the electronic device can continue to receive the log structure issued by the log driver.

[0014] In this embodiment of the application, if the caching time of the cache pool does not reach the preset caching time, it indicates that the log files in the cache pool have been stored in the cache pool for a short time. Therefore, the electronic device can continue to receive the log structure issued by the log driver so as to merge the duplicate log structures in the future and improve the aggregation degree of the logs.

[0015] In one possible implementation of the first aspect, the method further includes: if the total amount of data in all log structures in the cache pool does not reach the preset amount of data, determining whether the length of the logs in the cache pool is greater than the preset log length.

[0016] In this embodiment of the application, if the log cache capacity corresponding to the cache area does not exceed the preset cache capacity, it indicates that although there are log file timeouts in the cache area, there is still free memory space. Therefore, in order for the non-blocking socket buffer to store more log files, the electronic device can determine whether the log length in the cache pool is greater than the preset log length, so as to compress the log structure whose log length is less than the preset log length, thereby maximizing the saving of socket buffer storage resources.

[0017] In one possible implementation of the first aspect, the process of writing multiple log structures from the cache pool into the socket buffer may specifically include: if the log length of the third log structure is greater than or equal to the preset log length, the third log structure is written into the socket buffer, wherein the third log structure is any log structure among the multiple log structures that has not been written into the socket buffer.

[0018] In this embodiment, if the log length of the third log structure is greater than or equal to the preset log length, it indicates that the third log structure is a long log. Therefore, the third log structure can be directly written into the socket buffer, which can improve the sending efficiency of the log structure and reduce the waste of resources caused by unnecessary log merging.

[0019] In one possible implementation of the first aspect, the method further includes: if the log length of the third log structure is less than the preset log length, merging the third log structure with one or more fourth log structures until the length of the merged log structure is greater than or equal to the preset log length, and writing the merged log structure into the socket buffer, wherein the fourth log structure is a log structure located after the third log structure that has not been written into the socket buffer.

[0020] In this embodiment, if the log length of the third log structure is less than the preset log length, it indicates that the third log structure is a short log. Therefore, in order to improve the log storage efficiency of the buffer, the third log structure can be merged with one or more fourth log structures until the length of the merged log is greater than or equal to the preset log length, that is, until the merged log structure is a long log, the merged log structure is written to the socket buffer. In this way, multiple short log files can be merged into one long log file, which can not only save mobile phone storage resources and improve log aggregation, reduce the probability of log loss, but also reduce the occurrence of IO resource consumption due to sending log files to the socket buffer multiple times, and increase the frequency of IO resource calls.

[0021] In one possible implementation of the first aspect, the process of merging the above-mentioned log structures may specifically include: merging the contents of one or more fourth log structures that are different from the third log structure into the third log structure.

[0022] In this embodiment, if the log length of the third log structure is less than the preset log length, the content in the fourth log structure that is different from the third log structure is merged into the third log structure. In this way, the log storage efficiency of the socket buffer can be maximized while avoiding the merged log length being too long, reducing the occurrence of log loss due to insufficient storage space of electronic devices, and providing more storage space for the log structures to be issued later.

[0023] In one possible implementation of the first aspect, the process of merging the aforementioned log structures may specifically include: if the log length of the third log structure is less than a preset log length, merging the third log structure with the next log structure following the third log structure to obtain a candidate log file; wherein, the third log structure is a log file in the buffer whose log length is less than the preset log length. Then, if the log length corresponding to the candidate log file is less than the preset log length, the candidate log file is used as the third log structure, and the process returns to the step of "merging the third log structure with the next log structure following the third log structure to obtain a candidate log file," until the log length corresponding to the candidate log file is not less than the preset log length, and the merged log structure is written to the socket buffer.

[0024] In one possible implementation of the first aspect, the method further includes: determining the arrangement order of the log structures by sorting the storage times corresponding to each log structure in the cache according to a preset order. Then, based on the arrangement order of the log structures, a fourth log structure is determined.

[0025] In one possible implementation of the first aspect, after writing multiple log structures from the cache pool into the socket buffer, the method further includes: reconfiguring the cache pool according to preset cache information; wherein the preset cache information includes preset cache time and / or preset data volume.

[0026] In one possible implementation of the first aspect, the method further includes: reconfiguring a timer when the preset cache information includes a preset cache time; wherein the timer is used to record the time when the log file is stored in the cache pool.

[0027] In this embodiment of the application, after sending multiple log structures in the cache pool, the mobile phone can reset the cache area and timer, providing a basis for storing log files in the cache area subsequently.

[0028] In one possible implementation of the first aspect, upon receiving a log structure issued by the log driver, if the first application is the first application to issue a log file, the cache pool is initialized and configured according to preset cache information; wherein, the preset cache information includes preset cache time and / or preset data volume.

[0029] In this embodiment of the application, after obtaining the above-mentioned log structure, the electronic device can determine whether to initialize the cache. If the electronic device does not initialize the cache, it indicates that the current application process is generating a log file for the first time. Therefore, the electronic device can initialize the cache. If the electronic device has already initialized the cache, it indicates that the current application or process is not generating a log file for the first time. Therefore, the electronic device does not need to initialize the cache to avoid unnecessary waste of resources.

[0030] In one possible implementation of the first aspect, the method further includes: initializing and configuring a timer when the preset cache information includes a preset cache time; wherein the timer is used to record the time when the log file is stored in the cache pool.

[0031] In this embodiment, if the preset cache information includes a preset cache time, it indicates that the mobile phone needs to obtain the log cache time. Therefore, the mobile phone can configure a timer to determine the storage time of the log file, thus providing a basis for subsequently determining the log cache time of the cache pool. Furthermore, since electronic devices may experience delays between log generation and log storage times due to lag or other reasons, in order to accurately calculate the log file cache time, in this embodiment, the electronic device can directly obtain the log file storage time through a timer.

[0032] In one possible implementation of the first aspect, the method further includes: sending the log structure in the socket buffer to the logging module. Then, the log structure received by the logging module is restored to obtain an initial log structure; wherein the initial log structure is the structure corresponding to the log file generated by the first application and not yet merged.

[0033] In this embodiment of the application, if the log structure is sent to the log recording module, the electronic device can parse the received log structure so that the merged log structure can be restored. This facilitates subsequent analysis of the log file and improves log analysis efficiency.

[0034] In one possible implementation of the first aspect, the method further includes: compressing the log file with the highest log traffic based on the log traffic corresponding to the log files in the buffer, to obtain a compressed log file. Then, the structure corresponding to the compressed log file is written into the socket buffer.

[0035] In this embodiment, not only can duplicate log files and log files with a small number of characters be merged, but log files with a large log volume can also be compressed. In this way, the aggregation degree of log files can be maximized, the waste of storage resources can be reduced, and the storage efficiency of the socket buffer can be improved.

[0036] In one possible implementation of the first aspect, the method further includes: compressing log files with higher priority based on their log priorities in the buffer to obtain compressed log files. Then, the structure corresponding to the compressed log file is written into the socket buffer.

[0037] In this embodiment, not only can duplicate log files and log files with a small number of characters be merged, but log files with high log priority can also be compressed. In this way, the aggregation degree of log files can be maximized, the waste of storage resources can be reduced, and the storage efficiency of the socket buffer can be improved.

[0038] In a second aspect, this application provides an electronic device, the electronic device including a memory and one or more processors; the memory and the processors are coupled; the memory is used to store computer program code, the computer program code including computer instructions; when the processor executes the computer instructions, the electronic device performs the method described above.

[0039] Thirdly, this application provides a computer-readable storage medium including computer instructions that, when executed on an electronic device, cause the electronic device to perform the method described above.

[0040] Fourthly, this application provides a computer program product that, when run on an electronic device, causes the electronic device to perform the method described above.

[0041] Fifthly, a chip is provided, comprising: an input interface, an output interface, a processor, and a memory, wherein the input interface, the output interface, the processor, and the memory are connected via an internal connection path, and the processor is used to execute code in the memory, wherein when the code is executed, the processor is used to execute the method described above.

[0042] The beneficial effects that the electronic device described in the second aspect, the computer-readable storage medium described in the third aspect, the computer program product described in the fourth aspect, and the chip described in the fifth aspect can achieve can be referred to the beneficial effects of the first aspect and any of its possible design embodiments, and will not be repeated here. Attached Figure Description

[0043] Figure 1 This application provides a schematic diagram of the structure of a log system according to an embodiment of the present application.

[0044] Figure 2 A schematic diagram of a news interface that a user swipes up on, provided as an embodiment of this application;

[0045] Figure 3 A schematic diagram of an interface for entering the initial interface of a video application, provided as an embodiment of this application;

[0046] Figure 4 A schematic diagram illustrating the display of multiple duplicate logs provided in an embodiment of this application;

[0047] Figure 5 A schematic diagram illustrating the display of multiple short logs provided in an embodiment of this application;

[0048] Figure 6 A schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application;

[0049] Figure 7 A schematic diagram of the software structure of an electronic device provided in an embodiment of this application;

[0050] Figure 8 This is a schematic diagram of another log system provided in an embodiment of this application;

[0051] Figure 9 A flowchart illustrating a log management method provided in an embodiment of this application;

[0052] Figure 10 This application provides a schematic diagram of the structure of a log structure table corresponding to a log file.

[0053] Figure 11 This is a schematic diagram of a log structure provided in an embodiment of this application;

[0054] Figure 12 A flowchart illustrating another log management method provided in this application embodiment;

[0055] Figure 13 This application provides a schematic diagram of the structure of a timestamp chain in a log structure.

[0056] Figure 14 This is a schematic diagram illustrating the merging of duplicate logs as provided in an embodiment of this application;

[0057] Figure 15 This application provides a schematic diagram of the structure of a log structure table corresponding to a reconstructed log file.

[0058] Figure 16 A schematic diagram illustrating another method of merging duplicate logs provided in this application embodiment;

[0059] Figure 17 This is a schematic diagram illustrating the addition of duplicate logs to a cache area, as provided in an embodiment of this application.

[0060] Figure 18 A schematic diagram illustrating the merging of short logs in a cache area, provided as an embodiment of this application;

[0061] Figure 19 This is a schematic diagram of merging short logs in another cache area provided in an embodiment of this application. Detailed Implementation

[0062] The technical solutions of the embodiments of this application will be described below with reference to the accompanying drawings. In the description of this application, unless otherwise stated, "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone, where A and B can be singular or plural. Furthermore, in the description of this application, unless otherwise stated, "multiple" refers to two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple. Additionally, to facilitate a clear description of the technical solutions of the embodiments of this application, the terms "first" and "second" are used in the embodiments of this application to distinguish identical or similar items with essentially the same function and effect. Those skilled in the art will understand that the terms "first," "second," etc., do not limit the quantity or order of execution, and that "first," "second," etc., are not necessarily different. Furthermore, in the embodiments of this application, words such as "exemplary" or "for example" are used to indicate that something is being used as an example, illustration, or description. Any embodiment or design scheme described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner for ease of understanding.

[0063] In some embodiments, electronic devices can use a logging system to distribute, store, and analyze log files (or log data). For example, such as... Figure 1As shown, the logging system can include a system / log (liblog) library, a socket buffer, and a logd module. The system / log library is used to send and receive log files and can be invoked by any process. The socket buffer is used to receive log files sent by the system / log library. The logd module is the core process of this logging system; it is used to store and manage log files.

[0064] The aforementioned system / logging library includes a log delivery driver (logger_write), a log delivery interface (logd_writer), a log reading driver (logger_read), and a log reading interface (logd_reader). The log delivery driver controls the log delivery interface to send log files. The log delivery interface is used to send log files. The log reading driver enables the log reading interface to establish communication connections with the xlogcat / logcatz module and the logcat module. The log delivery interface is used to send log files and log read requests.

[0065] The aforementioned socket buffer includes the logdw, logdr, and logd node files. The logdw node file stores log files sent by the aforementioned log distribution interface. The logdr node file stores log files sent by the logd module. The logd node file stores log read requests sent by the aforementioned log read interface.

[0066] In this embodiment, the aforementioned socket buffer is generally set to non-blocking mode. This non-blocking mode means that when the socket buffer has no memory space to store log files, it can reject log files that cannot be stored in it. In other words, the socket buffer will refuse to write new log files. Therefore, if the frequency of log file transmission is too high, the frequency of log reception in the socket buffer may exceed the frequency of log transmission. That is, the number of logs received by the socket buffer may be greater than the number of logs transmitted, leading to the socket buffer becoming full and unable to receive new log files, resulting in log file loss. It is understandable that if log files are lost, it may be impossible to analyze the lost log files, which may prevent timely problem resolution and ultimately affect the user experience.

[0067] The aforementioned `logd` module includes a log listener, a log buffer, a log reader, and a command listener. The log listener is a log collection client provided by the log service for quick access to the service. The log reader reads log files from the buffer. The command listener listens for log read requests in the `logd` node files. The log buffer can include a main buffer, a system buffer, a crash buffer, and an event buffer. The main buffer stores application-related logs, the system buffer stores logs related to system calls and the system framework, the crash buffer stores logs related to system failures such as system freezes (high-priority logs), and the event buffer stores logs corresponding to upper-layer calls to system event-related interfaces. For example, taking a user swiping the display interface of an electronic device as an example, the `logd` module can store this swipe event in the event buffer. It should be noted that different areas correspond to different interfaces; by calling the corresponding interface, the log files within that area can be parsed.

[0068] Specifically, applications (or upper-layer applications) in electronic devices can call the log delivery driver in the system / logging library via Java, C, or C++ to send log files to the `logdw` node file in the non-blocking socket buffer through the log delivery interface. This log file is represented as a log structure. Then, the log listener in the `logd` module listens for log files in the `logdw` node file. Subsequently, when the log listener detects a log file in the non-blocking socket buffer, it sends that log file to the log buffer.

[0069] In some embodiments, if the logcat module wants to retrieve the aforementioned log file, it can call the log reading driver and invoke the log reading interface to send a log reading request (or log reading command) to the logd node file in the non-blocking socket buffer. Subsequently, if the command listener in the logd module detects that the logd node file contains the log reading request, the aforementioned log buffer receives the log reading request from the logd node file. Then, the log reader in the logd module parses the log file by calling the interface corresponding to the log file. The log reader can then send the parsed log file to the logdr node file in the non-blocking socket buffer. Subsequently, if the logdr node file receives the log file, it sends the log file to the log reading driver through the log reading interface in the system / log library. Finally, the log reading driver can send the log file to the logcat module to retrieve the log file.

[0070] It should be noted that, Figure 1 The xlogcat / logcatz module is a log write service. This service stores the log files in the log buffer to prevent them from being cleared due to power failure, restart, or other reasons. In other words, the xlogcat / logcatz module can be used to back up the log files in the log buffer to prevent them from being lost.

[0071] In some embodiments, during a user's use of an electronic device (such as a mobile phone), the application processes within the device may generate a large amount of log data (or log files) frequently due to various reasons (such as the user swiping the screen). In other words, the aforementioned logging system will generate a large amount of log data. The electronic device can then perform log analysis based on this large amount of log data.

[0072] Taking mobile phones as an example, for instance... Figure 2 As shown, the phone is displaying news content corresponding to News 1 through News 5. Users can swipe up on the currently displayed news page according to their needs. Afterwards, the phone will display the page corresponding to News 2 through News 6 based on the user's upward swipe. It can be understood that during the user's upward swipe, the phone generates a large amount of log data based on the changes in the touch position of the swipe.

[0073] Taking mobile phones as an example, for instance... Figure 3As shown, the phone displays the main interface, which includes icons and names of multiple apps. Users can click on any app icon on the main interface according to their needs, such as clicking the video app icon 11. In response to the user's click, the phone can display the initial interface 12 of the video app, which displays the cover images corresponding to multiple videos. It's understandable that if the phone cannot display the initial interface of the video app in a timely manner after receiving the user's click, i.e., the phone experiences page lag, it will generate a large number of error logs to facilitate subsequent problem analysis.

[0074] It is understandable that if the application process sends too much log data, it will cause the log data to occupy too much storage space (such as local memory space, cloud storage space, etc.). This will not only cause excessive waste of storage resources, but also, due to the large number of logs, critical log data may be diluted, which is not conducive to subsequent problem analysis based on log data, and thus cannot solve problems in a timely manner.

[0075] In one example, such as Figure 4 As shown, taking four log files from the aforementioned large number of log files as examples, the log information for log file 1 is "06-14 14:50:02.410 2662 6377IPCUtils:IS_ASSIST_MODE is:false", the log information for log file 2 is "06-14 14:50:02.411 2662 6377IPCUtils:IS_ASSIST_MODE is:false", the log information for log file 3 is "06-14 14:50:02.411 2662 6377IPCUtils:IS_ASSIST_MODE is:false", and the log information for log file 4 is "06-14 14:50:02.411 2662 6377IPCUtils:IS_ASSIST_MODE is:false". These four log files show that, apart from the timestamps, all other log information is identical. In other words, the duplicate log files contain the same information except for their corresponding timestamps. Therefore, storing these duplicate log files sequentially in the socket buffer would not only consume significant transmission resources but also waste storage resources. Consequently, subsequent useful log files would be unavailable for storage, making log analysis impossible.

[0076] In another example, such as Figure 5As shown, taking three log files from a large number of log files as an example, log file A contains the log information "06-14 14:50:02.419 29536 29536I BaseActivity:onCreate", log file B contains the log information "06-14 14:50:02.420 29536 29536I BaseActivity:onCreateCommon", and log file C contains the log information "06-14 14:50:02.420 29536 29536IBaseActivity:addWindowFlags". From these three log files, it can be seen that, apart from the timestamp and log content, the remaining log information is identical. In other words, in the shorter log file, all log information except for the timestamp and log content is repeated. Therefore, storing each short log file as an independent log file sequentially in the socket buffer would not only consume a lot of transmission resources, but also waste storage resources, thus preventing the storage of subsequent useful log files and making it impossible to perform log analysis based on those useful log files in a timely manner.

[0077] However, according to the above Figure 4 as well as Figure 5 As can be seen from the log files, the large number of log files issued by the application processes in the aforementioned electronic device may have characteristics of information redundancy and short character length. That is, these large number of log files may include some duplicate log files and log files with short strings. Among them, the duplicate log files are generated by calling log printing in the loop execution process. Therefore, in order to solve the above-mentioned log file loss problem, this application embodiment provides a log management method and electronic device. In this method, the electronic device obtains log files, wherein the log files are files generated by the application processes in the electronic device. Then, if the log files meet the preset log conditions, the electronic device performs log merging on the log files to obtain a target log file. The preset log conditions are that the log file meets the preset log conditions if there is a log file with the same log information as the log file in the buffer (or buffer pool) and / or the log length of the corresponding log file is less than the preset log length. Then, the electronic device sends the target log file to the socket buffer, wherein the socket buffer is used to send the target log file to the logd module, and the logd module is used to store and manage logs.

[0078] In this embodiment, the electronic device can process duplicate log files and short log files separately to obtain reconstructed log files. In this way, not only can duplicate log files be merged, but multiple short log files can also be merged into a long log file, thereby improving the aggregation degree of log files, reducing the waste of storage resources, and reducing the probability of losing useful log files, thus providing a foundation for subsequent log file analysis.

[0079] For example, the aforementioned electronic device can be any embedded electronic device capable of high-frequency log printing, such as mobile phones, tablets, laptops, desktop computers, watches, in-vehicle devices, etc. This application embodiment does not impose any restrictions on the specific type of electronic device.

[0080] Figure 6 This is a schematic diagram of the hardware structure of the electronic device 100 provided in the embodiments of this application, as shown below. Figure 6 As shown, the electronic device 100 may include a processor 110, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an external memory interface 120, an internal memory 121, etc.

[0081] It is understood that the structures illustrated in the embodiments of the present invention do not constitute a specific limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0082] Processor 110 may include one or more processing units, such as: application processor (AP), modem processor, graphics processing unit (GPU), image signal processor (ISP), controller, memory, video codec, digital signal processor (DSP), baseband processor, and / or neural network processing unit (NPU), etc. Different processing units may be independent devices or integrated into one or more processors.

[0083] The controller can be the nerve center and command center of the electronic device 100. The controller can generate operation control signals according to the instruction opcode and timing signals to complete the control of fetching and executing instructions.

[0084] The processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. This memory can store instructions or data that the processor 110 has just used or that are used repeatedly. If the processor 110 needs to use the instruction or data again, it can retrieve it directly from the memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0085] In some embodiments, the processor 110 may include one or more interfaces. Interfaces may include inter-integrated circuit (I2C) interfaces, inter-integrated circuit sound (I2S) interfaces, pulse code modulation (PCM) interfaces, universal asynchronous receiver / transmitter (UART) interfaces, mobile industry processor interfaces (MIPI), general-purpose input / output (GPIO) interfaces, etc.

[0086] The I2S interface can be used for audio communication. The PCM interface can also be used for audio communication, sampling, quantizing, and encoding analog signals.

[0087] The wireless communication function of electronic device 100 can be realized through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor and baseband processor, etc.

[0088] Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in electronic device 100 can be used to cover one or more communication frequency bands. Different antennas can also be multiplexed to improve antenna utilization. For example, antenna 1 can be multiplexed as a diversity antenna for a wireless local area network. In some other embodiments, the antennas can be used in conjunction with tuning switches.

[0089] The mobile communication module 150 can provide solutions for wireless communication, including 2G / 3G / 4G / 5G, applied to the electronic device 100. The mobile communication module 150 may include at least one filter, switch, power amplifier, low noise amplifier (LNA), etc. The mobile communication module 150 can receive electromagnetic waves via antenna 1, and perform filtering, amplification, and other processing on the received electromagnetic waves before transmitting them to a modem processor for demodulation. The mobile communication module 150 can also amplify the signal modulated by the modem processor and convert it into electromagnetic waves for radiation via antenna 1. In some embodiments, at least some functional modules of the mobile communication module 150 may be housed in the processor 110. In some embodiments, at least some functional modules of the mobile communication module 150 and at least some modules of the processor 110 may be housed in the same device.

[0090] The wireless communication module 160 can provide solutions for wireless communication applications on the electronic device 100, including wireless local area networks (WLAN) (such as Wi-Fi), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), and infrared (IR). The wireless communication module 160 can be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via antenna 2, performs frequency modulation and filtering of the electromagnetic wave signals, and sends the processed signal to processor 110. The wireless communication module 160 can also receive signals to be transmitted from processor 110, perform frequency modulation and amplification, and convert them into electromagnetic waves for radiation via antenna 2. In some embodiments, at least some functional modules of the wireless communication module 160 can be housed within processor 110.

[0091] It is understood that the interface connection relationships between the modules illustrated in the embodiments of the present invention are merely illustrative and do not constitute a structural limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may also employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.

[0092] The external storage interface 120 can be used to connect an external storage card, such as a Micro SD card, to expand the storage capacity of the electronic device 100.

[0093] Internal memory 121 can be used to store computer executable program code, which includes instructions. Processor 110 executes various functional applications and data processing of electronic device 100 by running the instructions stored in internal memory 121. Internal memory 121 may include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback, image playback, etc.), etc. The data storage area may store data created during the use of electronic device 100 (such as audio data, phonebook, etc.).

[0094] In some embodiments, the aforementioned storage data area may also store log files generated by applications or processes during the use of the electronic device 100. For example, the storage data area may include a cache pool for storing short-term log structures, that is, log structures whose log storage time is less than a preset storage time.

[0095] In addition, the internal memory 121 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc.

[0096] For example, the software system of the aforementioned electronic device 100 can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. This embodiment of the invention uses the layered architecture Android system as an example to illustrate the software structure of the electronic device 100.

[0097] Figure 7 This is a software structure block diagram of an electronic device 100 according to an embodiment of this application.

[0098] A layered architecture divides software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, the Android system is divided into four layers, from top to bottom: the application layer (application layer), the application framework layer (framework layer), the Android runtime and system libraries, and the kernel layer (or driver layer). The application layer can include a series of application packages.

[0099] The application layer can include a series of application packages. This application layer can include multiple application packages. For example... Figure 7 As shown, this application package can include applications such as camera, calendar, map, WLAN, music, SMS, gallery, call, navigation, Bluetooth, and video.

[0100] The application framework layer provides application programming interfaces (APIs) and a programming framework for applications in the application layer. The application framework layer includes some predefined functions. For example... Figure 7 As shown, the application framework layer may include a window manager, content provider, phone manager, resource manager, notification manager, package manager, etc.

[0101] The window manager is used to manage windowed applications. It can retrieve screen size, determine the presence of a status bar, lock the screen, and capture screenshots, among other things.

[0102] Content providers store and retrieve data, making that data accessible to applications. This data may include videos, images, audio, made and received phone calls, browsing history and bookmarks, phone books, etc.

[0103] The phone manager is used to provide communication functions for electronic device 100. For example, it manages call status (including connection and disconnection).

[0104] The file explorer provides applications with various resources, such as localized strings, icons, images, layout files, video files, and more.

[0105] The notification manager allows applications to display notifications in the status bar. These notifications can be used to deliver informational messages and can disappear automatically after a short pause, requiring no user interaction. For example, the notification manager can be used to notify users of completed downloads or message alerts. The notification manager can also display notifications as icons or scrolling text in the top status bar, such as notifications from background applications, or as dialog boxes on the screen. Examples include displaying text messages in the status bar, emitting sounds, vibrating electronic devices, and flashing indicator lights.

[0106] The package manager is used to manage information about applications installed in the system, as well as to query information about individual installation packages and applications with hidden icons.

[0107] The Android runtime consists of core libraries and a virtual machine. The Android runtime is responsible for scheduling and managing the Android system.

[0108] The core library consists of two parts: one part is the functionalities that need to be called by the Java language, and the other part is the Android core library.

[0109] The application layer and application framework layer run in a virtual machine. The virtual machine executes the Java files of the application layer and application framework layer as binary files. The virtual machine is used to perform functions such as object lifecycle management, stack management, thread management, security and exception management, and garbage collection.

[0110] The system library can include multiple functional modules. Examples include: a surface manager, media libraries, 3D graphics processing libraries (e.g., OpenGL ES), a logging library, the `logd` module, and the `logcat` module. The logging library is used to send and receive log files. This library can include a log delivery driver, a log delivery interface, a log reading driver, a buffer, and a log reading interface.

[0111] The Surface Manager is used to manage the display subsystem and provides the blending of 2D and 3D layers for multiple applications.

[0112] The media library supports playback and recording of various common audio and video formats, as well as still image files. It supports multiple audio and video encoding formats, such as MPEG4, H.264, MP3, AAC, AMR, JPG, and PNG.

[0113] The 3D graphics processing library is used to implement 3D graphics drawing, image rendering, compositing, and layer processing.

[0114] The log delivery driver is used to deliver log files. Specifically, through this log delivery driver, the log file can be sent to a non-blocking socket buffer.

[0115] The log delivery interface is used to send log files. Specifically, calling this log delivery interface will send the log file to the buffer.

[0116] The log reading driver is used to read log files. Specifically, through this log reading driver, the log file can be sent to the logcat module to obtain the log file.

[0117] The log reading interface is used to send log files. Specifically, calling this log sending interface can send the log file in the non-blocking socket buffer to the logcat module.

[0118] The buffer is used to temporarily store log files. Specifically, when a log file is received from the log delivery interface, the buffer can store that log file.

[0119] The logd module is used to manage and store log files. Specifically, it stores the log file when it detects that a log file is stored in the non-blocking socket buffer.

[0120] The logcat module is used to retrieve log files.

[0121] The kernel layer is the layer between hardware and software. At a minimum, the kernel layer includes display drivers, camera drivers, audio drivers, and non-blocking socket buffers. Specifically, the non-blocking socket buffer is used to store log files; it receives log files sent from the buffer. This non-blocking socket buffer can include logdw, logdr, and logd node files.

[0122] In some embodiments, electronic devices can compress and reassemble log files using a cache in the system library to reduce the occurrence of log loss. For example... Figure 8 As shown, an electronic device (or an application or process within the electronic device) can use Java, C, or C++ to call the log delivery driver in the system / logging library to deliver log files. The electronic device can then send the log files to the buffer via the log delivery interface. Subsequently, if the log file's buffering time exceeds a preset buffering time and / or the number of log files in the buffer exceeds a preset buffer limit, the electronic device will send the log files from the buffer to a non-blocking socket buffer. Then, the log listener in the logd module can receive the log files sent from the non-blocking socket buffer if it detects that the logdw node file in the non-blocking socket buffer contains log files.

[0123] Subsequently, if the logcat module wants to retrieve the aforementioned log file, it can use the log reading driver to call the log reading interface and send the log reading request to the logd node file in the non-blocking socket buffer. Then, if the command listener in the logd module detects that the logd node file contains the log reading request, the aforementioned log buffer receives the log reading request from the logd node file. Next, the log reader in the logd module parses the log file by calling the interface corresponding to the log file. The log reader can then send the parsed log file to the logdr node file in the non-blocking socket buffer. If the logdr node file receives the log file, it sends the log file to the log reading driver through the log reading interface in the system / log library. Finally, the log reading driver sends the log file to the logcat module.

[0124] The log management method of this application embodiment can be applied to scenarios where logs are printed frequently (such as logs recording the position of a user's finger swiping the screen, or a large number of error logs printed due to system lag, etc.). The method of this application embodiment will be described below using a mobile phone as an example of an electronic device. Specifically, as... Figure 9 As shown, the log management method may include S801 to S810.

[0125] S801, mobile phone retrieves log files.

[0126] The log file, issued by the log driver, records the operational status of the phone's hardware, software, and system. This means the phone can use the log file to determine if there are any problems with its hardware, software, or system. For example, if the phone experiences lag or crashes, it can analyze the log file to assess its operating status and thus determine the cause of the malfunction. For instance, if a user clicks on... Figure 3 The video application icon 11 shown indicates that if the phone cannot respond to the user's click in a timely manner, meaning the phone needs to wait for a period of time before displaying the initial interface of the video application (e.g., ...). Figure 3 The interface shown in 12) indicates that the phone is experiencing page lag. Therefore, the phone can analyze the cause of the page lag based on the obtained log file.

[0127] It should be noted that the log files mentioned above are generated by the application process (or primary application) on the phone during system runtime. A process is an instance of a program currently running on the phone.

[0128] Specifically, the aforementioned log file may include at least one of the following: log name (logId), process ID / thread ID (tid / pid), timestamp (timespec), log priority (priority), log tag (tag), and log content (msg). The log name is one of the above... Figure 1 The name of the region corresponding to the middle buffer. For example, if the log file is related to an application (such as a video app), then the log name of the log file would be log_id_main. It should be noted that the default log name for the log file is log_id_main.

[0129] The log priorities mentioned above can include verbose (V), debug (D), info (I), warning (W), error (E), and fatal (F). These log priorities characterize the importance of the log file; the higher the priority, the more important the log file. Specifically, log files with priority V are less important than those with priority D, which is less important than those with priority I, which is less important than those with priority W, which is less important than those with priority E, and which is less important than those with priority F. In other words, log files with priority F are the most important.

[0130] For example, as described above Figure 4 Taking log file 1 as an example, let's analyze log file 1 and get the following results: Figure 10 The log structure table is shown below. Specifically, the process ID / thread ID corresponding to log file 1 is 2662 / 6377, the timestamp corresponding to log file 1 is 06-14 14:50:02.410, the log priority corresponding to log file 1 is I, the log tag corresponding to log file 1 is PCUtils, and the log content corresponding to log file 1 is IS_ASSIST_MODE is:false. It can be understood that since log file 1 does not display a log name, the phone can default to the log name for log file 1 as log_id_main.

[0131] In this application, the storage unit for the aforementioned log file is an array of structures. That is, the log file is distributed via the log driver and log interface in the form of log structures. This log structure (or first log structure) can include multiple sub-log structures (iovec), and each distributed log structure encapsulates the starting address of a memory block and the log length. For example, as shown... Figure 11 As shown, the log structure includes two member variables: a pointer variable (iov_base) and a length variable (iov_len). The pointer variable points to the starting address of the log file, and the length variable represents the log length of the file.

[0132] In one example, Figure 10 In this context, nr represents the total number of sub-log structures in the log file, for example, Figure 10In the log file 1, the corresponding nr is 4. Among them, iovec[0] is the first sub-log structure (or the header sub-structure), iovec[1] is the second sub-log structure, and iovec[nr-1] is the last sub-log structure, which is the fourth sub-log structure. It should be noted that the header sub-structure corresponding to the log file in the native logging system includes the log name, process ID / thread ID, and timestamp. After that, each log file's other sub-structures correspond to a structure type (or member variable), that is, iovec[1] corresponds to the log priority of the log file, iovec[2] corresponds to the log tag of the log file, and iovec[3] corresponds to the log content of the log file. For example, taking the above log file 1 as an example, the iovec[0] corresponding to log file 1 includes "06-14 14:50:02.410 2662 / 6377", the iovec[1] corresponding to log file 1 includes "I", the iovec[2] corresponding to log file 1 includes "PCUtils", and the iovec[3] corresponding to log file 1 includes "IS_ASSIST_MODEis:false".

[0133] In one implementation, the mobile phone can pre-configure cache information, which may include cache time and / or cache capacity. The cache time refers to the time during which log files can be stored in the cache area. The cache capacity refers to the total length of log files that the cache area (or cache pool) can store. After obtaining the aforementioned log files, the mobile phone can directly retrieve the pre-configured cache information (or preset cache information) and, based on this preset cache information, determine the cached log information in the cache area without needing to initialize the cache area.

[0134] In another implementation, if the log file is generated by a new process on the phone—that is, when the new process calls the log delivery interface for the first time to deliver the log file—the phone can initialize the cache pool according to preset cache information. It can be understood that during the initialization of the cache pool, the cache pool does not contain the log file; in other words, the cache pool is empty.

[0135] Specifically, after obtaining the aforementioned log file, the phone can determine whether to initialize the cache. If the phone has not initialized the cache, it indicates that the current application process is generating the log file for the first time; therefore, the phone can initialize the cache. If the phone has already initialized the cache, it indicates that the current application or process is not generating the log file for the first time; therefore, the phone does not need to initialize the cache to avoid unnecessary resource waste. For example, the process by which the phone determines cache initialization may include, as follows: Figure 12 S10-S30 are shown.

[0136] S10: The phone determines whether the cache area has been initialized and configured.

[0137] For example, if the phone has not initialized the cache, it can execute S20. If the phone has already initialized the cache, it can execute S802. The cache is a pre-defined memory area in the phone used for temporary storage of log files generated by the same process.

[0138] In some embodiments, the mobile phone can determine whether the above-mentioned cache has been initialized by judging whether the process in the mobile phone is calling the log delivery interface for the first time. If the process is calling the log delivery interface for the first time, it means that the process has not delivered log files. Therefore, the mobile phone can determine that the cache has not been initialized. If the process is not calling the log delivery interface for the first time, it means that the process has delivered log files. Therefore, the mobile phone can determine that the cache has been initialized.

[0139] S20: The mobile phone initializes and configures the cache area according to the preset cache information to obtain the configured cache area. The preset cache information may include the preset cache time and / or the preset cache capacity.

[0140] In some embodiments, the preset cache information corresponding to each process in the mobile phone may be the same or different, and there is no specific limitation. This preset cache information may include preset cache time and / or preset cache capacity (or preset data volume).

[0141] The aforementioned preset cache time is a pre-set maximum time that log files can be stored. It can be understood that since log files have a time limit, if the cache time of a log file exceeds the preset cache time, it means that the log file has been stored in the cache for a long time. Therefore, in order to avoid the inability to analyze logs in a timely manner due to the excessive storage time of log files, the mobile phone can send all log files in the cache after the cache time of the log file exceeds the preset cache time. For example, the mobile phone can send the log file to a non-blocking socket buffer.

[0142] The aforementioned preset cache capacity is a pre-set maximum length that can be stored for log files. It can be understood that since the above cache area is a part of the memory area in the phone, and the memory area corresponding to the cache area is pre-divided, the total length (or data volume) of all log files in the cache area cannot exceed the memory area corresponding to the cache area (or preset cache capacity, preset data volume). Therefore, if the total length of all log files in the cache area is greater than the preset cache capacity, it means that there is no remaining memory space in the cache area. Therefore, in order to avoid the loss of subsequent log files, the phone can send all log files in the cache area after the data volume of all log files in the cache area exceeds the preset cache capacity. For example, the phone can send all log files in the cache area to a non-blocking socket buffer.

[0143] S30, the phone is equipped with a timer, which is used to record the storage time of the aforementioned log file.

[0144] The storage time refers to the time when the aforementioned log file is stored in the cache.

[0145] In some embodiments, the mobile phone may need to configure a timer to determine the storage time of the log file, thus providing a basis for subsequently determining the log caching time of the cache pool. The storage time of the log file is the time corresponding to when the log file is stored in the cache area. It should be understood that the timestamp in the log file is the timestamp of the log file generation. Normally, the log generation time and the log storage time should be the same. However, in reality, due to factors such as lag, there may be a delay between the log generation time and the log storage time. Therefore, in order to accurately calculate the caching time of the log file, in this embodiment, the mobile phone can directly obtain the storage time of the log file through a timer.

[0146] In other embodiments, although there may be a delay between the log generation time and the log storage time, the delay may be small, that is, it can be ignored. Therefore, the mobile phone does not need to configure a timer, that is, it does not need to obtain the storage time of the log file, and directly uses the timestamp in the log file as the storage time of the log file.

[0147] Specifically, after obtaining the preset cache information, if the preset cache information includes a preset cache time, it indicates that the phone needs to obtain the log cache time. Therefore, the phone can configure a timer to calculate the log cache time. In other words, if the preset cache information is the preset cache capacity, the phone does not need to configure a timer to reduce unnecessary resource waste. It can be understood that when a log file is received in the cache, the phone can refresh the timer, meaning the timer starts counting from the current timestamp until the accumulated time reaches the preset cache time. Then, the phone sends all log files in the cache to the non-blocking socket buffer.

[0148] S802, the mobile phone determines whether there is a log file in the cache with the same log information as the aforementioned log file.

[0149] The aforementioned log information includes all content in the log structure except for the timestamp. In other words, the log information includes at least one of the following: log name, process ID / thread ID, log priority, log tag, and log content.

[0150] In some embodiments, after obtaining the aforementioned log file, the mobile phone can determine whether there is a log file in the cache with the same log information as the log file, that is, whether the log information corresponding to the log file is duplicated with the log information corresponding to any log file in the cache. If there is a log file in the cache with the same log information as the log file, it indicates that the log file obtained by the mobile phone is a duplicate log, and the mobile phone can execute S803; if there is no log file in the cache with the same log information as the log file, it indicates that the log file obtained by the mobile phone is not a duplicate log, that is, it is a new log file, and the mobile phone does not need to process the log file, that is, the mobile phone can execute S804 to continue to judge the log file.

[0151] It is understandable that since the log file mentioned above and the log file in the cache may be generated at different times, that is, the timestamps corresponding to the log file in the cache are different, the mobile phone does not need to check the timestamp when determining whether the log content is the same. In other words, the mobile phone only needs to check whether the log name, process ID / thread ID, log priority, log tag, and log content are the same.

[0152] In one example, if the log structure corresponding to the above log file is "06-14 14:50:02.411 26626377IPCUtils:IS_ASSIST_MODE is:false", and the log structure corresponding to one of the log files in the above buffer is "06-14 14:50:02.410 2662 6377IPCUtils:IS_ASSIST_MODE is:false", it means that there is a log file in the buffer with the same log information as the log file corresponding to that log file, that is, the log file is a duplicate log.

[0153] In another example, if the log structure corresponding to the above log file is "06-14 14:50:02.41929536 29536IBaseActivity:onCreate", and the log structures corresponding to the log files in the above cache are "06-1414:50:02.420 29536 29536I BaseActivity:onCreateCommon" and "06-14 14:50:02.420 2953629536I BaseActivity:addWindowFlags", then the log structure corresponding to this log file is different from the log structure corresponding to the log file in the cache. In other words, there is no log file in the cache with the same log information as this log file, that is, this log file is not a duplicate log.

[0154] In some embodiments, after obtaining the aforementioned log file, the mobile phone can determine whether there exists a log file with the same log content as the aforementioned log file among a preset number of log files in the cache area located before the timestamp corresponding to the aforementioned log file. For example, the cache area includes the aforementioned... Figure 5Taking log files A, B, and C as an example, if the preset quantity is 2, the phone can compare the log files obtained by the phone with the corresponding log information of log files B and C in the cache. If the log information of the log file obtained by the phone is "06-14 14:50:02.420 29536 29536I BaseActivity:onCreateCommon", it means that the log file is the same as the log information of log file B in the cache. Therefore, the phone can determine that the log file is a duplicate log, and the phone can reassemble the log file with the log file B in the cache. If the log information of the log file obtained by the phone is "06-14 14:50:02.420 29536 29536I BaseActivity:onCreate", it means that the log file is different from the log information of log files B and C in the cache. Therefore, the phone can determine that the log file is not a duplicate log.

[0155] S803, the mobile phone adds the timestamp and log repetition count corresponding to the above log file to the first log file to obtain a new log file, wherein the log information corresponding to the first log file is the same as that of the new log file.

[0156] Specifically, after confirming the existence of a log file in the cache with the same log information as the aforementioned log file, the phone can merge this log file with the other log file in the cache (or the first log file). This merges duplicate log files into a single file, saving phone storage resources while increasing log file aggregation. This provides storage space for subsequently generated log files, reducing log loss due to insufficient phone storage, lowering the log loss rate, and improving log file storage efficiency. Log merging refers to adding the log repetition count and the timestamp corresponding to the duplicate logs to the first log file.

[0157] The statement that the log information of the first log file is the same as the log information of the corresponding log structure (or the second log structure) is the same as the log information of the first log structure.

[0158] It is understood that the aforementioned cache area may include at least one log file. This log file can be a log file directly obtained by the mobile phone, or it can be a new log file obtained by reassembling the aforementioned log file; there is no specific limitation on the type of log file.

[0159] In some embodiments, the new log file may include at least one of the following: log name, process ID / thread ID, log priority, log tag, log content, log repetition count (repeat_count), and timestamp list (timespec_list). For example, Figure 13 As shown, the timestamp linked list includes the current timestamp and a pointer to the next timestamp. The length of the linked list is determined by the number of times the log is repeated.

[0160] In one example, such as Figure 14 As shown, taking four log files as an example, the log content for log file 1 is "06-14 14:50:02.410 2662 6377IPCUtils:IS_ASSIST_MODE is:false", the log information for log file 2 is "06-14 14:50:02.411 2662 6377IPCUtils:IS_ASSIST_MODE is:false", the log information for log file 3 is "06-14 14:50:02.411 2662 6377IPCUtils:IS_ASSIST_MODE is:false", and the log information for log file 4 is "06-14 14:50:02.411 2662 6377IPCUtils:IS_ASSIST_MODE is:false". These four log files show that, except for the timestamps, all the log information is identical. Therefore, the phone can merge these four log files to obtain log file 1234. The log information corresponding to log file 1234 is "06-14 14:50:02.410 2662 6377IPCUtils:IS_ASSIST_MODE is:false[×4][14:50:02.411][14:50:02.411][14:50:02.411]". It can be understood that [×4] in log file 1234 represents the number of log repetitions, and [14:50:02.411][14:50:02.411][14:50:02.411] in log file 1234 represents the timestamps corresponding to the repetitive logs, which are the timestamps corresponding to log files 2, 3, and 4.

[0161] Afterwards, the phone can analyze the log file 1234 and obtain the following results: Figure 15The log structure table is shown below. Specifically, the process ID / thread ID corresponding to log file 1234 is 2662 / 6377, the log priority is I, the log tag is PCUtils, the log content is IS_ASSIST_MODE is:false, the log repetition count is [×4], and the timestamp linked list includes [14:50:02.411][14:50:02.411][14:50:02.411]. It can be understood that since log file 1234 does not display a log name, the phone can default the log name to log_id_main.

[0162] It is understandable that, since the above log file can include multiple sub-log structures, the log file obtained after log reorganization can also include multiple new sub-log structures (new_iovec). For example, as shown... Figure 15 As shown above, nr represents the total number of sub-log structures in the log file. That is, the nr corresponding to log file 1234 is 5. Among them, new_iovec[0] is the first new sub-log structure (or new header sub-structure), new_iovec[1] is the second new sub-log structure, and new_iovec[nr-1] is the last new sub-log structure, which is the fifth new sub-log structure. Among them, the new header sub-structure includes the log name, the number of log repetitions, and the timestamp list. After that, each new sub-structure corresponding to each reorganized log file corresponds to a structure type. That is, new_iovec[1] corresponds to the process ID / thread ID of the log file, new_iovec[2] corresponds to the log priority of the log file, new_iovec[3] corresponds to the log tag of the log file, and new_iovec[4] corresponds to the log content of the log file. For example, taking the above log file 1234 as an example, the new_iovec[0] corresponding to log file 1234 includes "[×4][14:50:02.411][14:50:02.411][14:50:02.411]", the new_iovec[1] corresponding to log file 1234 includes "2662 / 6377", the new_iovec[2] corresponding to log file 1234 includes "I", the new_iovec[3] corresponding to log file 1234 includes "PCUtils", and the new_iovec[4] corresponding to log file 1234 includes "IS_ASSIST_MODE is:false".

[0163] In another example, such as Figure 16 As shown, taking 6 log files as an example, the log information for log file a is "06-28 11:24:18.036 1746 1746E SurfaceFlinger:checkFrameMiss ADD 1.reason:!Composite", the log information for log file b is "06-28 11:24:18.227 1672 1672EHW_DISPLAY:get_cative_panel:index:0", the log information for log file c is "06-28 11:24:18.24517461746E SurfaceFlinger:checkFrameMiss ADD 1.reason:!Composite", and the log information for log file d is "06-28 11:24:18.436 1672 1672E". The log information for log file e is "06-28 11:24:18.452 1746 1746E SurfaceFlinger:checkFrameMiss ADD 1.reason:! Composite", and the log information for log file f is "06-28 11:24:18.645 1672 1672EHW_DISPLAY:get_cative_panel:index:0". From these six log files, it can be seen that the log information for log files a, c, and e is identical except for the timestamp, and the log information for log files b, d, and f is also identical except for the timestamp. Therefore, the phone can merge the logs from log files a, c, and e to obtain log file ace. Simultaneously, the phone can merge the logs from log files b, d, and f to obtain log file bdf. The log information corresponding to the ace log file is "11:24:18.036 1746 1746E SurfaceFlinger:checkFrameMiss ADD 1.reason:!Composite[×3][11:24:18.245][11:24:18.452]", and the log information corresponding to the bdf log file is "06-28 11:24:18.227 1672 1672E HW_DISPLAY:get_cative_panel:index:0[×3][11:24:18.436][11:24:18.645]".

[0164] For example, such as Figure 17 As shown, if the cache includes log files A, B, and C, and the log information corresponding to log file D obtained by the phone is "06-14 14:50:02.421 2953629536IBaseActivity:onCreateCommon", it means that log file D and log file B in the cache are identical except for the timestamp. Therefore, the phone can merge log file D with log file B in the cache to obtain log file BD. The log information corresponding to log file BD becomes "06-14 14:50:02.42029536 29536IBaseActivity:onCreateCommon[×2][14:50:02.421]". It should be noted that log files in the cache with different log information retain their original log information; that is, the phone will not merge log files with different log information. Figure 17 The log information corresponding to log files A and C in the system has been changed.

[0165] In some embodiments, after the log file and the first log file are reassembled, the mobile phone can refresh the timer, that is, obtain the current time and determine the current time as the storage time of the log file, that is, the time when the log file was stored in the cache. Then, the mobile phone can encapsulate the log structure corresponding to the reassembled log file (or the new log file) to obtain the log cache entity corresponding to the new log file. For example, see... Figure 15 The mobile phone can encapsulate new_iovec[0], new_iovec[1], new_iovec[2], ..., new_iovec[nr-1] to obtain the log cache entity (logCache_iovec[0]) corresponding to the log file.

[0166] In one implementation, after determining that a log file with the same log content as the aforementioned log file exists in the cache, the mobile phone can use a target memory algorithm to process the log file in the cache to obtain the target cache. The target memory algorithm is the Least Recently Used (LRU) algorithm, which, when memory space is insufficient, prioritizes deleting log files with earlier storage times based on their storage duration.

[0167] Specifically, the phone can obtain the storage time of each log file in the cache. Then, the phone can delete the log file with the oldest storage time and add the log file obtained by the phone to the cache to ensure that the logs in the cache are the most recently generated log files.

[0168] S804, the phone adds the aforementioned log file to the aforementioned cache area.

[0169] Specifically, once it is determined that there is no log file in the cache with the same log content as the aforementioned log file, the phone can directly add the log file to the cache without recombining the log file with the log file in the cache.

[0170] For example, the cache includes the above. Figure 5 Taking log files A and B as examples, if the log content corresponding to the log file obtained by the phone is "06-14 14:50:02.420 29536 29536I BaseActivity:addWindowFlags", it means that this log file is different from the log file in the cache. Therefore, the phone can add this log file to the cache, which means that this log file is log file C in the cache.

[0171] In some embodiments, after adding the log file to the cache, the phone can refresh the timer, that is, obtain the current time and determine the current time as the storage time of the log file. Then, the phone can encapsulate the log structure corresponding to the log file to obtain the log cache entity corresponding to the log file.

[0172] S805, the mobile phone determines whether there are log files in the above cache area whose log caching time exceeds the preset caching time.

[0173] In some embodiments, after obtaining the log file, the mobile phone can determine whether there is a log file in the cache area whose cache time exceeds a preset cache time. This refers to the cache time corresponding to the earliest stored log file. If a log file with a cache time exceeding the preset cache time exists in the cache area, it indicates that the log file has been stored in the cache area for a relatively long time. Therefore, to avoid the inability to analyze the logs in a timely manner due to excessively long log storage time, the mobile phone can execute S806 to further determine whether the log file needs to be compressed. If no log file with a cache time exceeding the preset cache time exists in the cache area, it indicates that the log file in the cache area has been stored for a relatively short time. The mobile phone can return to execute S801 to continue waiting for the upper-layer application process to send the log file.

[0174] In one implementation, since the timer starts counting down after the cache is configured and the first log file is received, the phone can determine whether further compression of the log files is needed based on whether the cache duration has reached the preset cache time. This cache duration refers to the time between the initialization of the cache pool and the current time. The initialization of the cache pool includes the initial initialization and subsequent initializations after each log structure in the cache pool is written to the socket buffer, i.e., the reconfigured cache pool.

[0175] Specifically, if the cache duration of the cache pool reaches the preset cache time, it indicates that the log file has been stored in the cache for a relatively long time. Therefore, to avoid the inability to analyze the logs in a timely manner due to excessive log storage time, the phone can execute S806 to further determine whether the log file needs to be compressed. If the cache duration of the cache pool does not reach the preset cache time, it indicates that the log file in the cache has been stored in the cache for a relatively short time. The phone can return to execute S801 to continue waiting for the upper-layer application process to send the log file.

[0176] S806, the mobile phone determines whether the log cache capacity corresponding to the above cache area exceeds the preset cache capacity.

[0177] In some embodiments, after determining that there are log files in the buffer whose caching time exceeds a preset caching time, the mobile phone can further determine whether the log cache capacity corresponding to the buffer exceeds the preset cache capacity, where the log cache capacity refers to the data volume of all log structures in the buffer. If the log cache capacity corresponding to the buffer exceeds the preset cache capacity, it indicates that the buffer has no remaining memory space. Therefore, to avoid the loss of subsequent log files, the mobile phone can execute S809. If the log cache capacity corresponding to the buffer does not exceed the preset cache capacity, it indicates that although there are log files that have timed out, there is still free memory space in the buffer. Therefore, in order for the non-blocking socket buffer to store more log files, the mobile phone can execute S807.

[0178] S807, the mobile phone determines whether there is a log file in the above-mentioned cache area whose log length is less than the preset log length.

[0179] In some embodiments, after determining that the log cache capacity corresponding to the buffer does not exceed the preset cache capacity, the mobile phone can determine whether there are log files in the buffer with a log length shorter than the preset log length. If there are log files in the buffer with a log length shorter than the preset log length, it indicates that there are short logs in the buffer. Therefore, in order to improve the log storage efficiency of the socket buffer, the mobile phone can execute S808. If there are no log files in the buffer with a log length shorter than the preset log length, that is, the log length of all log files in the buffer is not less than the preset log length, it indicates that the log files in the buffer are all long logs. Therefore, the mobile phone does not need to merge the log files in the buffer, that is, the mobile phone can execute S809.

[0180] Specifically, the phone can determine the log length of each log file in the cache, starting with the oldest log file, based on its storage time, and then check if the log length of that log file is greater than a preset log length. Here, log length refers to the number of strings corresponding to the log file.

[0181] In one implementation, the mobile phone can determine the log file order by sorting the storage times of each log file in the cache according to a preset order. The preset order can be either descending or ascending, and is not limited to either. Then, the mobile phone can determine the log length of each log file based on its sorting order. For example, if the preset order is descending, the log file at the first position has the earliest storage time, and therefore the mobile phone can determine its log length. If the preset order is ascending, the log file at the last position has the earliest storage time, and therefore the mobile phone can determine its log length.

[0182] In some embodiments, the mobile phone may not execute S806 as described above. That is, the preset cache information only includes the preset cache time. The mobile phone only needs to determine whether there are log files in the cache area whose cache time exceeds the preset cache time. If there are log files in the cache area whose cache time exceeds the preset cache time, the mobile phone can directly execute S807. If there are no log files in the cache area whose cache time exceeds the preset cache time, the mobile phone can return to execute S801 to continue waiting for the upper-layer application or process to send the log file.

[0183] S808: The mobile phone merges log files with log lengths shorter than the preset log length with a second log file to obtain the target log file.

[0184] The second log file is the next log file after the log file whose length is less than the preset log length. It can be understood that if the first log file is the last log file in the cache, then the second log file is the next log file the phone will obtain; if the first log file is not the last log file in the cache, then the second log file is the next log file in the cache after the first log file.

[0185] In some embodiments, after determining that a log file with a length shorter than a preset log length exists in the aforementioned buffer, the mobile phone can merge this log file (or third log file) with the second log file. Log merging refers to adding log content from the second log file that differs from the third log file to the third log file; that is, integrating the log content from the second log file into the third log file to form a long log. In this way, multiple short log files can be merged into a single long log file. This not only saves mobile phone storage resources while improving log aggregation and reducing the probability of log loss, but also reduces the consumption of I / O resources due to multiple sending of log files to the socket buffer, thus increasing the frequency of I / O resource usage.

[0186] Specifically, the phone can identify the first log file in the cache whose log length is less than the preset log length as the third log file. Then, the phone can merge the third log file with the second log file to obtain a merged log file (or candidate log file). Next, the phone can determine if the log length of the merged log file is less than the preset log length. If the log length of the merged log file is not less than the preset log length, the phone can directly identify the merged log file as the target log file. If the log length of the merged log file is still less than the preset log length, the phone can identify the merged log file as the third log file and return to the step of "merging the third log file with the second log file to obtain the merged log file," until the log length of the merged log file is not less than the preset log length, at which point the phone can identify the merged log file as the target log file.

[0187] Afterward, the phone can continue to determine if there are log files in the cache with a log length shorter than the preset log length. If there are still log files in the cache with a log length shorter than the preset log length, the phone can continue to merge the logs of these log files with the corresponding second log files until the log lengths of all the log files in the cache are shorter than the preset log length. At this point, the phone can determine that all log files in the cache are the target log files. It can be understood that the log length of the target log file is not shorter than the preset log length.

[0188] In one example, the buffer includes Figure 18 Taking three log files as an example, if log file A is the third log file, that is, log file A is a short log, and log file B is the second log file mentioned above, then the mobile phone can merge log files A and B to obtain the merged log file (or candidate log file), which is log file AB. Specifically, since the log content corresponding to log file A includes "06-14 14:50:02.4192953629536I BaseActivity:onCreate", and the log content corresponding to log file B includes "06-14 14:50:02.420 2953629536I BaseActivity:onCreateCommon", the mobile phone can determine that the log information in log file B is different from the log information in log file A. In other words, the mobile phone can add the timestamp and log information in log file B to log file A to obtain log file AB. The log content corresponding to log file AB includes "06-14 14:50:02.419 29536 29536I BaseActivity:onCreate[14:50:02.420]onCreateCommon".

[0189] It is understandable that after merging log files A and B, the buffer only includes log files AB and C. In other words, the phone needs to further determine if the log length corresponding to log file AB is less than the preset log length. If the log length corresponding to log file AB is still less than the preset log length, it indicates that the merged log file is still a short log. Therefore, the phone can continue to merge log file AB with the aforementioned log file C to obtain log file ABC. The log content corresponding to log file ABC includes "06-14 14:50:02.419 2953629536IBaseActivity:onCreate[14:50:02.420]onCreateCommon[14:50:02.420]addWindowFlags".

[0190] If the log length corresponding to the aforementioned log file AB is not less than the preset log length, it indicates that the log file AB is a long log. Therefore, the phone can continue to determine whether the log length corresponding to the aforementioned log file C is less than the preset log length. If the log length corresponding to log file C is less than the preset log length, it indicates that the log file C is a short log. Therefore, the phone can merge the log file C with the next log file stored in the cache area. If the log length corresponding to log file C is not less than the preset log length, the phone can determine that log files AB and log file C are the target log files.

[0191] In another example, the cache includes Figure 19 Taking three log files as an example, if log file AD is the third log file, that is, log file AD is a short log, and log file B is the second log file mentioned above, then the mobile phone can merge log files AD and B to obtain the merged log file (or candidate log file), which is log file ADB. Specifically, since the log content corresponding to log file AD includes "06-14 14:50:02.41929536 29536I BaseActivity:onCreate[×2][14:50:02.421]", and the log content corresponding to log file B includes "06-14 14:50:02.420 29536 29536I BaseActivity:onCreateCommon", the mobile phone can determine that the log information in log file B is different from the log information in log file AD. In other words, the mobile phone can add the timestamp and log information in log file B to log file AD to obtain log file ADB. The log content corresponding to log file ADB includes "06-14 14:50:02.419 29536 29536IBaseActivity:onCreate[×2][14:50:02.421][14:50:02.420]onCreateCommon".

[0192] In some embodiments, if the log length of the third log structure is less than a preset log length, the mobile phone can merge the third log structure with one or more fourth log structures until the length of the merged log structure is greater than or equal to the preset log length. The log structure with a length greater than or equal to the preset log length is then determined as the log structure corresponding to the target log file. The third log structure is any log structure in the buffer that has not been written to the socket buffer. The fourth log structure is a log structure located after the third log structure and / or that has not been written to the socket buffer.

[0193] It should be noted that in this embodiment, the mobile phone only performs log merging on log files with different timestamps and / or log content. However, in other embodiments, the mobile phone can perform log merging on log files with different member variables other than process ID / thread ID in the log information. The specific method is not limited.

[0194] In one implementation, after determining that there is a log file in the buffer that has been cached for a period of time exceeding the preset cache time, the mobile phone may not execute the judgment process of S806 to S808 as described above. That is, the mobile phone can directly execute S809 to send the log file in the buffer to the non-blocking socket buffer.

[0195] S809, the mobile phone identifies the log file in the aforementioned cache area as the target log file.

[0196] Specifically, after determining that there are no log files in the above-mentioned cache area with a log length shorter than the preset log length, the mobile phone can directly identify all log files in the cache area as the target log file.

[0197] In some embodiments, after determining that there are no log files in the buffer with a log length shorter than a preset log length, the mobile phone can also compress log files with higher log priority based on their log priority in the buffer, and / or, the mobile phone can also compress log files with the largest log traffic based on their log traffic in the buffer, to obtain the target log file. In other words, this application can compress not only duplicate log files and log files with fewer characters, but also log files with higher log priority and larger log traffic. This maximizes the aggregation of log files, reduces the waste of storage resources, and improves the storage efficiency of the socket buffer.

[0198] In other embodiments, if the log length of the third log structure is greater than or equal to the preset log length, the mobile phone can determine the third log structure as the log structure corresponding to the target log file.

[0199] In one implementation, after updating the cache, the phone can skip the judgment processes S805-S809. That is, after determining whether the log file is a duplicate log, the phone can directly execute S810 to send the log file to the non-blocking socket buffer; alternatively, the phone can return to execute S801 to continue waiting for the upper-layer application or process to send the log file. Updating the cache refers to the process of adding the aforementioned log file to the cache and obtaining the new log file.

[0200] In another implementation, the phone may not execute S805. That is, the preset cache information only includes the preset cache capacity. The phone only needs to determine whether the log cache capacity corresponding to the cache area exceeds the preset cache capacity. If the log cache capacity corresponding to the cache area exceeds the preset cache capacity, the phone can execute S809. If the log cache capacity corresponding to the cache area does not exceed the preset cache capacity, the phone can execute S807.

[0201] S810: The phone sends all target log files in the aforementioned cache to the socket buffer.

[0202] Specifically, after identifying the target log file, the phone can directly send all target log files from the buffer to the socket buffer. This socket buffer is a non-blocking socket buffer used to store the log files. This provides a foundation for storing subsequent log files acquired by the phone in the buffer.

[0203] In some embodiments, after sending the target log file, the phone can reset the buffer and timer, providing a basis for subsequent storage of the log file in the buffer. It is understood that during the reconfiguration of the buffer, the buffer does not contain the log file; that is, the buffer is empty.

[0204] In other embodiments, when the logd module in the mobile phone detects that the socket buffer includes the target log file, the log buffer in the logd module sequentially receives the log files from the socket buffer. Then, the logd module can parse the received log files to restore the reconstructed log files and obtain an initial log structure. This initial log structure is the log structure generated by the first application and before log merging, which is the structure corresponding to when the mobile phone obtains the log file. This facilitates subsequent log file analysis and improves log analysis efficiency.

[0205] It is understandable that the process of resetting the phone's cache and timer, as well as the process of the logd module receiving the target log file, can be performed simultaneously, sequentially, or one of them can be selected; there is no specific limitation.

[0206] This application also provides a computer-readable storage medium including computer instructions that, when executed on the electronic device, cause the electronic device to perform the various functions or steps described in the method embodiments.

[0207] This application also provides a computer program product, including a computer program that, when run on an electronic device, causes the electronic device to perform the various functions or steps described in the above method embodiments.

[0208] This application provides a chip for executing instructions. When the chip is running, it executes the technical solutions described in the above embodiments. Its implementation principle and technical effects are similar and will not be repeated here.

[0209] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., high-density digital video discs (DVDs)), or semiconductor media (e.g., solid-state disks (SSDs)).

[0210] It should be understood that the term "embodiment" used throughout the specification means that a specific feature, structure, or characteristic related to an embodiment is included in at least one embodiment of this application. Therefore, various embodiments throughout the specification do not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It should be understood that in the various embodiments of this application, the sequence numbers of the above processes do not imply a sequential order of execution; the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0211] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0212] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0213] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0214] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0215] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0216] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, essentially or in other words, the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0217] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A log management method, characterized in that, Applied to an electronic device in which a first application is installed, the method includes: Receive a log structure sent by the log driver, wherein the log structure is the structure corresponding to the log file generated by the first application; If the log information of the first log structure is the same as the log information of the second log structure in the cache pool, the timestamp of the first log structure is added to the second log structure to obtain the merged second log structure; wherein, the first log structure is any log structure issued by the log driver, the second log structure is any log structure in the cache pool, and the log information includes all the contents of the log structure except for the timestamp. If the log information of the first log structure is different from the log information of all log structures in the cache pool, the first log structure is stored in the cache pool; wherein, during the configuration of the cache pool, the cache pool does not contain log structures; Under the condition that the preset conditions are met, multiple log structures in the cache pool are written into the socket buffer, which is used by the electronic device to read and write log files to the log recording module. The multiple log structures are stored in the cache pool in a preset order. When the total amount of data of all log structures in the cache pool has not reached the preset amount of data, if the log length of the third log structure is greater than or equal to the preset log length, the third log structure is written into the socket buffer. If the log length of the third log structure is less than the preset log length, the third log structure and the fourth log structure are merged to obtain the target log file; wherein, this includes merging the content of the fourth log structure that is different from the third log structure into the third log structure; If the target log file is smaller than the preset log length, the target log file is merged with the next fourth log structure until the length of the merged log is greater than or equal to the preset log length, and the merged log structure is written into the socket buffer. Wherein, the third log structure is any log structure among the plurality of log structures that has not been written to the socket buffer, and the fourth log structure is a log structure located after the third log structure that has not been written to the socket buffer; Send the target log structure in the socket buffer to the log recording module; The log structure received by the log recording module is restored to obtain an initial log structure; wherein, the initial log structure is the structure corresponding to the log file generated by the first application and not merged, and the timestamp in the restored initial log structure comes from the timestamp linked list in the target log structure.

2. The method according to claim 1, characterized in that, The preset conditions include: The cache duration of the cache pool reaches the preset cache time; and / or, The total amount of data in all log structures in the cache pool has reached the preset amount.

3. The method according to claim 1 or 2, characterized in that, After writing multiple log structures from the cache pool into the socket buffer, the method further includes: The cache pool is reconfigured according to preset cache information; wherein the preset cache information includes preset cache time and / or preset data volume.

4. The method according to claim 3, characterized in that, The method further includes: If the preset cache information includes a preset cache time, the timer is reconfigured; wherein the timer is used to record the time when the log file is stored in the cache pool.

5. The method according to claim 1 or 2, characterized in that, After receiving the log structure sent by the log driver, the method further includes: When the first application is the first application to issue log files, the cache pool is initialized and configured according to preset cache information; wherein, the preset cache information includes preset cache time and / or preset data volume.

6. An electronic device, characterized in that, The electronic device includes a memory and one or more processors; the memory and the processors are coupled; the memory is used to store computer program code, the computer program code including computer instructions; when the processor executes the computer instructions, the electronic device performs the method as described in any one of claims 1 to 5.

7. A computer-readable storage medium, characterized in that, Includes computer instructions that, when executed on an electronic device, cause the electronic device to perform the method as described in any one of claims 1 to 5.

Images