Cross-platform network speed measurement and adaptive path switching method and device, and storage medium

Abstract

The invention provides a cross-platform network speed measurement and adaptive path switching method and device and a storage medium. The method comprises the following steps: receiving a target domain name and a multi-source DNS server list; extracting historical network quality data corresponding to the environment identifier and each candidate IP address, inputting the historical network quality data into a link quality prediction model to obtain a prediction score of each candidate IP address, and screening according to a preset threshold to obtain a target IP subset; performing active detection of limited times on each IP address in the target IP subset to obtain a detection index; calculating the comprehensive score of each IP address based on the prediction score and the detection index, determining the optimal IP address with the highest comprehensive score, and recording the DNS server address of the optimal IP address; and establishing a network connection path according to the optimal IP address, and providing a DNS server address of the optimal IP address for a service layer. According to the method and the device, the cross-platform maintenance cost can be reduced, the real-time performance and the performance overhead are considered, the path is dynamically optimized, and rapid connection switching is realized.

Description

Technical Field

[0001] This application relates to the field of mobile Internet technologies, and in particular, to a cross-platform network speed measurement and adaptive path switching method, device, and storage medium. Background Art

[0002] With the popularization of the mobile Internet, application programs need to run simultaneously on multiple operating systems such as HarmonyOS, Android, and iOS. The network stack implementations, hardware radio frequency performances, and operator policies of different platforms vary, resulting in highly fragmented characteristics of the terminal network connection quality. If mobile applications cannot timely perceive and adapt to network quality differences, phenomena such as slow loading, request timeouts, or connection interruptions are likely to occur, seriously affecting the user experience.

[0003] To ensure connection stability, the industry usually integrates a network speed measurement component on the client side. Common implementation methods include the following: 1. Dedicated implementation for a single platform: Native APIs are called separately within each operating system to perform Ping or HTTP download speed measurement; 2. Static DNS resolution strategy: A single DNS service is preset or fixedly used to provide domain name resolution; 3. Simple screening with latency priority: Only the RTT (round-trip time) is compared to select the connection target; 4. Manual node switching: When the network quality deteriorates, the user or a preset logic manually reconnects to a standby server.

[0004] The main problems existing in the above-mentioned prior art include: First, the cross-platform maintenance cost is high. The speed measurement logics need to be developed and maintained separately for different systems, and it is difficult to keep the algorithms and thresholds consistent; Second, the speed measurement dimension is single. Most solutions only focus on latency or bandwidth and do not comprehensively consider indicators such as jitter, packet loss rate, and stability; Third, there is an imbalance between real-time performance and overhead. Frequent execution of complete speed measurement will bring additional traffic and power consumption, while reducing the speed measurement frequency makes it difficult to capture network fluctuations in a timely manner; Fourth, there is a lack of adaptive strategies. Existing methods usually switch nodes based on static thresholds or fixed rules and cannot dynamically optimize the path according to historical big data and the current environment; Finally, the connection switching is lagging. When the quality of the current link deteriorates rapidly, traditional solutions often take a long time to complete detection, decision-making, and migration, resulting in an increased risk of service interruption. Summary of the Invention

[0005] In view of this, the embodiments of this application provide a cross-platform network speed measurement and adaptive path switching method, device, and storage medium to solve the problems of high cross-platform maintenance cost, single speed measurement dimension, imbalance between real-time performance and overhead, lack of adaptive strategies, and lagging connection switching existing in the prior art.

[0006] In the first aspect of the embodiments of the present application, a cross-platform network speed measurement and adaptive path switching method is provided, including: collecting the operating platform information, network mode information, and location information of a terminal device to generate an environment identifier; receiving a target domain name and a multi-source DNS server list, and obtaining a set of candidate IP addresses corresponding to the target domain name by using a parallel parsing method; extracting historical network quality data corresponding to the environment identifier and each candidate IP address from a pre-constructed multi-dimensional link quality database, inputting the historical network quality data into a link quality prediction model to obtain the prediction scores of each candidate IP address, and screening to obtain a target IP subset according to a preset threshold; performing a limited number of active detections on each IP address in the target IP subset to obtain detection metrics; calculating the comprehensive scores of each IP address based on the prediction scores and the detection metrics, determining the optimal IP address with the highest comprehensive score, and recording the DNS server address of the optimal IP address; establishing a network connection path according to the optimal IP address, and providing the DNS server address of the optimal IP address to the service layer; periodically obtaining real-time network quality monitoring data of the network connection path, and when the real-time network quality monitoring data meets the preset change conditions, re-selecting alternative IP addresses and switching the network connection path.

[0007] In the second aspect of the embodiments of the present application, a cross-platform network speed measurement and adaptive path switching device is provided, including: a collection module for collecting the operating platform information, network mode information, and location information of a terminal device to generate an environment identifier; a parsing module for receiving a target domain name and a multi-source DNS server list, and obtaining a set of candidate IP addresses corresponding to the target domain name by using a parallel parsing method; a prediction module for extracting historical network quality data corresponding to the environment identifier and each candidate IP address from a pre-constructed multi-dimensional link quality database, inputting the historical network quality data into a link quality prediction model to obtain the prediction scores of each candidate IP address, and screening to obtain a target IP subset according to a preset threshold; a detection module for performing a limited number of active detections on each IP address in the target IP subset to obtain detection metrics; a calculation module for calculating the comprehensive scores of each IP address based on the prediction scores and the detection metrics, determining the optimal IP address with the highest comprehensive score, and recording the DNS server address of the optimal IP address; an establishment module for establishing a network connection path according to the optimal IP address, and providing the DNS server address of the optimal IP address to the service layer; a switching module for periodically obtaining real-time network quality monitoring data of the network connection path, and when the real-time network quality monitoring data meets the preset change conditions, re-selecting alternative IP addresses and switching the network connection path.

[0008] In the third aspect of the embodiments of the present application, an electronic device is provided, including a memory, a processor, and a computer program stored on the memory and executable on the processor, and the processor implements the steps of the above method when executing the computer program.

[0009] In a fourth aspect of the embodiments of the present application, a computer-readable storage medium is provided. The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the above method are implemented.

