Method, device and equipment for testing vehicle terminal reconnection delay and storage medium

Abstract

The application discloses a kind of vehicle terminal reconnection latency test method, device, equipment and storage medium, method includes the starting time of the terminal to be measured is recorded;In response to the starting time, the data of the host control interface for establishing wireless connection with mobile terminal is monitored, the occurrence time of the first target event is obtained as the connection completion event when the first wireless link is established;The data of the wireless screen projection session of mobile terminal is monitored, and the sending time of the display configuration response message is obtained as the occurrence time of the second target event;According to the occurrence time of second target event and the preset interface rendering delay, the screen projection interface display time is determined;According to the starting time, the occurrence time of first target event and screen projection interface display time, the reconnection session starting delay is determined.The application eliminates the timing deviation caused by application layer scheduling, truly restores the whole process delay of message interaction to screen rendering completion, improves the accuracy and effectiveness of test result.

Description

Technical Field

[0001] This invention relates to the technical field of communication performance testing technology, and in particular to a method, apparatus, equipment and storage medium for testing the reconnection latency of a vehicle-mounted terminal. Background Technology

[0002] With the rapid development of intelligent connected vehicle technology, wireless screen projection technology between in-vehicle terminals and mobile terminals has been widely applied. In such application scenarios, the startup latency of establishing a wireless reconnection session between the in-vehicle terminal and the mobile terminal after a cold or warm start directly affects the user's interactive experience. Therefore, accurate measurement of the reconnection session startup latency is particularly important during product certification and R&D testing. Existing technologies typically focus on two key phases for testing wireless reconnection latency: the physical link establishment time from system startup to the completion of Bluetooth paging broadcast, and the session negotiation time from link establishment to successful rendering and display of the projection interface. To quantify these metrics, most industry players use professional Bluetooth air interface packet capture analyzers or dedicated testing applications based on the mobile terminal side for data collection and latency calculation.

[0003] Existing testing technologies have some shortcomings in practical applications. On the one hand, while professional Bluetooth air interface analyzers can accurately capture paging broadcast packets at the radio frequency layer, such equipment is extremely expensive and has stringent testing environment requirements, making it difficult to conduct high-frequency self-testing in the early stages of R&D. On the other hand, when using dedicated testing applications on the mobile terminal side for latency measurement, the link establishment timestamp recorded by the application runs on a higher-level protocol stack, resulting in an unavoidable system-level deviation between the application's recorded timestamp and the actual broadcast time sent by the underlying radio frequency. Furthermore, the application's determination of the screen display time often relies on application-layer callbacks, failing to accurately reflect the entire latency process from the sending of the underlying display configuration response message to the actual rendering of the screen. This leads to test results that are smaller than the actual values, failing to accurately expose reconnection timeout issues. This testing bias makes it difficult for early self-test results to be consistent with certification results from authoritative third-party laboratories, seriously affecting the effectiveness of testing and the accuracy of product iteration. Summary of the Invention

[0004] To overcome the shortcomings of existing technical solutions, embodiments of the present invention provide a method, apparatus, device, and storage medium for testing the reconnection latency of vehicle-mounted terminals.

[0005] The technical solution adopted by this invention to solve its technical problem is: In a first aspect, the present invention provides a method for testing the reconnection latency of an in-vehicle terminal, the testing method comprising: Record the startup time of the terminal under test; In response to the startup time, the occurrence time of the first target event is obtained by monitoring the data of the host control interface that establishes a wireless connection with the mobile terminal, wherein the first target event is a connection completion event sent when the wireless link is first established; Monitor the data of the wireless screen projection session of the mobile terminal to obtain the occurrence time of the second target event, wherein the second target event is the time when the display configuration response message is sent; The screen projection interface display time is determined based on the occurrence time of the second target event and the preset interface rendering delay. The reconnection session startup delay is determined based on the startup time, the occurrence time of the first target event, and the display time of the projection interface.

[0006] Secondly, the present invention provides a testing device for reconnection latency of an in-vehicle terminal, the testing device comprising: The recording module is used to record the startup time of the terminal under test; The first acquisition module is used to acquire the occurrence time of the first target event by monitoring the data of the host control interface that establishes a wireless connection with the mobile terminal in response to the start time, wherein the first target event is a connection completion event sent when the wireless link is first established. The second acquisition module is used to monitor the data of the wireless screen projection session of the mobile terminal to obtain the occurrence time of the second target event, wherein the second target event is the sending time of the display configuration response message; The first determining module is used to determine the display time of the projection interface based on the occurrence time of the second target event and the preset interface rendering delay. The second determining module is used to determine the reconnection session startup delay based on the startup time, the occurrence time of the first target event, and the display time of the projection interface.

[0007] Thirdly, the present invention provides a computer device, the computer device including a processor, a network interface, a memory and a communication bus, wherein the processor, the network interface and the memory communicate with each other through the communication bus; Memory, used to store computer programs; The processor, when executing a program stored in memory, implements the steps of the method for testing the reconnection delay of the vehicle terminal as described in any of the first aspects above.

[0008] Fourthly, the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the test method for vehicle terminal reconnection latency as described in any one of the first aspects above.

[0009] Compared with the prior art, the beneficial effects of the present invention are: By monitoring host control interface data, the connection completion event at the moment the wireless link is first established is extracted as the occurrence time of the first target event. The underlying protocol data is used to replace the capture of air interface radio frequency packets, which not only eliminates expensive hardware but also eliminates timing deviations caused by application layer scheduling delays. At the same time, by monitoring wireless screen projection session data to obtain the time of sending display configuration response messages and superimposing a preset interface rendering delay, the time of display of the screen projection interface is determined, which truly restores the entire process delay from underlying message interaction to the actual completion of screen rendering. Finally, the total delay of reconnection session startup is accurately calculated by combining the startup time, which effectively eliminates the systematic deviation between the results of previous self-testing and third-party laboratory certification, ensuring that the test results can truly expose potential timeout issues, thereby improving the effectiveness of the test. Attached Figure Description

