Pre-request optimization method for embedded H5 page of mobile terminal application program and storage medium

Abstract

The invention discloses a pre-request optimization method for an embedded H5 page of a mobile terminal application program and a storage medium. The invention relates to the technical field of computer networks. And carrying out system environment detection, and determining whether a network state, equipment resources, a storage space and the like meet preloading conditions or not. If yes, a preloading strategy configuration file is loaded, and the file comprises the preloading resource list, the priority, the cache rule and the timeout time. And constructing a preloading task queue according to the configuration strategy. In the task queue, the resources with high priorities are loaded preferentially. According to the method, key resources are loaded in advance, so that the waiting time of a user is shortened, and particularly, the first screen content is quickly displayed, so that the application feels smoother and responds immediately. Even under the condition that the network is unstable, instant availability of the basic content can be guaranteed by means of the local cache, and the bad experience of white screen or long-time loading is avoided.

Description

Technical Field

[0001] The present invention relates to the technical field of computer network and data communication technology, and specifically to a pre-request optimization method and storage medium for an H5 page embedded in a mobile application. Background Art

[0002] In today's rapidly changing mobile Internet technology, HTML5 (H5) technology has become an indispensable core technology for the development of embedded web pages in mobile applications with its remarkable cross-platform compatibility and rich multimedia integration capabilities. The widespread adoption of H5 has not only promoted the development concept of "write once, run everywhere", but also greatly enriched the interface expressiveness and functionality of mobile applications, meeting users' needs for high-quality interactive experience. However, this technology application is also accompanied by several challenges, the most prominent of which is the direct impact of web page loading speed on user experience.

[0003] Especially in the current situation where the mobile network environment is complex and changeable, and users' expectations for instant feedback continue to rise, the optimization of H5 page loading speed has become one of the key indicators to measure the success of an application. Studies have shown that even if the page loading time increases by only a few seconds, it may lead to a significant drop in user satisfaction and a significant increase in user churn. Although the current strategies such as resource file compression, efficient caching mechanism and on-demand loading have alleviated the loading speed problem to a certain extent, these measures are not effective enough when faced with poor network conditions or huge data transmission volume, and it is difficult to fundamentally solve the problem of impaired user experience.

[0004] In view of this, academia and industry are actively exploring and developing more advanced technical solutions, aiming to optimize the resource request process of H5 pages from the source, that is, to predictively schedule and optimize page resources through intelligent preloading and preprocessing technology before the user initiates the actual request.

[0005] To this end, the present invention proposes a pre-request optimization method and storage medium for H5 pages embedded in mobile terminal applications. Summary of the invention

[0006] In view of this, the present invention hopes to provide a pre-request optimization method and storage medium for H5 pages embedded in mobile applications to solve or alleviate the technical problems existing in the prior art, namely, how to directly pre-send requests and cache in Native while opening Webview, and eliminate the cache when the request time exceeds the threshold. At the same time, for the case of request failure, the failure reason can be recorded and fed back to the monitoring system to optimize the subsequent request strategy. The technical solution of the present invention is implemented as follows:

[0007] 1. Overview:

[0008] The present invention aims to solve the above technical problems. To optimize the loading speed of H5 pages embedded in mobile applications. When the application is started, the Native preloading logic is triggered. The system environment is detected first, and then the background preloading task queue is built and executed according to the configuration strategy, the resource request sequence is arranged, and the concurrency is controlled to prevent network congestion. The acquired resources are stored in the local cache according to the strategy, and the timeliness is checked in real time to ensure that the data can be quickly extracted when the Webview is loaded, or a real-time request is initiated when necessary.

[0009] Performance monitoring runs through the entire process, recording the request status and time consumption in detail, providing a data basis for analysis and optimization. Based on log analysis, the preloading strategy is dynamically adjusted, and the cache rules and network request paths are optimized, including adjusting the loading timing, adopting dynamic cache elimination strategies, resource compression and merging, etc., supplemented by a fallback mechanism to ensure user experience. Through continuous iteration and optimization, this solution has significantly accelerated the loading of H5 pages on mobile terminals.

[0010] (II) Technical solution:

[0011] 2.1 Step S1, initialization:

[0012] When the application is started, the Native preloading logic is activated and background pre-requests for resources are started according to the configuration policy.

[0013] 2.1.1 Step S100, system starts detection:

[0014] Perform system environment detection to confirm whether the network status, device resources, storage space, etc. meet the preloading conditions. If so, load the preloading policy configuration file, which contains the preloading resource list, priority, cache rules, and timeout.

[0015] 2.1.2 Step S101, task queue construction:

[0016] Construct a preload task queue based on the configuration strategy. In the task queue, resources with high priority are loaded first.

[0017] 2.1.3 Step S102, background thread starts:

[0018] Activate the Native preloading logic in the background thread or dedicated preloading service to avoid blocking the main thread and ensure that the application startup is not affected. At the same time, implement concurrent request control to avoid network congestion or server pressure caused by too much concurrency.

[0019] 2.1.4 Step S103, pre-request execution:

[0020] The Native layer starts sending HTTP / HTTPS requests to the server in the order of the task queue to obtain the specified static resources (including images, CSS and / or JS files) and dynamic data (data returned by the API).

[0021] 2.2 Step S2, data processing:

[0022] When the Native layer obtains the static resources and dynamic data required by the H5 page, it stores them in the local cache according to the policy and marks the expiration date. It checks the timeliness of the cached resources and decides whether to use or re-request them.

[0023] When Webview is loaded, data is extracted from the cache to achieve fast page rendering. If the cache is invalid or there is no cache, data is requested and displayed in real time.

[0024] 2.2.1 Step S200, resource cache strategy execution:

[0025] Before using cached data, check its timeliness. For expired resources, mark them as invalid and plan to re-request them; for valid resources, prepare them for page rendering. For successfully obtained static resources and dynamic data, use the SQLite database to store them locally according to the preset cache strategy, and record the resource's validity period or last update time.

[0026] 2.2.2 Step S201, resource scheduling and priority:

[0027] According to the actual loading requirements of Webview, the resources in the cache are scheduled, and resources important for first-screen rendering are provided first to ensure that they are presented to users quickly.

[0028] 2.2.3 Step S202, Webview interacts with cache:

[0029] When Webview starts loading a page, it communicates with the Native layer through the JavaScript bridge (JavaScriptInterface) to request the required resources. The Native layer extracts data from the cache based on the request and passes it to Webview through the interface.

[0030] 2.2.4 Step S203, execute real-time request and fallback mechanism:

[0031] If the required resource is found to be missing from the cache or has expired, a real-time network request is triggered to obtain the latest data, while using placeholders to keep the user interface responsive.

[0032] 2.2.5 Step S204, data synchronization and update:

[0033] By comparing the timestamp or other identifiers of the cached data with the server data, real-time synchronization and update of the data can be achieved.

[0034] 2.3 Step S3, performance monitoring and log collection:

[0035] Keep track of pre-request duration, success rate, cache hit rate, and page load time.

[0036] Capture network request failures, timeouts, and cache exceptions, and record detailed logs including error codes, timestamps, and request details.

[0037] 2.3.1 Step S300, performance indicator definition and collection:

[0038] Integrated performance monitoring tools to record key performance indicators (KPIs), including pre-request time, request success rate, cache hit rate, page first rendering time (Time to First Byte, TTFB) and full load time.

[0039] 2.3.2 Step S301, real-time data tracking:

[0040] Track the life cycle of each network request in real time, from the initiation of the request to the receipt of the response, and record key time points, including sending time, receiving time, and processing time.

[0041] 2.4 Step S4, analysis and optimization:

[0042] Based on the detailed logs of S3, when a network request fails (such as an HTTP error status code), times out, or a cache read or write exception occurs, the exception handling process is triggered. The exception handling process is triggered by adjusting the preloading policy based on the cache elimination rules to optimize the network request path and cache mechanism.

[0043] 2.4.1 Step S400, preloading strategy adjustment:

[0044] For requests that frequently fail or time out, adjust the preloading timing or order to optimize the management of the network request queue and avoid network congestion caused by too many concurrent requests.

[0045] 2.4.2 Step S401, cache elimination rule optimization:

[0046] According to the cache hit rate and the preset threshold, the cache elimination strategy is activated and adjusted. The cache elimination strategy is to dynamically switch between the LRU strategy (Least Recently Used) and the LFU strategy (Least Frequently Used) to ensure that high-frequency access resources are retained in the cache for a longer period of time.

