Mobile application network optimization method and system based on multi-domain-name dynamic optimization

Abstract

The invention relates to the technical field of mobile internet software, in particular to a mobile application network optimization method and system based on multi-domain-name dynamic optimization, and the method comprises the following steps: obtaining identification information, filling a country code and version information into address parameters, extracting a matching field, obtaining an associated domain name, accessing the domain name, judging a connection state, and screening a smooth path. Recording an interrupt behavior to generate a replacement path, covering a default path to synchronize an entry update address, and replacing a request and a loading path to initiate access. According to the method, a dynamically screened candidate address set is constructed through matching consistency between fields, a stable path is screened by combining a connection state and link smoothness, communication interruption and reconnection behaviors are recorded to generate a replacement sequence, path coverage and access entry synchronous replacement are completed, and a request address and a resource loading path are dynamically updated. Path switching and entry updating are completed in the access process, the link maintaining capacity is enhanced, and the request continuity, the data receiving and sending integrity and the network response efficiency are improved.

Description

Technical Field

[0001] This invention relates to the field of mobile internet software technology, and in particular to a method and system for optimizing mobile application networks based on dynamic selection of multiple domain names. Background Technology

[0002] This invention relates to the field of mobile internet software technology, specifically to the optimization of data communication and access for mobile terminal applications in complex network environments. Key aspects include domain name resolution processing, connection path selection, network performance measurement, and client-server collaborative scheduling mechanisms. This field focuses on the access stability and communication efficiency of mobile applications under varying global network conditions, with the core objective of improving connection success rates, reducing access latency, and enhancing service continuity. A traditional mobile application network optimization method based on dynamic multi-domain selection involves configuring multiple top-level domains on the client side, combining server-side scheduling strategies with real-time client performance monitoring, and selecting the optimal domain from multiple candidate domains to establish a communication connection. This method typically involves: loading a candidate domain list issued by the server, calling the system's DNS resolution interface to obtain the IP address, evaluating network quality using metrics such as TCP handshake latency or HTTP response time, and selecting the access path to execute the business request according to rules. Some methods also enhance decision-making stability through local caching and failure protection logic.

[0003] Existing technologies use static loading of candidate domain names and local DNS resolution for connection path selection. In a variable network environment, there is a lack of dynamic configuration based on parameter dimensions. During the path selection process, the regional compatibility differences caused by device and version information cannot be perceived, resulting in inaccurate access entry matching in some scenarios. There is a lack of a continuous judgment mechanism for link response status during the connection request process. Path maintenance lacks complete tracking and real-time switching logic for the communication stage. This is common in situations where the connection cannot be repaired in time after a link anomaly occurs, affecting the continuity of business services and causing access path jitter. Connection interruption and resource loading failure are more likely to occur, especially in high-frequency network switching and weak network environments. Summary of the Invention

[0004] To address the technical problems existing in the prior art, this invention provides a mobile application network optimization method based on dynamic multi-domain selection, comprising the following steps: To achieve the above objectives, the present invention adopts the following technical solution: a mobile application network optimization method based on dynamic multi-domain selection, comprising the following steps: S1: Obtain identification information, country code and version information, fill the fields into the address parameter positions, extract the field values ​​and analyze the consistency with the configuration fields, match the configuration entries, extract the related domain name content, and obtain the candidate domain name grouping structure; S2: Based on the domain name field in the candidate domain name grouping structure, initiate an access request, determine whether the return status is successful, identify connection interruption and reconnection, filter smooth paths and add them to the path list to obtain the available domain name connection path structure. S3: Based on the main connection path in the available domain name connection path structure, identify communication interruption and reconnection behaviors, determine connection continuity, analyze whether the backup path will replace the current path after no interruption occurs, and obtain the main path replacement execution record structure. S4: Based on the main path replacement execution record structure, the active path field is selected and written to the current path, the old value is cleared and the entry path is synchronized to obtain the updated multi-domain distribution structure; S5: Based on the path bound in the updated multi-domain distribution structure, replace the original request address and webpage loading path, inject the path to initiate an access action, and obtain the dynamic network request optimization path for end-to-end landing.

[0005] As a further aspect of the present invention, the candidate domain name grouping structure includes a consistency verification result of an identification information field, a country code field, and a version information field, a set of available configuration entries, and filtered domain name data. The available domain name connection path structure includes a request address, return status content, connection success status marker, link interruption identification information, and a path record list. The main path replacement execution record structure includes a main connection channel status identifier, a communication interruption event identifier, backup path communication continuity analysis results, and a main connection replacement path. The updated multi-domain name distribution structure includes an active path field, original configuration path location, current path value, old path association record, and access entry path synchronization replacement item. The end-to-end dynamic network request optimization path includes address parameter field replacement results, embedded web page resource path, page loading action path, and updated network access path.

[0006] As a further aspect of the present invention, the configuration field refers to a preset set of parameters, which is used to compare the consistency of uploaded information and filter configuration items and candidate domain names; The associated domain name content refers to the domain name data extracted from the matching configuration items for network access.

[0007] As a further aspect of the present invention, the clearing of old values ​​refers to deleting the traces of the old path field in the reference list in the original configuration during the path update process, thereby preventing the old path from being called again and interfering with the new path; The replacement of the original request address refers to updating the old access address using dynamically filtered paths.

[0008] As a further aspect of the present invention, the specific steps of S1 are as follows: S101: Obtain identification information, country code and version information, fill the fields into the parameter positions of the access address, extract the field values ​​in a fixed order after the filling action, and compare and analyze the consistency with the corresponding items in the configuration field set to obtain a field consistency matching record set; S102: Based on the field groups in the field consistency matching record set, extract the configuration entry identifier code associated with each group, call the configuration entry identifier code and compare the tag fit with the tag set to which the current request belongs, filter the entries in the tag intersection that include the field group content, and obtain the matching configuration entry identifier set; S103: Based on the domain name parameter field associated with the entries in the matching configuration entry identifier set, extract the domain name content and fill the corresponding domain name parameter field into the preset position in the return response structure. After the field is filled in, write the response structure into the network return channel to obtain the candidate domain name grouping structure.