[0010] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is a flowchart of the steps of the test method for reconnection latency of vehicle terminal according to an embodiment of the present invention.

[0012] Figure 2 This is a flowchart illustrating the specific steps of step S120 in an embodiment of the present invention.

[0013] Figure 3 This is a flowchart illustrating the specific steps of step S130 in an embodiment of the present invention.

[0014] Figure 4 This is a flowchart illustrating the specific steps of step S150 in an embodiment of the present invention.

[0015] Figure 5 This is a schematic diagram illustrating an application scenario of the vehicle terminal reconnection latency testing method according to an embodiment of the present invention.

[0016] Figure 6 This is a block diagram of a test device for vehicle terminal reconnection delay according to an embodiment of the present invention.

[0017] Figure 7 This is a schematic block diagram of a computer device according to an embodiment of the present invention. Detailed Implementation

[0018] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0020] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0021] It should also be further understood that the term "and / or" as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0022] To address the issues of high cost and limited availability of professional air interface analyzers in existing technologies, and the system-level discrepancy between the underlying link establishment timestamp and interface rendering latency determination caused by system scheduling in application-layer-based dedicated testing programs, which leads to inconsistencies between initial self-test results and third-party laboratory certification results and fails to accurately expose the true reconnection timeout problem, this invention provides a testing method, apparatus, device, and storage medium for vehicle-mounted terminal reconnection latency.

[0023] The following details the specific steps of a test method for reconnection latency of a vehicle terminal provided by an embodiment of the present invention. Figure 5 As shown, the test method is applied to the test terminal 10 to execute the stored software program to implement the above-mentioned test method for the wireless reconnection session startup latency of the vehicle terminal. The test terminal 10 is communicatively connected to at least one terminal under test 20 and a mobile terminal 30. It can be understood that the test terminal 10 in this embodiment is a computer device used for wireless reconnection latency testing and data analysis, such as a portable computer, desktop computer, or test server, which runs packet capture tools and automated test scripts internally. The terminal under test 20 is the vehicle terminal to be evaluated, such as a vehicle infotainment system. The mobile terminal 30 is a portable device, such as a smartphone, that establishes a wireless screen projection connection with the terminal under test.

[0024] According to the appendix Figures 1-4 As shown, the specific steps of the test method for the reconnection latency of the vehicle terminal include the following: Step S110: Record the startup time of the terminal under test.

[0025] Specifically, the terminal under test (DUT) enters a startup process upon receiving a trigger command. This startup process can include a cold start, such as a power-on startup after a complete system power failure, or a warm start, such as a wake-up startup after system hibernation. Recording the startup time of the DUT can be performed by the test host. The test host establishes a communication connection with the DUT, which can include a Universal Serial Bus (USB) connection, a Universal Asynchronous Receiver / Transmitter (UART) serial port connection, or an in-vehicle Ethernet connection. When the DUT receives an ignition signal or a wake-up signal, the underlying hardware generates a level transition, and the DUT's Basic Input / Output System (BIS) or underlying bootloader begins execution. At this time, the DUT sends a startup indication signal to the test host through the aforementioned communication connection. Upon detecting this startup indication signal, the test host calls its local high-precision system clock to record the current timestamp, which is used as the startup time of the DUT.

[0026] In some alternative implementations, this step specifically includes the test host continuously monitoring the status of the target communication port; triggering a timing interrupt in response to detecting a startup status code or hardware level change sent by the terminal under test; obtaining the current system time of the test host and formatting it as an absolute timestamp.

[0027] The start time will serve as the time reference for subsequent latency calculations. This start time is recorded and stored in the memory or log file of the test host, waiting to be calculated by difference with the occurrence time of the first target event and the display time of the projection interface obtained in subsequent steps.

[0028] Step S120: In response to the startup time, the occurrence time of the first target event is obtained by monitoring the data of the host control interface that establishes a wireless connection with the mobile terminal. The first target event is the connection completion event sent when the wireless link is first established.

[0029] Specifically, after recording the startup time of the terminal under test (DUT), the test host immediately initiates real-time monitoring of the host control interface data stream in response to that startup time. A physical connection is established between the test host and the DUT via dual Type-C cabling. This cabling is used not only for data exchange but also for bypassing and capturing HCI communication data between the DUT's internal Bluetooth chip and the operating system protocol stack. The test host runs a packet capture tool, such as the ATS tool, which can parse HCI data packets in real time. After the DUT completes the Bluetooth module initialization during startup, it actively calls the HCI_Create_Connection command as the master device to initiate Bluetooth paging to the mobile terminal. Since there is no asynchronous connection-oriented logical transmission handle during the physical link synchronization phase, the radio frequency interaction of the air interface is difficult to capture directly. Therefore, the equivalent time point is obtained by monitoring the HCI layer's event reporting mechanism. When the underlying Bluetooth baseband completes frequency hopping synchronization and successfully establishes the physical link, the Bluetooth controller sends a connection completion event to the host.

[0030] Configure packet capture filtering rules on the test host to filter out HCI event messages with the event code "ConnectionComplete"; continuously listen for and parse HCI event streams that match the filtering rules; in response to the first connection completion event being detected, call the high-precision system clock of the test host to record the timestamp when the message was captured, and use this as the occurrence time of the first target event.

[0031] The occurrence time of the first target event represents the absolute time point when the underlying wireless link is successfully established for the first time. After this occurrence time is extracted, it will be used as the endpoint for calculating the wireless link establishment time, and also as the starting point for calculating the startup time of the subsequent screen projection session. Together with the startup time recorded in the aforementioned steps and the screen projection interface display time obtained in subsequent steps, it will participate in the final latency difference calculation.

[0032] Step S130: Monitor the data of the wireless screen projection session of the mobile terminal to obtain the occurrence time of the second target event, wherein the second target event is the time when the display configuration response message is sent.

