Improvement method for one-key login of mobile phone number to weak network and electronic equipment

Abstract

The invention discloses an improved method for logging in a weak network by a mobile phone number through one key and electronic equipment, and belongs to the technical field of communication, and the method comprises the following steps: a main processor creates a pre-connection pool, records a pre-connection domain name and a port list, and executes pre-connection; meanwhile, various parameters required by number prefetching are prepared, and a number prefetching request is sent; the network processor creates a retry controller, and the retry controller intelligently determines a corresponding retry mode according to the failure reason and the network state; unnecessary repeated operation is avoided by means of implementing a breakpoint resume type retry mechanism, error type detection and classification processing, network availability judgment and automatic reconstruction, private network IP change detection and URL reconstruction, an exponential backoff algorithm to control a retry interval and the like, and a staged timeout mechanism is introduced, so that the retry efficiency is improved. The personalized reasonable timeout time of different stages is set, the problem that a certain stage consumes too long time is avoided, and the network request success rate of the SDK in the weak network environment is improved.

Description

Technical Field

[0001] This application belongs to the field of communication technologies, and particularly relates to an improved method for one-key login of mobile phone numbers in a weak network and an electronic device. Background Art

[0002] At present, the disadvantages of the one-key login SDK prefetching technology solution mainly include several aspects: 1) When the application App calls the one-key login SDK to prefetch numbers, the generally set total timeout time does not exceed 5 seconds. In a weak network environment, the SDK prefetching process is prone to TCP connection establishment or data transmission failure due to network fluctuations, resulting in prefetching failure or timeout; 2) The existing SDK prefetching retry mechanism is for overall retry. Once the request fails, it will start retrying from the first step. Due to the long process, the overall retry reduces the success rate of prefetching retry; 3) There is a lack of phased timeout control for weak network scenarios, and a unified timeout time is used in each stage of the network request, resulting in easy overall timeout when the network condition fluctuates.

[0003] In view of the above problems, an improved method for one-key login of mobile phone numbers in a weak network and an electronic device of this application are proposed. Summary of the Invention

[0004] To solve the deficiencies of the existing technology described above, this application provides an improved method for one-key login of mobile phone numbers in a weak network, which can solve technical problems in the existing technology such as the SDK prefetching process being prone to TCP connection establishment or data transmission failure due to network fluctuations, resulting in prefetching failure or timeout, low retry success rate, and easy overall timeout.

[0005] The technical effects to be achieved by this application are realized through the following solutions: In a first aspect, this application provides an improved method for one-key login of mobile phone numbers in a weak network, including: The main processor creates a pre-connection pool, which records the list of domain names and ports of the pre-connections and performs pre-connection operations. The main processor intelligently maintains the list of domain names and ports of the pre-connections according to the previous request records of the current device, and preposes DNS resolution and TCP connection creation so as to execute concurrently with the steps of preparing various parameters required for the main processor to prefetch numbers; The main processor prepares various parameters required for prefetching numbers, performs private network IP acquisition, data encryption, and signature calculation, and sends a prefetching number request to the network processor. The various parameters required for prefetching numbers include application authentication information, device information, and network information; After receiving the prefetching number request, the network processor creates a retry controller and sets a callback function, which is used to actually initiate a network request. The retry controller triggers the callback function and passes in the URL that needs to initiate a network request currently; The callback function receives the URL and initiates a network request, receives the returned HTTP result. When the returned HTTP result is 302, a recursive call is executed to initiate a network request to the redirected URL. When the returned HTTP result is not 302, the callback function returns the returned HTTP result, the depth of the recursive call, and the current URL to the retry controller; The retry controller returns the HTTP response result to the main processor; The main processor receives and parses the HTTP response result, and extracts the prefetch number result, which includes the access code and the mobile phone number mask.

[0006] In some embodiments, the execution of the pre-connection operation includes: Create an independent worker thread for each pre-connection task; According to the network condition and the total timeout time set by the user, calculate the reasonable timeout times for DNS resolution, TCP handshake, and TLS handshake; Return the differentiated timeout parameters for each stage; Create an SSLSocket and set parameters; Configure DNS resolution and TCP parameters, and perform TCP connection and TLS handshake; Store the SSLSocket object in the pre-connection pool and mark the connection status.

[0007] In some embodiments, the initiation of a network request to the redirected URL includes: The network processor obtains the domain name and port information from the URL parameters; The pre-connection pool returns an SSLSocket according to the domain name and the port information; The network processor creates an HTTPS connection based on the SSLSocket and accesses the corresponding URL; The HTTPS connection returns the target HTTP result. When the target HTTP result is 302, the callback function will make a recursive call to access the redirected URL.