[0010] The above at least one technical solution adopted in the embodiments of the present application can achieve the following beneficial effects: By collecting the operating platform information, network mode information, and location information of the terminal device, an environment identifier is generated; receiving the target domain name and the multi-source DNS server list, and obtaining the candidate IP address set corresponding to the target domain name by using the parallel parsing method; extracting the historical network quality data corresponding to the environment identifier and each candidate IP address from the pre-constructed multi-dimensional link quality database, inputting the historical network quality data into the link quality prediction model, obtaining the prediction scores of each candidate IP address, and screening to obtain the target IP subset according to the preset threshold; performing a limited number of active detections on each IP address in the target IP subset to obtain detection indicators; calculating the comprehensive scores of each IP address based on the prediction scores and the detection indicators, determining the optimal IP address with the highest comprehensive score, and recording the DNS server address of the optimal IP address; establishing a network connection path according to the optimal IP address, and providing the DNS server address of the optimal IP address to the service layer; periodically obtaining the real-time network quality monitoring data of the network connection path, and when the real-time network quality monitoring data meets the preset change conditions, reselecting the alternative IP address and switching the network connection path. The present application can reduce the cross-platform maintenance cost, balance the real-time performance and performance overhead, dynamically optimize the path, and achieve fast connection switching. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following will briefly introduce the drawings required for use in the embodiments or the description of the prior art. Obviously, the following drawings are only some embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other drawings can be obtained according to these drawings.

[0012] Figure 1 is a flowchart of the cross-platform network speed measurement and adaptive path switching method provided by the embodiments of the present application; Figure 2 is a structural diagram of the cross-platform network speed measurement and adaptive path switching device provided by the embodiments of the present application; Figure 3 is a structural diagram of the electronic device provided by the embodiments of the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0013] In the following description, specific details such as specific system architectures and technologies are presented for the purpose of illustration rather than limitation, so as to thoroughly understand the embodiments of the present application. However, those skilled in the art should clearly understand that the present application can also be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to avoid unnecessary details from interfering with the description of the present application.

[0014] To solve the problem of cross-platform (HarmonyOS, Android, iOS) network speed measurement, the present application provides a technical solution for optimizing cross-platform network connection speed based on the Dart engine. The technical implementation idea of the technical solution of the present application includes: 1. Specify the target domain name and a group of DNS server IPs for a specific platform to obtain all possible IP addresses under the specified domain name.

[0015] 2. Traverse and test the connection speed (Ping) of each IP address with the current device.

[0016] 3. Find the corresponding optimal DNS server IP according to the test results.

[0017] 4. Send a network request based on the optimal DNS server IP and provide this DNS server to the service layer.

[0018] In addition, on the basis of the above technical implementation idea, the present application adds the establishment of a cross-platform network connection speed measurement basic database. By pre-establishing a network speed measurement data set for different geographical locations, network operator environments, and time periods of different platforms of HarmonyOS, Android, and iOS.

[0019] This network speed measurement data set includes network connection quality parameters such as specific platform device environment information (such as platform type, network mode, signal strength, geographical location), DNS resolution results, IP address information corresponding to the domain name, Ping latency, link jitter, network throughput, and packet loss rate.

[0020] In addition, the present application also introduces link quality comprehensive evaluation and multi-dimensional network speed measurement technologies. Not only uses the Ping latency index, but also introduces multi-dimensional network quality evaluation parameters, including: network jitter, packet loss rate, network throughput, link stability, etc. Implement a cross-platform unified network quality comprehensive evaluation model on the Dart engine to construct a link quality evaluation index system.

[0021] The main content of the technical solution of the present application is briefly described below: 1. Establish a cross-platform network connection speed measurement basic database Pre - establish a network speed measurement dataset for different geographical locations, network operator environments, and time periods on different platforms of HarmonyOS, Android, and iOS.

[0022] This network speed measurement dataset includes network connection quality parameters such as specific platform device environment information (e.g., platform type, network mode, signal strength, geographical location), DNS resolution results, IP address information corresponding to domain names, Ping latency, link jitter, network throughput, packet loss rate, etc.

[0023] 2. Cross - platform dynamic DNS resolution and IP speed measurement optimization During the actual operation process, the Dart engine first receives the target domain name specified by the user and a group of alternative DNS server IPs, performs domain name resolution, and obtains multiple available IP addresses under the target domain name.

[0024] For the resolved IP addresses, first quickly predict the network quality of each IP address according to the model, and initially filter out the IPs with poor network quality.

[0025] For some IP addresses with better prediction results, further perform a small number of Ping tests to quickly verify the network quality and correct the model prediction accuracy.

[0026] Finally, combine the model prediction results with the actual results of a small number of Ping tests to dynamically select the optimal IP address in the current environment in real - time.

[0027] 3. Real - time adaptive optimization of network connection paths Continuously monitor the connection quality of the determined optimal IP address, and real - time monitor the network jitter and latency changes.

[0028] When it is detected that the network connection quality indicators change (e.g., the latency increases or the packet loss rate significantly increases), trigger the model prediction process again, and dynamically switch to the sub - optimal or alternative IP evaluated by the comprehensive evaluation of model prediction and real - time speed measurement; realize the closed - loop adaptive adjustment of the entire network connection optimization.

[0029] The following will describe the content of the technical solution of this application in detail with reference to the accompanying drawings and specific embodiments.

[0030] Figure 1 It is a flowchart of the cross - platform network speed measurement and adaptive path switching method provided by the embodiment of this application. As Figure 1 shown, the cross - platform network speed measurement and adaptive path switching method can specifically include: S101, collect the running platform information, network mode information, and location information of the terminal device, and generate an environment identifier; S102. Receive the target domain name and the multi-source DNS server list, and use the parallel parsing method to obtain the candidate IP address set corresponding to the target domain name; S103. Extract the historical network quality data corresponding to the environmental identifier and each candidate IP address from the pre-constructed multi-dimensional link quality database, input the historical network quality data into the link quality prediction model, obtain the prediction scores of each candidate IP address, and filter to obtain the target IP subset according to the preset threshold; S104. Perform a limited number of active detections on each IP address in the target IP subset to obtain detection metrics; S105. Calculate the comprehensive score of each IP address based on the prediction score and the detection metrics, determine the optimal IP address with the highest comprehensive score, and record the DNS server address of the optimal IP address; S106. Establish a network connection path according to the optimal IP address and provide the DNS server address of the optimal IP address to the service layer; S107. Periodically obtain the real-time network quality monitoring data of the network connection path. When the real-time network quality monitoring data meets the preset change conditions, re-select the alternative IP address and switch the network connection path.