[0033] Specifically, after the initial establishment of the underlying wireless link, the tested terminal and the mobile terminal begin protocol interaction for the upper-layer wireless screen projection session. The test host uses a continuously running packet capture tool, such as ATS, to listen to the communication ports of both parties after the connection is established, in order to capture the data stream of the wireless screen projection session. The triggering condition follows immediately after the first target event. At this stage, the tested terminal and the mobile terminal exchange screen projection configuration parameters through network layer protocols such as Transmission Control Protocol or User Datagram Protocol. The test host is configured with filtering rules for specific port numbers or protocol characteristics to separate the wireless screen projection session packets from the massive bus data. When the tested terminal sends a response packet to the mobile terminal to configure the screen display parameters, the test host recognizes the packet and records its transmission time.

[0034] Configure deep packet parsing rules for the wireless projection session protocol in the test host; monitor and parse network packet payloads that conform to the rules in real time; respond to the parsed payload feature fields that match the configuration response, such as the SETUP Response-Screen message in the CarPlay protocol, call the high-precision system clock of the test host to record the timestamp of the message sent, and use it as the occurrence time of the second target event.

[0035] The occurrence time of the second target event represents the absolute time point when the upper-level screen projection session display configuration negotiation is completed. After this occurrence time is extracted, it serves as the core benchmark for calculating the screen projection interface display time. It has a temporal connection with the occurrence time of the first target event obtained in the previous step, and participates in subsequent calculations together with the preset interface rendering delay.

[0036] Therefore, by decoupling the uncontrollable UI rendering scheduling process at the application layer from the deterministic message interaction process at the protocol layer, and using the specific message sending time as the calculation benchmark, the system scheduling error of several seconds caused by the test application's point-by-point operation at the application layer in related technologies is avoided. Moreover, it can be achieved based on the software packet capture capability of existing debugging tools, without relying on expensive air interface RF analyzers. This reduces testing costs while ensuring the objectivity and reproducibility of time points.

[0037] Step S140: Determine the display time of the projection interface based on the occurrence time of the second target event and the preset interface rendering delay.

[0038] Specifically, after obtaining the occurrence time of the second target event, since there is a fixed hardware processing and graphics rendering time from the time the message is sent to the actual rendering and display of the projection interface on the screen of the tested terminal, this step calculates the actual time when the projection interface is fully displayed by superimposing the occurrence time with the preset interface rendering delay.

[0039] It should be noted that the preset interface rendering latency is a pre-calibrated empirical parameter. This interface rendering latency can be obtained by acquiring multiple sets of video streams from historical test processes using a high-speed camera, and analyzing the difference between the message sending time and the UI pixel change time frame by frame at a high frame rate, and averaging the multiple sets of differences; for example, the preset interface rendering latency can be calibrated to 500 milliseconds.

[0040] When the occurrence time of the second target event extracted in the aforementioned steps is input, along with the interface rendering latency pre-stored in the test system configuration file, the screen projection interface display time is output by performing a positive offset compensation calculation on the timeline. This screen projection interface display time will be used as the endpoint timestamp for calculating the total latency of the reconnection session, and will then be passed to the final latency calculation module for difference calculation with the startup time.

[0041] By recording the startup time of the terminal under test as a time reference, the system monitors the first target event of the completion of the wireless link establishment for the first time through the data acquisition of the host control interface, and monitors the second target event of the wireless screen projection session. Based on this, the system determines the screen projection interface display time by combining the preset interface rendering latency. Then, based on the startup time and the screen projection interface display time, the system accurately calculates the reconnection session startup latency, thereby effectively decoupling the protocol layer interaction and application layer rendering process, and achieving high-precision latency quantization without the need for complex image recognition intervention.

[0042] Step S150: Determine the reconnection session start delay based on the start time, the occurrence time of the first target event, and the display time of the projection interface.

[0043] Specifically, after obtaining the startup time T0 of the terminal under test, the occurrence time T1 of the first target event (i.e., the occurrence time of the connection completion event sent when the wireless link is first established), and the display time T2 of the screen projection interface, the test host calculates the reconnection session startup delay by performing time difference calculation. This delay reflects the total time consumed by the terminal under test from power-on to the final complete presentation of the wireless screen projection interface.

[0044] More specifically, the calculation of the underlying wireless link establishment time is the difference between the occurrence time of the first target event and the start time, which can be expressed as T1-T0. The calculation of the screen projection session startup and rendering time is the difference between the screen projection interface display time and the occurrence time of the first target event, which can be understood as T2-T1. Finally, the calculation of the total latency of the reconnection session startup is the difference between the screen projection interface display time and the startup time, which can be understood as T2-T0.

[0045] By receiving the three absolute timestamps T0, T1, and T2 transmitted in the aforementioned steps, the data is converted into relative latency data through subtraction. The calculated latency data can be output and displayed independently, or it can be linked with the judgment module of the test system to be compared with the latency threshold to generate a test report.

[0046] By recording the startup time of the terminal under test as a time reference, the system monitors the first target event (the completion of the initial establishment of the wireless link for data acquisition on the host control interface) and the second target event (the occurrence of the configuration response message for the wireless projection session). Combined with a preset interface rendering delay, the screen projection interface display time is determined. Based on the startup time, the occurrence time of the first target event, and the screen projection interface display time, the reconnection session startup delay is calculated. This precisely decouples and quantifies the timing of the underlying link establishment and the upper-layer interface rendering. Without requiring expensive hardware, it achieves testing accuracy highly consistent with professional-grade air interface packet capture testers, effectively improving the accuracy and reliability of wireless reconnection performance evaluation.

[0047] For example, the tester sends an IgnitionOn signal to the vehicle's infotainment system via the vehicle's ignition key or an analog signal generator. Upon detecting this ignition signal, the microcontroller at the vehicle's core immediately sends a hexadecimal "BOOT_START" status code to the Mac computer via the UART serial port. The automated test script running on the Mac computer polls the serial port data in real time. Once it parses the BOOT_START status code, it immediately calls the Mac operating system's core time API to obtain the current absolute time. For example, the obtained system time is recorded as T0=16:35:00.285. After recording the start time T0, the ATS tool on the MAC computer immediately begins real-time capture and parsing of the data stream from the vehicle's head unit control interface. After the vehicle completes the Bluetooth module initialization, it actively calls the HCI_Create_Connection command to initiate a Bluetooth paging to the iPhone. When the underlying Bluetooth baseband completes frequency hopping synchronization and successfully establishes a physical link, the vehicle's Bluetooth controller sends a connection completion event to the upper layer. The ATS tool captures this message, identifies its event code as Connection Complete, and immediately records the absolute timestamp of the current system on the MAC computer. For example, the ATS tool records the occurrence time of this first target event as T1=16:35:03.487.