[0008] In some embodiments, the pre-connection pool returns an SSLSocket according to the domain name and the port information, including: When there is an available connection in the connection pool corresponding to the domain name and port information, directly reuse the existing connection and return the SSLSocket; When there is a connection in the connection pool corresponding to the domain name and port information and the connection is in progress, wait for the connection state to end and return the SSLSocket; When there is no available connection in the connection pool corresponding to the domain name and port information, a new SSLSocket is created to perform the connection operation and then the new SSLSocket is returned.

[0009] In some embodiments, the method further includes: Setting a phased timeout mechanism, setting reasonable and differentiated timeout times according to each stage of the network request, and dynamically adjusting the reasonable timeout times of each stage according to the total prefetch number timeout value.

[0010] In some embodiments, before the retry controller returns the HTTP response result to the main processor, it further includes: The retry controller determines whether a retry is needed; When a retry is needed, the retry controller extracts the redirect URL and the current call depth from the failure result, preferentially uses the obtained redirect URL and call depth information, and directly continues to execute the subsequent request from the failure point, where the subsequent request includes: executing different retry policies according to the failure type and the network status, carrying the updated URL, and re-triggering the callback function; When a retry is not needed, the HTTP response result is obtained.

[0011] In some embodiments, the execution of different retry policies according to the failure type includes: If the failure type is a network exception, check the network availability and evaluate the network quality. When the network is unavailable or of poor quality, recreate the cellular network object, reset the pre-connection pool, and trigger the pre-connection operation for the recreated pre-connection pool; If the failure type is the invalidation of the private network IP, re-obtain the private network IP and update the request URL; If the failure type is a business error, decide whether to retry according to the error type.

[0012] In some embodiments, each stage includes: the DNS resolution stage, the TCP handshake stage, and the TLS handshake stage. The reasonable timeout time for the DNS resolution stage is 300 ms, the reasonable timeout time for the TCP handshake stage is 900 ms, and the reasonable timeout time for the TLS handshake stage is 1200 ms.

[0013] In a second aspect, the present application provides an electronic device, which includes: a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the computer program, the method described in any one of the foregoing is implemented.

[0014] In a third aspect, the present application provides a computer-readable storage medium storing one or more programs, which can be executed by one or more processors to implement the method described in any one of the foregoing items.

[0015] Through the improved method for one-key login in weak network and the electronic device provided by the embodiments of the present application, in the scenario of prefetching numbers by the one-key login SDK of the mobile phone, the required server list is collected by using the current device request record for TCP pre-connection, a "breakpoint resume" retry mechanism, error type detection and classification processing during the retry process, network availability judgment and automatic reconstruction, private network IP change detection and URL reconstruction, a phased timeout control mechanism, etc., improving the success rate of network requests of the SDK in a weak network environment. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0017] Figure 1 It is a flowchart of the improved method for one-key login in weak network in an embodiment of the present application; Figure 2 It is a pre-connection schematic diagram of the improved method for one-key login in weak network in an embodiment of the present application; Figure 3 It is the specific implementation of the improved method for one-key login in weak network in an embodiment of the present application Figure 1 ; Figure 4 It is a schematic block diagram of an electronic device in an embodiment of the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0018] To make the objectives, technical solutions, and advantages of the present application clearer, the technical solutions of the present application will be clearly and completely described below in conjunction with specific embodiments and the corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all of the embodiments. Based on the embodiments of the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts fall within the protection scope of the present application.

[0019] It should be noted that, unless otherwise defined, the technical terms or scientific terms used in one or more embodiments of the present application should be understood by people with ordinary skills in the field to which the present application belongs. The "first", "second" and similar words used in one or more embodiments of the present application do not indicate any order, quantity or importance, but are only used to distinguish different components. "Include" or "comprise" and similar words mean that the elements or objects appearing before the word cover the elements or objects listed after the word and their equivalents, without excluding other elements or objects. "Connect" or "connected" and similar words are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect. "Up", "down", "left", "right" and the like are only used to indicate relative positional relationships. When the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0020] In related technologies, the operator's one-click login with a mobile phone number is to use the smartphone's cellular network to initiate a data request to the one-click login server, and the one-click login service obtains the complete mobile phone number information from the cellular network connection. The pre-number request is the key to the entire process. The one-click login SDK actively initiates a pre-number request. After the backend service receives the request, it triggers the SDK to make three connection redirection requests, a total of four requests to complete the pre-number operation. The main process includes: 1. The user opens the mobile app and enters the login interface. At this time, the app needs to prepare for a one-click login and pre-retrieval number operation.

[0021] 2. The application App calls the SDK's pre-number acquisition method, sets parameters such as timeout, encryption type, and callback function, and starts the pre-number acquisition process.

[0022] 3. The SDK constructs the request parameters and creates a new HTTP connection, sending a pre-number request to the One-Click Login Access Gateway. The request contains parameters such as application ID, device information, and network information.

[0023] 4. After the one-click login access gateway receives the request, if it cannot determine the province to which the current mobile phone number is connected to the base station, it will return the HTTP 302 status code, instructing the SDK to redirect to the China Unicom portal service address. The redirection URL carries parameters such as application information and request identifier.

[0024] 5. Based on the received redirection information, the SDK creates a new connection pointing to the China Unicom portal service address and sends a GET request.

[0025] 6. After receiving the request, the China Unicom portal service determines the province to which the mobile phone number accesses the base station, and then returns the HTTP 302 status code, instructing the SDK to redirect to the corresponding provincial authentication service address. The redirection URL is accompanied by user analysis information and authorization parameters.

[0026] 7. Based on the redirection information received, the SDK creates a new connection to the user's provincial authentication service address and sends a GET request.

[0027] 8. After the provincial authentication service completes user identification and authorization, it returns the HTTP 302 status code, instructing the SDK to redirect to the one-click login callback gateway address. The redirection URL carries the authentication code information, which is an important credential for subsequent processing.

[0028] 9. Based on the redirection information received, the SDK creates a new connection to the one-key login callback gateway address and sends a GET request with the authentication code.

[0029] 10. After receiving the request, the one-click login callback gateway initiates a request to the provincial authentication service through the authentication code.

[0030] 11. After verification, the provincial authentication service generates a pcode and user mobile phone number mask as user identification information.

[0031] 12. One-click login callback gateway securely encapsulates the pcode and generates a temporary access code, which is used in the subsequent number replacement phase.

[0032] 13. One-click login callback gateway returns accesscode and mobile phone suffix code to SDK.

[0033] 14. After receiving the information returned by the one-key login callback gateway, the SDK parses and extracts the access code and mobile phone mask.

[0034] 15. The application App displays the login authorization page, which shows the user's mobile phone number mask and waits for the user to confirm the authorization.

[0035] The above solution has the disadvantages that the SDK pre-numbering process is prone to TCP connection establishment or data transmission failure due to network fluctuations, resulting in pre-numbering failure or timeout, low retry success rate, and easy overall timeout.

[0036] Therefore, it is necessary to adopt the improved method and electronic device for one-click login to weak network by mobile phone number provided by this application. The focus of this application is to solve the above-mentioned drawbacks of the one-click login pre-number scenario of mobile phone. The main measures include the following points: (1) Pre-connection mechanism: The SDK intelligently maintains a list of pre-connected domain names and ports based on the previous request records of the current device. When the application App calls the SDK's pre-number fetching method, TCP connections to multiple servers are established in advance, rather than the existing SDK establishing connections only when an actual request is made. By pre-resolving the DNS local cache, combined with optimized TCP parameter configuration and multi-threaded parallel connection strategies, the connection establishment phase is separated from the critical request path.

[0037] (2) Intelligent retry strategy: It can intelligently determine which retry method to use based on the failure reason and network status. By implementing a "resume interrupted transfer" - style retry mechanism, error type detection and classification processing, network availability judgment and automatic reconstruction, private network IP change detection and URL reconstruction, and exponential backoff algorithm to control the retry interval, unnecessary repeated operations are avoided, and the retry efficiency and success rate are improved.

[0038] (3) Segmented timeout control: A refined phased timeout mechanism is introduced. Different timeout times are set according to each stage of the network request (DNS resolution 300ms, TCP handshake 900ms, TLS handshake 1200ms, first packet response 1800ms), and the timeout time for each stage is dynamically calculated based on the total timeout value of the pre-number fetching set by the application App. This avoids the problem that the subsequent stage or retry time is insufficient due to a long time-consuming in a certain stage, is suitable for a weak network environment with large network fluctuations, and improves the success rate of the overall request.

[0039] Next, in conjunction with the accompanying drawings, various non-limiting embodiments of the present application will be described in detail.

[0040] First, with reference to Figure 1 , the improved method for one-key login of mobile phone numbers in a weak network of the present application will be described in detail.

[0041] The present application provides an improved method for one-key login of mobile phone numbers in a weak network, including: S1: The main processor creates a pre-connection pool, which records the list of pre-connected domain names and ports, and performs pre-connection operations. The main processor intelligently maintains the list of pre-connected domain names and ports based on the previous request records of the current device, and advances DNS resolution and TCP connection creation so as to execute concurrently with the steps of preparing various parameters required for the main processor to pre-fetch numbers; S2: The main processor prepares various parameters required for pre-fetching numbers, performs private network IP acquisition, data encryption, and signature calculation, and sends a pre-number fetching request to the network processor. The various parameters required for pre-fetching numbers include application authentication information, device information, and network information; S3: After receiving the prefetch number request, the network processor creates a retry controller and sets a callback function, which is used to actually initiate a network request. The retry controller triggers the callback function and passes in the URL that needs to initiate a network request currently. S4: The callback function receives the URL and initiates a network request, and receives the returned HTTP result. When the returned HTTP result is 302, a recursive call is executed to initiate a network request to the redirected URL. When the returned HTTP result is not 302, the callback function returns the returned HTTP result, the recursive call depth, and the current URL to the retry controller. S5: The retry controller returns the HTTP response result to the main processor. S6: The main processor receives and parses the HTTP response result, and extracts the prefetch number result, where the prefetch number result includes an access code and a mobile phone number mask.

[0042] Exemplarily, steps S1 and S2 above can be executed in parallel, so that operations such as DNS resolution and TCP connection creation are preposed and executed concurrently with the preparation of prefetch number parameters, improving the network request efficiency.

[0043] Through the improved method and electronic device for one-key login in weak network of mobile phone numbers provided by the embodiments of the present application, in the scenario of prefetching numbers by the mobile phone one-key login SDK, a required server list is collected using the current device request record for TCP pre-connection, a "breakpoint resume" - type retry mechanism, error type detection and classification processing during the retry process, network availability judgment and automatic reconstruction, private network IP change detection and URL reconstruction, a phased timeout control mechanism, etc., improving the success rate of network requests of the SDK in a weak network environment.

[0044] As Figure 2 shown, the pre-connection mechanism of the present application includes: Asynchronous multi-threaded execution of DNS resolution, asynchronous multi-threaded execution of a TCP pre-connection pool. Among them, the first of the three modified boxes connected together represents obtaining a connection from the TCP pre-connection pool, the second box represents request and response (request + respond), and the third box represents the SDK processing the response message; where connect includes a TCP connection and a TLS handshake.

[0045] The SDK intelligently maintains a list of pre-connected domain names and ports based on the previous request records of the current device, and pre-establishes TCP connections to multiple servers when the application App calls the SDK prefetch number method, separating the DNS resolution, TCP connection, and TLS handshake processes in the originally serial execution of 4 http requests from the process and performing preposed asynchronous execution before the actual request occurs, reducing the time of 4 http requests.

[0046] In some embodiments, performing the pre-connection operation includes: Creating an independent worker thread for each pre-connection task; Calculating reasonable timeout times for DNS resolution, TCP handshake, and TLS handshake according to the network condition and the total timeout time set by the user; Returning differential timeout parameters for each stage; Creating an SSLSocket and setting parameters; Configuring DNS resolution and TCP parameters, and performing TCP connection and TLS handshake; Storing the SSLSocket object in the pre-connection pool and marking the connection status.

[0047] In some embodiments, initiating a network request to the redirected URL includes: The network processor obtains the domain name and port information from the URL parameters; The pre-connection pool returns an SSLSocket according to the domain name and the port information; The network processor creates an HTTPS connection based on the SSLSocket and accesses the corresponding URL; The HTTPS connection returns the target HTTP result. When the target HTTP result is 302, the callback function will make a recursive call to access the redirected URL.

[0048] In this application, steps such as DNS pre-resolution and switching of device networks, TCP pre-connection and request parameter assembly are executed concurrently in an asynchronous thread manner. DNS resolution and TCP connection are preposed, improving the overall execution efficiency.

[0049] See Appendix Figure 3 , after the pre-area number is initialized, DNS resolution is first performed, and an asynchronous thread is started. The DNS resolution process includes: traversing the domain name cache list, performing Local DNS resolution using the system InetAddress, updating the cached IP and the validity period; switching the device network, performing TCP connection, and starting an asynchronous thread. The TCP connection process includes: traversing the domain name cache list, creating an SSLSocket for TCP connection and TLS handshake, and updating the connection status of the pre-connection pool.

[0050] Assemble the request parameters, parse the domain name and port information from the request URL, update the local domain name cache list according to the domain name and port information, obtain the corresponding domain name connection from the pre-connection pool, initiate a network request using this connection. If the request is successful, return the pre-fetch number result. If the request fails, determine whether to perform a 302 redirect. If a redirect is required, return to the step of parsing the domain name and port information from the request URL to start execution. If not, return the pre-fetch number result.

[0051] In some embodiments, the pre-connection pool returns an SSLSocket according to the domain name and the port information, including: When there is an available connection in the connection pool corresponding to the domain name and port information, directly reuse the existing connection and return the SSLSocket; When there is a connection in the connection pool corresponding to the domain name and port information and the connection is in progress, wait for the connection state to end and return the SSLSocket; When there is no available connection in the connection pool corresponding to the domain name and port information, create a new SSLSocket, perform a connection operation, and then return the new SSLSocket.