[0031] In some embodiments, receiving the target domain name and the multi-source DNS server list, and using the parallel parsing method to obtain the candidate IP address set corresponding to the target domain name includes: Based on the multi-source DNS server list, construct a corresponding parallel parsing task set for the target domain name, and each parallel parsing task points to a DNS server record in the list; Through the asynchronous I / O or multi-thread mechanism, send domain name resolution requests to each DNS server in the parallel parsing task set simultaneously and receive the parsing records; Perform format verification, blacklist comparison, and deduplication and merging on the IP addresses returned by each parsing record to obtain the initial candidate IP address set; Attach the parsing timestamp and the source DNS server identifier to each IP address in the initial candidate IP address set to generate the candidate IP address set.

[0032] Specifically, in an exemplary embodiment that can run on the Flutter / Dart cross - platform engine, the client first loads a DNS server list for multiple platforms from the local configuration center during the application startup phase. This list includes both the default DNS dynamically allocated by the operating system, several hard - coded public recursive DNSs (such as 8.8.8.8, 1.1.1.1, etc.), and the resolution endpoints encapsulated by the DoH (DNS over HTTPS) protocol. Subsequently, the client constructs a "parallel resolution task set" for a single target domain name based on this list. During the construction process, a task description unit is created for each DNS server record, and operating parameters such as the server IP, resolution protocol type (traditional UDP - 53 or DoH - 443), maximum waiting duration, and upper limit of retry times are recorded within the description unit. All task description units are pushed to a unified resolution task queue for subsequent concurrent scheduling.

[0033] After the resolution task queue is started, the client drives the concurrent process at the Dart layer through an Isolate pool (by default, four working Isolates per platform, which can be automatically scaled up or down according to the number of CPU cores). For tasks using the UDP - 53 resolution protocol, the working Isolate directly constructs a DNS request message through the FFI interface and writes it into the native socket to send a query request message (RFC1035) to the target DNS server; for tasks using the DoH protocol, it is encapsulated as an HTTPS GET request, and "accept: application / dns - json" is explicitly declared in the request header. All requests are attached with independent timeout timers to avoid a single - point lag from dragging down the overall resolution cycle.

[0034] Furthermore, when the resolution results are successively returned by each DNS server, the working Isolate immediately parses the A record and AAAA record locally, extracts the obtained IP addresses, and performs a triple - verification process: First, verify whether the IP format complies with the regular rules; second, compare the IP address with the preset blacklist of invalid nodes and the blacklist of malicious networks; finally, perform a quick duplicate detection on the IP addresses that pass the first two rounds of verification to ensure that the same address is only retained once. After passing these three verifications, the IP addresses from each resolution record are appended and written into the local "initial candidate IP address set" cache structure, and the timestamp of the resolution completion and the DNS server identifier that returned the IP address are synchronously recorded.

[0035] In some examples, to reduce the risk of DNS cache poisoning in a short period of time, the client performs a final consistency check after completing all concurrent tasks: if multiple DNS servers return the same IP address, the system preferentially retains the first successfully returned resolution record and appends a "multi-source confirmation" flag to its metadata. Subsequently, the verified and deduplicated IP list is used as the final candidate IP address set, and metadata such as the source information, resolution protocol, resolution time consumption, and timestamp of each IP is synchronously written into the side cache and delivered to the subsequent link quality prediction and active detection processes through a callback interface.

[0036] In scenarios of weak networks or extremely old devices that only support single-threaded network libraries, this embodiment also provides a degradation strategy: the system will automatically degrade to the sequential resolution mode, but still output the candidate IP address set according to the same verification, comparison, and deduplication logic to ensure the consistency and security of the resolution results.

[0037] In some embodiments, the historical network quality data is input into the link quality prediction model to obtain the prediction scores of each candidate IP address, and a target IP subset is obtained by screening according to a preset threshold, including: Performing missing value filling, metric normalization, and feature vector construction on the historical network quality data records to form input feature vectors corresponding to each candidate IP address one by one; Inputting each input feature vector into the link quality prediction model obtained through offline training to output the prediction scores corresponding to each candidate IP address; Comparing each prediction score with the preset threshold, and retaining the candidate IP addresses whose prediction scores meet the preset threshold to form a target IP subset.

[0038] Specifically, in an embodiment that can run on the Flutter cross-platform engine, after the client completes the resolution of the candidate IP address set, it will call the link quality prediction module to perform pre-score screening on each candidate IP address, and the specific process is as follows.

[0039] First, the client retrieves the historical network quality data records corresponding to each candidate IP address in the locally persisted multi-dimensional link quality database according to the environment identifier generated in the resolution process. The historical network quality data records include entries such as latency, jitter, throughput, packet loss rate, connection stability, and collection timestamp. To ensure the integrity of the input data, the system performs two-level filling for missing entries: for indicators missing within the last thirty minutes, the nearest neighbor interpolation of the same indicator is used for filling; for indicators still missing after more than thirty minutes, the historical mean of the same environment identifier is used for filling.

[0040] After completion of padding, the client performs normalization processing on all metrics. Latency, jitter, and packet loss rate are normalized to zero mean; throughput and stability are scaled to the range from zero to one using min-max scaling. Subsequently, the system assembles a five-dimensional metric vector in a fixed field order according to a predefined feature template, and appends a three-dimensional environment feature encoding at the end of the vector, including platform type encoding, network mode encoding, and operator encoding, thereby forming an input feature vector of length eight, which corresponds one-to-one with the current candidate IP address.

[0041] Next, the client inputs the batch of feature vectors into the link quality prediction model obtained from offline training. This model is trained using the gradient boosting tree algorithm in the cloud, automatically incrementally updated every 24 hours, and distributed to each terminal in JSON format. When the model performs inference on the edge side, it outputs a prediction score between zero and one for each feature vector. The higher the score, the more likely the IP address is to perform well in the current environment.