[0048] After the Bluetooth link is established, the vehicle's infotainment system and the mobile terminal initiate a CarPlay session via Wi-Fi. The Mac computer continues to capture network port data packets in real time using the ATS tool, and decapsulates the data packets layer by layer using the built-in CarPlay protocol parsing module. When the vehicle's infotainment system completes the negotiation of display parameters such as screen resolution and color format, and sends a display configuration response message to the iPhone, the ATS tool captures this specific message, namely the SETUP Response-Screen message, extracts its frame header information, and adds a timestamp. For example, the occurrence time of this second target event is recorded as T2=16:35:06.895. The preset interface rendering latency Δt render=500ms corresponding to the current tested terminal model is retrieved from the configuration database. Subsequently, a time addition operation is performed to determine the actual complete display time of the projected interface as T display=T2+Δtrender=16:35:06.895+0.500s=16:35:07.395. The latency calculation module of the test host reads the three timestamps T0, T1, and Tdisplay, and performs the difference calculation to obtain: 1. Low-level wireless link establishment time = T1 - T0 = 16:35:03.487 - 16:35:00.285 = 3.202s; 2. Screen projection session startup and rendering time = Tdisplay - T1 = 16:35:07.395 - 16:35:03.487 = 3.908s; 3. Total latency of reconnection session startup = Tdisplay - T0 = 16:35:07.395 - 16:35:00.285 = 7.110s; Finally, after the test, the system automatically generates and outputs a structured JSON format test log, which includes the time base, timestamps of each key event, time of each stage, and final judgment result.

[0049] Thus, it can be seen that the test system does not need to rely on expensive air interface radio frequency analyzers to accurately reproduce and quantify the underlying link timing and upper layer rendering time of the vehicle's infotainment system from ignition to the complete display of the CarPlay interface, and the test results are highly consistent with the test results of third-party professional laboratories.

[0050] It is understood that the terminal under test in this embodiment of the invention is an in-vehicle terminal or an in-vehicle infotainment system, and the wireless screen projection session is an in-vehicle screen projection session.

[0051] In some specific embodiments, the step involves monitoring data from the host control interface that establishes a wireless connection with the mobile terminal to obtain the time of occurrence of the first target event, specifically including the following steps: Step S121: Interact with the mobile terminal using a testing tool to capture the host control interface data of the mobile terminal.

[0052] Specifically, the test host runs a test tool, namely the ATS tool. The test host establishes a physical connection with the mobile terminal via dual Type-C cables. This physical connection is used not only for power supply but also for establishing a data bypass channel. In response to the startup of the terminal under test, the test tool starts a data monitoring process. Through data interaction with the mobile terminal, it captures the host control interface data of the communication between the Bluetooth chip inside the mobile terminal and the operating system protocol stack in real time.

[0053] Optionally, the testing tool can configure packet capture filtering rules in its interface to reduce resource consumption caused by irrelevant data.

[0054] After performing the above steps, the test host will obtain a raw HCI data stream containing various commands and event messages.

[0055] Step S122: Extract the occurrence time of the first target event from the host control interface data.

[0056] Specifically, the testing tool or accompanying parsing script decapsulates and parses the captured raw HCI data stream layer by layer. After the Bluetooth baseband initiates paging and completes physical link synchronization, the underlying controller reports a connection completion event to the host. This step is executed when an event code indicating "Connection Complete" is parsed, such as an EVTConnection Complete message. Since there is no asynchronous connection-oriented logical transmission handle during the link synchronization phase, the radio frequency interaction of the air interface is difficult to capture directly. Therefore, this connection completion event is taken as the first target event, equivalent to replacing the first frame of the Bluetooth Page Broadcast packet of the air interface. When the test host parses the first connection completion event from the HCI data, it immediately calls the local high-precision system clock to record the current timestamp, which is taken as the occurrence time of the first target event. This occurrence time will be passed to the final delay calculation module for difference calculation with the start time.

[0057] In some specific embodiments, the step involves monitoring the data of the mobile terminal's wireless screen projection session to obtain the time of occurrence of the second target event, specifically including the following steps: Step S131: Use a testing tool to interact with the mobile terminal to capture wireless screen projection session data on the mobile terminal side.

[0058] Specifically, the test host runs a test tool. The test host establishes a physical connection with the mobile terminal through dual Type-C cables. After the underlying Bluetooth link is established, the tested terminal and the mobile terminal begin protocol interaction for upper-layer wireless screen projection sessions based on the Wi-Fi network. The test tool interacts with the mobile terminal through the aforementioned physical connection channel and captures the wireless screen projection session data stream generated and forwarded by the mobile terminal in real time.

[0059] Step S131: Extract the occurrence time of the second target event from the wireless screen projection session data.

[0060] Specifically, the testing tool or accompanying parsing script performs layer-by-layer decapsulation and deep message parsing on the captured wireless screen projection session data stream. During the screen projection session initialization phase, the tested terminal and the mobile terminal need to negotiate display parameters such as screen resolution and color format. When the test host parses the payload feature field and matches the display configuration response message, such as the SETUP Response-Screen message in the CarPlay protocol, the sending time of this message is defined as the second target event.

[0061] In response to the parsing of the message, the test host immediately calls the local high-precision system clock to record the current timestamp, which is used as the occurrence time of the second target event. After the occurrence time of the second target event is extracted, it will be transferred to the subsequent calculation module to calculate the display time of the projection interface in combination with the preset interface rendering delay.

[0062] Therefore, this application decouples the uncontrollable UI rendering scheduling process from the deterministic message interaction process at the protocol layer by capturing and extracting the sending time of the display configuration response message at the protocol interaction layer as the second target event. By using the specific message sending time as the calculation benchmark, it avoids the system scheduling error of several seconds caused by the test application's point-by-point operation at the application layer in related technologies. Moreover, it can be achieved based on the software packet capture capability of existing debugging tools, without relying on expensive air interface RF analyzers. This reduces testing costs while ensuring the objectivity and reproducibility of the time points.

[0063] In some specific embodiments, the steps involve determining the reconnection session startup delay based on the startup time, the occurrence time of the first target event, and the display time of the projection interface, specifically including the following steps: Step S151: Calculate the first reconnection delay based on the startup time and the occurrence time of the first target event.

[0064] Specifically, the test host's calculation module calls the start time T0 and the occurrence time T1 of the first target event recorded in the aforementioned steps, performs the first subtraction operation, and calculates the time difference between T1 and T0. This time difference is the first reconnection delay, which physically means the total time consumed by the tested terminal from power-on to the first establishment of the underlying wireless link. The data output through this step will be transferred to the total delay calculation module as the first addend, and can also be output independently to evaluate the underlying link establishment performance.

[0065] Step S152: Calculate the time difference between the occurrence time of the second target event and the occurrence time of the first target event, and calculate the sum of the first time difference and the preset interface rendering delay as the second reconnection delay.

[0066] Specifically, the computing module of the test host first calls the occurrence time T1 of the first target event and the occurrence time T2 of the second target event, performs a second subtraction operation, calculates the time difference between T2 and T1, and obtains the first time difference. This first time difference represents the protocol interaction time consumed from the completion of the establishment of the underlying wireless link to the sending of the upper-layer projection session display configuration response message. Subsequently, the computing module reads the preset interface rendering delay from the configuration database. This interface rendering delay is a fixed empirical value calibrated by the high-speed camera. The first time difference is summed with the preset interface rendering delay, and the sum obtained is the second reconnection delay. This second reconnection delay represents the total link time consumed from the completion of the establishment of the underlying link to the actual complete rendering and display of the projection interface on the screen.

[0067] Step S153: Determine the reconnection session start delay based on the first reconnection delay and the second reconnection delay.

[0068] Specifically, the test host's calculation module performs an accumulation operation on the first reconnection delay output and the second reconnection delay output by the sub-output. The sum obtained is the total reconnection session startup delay. This total delay reflects the end-to-end real time taken for the tested terminal from ignition to the final complete presentation of the wireless projection interface. After the calculation result is generated, it can be linked with the test system's judgment module to be compared with the delay threshold to generate the final test report.

[0069] For example, the start time T0 is 16:35:00.285, the occurrence time of the first target event T1 is 16:35:03.487, the occurrence time of the second target event T2 is 16:35:06.895, and the preset interface rendering delay Δt_render is 0.500s. First, calculate the first reconnection delay as T1-T0=16:35:03.487-16:35:00.285=3.202s; calculate the first time difference as T2-T1=16:35:06.895-16:35:03.487=3.408s, and calculate the second reconnection delay: first time difference + Δt_render=3.408s+0.500s=3.908s; finally, calculate the reconnection session startup delay, which is the first reconnection delay + the second reconnection delay = 3.202s+3.908s=7.110s.

[0070] In a further embodiment, in order to achieve testing accuracy highly consistent with professional-grade air interface packet capture testers, and to automatically output objective certification-level test conclusions, effectively improving the automation level and fault location efficiency of wireless reconnection performance evaluation, the testing method further includes the following steps: Determine whether the first reconnection delay is less than a first preset threshold, and determine whether the second reconnection delay is less than a second preset threshold.

[0071] Specifically, the test host's judgment module calls the first reconnection delay calculated in the pre-processing steps, which is the time elapsed from the start time to the occurrence of the first target event, representing the time elapsed for establishing the underlying wireless link. This delay is then compared with a first preset threshold value preset in the system configuration file. This first preset threshold value can be set according to specific certification specifications. For example, in some wireless Apple CarPlay certification standards, the time from power-on to the appearance of the first Bluetooth PageBroadcast is required to be no more than 2 seconds, so the first preset threshold value can be set to 2.0 seconds.

[0072] If the first reconnection delay is less than the first preset threshold and the second reconnection delay is less than the second preset threshold, then the vehicle terminal reconnection session startup delay test is deemed to have passed.

[0073] Specifically, the second reconnection latency, calculated by synchronous or asynchronous calls, is the time elapsed from the occurrence of the first target event to the display of the projection interface. This latency represents the time spent on upper-layer protocol interaction and interface rendering. The second reconnection latency is then compared with a second preset threshold in the system configuration file. This second preset threshold is also set according to the authentication specifications. For example, in the wireless Apple CarPlay authentication standard, it is required that the time from the appearance of Bluetooth Page Broadcast to the display of CarPlayUI should not exceed 3 seconds. Therefore, the second preset threshold can be set to 3.0 seconds.

[0074] Otherwise, the test for reconnection session startup latency of the vehicle terminal is deemed unsuccessful.

[0075] Specifically, a logical AND operation is performed on the first and second Boolean output values. If the first reconnection delay is less than the first preset threshold and the second reconnection delay is less than the second preset threshold, i.e., the logical operation result is true, then the vehicle terminal reconnection session startup delay test is deemed to have passed; otherwise (including cases where only one of them is not satisfied, or both are not satisfied), the vehicle terminal reconnection session startup delay test is deemed to have failed. This conclusion data is transferred to the report generation module for the output of the final test report.

[0076] For example, firstly, the first reconnection latency of 1.850s is read and compared with the first preset threshold of 2.0s. Since 1.850 < 2.0, the result is considered passed. Then, the second reconnection latency of 2.620s is read and compared with the second preset threshold of 3.0s. Since 2.620 < 3.0, the result is considered passed. Finally, the vehicle terminal reconnection session startup latency test is determined to be passed.

[0077] In some specific embodiments, the preset interface rendering latency is obtained by means of the following steps: Monitor and obtain the sending time of the display configuration response message.