[0009] As a further aspect of the present invention, the specific steps of S2 are as follows: S201: Based on the domain name field information in the candidate domain name grouping structure, initiate a network request operation to each domain name address, identify the returned data packet status field, determine whether the returned status is a connection establishment success identifier type, aggregate the address fields of the success type, and obtain the initial successful connection address set; S202: Call the addresses in the initial successful connection address set, analyze the data communication flow on each path during the connection phase, monitor whether the link is disconnected during each data transmission behavior, identify whether the client automatically re-establishes the connection after the disconnection, determine the continuity based on the status of the connection behavior, and obtain a set of stable connection path sequences. S203: Based on the connectivity performance of the paths in the stable path sequence set, filter the paths that have not been interrupted or reconnected within the period, write the paths into the record structure list according to the original address reading order, and after filling the structure list, obtain the available domain name connection path structure.

[0010] As a further aspect of the present invention, the specific steps of S3 are as follows: S301: Based on the main connection path in the available domain name connection path structure, extract the sending time and receiving time within the communication period, identify the time interruption in continuous data transmission, determine the changes in the number of requests and received feedback before and after the interruption, locate the start and end time period of the data interruption, and obtain the main connection interruption time period set. S302: Based on the time boundary of the main connection interruption time period set, extract the transmission behavior and corresponding feedback information of the backup path within the same time range, analyze whether there is transmission interruption and response abnormality in the feedback, filter the backup path that has not been interrupted by continuous feedback status, and extract the field set corresponding to the path to obtain the backup path sequence information set. S303: Based on the backup path sequence information set, execute data requests according to the start time of the main path interruption, analyze the range of response delay changes and the continuity of the completeness of the returned information, remove abnormally fluctuating paths, retain the paths with continuous transmission performance to replace the current main path, and obtain the main path replacement execution record structure.

[0011] As a further aspect of the present invention, the specific steps of S4 are as follows: S401: Based on the activation path field information in the main path replacement execution record structure, divide the default path area in the original configuration content, match the field position corresponding to the activation path, and overwrite the original field content with the current path value to obtain the path field overwritten content; S402: Based on the replaced path value in the path field coverage content, identify the residual position of the corresponding old path field in the original configuration structure, delete the path content in the reference list, and obtain the reference path clearing data; S403: Based on the access entry position in the reference path clearing data, write the current path value item by item, replace the path field in the configuration, and keep each access entry pointing to the current path content to obtain the updated multi-domain distribution structure.

[0012] As a further aspect of the present invention, the specific steps of S5 are as follows: S501: Based on the updated multi-domain distribution structure, extract the address parameter field in the original request process, compare the parameter field with the target address field in the path content, locate the corresponding field position and replace the address value to obtain the address parameter replacement field; S502: Call the address parameter replacement field to replace the replaced address value, match the resource loading path field in the embedded web page display structure, update the resource path according to the same field replacement logic, and obtain the resource path replacement field; S503: Based on the updated path value in the resource path replacement field, load the web page resource content, initiate each type of network request in the direction indicated by the path, continuously collect access response status and resource loading completion information, and obtain the dynamic network request optimization path for the entire link landing.

[0013] A mobile application network optimization system based on dynamic multi-domain selection includes: The device parameter extraction module obtains identification information, country code and version information, fills the fields into the request parameters in sequence, extracts the field values ​​and compares them with the preset set, analyzes the field matching items and filters the associated domain name addresses to obtain the candidate domain name grouping structure; The connection path filtering module initiates requests sequentially based on the domain name addresses of the candidate domain name grouping structure, determines the connection status and identifies whether it is interrupted, filters continuously connectable paths, and obtains the available domain name connection path structure. The channel path replacement module identifies data interruption behavior and reconnection actions during communication based on the main connection channel in the available domain name connection path structure, determines whether the backup path maintains continuous communication within the same period, replaces the main channel with the backup path to request connection, and obtains the main path replacement execution record structure. The configuration path update module locates the local default path position based on the path content in the main path replacement execution record structure, replaces it with the current path and clears the old path reference, replaces the path address, and obtains the updated multi-domain distribution structure. The network path assignment module replaces the request fields of the interface and web page display resources based on the domain name address bound in the updated multi-domain distribution structure, and re-initiates the resource access operation to obtain a dynamic network request optimization path for the entire chain.

[0014] Compared with the prior art, the advantages and positive effects of the present invention are as follows: In this invention, a dynamically filtered set of candidate addresses is constructed by matching consistency between fields, stable paths are filtered by combining connection status and link smoothness, communication interruption and reconnection behavior is recorded to generate replacement sequences, path coverage and access entry synchronous replacement are completed, request addresses and resource loading paths are dynamically updated, path switching and entry updates are completed during access, link maintenance capability is enhanced, and request continuity, data transmission and reception integrity and network response efficiency are improved. Attached Figure Description

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

[0016] Figure 1 This is a schematic diagram of the steps of the present invention; Figure 2 This is a detailed schematic diagram of S1 of the present invention; Figure 3 This is a detailed schematic diagram of S2 of the present invention; Figure 4 This is a detailed schematic diagram of S3 of the present invention; Figure 5 This is a detailed schematic diagram of S4 of the present invention; Figure 6 This is a detailed schematic diagram of S5 of the present invention; Figure 7 This is a system module diagram of the present invention. Detailed Implementation

[0017] The technical solution of the present invention will now be described with reference to the accompanying drawings.

[0018] In embodiments of the present invention, words such as "exemplarily," "for example," etc., are used to indicate that something is an example, illustration, or description. Any embodiment or design described as "exemplary" in the present invention should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of the word "exemplary" is intended to present the concept in a concrete manner. Furthermore, in embodiments of the present invention, the meaning expressed by "and / or" can be both, or either one.

[0019] In the embodiments of this invention, the terms "image" and "picture" may sometimes be used interchangeably. It should be noted that, without emphasizing the distinction between them, they convey the same meaning. Similarly, the terms "of," "corresponding (relevant)," and "corresponding" may sometimes be used interchangeably. It should be noted that, without emphasizing the distinction between them, they convey the same meaning.

[0020] In this embodiment of the invention, sometimes a subscript such as W1 may be written in a non-subscript form such as W1. When the difference is not emphasized, the meaning they express is the same.

