CN107203555B

CN107203555B - Page loading processing method and device

Info

Publication number: CN107203555B
Application number: CN201610154563.5A
Authority: CN
Inventors: 杨成旭
Original assignee: Alibaba Group Holding Ltd
Current assignee: Alibaba Group Holding Ltd
Priority date: 2016-03-17
Filing date: 2016-03-17
Publication date: 2021-04-30
Anticipated expiration: 2036-03-17
Also published as: CN107203555A

Abstract

The embodiment of the application discloses a page loading processing method and a page loading processing device, wherein the method comprises the following steps: providing an offline data packet, wherein the offline data packet comprises configuration information in the packet and a plurality of data contents; hijacking a target page file access request generated in an application, and judging whether the offline data packet has target data content corresponding to target URL information or not by using configuration information in the packet; and if the target data content exists, intercepting the target page file access request, constructing page file access response data in a browser response simulating mode by using the target data content in the offline data packet, and returning the response data to a browser control built in the application. By the method and the device, the page loading speed is improved, and meanwhile the robustness of the scheme is improved.

Description

Page loading processing method and device

Technical Field

The present application relates to the field of page loading processing technologies, and in particular, to a page loading processing method and apparatus.

Background

Hybrid App (mixed mode mobile application) is a currently common mobile internet application development mode, and in this mode, a developer can embed an HTML5 application program into a thin native container, so that the Hybrid App can integrate the advantages of a native application program and an HTML5 application program. However, since HTML (hypertext markup language), CSS (Cascading Style Sheet), and js (javascript) files required for interface rendering in the Hybrid App generally need to be acquired by a request server, there may be a problem that a page loading time is long, which affects user experience.

In order to solve the problem of overlong page loading time, two modes exist in the prior art for an iOS platform. The first mode is to realize local loading of static resources by self-defining NSURLCache, specifically, cache a static resource file JS/CSS locally, judge whether a file corresponding to the static resource file JS/CSS is cached locally according to URL when an H5 page is accessed, and construct NSURLResponse response and return the NSURLResponse response according to the content of the local file if the file is cached locally. If the local cache does not exist, the network requests the remote server to acquire corresponding data, and then the corresponding data is added into the local cache so as to be read from the cache in the next access. The scheme can completely realize local loading of static resources such as JS, CSS and pictures, but has the obvious defect that the incoming parameters cannot be obtained by applying the built-in browser control UIWebView to the locally loaded HTML request. For example, the URL (Uniform resource Locator) of the H5 page requesting access is: http:// h5.m. taobao. com/trip/holiday/search. htmllat ═ 122& lon ═ 32, but the scheme is to find the corresponding local file content and construct a response according to http:// h5.m. taobao. com/trip/holiday/search. html, i.e., the lat and lon parameter values are removed, resulting in lat and lon parameter values that cannot be passed to UIWebView. However, if the parameter value in the URL is related to page rendering, the UIWebView fails to obtain the parameter value when performing HTML page parsing rendering.

The other solution is a method for constructing a virtual host domain, which comprises the steps of firstly judging whether the file content corresponding to the HTML type request is in a local disk, if the file content can be found locally, replacing the domain name of the file with a virtual host, and then redirecting all static resource file (HTML, JS, CSS and pictures) requests under the domain name to local loading without accessing a server. That is, once it is found that the content of a file requested by an HTML is stored in the local disk, all domain names requested by CSS, JS, pictures, etc. having the same domain name as the HTML are modified to virtual host, so that all accesses to files such as CSS, JS, pictures, etc. are redirected to the local disk. And then returning a response to the UIWebView in a manner of locally constructing the response. This kind of mode can enough realize the local loading of file such as CSS, JS, also can realize the local loading of HTML, but the shortcoming lies in: an H5 page is usually composed of an HTML file, a plurality of CSS files, a plurality of JS files and a plurality of pictures, and the scheme cannot know in advance which JS/CSS file requests are contained in the HTML file, so that whether the JS and CSS files contained in the HTML file exist in a local disk or not cannot be judged. Therefore, if the HTML file is in the local disk, but the JS and the CSS requested by the HTML file are not in the local disk, a nonexistent virtual domain can be obtained after the domain name requested by each JS and CSS is modified, so that the response cannot be constructed locally, and further, the page access is wrong.

In summary, how to further optimize the page loading process improves the robustness of the scheme while solving the problem of too long page loading time, which becomes a technical problem to be solved by the technical personnel in the field.

Disclosure of Invention

The application provides a page loading processing method and device, which can improve the page loading speed and the robustness of a scheme.

The application provides the following scheme:

a page loading processing method is characterized by comprising the following steps:

providing an offline data packet, wherein the offline data packet comprises configuration information in the packet and a plurality of data contents, each data content corresponds to a page file to be accessed, and the configuration information in the packet comprises a corresponding relation between Uniform Resource Locator (URL) information for accessing each page file and relative path information of the data contents in the packet;

hijacking a target page file access request generated in an application, determining target URL information of the target page file access request, and judging whether the offline data packet has target data content corresponding to the target URL information by utilizing configuration information in the packet;

and if the target data content exists, intercepting the target page file access request, constructing page file access response data in a browser response simulating mode by using the target data content in the offline data packet, and returning the response data to a browser control built in the application.

A page load processing apparatus, comprising:

the off-line data package providing unit is used for providing an off-line data package, the off-line data package comprises in-package configuration information and a plurality of data contents, each data content corresponds to a page file to be accessed, and the in-package configuration information comprises a corresponding relation between Uniform Resource Locator (URL) information used for accessing each page file and relative path information of the data contents in the package;

the judging unit is used for hijacking a target page file access request generated in an application, determining target URL information of the target page file access request, and judging whether the offline data packet has target data content corresponding to the target URL information by utilizing configuration information in the packet;

and the response data construction unit is used for intercepting the target page file access request if the target data content exists, constructing page file access response data in a browser response simulating mode by using the target data content in the offline data packet, and returning the response data to a browser control built in the application.

According to the specific embodiments provided herein, the present application discloses the following technical effects:

according to the embodiment of the application, whether the corresponding target data content exists in the offline data packet or not is judged according to the page file access requests of the types such as HTML, CSS, JS and pictures, so that even if the HTML file is in the offline data packet, the JS file, the CSS file and the like contained in the same H5 page are not in the offline data packet, the situation of webpage errors can not occur. And then, if the target data content exists in the offline data packet, constructing response data by using the target data content in the offline data packet in a mode of completely simulating browser response, and returning the response data to the browser control built in the application for analyzing and rendering. During the period, operations such as virtual domain replacement and the like are not required, so that when the HTML request loaded from the offline data packet is completely supported, any parameter is transmitted to the browser control, and the JS request and the CSS request are not transmitted with the parameter, so that the offline data packet loading can be supported better. In summary, according to the embodiment of the application, loading from an offline data packet can be achieved for access requests of various types of files, and high robustness is achieved.

In a preferred implementation manner, the offline data packets can be divided according to the service modules, so that each time the offline packet of one module is updated instead of the offline packets of all apps, the update packet size is reduced, the update cost is reduced, and the flexibility is improved.