[0078] Specifically, the test host interacts with the mobile terminal through the test tool, captures the data stream of the wireless screen projection session in real time, and when the load feature field is parsed to match the display configuration response message, it calls the local high-precision system clock to record the current timestamp. This sending time represents the absolute time node when the upper layer application completes the negotiation of display parameters and sends the rendering command to the graphics processing stack.

[0079] Record the screen display content of the terminal under test, and analyze the recorded video frame by frame to determine the actual time when the screen projection interface is fully rendered and appears on the screen.

[0080] Specifically, a high frame rate image acquisition device can be used to record the physical screen of the terminal under test in real time. The frame rate of the camera is set to 240 frames per second or higher to ensure that the time resolution reaches the millisecond level. The recording process needs to cover the time period before and after the display configuration response message is sent. Subsequently, the recorded video stream is analyzed frame by frame. To improve the accuracy of the analysis, the video frames can be preprocessed, such as grayscale conversion, image cropping, and Gaussian denoising. Then, feature extraction methods, such as multi-scale convolution or edge detection algorithms, are used to extract the key feature contours of the projection interface. Finally, based on classification logic, it is determined whether the current frame is the first frame to be fully rendered on the projection interface, and the timestamp corresponding to the frame is mapped to the absolute system time, which is the actual display time.

[0081] Calculate the time difference between the actual display time and the sending time, and use it as the preset interface rendering delay.

[0082] Specifically, the actual display time is subtracted from the transmission time, and the resulting time difference is the interface rendering latency for this test. To eliminate random errors from a single measurement, the above steps can be repeated multiple times, and the average of the multiple time differences can be calculated. This average is then used as the final preset interface rendering latency and stored in the configuration file. This parameter will be passed to the subsequent total latency calculation module for addition operations.

[0083] For example, the video recording is processed, and then image features are extracted and compared with a pre-stored CarPlay UI template. After analysis, it is found that the first frame (10:00:05.500) first meets the threshold for complete UI display. Therefore, the actual display time is determined to be T_display_actual=10:00:05.500, and the time difference is calculated as T_display_actual-Tsend=10:00:05.500-10:00:05.000=0.500 seconds. After averaging multiple tests, the final output preset interface rendering latency is 500ms. The final result is stored in the form of a configuration file as {"Render_Delay_Preset(ms)":500}.

[0084] In some specific embodiments, after step S130, which involves monitoring the data of the mobile terminal's wireless screen projection session to obtain the time of occurrence of the second target event, the following steps are also included: In response to the acquisition of the occurrence time T2 of the second target event, the test host sends a system resource status query request message to the terminal under test and receives the system resource status vector returned by the terminal under test.

[0085] Specifically, the tested terminal has a pre-installed lightweight resource probe daemon that listens on a specific port. When the test host parses the display configuration response message and records T2, it immediately triggers a resource query interaction. The interaction protocol includes a request message REQ_RES_STATUS containing the fields [Magic_Code (2 bytes), Req_Type (1 Byte = 0x01), Timestamp (8 bytes = T2), CRC (2 bytes)]; and a response message RES_RES_STATUS containing the fields [Magic_Code (2 bytes), Res_Type (1 Byte = 0x81), CPU_Util (2 bytes), GPU_Util (2 bytes), Mem_Avail (4 bytes), CRC (2 bytes)]. Among these, CPU_Util represents the current CPU utilization (in units of 0.1%), GPU_Util represents the current GPU utilization (in units of 0.1%), and Mem_Avail represents the available memory. The test host extracts and constructs the system resource status vector V from the response message. status =[v cpu ,v gpu ,v mem ].

[0086] The test host calculates the dynamic compensation coefficient Kadjust for rendering latency based on the system resource status vector Vstatus.

[0087] Specifically, the test host has a pre-configured baseline resource threshold vector V. threshold =[C cpu C gpu C mem (e.g., C) cpu =60%, C gpu =50%), and the resource usage penalty factor is calculated using a piecewise linear interpolation algorithm: for CPU utilization, if v cpu ≤C cpu Then f cpu =1; if v cpu >C cpu Then f cpu =1+α×(v cpu -C cpu ) / (100-C cpu ), where α is the CPU weight coefficient, such as a value of 0.5; similarly, the GPU penalty factor f is calculated. gpu Memory factor f mem In v mem When the memory level falls below the warning threshold, the value is increased inversely; otherwise, it is 1. Finally, the dynamic compensation coefficient K for rendering latency is applied. adjust =max(fcpu ,f gpu )×f mem The dynamic compensation coefficient for rendering latency reflects the degree of blockage of the UI rendering pipeline by the current system load.

[0088] If necessary, the memory warning threshold can be set to M. threshold (e.g., 512MB), when v mem ≤M threshold At that time, f mem =M threshold / v mem When v mem >M threshold At that time, f mem =1.

[0089] Based on the baseline rendering latency and dynamic compensation coefficient, the dynamic interface rendering latency is determined, and the display time of the projection interface is estimated.

[0090] Specifically, the baseline interface rendering latency Δt, calibrated under no-load conditions, is retrieved from the configuration database. base For example, if the original time is 500ms, calculate the dynamic interface rendering delay Δt. dynamic =Δt base ×K adjust Subsequently, the display time T on the projection interface was determined. display =T2+Δt dynamic .

[0091] Based on the start time T0, the occurrence time of the first target event T1, and the display time of the projection interface T display Determine the reconnection session startup delay and perform root cause diagnosis based on resource status.

[0092] Specifically, the first reconnection delay Δt1 = T1 - T0, and the second reconnection delay Δt2 = T display -T1, total delay Δt total =T display -T0. If the total delay Δt total If the preset total latency threshold is exceeded, the root cause diagnosis branch is triggered: if K is determined... adjust >K threshold , such as K threshold When K = 1.3, the output first-level diagnostic result is rendering latency degradation, the root cause of which is GPU rendering pipeline blockage caused by system resource preemption; if K adjust ≤K threshold If Δt1 exceeds the limit, the output first-level diagnostic result is an abnormal establishment of the underlying wireless link; if K adjust ≤K thresholdIf Δt1 is normal but Δt2 exceeds the limit, the first-level diagnostic result is output as "upper-layer screen projection session negotiation timeout". The diagnostic result, along with the latency of each stage, is written into the structured test log.