[0021] To make the technical problems, technical solutions and advantages of the present invention clearer, a detailed description will be given below in conjunction with the accompanying drawings and specific embodiments.

[0022] Please see Figure 1 This invention provides a mobile application network optimization method based on dynamic multi-domain selection, comprising the following steps: S1: Obtain the identification information, country code and version information, fill the fields into the request address parameter position in sequence, extract the corresponding values ​​according to the field arrangement order before initiating access, compare the extracted values ​​with the reference items in the preset field set, analyze the available configuration items by judging the consistency of field values, filter the associated domain name data in the configuration items, and write the returned content to obtain the candidate domain name grouping structure. S2: Based on the domain name field information provided by the candidate domain name grouping structure, send requests to each address in sequence, read the returned status content in order, determine whether it is a successful connection status, identify whether a link interruption has occurred or whether the client has re-initiated the connection during the connection phase, and put the paths that have not been interrupted and have always remained open into the path record list according to the current order to obtain the available domain name connection path structure. S3: Based on the channel path of the main connection in the available domain name connection path structure, analyze whether interruption occurs during data sending and receiving during the communication period, identify the connection continuity of the behavior of re-initiating the request after the interruption, analyze the continuous communication of the backup path without interruption during the same period, replace the current main connection channel as the backup path, and obtain the main path replacement execution record structure. S4: Based on the main path replacement execution record structure, find the position corresponding to the default path in the original configuration content, write the current path value to the position to overwrite the original content, clear the record information associated with the old path after writing, and synchronously replace the access entry of each calling path with the current path to obtain the updated multi-domain distribution structure. S5: Based on the currently effective domain name binding results in the updated multi-domain distribution structure, replace the address parameter field in the native request process, and simultaneously replace the resource request path of the embedded web page display part. After the address is replaced, initiate the page resource loading action, and access each type of network according to the updated path to obtain the dynamic network request optimization path for the entire link landing.

[0023] The candidate domain name grouping structure includes the consistency verification results of the identification information field, country code field, and version information field, the set of available configuration entries, and the filtered domain name data. The available domain name connection path structure includes the request address, return status content, connection success status marker, link interruption identification information, and path record list. The main path replacement execution record structure includes the main connection channel status identifier, communication interruption event identifier, backup path communication continuity analysis results, and main connection replacement path. The updated multi-domain name distribution structure includes the activation path field, original configuration path location, current path value, old path association record, and access entry path synchronization replacement item. The dynamic network request optimization path with full-link implementation includes the address parameter field replacement result, embedded web page resource path, page loading action path, and updated network access path.

[0024] Please see Figure 2 The specific steps of S1 are as follows: S101: Obtain identification information, country code and version information, fill the fields into the parameter positions of the access address, extract the field values ​​in a fixed order after the filling action, and compare and analyze the consistency with the corresponding items in the configuration field set to obtain a field consistency matching record set; Retrieve the identification information, country code, and version information. The identification information is the device's unique identifier, for example, the device number is "DVC00123". The country code can be set to two or three letters, such as "CN" representing China. The version information, such as "V10", indicates the current system version. Fill these three fields sequentially into the parameter position of the access address, where the access address is a preset network configuration address path, assuming the path is "net.example.com / api?device=&country=&version=". Replace "net.example.com / api?device=DVC00123&country=CN&version=V10" according to the field order. After the replacement is completed, extract the values ​​of each field written to the address, i.e., extract "DVC00123", "CN", and "V10". After extraction, match each field value with the standard field set registered in the configuration field set. This set pre-maintains several groups of valid fields. For example, "DVC00123, CN, V10" is one of the valid groups. During item-by-item comparison, each field value is checked sequentially to see if it is equal to the corresponding content in the target field group. If the identification information, country code, and version information are all consistent, the field group is considered valid, and this field group is recorded as a consistent matching group in the current identification results. Then, the extraction and comparison of the next device field group is performed. For example, if the new group is "DVC00128, CN, V9", and the version information is inconsistent, it is determined to be a mismatch and the group is excluded. This process... When accessing multiple devices or performing batch verification, the process is executed synchronously. Under the condition that the device set is {DVC00123, DVC00124, DVC00125}, the country code is always "CN", and the versions are {V10, V10, V8}, only the first two groups meet the configuration field set conditions and are therefore included in the record. The field matching standard is strict equivalence comparison, and fuzzy matching or omissions are not allowed between fields. After all comparison actions are completed, the sets that meet the conditions in all field groups are extracted to obtain the field consistency matching record set.

[0025] S102: Based on the field consistency matching record set, extract the configuration entry identifier code associated with each group, call the configuration entry identifier code and compare the tag fit with the tag set to which the current request belongs, filter the entries that include the field group content in the tag intersection, and obtain the matching configuration entry identifier set; Each field group typically consists of identification information, country code, and version information. For example, a field group might be {DVC00123, CN, V10}. Within the field groups that have already matched, it's necessary to further extract the configuration entry identifier associated with each field group. This identifier is a unique number for each configuration item in the configuration file. For instance, the configuration entry identifier corresponding to the field group {DVC00123, CN, V10} is CFG0021. After extraction, the tag set carried by the current request is called. For example, if the tag set corresponding to this request is {Overseas, Mobile, HTML5}, the tag set is cross-compared with the tag set associated with the configuration entry identifier. Assuming CFG0021 is associated with the tags {HTML5, Android, High-speed}, the tag fit can be calculated by dividing the number of tag intersections by the total number of tag sets. In this example, the intersection is {HTML5}, the number of intersections is 1, and the total number of tags is 6. The fit is set to 1 / 6, and the selection criteria are further limited by the fit threshold. For example, when the threshold is set to 0.3, only configuration item identifiers with two or more overlapping tags are retained. If the threshold is not met, the current item is removed. In this selection process, the tag fit is screened for all field groups and their corresponding configuration item identifiers. Configuration items with zero overlapping tags or that are not related to the current request scenario are further removed. For example, the field group {DVC00128, CN, V9} corresponds to CFG0024, whose tag set is {desktop, test, intranet}. It has no overlap with the request tag {overseas, mobile, HTML5}, so this configuration item is directly discarded and will not participate in subsequent path allocation or resource injection actions. The tag fit is not set with upper and lower limits, but rather the number of overlaps is used as the core judgment criterion. After the full field group screening is completed, the set of all configuration item identifiers that meet the conditions is aggregated to obtain the matching configuration item identifier set.