[0042] After obtaining all the prediction scores, the client compares the scores with a dynamic threshold. The threshold is adjusted and pushed by the server hourly according to the overall network fluctuations, with a default value of 0.7 for example. The system traverses the list of candidate IP addresses and retains the IP addresses whose prediction scores are not lower than the threshold, forming a target IP subset in real time. If only a small number of IP addresses meet the threshold condition in a certain environment, resulting in fewer than three elements in the subset, the system automatically lowers the threshold by 0.05 for re-screening to ensure an adequate number of elements in the target IP subset, and then submits the target IP subset to the active detection module for the next lightweight detection.

[0043] In some embodiments, the active detection is performed on each IP address in the target IP subset for a limited number of times to obtain detection metrics, including: Generate detection configuration parameters for each IP address in the target IP subset. The detection configuration parameters include the type of detection packet, the size of the packet, and the maximum number of detections; Based on the asynchronous socket or multi-thread mechanism, send detection packets to each IP address in parallel according to the detection configuration parameters, and receive the corresponding response packets; Record the original detection data when receiving the response packets, and perform statistical aggregation on the original detection data to obtain detection metrics; Associate and store the detection metrics with the corresponding IP address, DNS server identifier, and timestamp.

[0044] Specifically, in a typical embodiment, the edge side has obtained five target IP addresses through the historical prediction link: 203.0.113.12, 203.0.113.18, 198.51.100.7, 198.51.100.9, and 192.0.2.4. The speed measurement module first generates detection configuration parameters for each IP address. The configuration parameters are fixed as follows: the type of detection data packet is ICMP echo request, the size of a single data packet is 56 bytes, and the maximum number of detection times is 4 times; if there are 2 consecutive timeouts, the detection loop for this IP address will end prematurely.

[0045] Subsequently, the speed measurement module starts the same number of worker threads as the number of IP addresses at the Dart layer, and allocates independent send buffers and receive buffers for each thread through non-blocking sockets. Each thread sends ICMP echo requests to the corresponding IP address in parallel according to the detection configuration parameters; the local high-precision timestamp is recorded during sending. When the thread receives an echo response, the arrival timestamp is also recorded and the one-way round-trip delay value is calculated immediately. If the thread waits for more than the default timeout duration of 1000 ms and still does not receive an echo response, a packet loss flag is recorded in the detection result of this time. During the whole process, the thread appends the one-way round-trip delay, whether there is packet loss, and the detection packet sequence number to the original detection data buffer private to the thread.

[0046] When all threads complete the detection of the specified number of times, the speed measurement module merges the thread buffers and performs statistical aggregation on the original data for the same IP address. The aggregation process includes: calculating the average value, range, and variance of all valid round-trip delays to obtain the delay jitter; calculating the ratio of the number of packet losses to the number of detections to obtain the packet loss rate; estimating the instantaneous throughput reference value based on the total time taken for the four ICMP packets to return. The aggregated detection metrics are bound in key-value form with the corresponding IP address, the DNS server identifier that triggered this resolution, and the local timestamp when the detection was implemented, and are synchronously written into the lightweight SQLite database on the edge side to provide real-time network quality input for the subsequent comprehensive scoring link.

[0047] Through the method of the above embodiment, without introducing additional application layer load, multi-IP parallel active detection can be completed within hundreds of milliseconds, and multi-dimensional link quality metrics covering average round-trip delay, delay jitter, packet loss rate, and instantaneous throughput can be obtained, thus laying an accurate and timely data foundation for subsequent comprehensive scoring and optimal IP selection.

[0048] In some embodiments, calculating the comprehensive score of each IP address based on the prediction score and the detection metrics, and determining the optimal IP address with the highest comprehensive score includes: For different network modes, a set of weight coefficients corresponding to the network mode are preset, and the weight coefficients are used for weighted processing of the prediction score and the detection metrics; Perform normalization processing on the predicted scores and detection metrics obtained for each IP address respectively to form comparable score vectors; Perform weighted combination on each score vector according to the weight coefficients to obtain the comprehensive score of each IP address; Arrange the comprehensive scores in descending order according to the preset sorting rules, and determine the IP address ranked first as the optimal IP address.

[0049] Specifically, in a typical embodiment, the terminal device detects that the current access network mode is 5GNR, and thus loads a set of weight coefficients corresponding to 5GNR from the terminal-side weight configuration file. This set of coefficients has a total of five dimensions: prediction score weight 0.35, average delay weight 0.25, delay jitter weight 0.15, packet loss rate weight 0.15, and instantaneous throughput weight 0.10. The weight configuration file is generated by the cloud based on long-term monitoring and statistical results, and is sent through an incremental package at 0:00 every day, and the version is distinguished by the timestamp on the terminal side.

[0050] After the active detection in the previous stage is completed, each of the five candidate IP addresses has a complete set of metric records. Since the dimensions of each metric are different, the terminal side first performs normalization processing on all metrics: the prediction score itself is already in the range of 0 to 1 and does not need to be transformed; for the remaining four metrics, according to the principle that "the smaller represents better quality", a unified minimum-maximum inverse scaling is adopted to map the metric values to the range of 0 to 1, where 1 represents the best. The specific steps are as follows: calculate the minimum and maximum values of a metric in the current candidate set, and then apply the inverse scaling formula to the metric corresponding to each IP address. After the processing is completed, a set of five-dimensional score vectors is obtained for each IP address.

[0051] Subsequently, the terminal side performs weighted combination on the five-dimensional score vectors of each IP address according to the loaded weight coefficients. The weighting method is to multiply the corresponding weight coefficients by the same vector in the order of dimensions respectively, and then calculate the weighted sum to obtain a single comprehensive score. The theoretical range of the comprehensive score is still 0 to 1, and the higher the score, the better the overall performance under the current network mode.

[0052] When the comprehensive scores of all candidate IP addresses are calculated, the terminal side sorts the score results in descending order. During the sorting process, if there is a tie with exactly the same comprehensive score, the average delay score is preferentially compared; if the average delay scores are still the same, the packet loss rate scores are continued to be compared. After sorting, the IP address with the highest comprehensive score and meeting the tie-breaking condition is determined as the optimal IP address, recorded as 198.51.100.9, and this IP address is pushed to the connection establishment module, and written into the "currently effective IP" field in the memory. At the same time, the DNS server that resolves this IP is returned to the service layer, and subsequent network connections are all carried out through this optimal DNS server to ensure that the optimal IP is resolved.