[0052] In some embodiments, the method further includes: Set a phased timeout mechanism, set different reasonable timeout times according to each stage of the network request, and dynamically adjust the reasonable timeout times of each stage according to the total pre-fetch number timeout value.

[0053] In some embodiments, before the retry controller returns the HTTP response result to the main processor, it further includes: The retry controller determines whether to retry; When a retry is required, execute different retry policies according to the failure type, carry the updated URL, and re-trigger the callback function; When a retry is not required, obtain the HTTP response result.

[0054] In some embodiments, the execution of different retry policies according to the failure type includes: If the failure type is a network exception, check the network status, rebuild the connection pool, and update the DNS resolution; If the failure type is a private network IP failure, re-obtain the private network IP and update the request URL; If the failure type is a business error, determine whether to retry according to the error type.

[0055] In some embodiments, each stage includes: a DNS resolution stage, a TCP handshake stage, and a TLS handshake stage. The reasonable timeout for the DNS resolution stage is 300 ms, the reasonable timeout for the TCP handshake stage is 900 ms, and the reasonable timeout for the TLS handshake stage is 1200 ms.

[0056] A detailed description of an embodiment of the present application is as follows: 1. The main processor detects the current network environment and forcibly switches to the cellular network to obtain network objects.

[0057] 2. The main processor creates a pre-connection pool.

[0058] 3. The main processor creates a child thread and asynchronously calls the pre-connection pool method to trigger a pre-connection operation. The input parameters are a list of domain names and ports collected according to the URLs accessed by the device's previous prefetch number network requests.

[0059] The pre-connection pool traverses the domain name and port information (such as the port list) and performs a pre-connection operation on each item: 3.1. Create an independent worker thread for each pre-connection task.

[0060] 3.2. Calculate the reasonable timeout for each stage, such as DNS resolution, TCP handshake, and TLS handshake, based on the network conditions and the total timeout set by the user.

[0061] 3.3. Return the differentiated timeout parameters for each stage.

[0062] 3.4. Create an SSLSocket and set parameters: initialize the SSL Socket object, configure parameters such as the TLS version, cipher suite, and timeout for each stage.

[0063] 3.5. Configure DNS resolution and TCP parameters, and perform a TCP connection and a TLS handshake.

[0064] 3.6. Store the SSLSocket object in the pre-connection pool and mark the connection status.

[0065] 4. The main processor assembles the request parameters: prepares the various parameters required for prefetching the number, including application authentication information, device information, network information, etc., and performs private network IP acquisition, data encryption, and signature calculation.

[0066] 5. The main processor sends a prefetch number request to the network processor.

[0067] 6. The network processor creates a retry controller and sets a callback function, which is used to actually initiate a network request.

[0068] 7. The retry controller triggers the callback function and passes in the URL for which the network request needs to be initiated currently.

[0069] The callback function receives the URL to initiate a network request and determines the returned HTTP result. When the returned HTTP result is 302, a recursive call will be made to initiate a network request to the redirected URL. The specific processing flow is shown in steps 8 - 11.

[0070] 8. The network processor obtains the domain name and port information from the URL parameters.

[0071] 9. The pre - connection pool returns an SSLSocket based on the domain name and port; When there is an available connection in the connection pool corresponding to the domain name and port information, directly reuse the existing connection and return the SSLSocket; When there is a connection in the connection pool corresponding to the domain name and port information and it is in the connected state (connect), wait for the connect to end and return the SSLSocket; When there is no available connection in the connection pool corresponding to the domain name and port information, create a new SSLSocket, perform the connect operation, and return the new SSLSocket 10. The network processor creates an HTTPS connection based on the SSLSocket and accesses the corresponding URL.

[0072] 11. The HTTPS connection returns the HTTP result. When the HTTP return result is 30, the callback function will make a recursive call to access the redirected URL.

[0073] 12. When the returned HTTP result is not 302, the callback function returns information such as the HTTP result, the depth of the recursive call, and the current URL to the retry controller.

[0074] 13. The retry controller determines whether to retry.

[0075] 14. When a retry is needed, different retry strategies are executed according to the failure type, carrying the updated URL, and the callback function is triggered again; Network exception: Check the network status, rebuild the connection pool, and update DNS resolution; Private network IP invalidation: Re - obtain the private network IP and update the request URL; Business error: Determine whether to retry according to the error type.

[0076] 15. When a retry is not needed, return the HTTP response result.

[0077] 16. Return the final HTTP response result 17. The main processor parses the HTTP response result and extracts the prefetch number result (access code and mobile phone number mask).

[0078] 18. After the processing is completed, release the connection resources that are no longer needed.