[0026] S103: Based on the domain name parameter field associated with the entries in the matching configuration entry identifier set, extract the domain name content and fill the corresponding domain name parameter field into the preset position in the returned response structure. After the field is filled in, write the response structure into the network return channel to obtain the candidate domain name grouping structure. First, each identifier points to a data structure for a specific configuration entry, which contains multiple parameter fields. The domain name parameter field defines the network domain address of the request destination. For example, the domain name field corresponding to the configuration entry identifier CFG0117 is "cdn3.net-access.com". During the extraction process, each identifier is first traversed, and its corresponding entry's domain name field is read. If the entry does not have a configured domain name field, the current entry is skipped and not processed further. If a domain name field exists, its value is extracted. After extraction, the domain name values ​​are filled into the specified positions in the response structure according to the field content order. This structure has several pre-defined field slots corresponding to different types of network request scenarios. For example, slot A corresponds to resource retrieval. For class requests, slot B corresponds to page redirection class requests. The field slots are matched based on the source and purpose of the entries, and the domain value is placed into the matching slot. No position drift processing is performed. Once the domain field is written, it is bound to the slot. At the same time, according to the return requirements of the call channel, the response structure with the filled fields is transferred to the network return channel. This channel is used to carry the page request results back to the client. If there are empty or redundant fields in the response structure during the writing process, the empty field positions are cleared and reusable fields are merged to avoid path conflicts caused by redundant field content. After all domain field is filled and entered into the channel for transmission, the mapping relationship between multiple domain content and its source configuration entry identifier is gathered to obtain the candidate domain grouping structure.

[0027] Please see Figure 3 The specific steps of S2 are as follows: S201: Based on the domain name field information in the candidate domain name grouping structure, initiate a network request operation to each domain name address, identify the returned data packet status field, determine whether the returned status is a connection establishment success identifier type, aggregate the address fields of the success type, and obtain the initial successful connection address set; First, a network request is made for each domain name address. The domain name field is represented as a string, and each item corresponds to a specific server resource node, such as "api.route-access.net" or "cdn.login-host.com". During the request process, the current domain name is written into the Host field of the HTTP request header, and the corresponding GET request path is set. The request packet is sent to the IP node corresponding to the target domain name via a TCP connection. The server responds with a data packet containing multiple field segments. The status field is located in the identifier section of the response header. This field is usually presented as a three-digit code, such as "200" for a successful connection, "403" for blocked access, and "503" for blocked access. When the service is unavailable, the status field in the response header is located during parsing. The status code is extracted and identified. If the status field value is "200", the current request is considered a successful connection. Other values ​​are not included in the success list. For all requests that are considered successful connections, the address field information is extracted. The address field refers to the complete representation of the current domain name in the request header, including the protocol, hostname, and port number, represented in URI form, such as "https: / / cdn.login-host.com:443". All address fields corresponding to successful statuses are aggregated and integrated, duplicates are excluded, and unique values ​​are retained. After all address information is processed, the initial set of successful connection addresses is obtained.

[0028] S202: Call the addresses in the initial successful connection address set, analyze the data communication flow on each path during the connection phase, monitor whether the link is broken during each data transmission behavior, identify whether the client automatically re-establishes the connection after the break, judge the continuity based on the status of the connection behavior, and obtain a set of stable connection path sequences; First, each address in the initial successful connection address set is used as the communication target. Connection establishment and data transmission operations are performed for each address path. During each communication process, the interaction flow between sent data frames and received response frames is monitored segment by segment. The control bit status, time interval, and whether the received acknowledgment response is returned in sequence are recorded during data frame transmission. If no response frame is returned, connection timeout occurs, or control bit disconnection signals appear during the transmission phase, it is marked as a disconnection. In actual operation, if the client continuously sends heartbeat packets to the address "https: / / api.route-access.net" and receives no response for two consecutive cycles, it is determined that the path has been interrupted. After the disconnection event, the client's connection behavior continues to be monitored. If the client re-initiates a connection initialization request to the same address and receives a valid handshake response packet, it is determined that a reconnection has occurred. By judging whether the current connection is in a state of interruption and reconnection, the connection continuity of the path is marked. Among all paths, paths that have not experienced a disconnection or have failed to recover after a disconnection are removed, and only paths that have not experienced a disconnection during data transmission are retained. The determination of path continuity depends on the completeness of the response in the data transmission behavior and the continuity of the control information feedback. Combined with the fields such as "connecting", "disconnected", and "reconnecting" in the status data group, it is further verified whether the connection is a single continuous communication segment. The valid paths in the above verification results are numbered and organized, and combined with the source address information to form a path identifier sequence, finally obtaining a set of stable connection path sequences.

[0029] S203: Based on the connectivity performance of paths in the stable path sequence set, filter out paths that have not been interrupted or reconnected within the period, write the paths into the record structure list according to the original address reading order, and after filling the structure list, obtain the available domain name connection path structure. First, extract the status identifier field and communication process field corresponding to each path. Then, call the data sending log and response confirmation log of each path within a continuous communication cycle. Perform Boolean value judgment on the "broken link flag" and "reconnection flag" fields recorded in the log. If no broken link or reconnection flag with a Boolean value of "true" appears in any communication cycle, the path is determined to be a valid path with complete communication within the cycle. In practical applications, if a path "https: / / net-alpha.service.com" receives normal response packets in several consecutive data packet sending cycles and the corresponding field value in the log is always "false", it is classified as a valid path. Extract the path strings of all paths that meet the complete transmission requirements according to the address reading order recorded when the connection is successful. Write the extracted paths sequentially into a newly created address record structure list. During the writing process, call the unique identifier field corresponding to each path to build the associated key-value pairs in the record entries so that the port configuration parameters bound to the path can be located in the subsequent communication stage. After the writing is completed, each path field contained in the record structure list will serve as a candidate channel in the subsequent path selection process, and finally obtain the available domain name connection path structure.

[0030] Please see Figure 4 The specific steps of S3 are as follows: S301: Based on the main connection path in the available domain name connection path structure, extract the sending time and receiving time within the communication period, identify the time interruption in continuous data transmission, determine the changes in the number of requests and received feedback before and after the interruption, locate the start and end time period of the data interruption, and obtain the main connection interruption time period set. First, the logs of sent and received data packets during the communication phase on the main path are retrieved. The send time field and corresponding receive time field in each record are parsed to extract the time interval between consecutive data packets. The interval between the receive time and the next send time in each pair of adjacent data records is calculated and recorded. When the interval between any two time points exceeds a preset communication interval reference value, it is marked as a potential interruption node. In a specific scenario, for example, if the data packets continuously recorded on the main path "https: / / node-alpha.com" have a receive time of 190 and a send time of 27... If the interval is 0 and the interval is 80, which is much larger than the typical periodic value of 10, then this point is presumed to be the start of the interruption. At the same time, the number of requests and the response fields of the five consecutive times before and after the potential interruption point are retrieved. The number of requests marked "request sent" and the number of responses marked "response received" are counted. If the number of requests remains unchanged but the number of responses decreases significantly before and after the interruption point, then the communication interruption in this time period is confirmed. The start and end times are recorded and added to the interruption period list. Based on this, a merging and deduplication operation is performed on all confirmed interruption periods, and each segment is expressed by combining timestamps to finally obtain the main connection interruption period set.

[0031] S302: Based on the time boundary of the main connection interruption time period set, extract the transmission behavior and corresponding feedback information of the backup path within the same time range, analyze whether there is transmission interruption and response abnormality in the feedback, filter the backup path that has not been interrupted by continuous feedback status, and extract the field set corresponding to the path to obtain the backup path sequence information set. First, the start and end times of each interruption record within the time period are read as the boundaries of the time window. Then, data transmission records whose sending and receiving times fall within this time window are filtered from the communication logs of the backup path. After extraction, the sending field and corresponding feedback field of each record are parsed item by item to identify whether the feedback field contains an exception type code. If there are flags such as no response, connection timeout, or data loss, the path corresponding to that record is marked as having an exception. By setting the flag range for the feedback status, only path data that returns a normal status throughout the entire time window is retained. In specific scenarios, such as backup paths... If the communication records for the path "https: / / node-beta.com" continuously return "status code 200" or "connection valid" within the time interval from point A to point B when the main connection is interrupted, then the path is marked as an uninterrupted path. Conversely, if there is a return field of "status code 504" or "connection timeout", then the path is removed. After marking, all backup paths that have not shown any abnormalities are further counted, and their address field, port field, path label field, etc. in the configuration table are called. The above field values ​​are combined into a path field set. A field combination body is constructed from all paths that meet the conditions, and finally the backup path sequence information set is obtained.

[0032] S303: Based on the backup path sequence information set, execute data requests according to the start time of the main path interruption, analyze the range of response delay variation and the continuity of the completeness of the returned information, remove abnormally fluctuating paths, retain the paths with continuous transmission performance to replace the current main path, and obtain the main path replacement execution record structure. First, the address parameters, port number, connection protocol, and request tag corresponding to each path are read. Simulated data request operations are then initiated sequentially at the same start time as the main path's interruption time. The initiation and reception times are recorded during each request. The response latency of that path in the current transmission process is obtained. The magnitude of response time variation between different request rounds is calculated. An interval distribution judgment is performed on the response time results across all request cycles. If the response time offset of a path exceeds the average fluctuation threshold in several consecutive requests, it is marked as a response fluctuation path. For example, when requesting data in the file "ping_test.json", if the first three requests in a certain path are 120ms, 124ms, and 121ms respectively, but the fourth suddenly increases to 198ms... The path can then be identified as exhibiting fluctuations. Further analysis of the data packets returned by each request is performed to check for missing fields, incomplete content fragments, or returned error codes. The number of missing fields is counted per round. If the number of missing fields exceeds a set limit, the path is considered discontinuous. Through this two-dimensional analysis, paths with significant fluctuations or missing content are removed. Paths that maintain response latency within the average offset range, return complete data content structure, and have continuous fields within the request cycle are retained. Subsequent requests during the interruption period of the current main path are redirected to this retained path. Its availability is continuously monitored, and corresponding switching parameter information, triggering switching conditions, switching path identification data, path latency indicators, etc., are recorded. Finally, the main path replacement execution record structure is obtained.

[0033] Please see Figure 5 The specific steps of S4 are as follows: S401: Based on the activation path field information in the main path replacement execution record structure, divide the default path area in the original configuration content, match the field position corresponding to the activation path, and overwrite the original field content with the current path value to obtain the path field overwritten content; First, extract the path field from the record structure. This path field is typically the actual target address after the replacement action is completed. The field content is generally a full URL string or a combination of IP address and port, such as "http: / / api.domain.com:8080" or "192.168.100.8:9001". After extracting this field, locate the default path field area defined in the original configuration content. This area is generally identified by path tags, such as "default_url=", "base_link=", or "target_host=" as field prefixes in the configuration text. During the location process, first perform a string-level character-by-character comparison between the prefix or keyword in the active path field and the tag name in the configuration text, and perform a full match verification based on the number of characters to confirm its accuracy. If the match is perfect, the current position is located as the field position. Then, the line terminator of the matching field is analyzed to identify the start and end positions of the field value. After determining the original value range, the extracted path value is written to the original field value position according to the original format. For example, if the original field is "base_link=http: / / init.domain.net", it is directly replaced with "base_link=http: / / api.domain.com:8080". After the overwrite is completed, the target field content is read again. The result value of the replacement action is compared with the value of the activated path field. If the two characters are completely identical, it means that there is no abnormal deviation in the overwrite action. After the process is completed, the field position is marked for unified processing in the subsequent path reference cleanup stage. Finally, the overwritten content of the path field is obtained.

[0034] S402: Based on the replaced path value in the path field overridden content, identify the residual position of the corresponding old path field in the original configuration structure, delete the path content in the reference list, and obtain the reference path clearing data; First, the content of the overridden field is retrieved. This field is usually the latest activated path, such as "https: / / live.node01.com" or "http: / / api.region02.cn". After reading this path value, it is used as the reference item for the new path. A comparison operation is performed on all path fields in the original configuration structure. Before performing the comparison, all field name-value pairs are extracted from the configuration structure. Fields containing keywords such as "url", "path", and "endpoint" are screened, and their corresponding field values ​​are extracted sequentially. Then, the replaced path value and the extracted field value are compared character by character. The comparison method uses character-by-character matching. If there are multiple character differences between the extracted field value and the replacement value, it is determined to be the original residual field location. If the number of characters is the same but only the port number or protocol part is different, for example, the replaced value is "https: / / api.service.com:443" and the original field is "http: / / api.service.co". If "m:80" is an old field, it is determined by comparing the protocol prefix with the port field. After matching the old path field position, its role in the reference list is further analyzed. The reference list is usually a field call area listed at the end of the configuration file in the form of path index, with formats such as "path_index=target_path" and "link_list=node_url". These entries are scanned sequentially and the value field is extracted. Each reference item is compared with the old field value. If a match is found, it is marked as a path reference item that needs to be cleared. In all marked items, the deletion action is performed from the field order, that is, it is removed from the configuration structure or path set. At the same time, the value field record of the associated field name is cleared. For example, the line content is removed from "link_list=http: / / old.service.net". After the deletion action is completed, a clearing list is built. This list consists of the deleted path field content and serves as the reference basis for subsequent path updates. Finally, the reference path clearing data is obtained.

[0035] S403: Based on the reference path, clear the access entry position in the data, write the current path value item by item, replace the path field in the configuration, keep each access entry pointing to the current path content, and obtain the updated multi-domain distribution structure; First, the address list in the reference clearing result is invoked. This address list is typically in the form of " / login", " / auth / token", " / api / request", etc., which are the interface entry points used for external calls in the original configuration. Each access entry corresponds to a field reference item. Each path item in this list is traversed item by item. For each traversed item, a field matching operation is performed. Using the path as a keyword, all key-value pairs in the original configuration structure are scanned, and configuration locations containing the current path content in the field name are extracted. For example, for the access entry " / login", field names such as "login_path=" and "user_login_url=" are matched. By checking whether the field value contains null values, default path values, or old path remnants, it is identified as the target location to be written. Then, the corresponding current path value is extracted from the already generated path field overridden content. For example, the field "active_path=https: / / node4.api.com" is obtained, and this value is assigned to the value field of all matching fields. When performing the replacement operation, it is necessary to check whether the original data format of the field contains escape characters, path... For path suffix or additional parameter fields, if the original field is "login_path=https: / / old.domain.com / login?retry=1", the "?retry=1" additional item must be cleared first, keeping only the main path and replacing it with the new value. Then, the new path value is concatenated with the required parameters and written back to the original position. After completing the writing operation, this process is repeated for all access entry points to ensure that the current path value is replaced for each access path item. Finally, multiple entry fields all point to the same main path source. After the traversal processing is completed, a structure object is constructed, and the updated path field values ​​are rearranged in key-value pairs and organized into a structure output item set according to the original configuration format. Each item is in the format "access_entry_x=current_path_value", where access_entry_x represents the entry field name and current_path_value is the replaced path content, such as "access_entry_1=https: / / node4.api.com / login". Finally, the updated multi-domain distribution structure is obtained.

[0036] Please see Figure 6 The specific steps of S5 are as follows: S501: Based on the updated multi-domain distribution structure, extract the address parameter field in the original request process, compare the parameter field with the target address field in the path content, locate the corresponding field position and replace the address value to obtain the address parameter replacement field; First, all key-value pairs in the structure are retrieved, and the main access address field corresponding to each path is extracted, for example, "https: / / cdn.node7.proxy.com / resource". This address is used as the target comparison object. The parameter structure relied upon during request construction is read from the native request flow, and fields with address characteristics are extracted. It is determined whether the field value contains typical identifiers, such as the "http" prefix, " / api", or " / v1" directory, to identify whether it is the address parameter field that needs to be matched and replaced. Then, each extracted parameter field is compared one by one with each path value in the update path list. During the comparison, a whole-character matching operation of the field value is used. Without using fuzzy matching, each path field is checked to see if it contains nested original address values ​​or has the same directory cascading structure. For example, "https: / / old.domain.cn / api / user?id=5" is compared with "https: / / cdn.node7.proxy.com / api / user". If the path prefix is ​​the same and the directory structure is consistent, it is marked as... If a match is successful, record the field position and original value in the parameter structure, and use this address field as the target field for replacement. During the replacement process, read the field name and its hierarchical position in the parameter structure, and construct a new value according to the original structure format. For example, retain the original field name "request_url" and replace its value from "https: / / old.domain.cn / api / user" to "https: / / cdn.node7.proxy.com / api / user". At the same time, check whether the parameter structure contains nested request headers, authorization information, or other signature fields. If so, re-verify the consistency of the complete parameter set before and after the address change. During the check, a fixed content checking process should be called to compare whether the number of fields and field names have changed, and verify whether the original field parameters are retained in the replaced address. For example, whether "id=5" still exists at the end of the replaced address. Ensure that the original parameter fields are not lost during value replacement. After all matched fields are replaced, append the changed address field result to the record set for subsequent request process reconstruction or rewriting, and finally obtain the address parameter replacement field.

[0037] S502: Call the address parameter replacement field to replace the replaced address value, match the resource loading path field in the embedded web page display structure, update the resource path according to the same field replacement logic, and obtain the resource path replacement field; First, iterate through each address parameter in this field, extracting the complete network path string content from each replacement address value, such as "https: / / cdn.proxy8.io / static / js / index.js". Extract the resource directory level and file type suffix in the path through character truncation, and use this value as the matching target object. Then, compare each field of the resource loading path field in the embedded webpage display structure. After extracting all path field values, perform a consistency matching operation based on the path prefix, directory structure, and filename. For example, if a path field in the display structure is "https: / / old.cdn.net / static / js / index.js", then " / static / js / index.js" is used as the comparison key. If the filename at the end of the path matches, it is considered a successful match. Record its field position and current value in the display structure. Next, construct the replacement address value, using "https: / / cdn.proxy8.io" as the new prefix, and concatenate it with the end structure of the original path to generate the complete resource address "https: / / cdn.proxy8". The new path value is assigned to the corresponding field in the display structure, io / static / js / index.js. During the replacement process, the field names and formats must remain consistent, and the replacement path must be verified to ensure it can be correctly parsed by the display structure. If the display structure expresses the resource list in a nested JSON format, all path fields within the structure must be recursively traversed. Before each path field replacement, the parent node field type must be verified to be a tag field with resource identification characteristics, such as "resource", "url", or "src", to avoid structural anomalies caused by replacing non-path fields. For paths containing placeholder content such as "{cdn_host} / img / logo.png", the field name referred to by the placeholder content should be extracted first, and then the corresponding field value should be found in the address parameter replacement field for placeholder replacement. Then, the path merging operation should be performed to ensure that the final generated path does not contain illegal symbols or unresolved template tags. After all resource path fields are replaced, the replaced path fields and their original field positions are constructed into a path replacement mapping set, which serves as the operation record content for the resource update process, ultimately yielding the resource path replacement fields.