[0047] 2.4.3 Step S402, resource compression and merging:

[0048] Set thresholds to determine whether certain resources are frequently loaded; for frequently preloaded resources, compress them to reduce their size or merge multiple small files into one large file to reduce the number of requests.

[0049] 2.4.4 Step S403, execute the fallback mechanism:

[0050] Implement fallback strategies when network requests fail, including using degraded resources, local cache, or providing default data, to ensure that the user experience is not severely affected.

[0051] (III) Mechanism for solving technical problems:

[0052] When the application starts, the system first performs initialization settings and loads the preloading policy configuration. These policies define which resources need to be preloaded, their priorities, caching rules, and timeout thresholds.

[0053] The Native layer starts background preloading operations according to the strategy, builds a task queue, and schedules them according to the priority of the resources. At this time, Native directly sends a request to the server through the HTTP / HTTPS protocol to obtain static resources (such as pictures, CSS, JS) and dynamic data (API return data) of the H5 page. This process is performed in the background thread to avoid affecting the startup speed of the application. The obtained resources are stored in the local cache according to the strategy, and their validity period is recorded. Before Webview actually loads resources, the system will check the timeliness of the resources in the cache to ensure that the latest or valid data is used. For expired resources, the system marks them as invalid and plans to re-request them.

[0054] If the preloading request for a resource takes longer than a preset threshold (such as 150 milliseconds), the system will not wait for the request to complete, but will directly switch to using the existing cached data (if it exists) or initiate a new request to obtain the data in real time. This means that for requests with slow responses, the system will quickly switch to alternative solutions to avoid users waiting too long. For dynamic data, the system will compare the timestamp or version information of the cached data with the server data each time it is loaded to ensure that the user obtains the latest data and achieve real-time data synchronization.

[0055] (IV) Compared with the prior art, the beneficial effects of the present invention are:

[0056] (1) Improve user experience: The present invention reduces user waiting time by loading key resources in advance, especially for the rapid display of the first screen content, making the application feel smoother and more responsive. Even in the case of unstable network, the local cache can be relied on to ensure the immediate availability of basic content, avoiding the undesirable experience of white screen or long loading time.

[0057] (2) Reduce network data consumption: The present invention utilizes a cache mechanism so that resources that are repeatedly accessed do not need to be downloaded from the server each time, which reduces the data traffic consumption of mobile devices, a significant advantage for users with limited data packages. By dynamically adjusting cache elimination rules, local storage space is efficiently managed, useless resource occupation is avoided, and efficient turnover of cache space and rapid availability of the latest content are ensured.

[0058] (3) Promoting data real-time and consistency: The real-time data synchronization and update mechanism of the present invention ensures that the information obtained by the user is the latest, especially when processing dynamic content, improving the accuracy and timeliness of the information. BRIEF DESCRIPTION OF THE DRAWINGS

[0059] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or technical descriptions will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0060] Figure 1 A logical schematic diagram of the method of the present invention;

[0061] Figure 2 The present invention is a schematic diagram of the method execution flow. DETAILED DESCRIPTION

[0062] In order to make the above-mentioned purposes, features and advantages of the present invention more obvious and easy to understand, the specific implementation methods of the present invention are described in detail below in conjunction with the accompanying drawings. In the following description, many specific details are set forth to facilitate a full understanding of the present invention. However, the present invention can be implemented in many other ways different from those described herein, and those skilled in the art can make similar improvements without violating the connotation of the present invention. Therefore, the present invention is not limited to the specific embodiments disclosed below;

[0063] It should be noted that the various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments, and the same or similar parts between the various embodiments can be referred to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part description.

[0064] Example: Figures 1-2 As shown, this embodiment discloses a pre-request optimization method for H5 pages embedded in a mobile terminal application. In actual application, the following steps S1 to S4 need to be performed.

[0065] In this embodiment, regarding step S1, initialization: when the application is started, the Native preloading logic is activated, and the background pre-request of resources begins according to the configuration policy.

[0066] Specifically, step S100, system startup detection: When the application starts, a series of system environment checks are first performed. This includes checking the type of current network connection (Wi-Fi, 4G / 5G) and connection quality through the network status API, evaluating the available memory and storage space of the device, and checking whether there are enough resources to support the preloading operation. Through these tests, the system can determine whether the current environment is suitable for starting the preloading logic.

[0067] For example, when the network condition is poor or the device resources are limited, it is chosen not to execute or to limit the scale of preloading to avoid a negative impact on the user experience.

[0068] The detection mechanism at this stage helps ensure that preloading activities are performed without affecting the application startup speed and system stability, and avoids forced preloading in a resource-constrained environment, which may cause application freezes or crashes.

[0069] Specifically, step S101, task queue construction: based on the preloading policy configuration file, the application constructs a priority-sorted task queue. The policy file is defined by the developer and includes information such as which resources need to be preloaded, priority sorting, caching rules (such as expiration time) and timeout time.

[0070] By building a task queue, the system can process preload requests in an orderly manner and prioritize loading resources that have the greatest impact on the user experience (such as resources related to the first screen content). This ensures that limited system resources are used most efficiently. Prioritization helps quickly load the content that users are most likely to see, significantly improves the first screen loading speed, and gives users an instant response experience, thereby increasing user satisfaction and retention.

[0071] Specifically, step S102, background thread start: execute Native preloading logic in the background thread or a service dedicated to preloading to avoid competing for resources with the UI main thread and ensure smooth application startup. Multithreading technology can be used to separate time-consuming network requests and resource loading operations to prevent them from affecting UI updates and other immediate response operations, ensuring the responsiveness and startup speed of the application. By executing preloading through the background thread, the application can load resources and display the interface at the same time, avoiding the waiting time felt by the user and improving the overall user experience.

[0072] Specifically, step S103, pre-request execution: the Native layer initiates HTTP / HTTPS requests to the server in the order in the task queue, and the requests include static resources (images, CSS, JS) and dynamic data (API requests). By using Native code to interact directly with the network, the request process can be controlled more flexibly, including concurrency control, error handling, etc. By obtaining these resources in advance, when the user actually visits the H5 page, most of the data is ready and can be used directly or rendered quickly.

[0073] Understandably, this step directly contributes to the improvement of page loading speed, especially when the user is already connected to the network but not actively browsing the page. Preloading can save users valuable loading time, thereby enhancing the attractiveness and convenience of the application.

[0074] Furthermore, the Java program of step S1 (using the Kotlin coroutine of the Android platform) is as follows:

[0075]

[0076]

[0077]

[0078] In the above program, a background coroutine is started through GlobalScope.launch, and withContext(Dispatchers.IO) is used to ensure that the network request is executed in the background thread to avoid blocking the UI thread. Check the network and storage space before preloading to ensure that the preloading is performed in a suitable environment. Build a priority task queue according to the policy configuration, and load high-priority resources first. Traverse the task queue, initiate an HTTP request for each resource, and store the data in the cache after obtaining it. Use exception handling to ensure that the failure of a single request does not affect the execution of other requests. Use the CacheManager class to implement local caching of resources, considering factors such as priority and expiration time to improve resource reuse rate

[0079] In this embodiment, regarding step S2, data processing: after the Native layer obtains the static resources and dynamic data required by the H5 page, it stores them in the local cache according to the policy and marks the validity period. Check the timeliness of the cached resources and decide whether to use or re-request.

[0080] When Webview is loaded, data is extracted from the cache to achieve fast page rendering. If the cache is invalid or there is no cache, data is requested and displayed in real time.

[0081] Specifically, step S200, resource cache strategy execution: At the Native layer, after obtaining a resource, first check whether it already exists in the local cache, by comparing the storage time of the resource with the current time, and checking the expiration tag or last update time of the resource to verify its timeliness. Expired resources will be marked as invalid and planned to be re-requested in the background.

[0082] In this way, we ensure that the latest content is always displayed to users, avoiding user experience problems caused by using outdated data. This strategy effectively reduces dependence on external networks and speeds up page loading, especially when network conditions are poor. At the same time, by intelligently judging the validity of resources, we ensure the accuracy and reliability of data.

[0083] Specifically, step S201: resource scheduling and priority: when the Webview is loaded, the resources in the cache are dynamically scheduled according to the actual needs of page rendering. Resources with high priority, such as images and key scripts required for first screen rendering, will be provided to the Webview first.

[0084] Priority scheduling ensures that the content that users perceive most directly can be loaded as quickly as possible, improving the first screen loading speed and user satisfaction. In addition, by prioritizing the loading of resources that directly affect the user experience, users can see the main content of the page faster, reducing the frustration caused by waiting for the page to load completely, and improving the overall experience.

[0085] Specifically, step S202: Webview interacts with the cache: Webview can communicate with the Native layer using Android's JavaScriptInterface. When Webview requests a resource, the Native layer retrieves data from the cache through this interface and passes the data back to Webview through JavaScript callback. This interaction mechanism breaks down the barriers between native and Web technologies, allowing more efficient use of local resources and reducing the overhead of JavaScript directly initiating network requests. This improves the efficiency and security of data transmission, while simplifying the complexity of Webview's interaction with local data, and improving page loading speed and application performance.

[0086] Specifically, step S203: execute real-time request and fallback mechanism: when it is found that the cache is missing or the resource has expired, immediately initiate a real-time network request in the background, and a placeholder or loading indicator may be displayed on the front end to maintain the responsiveness of the user interface.

[0087] By instantly requesting the latest data and combining it with visual feedback on the front end, the freshness of the data is guaranteed while preventing users from being confused by unresponsive pages. This mechanism ensures that even in the case of cache failure, data availability can be quickly restored while maintaining a good user experience.

[0088] Specifically, step S204: data synchronization and update: when new data is obtained from the server, by comparing the timestamp or version number of the resource, decide whether the data in the local cache needs to be updated. If necessary, update the cache and record the new timestamp. Real-time monitoring and synchronization of data changes ensures the consistency of local cache and server data.

[0089] This strategy ensures that users can obtain the latest information, reduces potential problems caused by inconsistent data, and optimizes the use of network resources by reducing unnecessary repeated requests.

[0090] Furthermore, the Java program of step S2 (using the Kotlin coroutine of the Android platform, as well as the WebView component and the SQLite database as local cache storage) is as follows:

[0091]

[0092]

[0093]

[0094]

[0095]

[0096]

[0097] In the above program, the cache manager (CacheManager) uses the SQLite database to store resources and provides methods for saving and retrieving data and checking whether the cache is expired. Webview and Native communicate through MyJavaScriptInterface as a bridge, allowing JavaScript to call Android native code to implement resource requests and data transfer.

[0098] The asynchronous task in MyJavaScriptInterface first tries to get the resource from the cache. If the cache is invalid or does not exist, it triggers a real-time network request.

[0099] In this embodiment, regarding step S3, performance monitoring and log collection: continuously track the time consumption, success rate, cache hit rate and page load time of pre-requests. Capture network request failures, timeouts and cache anomalies, and record detailed logs, including error codes, timestamps and request details.

[0100] Specifically, step S300, performance indicator definition and collection: select a performance monitoring system (such as FirebasePerformance Monitoring, New Relic), and clearly monitor which performance indicators, including but not limited to pre-request time, request success rate, cache hit rate, page first rendering time (TTFB) and full load time. These indicators are directly related to the user experience. Set a monitoring point between the Native layer and Webview to automatically record the start time, end time and request result of each preload request, including whether data is read from the cache.

[0101] By monitoring these key performance indicators in real time, you can intuitively evaluate the effectiveness of the preloading strategy and identify performance bottlenecks, such as network latency, slow server response, or poor resource loading. Defining KPIs and automatically collecting data provides an objective basis for subsequent analysis. Clear performance indicators help the team quickly locate problems. For example, if the cache hit rate is low, it may indicate that the cache strategy needs to be optimized; if the TTFB is long, the server response time may need to be optimized. Decisions based on quantitative data are more scientific and can accurately identify which optimization measures are most effective in improving user experience.

[0102] Specifically, step S301, real-time data tracking: using the interceptor function of the network library (such as OkHttp) or a custom network layer, start recording the timestamp from the time the request is initiated until the moment the response data is received, including the data processing time. Record the sending time, response receiving time, and data processing completion time of each request. These time points are very critical for analyzing the request time. When the request fails, times out, or the cache read and write is abnormal, in addition to recording the timestamp, detailed information such as the error code, request URL, and request parameters must also be captured and recorded.

[0103] It is understandable that real-time tracking of the life cycle of each request can not only evaluate the efficiency of the request, but also provide sufficient context information when problems occur, so as to facilitate rapid location and resolution of the problem. Detailed records of abnormal situations are essential for understanding the root causes and patterns of errors.