[0079] The retry process disclosed in another embodiment of the present application is described in detail below; the prefetch number request starts, a prefetch number request is sent, the result is checked. If successful, a successful result is returned. If failed, analyze the error type, determine whether it can be retried. If it is a non-retryable error, return a failed result. If it is retryable, check the number of retries. If the maximum number of retries is reached, return a failed result. If the maximum number of retries is not reached, check the network status. If the network is available, there is no need to recreate the network connection. If the network is unavailable, recreate the network connection. Then check whether the private network IP has changed. If the IP has not changed, reset the connection pool. If the IP has changed, reset the connection pool after reconstructing the URL parameters, prepare for retry, calculate the retry delay exponential backoff algorithm, wait for the delay time, resend the request, and return to the step of checking the result.

[0080] This application preferentially continues the request from the failure point: existing SDKs usually retry from the beginning after a request fails, while this application implements a "resume interrupted transfer" - style retry mechanism. The network controller extracts the redirected URL and the current call depth from the failure result. When retrying, it preferentially uses the obtained redirected URL and call depth information to directly continue the subsequent request from the failure point instead of restarting the entire process. Especially for multiple redirects during the prefetch number process, this mechanism avoids repeating the steps that have been successfully executed and significantly improves the retry efficiency. Only when it is detected that there is a fundamental change in the network environment (such as a change in the private network IP), the call depth will be reset and the retry will start from the beginning.

[0081] The advantages of the error type detection and classification processing of this application are: The intelligent retry strategy accurately analyzes the error type through methods and classifies the errors into multiple categories: network exceptions or network exception errors (DNS resolution failure, TCP connection timeout, TLS handshake failure), HTTP protocol errors (client errors, server errors), and business errors (invalid private network IP, authentication failure). The system takes different treatments for each type of error: automatically retry for network errors and some server errors, directly return for non-recoverable business errors, and retry after clearing the cache and reconstructing the request parameters for specific errors (such as invalid private network IP). This fine-grained error classification and processing mechanism avoids invalid retries and significantly improves the resource utilization efficiency and the final success rate.

[0082] The advantages of the network availability judgment and automatic reconstruction of this application are: The SDK implements a network availability detection mechanism that not only checks the network connection status but also evaluates the network quality. When the network is detected to be unavailable or of poor quality, the system attempts to create a new network connection, forcibly re-switch the cellular network to obtain a network object, and reset the connection pool to ensure the use of the latest network environment. This proactive network availability detection and switching mechanism significantly improves the request success rate in scenarios of weak network or network switching.

[0083] The advantages of the private network IP change detection and URL reconstruction in this application are as follows: During the prefetch number process, the private network IP is a key parameter. A change in the private network IP during the request process will cause the request to fail. The retry controller detects whether the private network IP has changed before each retry. Once a change is detected (such as a base station handover or a 5G to 4G handover), the request URL will be reconstructed, and the call depth counter will be reset to ensure starting from the beginning of the prefetch number process. This precise detection and handling of private network IP changes solve the problem of prefetch number failure in network switching scenarios.

[0084] The advantages of the exponential backoff algorithm in this application for controlling the retry interval are as follows: To avoid frequent retries exacerbating network congestion, the system uses an exponential backoff algorithm to dynamically calculate the retry interval. The delay time will increase exponentially with each retry (initial delay × 2^(number of retries - 1)), and at the same time, a maximum delay limit is set to avoid excessive waiting. This strategy of gradually increasing the retry interval can both quickly recover in short-term network fluctuations and avoid resource waste in persistent network problems.

[0085] The phased timeout control mechanism of this application effectively solves the shortcoming of the traditional SDK's single timeout setting in a weak network environment by finely dividing key stages such as DNS resolution (300ms), TCP handshake (900ms), TLS handshake (1200ms), and first packet response (1800ms) of a network request and assigning reasonable timeout thresholds for each stage. This phased control not only ensures that the overall timeout does not exceed the user-set value but also can dynamically adjust resource allocation according to the actual network requirements of each stage, avoiding the problem that subsequent links (such as data transmission and failure retry) do not have enough time due to a long time-consuming stage (such as DNS resolution). Especially in a weak network environment with large network fluctuations, reasonable time allocation significantly improves the success rate of each link, enabling the overall request to be completed as much as possible within a limited time window.

[0086] Default values and dynamic calculation rules for each stage:

[0087] It should be noted that the method of one or more embodiments of the present application can be executed by a single device, such as a computer or a server. The method of this embodiment can also be applied to a distributed scenario and completed by the cooperation of multiple devices. In this case of a distributed scenario, one of the multiple devices can only execute one or more steps of the method of one or more embodiments of the present application, and these multiple devices will interact with each other to complete the described method.