In another preferred implementation, by providing a common offline data package and a lazy-loading offline data package scheme, the volume of the offline data package can be reduced better, and the volume of the application installation package can be reduced.

In another preferred implementation, a cache mechanism may be used to add the relevant data involved in the first access to the cache, perform subsequent accesses from the cache, and reside the global configuration information in the memory, thereby reducing the number of I/O times of the disk to the maximum extent and further increasing the time for loading the page.

Of course, it is not necessary for any product to achieve all of the above-described advantages at the same time for the practice of the present application.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings needed to be used in the embodiments will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings without creative efforts.

FIG. 1 is a conceptual diagram of a data packet provided by an embodiment of the present application;

FIG. 2 is a flow chart of a method provided by an embodiment of the present application;

FIG. 3 is a flow chart of another method provided by embodiments of the present application;

FIG. 4 is a schematic diagram comparing page loading time in the embodiment of the present application with that in the prior art;

fig. 5 is a schematic diagram of an apparatus provided in an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments that can be derived from the embodiments given herein by a person of ordinary skill in the art are intended to be within the scope of the present disclosure.

In the embodiment of the application, in order to further optimize the page loading process, improve the robustness of the page loading scheme while solving the problem of too long page loading time, provide an offline data packet, and when the application is in operation, intercept a page file access request through a pre-registered protocol class, after intercepting a specific page file access request, judge whether an HTML file access request, a CSS file access request, a JS file access request, or a picture file access request exists in the offline data packet, if so, construct page file access response data by using data contents in the offline data packet in a manner of completely simulating browser response, and return the page file access response data to a browser control built in the application, and performing operations such as analyzing and rendering the page. In the scheme, because the access requests of various file types can be judged whether the corresponding data content exists in the offline data packet, if so, the data content in the offline data packet is loaded, otherwise, the data content is loaded from the remote server according to the original URL request. In this way, even if the HTML file is in the offline package, if the JS file, CSS file, or the like included in the same H5 page is not in the offline package, a web page error does not occur. In addition, response data is constructed in a mode of completely simulating browser response, operations such as replacement of virtual domains are not needed, and therefore when the HTML request loaded from the offline data packet is completely supported, any parameter is transmitted to the browser control. That is to say, the page loading scheme provided by the embodiment of the present application can implement loading from offline data packets for access requests of various types of files, and has high robustness.

In order to facilitate understanding of the technical solutions of the embodiments of the present application, some related concepts and functions will be described first.

Referring to fig. 1, the concepts involved in the embodiments of the present application include:

1. regarding offline data packets. In this embodiment of the application, the offline data package may first include multiple data contents, where each data content corresponds to a page file to be accessed, and the page file includes an HTML file, a CSS file, a JS file, or a picture file, that is, the data contents of various types of page files may be stored in the offline data package.

2. Regarding intra-packet configuration information. Since a plurality of data contents are stored in one offline data packet, each data content corresponds to one page file, and configuration information in one packet can be provided for judging whether the data content corresponding to a specific page file access request exists in the offline data packet or not when the specific page file access request is intercepted. The information may exist in the form of a file, etc., wherein the configuration information in the package includes: and the corresponding relation between the URL information for accessing each page file and the relative path information of the data content in the package.

For example, a specific information holding structure may be as follows: "trip/hold/search. html": search/search. html ", this example indicates that the URL of the pagefile is: http:// h5.m. taobao. com/trip/holiday/search. html, the relative address of the file in the offline packet is/search. htmll, i.e., the search. htmll file under the search directory, etc.

The URL information for accessing each page file may be known in advance, and the relative path information of the data content in the packet may be set when the offline data packet is generated, that is, may also be known in advance, so that the mapping relationship between the two information may be recorded in the configuration information in the packet. The in-packet configuration information may also be stored in an offline data packet. The data content may be distinguished from the specific data content by an extension of the file, for example, the configuration information in the package may be saved as a json file, that is, json is used as an extension, and the like.

3. Regarding global configuration information. Generally, for some applications with simple functions, a unified offline package can be used to support offline loading of all pagefiles. However, some applications with complex functions include a large number of pages, and one page often includes an HTML file, several CSS files, several JS files, and several picture files, so that the number of page files is larger, and at this time, if all page files are stored in the same offline data packet, the volume of the offline data packet is larger, the data transmission amount during updating the offline data packet is larger, and it takes longer time, and the time taken to download the latest offline data packet from the server is longer, which increases the insecurity of the function, because the longer the time is, the higher the probability that a network interruption occurs or the application is switched to a background operation is, the update operation may be terminated at any time, and especially in a 3G network state, the situation is more serious; in addition, the packet size is too large, and the generation logic of the server for the update packet becomes very complicated.

For the above reasons, it is considered that a large application is generally divided into a plurality of service modules according to service lines, for example, for the ali travel App, the modules are generally divided according to service lines such as admission tickets, hotels, vacations, taxi-taking and the like. Therefore, in the preferred embodiment of the present application, a plurality of offline data packets may be provided according to a plurality of service modules included in the application, each offline data packet corresponds to a page file access request of each page in the same service module, and each offline data packet corresponds to respective in-packet configuration information. For example, for an ari travel App, an offline data packet corresponding to a ticket module, an offline service data packet corresponding to a hotel module, and the like may be provided, where the offline data packet corresponding to the ticket module only includes various types of page files included in each page related to the ticket service, the offline data packet corresponding to the hotel module only includes various types of page files included in each page related to the hotel service, and the like. Therefore, the volume of each offline data packet can be greatly reduced, when the offline data packets are updated, the offline data packets corresponding to each service module can be used as units for updating, and the data volume transmitted when the data are updated is greatly reduced.

In this way, of course, each offline data packet corresponds to its own configuration file in the packet, that is, the configuration file in one packet only needs to record the corresponding relationship between each file URL in one data packet and the corresponding path of the data content in the packet, so in order to locate the data content actually corresponding to a target URL, it is also necessary to first know in which particular offline data packet the data content corresponding to the URL is stored.

For this reason, in the embodiment of the present application, global configuration information is also provided, and the information may also exist in a json-type file, for example, which may be named as h5packagemap. In the global configuration information, a correspondence between the URL and an identifier of an offline data packet where the corresponding data content is located (the identifier of the data packet may be a name of the data packet, which is simply referred to as a "packet name", and may be other identifiers, of course) may be recorded. For example, suppose that the URL for accessing a certain pagefile is http:// h5.m. taobao. com/trip/hold/search. html, the relative path (relative path) of the above-mentioned link is trip/hold/search. html, and the data content corresponding to this URL is located in an offline data packet with a packet name of h 5-hold, so the corresponding relationship can be recorded as: "/trip/holiday/+": h5-holiday ". Therefore, when a page file access request is specifically intercepted, the corresponding offline data packet name can be determined according to the URL corresponding to the request and the corresponding relation.

