Cross-device log processing method and device, storage medium and electronic device

Abstract

The invention provides a cross-device log processing method and device, a storage medium and electronic equipment, and is applied to the technical field of distributed system debugging. According to the method, the comprehensive capability parameters of the terminal devices in the local area network are obtained, the optimal master device is intelligently selected based on the multiple indexes, and other devices serve as the slave devices. The master device broadcasts the master timestamp to the slave device, so that the slave device corrects the local log timestamp, and the time synchronization precision is improved. And the main device aggregates the corrected log files, generates a first target log file according to session merging, and generates an encrypted hash value, a complete sorting log and a time sequence diagram for the first target log file. And compressing and packaging the files to form a log package with a digital certificate. According to the invention, through unifying the time reference and log management, the accuracy and credibility of cross-device log time synchronization are effectively improved, and the requirement of multi-terminal collaborative debugging is met.

Description

Technical Field

[0001] This invention relates to the field of distributed system debugging technology, and in particular to a cross-device log processing method, apparatus, storage medium and electronic device. Background Technology

[0002] With the diversification of smart terminals, collaborative development across multiple terminals such as mobile phones, TVs, and embedded SDKs is common. Unified collection and synchronization of cross-terminal logs has become the key to improving debugging efficiency and problem localization.

[0003] However, existing technologies have significant shortcomings in addressing "time base drift" and "log acquisition in offline environments." Furthermore, when dealing with large time differences between master and slave devices (e.g., exceeding 30 seconds), time synchronization convergence is slow, failing to meet real-time debugging requirements. Traditional master device election mechanisms do not adequately consider multi-device environments within a local area network, leading to unstable time bases, large log timestamp errors, and an inability to accurately reconstruct the timing of cross-device events, thus impacting normal business operations.

[0004] Therefore, how to effectively improve the convergence speed and accuracy of log time synchronization across devices has become a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0005] In view of the above problems, the present invention provides a cross-device log processing method, apparatus, storage medium, and electronic device that overcomes or at least partially solves the above problems, the technical solution of which is as follows:

[0006] A cross-device log processing method includes:

[0007] Obtain the capability parameters of each terminal device within the local area network, wherein the capability parameters include multiple indicator parameters reflecting the comprehensive performance capability of the terminal device in a time synchronization scenario;

[0008] Using the various index parameters of each of the terminal devices, a master device is elected from among the terminal devices, and the other terminal devices are designated as slave devices.

[0009] The master device broadcasts a master timestamp to the slave devices, so that each slave device can correct the timestamp of its local log file based on the master timestamp.

[0010] The master device aggregates the timestamp-corrected log files of each terminal device in the local area network and merges them into a first target log file according to the session.

[0011] For each of the first target log files, generate the corresponding encrypted hash value, a fully sorted log file, and a time sequence diagram file;

[0012] The encrypted hash value, the complete sorted log file, and the time sequence graph file, which belong to the same first target log file, are compressed and packaged to generate a corresponding log package and its digital certificate, wherein the digital certificate is used to verify the log package.

[0013] Optionally, the capability parameters include the device performance rating, network round-trip time, system load, and network time synchronization freshness of the terminal devices. The step of selecting a master device from among the terminal devices using each of the aforementioned indicator parameters includes:

[0014] For any of the terminal devices: the comprehensive performance parameters of the terminal device are obtained by using the device performance rating, network round-trip time, system load, network time synchronization freshness and corresponding indicator weights of the terminal device;

[0015] Based on the comprehensive performance parameters of each terminal device, a master device is elected from among the terminal devices.

[0016] Optionally, the capability parameters further include the device identifier of the terminal device, and the process of electing a master device among the terminal devices based on the comprehensive performance parameters of each terminal device includes:

[0017] Among all the terminal devices, the terminal device with the largest comprehensive performance parameter is selected as the master device;

[0018] In the case where there are multiple terminal devices with the largest comprehensive performance parameters, the terminal device with the smallest device identifier in the preset device dictionary order is elected as the master device.

[0019] Optionally, the step of broadcasting a master timestamp to the slave devices through the master device, so that each slave device corrects the timestamp of its local log file based on the master timestamp, includes:

[0020] The master device broadcasts a master timestamp to the slave devices, so that each slave device can calculate its corresponding time offset using its own slave timestamp, the master timestamp, and an error compensation coefficient. The time offset is then used to correct the timestamp of the slave device's local log file. The error compensation coefficient is dynamically adjusted based on the estimated network latency of the local area network to ensure that the time offset is less than or equal to a preset threshold.

[0021] Optionally, the step of broadcasting a master timestamp to the slave devices through the master device, so that each slave device corrects the timestamp of its local log file based on the master timestamp, includes:

[0022] The master device broadcasts a time synchronization packet to the slave device, wherein the time synchronization packet includes a master timestamp and a sending time;

[0023] In the event that any of the slave devices receives the time synchronization packet, the slave device calculates the network latency based on the reception time and the transmission time;

[0024] The time offset is obtained using the master timestamp and the network latency.

[0025] If the time offset is greater than or equal to a preset time offset threshold, then when the slave device generates a local log file, the local system time is added to the time offset to obtain the timestamp of the local log file. If not, the time offset is smoothed, and when the slave device generates a local log file, the local system time is added to the smoothed time offset to obtain the timestamp of the local log file.

[0026] Optionally, before merging the first target log file by session, the method further includes:

[0027] When a cross-device interaction is initiated between the master device and the slave device, a session identifier is generated and transparently transmitted to all participating devices through a service channel, so that each participating device stores the session identifier, the corrected log timestamp, the device identifier, the event type, and additional information as log entries when recording logs.

[0028] Optionally, before obtaining the capability parameters of each terminal device within the local area network, the method further includes:

[0029] The system checks whether the cloud service network is connected. If not, it obtains the capability parameters of each terminal device in the local area network. If so, it uploads the local logs of each terminal device to the cloud server, so that the cloud server can merge the uploaded local logs into a second target log file by session, and generate a cloud aggregated log and a visual time-series report based on each second target log file.

[0030] A cross-device log processing apparatus includes: a capability parameter acquisition unit, a master device election unit, a master timestamp broadcasting unit, a first target log file merging unit, a file generation unit, and a log compression and packaging unit;

[0031] The capability parameter acquisition unit is used to obtain the capability parameters of each terminal device in the local area network, wherein the capability parameters include multiple index parameters reflecting the comprehensive performance capability of the terminal device in the time synchronization scenario;

[0032] The master device election unit is used to elect a master device from among the terminal devices by using the various index parameters of each terminal device, and to treat other terminal devices as slave devices.

[0033] The master timestamp broadcasting unit is used to broadcast the master timestamp to the slave devices through the master device, so that each slave device can correct the timestamp of its local log file based on the master timestamp;

[0034] The first target log file merging unit is used to aggregate the timestamp-corrected log files of each terminal device in the local area network through the master device, and merge them into a first target log file according to session;

[0035] The file generation unit is used to generate corresponding encrypted hash values, complete sorted log files, and time sequence diagram files for each of the first target log files;

[0036] The log compression and packaging unit is used to compress and package the encrypted hash value, the complete sorted log file, and the time sequence diagram file that belong to the same first target log file to generate a corresponding log package and its digital certificate, wherein the digital certificate is used to verify the log package.

[0037] A computer-readable storage medium having a program stored thereon that, when executed by a processor, implements the cross-device log processing method described above.

[0038] An electronic device includes at least one processor, at least one memory connected to the processor, and a bus; wherein the processor and the memory communicate with each other via the bus; the processor is used to call program instructions in the memory to execute the cross-device log processing method.

[0039] By employing the above technical solution, this invention provides a cross-device log processing method, apparatus, storage medium, and electronic device. This method obtains capability parameters of each terminal device within a local area network (LAN), including multiple indicator parameters reflecting the comprehensive performance of each terminal device in a time synchronization scenario. Using these indicator parameters, a master device is elected from among the terminal devices, and other terminal devices are designated as slave devices. The master device broadcasts a master timestamp to the slave devices, enabling each slave device to correct the timestamp of its local log file based on the master timestamp. The master device aggregates the timestamp-corrected log files from each terminal device in the LAN and merges them into a first target log file based on sessions. For each first target log file, a corresponding encrypted hash value, a fully sorted log file, and a timing graph file are generated. The encrypted hash value, fully sorted log file, and timing graph file belonging to the same first target log file are compressed and packaged to generate a corresponding log package and its digital certificate, wherein the digital certificate is used to verify the log package. This invention obtains the comprehensive capability parameters of each terminal device in the local area network, intelligently elects the optimal master device and broadcasts the master timestamp, thereby enabling slave devices to accurately correct their local log timestamps. Combined with the master device's aggregation, encryption verification and unified sorting of the corrected logs, this invention effectively improves the accuracy and reliability of cross-device log time synchronization.

[0040] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention and to implement it in accordance with the contents of the specification, and in order to make the above and other objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0041] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0042] Figure 1 A flowchart illustrating one embodiment of the cross-device log processing method provided by this invention is shown.

[0043] Figure 2 A schematic diagram of the log entry structure provided in an embodiment of the present invention is shown;

[0044] Figure 3 A flowchart illustrating another implementation of the cross-device log processing method provided in this embodiment of the invention is shown.

[0045] Figure 4 A logical block diagram of the dual-mode adaptive log aggregation process provided in an embodiment of the present invention is shown;

[0046] Figure 5 A schematic diagram of the cross-device log processing apparatus provided in an embodiment of the present invention is shown;

[0047] Figure 6 A schematic diagram of the structure of an electronic device provided in an embodiment of the present invention is shown. Detailed Implementation

[0048] Exemplary embodiments of the invention will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the invention are shown in the drawings, it should be understood that the invention may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this invention will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art.

[0049] With the diversification of smart terminal devices, collaborative development across multiple terminals, including mobile phones, TVs, and embedded SDKs (Software Development Kits), has become a common application scenario. In this context, achieving unified collection and synchronization of logs across terminals is crucial for improving system debugging efficiency and problem localization capabilities. However, existing technologies face significant technical bottlenecks in solving multi-terminal log synchronization issues, particularly regarding the critical problems of "time base drift" and "log acquisition in offline environments," making it difficult to meet practical needs.

[0050] First, existing master device election mechanisms are largely unoptimized for the specific scenario of log synchronization across multiple devices within a local area network. They neglect the combined impact of factors such as device performance differences, network latency, system load, and NTP synchronization status, leading to instability in the elected time base device and significant log timestamp errors. In extreme network environments or under high load conditions, insufficient time synchronization accuracy may affect the operation of normal services and fail to accurately reproduce the chronological order of events across devices, posing significant challenges to debugging and troubleshooting.

[0051] Secondly, for log collection and aggregation in offline environments, existing solutions lack effective integrity verification methods and cannot generate verifiable complete log packages. Field engineers often have to manually splice log files from different devices, which is cumbersome, error-prone, and greatly reduces debugging efficiency and data reliability.

[0052] Furthermore, existing mainstream time synchronization protocols such as NTP (Network Time Protocol) and PTP (Precision Time Protocol) each have their shortcomings. NTP operates at the application layer, relies on software timestamps, and is greatly affected by network jitter and device crystal oscillator drift, typically achieving only millisecond-level synchronization accuracy, making it difficult to meet the high-precision requirements for cross-device log alignment. While PTP can achieve nanosecond-level synchronization accuracy, it relies on dedicated hardware support, making deployment complex and costly, hindering its widespread application in consumer devices such as mobile phones and televisions, as well as temporary networking environments.

[0053] In summary, there are three main problems in current cross-terminal collaborative debugging: First, the time synchronization accuracy of consumer-grade devices is low, which cannot meet the needs of event timing restoration; second, the log format and time base are not uniform, making it difficult to accurately aggregate and sort logs across devices; and third, the existing solutions have high deployment costs, limited applicability, and log management in offline environments relies on manual operation, which is inefficient and cannot support efficient on-site debugging and collaborative development.

[0054] Based on this, this embodiment of the invention provides a cross-device log processing method. First, it intelligently selects the optimal time reference source based on multi-dimensional factors to achieve a high-precision, low-cost, and highly compatible time synchronization service. Second, it adopts a lightweight time synchronization protocol to ensure the accuracy of log timestamps without affecting device business operations. In addition, it supports the automatic generation of verifiable complete log packages in offline environments, improving on-site debugging efficiency and the credibility of log data, and providing strong technical support for multi-terminal cross-device collaborative development.

[0055] like Figure 1 The diagram shows a flowchart of one embodiment of the cross-device log processing method provided by this invention. The method may include:

[0056] S100. Obtain the capability parameters of each terminal device in the local area network. The capability parameters include multiple indicator parameters that reflect the comprehensive performance capability of the terminal devices in the time synchronization scenario.

[0057] The capability parameters may include at least one of the following indicators: device performance rating of the terminal device, network round-trip time, system load, network time synchronization freshness, and device identification.

[0058] Device performance grading refers to classifying devices into different performance levels (e.g., high-end mobile phones, mid-range mobile phones, high-end TVs, and low-end TVs) based on their hardware and software performance indicators. Grading criteria may include CPU model and clock speed, memory capacity, storage speed, and crystal oscillator quality, used to assess the device's potential and stability as a time synchronization master. Higher-performance devices typically have more stable and accurate local clocks and stronger processing capabilities, resulting in higher performance scores. For example, a mobile phone's performance level is higher than that of a TV.

[0059] Round-Trip Time (RTT) refers to the time it takes for a data packet to travel from the sender to the receiver and back. RTT reflects network communication latency and is a key indicator of network connection quality and time synchronization accuracy. A lower RTT indicates a faster network connection, lower latency in obtaining accurate time, and a higher RTT score.

[0060] System load refers to the degree to which a terminal device's current operating status utilizes its processing power, and can include metrics such as CPU utilization, memory utilization, and disk I / O wait rate. High system load may reduce the device's ability to synchronize time and generate logs, and may also increase crystal oscillator clock errors, affecting time synchronization accuracy. The system load score is calculated by weighting and normalizing multiple metrics. The lower the system load, the higher the corresponding load score.