[0053] Through the method of the above embodiments, by predefining differential weights for different network modes, performing unified dimension conversion and weighted fusion on multi-dimensional indicators, the comprehensive quality evaluation of candidate IP addresses and the selection of the optimal IP address can be completed within dozens of milliseconds, significantly improving the adaptability of the scoring result to the specific network environment and the decision-making accuracy.

[0054] In some embodiments, a network connection path is established according to the optimal IP address, and the DNS server address of the optimal IP address is provided to the service layer, including: Writing the optimal IP address and the target domain name into the runtime routing mapping table, and setting an expiration duration for the routing mapping table; Determining a set of connection parameters according to the current network mode and service requirements, where the set of connection parameters includes the transport layer protocol type, the encryption negotiation method, and the handshake timeout time; Initiating a connection handshake to the optimal IP address using the non-blocking socket mechanism, and generating a connection context identifier after the handshake is successful; Writing the connection context identifier and the optimal IP address into the connection management table, and exposing the DNS server address and the connection context identifier of the optimal IP address to the service layer through a cross-platform interface.

[0055] Specifically, in this embodiment, the terminal device runs in the Flutter cross-platform engine environment. In the previous scoring and sorting stage, the optimal IP address has been determined as 198.51.100.9, corresponding to the target domain name api.gamecloud.com. The speed measurement optimization component then enters the path establishment process.

[0056] First, the component calls the built-in routing mapping manager to write the key-value pair <api.gamecloud.com, 198.51.100.9> into the HashMap structure maintained within the process. This mapping record comes with a TTL (Time-To-Live) expiration duration field, with a default value of 900s. When the TTL expires or the monitoring module triggers a link degradation event, the mapping manager automatically deletes this record to avoid stale entries interfering with subsequent parsing.

[0057] Next, the component determines the set of connection parameters according to the current network mode 5GNR and the low-latency requirements of the service layer interface. The set of connection parameters specifies three items: the transport layer protocol type is QUIC, the encryption negotiation method is TLS1.3, and the handshake timeout time is 800ms. If it is detected that the system does not support UDP hole punching or the operator blocks UDP traffic, the parameter set will degrade to TCP + TLS1.3 and the handshake timeout time will be extended to 1500ms.

[0058] Subsequently, the component calls the PlatformChannel in the Dart layer to bridge the native network stack and initiates a QUIC handshake through the non-blocking socket mechanism within Android, iOS, and HarmonyOS respectively. To ensure cross-platform consistency, the component immediately sets the O_NONBLOCK flag after creating the socket and configures both the send and receive buffer sizes to be 64KB. During the handshake, the network stack automatically completes the ClientHello, ServerHello, and certificate verification processes. If the key negotiation is not completed within 800ms, the handshake is considered a failure and a handshake timeout event is recorded.

[0059] After the handshake is successful, the component reads the connection handle from the native network stack and generates a unique connection context identifier CTX20250429170351, which contains the establishment time, protocol family, socket file descriptor, and cipher suite information. The connection context identifier, together with the optimal IP address, is written into the in-process connection management table. The connection management table indexes domain names with a Trie, allowing for quick location of active connections. To avoid memory leaks, the table entry also records the idle timeout threshold, and when there is no traffic data flowing through the connection for 30 consecutive seconds, the socket is automatically closed and the table entry is removed.

[0060] Finally, the component exposes the DNS server address of the optimal IP address and the connection context identifier to the Flutter business layer through the MethodChannel. The business layer then inserts Host:api.gamecloud.com into the HTTP request header and sets the destination address to 198.51.100.9; if the business layer uses a custom protocol, it directly reuses the QUIC session corresponding to CTX20250429170351, saving the overhead of a second handshake. If the business layer detects a connection anomaly, it can call the switching interface provided by the speed measurement and optimization component to immediately restart the scoring and screening and path establishment processes.

[0061] Through the method of the above embodiments, the system completes the writing of the optimal IP address, protocol parameter self-adaptation, non-blocking handshake, and connection context output within milliseconds, significantly reducing the first-packet delay and ensuring that the business layer obtains a reusable and stable session, improving the network connection success rate and continuous performance in cross-platform scenarios.

[0062] In some embodiments, real-time network quality monitoring data of the network connection path is periodically obtained, and when the real-time network quality monitoring data meets the preset change conditions, an alternative IP address is reselected and the network connection path is switched, including: Setting monitoring period parameters and dynamically adjusting the monitoring period according to business traffic activity or network mode, and collecting real-time network quality monitoring data of the network connection path through passive sampling or sending heartbeat probe packets within each monitoring period; Compare the real-time network quality monitoring data with the change thresholds preset for the current environment identifier. If the preset change conditions are met, trigger the alternative IP address reselection process; On the premise of excluding the current optimal IP address, perform prediction scoring, active detection, and comprehensive scoring on the remaining candidate IP addresses or the IP addresses obtained by re-parsing to determine the alternative IP address with the highest comprehensive score; Based on the alternative IP address, establish a standby network connection path. After successful handshake and data consistency confirmation, update the connection management table to switch the standby network connection path to a new network connection path and close the original network connection path.

[0063] Specifically, in this embodiment, the terminal device has established a QUIC session CTX20250429170351 with the optimal IP address 198.51.100.9. To ensure the continuous reliability of the link quality, the speed measurement and optimization component starts a real-time monitoring task throughout the full connection cycle. When the task is initialized, the starting monitoring period T is calculated according to the traffic type and network mode reported by the service layer: if the current traffic is video live broadcast and the network is 5G NR, then T is set to 3s; if the traffic is ordinary file download and the network is LTE, then T is relaxed to 8s. This parameter is stored in the monitoring task control block and allows subsequent dynamic adjustment.

[0064] Within each monitoring period, the component first tries passive sampling: collect ACK-ECN information and path verification frame RTT for the data packets passing through the QUIC path, and write the sampled delay, jitter, and packet loss statistics into the circular buffer; if there is no service data passing through in the current period, send a QUIC PING frame with a length of 46 bytes as a heartbeat detection packet at the end of the period and record the round-trip time. To reduce power consumption, when the global CPU utilization rate is continuously lower than 15% and the application enters the background, the component automatically expands the monitoring period to T×2.