[0088] It should be noted that the above describes specific embodiments of the present application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in a different order than in the embodiments and still achieve the desired result. Additionally, the processes depicted in the figures do not necessarily require the specific order or sequential order shown to achieve the desired result. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0089] Based on the same inventive concept, corresponding to the method of any of the above embodiments, the present application also discloses an electronic device; Specifically, Figure 4 FIG. shows a schematic hardware structure diagram of an electronic device for an improved method of one-key login in a weak network of a mobile phone number. The device may include: a processor 410, a memory 420, an input / output interface 430, a communication interface 440, and a bus 450. Among them, the processor 410, the memory 420, the input / output interface 430, and the communication interface 440 are communicatively connected to each other inside the device through the bus 450.

[0090] The processor 410 can be implemented in a general-purpose CPU (Central Processing Unit), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits, etc., and is used to execute relevant programs to implement the technical solutions provided by the embodiments of the present application.

[0091] The memory 420 can be implemented in the form of a ROM (Read Only Memory), a RAM (Random Access Memory), a static storage device, a dynamic storage device, etc. The memory 420 can store an operating system and other application programs. When implementing the technical solutions provided by the embodiments of the present application through software or firmware, the relevant program codes are stored in the memory 420 and called by the processor 410 for execution.

[0092] The input / output interface 430 is used to connect to the input / output module to enable information input and output. The input / output module can be configured as a component in the device (not shown in the figure) or externally connected to the device to provide corresponding functions. Among them, the input devices can include keyboards, mice, touchscreens, microphones, various sensors, etc., and the output devices can include displays, speakers, vibrators, indicator lights, etc.

[0093] The communication interface 440 is used to connect to the communication module (not shown in the figure) to enable communication and interaction between this device and other devices. Among them, the communication module can achieve communication through wired means (such as USB, network cable, etc.) or through wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0094] The bus 450 includes a path for transmitting information between various components of the device (such as the processor 410, the memory 420, the input / output interface 430, and the communication interface 440).

[0095] It should be noted that although the above device only shows the processor 410, the memory 420, the input / output interface 430, the communication interface 440, and the bus 450, in the specific implementation process, the device may also include other components necessary for normal operation. In addition, those skilled in the art can understand that the above device may also only include the components necessary to implement the solution of the embodiments of the present application, and does not necessarily include all the components shown in the figure.

[0096] The electronic device of the above embodiment is used to implement the improved method for one-key login of a mobile phone number in a weak network in any of the foregoing embodiments, and has the beneficial effects of the corresponding method embodiments, which will not be elaborated here.

[0097] Based on the same inventive concept, corresponding to the method in any of the above embodiments, one or more embodiments of the present application also provide a computer-readable storage medium, and the computer-readable storage medium stores computer instructions, and the computer instructions are used to cause the computer to execute the improved method for one-key login of a mobile phone number in a weak network as described in any of the foregoing embodiments.

[0098] The computer-readable medium of this embodiment includes permanent and non-permanent, removable and non-removable media, and information storage can be implemented by any method or technology. The information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassette tapes, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device.

[0099] The computer instructions stored in the storage medium of the above embodiment are used to cause the computer to execute the improved method for one-key login in a weak network of a mobile phone number as described in any one of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be elaborated here.

[0100] Those of ordinary skill in the art should understand that: the discussion of any of the above embodiments is only exemplary, and is not intended to imply that the scope of the present application (including the claims) is limited to these examples; under the concept of the present application, the technical features in the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations in different aspects of one or more embodiments of the present application as described above, which are not provided in detail for the sake of brevity.

[0101] In addition, for the sake of simplicity of description and discussion, and in order not to make one or more embodiments of the present application difficult to understand, the well-known power / ground connections to integrated circuit (IC) chips and other components may or may not be shown in the provided drawings. In addition, the device may be shown in block diagram form to avoid making one or more embodiments of the present application difficult to understand, and this also takes into account the fact that the details of the implementation of these block diagram devices are highly dependent on the platform on which one or more embodiments of the present application will be implemented (i.e., these details should be fully within the understanding of those skilled in the art). In the case where specific details (such as circuits) are set forth to describe the exemplary embodiments of the present application, it will be apparent to those skilled in the art that one or more embodiments of the present application can be implemented without these specific details or with variations of these specific details. Therefore, these descriptions should be considered illustrative rather than restrictive.

[0102] Although the present application has been described in connection with specific embodiments thereof, many alternatives, modifications, and variations of these embodiments will be apparent to those of ordinary skill in the art in light of the foregoing description. For example, other memory architectures (e.g., dynamic RAM (DRAM)) may be used with the embodiments discussed.

[0103] One or more embodiments of the present application are intended to cover all such alternatives, modifications, and variations that fall within the broad scope of the appended claims. Accordingly, any omissions, modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of one or more embodiments of the present application shall be included within the scope of protection of the present application.

Claims