[0061] Network time synchronization freshness refers to the time interval between the last successful synchronization of the terminal device's system time via a network time protocol (such as NTP). Higher synchronization freshness (i.e., more recent synchronization time) results in better time accuracy of the device's internal clock and provides a more stable time reference. It is typically scored based on the length of time since the synchronization occurred; for example, NTP scores full marks for synchronizations within 5 minutes, and the score decreases as the synchronization time exceeds a certain threshold.

[0062] The Device ID is a string or code value used to uniquely identify each terminal device, ensuring differentiation between devices within a local area network or system. Device IDs are typically generated based on unique information inherent to the device, such as Settings.Secure.ANDROID_ID for Android devices, identifierForVendor for iOS, and hash values ​​of MAC addresses or serial numbers for TVs and embedded devices. Beyond device identification, the Device ID plays a crucial role in master device election and log merging, for example, serving as a fallback criterion in cases of tied scores.

[0063] Specifically, embodiments of the present invention can automatically collect the capability parameters of each device when all devices start up or enter debug mode. The capability parameters include device performance level (e.g., determined by a built-in model classification table or system information), current system load (e.g., real-time query of CPU, memory, and disk usage), network round-trip time (e.g., obtaining the RTT value by pinging a specified server), freshness of the most recent NTP time synchronization (obtaining the synchronization interval), and unique device identifier. This data is exchanged through local or LAN broadcast methods to prepare for subsequent master device election.

[0064] S110. Using the various indicator parameters of each terminal device, select the master device from among the terminal devices and treat the other terminal devices as slave devices.

[0065] The master device refers to the optimal device selected through an intelligent election mechanism within the local area network. It serves as the time reference source, is responsible for broadcasting the master timestamp, coordinating time synchronization, and undertaking log aggregation and service functions in offline mode.

[0066] In this context, a slave device refers to other terminal devices within the local area network besides the master device. These devices receive time information broadcast by the master device to correct their own log timestamps and ensure alignment with the master device's time base.

[0067] Specifically, in this embodiment of the invention, a comprehensive evaluation model that integrates multi-dimensional performance indicators can be constructed to calculate the comprehensive performance value of each terminal device in the time synchronization scenario, and based on this, the optimal device in the local area network can be selected as the master clock source.

[0068] S120. The master device broadcasts the master timestamp to the slave devices so that each slave device can correct the timestamp of its local log file based on the master timestamp.

[0069] The master timestamp refers to the time identifier that the master device broadcasts periodically. Based on this timestamp, the slave device dynamically calculates the local time offset and corrects the log timestamp, thereby achieving high-precision time synchronization.

[0070] The local log file refers to the debug log generated by each terminal device, which can record device operation events and status, including fields such as corrected timestamp, device ID, session ID and event type, for subsequent aggregation and analysis.

[0071] Specifically, the master device can broadcast a data packet containing time reference information, enabling the slave device to calculate and apply a dynamically calibrated time offset based on this information to perform high-precision soft synchronization correction on its local log timestamps.

[0072] S130. The master device aggregates the log files of each terminal device in the local area network after timestamp correction, and merges them into the first target log file according to the session.

[0073] A session is a unique identifier for a cross-device interaction process triggered by a user or system. By using a unified session ID to associate logs from multiple devices, it supports the association and sorting of cross-device events.

[0074] The first target log file refers to the log file generated by the master device by merging and combining multiple slave device logs after correcting the timestamps, according to the session ID, and sorting them uniformly.

[0075] Specifically, the master device can start the HTTP / FTP service at a specified aggregation time (such as user-triggered or automatically scheduled) and broadcast its own IP port. Each slave device uploads its local log files, corrected for timestamps, to the master device. After receiving all device logs, the master device groups them by session ID, sorts them globally by corrected timestamps, and merges them to generate a unified first target log file.

[0076] As examples, when log aggregation is triggered (e.g., a user clicks "Generate Report") and no internet connection is detected, LAN aggregation mode is initiated. First, a master device is elected or designated as the log aggregation host. The master device starts a lightweight HTTP service (e.g., port 8080) and broadcasts its service address. All slave devices upload locally stored, timestamped log files (in a structured data format containing mandatory fields such as sessionId, timestamp, event, and payload) to the master device via HTTP POST requests. After receiving all logs, the master device's aggregation service first sorts and merges all log entries globally, prioritizing sessions and then timestamping them. For each independent session, a first target log file is generated, arranged chronologically and incorporating logs from all participating devices. This file fully records the entire event flow across devices within that session.

[0077] S140. For each first target log file, generate the corresponding encrypted hash value, complete sorted log file, and time sequence diagram file respectively.

[0078] The cryptographic hash value refers to the cryptographic hash value (such as SHA-256) generated based on the first target log file. It is used to verify the integrity of the log file and prevent tampering, ensuring the credibility of the log data.

[0079] Among them, the complete sorted log file refers to the comprehensive log file that is sorted in chronological order after unified time synchronization and session merging on the master device, reflecting the true time sequence of events across devices.

[0080] Among them, the timing diagram file refers to the timeline and session flow of log events in a graphical form, which supports exception marking and collaborative annotation, making it easier for developers to intuitively understand the relationship between events across devices.

[0081] Specifically, the master device uses an encryption algorithm to generate a hash value for each merged target log file, writes it to a separate verification file, outputs a complete sorted log file, and automatically generates a sequence diagram to display the event chain and process, so as to realize the integrity verification and visualization analysis of log data.

[0082] As examples, the master device performs three parallel processes for each primary target log file (i.e., the log set merged by session): 1. Generate a cryptographic hash value: Calculate a unique hash value using a cryptographic hash algorithm (such as SHA-256) on the original content of the log file and save it to a separate log_hash.txt file for integrity verification. 2. Generate a fully sorted log file: Convert the content of the primary target log file into a more readable text format (such as merged_logs.txt), where each log entry clearly displays information such as device, time, and event. 3. Generate a time-series graph file: Parse the primary target log file, extract key events and their timestamps, and automatically generate a visual, interactive HTML time-series graph file (such as timeline.html) using a template engine (such as Jinja2) or a front-end charting library (such as ECharts). This graph visually displays the causal relationships and execution sequences of events across devices in a timeline format.

[0083] S150. Compress and package the encrypted hash value, the complete sorted log file, and the time sequence diagram file that belong to the same first target log file to generate the corresponding log package and its digital certificate. The digital certificate is used to verify the log package.

[0084] The log package refers to a data set formed by compressing and packaging the first target log file, the encrypted hash value file, and the time sequence graph file, etc., to facilitate unified transmission, storage, and verification.

[0085] Digital credentials refer to the verification information attached to the log packet, which may include the log packet hash value, generation timestamp, and master device ID, etc., and are used to scan and verify the integrity and authenticity of the log packet, preventing logs from being tampered with.

[0086] Specifically, the master device can ZIP-compress and package the encrypted hash value file, the complete sorted log file, and the timing graph file to form a formal log package. Simultaneously, it generates a digital credential containing information such as the hash value, generation timestamp, and master device ID, which can be presented as a QR code or embedded with metadata. When downloading or scanning the log package, the hash value is automatically compared to ensure the content has not been tampered with, achieving secure verification and trusted transmission of the log package.

[0087] As examples, the master device can package three files belonging to the same session (log_hash.txt, merged_logs.txt, timeline.html) using a standard compression algorithm (such as ZIP) to generate a single log package (e.g., SESSION_123.zip). Simultaneously, based on the final hash value, generation timestamp, master device ID, and other core metadata of this log package, a structured data block is constructed. This data block is encoded as a QR code image, serving as a digital credential for the log package. By scanning this QR code, users can quickly obtain the log package's metadata and use the hash value it contains to verify the integrity of the downloaded log package, ensuring that the logs have not been tampered with during transmission and storage, thus achieving secure and reliable log delivery in offline environments.

[0088] This invention provides a cross-device log processing method, which includes: obtaining capability parameters of each terminal device in a local area network (LAN), wherein the capability parameters include multiple indicator parameters reflecting the comprehensive performance capability of the terminal devices in a time synchronization scenario; using the various indicator parameters of each terminal device, electing a master device among the terminal devices and designating other terminal devices as slave devices; broadcasting a master timestamp to the slave devices through the master device, so that each slave device corrects the timestamp of its local log file based on the master timestamp; aggregating the timestamp-corrected log files of each terminal device in the LAN through the master device, and merging them into a first target log file according to sessions; generating corresponding encrypted hash values, fully sorted log files, and time sequence graph files for each first target log file; compressing and packaging the encrypted hash values, fully sorted log files, and time sequence graph files belonging to the same first target log file to generate a corresponding log package and its digital certificate, wherein the digital certificate is used to verify the log package. This invention obtains the comprehensive capability parameters of each terminal device in the local area network, intelligently elects the optimal master device and broadcasts the master timestamp, thereby enabling slave devices to accurately correct their local log timestamps. Combined with the master device's aggregation, encryption verification and unified sorting of the corrected logs, this invention effectively improves the accuracy and reliability of cross-device log time synchronization.

[0089] Optionally, in the above Figure 1Based on one or more corresponding embodiments, in another optional embodiment provided by the present invention, a master device is elected from among the terminal devices using various indicator parameters of each terminal device, which may specifically include:

[0090] For any terminal device: obtain the comprehensive performance parameters of the terminal device by using the device performance classification, network round-trip time, system load, network time synchronization freshness and corresponding indicator weights; based on the comprehensive performance parameters of each terminal device, select the master device from among the terminal devices.

[0091] Specifically, in this embodiment of the invention, for any terminal device, the performance level is first determined by reading a preset device performance rating table and combining it with the device model, and a corresponding performance score is assigned. Simultaneously, the device periodically performs network connectivity checks, pinging a specified public server to obtain network round-trip time. The device collects current system load data, including CPU utilization, memory usage, and disk I / O, and calculates a system load score. Additionally, the device queries the time interval of the most recent network time synchronization to evaluate the synchronization freshness score. The above four indicators are weighted and summed according to preset weights to calculate the device's comprehensive performance parameters. Based on the comprehensive performance parameters of each terminal device, a unique master device is elected using a priority algorithm based on numerical comparison.

[0092] As examples, embodiments of the present invention can read a pre-set "device performance rating table" (e.g., a JSON configuration file or obtained from a remote interface) after the terminal device starts up. This table predefines performance levels based on mainstream device models (e.g., high-end mobile phones, mid-range mobile phones, high-end TVs, etc.). The terminal device obtains the corresponding performance level value by matching its own device model (e.g., 1.0 for high-end mobile phones, 0.7 for mid-range mobile phones). The terminal device attempts to send a Ping probe packet to a preset public network address and records the round-trip time (RTT). Based on the measured RTT value, it is mapped to a score between 0 and 1 (e.g., 1.0 for RTT < 50ms, 0.8 for 50-100ms). The terminal device collects CPU utilization, memory usage, and disk I / O wait rate in real time through the system interface. A preset weighted calculation formula (e.g., load score = 1 - (0.4 × CPU + 0.4 × memory + 0.2 × disk)) is used for calculation, and the result is normalized to the [0,1] range, with higher values ​​indicating lower load and better status. The terminal device queries the system for the timestamp of the last successful NTP network time synchronization. Based on the interval between the current time and the last NTP synchronization time, a freshness score is calculated (e.g., less than 5 minutes equals 1.0 point, 5-30 minutes equals 0.5 points, more than 30 minutes or no synchronization equals 0.1 points). The terminal device then calculates its overall performance parameters by weighting the obtained parameter values ​​according to performance rating (30%), network RTT (30%), system load (20%), and NTP freshness (20%). In offline mode, the weight of the network RTT parameter can be zero, while the other weights are proportionally amplified.

[0093] This invention utilizes multiple metrics, including device performance ratings, network round-trip time, system load, and network time synchronization freshness, combined with preset metric weights, to calculate comprehensive performance parameters. This allows for a complete and dynamic reflection of each device's actual performance capabilities in time synchronization scenarios. Master device election based on these comprehensive performance parameters helps automatically identify the most stable and suitable device to assume the role of time reference, thereby improving the accuracy and reliability of time synchronization, ensuring the consistency and accuracy of cross-device log timestamps, and laying a reliable foundation for subsequent unified log aggregation, sorting, and security verification.

[0094] Optionally, in embodiments of the present invention, the terminal device with the largest comprehensive performance parameters among all terminal devices can be selected as the master device; in the case of multiple terminal devices with the largest comprehensive performance parameters, the terminal device with the smallest device identifier in the preset device dictionary order can be selected as the master device.

[0095] Specifically, all terminal devices broadcast their overall performance parameters and device ID to the local area network via UDP multicast. After collecting the broadcast information from all candidate devices, the election algorithm selects the device with the highest overall performance parameters. If multiple terminal devices have the same highest overall performance parameters, the device with the smallest device ID in the preset lexicographical order is selected as the master device.

[0096] As examples, during the election phase, all participating devices broadcast a data packet containing their calculated overall performance parameters and their unique device ID to the local area network via UDP multicast. Each device listens for and collects broadcast information from all other candidate devices within a pre-defined collection time window. After collection, each device independently compares the parameters of all received candidate devices locally and selects the device with the highest overall performance parameter value. If this "maximum value" is unique, the device is determined as the master device for this election. During the comparison process, if two or more devices have identical overall performance parameter values, both being the maximum, a fallback strategy is triggered. In this case, the comparison algorithm selects the device identifier string from these parallel devices and compares them according to a pre-defined lexicographical order (e.g., ASCII code order). The device with the smallest device identifier in the lexicographical order is elected as the master device. For example, if the IDs of parallel devices are "device_abc" and "device_abd", then "device_abc" will be selected as the master device.

[0097] This invention elects a master device based on the comprehensive performance parameters of each terminal device, ensuring that the selected master device has optimal performance in terms of network status, performance, load, and time synchronization, thereby improving the accuracy and stability of time synchronization in the entire local area network environment. When the comprehensive performance parameters of multiple devices are the same, a fallback election is performed by using the lexicographical order of the device identifiers, which can effectively avoid uncertainties and conflicts in the master selection process, ensuring that the master device election result is unique and efficient, and realizing an automated and highly reliable master device determination mechanism.

[0098] Optionally, in the above Figure 1 Based on one or more corresponding embodiments, in another optional embodiment provided by the present invention, step S120 may specifically include:

[0099] The master device broadcasts the master timestamp to the slave devices, enabling each slave device to calculate its own time offset using its slave timestamp, master timestamp, and error compensation coefficient. The time offset is then used to correct the timestamp of the slave device's local log file. The error compensation coefficient is dynamically adjusted based on the estimated network latency of the local area network to ensure that the time offset is less than or equal to a preset threshold.

[0100] To achieve unified log timestamps across devices, this embodiment of the invention employs a lightweight time synchronization protocol. First, the elected master device broadcasts a data packet via UDP to all slave devices within the local area network at fixed intervals (e.g., every 5 minutes). The core content of this data packet is the master timestamp (e.g., the master device's own NTP calibration time). Upon receiving this broadcast packet, each slave device immediately records its current NTP calibration time as its slave timestamp. To accurately calculate time deviation, the system introduces an error compensation coefficient. This coefficient is not a fixed value but is dynamically adjusted based on a real-time estimate of the current local area network latency (e.g., estimating one-way latency by calculating the nanosecond difference between data packet transmission and reception). Subsequently, each slave device independently calculates its own time offset using the acquired master timestamp, its own recorded slave timestamp, and the dynamically calculated error compensation coefficient, through a specific formula (e.g., (master timestamp - slave timestamp) × (1 + error compensation coefficient)). This calculation mechanism aims to ensure, through dynamic calibration, that the final time offset is less than or equal to a preset threshold (e.g., 5 milliseconds). Ultimately, when generating local log files, each slave device does not modify its operating system clock. Instead, it only applies the calculated time offset to the log recording process, that is, it corrects the original timestamp of each log entry, so that the logs generated by all devices maintain high-precision synchronization under a unified time base.

[0101] This invention, through a master device broadcasting a master timestamp to a slave device, allows the slave device to calculate an accurate time offset by combining its own local timestamp, the received master timestamp, and an error compensation coefficient dynamically adjusted based on local area network latency. This time offset is then used to correct the timestamp of the local log file. This effectively eliminates time errors caused by network latency and device clock differences, ensuring that log time consistency and synchronization accuracy remain stable within a preset threshold. This not only improves the accuracy of cross-device log time alignment but also enhances the system's adaptability to network fluctuations, ensuring the reliability and aggregability of log data. Consequently, it provides an accurate time basis for subsequent log merging, sorting, and time-series analysis, significantly improving debugging efficiency and the accuracy of problem localization.

[0102] Optionally, in the above Figure 1 Based on one or more corresponding embodiments, in another optional embodiment provided by the present invention, step S120 may specifically include:

[0103] The master device broadcasts a time synchronization packet to the slave device, which includes a master timestamp and a sending time. When either slave device receives the time synchronization packet, it calculates the network latency based on the receiving and sending times. Using the master timestamp and the network latency, it obtains a time offset. It then determines whether the time offset is greater than or equal to a preset time offset threshold. If it is, when the slave device generates a local log file, it adds the local system time to the time offset to obtain the timestamp of the local log file. If not, it smooths the time offset, adding the smoothed time offset to the local system time when the slave device generates the local log file to obtain the timestamp of the local log file.

[0104] Specifically, in this embodiment of the invention, when the time offset is greater than or equal to a preset time offset threshold, a fast correction algorithm can be used to directly apply the time offset. When the absolute value of the first time offset is less than the preset time offset threshold, a smooth tracking algorithm is used to smooth the time offset before applying the smoothed time offset.

[0105] The fast correction algorithm refers to directly applying the first time offset when the absolute value of the time offset is greater than or equal to the preset time offset threshold, i.e., timeOffset=newOffset.

[0106] The smooth tracking algorithm refers to using a low-pass filtering algorithm to smooth the time offset when the absolute value of the time offset is less than a preset time offset threshold. For example: timeOffset = timeOffset × 0.7 + newOffset × 0.3. This formula assigns 70% weight to historical offsets and 30% weight to newly calculated offsets, thus smoothly updating the final timeOffset.

[0107] The elected master device will send a structured time synchronization data packet to the broadcast address within the local area network via UDP at a preset fixed period (e.g., every 5 minutes or 300 seconds). This data packet contains at least two key pieces of information: one is the master timestamp in milliseconds, indicating the master device's corrected system time when constructing this data packet; the other is the send time (sendNanoTime), a high-precision nanosecond timestamp recorded by the master device before sending the data packet by calling a high-precision system timer (such as System.nanoTime()) and included in the data packet for subsequent delay calculations.

[0108] When any slave device listens for and receives this UDP broadcast packet, it immediately calls its own system high-precision timer to record the reception time (recvNanoTime) the instant the data link layer reception is completed. Subsequently, the slave device parses the data packet and extracts the sendNanoTime recorded by the master device. The network latency (estimatedDelayMs) is estimated using the following formula: (recvNanoTime - sendNanoTime) / 2000000. Dividing by 2000000 here converts nanoseconds to milliseconds and takes the one-way latency estimate, assuming the round-trip latency is evenly distributed, to obtain the one-way network latency in milliseconds.

[0109] After calculating the network latency, the slave device uses the parsed master timestamp to make further calculations. First, it estimates the master device's time at the moment of reception as: estimatedMasterTime = masterTimestamp + estimatedDelayMs. Then, the slave device reads its own current system time (System.currentTimeMillis()), subtracts the estimated master device time from its own system time, and calculates the initial time offset (newOffset) using the formula: estimatedMasterTime - System.currentTimeMillis(). This value represents a rough deviation of the slave device's time relative to the master device's time.

[0110] The device determines whether to use fast correction or smooth tracking by comparing the absolute value of the time offset with a preset time offset threshold (e.g., 1000ms).

[0111] 1. Fast correction: When |newOffset|≥1000ms, newOffset is directly used as the final offset (timeOffset=newOffset) to quickly reduce the time difference between master and slave devices.

[0112] 2. Smooth Tracking: When |newOffset| < 1000ms, a low-pass filtering algorithm is used to smooth newOffset. For example: timeOffset = timeOffset × 0.7 + newOffset × 0.3. This formula assigns 70% weight to historical offsets and 30% weight to newly calculated offsets, thus smoothly updating the final timeOffset.

[0113] Subsequently, when any local log entry is generated from the device's application, its timestamp no longer uses the system time directly. Instead, the local system time is added to the time offset to generate a corrected timestamp for logging that is aligned with the master device's time base.

[0114] This invention further introduces a time synchronization algorithm that combines fast correction and smooth tracking. When the time difference between the master and slave devices is large, fast correction is used, and when the time difference is small, smooth tracking is used, which effectively solves the problem of slow time convergence and further improves the time synchronization accuracy.

[0115] Optionally, in the above Figure 1 Based on one or more corresponding embodiments, in another optional embodiment provided by the present invention, before merging the first target log file by session, the method may further include:

[0116] When a cross-device interaction is initiated between the master device and the slave device, a session identifier is generated and transmitted to all participating devices through the service channel, so that each participating device stores the session identifier, the corrected log timestamp, the device identifier, the event type, and additional information as log entries when recording logs.

[0117] Specifically, when the master device initiates cross-device interaction, it uses a random number generation algorithm to dynamically generate a unique session identifier to identify the current cross-device collaboration session. The master device then sends the generated session identifier to all participating devices via a service channel. The message body typically includes the session identifier and necessary session parameters to ensure that each device can correctly receive and recognize the session identifier.

[0118] refer to Figure 2The log entry structure shown illustrates how each device enters a session context after receiving the sessionId. When a device triggers a critical business event, it automatically calls the unified logging interface (e.g., CrossDeviceLogger.log) and fills the log with the following fields: otimestamp: corrected timestamp (ms); odeviceId: unique device ID; odeviceType: phone / tv / sdk; session: session ID; oevent: event type; opayload: JSON record of additional information, which can be expanded (e.g., what specific data happened? Are the parameters abnormal? What is the context state?); othread: current thread name, important context information; olocation: call location (filename:line number), e.g., the log directly displays KTVAudioPlayer.java:215. All logs are stored in a local log file or log database in a standardized format (e.g., JSON or database table structure) according to the above fields.

[0119] As examples, when a user clicks "Cast to TV" on their phone, the device that initiated the interaction request serves as the starting point of the session. This device can use the UUID v4 algorithm to generate a globally unique string as the session ID for this cross-device interaction. This session ID remains unchanged throughout the entire interaction's lifecycle and is used to correlate the scattered logs of all participating devices into a complete event chain. The generated session ID is not transmitted through a dedicated channel used for time synchronization or log aggregation, but rather through a business channel that supports the interaction itself. For example, in a screen casting scenario, this session ID can be embedded in the HTTP header of the screen casting request, the WebSocket handshake message, or the header of a data packet in a business-custom protocol. All devices that receive this business request and participate in subsequent interactions (such as the target TV, audio processing SDK, etc.) parse this session ID from the business channel and store it in their local context.

[0120] When any participating device (whether master or slave) needs to log at a critical path in its code (such as receiving a request, starting processing, encountering an error, or completing a task), it first retrieves the Session ID of the current interaction from its local context. Then, it calls a unified logging interface to write this session identifier as a mandatory field into the upcoming log entry. In this way, each log entry naturally carries its associated business session tag. Simultaneously with writing the Session ID, the logging process populates other structured fields: 1. A log timestamp corrected by the time synchronization service module, aligned with the master device's time base. 2. A unique device identifier (deviceId) for the local machine. 3. A specific event type (e.g., screen_cast_start, audio_decode_error) based on the action or state represented by the current log point. Finally, detailed information related to this event (such as parameters, status codes, and error messages) is serialized in JSON format and stored as additional information (payload). Ultimately, all these fields together constitute a structured, associative, and sortable complete log entry, persisted to local storage.

[0121] This invention generates a unique session identifier when cross-device interaction is initiated between the master and slave devices, and transmits it in real time to all participating devices through a service channel. This allows each device to uniformly label its log entries with this session identifier. Combined with a corrected high-precision timestamp, device identifier, event type, and rich additional information, the integrity and consistency of log entries are guaranteed. This not only achieves accurate cross-device log association and context restoration, improving log merging quality and the accuracy of time-series analysis, but also facilitates session-level problem tracking and localization, significantly improving debugging efficiency and the reliability of system fault diagnosis. This lays a reliable data foundation for subsequent merging of the first target log file by session, ensuring the integrity and security of subsequent log packets.

[0122] Optional, based on Figure 1 The method shown is as follows: Figure 3 As shown, this is a flowchart illustrating another embodiment of the cross-device log processing method provided by this invention. Before step S100, the method may further include:

[0123] S10. Check if the cloud service network is connected. If not, proceed to step S100; if yes, proceed to step S200.

[0124] Specifically, any device can test network connectivity by sending an HTTP request (such as a GET request to access a preset cloud health check interface). If the server returns an HTTP 200 response, the cloud service is deemed available, and the device enters cloud aggregation mode; otherwise, it enters LAN aggregation mode.

[0125] S200. Upload the local logs of each terminal device to the cloud server, so that the cloud server can merge the uploaded local logs into a second target log file according to the session, and generate cloud aggregated logs and visual time-series reports based on each second target log file.

[0126] Specifically, once all participating devices detect cloud accessibility, they initiate the local log upload process. Devices filter out unuploaded log data from their local cache (such as an SQLite database or file system), organize it according to a unified data format (including uniformly corrected timestamps, device IDs, session IDs, event types, etc.), and prepare for batch or incremental upload. Each device sends an HTTP POST request to the designated interface of the cloud log management service (e.g., / upload), along with the corresponding session identifier (sessionId) and log content. The upload process supports breakpoint resumption and retry mechanisms to ensure complete and reliable transmission of log data.

[0127] After receiving log data from multiple devices, the cloud server groups the logs according to session IDs. Within each session ID, the logs are globally sorted based on their corrected timestamps, generating a second target log file. This file ensures consistent log timing across devices, facilitating unified analysis. Based on the merged second target log file, the cloud service further generates a structured aggregated log file (e.g., JSON format) and a corresponding HTML-formatted visual time-series report. The report displays the event time-series chain by session and supports features such as anomaly highlighting and interactive annotation, enabling engineers to remotely debug and analyze the data.

[0128] To facilitate understanding of the dual-mode adaptive log aggregation process in the cross-device log processing method provided in this embodiment of the invention, this section combines... Figure 4 Explanation: Figure 4The diagram shows the logical block diagram of the dual-mode adaptive log aggregation process provided in this embodiment of the invention. The left side represents the cloud aggregation mode, and the right side represents the local area network (LAN) aggregation mode. The dual-mode adaptive log aggregation process aims to achieve efficient merging and secure management of log data across device environments, supporting automatic switching between cloud internet environments and LAN environments without network connectivity. When a user triggers the generation of debug log packages, any device first attempts to access a preset cloud log service address to test network connectivity. If the cloud service responds normally (HTTP 200), it prioritizes entering the cloud aggregation mode. At this time, all participating devices upload their locally cached log data in parallel. The upload request includes the corresponding session identifier (sessionId) to ensure cross-device association of log data. After receiving the logs, the cloud service groups the logs according to the session identifier and sorts them globally in ascending order of timestamp. Based on the merged log data, the cloud further generates a structured JSON format aggregated log file and a corresponding HTML format visual time-series report, which developers can obtain via download links or push notifications for convenient remote debugging and analysis.

[0129] When cloud services become inaccessible, the system automatically enters LAN aggregation mode. First, a "log aggregation host" is automatically elected within the LAN, prioritizing the current time synchronization master device or the device with the lowest load. The aggregation host starts a lightweight HTTP service (default listening port 8080) and exposes the following interfaces: a root path interface returns the upload page, a POST interface receives log files uploaded by other devices, and a GET interface provides a downloadable compressed log package based on session identifiers. The aggregation host broadcasts its IP address and service port information via UDP, notifying other devices to upload logs. Upon receiving the broadcast, each device uploads its local log files (supporting SQLite or JSON format) to the host via an HTTP POST request. After receiving all device logs, the aggregation host merges them according to session identifiers and globally sorts them based on timestamps. It then generates a ZIP archive containing the complete sorted logs (merged_logs.txt), a cross-device session event chain sequence diagram (timeline.html), and log file hash values ​​(log_hash.txt). Meanwhile, the system generates a QR code containing information such as the encrypted hash value of the log packet, the generation timestamp, and the master device identifier. Developers can scan the code to verify the integrity of the log and obtain the log through a local area network download link. This enables automatic integrity verification of log packets in offline environments, effectively avoiding manual merging errors and significantly improving on-site debugging efficiency.

[0130] In addition, the LAN aggregation mode supports one-click cloud re-upload after network recovery. Users can upload locally generated ZIP log packages to the cloud through the interface, realizing centralized management and long-term storage of logs.

[0131] The dual-mode adaptive log aggregation switching mechanism provided in this embodiment of the invention can intelligently sense the network environment, automatically select the optimal log merging path, and take into account efficiency, reliability and security, so as to meet the diverse needs of cross-device log processing.

[0132] Although the operations are described in a specific order, this should not be construed as requiring these operations to be performed in the specific order shown or in a sequential order. In certain environments, multitasking and parallel processing may be advantageous.

[0133] It should be understood that the various steps described in the method embodiments of the present invention may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of the present invention is not limited in this respect.

[0134] Corresponding to the above method embodiments, this invention also provides a cross-device log processing apparatus, the structure of which is as follows: Figure 5 As shown, it may include: a capability parameter acquisition unit 10, a master device election unit 20, a master timestamp broadcasting unit 30, a first target log file merging unit 40, a file generation unit 50, and a log compression and packaging unit 60.

[0135] Capability parameter acquisition unit 10 is used to acquire capability parameters of each terminal device in the local area network. The capability parameters include multiple indicator parameters that reflect the comprehensive performance capability of the terminal device in the time synchronization scenario.

[0136] The master device election unit 20 is used to select a master device from among the terminal devices by using various index parameters of each terminal device, and to treat other terminal devices as slave devices.

[0137] The master timestamp broadcasting unit 30 is used to broadcast the master timestamp to the slave devices through the master device, so that each slave device can correct the timestamp of its local log file based on the master timestamp;

[0138] The first target log file merging unit 40 is used to aggregate the timestamp-corrected log files of each terminal device in the local area network through the master device, and merge them into the first target log file according to the session.

[0139] The file generation unit 50 is used to generate corresponding encrypted hash values, complete sorted log files, and time sequence diagram files for each first target log file.

[0140] The log compression and packaging unit 60 is used to compress and package the encrypted hash value, the complete sorted log file and the time sequence diagram file that belong to the same first target log file, and generate the corresponding log package and its digital certificate. The digital certificate is used to verify the log package.

[0141] Optional capability parameters include the terminal device's performance rating, network round-trip time, system load, and network time synchronization freshness.

[0142] Optionally, the master device election unit 20 may include: a comprehensive performance parameter acquisition subunit and an election subunit.

[0143] The comprehensive performance parameter acquisition subunit is used to obtain the comprehensive performance parameters of any terminal device by utilizing the device performance classification, network round-trip time, system load, network time synchronization freshness and corresponding indicator weights of the terminal device.

[0144] The election subunit is used to elect a master device from among the terminal devices based on the comprehensive performance parameters of each terminal device.

[0145] The capability parameters also include the device identifier of the terminal device.

[0146] Optionally, the election subunit can be used to elect the terminal device with the largest comprehensive performance parameters among all terminal devices as the master device; in the case of multiple terminal devices with the largest comprehensive performance parameters, the terminal device with the smallest device identifier in the preset device dictionary order is elected as the master device.

[0147] Optionally, the master timestamp broadcast unit 30 can be used to broadcast the master timestamp to the slave devices through the master device, so that each slave device can calculate the corresponding time offset using its own slave timestamp, master timestamp and error compensation coefficient, and use the time offset to correct the timestamp of the slave device's local log file. The error compensation coefficient is dynamically adjusted based on the estimated network latency of the local area network so that the time offset is less than or equal to a preset threshold.

[0148] Optionally, the master timestamp broadcast unit 30 can be used to broadcast a time synchronization packet from the master device to the slave device. The time synchronization packet includes a master timestamp and a sending time. When any slave device receives the time synchronization packet, the slave device calculates the network delay time based on the receiving time and the sending time. It then uses the master timestamp and the network delay time to obtain a time offset. It determines whether the time offset is greater than or equal to a preset time offset threshold. If it is, when the slave device generates a local log file, it adds the local system time to the time offset to obtain the timestamp of the local log file. If not, it smooths the time offset and adds the local system time to the smoothed time offset when the slave device generates the local log file to obtain the timestamp of the local log file.

[0149] Optionally, the cross-device log processing apparatus may further include: a log entry storage unit.

[0150] The log entry storage unit is used to generate a session identifier and transmit it through the service channel to all participating devices when cross-device interaction between the master device and the slave device is initiated, before the first target log file merging unit 40 merges the first target log file by session. This enables each participating device to store the session identifier, the corrected log timestamp, the device identifier, the event type, and additional information as log entries when recording logs.

[0151] Optionally, the cross-device log processing device may also include a cloud service detection unit and a local log upload unit.

[0152] The cloud service detection unit is used to detect whether the cloud service network is connected before the capability parameter acquisition unit 10 obtains the capability parameters of each terminal device in the local area network. If not, the capability parameter acquisition unit 10 is triggered; if so, the local log upload unit is triggered.

[0153] The local log upload unit is used to upload the local logs of each terminal device to the cloud server, so that the cloud server can merge the uploaded local logs into a second target log file by session, and generate cloud aggregated logs and visual time-series reports based on each second target log file.

[0154] This invention provides a cross-device log processing apparatus, which is used to: obtain capability parameters of each terminal device in a local area network (LAN), wherein the capability parameters include multiple index parameters reflecting the comprehensive performance capability of the terminal devices in a time synchronization scenario; elect a master device among the terminal devices using the various index parameters of each terminal device, and designate other terminal devices as slave devices; broadcast a master timestamp to the slave devices through the master device, so that each slave device corrects the timestamp of its local log file based on the master timestamp; aggregate the timestamp-corrected log files of each terminal device in the LAN through the master device, and merge them into a first target log file according to sessions; generate corresponding encrypted hash values, fully sorted log files, and time sequence graph files for each first target log file; compress and package the encrypted hash values, fully sorted log files, and time sequence graph files belonging to the same first target log file to generate corresponding log packages and their digital credentials, wherein the digital credentials are used to verify the log packages. This invention obtains the comprehensive capability parameters of each terminal device in the local area network, intelligently elects the optimal master device and broadcasts the master timestamp, thereby enabling slave devices to accurately correct their local log timestamps. Combined with the master device's aggregation, encryption verification and unified sorting of the corrected logs, this invention effectively improves the accuracy and reliability of cross-device log time synchronization.

[0155] Regarding the apparatus in the above embodiments, the specific manner in which each unit performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0156] The cross-device log processing device includes a processor and a memory. The aforementioned capability parameter acquisition unit 10, master device election unit 20, master timestamp broadcasting unit 30, first target log file merging unit 40, file generation unit 50, and log compression and packaging unit 60 are all stored as program units in the memory. The processor executes the aforementioned program units stored in the memory to realize the corresponding functions.

[0157] The processor contains a kernel, which retrieves the corresponding program units from memory. One or more kernels can be configured; by adjusting kernel parameters, a unified time base and log management are achieved, effectively improving the accuracy and reliability of cross-device log time synchronization and meeting the needs of multi-terminal collaborative debugging.

[0158] This invention provides a computer-readable storage medium storing a program that, when executed by a processor, implements the cross-device log processing method.

[0159] This invention provides a processor for running a program, wherein the program executes the cross-device log processing method during runtime.

[0160] like Figure 6 As shown, this embodiment of the invention provides an electronic device 1000, which includes at least one processor 1001, at least one memory 1002 connected to the processor 1001, and a bus 1003. The processor 1001 and the memory 1002 communicate with each other via the bus 1003. The processor 1001 is used to call program instructions in the memory 1002 to execute the aforementioned cross-device log processing method. The electronic device in this document can be a server, PC, PAD, mobile phone, etc.

[0161] The present invention also provides a computer program product that, when executed on an electronic device, is suitable for executing a program that initializes a cross-device log processing method step.

[0162] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatuses, electronic devices (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable device, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1A device that provides the functions specified in one or more boxes.

[0163] In a typical configuration, an electronic device includes one or more processors (CPUs), memory, and a bus. The electronic device may also include input / output interfaces, network interfaces, etc.

[0164] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, like read-only memory (ROM) or flash RAM, and memory includes at least one memory chip. Memory is an example of computer-readable media.

[0165] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0166] In the description of this invention, it should be understood that if the terms "upper", "lower", "front", "rear", "left" and "right" are used to indicate the orientation or positional relationship based on the orientation or positional relationship shown in the drawings, they are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the position or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this invention.