[0093] For example, when a tester triggers a warm start of the vehicle's infotainment system, the test host records the start time as T0=10:00:00.000. The test host then captures the connection completion event by monitoring the HCI interface, recording T1=10:00:02.500; subsequently, it detects a SETUP Response-Screen message for the CarPlay protocol, recording T2=10:00:05.000. At this moment, the test host sends REQ_RES_STATUS to the vehicle's infotainment probe, which immediately returns RES_RES_STATUS, allowing the parsing of the state vector V. status =[v cpu =850 (i.e., 85%), v gpu =720 (i.e., 72%), v mem =102400].

[0094] Set the baseline threshold C cpu =60%, C gpu =50%, weight α=0.5. Calculate the CPU penalty factor as f. cpu =1 + 0.5 × (85 - 60) / (100 - 60) = 1.3125; Calculate the GPU penalty factor f. gpu =1+0.5×(72-50) / (100-50)=1.22.

[0095] Take the maximum value max(1.3125, 1.22) = 1.3125; assuming sufficient memory at this point. mem =1.0, then K adjust =1.3125, reference rendering latency Δt base =500ms, calculate the dynamic rendering latency Δt dynamic =500ms × 1.3125 = 656ms, calculate the display time T on the projection interface. display =10:00:05.000 + 0.656s = 10:00:05.656. Calculate the total delay Δt. total =10:00:05.656-10:00:00.000=5.656s.

[0096] Assuming a total latency threshold of 5.0 seconds, the test is deemed a failure because K... adjust(1.3125)>1.3, triggering root cause diagnosis, outputting the diagnosis log: {"Total_Delay":"5.656s","Status":"FAIL","Root_Cause":"Rendering latency deterioration, root cause is system resource preemption leading to GPU rendering pipeline blockage"}.

[0097] Therefore, the above solution can adapt to the resource load fluctuations of the vehicle system in concurrent scenarios of cold start or hot wake-up, accurately quantify the rendering latency expansion caused by GPU pipeline blockage, eliminate the distortion of estimated time caused by system load changes, further improve the fidelity of reconnection latency test, and realize the technical closed loop from latency quantification to root cause localization through the joint judgment of dynamic compensation coefficient and latency at each stage, thereby improving the fault location efficiency in the R&D and testing stage.

[0098] It should be understood that the baseline rendering latency refers to the rendering time calibrated by the aforementioned high-speed camera frame-by-frame analysis method under no-load baseline conditions, i.e., when the CPU utilization and GPU utilization are both below a specific threshold and memory is sufficient and there is no contention. It is a static physical eigenvalue representing the maximum processing time of the rendering pipeline under optimal resource conditions. The preset interface rendering latency in the aforementioned embodiments is a specific value of the baseline rendering latency in this embodiment. Dynamic rendering latency refers to the actual rendering time required for the projected interface under the current real load state of the terminal under test. The preset interface rendering latency is further instantiated as a dynamic rendering latency that adapts to the system state. The dynamic rendering latency is equal to the product of the baseline rendering latency and the dynamic compensation coefficient for the rendering latency, i.e., Δt. dynamic =Δt base ×K adjust Where, Δt dynamic K is used to replace the preset interface rendering latency in the calculation formula of the aforementioned embodiments. adjust These are the dynamic compensation coefficients calculated based on the current system resource state vector.

[0099] This invention also provides a vehicle terminal reconnection latency testing device 100. The testing device 100 is disposed at the testing terminal 10 and is used to execute any embodiment of the aforementioned vehicle terminal reconnection latency testing method.

[0100] Specifically, the following describes in detail the specific structure of a vehicle terminal reconnection latency testing device 100 provided by an embodiment of the present invention, according to the appendix. Figure 6 As shown, the specific structure of the vehicle terminal reconnection latency testing device 100 includes the following: Recording module 110 is used to record the startup time of the terminal under test; The first acquisition module 120 is used to, in response to the start-up time, acquire the occurrence time of the first target event by monitoring the data of the host control interface that establishes a wireless connection with the mobile terminal, wherein the first target event is a connection completion event sent when the wireless link is first established. The second acquisition module 130 is used to monitor the data of the wireless screen projection session of the mobile terminal to obtain the occurrence time of the second target event, wherein the second target event is the sending time of the display configuration response message; The first determining module 140 is used to determine the display time of the projection interface based on the occurrence time of the second target event and the preset interface rendering delay. The second determining module 150 is used to determine the reconnection session start delay based on the start time, the occurrence time of the first target event, and the display time of the projection interface.

[0101] This invention further provides a computer device, which can be used to perform the test method for vehicle terminal reconnection latency in any of the above embodiments.

[0102] See Figure 7 The computer device 500 includes a processor 502, a memory, and a network interface 505 connected via a communication bus 501. The memory may include a storage medium 503 and internal memory 504.

[0103] The storage medium 503 may store an operating system 5031 and a computer program 5032. When the computer program 5032 is executed, it enables the processor 502 to execute a test method for the reconnection latency of the vehicle terminal. The storage medium 503 may be a volatile storage medium or a non-volatile storage medium.

[0104] The processor 502 provides computing and control capabilities to support the operation of the entire computer device 500.

[0105] The internal memory 504 provides an environment for the operation of the computer program 5032 in the storage medium 503. When the computer program 5032 is executed by the processor 502, the processor 502 can execute a test method for the reconnection latency of the vehicle terminal.

[0106] This network interface 505 is used for network communication, such as providing data transmission. Those skilled in the art will understand that... Figure 7 The structure shown is merely a block diagram of a portion of the structure related to the present invention and does not constitute a limitation on the computer device 500 to which the present invention is applied. The specific computer device 500 may include, but is not limited to, the following: Figure 7 The diagram shows more or fewer components, or combinations of certain components, or different component arrangements.