[0104] Moreover, through real-time data tracking, once users report a problem, the development team can quickly find detailed information about the corresponding request from the log, shortening the time to locate the fault. Recording of abnormal situations helps analyze the reasons for request failures, such as network instability, server problems, or client logic errors, and provides data support for optimizing request strategies. Through continuous monitoring and rapid response, timely adjustment of optimization measures can reduce user churn caused by performance issues and improve the overall application experience.

[0105] Furthermore, the Java program of step S3 (using the Kotlin coroutine of the Android platform, using OkHttp as the network request library, and combining Timber as the logging tool) is as follows:

[0106] (1) Customize OkHttp Interceptor (network interceptor) to monitor the life cycle of requests and record key performance indicators and exception information:

[0107]

[0108]

[0109] (2) Configure the OkHttp client and integrate the Interceptor:

[0110]

[0111]

[0112] (4) When preloading H5 page resources or making any network requests, use OkHttpClient configured with Interceptor:

[0113]

[0114] In the above program, the custom PerformanceMonitoringInterceptor is used to record the timestamp when the request is issued and the response is received, calculate the request duration, and record whether the request is successful or not, so as to monitor the pre-request duration and request success rate. In the Interceptor, not only the success and failure of the request are recorded, but also the specific error code of the failure, as well as the time when the request is started and the response is received, providing a complete view of the request life cycle. Using the Timber log library, different levels of logs (INFO, ERROR) are output according to the status of the request, which makes it easier for developers to quickly identify problems and performance bottlenecks through logs.

[0115] In this embodiment, regarding step S4, analysis and optimization: Based on the detailed log of S3, when a network request fails (such as an HTTP error status code), times out, or a cache read / write exception occurs, the exception handling process is triggered. The triggering of the exception handling process is to adjust the preloading policy based on the cache elimination rule to optimize the network request path and cache mechanism.

[0116] Specifically, step S400, preloading strategy adjustment: regularly analyze logs to identify request patterns that frequently fail or time out, including requests for specific time periods, network environments, or specific resource types. Based on the analysis results, dynamically adjust the preloading strategy, such as postponing the preloading time of certain requests, or adjusting the priority order of requests to ensure that key resources are loaded first.

[0117] By analyzing failed and timed-out requests, understanding the volatility of the network environment and the rules of resource requests, dynamically adjusting strategies to adapt to different scenarios, reducing the possibility of request failures, and optimizing the order and timing of resource loading to ensure overall efficiency. Reduce request failure rates and timeouts, increase the success rate of resource loading, and optimize request queue management to avoid network congestion, ensure smooth application operation, and improve user experience.

[0118] Specifically, step S401, cache elimination rule optimization: continuously monitor cache hit rate, record resource access frequency and last access time. According to the evaluation results, dynamically switch between LRU (Least Recently Used) and LFU (Least Frequently Used) strategies; improve cache hit rate, reduce the number of requests to the server, reduce network resource consumption, speed up page loading speed, and improve user experience.

[0119] For example, for resources that are frequently accessed but not recently accessed, the LFU strategy is adopted, while for resources that are recently accessed but less frequently, the LRU strategy is more suitable. Automatic adjustment rules are set, and when the cache hit rate is lower than a preset threshold, strategy evaluation and switching are automatically triggered.

[0120] Specifically, step S402, resource compression and merging: setting a threshold to determine whether certain resources are frequently loaded; for frequently preloaded resources, compressing to reduce the size or merging multiple small files into one large file to reduce the number of requests.

[0121] Specifically, step S403 executes the fallback mechanism: when the request fails, the fallback strategy is triggered immediately, such as checking whether there is a cached copy available locally. Provide low-resolution images or simplified CSS / JS as alternatives. If the dynamic data request fails, display the default or last successfully requested data to ensure the integrity of the interface information.

[0122] When the latest or complete data cannot be obtained, an alternative solution is provided to ensure the continuity of the user experience and avoid the entire page being unable to display normally due to a single request failure. Even in the case of unstable network or request failure, the basic functions of the application can be guaranteed to be available, which improves the robustness of the application and the continuity of the user experience.

[0123] Furthermore, the Java program of step S4 (using the Kotlin coroutine of the Android platform) is as follows:

[0124] (1) Exception handling and fallback mechanism, implemented in OkHttp's Callback:

[0125]

[0126] (2) Dynamic adjustment of preloading strategy based on log analysis results:

[0127]

[0128] (3) Customize cache elimination rules by implementing the Cache interface, using the LRU strategy:

[0129]

[0130]

[0131] All the above embodiments only express the implementation methods of the relevant practical applications of the present invention, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the invention patent. It should be pointed out that, for ordinary technicians in this field, several variations and improvements can be made without departing from the concept of the present invention, which all belong to the protection scope of the present invention. Therefore, the protection scope of the patent of the present invention shall be based on the attached claims.

[0132] For those skilled in the art, it can be further appreciated that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in the above description according to function. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention.

[0133] At the same time, those skilled in the art can understand that all or part of the processes in all the above-mentioned embodiments can be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media provided in this application and used in the embodiments can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double-speed data rate SDRAM (SSRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

Claims

1. A pre-request optimization method for an H5 page embedded in a mobile application, characterized in that: include: S1, initialization: When the application is started, the Native preloading logic is activated and background pre-requests for resources are started according to the configuration policy; S2, data processing: When the Native layer obtains the static resources and dynamic data required by the H5 page, it stores them in the local cache according to the policy and marks the expiration date; when the Webview is loaded, it extracts data from the cache; S3, performance monitoring and log collection: capture network request failures, timeouts, and cache anomalies, and record detailed logs; S4, analysis and optimization: dynamically triggering the exception handling process based on the detailed log of S3; The exception handling process is triggered by adjusting the preloading policy based on the cache elimination rules to optimize the network request path and cache mechanism.

2. The pre-request optimization method according to claim 1, characterized in that: The execution steps of S1 include: S100, system startup detection: load the preloading policy configuration file, including the preloading resource list, priority, cache rules and timeout period; S101, task queue construction: construct a preload task queue according to the configuration strategy. In the task queue, resources with high priority are loaded first; S102, background thread start: activating the Native preloading logic in the background thread or the dedicated preloading service to implement concurrent request control; S103, pre-request execution: the Native layer sends an HTTP / HTTPS request to the server in the order of the task queue to obtain the specified static resources and dynamic data.

3. The pre-request optimization method according to claim 1, characterized in that: In S2, the implementation method of the strategy is: before using the cached data, check its timeliness; For expired resources, mark them as invalid and plan to re-request them; for valid resources, prepare them for page rendering; for successfully obtained static resources and dynamic data, use the SQLite database to store them locally and record the validity period of the resources.

4. The pre-request optimization method according to claim 3, characterized in that: In S2, the steps of loading and caching are respectively: S201, scheduling the resources in the cache, giving priority to providing resources important for first screen rendering; S202, when Webview starts to load the page, it communicates with the Native layer through JavaScript bridge and requests the required resources; the Native layer extracts data from the cache according to the request and passes it to Webview.

5. The pre-request optimization method according to claim 3, characterized in that: The cache in S2 further includes: S203, if it is found that the required resource is missing or expired in the cache, trigger a real-time network request to obtain the latest data; S204, achieving real-time synchronous update of data by comparing the timestamps of cached data.

6. The pre-request optimization method according to claim 1, characterized in that: The implementation method of S3 is: S300, an integrated performance monitoring tool, records key performance indicators, including pre-request time, request success rate, cache hit rate, page first rendering time and full load time; S301, the entire process from initiating a request to receiving a response, recording the sending time, receiving time and processing time.

7. The pre-request optimization method according to claim 1, characterized in that: In S4, the method for adjusting the preloading strategy is: adjusting the preloading timing or sequence for failed or timed-out requests to optimize the management of the network request queue.

8. The pre-request optimization method according to claim 7, characterized in that: In S4, the cache elimination rule method is: dynamically switching between the LRU strategy and the LFU strategy.

9. The pre-request optimization method according to claim 7, characterized in that: In said S4, it also includes: S402, setting a threshold to determine whether certain resources are frequently loaded; for resources that are frequently preloaded, compressing them to reduce their size or merging multiple small files into one large file; S403 executes a fallback strategy when a network request fails, including using degraded resources, local cache, or providing default data.

10. A storage medium, characterized in that: The storage medium stores program instructions capable of implementing the pre-request optimization method as described in any one of claims 1 to 9.

Images