[0167] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0168] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0169] The above are merely embodiments of the present invention and are not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of the present invention should be included within the scope of the present invention.

Claims

1. A cross-device log processing method, characterized in that, include: Obtain the capability parameters of each terminal device within the local area network, wherein the capability parameters include multiple indicator parameters reflecting the comprehensive performance capability of the terminal device in a time synchronization scenario; Using the various index parameters of each of the terminal devices, a master device is elected from among the terminal devices, and the other terminal devices are designated as slave devices. The master device broadcasts a master timestamp to the slave devices, so that each slave device can correct the timestamp of its local log file based on the master timestamp. The master device aggregates the timestamp-corrected log files of each terminal device in the local area network and merges them into a first target log file according to the session. For each of the first target log files, generate the corresponding encrypted hash value, a fully sorted log file, and a time sequence diagram file; The encrypted hash value, the complete sorted log file, and the time sequence graph file, which belong to the same first target log file, are compressed and packaged to generate a corresponding log package and its digital certificate, wherein the digital certificate is used to verify the log package.

2. The method according to claim 1, characterized in that, The capability parameters include the device performance rating, network round-trip time, system load, and network time synchronization freshness of the terminal devices. The process of selecting a master device from among the terminal devices using these parameters includes: For any of the terminal devices: the comprehensive performance parameters of the terminal device are obtained by using the device performance rating, network round-trip time, system load, network time synchronization freshness and corresponding indicator weights of the terminal device; Based on the comprehensive performance parameters of each terminal device, a master device is elected from among the terminal devices.

3. The method according to claim 2, characterized in that, The capability parameters also include the device identifier of the terminal device, and the process of electing a master device from among the terminal devices based on the comprehensive performance parameters of each terminal device includes: Among all the terminal devices, the terminal device with the largest comprehensive performance parameter is selected as the master device; In the case where there are multiple terminal devices with the largest comprehensive performance parameters, the terminal device with the smallest device identifier in the preset device dictionary order is elected as the master device.

4. The method according to claim 1, characterized in that, The step of broadcasting a master timestamp to the slave devices via the master device, so that each slave device can correct the timestamp of its local log file based on the master timestamp, includes: The master device broadcasts a master timestamp to the slave devices, so that each slave device can calculate its corresponding time offset using its own slave timestamp, the master timestamp, and an error compensation coefficient. The time offset is then used to correct the timestamp of the slave device's local log file. The error compensation coefficient is dynamically adjusted based on the estimated network latency of the local area network to ensure that the time offset is less than or equal to a preset threshold.

5. The method according to claim 1, characterized in that, The step of broadcasting a master timestamp to the slave devices via the master device, so that each slave device can correct the timestamp of its local log file based on the master timestamp, includes: The master device broadcasts a time synchronization packet to the slave device, wherein the time synchronization packet includes a master timestamp and a sending time; In the event that any of the slave devices receives the time synchronization packet, the slave device calculates the network latency based on the reception time and the transmission time; The time offset is obtained using the master timestamp and the network latency. If the time offset is greater than or equal to a preset time offset threshold, then when the slave device generates a local log file, the local system time is added to the time offset to obtain the timestamp of the local log file. If not, the time offset is smoothed, and when the slave device generates a local log file, the local system time is added to the smoothed time offset to obtain the timestamp of the local log file.

6. The method according to claim 1, characterized in that, Before merging the first target log file by session, the method further includes: When a cross-device interaction is initiated between the master device and the slave device, a session identifier is generated and transparently transmitted to all participating devices through a service channel, so that each participating device stores the session identifier, the corrected log timestamp, the device identifier, the event type, and additional information as log entries when recording logs.

7. The method according to any one of claims 1 to 6, characterized in that, Before obtaining the capability parameters of each terminal device within the local area network, the method further includes: The system checks whether the cloud service network is connected. If not, it obtains the capability parameters of each terminal device in the local area network. If so, it uploads the local logs of each terminal device to the cloud server, so that the cloud server can merge the uploaded local logs into a second target log file by session, and generate a cloud aggregated log and a visual time-series report based on each second target log file.

8. A cross-device log processing apparatus, characterized in that, include: The system includes a capability parameter acquisition unit, a master device election unit, a master timestamp broadcasting unit, a first target log file merging unit, a file generation unit, and a log compression and packaging unit. The capability parameter acquisition unit is used to obtain the capability parameters of each terminal device in the local area network, wherein the capability parameters include multiple index parameters that reflect the comprehensive performance capability of the terminal device in the time synchronization scenario. The master device election unit is used to elect a master device from among the terminal devices by using the various index parameters of each terminal device, and to treat other terminal devices as slave devices. The master timestamp broadcasting unit is used to broadcast the master timestamp to the slave devices through the master device, so that each slave device can correct the timestamp of its local log file based on the master timestamp; The first target log file merging unit is used to aggregate the timestamp-corrected log files of each terminal device in the local area network through the master device, and merge them into a first target log file according to session; The file generation unit is used to generate corresponding encrypted hash values, complete sorted log files, and time sequence diagram files for each of the first target log files; The log compression and packaging unit is used to compress and package the encrypted hash value, the complete sorted log file, and the time sequence diagram file that belong to the same first target log file to generate a corresponding log package and its digital certificate, wherein the digital certificate is used to verify the log package.

9. A computer-readable storage medium having a program stored thereon, characterized in that, When the program is executed by the processor, it implements the cross-device log processing method as described in any one of claims 1 to 7.

10. An electronic device, characterized in that, The electronic device includes at least one processor, at least one memory connected to the processor, and a bus; wherein the processor and the memory communicate with each other through the bus; the processor is used to call program instructions in the memory to execute the cross-device log processing method as described in any one of claims 1 to 7.

Images