Method and system for optimizing response time of mobile application
Through asynchronous task parallel processing and intelligent caching mechanism, the problem of slow response time for mobile application startup and page jump is solved, significantly improving response speed and user experience, and reducing server burden.
Patent Information
- Application Number
- CN202411780329.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-12-05
- Publication Date
- 2025-04-25
AI Technical Summary
The response time of existing mobile applications is slow when starting and page redirecting, resulting in increased user waiting time.
Through parallel processing of asynchronous tasks, page loading and data acquisition are performed simultaneously. Use the data preloader to send interface requests asynchronously and cache data when the page is loaded. The intelligent caching mechanism ensures that only unexpired data is used.
It significantly shortens user waiting time, improves the APP's response speed and user experience, reduces the server burden, and realizes efficient data processing and utilization.
Smart Images
Figure CN119883399A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical field of app page loading, and in particular to the parallel execution direction of app asynchronous tasks, and in particular to a method and system for optimizing the response time of a mobile application. Background Art
[0002] In the current field of mobile application development, the startup performance of an application (APP) is one of the important indicators for measuring user experience. Traditionally, the startup process of an APP usually follows a serial execution mode, that is, first loading and displaying the initial page (such as the homepage), then initiating a server request to obtain the necessary data, and finally displaying the data on the page. This process can be divided into two main stages: page loading stage and data acquisition stage.
[0003] During the page loading phase, the application needs to load and render page resources, including but not limited to layout files, images, scripts, etc. The time overhead of this process is assumed to be 500 milliseconds; then, during the data acquisition phase, the application will send a request to the server to obtain dynamic data for page display, and this process also takes a certain amount of time, assuming 500 milliseconds. Therefore, in serial execution mode, the total time consumed by the entire startup process will reach 1 second.
[0004] However, the serial execution mode is not the optimal solution. In order to improve the user experience, you can consider adopting a parallel execution strategy, that is, acquiring data while the page is loading. The core idea is to make full use of the page loading time so that the data acquisition process overlaps with the page loading process, thereby reducing the total waiting time for users.
[0005] To this end, the present invention proposes a method and system for optimizing the response time of mobile applications. Summary of the invention
[0006] In view of this, the present invention hopes to provide a method and system for optimizing the response time of mobile applications to solve or alleviate the technical problems existing in the prior art, that is, how to use the method of asynchronous task parallelism to solve the problem of slow display speed of app startup and page jump; the technical solution of the present invention is implemented as follows:
[0007] First, a method for optimizing the response time of mobile applications:
[0008] 1. Overview:
[0009] The present invention aims to optimize the startup and page display speed of APP by combining asynchronous task parallel processing with intelligent caching mechanism. When the user starts APP or triggers the loading of a new page, the system first initializes a data preloader, which can asynchronously send interface requests and receive data returned by the server. At the same time, the main thread of APP asynchronously loads page resources, such as layouts, images, and scripts, to achieve parallel execution of page loading and data acquisition. After receiving the data, the data preloader will cache it locally according to the unique identifier of the request for subsequent rapid retrieval. When the page loading is completed, the page will call the interface provided by the data preloader to obtain the required data. The intelligent caching mechanism ensures that only unexpired data is used, and expired data will be updated or re-requested. In this way, the user waiting time is significantly shortened, the response speed and user experience of APP are improved, while the burden on the server is reduced, and efficient data processing and utilization are achieved.
[0010] (II) Technical solution:
[0011] To achieve the above technical goals, when an activation instruction input by the user is received (for example, starting an APP or starting a new program), the data preloader is responded to and initialized, so that the data preloader waits to receive the request; when the main thread of the APP starts working (asynchronously loading the home page resources, such as parsing layout files, loading images and scripts, etc.), the following steps are performed.
[0012] 2.1 Step S1, call the data preloader and process the interface request:
[0013] While the page is loading, the app main thread or another asynchronous thread calls the data preloader;
[0014] The data preloader starts asynchronously sending interface requests to the server according to the preset configuration and waits for a response.
[0015] 2.1.1 Step S100, configure interface request:
[0016] The data preloader prepares the interface request to be sent to the server according to the preset configuration information, including the request URL, request parameters and request header.
[0017] 2.1.2 Step S101, send an interface request and wait for the server to respond:
[0018] The data preloader asynchronously sends an interface request to the server; during the waiting period, the app can continue to perform other tasks, such as loading page resources;
[0019] When the server processes the request, it returns the data to the data preloader.
[0020] 2.2 Step S2, cache interface data and check page loading status:
[0021] After receiving the data returned by the server, the data preloader creates an index relationship and caches it in the local cache of the APP.
[0022] 2.2.1 Step S200, cache interface data:
[0023] After receiving the data returned by the server, the data preloader caches the data in the local cache of the APP according to the unique identification key of the request (the ID of a data item or a query parameter). In this way, when the subsequent page needs to display data, it can be directly retrieved from the cache; the cached data is associated with the unique identification key to ensure that the required data can be retrieved quickly and accurately in the future.
[0024] 2.2.2 Step S201, check page loading status:
[0025] Simultaneously with step S200: By monitoring the page loading event or polling the page loading status, the APP main thread or the page loading manager will continuously check the progress of the page loading.
[0026] When the page loading reaches a preset completion state (such as the page layout loading is completed or the key resource loading is completed), the execution of step S3 is triggered.
[0027] 2.3 Step S3, page loading is completed, data is obtained:
[0028] After the page is loaded, the page needs to display data. At this time, the page calls the interface provided by the data preloader and sends a request data instruction according to the required unique identification key.
[0029] 2.3.1 Step S300, calling the data interface:
[0030] The page needs to display data at this time, so it will call the function or method of the interface provided by the data preloader to send a request data instruction.
[0031] 2.3.2 Step S301, send request data instruction:
[0032] The page will wait for the data to be returned after sending a request data instruction according to the required unique identification key. During this process, the page will display a loading animation or placeholder to inform the user that the data is loading.
[0033] 2.4 Step S4, intelligent processing of data requests:
[0034] According to the request data instruction sent in step S3, the data caller checks whether there is data in the cache according to the unique identification key, and gives the data to the page.
[0035] 2.4.1 Step S400, check cache:
[0036] After receiving the request data instruction sent in step S3, the data caller checks whether there is data in the cache according to the unique identification key.
[0037] If there is data in the cache, the data caller will check whether the data is expired. In order to ensure the real-time nature of the data, the data caller will only return data cached within a certain range of seconds (such as 5 seconds) when obtaining the interface cache. If the data is not expired, it will be directly returned to the page.
[0038] 2.4.2 Step S401, processing request status:
[0039] If there is no data in the cache or the data has expired, the data caller will check whether there is a request in progress for the key:
[0040] If the request is in progress, the data caller will wait for the response of the request and return the data to the page after the response comes back;
[0041] If the request is not in progress, the data caller will initiate a new request to the server to obtain the latest data.
[0042] 2.4.3 Step S402, obtain and return data:
[0043] Whether the data is obtained from the cache or through a new request, the data caller will eventually return the data to the page. After the page receives the data, it will display it.
[0044] 2.5 Step S5, display data:
[0045] After receiving the data in step S4, the page is rendered and displayed to present the final page content to the user.
[0046] 2.6 Step S6, enter the loop:
[0047] When the user jumps to a page or needs to refresh data, the data preloader is called repeatedly, processing data requests and caching according to the new unique identification key each time; when the APP enters normal operation, the data preloader remains active and is ready to process new data requests at any time.
[0048] 2.6.1 Step S600, processing new data request:
[0049] Each time the data preloader is called, the data request is processed based on the new unique identification key.
[0050] When processing a new data request, the data preloader checks whether there is data corresponding to the unique identification key in the cache. If there is valid data in the cache, it is directly returned to the page to reduce network requests.
[0051] 2.6.2 Step S601, initiate a network request:
[0052] If there is no data in the cache or the data has expired, the data preloader asynchronously initiates a new network request to the server to obtain the latest data. This request is made asynchronously to ensure that other operations of the app are not blocked.
[0053] 2.6.3 Step S602, update cache:
[0054] When the data preloader obtains new data from the server, it updates the data to the cache according to the unique identification key. In this way, subsequent requests with the same key can directly obtain data from the cache.
[0055] Regardless of whether the data is obtained from the cache or through a network request, the data preloader will eventually return the data to the page (i.e., return to step S5). After the page receives the data, it will display or update it accordingly.
[0056] (III) Mechanism for solving technical problems:
[0057] 3.1 Asynchronous tasks are executed in parallel:
[0058] When the app is started or the page jumps, the system no longer waits for the page to be fully loaded before fetching data, but starts two asynchronous tasks at the same time: page loading and data fetching. The page loading task is responsible for parsing layout files, loading images and scripts, etc., while the data fetching task asynchronously sends an interface request to the server through the data preloader and waits for a response.
[0059] The data preloader is a key component that can asynchronously send interface requests according to the preset configuration while the page is loading. When the server processes the request and returns the data, the data preloader receives the data and caches it in the local cache of the app according to the unique identifier (key) of the request.
[0060] 3.2 Intelligent caching mechanism:
[0061] The cached data is associated with a unique identification key for quick retrieval later. When a page needs to display data, it first checks whether there is data with the corresponding key in the cache. If there is and it has not expired, the cached data is used directly to avoid repeated network requests. The APP main thread or page loading manager continuously checks the progress of page loading, and triggers the data acquisition operation when the page loading reaches the preset completion state. Since data acquisition has been completed in advance through the data preloader, the page can immediately obtain the required data and render and display it.
[0062] 3.3 Real-time guarantee:
[0063] In order to ensure the real-time nature of the data, an expiration time (such as 5 seconds) is set for the cached data. Data that exceeds the expiration time will be considered expired, and a new request will be made to obtain the latest data when necessary.
[0064] When the user jumps to a page or needs to refresh data, the data preloader is called repeatedly to process data requests and caches based on the new key. This mechanism ensures that the APP always maintains efficient data processing and display speed during operation.
[0065] Second, a system for optimizing the response time of mobile applications:
[0066] like Figure 4 As shown, the system is used to implement the above-mentioned method for optimizing the response time of a mobile application, which includes:
[0067] (1) A data preloader that is responsible for asynchronously sending interface requests to the server while the page is loading and receiving the returned data for caching, including:
[0068] (1.1) Asynchronous execution submodule: It is not executed serially with the page loading task, which reduces the user's waiting time.
[0069] (1.2) Cache mechanism submodule: The acquired data is cached locally according to the unique identifier for quick retrieval later.
[0070] (2) The data caller is responsible for calling and processing data requests according to the requirements of the page: it checks whether there is available data in the local cache based on the unique identification key, and decides how to obtain the data based on the cache status and request status of the data.
[0071] (3) Asynchronous task manager responsible for scheduling and executing asynchronous tasks, including page loading tasks and data acquisition tasks: supports parallel execution of multiple asynchronous tasks to improve task processing efficiency.
[0072] (4) A local cache system used to store data obtained by the data preloader so that the page can quickly obtain and display the data when needed.
[0073] (5) The page loading manager is responsible for loading and rendering page resources: including layout files, images, scripts, etc. It also supports asynchronous loading of page resources to reduce the page white screen time.
[0074] (6) Network request module responsible for sending interface requests to the server and receiving response data: supports asynchronous network requests and does not block the UI thread. It handles errors that may occur during the network request process to ensure the integrity and accuracy of the data.
[0075] Compared with the prior art, the present invention has the following beneficial effects:
[0076] 1. Improve APP response speed: The present invention processes asynchronous tasks in parallel, and the page loading and data acquisition are performed simultaneously, which significantly shortens the user waiting time, enables the page to display content faster, and improves the user experience. The data preloader pre-acquires data while the page is loading and caches it locally. When the page needs to display data, it can be directly obtained from the cache without waiting for network requests, thereby improving the response speed of the APP.
[0077] 2. Reduce the burden on the server: The intelligent caching mechanism of the present invention reduces repeated network requests, reduces the burden on the server, and also reduces the problem of slow page loading caused by network delays or instability. The asynchronous task parallel processing of the present invention makes the CPU and network resources more efficiently utilized, avoiding idleness and waste of resources.
[0078] 3. Enhanced data real-time performance: The present invention ensures data real-time performance by setting the expiration time of cached data, so that users can see the latest page content. Asynchronous processing and caching mechanisms reduce the situation where APP crashes or page loading fails due to network problems or server failures, and improve the stability and reliability of APP. BRIEF DESCRIPTION OF THE DRAWINGS
[0079] 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.
[0080] Figure 1 It is a schematic diagram of the method flow of the present invention;
[0081] Figure 2 A schematic diagram of the method execution logic of steps S1 to S2 of the present invention;
[0082] Figure 3 A schematic diagram of the method execution logic of steps S3 to S4 of the present invention;
[0083] Figure 4 It is a schematic diagram of the system composition of the present invention. DETAILED DESCRIPTION
[0084] 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;
[0085] 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.
[0086] Explanation of relevant terms:
[0087] (1) APP main thread: responsible for the main execution path of loading and displaying the APP interface.
[0088] (2) Another asynchronous thread: runs in parallel with the main thread and is used to perform tasks that do not block the main thread, such as calling a data preloader.
[0089] (3) Data preloader: A module or component used to asynchronously fetch and cache data when the page loads.
[0090] (4) Preset configuration: pre-set parameters and rules that guide the data preloader on how to send requests and process data.
[0091] (5) Asynchronously send interface requests to the server: Send data requests to the server and wait for responses without blocking the main thread.
[0092] (6) Unique identification key: an identifier used to identify and distinguish different data items.
[0093] (7) Data: Information obtained from the server and used for page display.
[0094] (8) Preset completion state: A predefined state reached by page loading, which triggers subsequent data acquisition and display operations.
[0095] (9) Data caller: refers to the data preloader or the component responsible for processing data requests.
[0096] (10) Interface cache: Server response data stored locally for quick retrieval.
[0097] Embodiment 1: Figures 1 to 3 As shown, this embodiment will provide a method for optimizing the response time of the online car-hailing APP:
[0098] Suppose a user constantly switches between different function pages when using an online car-hailing APP, such as the home page, the car-hailing page, the trip page, the payment page, etc. The display of each page depends on the data provided by the backend server. In order to improve the user experience, this optimization method needs to ensure that the page loading and data display speed are as fast as possible. This optimization method includes the following steps S1 to S6.
[0099] In this embodiment, regarding step S1: calling the data preloader and processing the interface request: when the user opens the APP or jumps to a new page, the APP main thread will call the data preloader.
[0100] Step S100: Configure interface request. The data preloader prepares a request to be sent to the server according to a preset configuration, including the requested URL (such as an API for obtaining a ride-hailing list), request parameters (such as user location, timestamp), and request header (such as user identity authentication information).
[0101] Step S101: Send an interface request and wait for the server to respond. The data preloader asynchronously sends the request to the server, while the APP continues to load page resources. After the server processes the request, it returns the ride-hailing list data to the data preloader.
[0102] In this embodiment, regarding step S2: caching interface data and checking page loading status: after the data preloader receives the data returned by the server, it caches the data and checks the page loading status.
[0103] Step S200: Cache interface data. The data preloader caches the data into the local cache of the APP according to the unique identification key of the request (such as "ride list_user ID_timestamp").
[0104] Step S201: Check the page loading status. The APP main thread listens to the page loading event to determine whether the page is loaded. Once the page layout is loaded, step S3 is triggered.
[0105] In this embodiment, regarding step S3: after the page loading is completed, data is obtained: after the page loading is completed, data needs to be displayed.
[0106] Step S300: calling the data interface. The page calls the interface function provided by the data preloader to request data.
[0107] Step S301: Send a request data instruction. The page sends a request instruction according to the required unique identification key and displays a loading animation.
[0108] In this embodiment, regarding step S4: intelligently processing data requests: the data caller intelligently processes data requests according to the request instructions of the page.
[0109] Step S400: Check the cache. The data caller checks whether there is data in the cache and determines whether the data is expired.
[0110] Step S401: Process the request status. If there is no data in the cache or the data is expired, check whether there is an ongoing request. If there is, wait for a response; if not, initiate a new request.
[0111] Step S402: Obtain and return data. Regardless of whether the data is obtained from the cache or through a new request, it is returned to the page for display.
[0112] In this embodiment, regarding step S5: displaying data: after receiving the data, the page renders and displays it.
[0113] Specific implementation: The page updates UI elements such as the ride-hailing list and itinerary information based on the received data.
[0114] In this embodiment, regarding step S6: entering a loop: when the user jumps to a page or needs to refresh data, the data preloader is repeatedly called.
[0115] Step S600: Processing a new data request. Each time the data preloader is called, the data request is processed according to the new unique identification key.
[0116] Step S601: Initiate a network request. If there is no data in the cache or the data is expired, asynchronously initiate a new request to the server.
[0117] Step S602: Update the cache. After acquiring new data, update the cache for subsequent use.
[0118] In summary, in this embodiment, through the method of asynchronous task parallelism, data requests can be made while the page is loading, thereby reducing the waiting time for the page to display data. This makes the startup and page jump speed of the APP relatively faster, improving the user experience.
[0119] Asynchronous tasks allow the app to perform other operations without blocking the main thread. When the data preloader sends a request to the server asynchronously, the app can continue to load page resources without waiting for the server to respond. Similarly, when the data caller checks the cache or initiates a new request, it is also done asynchronously without blocking other operations on the page.
[0120] Embodiment 2: This embodiment further provides a Python execution program of the optimization method described in Embodiment 1, including the implementation of a data preloader, a data caller, and an asynchronous task manager:
[0121] import asyncio
[0122] import threading
[0123] import time
[0124] from concurrent.futures import ThreadPoolExecutor
[0125] from functools import partial
[0126]
[0127]
[0128]
[0129]
[0130] In the above program, DataPreloader is responsible for preloading data when the page is loaded or as needed. It uses a thread pool (ThreadPoolExecutor) to process network requests asynchronously to avoid blocking the main thread. After the data is loaded, it is cached in the local cache (local_cache).
[0131] Data Fetcher: Responsible for intelligently processing data requests based on the page's request instructions. First, check whether there is data in the local cache. If there is data, return it directly. If there is no data in the cache or the data is expired, call the data preloader to load the data.
[0132] The main function (main) performs the process of page loading, data request and data display. Use asyncio.run to run the asynchronous main function.
[0133] By using the asynchronous task parallel method, data requests can be made while the page is loading, thus reducing the waiting time for the page to display data. Asynchronous tasks allow the APP to perform other operations without blocking the main thread, improving the APP's response speed and user experience.
[0134] 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.
[0135] 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.
[0136] 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, and 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 may include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory may 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 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 method for optimizing the response time of a mobile application, characterized in that: After receiving the activation instruction input by the user, respond and initialize the data preloader, so that the data preloader waits for receiving the request; when the main thread of the APP starts working, perform the following steps: S1: While the page is loading, the APP main thread or another asynchronous thread calls the data preloader; the data preloader starts asynchronously sending interface requests to the server according to the preset configuration; S2: After receiving the data returned by the server, the data preloader creates an index relationship and caches it in the local cache of the APP; S3, after the page is loaded, call the interface provided by the data preloader and send a request data instruction according to the required unique identification key; S4, according to the request data instruction sent by S3, the data caller checks whether there is data in the cache according to the unique identification key, and gives the data to the page; S5, after receiving the data in step S4, the page is rendered and displayed to present the final page content to the user.
2. The optimization method according to claim 1, characterized in that: The execution steps of S1 include: S100, the data preloader prepares an interface request to be sent to the server according to preset configuration information, including a request URL, request parameters, and a request header; S101, the data preloader asynchronously sends an interface request to the server; during the waiting period, the APP continues to load page resources; when the server processes the request, it returns the data to the data preloader.
3. The optimization method according to claim 1, characterized in that: The execution method of S2 includes: S200, after receiving the data returned by the server, the data preloader caches the data into the local cache of the APP according to the unique identification key of the request; the cached data is associated with the unique identification key to implement the index; S201, by monitoring page loading events or polling page loading status; When the page load reaches the preset completion state, S3 execution is triggered.
4. The optimization method according to claim 3, characterized in that: The execution steps of S3 include: S300, calling a function or method of an interface provided by a data preloader to send a request data instruction; S301, sending a request data instruction according to the required unique identification key, so that the page waits for the return of data.
5. The optimization method according to claim 4, characterized in that: The execution method of S4 includes: S400, after receiving the request data instruction sent by S3, the data caller checks whether there is data in the cache according to the unique identification key; if there is data in the cache, the data caller checks whether the data is expired; if the data is not expired, it is directly returned to the page; S401: If there is no data in the cache or the data has expired, the data caller checks whether there is a request for the key in progress: If a request is in progress, wait for the response of the request and return the data to the page after the response comes back; If the request is not in progress, initiate a new request to the server to obtain the latest data; S402, returning the data to the page.
6. The optimization method according to claim 5, characterized in that: In S400, when the data caller obtains the interface cache, it will only return the data cached within a certain range of seconds; if the data is not expired, it will be directly returned to the page.
7. The optimization method according to claim 1, characterized in that: The further comprising S6: based on the user's instruction to jump to a page, the data preloader is repeatedly called; Each time a call is made, data requests and caches are processed based on a new unique identification key; The app enters normal operation, and the data preloader remains active, ready to handle new data requests at any time.
8. The optimization method according to claim 7, characterized in that: In S6, after the data preloader obtains new data from the server, the data is updated into the cache according to the unique identification key.
9. A system for implementing the optimization method according to any one of claims 1 to 8, characterized in that: The system comprises: A data preloader that is responsible for asynchronously sending interface requests to the server while the page is loading, and receiving the returned data for caching; Responsible for calling and processing data request data caller according to the requirements of the page; An asynchronous task manager responsible for scheduling and executing asynchronous tasks, including page loading tasks and data acquisition tasks.
10. The system according to claim 9, characterized in that: The data preloader comprises: Asynchronous execution submodules that are not executed serially with page loading tasks; The acquired data is cached to the local cache mechanism submodule according to the unique identifier.