[0107] The processor 502 is used to run the computer program 5032 stored in the memory to implement the corresponding function in the above-mentioned test method for vehicle terminal reconnection latency.

[0108] Those skilled in the art will understand that Figure 7 The embodiments of the computer device shown do not constitute a limitation on the specific configuration of the computer device. In other embodiments, the computer device may include, but is not limited to, other components. Figure 7 More or fewer components, or combinations of certain components, or different arrangements of components. For example, in some embodiments, a computer device may include only memory and a processor; in such embodiments, the structure and function of the memory and processor are different from those of other components. Figure 7 The embodiments shown are consistent and will not be described again here.

[0109] It should be understood that, in this embodiment of the invention, the processor 502 may be a Central Processing Unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0110] In another embodiment of the invention, a computer-readable storage medium is provided. This computer-readable storage medium may be volatile or non-volatile. The computer-readable storage medium stores a computer program, wherein when executed by a processor, the computer program implements the steps included in the above-described method for testing the reconnection latency of an in-vehicle terminal.

[0111] Those skilled in the art will readily understand that, for the sake of convenience and brevity, the specific working processes of the devices, apparatuses, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. 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, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in terms of function in the foregoing description. 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 invention.

[0112] In the embodiments provided by this invention, it should be understood that the disclosed devices, 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. Units with the same function may be grouped into one unit. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. In addition, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some interfaces, devices, or units, or it may be an electrical, mechanical, or other form of connection.

[0113] 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 the embodiments of the present invention, depending on actual needs.

[0114] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0115] The integrated units described above can be implemented in either hardware or software functional units.

[0116] 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 computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a computer-readable storage medium and includes several instructions to cause a computer device (which may be a personal computer, a data transmitter, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned computer-readable storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), magnetic disks, or optical disks.

[0117] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for testing the reconnection latency of an on-board terminal, characterized in that, The testing method includes: Record the startup time of the terminal under test; In response to the startup time, the occurrence time of the first target event is obtained by monitoring the data of the host control interface that establishes a wireless connection with the mobile terminal, wherein the first target event is a connection completion event sent when the wireless link is first established; Monitor the data of the wireless screen projection session of the mobile terminal to obtain the occurrence time of the second target event, wherein the second target event is the time when the display configuration response message is sent; The screen projection interface display time is determined based on the occurrence time of the second target event and the preset interface rendering delay. The reconnection session startup delay is determined based on the startup time, the occurrence time of the first target event, and the display time of the projection interface.

2. The test method for reconnection delay of vehicle-mounted terminal according to claim 1, characterized in that, The monitoring data from the host control interface that establishes a wireless connection with the mobile terminal is used to obtain the time of occurrence of the first target event, including: The test tool interacts with the mobile terminal to capture the host control interface data of the mobile terminal. Extract the occurrence time of the first target event from the host control interface data.

3. The test method for reconnection delay of vehicle-mounted terminal according to claim 1, characterized in that, The monitoring of data from the wireless screen mirroring session of the mobile terminal to obtain the time of occurrence of the second target event includes: The test tool interacts with the mobile terminal to capture data of the mobile terminal's wireless screen projection session. Extract the occurrence time of the second target event from the data of the wireless screen projection session.

4. The test method for reconnection delay of vehicle-mounted terminal according to claim 1, characterized in that, Determining the reconnection session startup delay based on the startup time, the occurrence time of the first target event, and the display time of the projection interface includes: The first reconnection delay is calculated based on the start time and the occurrence time of the first target event; Calculate the time difference between the occurrence time of the second target event and the occurrence time of the first target event, and calculate the sum of the first time difference and the preset interface rendering delay as the second reconnection delay; The reconnection session start delay is determined based on the first reconnection delay and the second reconnection delay.

5. The test method for reconnection delay of vehicle-mounted terminal according to claim 4, characterized in that, The testing method also includes: Determine whether the first reconnection delay is less than a first preset threshold, and determine whether the second reconnection delay is less than a second preset threshold; If the first reconnection delay is less than the first preset threshold and the second reconnection delay is less than the second preset threshold, then the vehicle terminal reconnection session startup delay test is deemed to have passed. Otherwise, the test for the reconnection session startup latency of the vehicle terminal is deemed to have failed.

6. The test method for reconnection delay of vehicle-mounted terminal according to claim 1, characterized in that, The preset method for obtaining the interface rendering latency includes: Monitor and obtain the sending time of the display configuration response message; Record the screen display content of the terminal under test, and analyze the recorded video frame by frame to determine the actual display time when the projection interface is fully rendered on the screen display content; Calculate the time difference between the actual display time and the sending time, and use it as the preset interface rendering delay.

7. The test method for reconnection delay of the vehicle terminal according to any one of claims 1-6, characterized in that, The terminal under test is a vehicle-mounted terminal, and the wireless screen projection session is a vehicle-mounted screen projection session.

8. A testing device for reconnection delay of a vehicle-mounted terminal, characterized in that, The testing apparatus includes: The recording module is used to record the startup time of the terminal under test; The first acquisition module is used to acquire the occurrence time of the first target event by monitoring the data of the host control interface that establishes a wireless connection with the mobile terminal in response to the start time, wherein the first target event is a connection completion event sent when the wireless link is first established. The second acquisition module is used to monitor the data of the wireless screen projection session of the mobile terminal to obtain the occurrence time of the second target event, wherein the second target event is the sending time of the display configuration response message; The first determining module is used to determine the display time of the projection interface based on the occurrence time of the second target event and the preset interface rendering delay. The second determining module is used to determine the reconnection session startup delay based on the startup time, the occurrence time of the first target event, and the display time of the projection interface.

9. A computer device, characterized in that, The computer device includes a processor, a network interface, a memory, and a communication bus, wherein the processor, network interface, and memory communicate with each other through the communication bus; Memory, used to store computer programs; The processor, when executing a program stored in memory, implements the steps of the test method for reconnection delay of the vehicle terminal as described in any one of claims 1-7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the test method for vehicle terminal reconnection latency as described in any one of claims 1-7.

Images