1. An improved method for one-key login of mobile phone numbers in weak network, characterized in that, The method includes: The main processor creates a pre-connection pool, which records the list of pre-connected domain names and ports, and performs pre-connection operations. The main processor intelligently maintains the list of pre-connected domain names and ports based on the previous request records of the current device, and preposes DNS resolution and TCP connection creation to execute concurrently with the steps of preparing various parameters required for the main processor to pre-fetch numbers; The main processor prepares various parameters required for pre-fetching numbers, performs private network IP acquisition, data encryption, and signature calculation, and sends a pre-fetch number request to the network processor. The various parameters required for pre-fetching numbers include application authentication information, device information, and network information; After receiving the pre-fetch number request, the network processor creates a retry controller and sets a callback function. The callback function is used to actually initiate a network request. The retry controller triggers the callback function and passes in the URL that needs to initiate a network request currently; The callback function receives the URL and initiates a network request, and receives the returned HTTP result. When the returned HTTP result is 302, a recursive call is executed to initiate a network request to the redirected URL. When the returned HTTP result is not 302, the callback function returns the returned HTTP result, the depth of recursive call, and the current URL to the retry controller; The retry controller returns the HTTP response result to the main processor; The main processor receives and parses the HTTP response result, and extracts the pre-fetch number result. The pre-fetch number result includes an access code and a mobile phone number mask.

2. The improved method for one-key login of mobile phone numbers in weak network according to claim 1, characterized in that, The execution of the pre-connection operation includes: Create an independent working thread for each pre-connection task; Calculate the reasonable timeout times for DNS resolution, TCP handshake, and TLS handshake according to the network status and the total timeout time set by the user; Return the differentiated timeout parameters for each stage; Create an SSLSocket and set parameters; Configure DNS resolution and TCP parameters, and perform TCP connection and TLS handshake; Store the SSLSocket object in the pre-connection pool and mark the connection status.

3. The improved method for one-key login of mobile phone numbers in a weak network according to claim 1 or 2, characterized in that The initiation of a network request to the redirected URL includes: The network processor obtains domain name and port information from the URL parameters; The pre-connection pool returns an SSLSocket according to the domain name and the port information; The network processor creates an HTTPS connection based on the SSLSocket and accesses the corresponding URL; The HTTPS connection returns the target HTTP result. When the target HTTP result is 302, the callback function will make a recursive call to access the redirected URL.

4. The improved method for one-key login of mobile phone numbers in weak network according to claim 3, characterized in that, The pre-connection pool returns an SSLSocket according to the domain name and the port information, including: When there is an available connection in the connection pool corresponding to the domain name and port information, directly reuse the existing connection and return the SSLSocket; When there is a connection in the connection pool corresponding to the domain name and port information and the connection is in progress, wait for the connection state to end and return the SSLSocket; When there is no available connection in the connection pool corresponding to the domain name and port information, create a new SSLSocket to perform the connection operation and then return the new SSLSocket.

5. The improved method for one-key login of mobile phone numbers in weak network according to claim 1, characterized in that, The method further includes: Setting a phased timeout mechanism, setting reasonable and differentiated timeout times according to each stage of the network request, and dynamically adjusting the reasonable timeout times of each stage according to the total prefetch number timeout value.

6. The improved method for one-key login of mobile phone numbers in weak network according to claim 1, characterized in that, Before the retry controller returns the HTTP response result to the main processor, it further includes: The retry controller determines whether a retry is needed; When a retry is needed, the retry controller extracts the redirect URL and the current call depth from the failure result, preferentially uses the obtained redirect URL and call depth information, and directly continues to execute the subsequent request from the failure point, where the subsequent request includes: executing different retry policies according to the failure type and network status, carrying the updated URL, and re-triggering the callback function; When a retry is not needed, obtain the HTTP response result.

7. The improved method for one-key login of mobile phone numbers in a weak network according to claim 6, characterized in that, The execution of different retry policies according to the failure type includes: If the failure type is a network exception, check the network availability and evaluate the network quality. When the network is unavailable or of poor quality, recreate the cellular network object, reset the pre-connection pool, and trigger the pre-connection operation for the recreated pre-connection pool; If the failure type is a private network IP failure, re-obtain the private network IP and update the request URL; If the failure type is a business error, decide whether to retry according to the error type.

8. The improved method for one-key login of mobile phone numbers in a weak network according to claim 5, characterized in that, Each stage includes: the DNS resolution stage, the TCP handshake stage, and the TLS handshake stage. The reasonable timeout time for the DNS resolution stage is 300 ms, the reasonable timeout time for the TCP handshake stage is 900 ms, and the reasonable timeout time for the TLS handshake stage is 1200 ms.

9. An electronic device, the electronic device comprising: A memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor implements the method according to any one of claims 1 to 8 when executing the computer program.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores one or more programs, and the one or more programs can be executed by one or more processors to implement the method according to any one of claims 1 to 8.

Images