[0038] S503: Based on the updated path value in the resource path replacement field, load the web page resource content, initiate each type of network request in the direction indicated by the path, continuously collect access response status and resource loading completion information, and obtain the dynamic network request optimization path for the entire link landing. First, perform resource loading initialization for each path field. Then, execute the URL request pointed to by the path using a browser emulator or resource fetching component. After each request, record the request header information and the corresponding response header status code. The response status code must capture a complete three-digit format and be categorized into three ranges: success, redirection, and failure. Success status codes are all values ​​between 200 and 299, redirection status codes are between 300 and 399, and failure status codes are all values ​​above 400. If the path request returns a failure status, record the corresponding resource name and path address, and mark it as an abnormal path. For each successfully loaded resource path, its content length and resource type suffix (e.g., css, js, png) must be recorded. The actual loaded size of the resource is checked against the content length; if it is zero, loading is considered a failure. Simultaneously, the resource's position index in the DOM structure is recorded, for example, by determining its order value through the path's insertion position within an HTML tag. After each resource loading is complete, subsequent path requests are continuously initiated via timed callbacks, forming an access sequence record table. This table displays the start time, end time, response time difference, status code value, and resource size in bytes for each path, sorted by time. To evaluate the access response status, it's necessary to calculate the percentage of successfully loaded resources for each resource type. For example, if a batch of resources contains 50 JS files, and 47 of them have a response status code of 200, the success rate is 94%. Success rates are calculated separately for each resource type. Resource paths with a success rate below 90% are screened and output to an abnormal path record table. When determining resource loading completion information, the criteria are a non-zero resource volume field and a status code of 200. A set of completed resource fields is constructed. After all paths have been processed, based on the path loading time sequence record, the data is analyzed according to resource type, loading order, and response time difference. Each path is sorted according to the request timeline, and loading segments are constructed by category. For example, all CSS file loading paths are sorted and merged into a "style loading path block", and JS resources are integrated into a "script loading path block". The request distribution within each path block is checked for intervals. If the time interval between the loading response of adjacent resources in a certain path block exceeds a set reference value, such as 2 seconds, then the segment is marked as a loading delay area. The actual access address, status code and resource size of the path involved in the segment are recorded. The above record table constitutes a complete request tracing record, and finally the dynamic network request optimization path with full-link landing is obtained.

[0039] Please see Figure 7 A mobile application network optimization system based on dynamic multi-domain selection includes: The device parameter extraction module obtains identification information, country code and version information, fills the fields into the request parameters in sequence, extracts the field values ​​and compares them with the preset set, analyzes the field matching items and filters the associated domain name addresses to obtain the candidate domain name grouping structure; The connection path filtering module initiates requests sequentially based on the domain name addresses of the candidate domain name grouping structure, judges the connection status and identifies whether it is interrupted, filters the continuously connectable paths, and obtains the available domain name connection path structure. The channel path replacement module identifies data interruption and reconnection actions during communication based on the main connection channel in the available domain name connection path structure, determines whether the backup path maintains continuous communication within the same period, and replaces the main channel with the backup path to request connection, thus obtaining the main path replacement execution record structure. The configuration path update module replaces the path content in the execution record structure based on the main path, locates the local default path, replaces it with the current path and clears the old path reference, replaces the path address, and obtains the updated multi-domain distribution structure. The network path assignment module replaces the request fields of the interface and web page display resources based on the domain name address bound in the updated multi-domain distribution structure, and re-initiates the resource access operation to obtain a dynamic network request optimization path with end-to-end landing.

[0040] 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 variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included 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 mobile application network optimization method based on dynamic multi-domain selection, characterized in that, Includes the following steps: S1: Obtain identification information, country code and version information, fill the fields into the address parameter positions, extract the field values ​​and analyze the consistency with the configuration fields, match the configuration entries, extract the related domain name content, and obtain the candidate domain name grouping structure; S2: Based on the domain name field in the candidate domain name grouping structure, initiate an access request, determine whether the return status is successful, identify connection interruption and reconnection, filter smooth paths and add them to the path list to obtain the available domain name connection path structure. S3: Based on the main connection path in the available domain name connection path structure, identify communication interruption and reconnection behaviors, determine connection continuity, analyze whether the backup path will replace the current path after no interruption occurs, and obtain the main path replacement execution record structure. S4: Based on the main path replacement execution record structure, the active path field is selected and written to the current path, the old value is cleared and the entry path is synchronized to obtain the updated multi-domain distribution structure; S5: Based on the path bound in the updated multi-domain distribution structure, replace the original request address and webpage loading path, inject the path to initiate an access action, and obtain the dynamic network request optimization path for end-to-end landing.

2. The mobile application network optimization method based on dynamic multi-domain selection according to claim 1, characterized in that, The candidate domain name grouping structure includes the consistency verification results of the identification information field, country code field, and version information field, the set of available configuration entries, and the filtered domain name data. The available domain name connection path structure includes the request address, return status content, connection success status marker, link interruption identification information, and path record list. The main path replacement execution record structure includes the main connection channel status identifier, communication interruption event identifier, backup path communication continuity analysis results, and main connection replacement path. The updated multi-domain name distribution structure includes the activation path field, original configuration path location, current path value, old path association record, and access entry path synchronization replacement item. The dynamic network request optimization path with full-link landing includes the address parameter field replacement result, embedded web page resource path, page loading action path, and updated network access path.

3. The mobile application network optimization method based on dynamic multi-domain selection according to claim 1, characterized in that, The configuration fields refer to a preset set of parameters, which are used to compare the consistency of uploaded information and filter configuration items and candidate domain names. The associated domain name content refers to the domain name data extracted from the matching configuration items for network access.

4. The mobile application network optimization method based on dynamic multi-domain selection according to claim 1, characterized in that, The "clearing old values" refers to deleting the traces of the old path fields in the reference list in the original configuration during the path update process, thereby preventing the old path from being called again and interfering with the new path. The replacement of the original request address refers to updating the old access address using dynamically filtered paths.

5. The mobile application network optimization method based on dynamic multi-domain selection according to claim 1, characterized in that, The specific steps of S1 are as follows: S101: Obtain identification information, country code and version information, fill the fields into the parameter positions of the access address, extract the field values ​​in a fixed order after the filling action, and compare and analyze the consistency with the corresponding items in the configuration field set to obtain a field consistency matching record set; S102: Based on the field groups in the field consistency matching record set, extract the configuration entry identifier code associated with each group, call the configuration entry identifier code and compare the tag fit with the tag set to which the current request belongs, filter the entries in the tag intersection that include the field group content, and obtain the matching configuration entry identifier set; S103: Based on the domain name parameter field associated with the entries in the matching configuration entry identifier set, extract the domain name content and fill the corresponding domain name parameter field into the preset position in the return response structure. After the field is filled in, write the response structure into the network return channel to obtain the candidate domain name grouping structure.

6. The mobile application network optimization method based on dynamic multi-domain selection according to claim 1, characterized in that, The specific steps of S2 are as follows: S201: Based on the domain name field information in the candidate domain name grouping structure, initiate a network request operation to each domain name address, identify the returned data packet status field, determine whether the returned status is a connection establishment success identifier type, aggregate the address fields of the success type, and obtain the initial successful connection address set; S202: Call the addresses in the initial successful connection address set, analyze the data communication flow on each path during the connection phase, monitor whether the link is disconnected during each data transmission behavior, identify whether the client automatically re-establishes the connection after the disconnection, determine the continuity based on the status of the connection behavior, and obtain a set of stable connection path sequences. S203: Based on the connectivity performance of the paths in the stable path sequence set, filter the paths that have not been interrupted or reconnected within the period, write the paths into the record structure list according to the original address reading order, and after filling the structure list, obtain the available domain name connection path structure.

7. The mobile application network optimization method based on dynamic multi-domain selection according to claim 1, characterized in that, The specific steps for S3 are as follows: S301: Based on the main connection path in the available domain name connection path structure, extract the sending time and receiving time within the communication period, identify the time interruption in continuous data transmission, determine the changes in the number of requests and received feedback before and after the interruption, locate the start and end time period of the data interruption, and obtain the main connection interruption time period set. S302: Based on the time boundary of the main connection interruption time period set, extract the transmission behavior and corresponding feedback information of the backup path within the same time range, analyze whether there is transmission interruption and response abnormality in the feedback, filter the backup path that has not been interrupted by continuous feedback status, and extract the field set corresponding to the path to obtain the backup path sequence information set. S303: Based on the backup path sequence information set, execute data requests according to the start time of the main path interruption, analyze the range of response delay changes and the continuity of the completeness of the returned information, remove abnormally fluctuating paths, retain the paths with continuous transmission performance to replace the current main path, and obtain the main path replacement execution record structure.

8. The mobile application network optimization method based on dynamic multi-domain selection according to claim 1, characterized in that, The specific steps of S4 are as follows: S401: Based on the activation path field information in the main path replacement execution record structure, divide the default path area in the original configuration content, match the field position corresponding to the activation path, and overwrite the original field content with the current path value to obtain the path field overwritten content; S402: Based on the replaced path value in the path field coverage content, identify the residual position of the corresponding old path field in the original configuration structure, delete the path content in the reference list, and obtain the reference path clearing data; S403: Based on the access entry position in the reference path clearing data, write the current path value item by item, replace the path field in the configuration, and keep each access entry pointing to the current path content to obtain the updated multi-domain distribution structure.

9. The mobile application network optimization method based on dynamic multi-domain selection according to claim 1, characterized in that, The specific steps of S5 are as follows: S501: Based on the updated multi-domain distribution structure, extract the address parameter field in the original request process, compare the parameter field with the target address field in the path content, locate the corresponding field position and replace the address value to obtain the address parameter replacement field; S502: Call the address parameter replacement field to replace the replaced address value, match the resource loading path field in the embedded web page display structure, update the resource path according to the same field replacement logic, and obtain the resource path replacement field; S503: Based on the updated path value in the resource path replacement field, load the web page resource content, initiate each type of network request in the direction indicated by the path, continuously collect access response status and resource loading completion information, and obtain the dynamic network request optimization path for the entire link landing.

10. A mobile application network optimization system based on dynamic multi-domain selection, characterized in that, The system is used to implement the mobile application network optimization method based on dynamic multi-domain selection as described in any one of claims 1-9, and the system includes: The device parameter extraction module obtains identification information, country code and version information, fills the fields into the request parameters in sequence, extracts the field values ​​and compares them with the preset set, analyzes the field matching items and filters the associated domain name addresses to obtain the candidate domain name grouping structure; The connection path filtering module initiates requests sequentially based on the domain name addresses of the candidate domain name grouping structure, determines the connection status and identifies whether it is interrupted, filters continuously connectable paths, and obtains the available domain name connection path structure. The channel path replacement module identifies data interruption behavior and reconnection actions during communication based on the main connection channel in the available domain name connection path structure, determines whether the backup path maintains continuous communication within the same period, replaces the main channel with the backup path to request connection, and obtains the main path replacement execution record structure. The configuration path update module locates the local default path position based on the path content in the main path replacement execution record structure, replaces it with the current path and clears the old path reference, replaces the path address, and obtains the updated multi-domain distribution structure. The network path assignment module replaces the request fields of the interface and web page display resources based on the domain name address bound in the updated multi-domain distribution structure, and re-initiates the resource access operation to obtain a dynamic network request optimization path for the entire chain.

Images