[0065] In some examples, the component sets two levels of change thresholds for the current environment identifier ENV-5GNR-CM: The first-level thresholds are ΔRTT = 40ms, ΔJitter = 15ms, and ΔLoss = 2%; The second-level thresholds are ΔRTT = 80ms and ΔLoss = 5%.

[0066] If the RTT increase rate ≥ ΔRTT and the packet loss rate ≥ ΔLoss occur in three consecutive monitoring periods, or the second-level threshold is directly triggered in a single period, the component records a link degradation event and enters the alternative IP address reselection process.

[0067] Furthermore, in the reselection process, the current optimal IP address is first removed from the candidate set. If the number of remaining candidate IPs is less than three or the last update time has exceeded TTL600s, the component immediately calls the parallel DNS resolution module to re-obtain the IP address set and write it into the historical database. Subsequently, the component performs the following operations in sequence: Call the prediction model module to generate the predicted scores of each candidate IP; Send two ICMP packets and one UDP packet in parallel to the IP addresses with scores higher than 0.6 to collect detection metrics; Calculate the comprehensive score and select the alternative IP address 198.51.100.7 ranked first, with a comprehensive score of 0.83, higher than the current link score of 0.65.

[0068] In some examples, the component creates a new QUIC session CTX20250429170826 for 198.51.100.7. The 0RTT data is enabled in the handshake phase, carrying the application layer token token=ZXfj93k to maintain session-level authentication. The handshake takes 212 ms to succeed. Subsequently, a 204-byte detection request is sent to the backend interface / router / ping to confirm that the service is reachable and the response time does not exceed 300 ms. After meeting the conditions, the component performs an atomic update in the connection management table: map api.gamecloud.com to CTX20250429170826, and set the old session status to Closing. To avoid packet loss, the component retains a 10-second half-closed time window for the old session for retransmission of the sent packets. After the window ends, CTX20250429170351 is completely closed, releasing the file descriptor and the encryption status cache.

[0069] After the switch is completed, the component writes the real-time monitoring data of this degradation event, the comprehensive score of the alternative IP address, and the switchover time into the SQLite table tbl_linklog. And recalculate the monitoring period with the new average RTT of 32 ms and packet loss rate of 0.3% as the baseline, which automatically converges to T = 3 s due to the network recovering stability.

[0070] Through the method of the above embodiments, this embodiment can complete millisecond-level detection at the initial stage of link quality attenuation through continuous and low-overhead real-time link monitoring and dynamic threshold determination; select and establish a backup path within hundreds of milliseconds with the help of the prediction-detection-comprehensive scoring closed loop; realize the seamless migration of service data through the Make-Before-Break switch mechanism, greatly reducing the probability of sudden packet loss, freezing, and connection interruption, and significantly improving the stability and user experience of cross-platform mobile applications in complex network environments.

[0071] The following is an embodiment of the apparatus of the present application, which can be used to execute the method embodiment of the present application. For details not disclosed in the apparatus embodiment of the present application, please refer to the method embodiment of the present application.

[0072] Figure 2 It is a schematic structural diagram of a cross-platform network speed measurement and adaptive path switching device provided by an embodiment of the present application. As Figure 2 shown, the cross-platform network speed measurement and adaptive path switching device includes: An acquisition module 201, configured to acquire the operating platform information, network mode information, and location information of the terminal device, and generate an environment identifier; An analysis module 202, configured to receive a target domain name and a multi-source DNS server list, and obtain a set of candidate IP addresses corresponding to the target domain name by using a parallel analysis method; A prediction module 203, configured to extract historical network quality data corresponding to the environment identifier and each candidate IP address from a pre-constructed multi-dimensional link quality database, input the historical network quality data into a link quality prediction model, obtain a prediction score for each candidate IP address, and screen to obtain a target IP subset according to a preset threshold; A detection module 204, configured to perform a limited number of active detections on each IP address in the target IP subset to obtain detection metrics; A calculation module 205, configured to calculate a comprehensive score for each IP address based on the prediction score and the detection metrics, determine the optimal IP address with the highest comprehensive score, and record the DNS server address of the optimal IP address; A establishment module 206, configured to establish a network connection path according to the optimal IP address and provide the DNS server address of the optimal IP address to the service layer; A switching module 207, configured to periodically obtain real-time network quality monitoring data of the network connection path, and when the real-time network quality monitoring data meets a preset change condition, re-select alternative IP addresses and switch the network connection path.

[0073] In some embodiments, Figure 2 the analysis module 202 of [] constructs a corresponding parallel analysis task set for the target domain name based on the multi-source DNS server list, and each parallel analysis task points to a DNS server record in the list; through an asynchronous I / O or multi-thread mechanism, send domain name resolution requests to each DNS server in the parallel analysis task set simultaneously and receive resolution records; perform format verification, blacklist comparison, and deduplication and merging on the IP addresses returned by each resolution record to obtain an initial set of candidate IP addresses; attach a resolution timestamp and a source DNS server identifier to each IP address in the initial set of candidate IP addresses to generate a set of candidate IP addresses.

[0074] In some embodiments, Figure 2The prediction module 203 performs missing value filling, metric normalization, and feature vector construction on the historical network quality data records to form input feature vectors corresponding one by one to each candidate IP address; inputs each input feature vector into the link quality prediction model obtained through offline training, and outputs the prediction scores corresponding to each candidate IP address; compares each prediction score with a preset threshold, and retains the candidate IP addresses whose prediction scores meet the preset threshold to form a target IP subset.

[0075] In some embodiments, Figure 2 The detection module 204 of generates detection configuration parameters for each IP address in the target IP subset, where the detection configuration parameters include the detection packet type, packet size, and maximum detection times; based on the asynchronous socket or multi-thread mechanism, sends detection packets to each IP address in parallel according to the detection configuration parameters, and receives the corresponding response packets; records the original detection data when receiving the response packets, and performs statistical aggregation on the original detection data to obtain detection metrics; associates and stores the detection metrics with the corresponding IP addresses, DNS server identifiers, and timestamps.

[0076] In some embodiments, Figure 2 The calculation module 205 pre-sets a set of weight coefficients corresponding to the network mode for different network modes, and the weight coefficients are used to perform weighted processing on the prediction scores and detection metrics; performs normalization processing on the prediction scores and detection metrics obtained for each IP address respectively to form comparable score vectors; performs weighted combination on each score vector according to the weight coefficients to obtain the comprehensive scores of each IP address; sorts the comprehensive scores in descending order according to the preset sorting rules, and determines the IP address ranked first as the optimal IP address.

[0077] In some embodiments, Figure 2 The establishment module 206 writes the optimal IP address and the target domain name into the runtime routing mapping table, and sets the expiration duration for the routing mapping table; determines a set of connection parameters according to the current network mode and service requirements, where the set of connection parameters includes the transport layer protocol type, encryption negotiation method, and handshake timeout time; uses the non-blocking socket mechanism to initiate a connection handshake to the optimal IP address, and generates a connection context identifier after the handshake is successful; writes the connection context identifier and the optimal IP address into the connection management table, and exposes the DNS server address and the connection context identifier of the optimal IP address to the service layer through a cross-platform interface.

[0078] In some embodiments, Figure 2The switching module 207 sets the monitoring period parameter, dynamically adjusts the monitoring period according to the service traffic activity or network mode, and collects real-time network quality monitoring data of the network connection path by passive sampling or sending heartbeat probe packets within each monitoring period; compares the real-time network quality monitoring data with the preset change threshold for the current environment identifier, and if the preset change condition is met, triggers the alternative IP address reselection process; performs prediction scoring, active detection, and comprehensive scoring on the remaining candidate IP addresses or the IP addresses obtained by re-parsing, excluding the current optimal IP address, to determine the alternative IP address with the highest comprehensive score; establishes a standby network connection path based on the alternative IP address, and after successful handshake and data consistency confirmation, updates the connection management table to switch the standby network connection path to the new network connection path and closes the original network connection path.

[0079] It should be understood that the magnitudes of the sequence numbers of the steps in the above embodiments do not mean the order of execution, and the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation to the implementation process of the embodiments of the present application.

[0080] Figure 3 is a schematic structural diagram of the electronic device 3 provided by the embodiment of the present application. As Figure 3 shown, the electronic device 3 of this embodiment includes: a processor 301, a memory 302, and a computer program 303 stored in the memory 302 and executable on the processor 301. When the processor 301 executes the computer program 303, the steps in the above various method embodiments are implemented. Alternatively, when the processor 301 executes the computer program 303, the functions of each module / unit in the above various device embodiments are implemented.

[0081] Exemplarily, the computer program 303 can be divided into one or more modules / units, and one or more modules / units are stored in the memory 302 and executed by the processor 301 to complete the present application. One or more modules / units can be a series of computer program instruction segments capable of performing specific functions, and the instruction segments are used to describe the execution process of the computer program 303 in the electronic device 3.

[0082] The electronic device 3 can be a desktop computer, a notebook, a palm computer, a cloud server, and other electronic devices. The electronic device 3 can include but is not limited to the processor 301 and the memory 302. Those skilled in the art can understand that Figure 3 is only an example of the electronic device 3, and does not constitute a limitation to the electronic device 3. It can include more or fewer components than shown in the figure, or combine some components, or different components. For example, the electronic device can also include input / output devices, network access devices, buses, etc.

[0083] The processor 301 can be a Central Processing Unit (CPU), or 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 can be a microprocessor or any conventional processor, etc.

[0084] The memory 302 can be an internal storage unit of the electronic device 3. For example, the hard disk or memory of the electronic device 3. The memory 302 can also be an external storage device of the electronic device 3. For example, a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) card, a Flash Card, etc. equipped on the electronic device 3. Further, the memory 302 can also include both the internal storage unit and the external storage device of the electronic device 3. The memory 302 is used to store computer programs and other programs and data required by the electronic device. The memory 302 can also be used to temporarily store data that has been output or will be output.

[0085] Those skilled in the art can clearly understand that, for the convenience and simplicity of description, only the above-mentioned division of each functional unit and module is used as an example. In actual applications, the above-mentioned functions can be allocated to different functional units and modules according to needs, that is, the internal structure of the device is divided into different functional units or modules to complete all or part of the functions described above. Each functional unit and module in the embodiment can be integrated into a processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of a software functional unit. In addition, the specific names of each functional unit and module are only for the convenience of mutual distinction and do not limit the protection scope of the present application. The specific working processes of the units and modules in the above system can refer to the corresponding processes in the foregoing method embodiments and will not be elaborated herein.

[0086] In the above embodiments, the descriptions of the various embodiments have their own emphases. For the parts not detailed or recorded in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0087] Those of ordinary skill in the art will realize that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be implemented by electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are executed in hardware or software depends on the specific application and design constraints of the technical solution. A professional technician can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of this application.

[0088] In the embodiments provided in this application, it should be understood that the disclosed device / computer equipment and method can be implemented in other ways. For example, the device / computer equipment embodiments described above are only illustrative. For example, the division of modules or units is only a logical function division. In actual implementation, there may be other division methods. Multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the displayed or discussed coupling or direct coupling or communication connection between each other can be through some interfaces. The indirect coupling or communication connection of the device or unit can be in an electrical, mechanical or other form.

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

[0090] In addition, the functional units in each embodiment of this application can be integrated in a processing unit, or each unit can exist physically alone, or two or more units can be integrated in one unit. The above-mentioned integrated units can be implemented in the form of hardware or in the form of software functional units.

[0091] When the integrated module / unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on such understanding, to implement all or part of the processes in the above-described embodiment methods of this application, it can also be completed by instructing relevant hardware through a computer program. The computer program can be stored in the computer-readable storage medium. When the computer program is executed by a processor, the steps of the above-described various method embodiments can be implemented. The computer program can include computer program code, and the computer program code can be in the form of source code, object code, executable file, or some intermediate form, etc. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording medium, USB flash drive, mobile hard disk, magnetic disk, optical disc, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signal, telecommunication signal, and software distribution medium, etc.

[0092] The above embodiments are only used to illustrate the technical solutions of this application, rather than to limit them; although the technical solutions of this application have been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that: they can still modify the technical solutions recorded in the foregoing embodiments, or perform equivalent replacements on some of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the various embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A cross-platform network speed measurement and adaptive path switching method, characterized in that Including: Collect the operating platform information, network mode information and location information of the collection terminal device to generate an environment identifier; Receive the target domain name and the multi-source DNS server list, and use the parallel parsing method to obtain the candidate IP address set corresponding to the target domain name; Extract the historical network quality data corresponding to the environment identifier and each candidate IP address from the pre-constructed multi-dimensional link quality database, input the historical network quality data into the link quality prediction model, obtain the prediction scores of each candidate IP address, and screen to obtain the target IP subset according to the preset threshold; Perform a limited number of active detections on each IP address in the target IP subset to obtain detection indicators; Calculate the comprehensive scores of each IP address based on the prediction scores and the detection indicators, determine the optimal IP address with the highest comprehensive score, and record the DNS server address of the optimal IP address; Establish a network connection path according to the optimal IP address and provide the DNS server address of the optimal IP address to the service layer; Periodically obtain the real-time network quality monitoring data of the network connection path. When the real-time network quality monitoring data meets the preset change conditions, re-select the alternative IP address and switch the network connection path.

2. The method according to claim 1, characterized in that, The receiving the target domain name and the multi-source DNS server list, and using the parallel parsing method to obtain the candidate IP address set corresponding to the target domain name includes: Based on the multi-source DNS server list, construct a corresponding parallel parsing task set for the target domain name, and each parallel parsing task points to a DNS server record in the list; Through asynchronous I / O or multi-thread mechanism, send domain name resolution requests to each DNS server in the parallel parsing task set at the same time and receive the parsing records; Perform format verification, blacklist comparison and deduplication and merging on the IP addresses returned by each parsing record to obtain the initial candidate IP address set; Attach a parsing timestamp and a source DNS server identifier to each IP address in the initial candidate IP address set to generate the candidate IP address set.

3. The method according to claim 1, wherein The inputting the historical network quality data into the link quality prediction model, obtaining the prediction scores of each candidate IP address, and screening to obtain the target IP subset according to the preset threshold includes: Perform missing value filling, index normalization and feature vector construction on the historical network quality data records to form input feature vectors corresponding to each candidate IP address one by one; Input each input feature vector into the link quality prediction model obtained by offline training, and output the prediction scores corresponding to each candidate IP address; Compare each prediction score with the preset threshold, and retain the candidate IP addresses whose prediction scores meet the preset threshold to form the target IP subset.

4. The method according to claim 1, characterized in that The performing a limited number of active detections on each IP address in the target IP subset to obtain detection indicators includes: Generate detection configuration parameters for each IP address in the target IP subset, and the detection configuration parameters include detection packet type, packet size and maximum detection times; Based on the asynchronous socket or multi-thread mechanism, probe packets are sent in parallel to each IP address according to the probe configuration parameters, and the corresponding response packets are received; When receiving the response packets, record the original probe data, and perform statistical aggregation on the original probe data to obtain probe metrics; Associate and store the probe metrics with the corresponding IP address, DNS server identifier, and timestamp.

5. The method according to claim 1, wherein Calculating the comprehensive score of each IP address based on the prediction score and the probe metrics, and determining the optimal IP address with the highest comprehensive score, including: For different network modes, preset a set of weight coefficients corresponding to the network mode, and the weight coefficients are used to weight the prediction score and the probe metrics; Perform normalization processing on the prediction scores and probe metrics obtained for each IP address respectively to form comparable score vectors; Perform weighted combination on each score vector according to the weight coefficients to obtain the comprehensive score of each IP address; Arrange the comprehensive scores in descending order according to the preset sorting rules, and determine the IP address ranked first as the optimal IP address.

6. The method according to claim 1, characterized in that, Establishing a network connection path according to the optimal IP address, and providing the DNS server address of the optimal IP address to the service layer, including: Write the optimal IP address and the target domain name into the runtime routing mapping table, and set the expiration time for the routing mapping table; According to the current network mode and service requirements, determine the connection parameter set, and the connection parameter set includes the transport layer protocol type, encryption negotiation method, and handshake timeout time; Use the non-blocking socket mechanism to initiate a connection handshake to the optimal IP address, and generate a connection context identifier after the handshake is successful; Write the connection context identifier and the optimal IP address into the connection management table, and expose the DNS server address of the optimal IP address and the connection context identifier to the service layer through the cross-platform interface.

7. The method according to claim 1, characterized in that, Periodically obtain the real-time network quality monitoring data of the network connection path. When the real-time network quality monitoring data meets the preset change conditions, re-select the alternative IP address and switch the network connection path, including: Set the monitoring period parameters, and dynamically adjust the monitoring period according to the service traffic activity or network mode. In each monitoring period, collect the real-time network quality monitoring data of the network connection path through passive sampling or sending heartbeat probe packets; Compare the real-time network quality monitoring data with the change threshold preset for the current environment identifier. If the preset change conditions are met, trigger the alternative IP address re-selection process; On the premise of excluding the current optimal IP address, perform prediction scoring, active probing, and comprehensive scoring on the remaining candidate IP addresses or the IP addresses obtained by re-parsing, and determine the alternative IP address with the highest comprehensive score; Based on the alternative IP address, establish a standby network connection path. After successful handshake and data consistency confirmation, update the connection management table to switch the standby network connection path to the new network connection path, and close the original network connection path.

8. A cross-platform network speed measurement and adaptive path switching device, characterized in that Including: A collection module for collecting the running platform information, network mode information, and location information of the terminal device to generate an environment identifier; A parsing module, configured to receive a target domain name and a multi-source DNS server list, and obtain a set of candidate IP addresses corresponding to the target domain name by using a parallel parsing method; A prediction module, configured to extract historical network quality data corresponding to the environment identifier and each candidate IP address from a pre-constructed multi-dimensional link quality database, input the historical network quality data into a link quality prediction model, obtain a prediction score for each candidate IP address, and filter to obtain a target IP subset according to a preset threshold; A detection module, configured to perform a limited number of active detections on each IP address in the target IP subset to obtain detection metrics; A calculation module, configured to calculate a comprehensive score for each IP address based on the prediction score and the detection metrics, determine an optimal IP address with the highest comprehensive score, and record the DNS server address of the optimal IP address; An establishment module, configured to establish a network connection path according to the optimal IP address and provide the DNS server address of the optimal IP address to the service layer; A switching module, configured to periodically obtain real-time network quality monitoring data of the network connection path, and when the real-time network quality monitoring data meets a preset change condition, re-select an alternative IP address and switch the network connection path.

9. An electronic device, comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, When the processor executes the computer program, the steps of the method according to any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

Images