It should be noted that, as can be seen from the foregoing examples of the intra-package configuration information and the global configuration information, when recording the correspondence between the URL information and the relative path of the data content in the package, or the offline package name, the URL information is the corresponding path portion (relatedpath) in the used URL, that is, the domain name portion (host, such as http:// h5.m. This is because, particularly when the configuration information is saved, it can be implemented by using a regular expression, but the requests of the same page file in the test, pre-issue and online environments correspond to different hosts, that is, different URL addresses, and if the URL is directly used for matching, different environments require different regular expressions, which may increase the data amount of the configuration information. Since the relativePath does not change with host, in the embodiment of the present application, the relativePath of the URL may be taken as a judgment basis, so that one regular expression may be adapted to all environments.

In addition, for the global configuration information, although the number of pages included in one offline data package is controlled (for example, after the ali travel App is divided into about 20 offline data packages according to service lines, each offline data package includes page files of 5 to 10H 5 pages), each H5 page includes an HTML file and a plurality of CSS, JS, pictures and other files. For so many page files, it is difficult to map the URLs (including JS and CSS files) of all the page files under the offline data packet to the same offline data packet name through the regular expression. If the requests of the same service logic can not be loaded from the same offline data packet, all the offline data packets can only be placed under the same local directory, so that the function of dividing the offline data packets according to the service modules can not be realized.

In this regard, considering that the process of loading resources by the WebKit kernel is to load an HTML file first, and then load JS/CSS files therein sequentially from top to bottom in the process of parsing HTML to build a DOM tree, for an H5 page, the HTML resource is loaded first, and the JS/CSS resources are loaded subsequently. By utilizing the characteristic, in the preferred embodiment of the application, the corresponding relation between the URL of the HTML file and the offline data packet to which the HTML file belongs can be included in the global configuration file, and the URL of the JS/CSS file is not expressed any more, so that the packet name mapping mode is realized through the regular expression, and the regular expression only needs to ensure that the URLs of all HTML requests and the offline data packet names are matched. Specifically, when a page file access request is intercepted, for the HTML file access request, an offline data packet name can be analyzed in a regular matching mode according to a global configuration file, the packet name can be recorded, a regular matching failure condition can occur in subsequent JS/CSS requests, and at the moment, data content can be acquired from the offline data packet analyzed from the previous HTML request. When a new HTML request is intercepted, if the analyzed offline data packet name is changed, the recorded offline data packet name can be updated, and the JS/CSS request after the new HTML request acquires data content from the updated offline data packet.

4. Regarding common offline data packets. In some applications, some page files such as CSS, JS, and pictures may exist, and may be used in different service modules, and for this portion of page files, in the preferred embodiment of the present application, the page files may also be stored by a single common offline data packet, and the page files may not appear in the offline data packet corresponding to each service module once, so that the volume of the offline data packet may be reduced. The public offline data packet also comprises public in-packet configuration information and a plurality of data contents, wherein each data content corresponds to one CSS file, JS file or picture file, and the public in-packet configuration information comprises the corresponding relation between URL information and the corresponding path information of the data contents in the packet. In addition, the global configuration information also includes mapping information about the common offline data packet, and certainly, since the common offline data packet does not include an HTML file and the number of files that can be truly shared among the service modules is not large in practical application, the global configuration information can directly generate a regular expression according to the URL of each CSS/JS/picture file and map the regular expression to the common offline data packet. When a CSS/JS/picture file access request is intercepted, regular matching can be performed by using a URL of the request, and if a public offline data packet can be matched, the corresponding specific data content is determined by using the configuration information in the packet in the public offline data packet. And if the public data packet cannot be matched, judging whether the offline data packet corresponding to each other service module can be matched.

In this case, if the regular expression is generated only from the URL of the HTML file for the offline data packet corresponding to each service module in the global configuration information, the two do not conflict, because the CSS/JS/picture file access request preferentially matches the common data packet and can directly match the common data packet with the URL of the CSS/JS/picture file access request. And under the condition that the public data packet cannot be matched, matching with the offline data packets corresponding to other specific service modules, and at the moment, taking the target offline data packet corresponding to the recently intercepted HTML file access request according to the mode, and obtaining the data content corresponding to the CSS/JS/picture file access request from the target offline data packet.

5. For lazy-to-load packets. In general, the offline data packet can be carried in the App installation, and is downloaded to the local terminal device along with the installation packet, and then decompressed to a specified local disk directory, and the offline loaded data is acquired from the directory. However, in practical applications, some pages in the service module may have a low access frequency, and the usage rate of the corresponding offline data packet is also low. For this situation, in the preferred embodiment of the present application, such an offline data packet with a low access frequency may be referred to as a "lazy loading packet", and for such an offline data packet, it may not be necessary to put it into the APP installation package for issuing. However, configuration information about such a lazy-loading package may be recorded in the global configuration information, that is, a specific page request may be matched to such a lazy-loading package, and in addition, a download address of the lazy-loading package may also be stored in the global configuration information. Therefore, when a user accesses the pages, the existence of the corresponding offline data packet can be determined according to the global configuration information, then whether data related to the offline data packet exists in the local disk is judged, if the data does not exist, the service module is proved to be accessed for the first time, at this time, a downloading sub-thread can be created, the downloading sub-thread accesses the remote server according to the data packet downloading address recorded in the global configuration information, the offline data packet corresponding to the page is downloaded to the specified directory in the local disk, and when a page file access request related to the offline data packet is intercepted again next time, the specific data content corresponding to the offline data packet can be directly obtained from the local disk.

Various concepts related to the embodiments of the present application are introduced above, and a detailed description is given below of a specific page loading processing flow provided by the embodiments of the present application.

Referring to fig. 2, an embodiment of the present application provides a page loading processing method, which may specifically include the following steps:

s201: providing an offline data package, wherein the offline data package comprises in-package configuration information and a plurality of data contents, each data content corresponds to a page file to be accessed, the page file comprises a hypertext markup language (HTML) file, a Cascading Style Sheet (CSS) file, a JS file or a picture file, and the in-package configuration information comprises a corresponding relation between Uniform Resource Locator (URL) information used for accessing each page file and relative path information of the data contents in the package;

the offline data package can be normally distributed along with the App installation package, so that when the user installs the App on the terminal device of the user, the offline data package is also downloaded to the local disk of the terminal device. The offline data package can exist in a zip package form in the App installation package, the App package cannot be modified, and in order to achieve dynamic updating of the offline data package, the offline data package can be operated under a sandbox, so that the zip package needs to be copied from the App installation package and decompressed to a specified sandbox directory after the App is installed and is opened for the first time. Wherein if there are multiple offline data packets, the global configuration file (e.g., h5packagemap. json) may also be included in the App install package and decompressed to the specified sandbox directory along with the Zip package. By sandboxing is meant the practice of running an application in a restricted, secure environment to restrict the code access rights granted to the application. The specific implementation of the sandbox is not within the protection scope of the embodiments of the present application, and is not described in detail herein.

Of course, the offline data packet may be downloaded from the server to the local disk of the terminal device when the offline data packet is accessed for the first time. Or, in the case that there are a plurality of offline data packets, the offline data packet with a high access frequency may be carried in the installation package, the offline data packet with a low access frequency may be stored in the server, and the offline data packet with a low access frequency may be downloaded from the server to the local sandbox when the offline data packet is accessed for the first time (that is, in a so-called lazy package loading manner).

S202: hijacking a target page file access request generated in an application, determining target URL information of the target page file access request, and judging whether the offline data packet has target data content corresponding to the target URL information by utilizing configuration information in the packet; the target page file access request comprises an HTML file access request, a CSS file access request, a JS file access request or a picture file access request;

in order to intercept the target pagefile access request generated in the application, various implementation manners are available in specific implementation. For example, in one implementation, a preset protocol class provided by the inheritance system may be used in advance, a key function of the preset protocol class is rewritten, a custom protocol class is generated, and the custom protocol class is registered when the application is opened, so that a target pagefile access request generated in the application may be intercepted by using the custom protocol class.

Specifically, under the iOS system, the embodiment of the application can utilize NSURLProtocol and NSURLProtocol client to realize that the Hybrid App loads the local page. The user-defined fusion URLProtocol is realized by inheriting NSURLProtocol and rewriting a key function, and then the user-defined Protocol is registered through a method [ NSURLProtocol register class ] [ fusion URLProtocol class ], so that the fusion URLProtocol can control page access in the application.

The NSURLProtocol is an abstract class provided by a Cocoa Touch framework (software development api, which is used for developing software on an iPhone, iPod and iPad, and the library exists in the form of a series of framework libraries which support developers to use User interface elements to construct imaging event-driven application programs), consists of a series of callback functions, provides a basic structure for loading URL data, can hijack a network request initiated by NSURLConnection globally, and can realize customization of an initiated request, return of processed data, improvement and supplementary processing of an existing network protocol, global cache support, User-Agent modification and HTTP proxy by rewriting the NSURLProtocol method. The NSURLProtocol client provides a method for controlling the URL Loading System to load the URL by the NSURLProtocol object, and the method of the NSURLProtocol client can be called when the NSURLProtocol object needs to perform various operations on data content corresponding to the URL.

In the embodiment of the application, the UIWebView can be used for realizing the browser control function built in the application, and the network resource loading function of the UIWebView is realized based on NSURLConnection, so that the NSURLProtocol is used for interfering the process of loading the page of the whole UIWebView. Specifically, each request of nserlconnection goes through all registered protocols, and when the callback function canInitWithRequest is called, the Protocol with the first return value of YES processes the nserlconnection request. The traversal follows the principle of last-in first-out and the latest registered first traversal, so if protocols of other functions exist, the Protocol realizing the page loading access control function in the embodiment of the application can be registered finally, so that the execution of additional operations is reduced, and the efficiency is improved.

In specific implementation, the specific pagefile access request is considered, and the pagefile access request is divided according to the type of operation to be performed on the data, and can be divided into multiple types, such as GET, POST, DELETE, PUT, and the like. The data requested by the POST must be submitted to a remote server for storage, so that the data cannot be loaded in an offline package mode. The DELETE request requires the deletion of resources from the server and the PUT request requires the storage of data to the server, so that loading from offline data packets can only be employed with GET requests that do not require the modification of server content. Therefore, in a specific implementation, before intercepting a target pagefile access request generated in an application, the type of an operation performed on data by the target pagefile access request may also be determined, and if the target pagefile access request belongs to a target operation type, for example, a GET type, the target pagefile access request is intercepted, otherwise, the target pagefile access request is not intercepted and is directly responded by a remote server.

In a specific implementation, in the iOS system, in order to implement the above determination, a callback function + (boul) canInitWithRequest (nsurrequest) request of nsurroprotocol may be rewritten, and the method may determine whether to intercept the access request according to related information in the access request, where YES indicates that the request is intercepted, and NO indicates that the request is not intercepted. The specific process can be that firstly, whether the httpMethod method of the access request is GET is judged, YES is returned if GET is judged, and NO is returned if not GET. Then, according to the URL of the access request, whether the corresponding data content can be found in the offline data packet or not can be judged by calling a preset function. For convenience of introduction, the function may be named as loadcacheddaForURL, the entry parameter of the function is URL of the access request, the return value is NSData type, if the return value data is not null, it indicates that the local offline package has corresponding content, then the canInitWithRequest function return value is YES, the request is intercepted, if the return value data is null, it indicates that the local offline package does not have corresponding content, and the canInitWithRequest function return value is NO, the request is not intercepted, and the load is performed through the remote server.

Specifically, when the intra-packet configuration information is used to determine whether the target data content corresponding to the target URL information exists in the offline data packet, that is, whether an intra-packet relative path corresponding to the target URL exists in the intra-packet configuration information is determined, and if the intra-packet relative path exists, it is verified that the target data content corresponding to the target URL information exists in the offline data packet. If only one offline data packet is downloaded to the local disk, a physical path can be constructed according to the directory where the data packet is located and the relative path in the packet, and specific target data content can be acquired through the physical path.

If a plurality of offline data packets corresponding to a plurality of service modules exist, whether a target offline data packet corresponding to the target URL exists or not can be judged by using the global configuration information, and if the target offline data packet exists, whether target data content corresponding to the target URL information exists in the target offline data packet or not can be judged by using the intra-packet configuration information of the target offline data packet.

If the global configuration information only comprises the corresponding relation between the URL information of the HTML file access request and the identifier of the offline data packet where the corresponding data content is located, the identifier of the target offline data packet can be recorded after the identifier of the corresponding target offline data packet is determined according to the recently intercepted HTML file access request, and when other types of file access requests are hijacked, the target offline data packet corresponding to the other types of file access requests can be determined by using the recorded identifier of the target offline data packet; the other types of file access requests include CSS file access requests, JS file access requests, or picture file access requests.

If a single public offline data packet is provided for a common CSS file, a common JS file or a common picture file among different service modules, when a CSS file access request, a JS file access request or a picture file request is hijacked, the configuration information in the public packet is preferentially utilized to judge whether target data content corresponding to the target URL exists in the offline data packet or not.

Specifically, in the global configuration information, for the common offline data packet, a correspondence between the URL information of the CSS file, the JS file, or the picture file and the identifier of the corresponding data content in the common offline data packet may be recorded. And for the offline data packet corresponding to the specific service module, if only the corresponding relation between the URL information of the HTML file access request and the identifier of the offline data packet where the corresponding data content is located is included, when other types of file access requests are hijacked, firstly, whether the target data content corresponding to the target URL exists in the public offline data packet is judged by using the global configuration information, and if so, the corresponding target data content is obtained from the public offline data packet by using the configuration information in the public packet. If the target data content corresponding to the target URL does not exist in the public offline data packet, the target offline data packet identifier corresponding to the recorded recently intercepted HTML file access request can be located, and whether the target data content corresponding to the target URL exists in the target offline data packet or not is judged by utilizing the intra-packet configuration information in the target offline data packet.

In addition, in practice, loading a file from an offline data packet involves a large number of disk I/O operations, and it is found in practice that for a request of a static resource file (HTML/CSS/JS), for example, for the same HTML request, the canInitWithRequest function performs three I/O operations, and startload performs two I/O operations, so that the same HTML file involves five I/O requests. For the same JS/CSS resource file request, the CanInitWithrequest function and the startLoading function respectively execute one I/O operation, so that the same JS/CSS file has two I/O operations. Therefore, in the embodiment of the present application, an NSCache may be used, that is, after the first I/O read operation, the relevant data may be stored in the cache, and all subsequent read operations on the data are obtained from the cache, so that the I/O operation may be optimized to only one time, and all repeated I/O operations are optimized.

Specifically, if the hijacked target page file access request corresponds to a new page creation, that is, an HTML file access request (because all page access requests start from HTML file access), the target data content corresponding to the target URL and the intra-packet configuration information corresponding to the offline data packet in which the URL is located may be added to the cache. Therefore, when a new page file access request in the page is hijacked, whether corresponding data content exists in the cache can be judged according to the URL, if the corresponding data content exists, the page is proved to be accessed, and response data construction can be directly carried out by using the data content in the cache. If the cache does not have the corresponding data content, whether the intra-package configuration information corresponding to the URL exists in the cache can be judged, if so, whether the data content corresponding to the URL of the new page file access request exists in the isolated package can be judged by utilizing the intra-package configuration information in the cache, and if so, the data content is obtained from the offline data package in the disk and is added into the cache. When the created page is closed, the intra-package configuration information and the target data content related to the page in the cache can be released. Of course, since the same offline data packet corresponds to multiple pages, that is, when multiple pages are accessed, the in-packet configuration file of the offline data packet is used, so that when a page is closed, the in-packet configuration information in the cache and the page may not be released temporarily. Therefore, when all pages under the same offline data packet are accessed, I/O operation is executed only for the first time, and the subsequent operation can acquire the packet internal configuration information of the offline data packet from the cache.

In addition, for the global configuration file, since all the page file access requests need to be judged by using the global configuration file first, the global configuration file can be kept resident in the memory. During specific implementation, a singleton thread may be created, and the global configuration information is read into a memory through the singleton thread. The singleton thread is characterized in that the thread is not released along with the closing of the page, so that the global configuration information can be resident in the memory, and thus, when the global configuration information is used for judging whether a target offline data packet corresponding to the target URL exists, the global configuration information can be directly read from the memory, and the page loading time is further shortened.

S203: and if the target data content exists, intercepting the target page file access request, constructing page file access response data in a browser response simulating mode by using the target data content in the offline data packet, and returning the response data to a browser control built in the application.

If the data content corresponding to the current page file access request exists in the offline data packet, the target data content can be obtained, and the page file access response data is constructed in a browser response simulating mode by using the target data content in the offline data packet.

Specifically, when the target data content is obtained, the high-frequency offline data packet with high access frequency is carried in an installation package of the application, and when the application is opened for the first time, the high-frequency offline data packet is decompressed from the installation package and then stored in a specified directory (sandbox) of a local disk. Therefore, specifically, when the target data content corresponding to the target URL is acquired from the local disk, it may be first determined whether the offline data packet is decompressed, and if so, the physical address of the offline data packet is mapped to the specified directory, otherwise, the physical address of the offline data packet is mapped into the installation packet. Then, the determined offline data packet names and the relative paths in the packets are combined to be assembled into a physical absolute path, and specific data contents are acquired through the path.

If the low-frequency offline data packet with low access frequency is stored in the remote server, but the global configuration information contains the corresponding relationship between the URL and the low-frequency offline data packet, under the condition that the URL of the hijacked page file access request corresponds to the low-frequency offline data packet, whether the low-frequency offline data packet exists in the local disk can be judged firstly, if the low-frequency offline data packet does not exist, a download sub-thread can be started, the download sub-thread is used for downloading the low-frequency offline data packet according to the download address information and storing the low-frequency offline data packet into a specified directory of the local disk, then the data content corresponding to the hijacked page file access request is obtained from the low-frequency offline data packet included in the local directory of the local disk, and browser response data is constructed.

Specifically, when response data is constructed, the response data can be constructed in a mode of completely simulating real browser response, so that the response data obtained by the browser control is the same as the response data returned from the remote service, and therefore, the analysis and the rendering of various types of page files can be completely realized. In a specific implementation, if the page file access request is an HTTP request, HTTP response data may be constructed according to an HTTP protocol. The HTTP response data includes two parts, one part is a nsttpurlresponse (response header) for notifying the browser control of the type of the requested resource, the data length, and the requested URL, and the other part is data NSData representing the body content of the response data.

In this way, when constructing HTTP response data, an HTTP response header may be generated according to suffix information in the target URL and length information of corresponding target data content, then a response header may be constructed according to the target URL, the HTTP response header, an HTTP response status code (e.g., 200), and HTTP protocol version information (e.g., HTTP/1.1), and a response body may be constructed according to the target data content, and then the response header and the response body may be returned to a browser control built in the application. In this way, the browser control can perform a specific parsing rendering operation by using the response header and the response body.

In short, according to the embodiment of the present application, it is determined whether the corresponding target data content exists in the offline data packet for the access request of the page file of the type of HTML, CSS, JS, picture, and the like, so that even if the HTML file is in the offline data packet, if the JS file, CSS file, and the like included in the same H5 page are not in the offline data packet, a web page error does not occur. And then, if the target data content exists in the offline data packet, constructing response data by using the target data content in the offline data packet in a mode of completely simulating browser response, and returning the response data to the browser control built in the application for analyzing and rendering. During the period, operations such as virtual domain replacement and the like are not required, so that when the HTML request loaded from the offline data packet is completely supported, any parameter is transmitted to the browser control, and the JS request and the CSS request are not transmitted with the parameter, so that the offline data packet loading can be supported better. In summary, according to the embodiment of the application, loading from an offline data packet can be achieved for access requests of various types of files, and high robustness is achieved.

The above provides a plurality of implementation manners, and in practical application, a preferable implementation manner can be selected. For example, in one of the manners, a plurality of offline data packets may be provided according to a plurality of service modules in the App, there is a common offline data packet, and there is a lazy-loading offline data packet. In order to reduce the number of I/O, a cache mode is also adopted, data in the offline data packet (including configuration information in the packet and data content corresponding to a specific page file) can be written into the cache when being read and written for the first time, and the data content of the relevant page file can be released from the cache when the page exits. The configuration information in the packet may be released from the cache after each page associated with the offline data packet exits. The global configuration information may be read into the memory at the time of first use and may be resident in the memory. In this implementation manner, in specific implementation, referring to fig. 3, the page loading method provided in this embodiment of the present application may include the following steps:

s301, hijacking a page file access request in an application;

s302, judging the operation type of the requested file, entering S303 if the file belongs to a GET type, and otherwise, releasing the request and loading the request from a remote server;

s303, judging whether data content corresponding to the page file request exists in the cache, if so, directly obtaining the data content of the page file from the cache for constructing response data, otherwise, entering S304;

s304, judging whether a packet name and in-packet configuration information corresponding to the page file request exist in the cache, if so, indicating that an offline data packet corresponding to the page file is accessed, and entering S311, otherwise, indicating that the page file may not have a corresponding offline data packet or a corresponding offline datagram is not accessed, and acquiring related data content and in-packet configuration information from a local disk, and therefore, entering S305;

s305, according to the URL of the page file request, inquiring global configuration information in a memory, judging whether the name of an offline data packet corresponding to the URL is empty, if so, proving that the page file may not be in the offline data packet, or the page file access request may be a CSS, JS or picture request instead of an HTML request, and at this moment, entering S311; otherwise, if not, entering S306;

s306, determining a local physical address of the offline data packet;

s307, judging whether the local physical address has a corresponding offline data packet file, if not, entering a lazy loading mode and being located in a remote server, and thus, entering S311; if so, go to S308;

s308, acquiring configuration information in the package, judging whether the data content corresponding to the URL of the current page file access request is empty according to the configuration information in the package, and if the data content is empty, proving that no local data content corresponding to the page file exists, so that a null value can be returned, the request can be released, and the data can be loaded from a remote server; if not, go to S309;

s309, replacing the recorded packet name corresponding to the latest hijacking request and the in-packet configuration information to determine the off-line data packet name and the in-packet configuration information corresponding to the subsequent hijacking CSS, JS and picture access request;

the step is to solve the problem that the JS/CSS request cannot hit the regular expression, and when the new offline data packet and the configuration information in the packet are obtained through the steps, it is described that a new page may be accessed next, so that a replacement operation may be performed to map the new JS/CSS request to the new offline data packet.

When the public offline data packet exists, the public offline data packet only contains the data content of JS/CSS which is commonly used by each module, so that when a new offline data packet and configuration information in the packet are obtained, the type of the new offline data packet can be judged, if the new offline data packet is the public data packet, the next access to a new page cannot be proved, and therefore, the replacement operation does not need to be executed.

S310, writing the replaced packet name and the configuration information in the packet into a cache, and entering S311;

s311, determining a physical absolute path of the data content;

for the HTML first request, when it comes to this step, it is said that the package name and the in-package configuration information have been obtained, and for the JS/CSS request, because HTML is requested first, the above contents have been saved in step S309, and in any case, when it comes to this, the package name and the in-package configuration information are present. The physical address of the offline data packet can be obtained according to the packet name by using a preset function, the relative path of the corresponding file can be obtained according to a configuration information (abc. json) mapping table in the packet, and the offline data packet address + the relative path are the final absolute path of the file corresponding to the URL.

In addition, a special processing may be performed for the URL request mapped to the common packet, because no replacement operation is performed for the common packet in step S309, that is, the abc.

S312, judging whether the data content corresponding to the physical absolute path exists or not, if not, returning to be empty, further releasing the request, and loading from the remote server, otherwise, entering S313;

and S313, obtaining the content of the offline data and establishing response data.

After the data content of the offline file is acquired by reading the local offline package, the data content can be stored in the cache NScache, and when the same URL request is subsequently received, the data can be directly acquired from the memory without executing the disk reading operation or the steps.

In the first case, the packet name and the configuration information in the packet can be obtained from the cache, which indicates that the offline data packet requested by the current URL is being accessed; in the second case, the offline data packet name corresponding to the URL cannot be obtained, and the URL request may be JS, CSS, or picture request, and the packet name cannot be obtained according to the regular expression of H5CacheList in step 5; in the third case, both the package name and the package configuration content are available, which indicates that this is an HTML request and is the first request to read the disk to obtain the data content. In each case, the specific manner of determining the physical absolute path may refer to the description in the foregoing, and in addition, regarding the related processing manners such as the lazy loading mode and the common offline data packet, the description in the foregoing may also refer to the description, and details are not described here again.

In order to more intuitively determine the effect obtained by the embodiment of the present application in terms of page loading time, the inventor of the present application selects the above preferred implementation and implements the implementation in the Taobao travel client. Fig. 4 is statistical data of a comparative test using the preferred implementation described above, wherein the ordinate represents the loading time. In the test, statistics are performed on 20 key pages of the ali travel client, and the test result shows that, by using the page loading scheme provided by the embodiment of the application, the average loading time of each page is 0.352s (only the comparison results of some key pages are shown in the figure, including the list page of the international air ticket, the single page under the international air ticket, and the like). If the page loading scheme of the embodiment of the application is not used, the statistical page average loading time is 1.423s, and therefore, the page loading speed is improved by about 4 times.

Corresponding to the page loading processing method provided in the embodiment of the present application, an embodiment of the present application further provides a page loading processing apparatus, where, referring to fig. 5, the apparatus may include:

an offline data packet providing unit 501, configured to provide an offline data packet, where the offline data packet includes configuration information in the packet and multiple data contents, each data content corresponds to a page file to be accessed, the page file includes a hypertext markup language HTML file, a cascading style sheet CSS file, a JS file, or a picture file, and the configuration information in the packet includes a correspondence between URL information used for accessing each page file and relative path information of the data contents in the packet;

a determining unit 502, configured to hijack a target page file access request generated in an application, determine target URL information of the target page file access request, and determine whether the offline data packet has target data content corresponding to the target URL information by using configuration information in the packet; the target page file access request comprises an HTML file access request, a CSS file access request, a JS file access request or a picture file access request;

a response data constructing unit 503, configured to intercept the target page file access request if the target data content exists, construct page file access response data in a browser response simulation manner by using the target data content in the offline data packet, and return the response data to a browser control built in the application.

The offline data packet providing unit 501 is specifically configured to:

providing a plurality of offline data packets according to a plurality of service modules included in the application, wherein each offline data packet corresponds to a page file to be accessed in the same service module, and each offline data packet corresponds to respective configuration information in the packet;

at this time, the apparatus further includes:

the global configuration information providing unit is used for providing global configuration information, and the global configuration information comprises a corresponding relation between URL information and an identifier of an offline data packet where corresponding data content is located;

correspondingly, the judging unit comprises:

the first judgment subunit is configured to judge whether a target offline data packet corresponding to the target URL exists or not by using the global configuration information;

and a second judging subunit, configured to, if the target data content exists, judge, by using the in-packet configuration information of the target offline data packet, whether the target data content corresponding to the target URL information exists in the target offline data packet.

Wherein, the global configuration information only includes the corresponding relation between the URL information of the HTML file access request and the identifier of the offline data packet where the corresponding data content is located, the device further includes:

the recording unit is used for recording a target offline data packet identifier after determining the corresponding target offline data packet identifier according to the recently intercepted HTML file access request;

the target offline data packet determining unit is used for determining a target offline data packet corresponding to the other type of file access request by using the recorded target offline data packet identifier when the other type of file access request is hijacked; the other types of file access requests include CSS file access requests, JS file access requests, or picture file access requests.

In a specific implementation, the offline data packet providing unit is specifically configured to:

providing an independent public offline data packet for a common CSS file, a common JS file or a common picture file among different service modules, wherein the public offline data packet comprises public in-packet configuration information and a plurality of data contents, each data content corresponds to one CSS file, each JS file or each picture file, and the public in-packet configuration information comprises a corresponding relation between URL information and corresponding path information of the data contents in the packet;

the judgment unit is specifically configured to:

and when the CSS file access request, the JS file access request or the picture file request is hijacked, preferentially utilizing the configuration information in the public packet to judge whether the target data content corresponding to the target URL exists in the offline data packet.

In the global configuration information, only the corresponding relation between the URL information of the HTML file access request and the identifier of the offline data packet where the corresponding data content is located is included for the offline data packet corresponding to the specific service module, and the corresponding relation between the URL information of the CSS file, the JS file or the picture file and the identifier of the corresponding data content in the public offline data packet is included for the public offline data packet;

the judging unit includes:

the recording subunit is used for recording the target offline data packet identifier after determining the corresponding target offline data packet identifier according to the recently intercepted HTML file access request;

a third determining subunit, configured to determine, when another type of file access request is hijacked, whether target data content corresponding to the target URL exists in the public offline data packet by using the global configuration information, and if so, obtain, from the public offline data packet, corresponding target data content by using the configuration information in the public packet; the other types of file access requests comprise CSS file access requests, JS file access requests or picture file access requests;

and the positioning subunit is configured to, if there is no target data content corresponding to the target URL in the public offline data packet, position a target offline data packet identifier corresponding to the recorded recently intercepted HTML file access request, and determine, by using intra-packet configuration information in the target offline data packet, whether there is target data content corresponding to the target URL in the target offline data packet.

In a specific implementation, the apparatus may further include:

and the singleton thread creating unit is used for creating singleton threads and reading the global configuration information into the memory through the singleton threads, wherein the singleton threads are not released along with the closing of the page so as to reside the global configuration information in the memory, and when the target offline data packet corresponding to the target URL is judged to exist or not by using the global configuration information, the global configuration information is read from the memory.

The low-frequency offline data packet with low access frequency is stored in a remote server, but the global configuration information comprises the corresponding relation between the URL and the low-frequency offline data packet, and the download address information of the low-frequency offline data packet is stored;

the device further comprises:

the local judgment unit is used for judging whether the low-frequency offline data packet exists in a local disk or not if the URL of the hijacked page file access request corresponds to the low-frequency offline data packet;

the downloading unit is used for starting a downloading sub-thread if the low-frequency off-line data packet does not exist, and the downloading sub-thread is used for downloading the low-frequency off-line data packet according to the downloading address information and storing the low-frequency off-line data packet into a specified directory of a local disk;

and the data content acquisition unit is used for acquiring the data content corresponding to the hijacked page file access request from the low-frequency offline data packet in the local disk local directory and constructing browser response data.

Carrying a high-frequency offline data packet with high access frequency in an installation package of an application, decompressing the high-frequency offline data packet from the installation package and storing the high-frequency offline data packet to a specified directory of a local disk when the application is opened for the first time;

the device further comprises:

and the physical address mapping unit is used for judging whether the offline data packet is decompressed when target data content corresponding to the target URL is acquired from the local disk, if so, mapping the physical address of the offline data packet to the specified directory, and otherwise, mapping the physical address of the offline data packet to the installation packet.

The URL information stored in the intra-package configuration information and the global configuration information is relative path information in a URL for accessing the page file; and when judging whether the target data content corresponding to the target URL exists, matching the relative path information in the target URL with the global configuration information and the intra-package configuration information.

In addition, the apparatus may further include:

the cache unit is used for adding target data content corresponding to the target URL and corresponding in-package configuration information of the offline data package into a cache if the target page file access request corresponds to the creation of a new page;

the cache data judgment unit is used for judging whether corresponding data content exists in the cache according to the URL when a new page file access request in the page is hijacked, and if the corresponding data content exists in the cache, response data construction is carried out by using the data content in the cache;

the cache configuration information judging unit is used for judging whether the data content corresponding to the URL of the new page file access request exists in the offline package or not by utilizing the intra-package configuration information in the cache if the corresponding data content does not exist in the cache, and acquiring the data content from the offline data package in the disk and adding the data content into the cache if the data content exists in the offline package;

and the cache releasing unit is used for releasing the content related to the page in the cache when the created page is closed.

During specific implementation, a user-defined protocol class can be generated by inheriting a preset protocol class provided by a system in advance and rewriting key functions therein, and the user-defined protocol class is registered when an application is opened, so that a target page file access request generated in the application is intercepted by using the user-defined protocol class.

In addition, the apparatus may further include:

the operation type determining unit is used for determining the operation type of data execution of a target page file access request before intercepting the target page file access request generated in the application;

and the interception triggering unit is used for triggering the interception of the target page file access request if the target page file access request belongs to the target operation type.

In a specific implementation, the target pagefile access request includes an HTTP request, and the response data constructing unit includes:

a response header generation subunit, configured to generate an HTTP response header according to suffix information in the target URL and length information of the corresponding target data content;

the response head construction subunit is used for constructing a response head according to the target URL, the HTTP response head, the HTTP response state code and the HTTP protocol version information;

the response body construction subunit is used for constructing a response body according to the target data content;

and the data returning subunit is used for returning the response head and the response body to the browser control built in the application.

From the above description of the embodiments, it is clear to those skilled in the art that the present application can be implemented by software plus necessary general hardware platform. Based on such understanding, the technical solutions of the present application may be essentially or partially implemented in the form of a software product, which may be stored in a storage medium, such as a ROM/RAM, a magnetic disk, an optical disk, etc., and includes several instructions for enabling a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the method according to the embodiments or some parts of the embodiments of the present application.

The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, the system or system embodiments are substantially similar to the method embodiments and therefore are described in a relatively simple manner, and reference may be made to some of the descriptions of the method embodiments for related points. The above-described system and system embodiments are only illustrative, wherein the units described as separate parts may or may not be physically separate, and the parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of the present embodiment. One of ordinary skill in the art can understand and implement it without inventive effort.

The page loading processing method and device provided by the present application are introduced in detail, and a specific example is applied in the text to explain the principle and the implementation of the present application, and the description of the above embodiment is only used to help understanding the method and the core idea of the present application; meanwhile, for a person skilled in the art, according to the idea of the present application, the specific embodiments and the application range may be changed. In view of the above, the description should not be taken as limiting the application.

Claims

1. A page loading processing method is characterized by comprising the following steps:

providing an offline data packet, wherein the offline data packet comprises configuration information in the packet and a plurality of data contents, each data content corresponds to a page file to be accessed, and the configuration information in the packet comprises a corresponding relation between Uniform Resource Locator (URL) information for accessing each page file and relative path information of the data contents in the packet; the providing of the offline data packet includes: providing a plurality of offline data packets according to a plurality of service modules included in the application, wherein each offline data packet corresponds to a page file to be accessed in the same service module, and each offline data packet corresponds to respective configuration information in the packet;

if the target data content exists, intercepting the target page file access request, constructing page file access response data in a browser response simulating mode by using the target data content in the offline data packet, and returning the response data to a browser control built in the application;

wherein the method further comprises:

and providing global configuration information, wherein the global configuration information comprises the corresponding relation between the URL information and the identification of the offline data packet where the corresponding data content is located.

2. The method of claim 1,

the page file comprises a hypertext markup language (HTML) file, a Cascading Style Sheet (CSS) file, a JS file or a picture file;

the target page file access request comprises an HTML file access request, a CSS file access request, a JS file access request or a picture file access request.

3. The method according to claim 1, wherein the determining whether the offline data packet has target data content corresponding to the target URL information by using the intra-packet configuration information includes:

judging whether a target offline data packet corresponding to the target URL information exists or not by using the global configuration information;

if the target data content exists, judging whether the target data content corresponding to the target URL information exists in the target offline data packet or not by using the in-packet configuration information of the target offline data packet.

4. The method of claim 3, wherein the global configuration information only includes a correspondence between the URL information of the HTML file access request and an identifier of an offline data packet in which the corresponding data content is located, and the method further comprises:

after determining a corresponding target offline data packet identifier according to a recently intercepted HTML file access request, recording the target offline data packet identifier;

when other types of file access requests are hijacked, determining target offline data packets corresponding to the other types of file access requests by using the recorded target offline data packet identifiers; the other types of file access requests include CSS file access requests, JS file access requests, or picture file access requests.

5. The method of claim 3, wherein providing the offline data packet comprises:

the determining whether the offline data packet has target data content corresponding to the target URL information by using the configuration information in the packet includes:

6. The method according to claim 5, wherein the global configuration information only includes, for the offline data packet corresponding to the specific service module, a correspondence between the URL information of the HTML file access request and the identifier of the offline data packet in which the corresponding data content is located, and includes, for the common offline data packet, a correspondence between the URL information of the CSS file, the JS file, or the picture file and the identifier of the corresponding data content in the common offline data packet;

the preferentially utilizing the configuration information in the public packet to judge whether the target data content corresponding to the target URL exists in the offline data packet or not comprises the following steps:

when other types of file access requests are hijacked, whether target data content corresponding to the target URL exists in the public off-line data packet or not is judged by using the global configuration information, and if the target data content exists, the corresponding target data content is obtained from the public off-line data packet by using the configuration information in the public packet; the other types of file access requests comprise CSS file access requests, JS file access requests or picture file access requests;

if the target data content corresponding to the target URL does not exist in the public offline data packet, locating the target offline data packet identifier corresponding to the recorded recently intercepted HTML file access request, and judging whether the target offline data packet has the target data content corresponding to the target URL or not by utilizing the in-packet configuration information in the target offline data packet.

7. The method of claim 3, further comprising:

creating a singleton thread, and reading the global configuration information into a memory through the singleton thread, wherein the singleton thread is not released along with closing of a page so as to reside the global configuration information in the memory, and when the singleton thread is used for judging whether a target offline data packet corresponding to the target URL exists, the global configuration information is read from the memory.

8. The method according to claim 3, wherein the low frequency offline data package with low access frequency is stored in a remote server, but the global configuration information includes a corresponding relationship between a URL and the low frequency offline data package, and stores download address information of the low frequency offline data package;

the method further comprises the following steps:

if the URL of the hijacked page file access request corresponds to the low-frequency offline data packet, judging whether the low-frequency offline data packet exists in a local disk;

if the low-frequency offline data packet does not exist, starting a downloading sub-thread, wherein the downloading sub-thread is used for downloading the low-frequency offline data packet according to the downloading address information and storing the low-frequency offline data packet into a specified directory of a local disk;

and acquiring data content corresponding to the hijacked page file access request from the low-frequency offline data packet in the local disk local directory, and constructing browser response data.

9. The method according to claim 3, wherein the high-frequency offline data packet with high access frequency is carried in an installation package of the application, and when the application is opened for the first time, the high-frequency offline data packet is decompressed from the installation package and then stored in a specified directory of a local disk;

when the target data content corresponding to the target URL is acquired from the local disk, the method comprises the following steps:

and judging whether the offline data packet is decompressed, if so, mapping the physical address of the offline data packet to the specified directory, and otherwise, mapping the physical address of the offline data packet to the installation packet.

10. The method according to claim 3, wherein the URL information stored in the intra-package configuration information and the global configuration information is relative path information in a URL for accessing a page file; and when judging whether the target data content corresponding to the target URL exists, matching the relative path information in the target URL with the global configuration information and the intra-package configuration information.

11. The method of any one of claims 1 to 10, further comprising:

if the target page file access request corresponds to new page creation, adding target data content corresponding to the target URL information and corresponding intra-package configuration information of the offline data package into a cache;

when a new page file access request in the target page file is hijacked, judging whether corresponding data content exists in a cache or not according to the URL, and if so, constructing response data by using the data content in the cache;

if the cache does not have corresponding data content, judging whether data content corresponding to the URL of the new page file access request exists in the offline package or not by utilizing the intra-package configuration information in the cache, and if so, acquiring the data content from the offline data package in the disk and adding the data content into the cache;

and when the created page is closed, releasing the content related to the created page in the cache.

12. The method according to any one of claims 1 to 10, wherein a custom protocol class is generated by inheriting a preset protocol class provided by a system in advance and rewriting key functions therein, and the custom protocol class is registered when an application is opened, so that a target pagefile access request generated in the application is intercepted by using the custom protocol class.

13. The method according to any one of claims 1 to 10, further comprising, before intercepting a target pagefile access request generated in an application:

determining the operation type of the target page file access request on data;

and if the target operation type is the target operation type, intercepting the target page file access request.

14. The method of any one of claims 1 to 10, wherein the target pagefile access request comprises an HTTP request, wherein the response data comprises an HTTP response, and wherein constructing the pagefile access response data by simulating a browser response comprises:

generating an HTTP response head according to suffix information in the target URL information and length information of corresponding target data content;

constructing a response head according to the target URL information, the HTTP response head, the HTTP response state code and the HTTP protocol version information;

constructing a response body according to the target data content;

and returning the response head and the response body to the browser control built in the application.

15. A page load processing apparatus, comprising:

the off-line data package providing unit is used for providing an off-line data package, the off-line data package comprises in-package configuration information and a plurality of data contents, each data content corresponds to a page file to be accessed, and the in-package configuration information comprises a corresponding relation between Uniform Resource Locator (URL) information used for accessing each page file and relative path information of the data contents in the package; the offline data packet providing unit is specifically configured to: providing a plurality of offline data packets according to a plurality of service modules included in the application, wherein each offline data packet corresponds to a page file to be accessed in the same service module, and each offline data packet corresponds to respective configuration information in the packet;

a response data construction unit, configured to intercept the target page file access request if the target data content exists, construct page file access response data in a browser response simulation manner by using the target data content in the offline data packet, and return the response data to a browser control built in the application;

the global configuration information only includes the corresponding relation between the URL information of the HTML file access request and the identification of the offline data packet where the corresponding data content is located.

16. The apparatus of claim 15, further comprising:

the judging unit includes:

17. The apparatus of claim 16, further comprising:

18. The apparatus according to claim 17, wherein the offline packet providing unit is specifically configured to:

the judgment unit is specifically configured to:

and when a CSS file access request, a JS file access request or a picture file request is hijacked, preferentially utilizing the configuration information in the public packet to judge whether target data content corresponding to the target URL information exists in the offline data packet.

19. The apparatus according to claim 18, wherein the global configuration information includes, for the offline data packet corresponding to the specific service module, only a correspondence between URL information of an HTML file access request and an identifier of the offline data packet where the corresponding data content is located, and for the common offline data packet, includes a correspondence between URL information of a CSS file, a JS file, or a picture file and an identifier of the corresponding data content in the common offline data packet;

the judging unit includes:

20. The apparatus of claim 16, further comprising:

21. The apparatus of claim 16, wherein the low frequency offline data packet with low access frequency is stored in a remote server, but the global configuration information includes a correspondence between a URL and the low frequency offline data packet, and stores download address information of the low frequency offline data packet;

the device further comprises: