CN113656720A

CN113656720A - Page display method and device, electronic equipment and storage medium

Info

Publication number: CN113656720A
Application number: CN202110982543.8A
Authority: CN
Inventors: 左景龙; 宗小斌
Original assignee: Beijing Dajia Internet Information Technology Co Ltd
Current assignee: Beijing Dajia Internet Information Technology Co Ltd
Priority date: 2021-08-25
Filing date: 2021-08-25
Publication date: 2021-11-16
Anticipated expiration: 2041-08-25
Also published as: CN113656720B

Abstract

The disclosure relates to a page display method and device, electronic equipment and a storage medium, relates to the technical field of computers, and aims to solve the problem that the loading speed of a page in the related art is low. The disclosed method comprises the following steps: when a page to be displayed is opened, locally acquiring a bytecode corresponding to a target script of the cached page to be displayed, wherein the bytecode is obtained by pre-compiling all script contents contained in the target script when the client is in an idle state, or the bytecode is obtained by compiling part of script contents operated in the target script when the target script is operated for the first time; and displaying the page to be displayed based on the byte codes. Because the byte codes in the method and the device are compiled in advance when the idle state or the script runs for the first time, when the client opens the page to be displayed, the client does not need to compile again, the compiling time is saved, and the page loading speed can be effectively improved.

Description

Page display method and device, electronic equipment and storage medium

Technical Field

The present disclosure relates to the field of computer technologies, and in particular, to a page display method and apparatus, an electronic device, and a storage medium.

Background

Along with the rapid development of science and technology, people using intelligent terminal equipment are more and more. Taking a mobile phone as an example, browsing a webpage through a mobile phone browser to obtain information has become a part of people's daily life. With the popularization of HTML5(HyperText Markup Language 5.0, fifth edition of HyperText Markup Language, H5 for short), the experience of a mobile phone browser is better and better, and the use frequency is higher and higher.

When a user browses an H5 page, a JavaScript (Java script) source code needs to be analyzed and compiled through a V8 engine, and the JavaScript source code is converted into binary byte codes used by a JavaScript virtual machine. And the JavaScript virtual machine on the browser executes the corresponding binary byte codes. Therefore, how to reduce the JavaScript script compiling time and accelerate the loading process of the H5 page is a critical solution.

Disclosure of Invention

The disclosure provides a page display method, a page display device, an electronic device and a storage medium, which are used for at least solving the problem of slow loading speed of a page in the related art. The technical scheme of the disclosure is as follows:

according to a first aspect of the embodiments of the present disclosure, there is provided a first page display method, including:

when a page to be displayed is opened, locally acquiring a bytecode corresponding to a target script of the cached page to be displayed, wherein the bytecode is obtained by pre-compiling all script contents contained in the target script when the client is in an idle state, or the bytecode is obtained by compiling part of script contents operated in the target script when the target script is operated for the first time;

and displaying the page to be displayed based on the byte codes.

Optionally, if the bytecode is obtained by pre-compiling all script contents included in the target script when the client is in an idle state, caching the bytecode to at least one of a memory and a disk;

if the bytecode is obtained by compiling part of script content operated in the target script when the target script is operated for the first time, caching the bytecode into a disk.

Optionally, if the page to be displayed is a page whose access times are greater than a preset threshold, the bytecode is obtained by performing pre-compilation on all script contents included in the target script when the client is in an idle state.

Optionally, if the bytecode is obtained by compiling a part of script content running in the target script when the target script is run for the first time; before the obtaining the cached bytecode corresponding to the target script of the page to be displayed from the local place when the page to be displayed is opened, the method further includes:

when the target script is operated for the first time, whether the local part contains byte codes corresponding to the target script is inquired;

and if the local area does not contain the byte codes corresponding to the target script, compiling and caching partial script contents operated in the target script.

Optionally, the compiling and caching the partial script content running in the target script includes:

compiling part of script contents running in the target script to obtain byte codes corresponding to the compiled parts;

and in the process of compiling part of script contents running in the target script, performing associated storage on the bytecode corresponding to the compiled part and the script identifier corresponding to the target script through at least one sub-thread.

Optionally, the obtaining the cached bytecode corresponding to the target script of the page to be displayed from the local includes:

acquiring a script identifier corresponding to the target script, wherein the script identifier is obtained by performing hash operation on the target script, or the script identifier is a network address or a file path corresponding to the target script;

and acquiring a cached bytecode corresponding to the script identifier from a local cache, wherein the bytecode and the script identifier are stored in the local cache in an associated manner.

Optionally, the method further includes:

inquiring whether a server stores the bytecode corresponding to the target script;

and if the server is determined not to store the bytecode corresponding to the target script, locally acquiring the cached bytecode corresponding to the target script of the page to be displayed.

Optionally, the querying whether the server stores the bytecode corresponding to the target script includes:

sending a query request aiming at the page to be displayed to the server so that the server acquires a bytecode corresponding to the target script according to the query request, wherein the bytecode is obtained by compiling all script contents contained in the target script by the server;

and if the bytecode returned by the server is not received within the set time length, determining that the bytecode corresponding to the target script is not stored in the server.

Optionally, the method further includes:

if the server is determined to store the bytecode corresponding to the target script, acquiring the bytecode returned by the server;

and executing the bytecode returned by the server, and displaying the page to be displayed according to an execution result.

Optionally, before the displaying the page to be displayed based on the bytecode, the method further includes:

sending a query request aiming at the page to be displayed to a server so that the server acquires a bytecode corresponding to the target script according to the query request, wherein the bytecode is obtained by compiling all script contents contained in the target script by the server;

receiving the bytecode returned by the server;

combining the bytecode returned by the server with the locally acquired bytecode to obtain a combined bytecode;

the displaying the page to be displayed based on the bytecode includes:

and executing the merged byte codes, and displaying the page to be displayed according to an execution result.

Optionally, before the combining the bytecode returned by the server with the locally obtained bytecode to obtain a combined bytecode, the method further includes:

comparing the bytecode returned by the server with the locally acquired bytecode to acquire a comparison result;

determining that the comparison result meets a merging condition, wherein the merging condition is as follows: the bytecode returned by the server is inconsistent with the locally acquired bytecode.

Optionally, the method further includes:

and if the comparison result is determined not to meet the merging condition, executing the byte codes returned by the server, and displaying the page to be displayed according to the execution result.

if the page to be displayed is a page with the access times larger than a preset threshold value, locally acquiring byte codes obtained by pre-compiling all script contents contained in the target script;

if the target script is a specified type script, locally acquiring a bytecode obtained by compiling part of script content running in the target script, wherein the specified type script comprises an inline script, a script with a byte length smaller than a set value, and at least one of scripts injected by a developer.

Optionally, the method further includes:

and if the page to be displayed is a page maintained by the server, acquiring the byte code corresponding to the target script of the page to be displayed from the server.

In the above embodiment, when the client is in the idle state, the target script of the page to be displayed can be pre-compiled and cached in advance; therefore, when a user browses the page to be displayed by using the client, the client can directly read the byte codes obtained by compiling before from the cache, and the page to be displayed is displayed based on the byte codes; or, the client may also compile the content of the script part that runs this time when the target script runs for the first time, so that when the user browses the page to be displayed next time by using the client, the corresponding bytecode may be directly read from the cache, and the page to be displayed is displayed based on the bytecode. In the two modes, the client does not need to compile the script content again, so that the compiling time is saved, and the page loading speed can be effectively improved.

According to a second aspect of the embodiments of the present disclosure, a second page display method is provided, including:

receiving a query request aiming at a page to be displayed and sent by a client, and acquiring a bytecode corresponding to a target script of the page to be displayed according to the query request, wherein the query request is sent when the client detects that the page to be displayed is opened;

and returning the byte codes to the client so that the client displays the page to be displayed based on the byte codes, wherein the byte codes are obtained by compiling all script contents contained in the target script.

Optionally, the obtaining, according to the query request, the bytecode corresponding to the target script of the page to be displayed includes:

acquiring a script identifier corresponding to the target script according to the query request, wherein the script identifier is obtained by performing hash operation on the target script, or the script identifier is a network address or a file path corresponding to the target script;

and acquiring the byte code corresponding to the script identifier.

In the embodiment, the server compiles the target script of the page to be displayed, so that when the client needs to display the page to be displayed, only the query request needs to be sent to the server, the server queries the bytecode obtained by compiling and returns the bytecode to the client, and then the client displays the page based on the bytecode returned by the server. In this way, the client directly runs the bytecode issued by the server when running the script, and the page loading speed can be effectively increased.

According to a third aspect of the embodiments of the present disclosure, there is provided a third page display method, including:

when a page to be displayed is opened, sending a query request aiming at the page to be displayed to a server so that the server obtains a bytecode corresponding to a target script of the page to be displayed according to the query request, wherein the bytecode is obtained by compiling all script contents contained in the target script by the server;

receiving the bytecode returned by the server;

and displaying the page to be displayed based on the byte codes.

Optionally, before the query request for the page to be displayed, sent to the server, the method further includes:

inquiring whether the bytecode corresponding to the target script is stored locally;

and if the bytecode corresponding to the target script is not locally stored, acquiring the cached bytecode corresponding to the target script of the page to be displayed from the server.

Optionally, if it is determined that the bytecode corresponding to the target script is locally stored, the bytecode is obtained by compiling in at least one of the following ways:

when the target script is in an idle state, pre-compiling all script contents contained in the target script to obtain the byte codes;

and compiling partial script contents operated in the target script to obtain the byte codes when the target script is operated for the first time.

According to a fourth aspect of the embodiments of the present disclosure, there is provided a page displaying apparatus, including:

the system comprises an acquisition unit, a storage unit and a display unit, wherein the acquisition unit is configured to execute a bytecode corresponding to a target script of a cached page to be displayed when the page to be displayed is opened, wherein the bytecode is obtained by pre-compiling all script contents contained in the target script when a client is in an idle state, or is obtained by compiling part of script contents running in the target script when the target script is run for the first time;

and the display unit is configured to display the page to be displayed based on the byte codes.

Optionally, the bytecode is obtained by compiling a part of script content running in the target script when the target script is run for the first time; the device further comprises:

the compiling unit is configured to execute whether the local bytecode corresponds to the target script or not when the target script is operated for the first time before the obtaining unit obtains the bytecode corresponding to the target script of the cached page to be displayed from the local when the page to be displayed is opened;

Optionally, the compiling unit is specifically configured to perform:

Optionally, the obtaining unit is specifically configured to perform:

Optionally, the obtaining unit is further configured to perform:

Optionally, the obtaining unit is specifically configured to perform:

Optionally, the obtaining unit is further configured to perform:

before the display unit displays the page to be displayed based on the bytecode, sending a query request aiming at the page to be displayed to a server so that the server obtains the bytecode corresponding to the target script according to the query request, wherein the bytecode is obtained by compiling all script contents contained in the target script by the server;

receiving the bytecode returned by the server;

the presentation unit is specifically configured to perform:

Optionally, the obtaining unit is further configured to perform:

comparing the bytecode returned by the server with the locally acquired bytecode to acquire a comparison result before merging the bytecode returned by the server with the locally acquired bytecode to acquire the merged bytecode;

Optionally, the presentation unit is further configured to perform:

Optionally, the obtaining unit is specifically configured to perform:

Optionally, the obtaining unit is further configured to perform:

According to a fifth aspect of the embodiments of the present disclosure, there is provided a second page displaying apparatus, including:

the query unit is configured to execute and receive a query request aiming at a page to be displayed and sent by a client, and acquire a bytecode corresponding to a target script of the page to be displayed according to the query request, wherein the query request is sent when the client detects that the page to be displayed is opened;

and the feedback unit is configured to return the bytecode to the client so that the client displays the page to be displayed based on the bytecode, wherein the bytecode is obtained by compiling all script contents contained in the target script.

Optionally, the query unit is specifically configured to perform:

and acquiring the byte code corresponding to the script identifier.

According to a sixth aspect of the embodiments of the present disclosure, there is provided a page displaying apparatus, including:

the system comprises an acquisition unit, a display unit and a display unit, wherein the acquisition unit is configured to send a query request aiming at a page to be displayed to a server when the page to be displayed is opened so that the server acquires a bytecode corresponding to a target script of the page to be displayed according to the query request, and the bytecode is obtained by compiling all script contents contained in the target script by the server;

the receiving unit is configured to execute receiving of the bytecode returned by the server;

Optionally, the obtaining unit is further configured to perform:

before a query request aiming at the page to be displayed is sent to a server, whether a bytecode corresponding to the target script is stored locally is queried;

Optionally, if it is determined that the bytecode corresponding to the target script is locally stored, the obtaining unit is further configured to perform compiling in at least one of the following ways to obtain the bytecode:

According to a seventh aspect of the embodiments of the present disclosure, there is provided an electronic apparatus including:

a processor;

a memory for storing the processor-executable instructions;

wherein the processor is configured to execute the instructions to implement the page presentation method of any one of the first aspect to the third aspect of the embodiments of the present disclosure.

According to an eighth aspect of the embodiments of the present disclosure, there is provided a non-volatile readable storage medium, where instructions of the storage medium, when executed by a processor of an electronic device, enable the electronic device to perform the page display method of any one of the first to third aspects of the embodiments of the present disclosure.

According to a ninth aspect of the embodiments of the present disclosure, there is provided a computer program product, which, when run on an electronic device, causes the electronic device to execute a method that may be involved in implementing any of the above first to third aspects and the first to third aspects of the embodiments of the present disclosure.

According to a tenth aspect of the embodiments of the present disclosure, there is provided a page display system, including:

the client is used for sending a query request aiming at the page to be displayed to the server when the page to be displayed is opened; if the server is determined not to store the bytecode corresponding to the target script, locally acquiring the cached bytecode corresponding to the target script of the page to be displayed, and displaying the page to be displayed based on the bytecode; if the server is determined to store the bytecode corresponding to the target script, acquiring the bytecode returned by the server; displaying the page to be displayed based on the byte codes returned by the server; the locally acquired bytecode is obtained by pre-compiling all script contents contained in the target script when the client is in an idle state, or is obtained by compiling part of script contents operated in the target script when the target script is operated for the first time;

the server is used for receiving a query request aiming at the page to be displayed and sent by the client, and acquiring the bytecode corresponding to the target script of the page to be displayed according to the query request; and returning the bytecode to the client, wherein the bytecode returned by the server is obtained by compiling all script contents contained in the target script.

Optionally, the client is specifically configured to:

executing the bytecode returned by the server, and displaying the page to be displayed according to an execution result; or

Combining the bytecode returned by the server with the locally acquired bytecode to obtain a combined bytecode; and executing the merged byte codes, and displaying the page to be displayed according to an execution result.

According to an eleventh aspect of the embodiments of the present disclosure, there is provided a page display system, including:

the client is used for sending a query request aiming at the page to be displayed to the server when the page to be displayed is opened; receiving the bytecode returned by the server; displaying the page to be displayed based on the byte codes;

the server is used for receiving a query request aiming at the page to be displayed and sent by the client, and acquiring the bytecode corresponding to the target script of the page to be displayed according to the query request; and returning the byte code to the client, wherein the byte code is obtained by compiling all script contents contained in the target script.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present disclosure and, together with the description, serve to explain the principles of the disclosure and are not to be construed as limiting the disclosure.

Fig. 1A is a schematic diagram of a first isolation cache method in the related art;

FIG. 1B is a diagram illustrating a second isolation buffer method in the related art;

FIG. 1C is a diagram illustrating a third isolation buffer method in the related art;

FIG. 2 is a schematic diagram illustrating a site isolation mechanism in accordance with an exemplary embodiment;

fig. 3A is a schematic diagram of a first resource caching method in the related art;

fig. 3B is a diagram illustrating a second resource caching method in the related art;

fig. 3C is a diagram illustrating a third resource caching method in the related art;

FIG. 4 is a flowchart illustrating a first page presentation method in accordance with an exemplary embodiment;

FIG. 5 is a diagram illustrating a complete flow of client idle state pre-compilation and bytecode acquisition in accordance with an exemplary embodiment;

FIG. 6 is a diagram illustrating a complete flow of compiling and retrieving bytecode the first time a client runs a script, in accordance with an illustrative embodiment;

FIG. 7 is a flowchart illustrating a first method of page presentation combining server compilation and client compilation in accordance with an exemplary embodiment;

FIG. 8 is a flowchart illustrating a second method of page presentation in conjunction with client compilation for server compilation in accordance with an exemplary embodiment;

FIG. 9 is a flowchart illustrating a second method of page presentation in accordance with an exemplary embodiment;

FIG. 10 illustrates a complete process flow for server compilation and delivery, according to an exemplary embodiment;

FIG. 11 is a flowchart illustrating a third method of page presentation in accordance with an exemplary embodiment;

FIG. 12 is a flowchart illustrating a third method of server compilation combined with client compilation to present a page in accordance with an illustrative embodiment;

FIG. 13 is a block diagram illustrating a first type of page presentation apparatus in accordance with an illustrative embodiment;

FIG. 14 is a block diagram illustrating a second type of page presentation device, in accordance with an exemplary embodiment;

FIG. 15 is a block diagram illustrating a third page presentation apparatus in accordance with an exemplary embodiment;

FIG. 16 is a block diagram illustrating a first type of electronic device in accordance with an exemplary embodiment;

FIG. 17 is a block diagram illustrating a second type of electronic device, according to an example embodiment.

Detailed Description

In order to make the technical solutions of the present disclosure better understood by those of ordinary skill in the art, the technical solutions in the embodiments of the present disclosure will be clearly and completely described below with reference to the accompanying drawings.

It should be noted that the terms "first," "second," and the like in the description and claims of the present disclosure and in the above-described drawings are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used is interchangeable under appropriate circumstances such that the embodiments of the disclosure described herein are capable of operation in sequences other than those illustrated or otherwise described herein. The implementations described in the exemplary embodiments below are not intended to represent all implementations consistent with the present disclosure. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present disclosure, as detailed in the appended claims.

Some of the words that appear in the text are explained below:

1. the term "and/or" in the embodiments of the present disclosure describes an association relationship of associated objects, and means that there may be three relationships, for example, a and/or B, which may mean: a exists alone, A and B exist simultaneously, and B exists alone. The character "/" generally indicates that the former and latter associated objects are in an "or" relationship.

2. The term "electronic device" in the embodiments of the present disclosure may be a mobile phone, a computer, a digital broadcast terminal, a messaging device, a game console, a tablet device, a medical device, a fitness device, a personal digital assistant, a vehicle-mounted terminal, and the like.

3. In the embodiment of the present disclosure, an "inline" is a C + + key, and the key inline is added before the function return type in the function declaration or definition, that is, the function may be designated as an inline function. The key inline must be placed with the function definition to make the function inline, and simply placing inline in front of the function declaration does nothing. An inline is a "key for implementation" and not a "key for declaration. Typically, a user can read the declaration of a function, but cannot see the definition of the function.

4. A "bytecode" in embodiments of the disclosure is a binary file consisting of a sequence of op code/data pairs containing an executing program. Bytecode is an intermediate code that is more abstract than machine code. It is often viewed as a binary file containing an executive, much like an object model. The byte code is called as such because each opcode is typically one byte long, but the length of the instruction code varies. Each instruction has a byte of opcode, from 0 to 255 (or 00 to FF in hexadecimal), followed by a parameter such as a register or memory address.

5. The "JavaScript" in the embodiments of the present disclosure: is a client-side scripting language that is object and event-driven based and has relative security. Meanwhile, the method is also a scripting language widely used for client Web development, and is often used for adding dynamic functions to an HTML webpage, such as responding to various operations of a user. Its interpreter, called JavaScript engine, is a part of the browser, widely used in the scripting language of the client, and was originally used on the HTML web page to add dynamic functionality to the HTML web page.

6. "V8" in the disclosed embodiment is a JavaScript engine. When the JavaScript code in the webpage is executed, the JavaScript source code can be compiled through V8, and the JavaScript source code is converted into binary byte codes used by the JavaScript virtual machine. And the JavaScript virtual machine on the browser executes the corresponding binary byte codes.

7. The "client" in the embodiments of the present disclosure may be software (e.g., a browser), or may also be a web page, an applet, and the like, and the server is a background server corresponding to the software, or the web page, the applet, and the like, or a server specially used for performing script compiling, which is not limited in this document.

The application scenario described in the embodiment of the present disclosure is for more clearly illustrating the technical solution of the embodiment of the present disclosure, and does not form a limitation on the technical solution provided in the embodiment of the present disclosure, and as a person having ordinary skill in the art knows, with the occurrence of a new application scenario, the technical solution provided in the embodiment of the present disclosure is also applicable to similar technical problems. Wherein, in the description of the present disclosure, unless otherwise indicated, "plurality" means.

The following briefly introduces the design ideas of the embodiments of the present disclosure:

blink is a browser layout engine, also known as rendering engine. Blink implements all rendering work in the browser tab, with the V8 engine built in to run JavaScript. When a page is opened by using a browser, Blink can deliver JavaScript in the page to V8, and a piece of JavaScript code is delivered to V8 from Blink to be executed, and is subjected to the processes of analysis, compiling, running, optimization and the like.

Wherein, the V8 engine executes the JavaScript script flow: first, the script content is obtained (one script is in a file, the file is downloaded firstly, then the file content is read, and the other script content is directly sent to V8), then the script is compiled to generate executable byte codes, and finally the byte codes are executed. The V8 will cache the compiled and parsed result, i.e. code cache, and when the same file is encountered next time, the process is skipped directly, and the directly cached data is used.

In the related art, two code cache schemes, namely an Isolate cache (isolated cache) and a resource cache (resource cache), are implemented in V8. The former is stored in memory and the latter is stored on disk. They will be described separately below:

first, the Isolate cache.

This cache is in the form of a hashtable in the heap of V8. The storage structure of the system is shown in FIG. 1A and comprises two parts, namely source and code. Wherein source refers to the content of source code, and code refers to byte code obtained by compiling. In this structure, the source code is used as a key, and the data (bytecode) generated after compilation is used as a corresponding value.

The following simple operating procedure is to be seen in conjunction with fig. 1A to 1C:

fig. 1A is a schematic diagram illustrating a first method for isolating a cache according to an embodiment of the disclosure. After Blink has copied a source code of JavaScript, V8 will compile JavaScript, i.e., the procedure of compactescript in fig. 1A, which specifically includes parsing, compiling, and running these several procedures to generate bytecode, i.e., in fig. 1A: 001101001001101100101 …

Fig. 1B is a schematic diagram illustrating a second isolation caching method in an embodiment of the disclosure. As shown in fig. 1B, the script source code is used as source, the bytecode obtained by compiling is used as code, and the bytecode is stored in the memory by means of the interrupt cache.

Fig. 1C is a schematic diagram illustrating a third isolation caching method in an embodiment of the disclosure. On the next execution, the bytecode is read from the memory and then executed.

However, for two tab pages that are loaded with the same script file a.js, since the isolation cache is only applicable to the same V8 process (site isolation mechanism), the two tab page processes are independent and cannot access data of each other, as shown in fig. 2, where the left and right sides of the dotted line respectively represent the loading processes corresponding to the first tab page and the second tab page. Based on a site isolation mechanism, when a second tab page starts to load a.js after the first tab page caches the a.js in the hashtable on the heap, the (byte codes of the) script file cached in the first tab page cannot be utilized, and recompilation is needed.

Second, resource cache.

The structure of this type of cache is shown in fig. 3A, and includes three parts, URI (Uniform Resource Identifier), Response, and Metadata. Wherein, URI represents the only mark of script file; response represents the content read out from the script file, namely [ data ]; the Timestamp value corresponding to the metadata field is a Timestamp indicating the time at which the script file was compiled. The metadata field may also correspond to a compiled bytecode, also called cached Code, thereafter.

The mode has three operation modes, and the following simple operation process is seen in combination with fig. 3A to 3C:

fig. 3A is a schematic diagram illustrating a first resource caching method in an embodiment of the disclosure. The figure shows a first mode of operation Cold Run: i.e. the first run. When a JavaScript file is requested for the first time, the cache of the compiling result is not carried out at this time, and only the timestamp is recorded.

Fig. 3B is a schematic diagram illustrating a second resource caching method in an embodiment of the disclosure. The figure shows a second operating mode, Warm Run: i.e. running the script a second time. If the running time is not more than 72 hours (more than 72 hours, the running time is still Cold Run, and the time stamp is updated) from the first time, serializing the compiling result after the script is Run by the compound, clearing the time stamp information in the disk, and storing the serialized code in the disk.

Fig. 3C is a schematic diagram illustrating a third resource caching method in an embodiment of the disclosure. The figure shows a third operating mode Hot Run: i.e. running the script a third time. If the cache is hit (namely the Code cache is read from the metadata part of the cache file), the cache is read from a disk, deserialization is carried out, and then the script is executed. Therefore, the analysis and compilation stages are skipped, and the cached data is directly executed. In this way, multiple processes can share cache, and a code cache can be shared among pages with different tags, as shown in fig. 3C.

However, in this method, only JavaScript scripts stored in a file or JavaScript in an external link are cached (byte length is less than 1024 and is not cached). For inline scripts, i.e., scripts embedded directly within page H5, V8 does not cache; for the JavaScript script with the byte length less than 1024, V8 is not cached; v8 is also not cached for JavaScript scripts that the developer actively injects. That is, the application scenario of this approach is very limited.

In addition to the above disadvantages, the above-listed two methods are compiled locally at the client, and are compiled during script running, that is, JavaScript script compiling is performed during loading the H5 page, so that the H5 page is loaded at a slow speed.

In view of this, the present disclosure provides a page display method, a page display apparatus, an electronic device, and a storage medium. According to the method and the device, the code cache strategy of the V8 is optimized, and the JavaScript compiling time is shortened, so that the loading process of the H5 page is accelerated, and the user experience is improved. The scheme in the present disclosure is based on the difference of execution main bodies, and can be specifically divided into two main categories: and the data is compiled and issued by a server, or the data is compiled locally by a client. The local compilation of the client can be divided into two modes: the client side is compiled in an idle state in advance, or the client side is compiled when the script runs for the first time. The above three methods may be used alone or in combination. Used alone: for the JavaScript scripts in the pages, any one of the three methods can be used according to the condition of each page; the combination use: a part of JavaScript application method in the page is a first method, a part of the script application method is a second method, and a part of the script application method is a third method.

The page display method in the present disclosure will be described in detail below with reference to the accompanying drawings:

fig. 4 is a flowchart illustrating a page display method according to an exemplary embodiment, where as shown in fig. 4, an execution subject of the process is a client, and the method specifically includes the following steps:

in step S41, when the client opens the page to be displayed, the client locally obtains the bytecode corresponding to the target script of the cached page to be displayed, where the bytecode is obtained by pre-compiling all script contents included in the target script when the client is in an idle state, or is obtained by compiling part of script contents running in the target script when the target script is run for the first time;

wherein, the running partial script content is as follows: when the page to be displayed is opened, the script content needing to be operated is in the target script corresponding to the page to be displayed; another part of the script content that does not need to be compiled refers to the part of the script content that does not need to be run in the target script when the page display is performed, which is exemplified below.

In the embodiment of the present disclosure, the idle state refers to a working state of the client. If the client is not running (not started); or the client is started but not running in the foreground but is idle in the background, etc., in which case the client is in the idle state.

The client can pre-compile script contents of the target script in an idle state; or compiling the target script when the client runs the target script for the first time. In addition, the two modes can be combined, namely, the client pre-compiles one part of script content of the target script in an idle state, and compiles the other part of script content when the target script is run for the first time; or, when the client runs the target script for the first time, compiling part of the script content running in the target script, and when the client is in an idle state, pre-compiling the script content not compiled in the target script, and the like.

In addition, except that the above-mentioned two ways can be adopted for the client to compile the script content of the same script, the client pre-compiles the content of a part of scripts in the page to be displayed in an idle state, and then pre-compiles the content of the target script when the target script is run for the first time.

In step S42, the client displays the page to be displayed based on the bytecode.

In the above embodiment, when the client is in the idle state, the target script of the page to be displayed can be pre-compiled and cached in advance; therefore, when a user browses the page to be displayed by using the client, the client can directly read the byte codes obtained by compiling before from the cache, and the page to be displayed is displayed based on the byte codes; in this way, the client can compile all the script contents in advance in the idle state, and the method has the advantages that the script is not required to be recompiled when the script is subsequently run again, so that the client does not need to recompile the script contents when the page to be displayed is opened, the compiling time is saved, and the page loading speed can be effectively improved.

In addition, the client can compile the content of the running script part when the target script runs for the first time, so that when a user browses the page to be displayed by using the client next time, the corresponding byte codes can be directly read from the cache, and the page to be displayed is displayed based on the byte codes. In the mode, because the script is compiled in the running process of the client, only the script which runs at this time is compiled, and the script which does not run at this time is not compiled in the mode, so that the opening speed is high. Moreover, when the client opens the page to be displayed subsequently, the script content does not need to be compiled again, so that the compiling time is saved, and the page loading speed can be effectively improved.

These two modes are described in detail below:

the first method is as follows: client idle state precompilation.

In this way, the client may pre-compile all content of the script related to the page, which is mainly exemplified herein by taking the target script as an example.

In an optional embodiment, the bytecode obtained by the client idle state precompilation may be cached in at least one of a memory and a disk. Namely: the cache can be cached in the memory or the disk independently, or can be cached in the memory partially or cached in the disk partially. Whether the data is stored in the memory may be determined according to actual conditions, such as the remaining size of the memory, the function of the target script, the reuse condition of the target script, and the like, and is not particularly limited herein.

Fig. 5 is a schematic diagram of a complete flow of pre-compiling and acquiring bytecode at the idle state of the client according to the embodiment of the disclosure, which specifically includes the following steps:

s501: when the client is in an idle state, acquiring each script corresponding to a page to be displayed;

s502: the client pre-compiles all script contents contained in each script respectively to obtain byte codes corresponding to each script;

s503: the client caches the script identification and the corresponding byte code of each script in a local corresponding memory or disk of the client;

s504: when a page to be displayed is opened by a client, locally acquiring a bytecode corresponding to a target script of the cached page to be displayed;

s505: and the client displays the page to be displayed based on the byte codes.

It should be noted that the method is applicable to all pages to be displayed and all scripts related to all pages to be displayed. In the embodiment of the present disclosure, the method may also be implemented only for scripts related to some pages based on big data statistics, or the method may be preferentially compiled and cached for scripts related to some pages, for example, a page with a large access amount is determined, or a small program with a large startup amount is started, and all contents of the scripts in the pages are pre-compiled and cached for JavaScript scripts in an idle state. The target script can be any one of the scripts listed above, and based on the above embodiment, when the client really runs the target script, the compiling time can be omitted, and the page loading speed can be increased.

The second method comprises the following steps: the client compiles when running the script for the first time.

In an optional implementation manner, when the client executes the target script for the first time, the bytecode is cached in the disk, where the compiled partial script content executed in the target script is obtained. By caching to disk, the cache can be shared by multiple processes.

Fig. 6 is a schematic diagram of a complete flow of compiling and obtaining bytecode when a client runs a script for the first time in the embodiment of the present disclosure, which specifically includes the following steps:

s601: when a target script corresponding to a page to be displayed runs for the first time, a client inquires whether the local part contains a bytecode corresponding to the target script;

s602: if the client determines that the local area does not contain the byte codes corresponding to the target script, compiling the content of a part of currently-running scripts in the target script to obtain the byte codes corresponding to the target script;

s603: caching the script identification of the target script and the corresponding byte code into a local corresponding disk of the client by the client;

s604: when the client opens the page to be displayed again, acquiring the byte codes corresponding to the target script of the cached page to be displayed from the local;

s605: and the client displays the page to be displayed based on the byte codes.

It should be noted that the query process in step S601 is unnecessary, that is, the client may directly compile a part of the script content currently running in the running process when the target script runs for the first time. The currently running partial script content refers to a partial script content which needs to be run and is related during the page display, and is specifically determined according to the requirements of a user and the like, for example, a target script contains 100 lines of script content, but the currently running partial script content is the first 60 lines, and only the 60 lines of script content need to be compiled, so that the first running speed is not affected.

In the case of executing the query process in step S601, if the client determines that the local (e.g., on the disk) does not include the bytecode corresponding to the target script, that is, the client does not perform pre-compilation on the target script in the idle state. That is, the flow shown in fig. 6 may be expressed as: and the client side is pre-compiled in an idle state, and is combined with the scheme that the client side is compiled when the script is run for the first time.

The above steps S602 and S603 describe a process of compiling and caching a part of the script content running in the target script. In an alternative embodiment, in order not to affect the first-time running speed, besides only compiling a part of the running script content, the caching work of the bytecode can be implemented on the basis of a sub-thread, and the specific implementation manner is as follows:

compiling partial script contents running in the target script by the client to obtain byte codes corresponding to the compiled parts; and in the process of compiling part of script contents running in the target script, performing associated storage on the bytecode corresponding to the compiled part and the script identifier corresponding to the target script through at least one sub-thread.

In the above embodiment, when the system runs for the first time, the main thread performs compiling and simultaneously one or more sub-threads perform caching, and the compiling and caching process is processed in parallel by multiple threads, so that the processing speed can be effectively improved.

In an optional implementation manner, when the client locally obtains the bytecode corresponding to the target script of the cached page to be displayed, the client needs to first obtain the script identifier corresponding to the target script, and then locally obtain the cached bytecode corresponding to the script identifier, where the bytecode and the script identifier are stored in the local cache in an associated manner.

It should be noted that the script identifier in the embodiment of the present disclosure may be obtained by performing hash operation on the target script, that is, hash the script content of the target script, and use the obtained hash value as the script identifier of the target script; or, the script identifier is a network address or a file path corresponding to the target script. Wherein the network address may refer to a download link.

Compared with the related art, the method has the advantages that the inline script, namely the script directly embedded in the page H5, or the JavaScript injected by the developer, or the JavaScript with the byte length smaller than 1024 cannot be cached in the mode, and the method is not supported. According to the embodiment of the disclosure, caching permissions for the inline script, the JavaScript script injected by developers and the JavaScript script with the byte length smaller than 1024 are opened through a self-research kernel, the number of bytes is not limited, and any type of script can be compiled and cached.

In the embodiment of the disclosure, by self-research of the kernel, for an inline script (without limit on the number of bytes), that is, a script (without limit on the number of bytes) directly embedded in a page H5, or a JavaScript script (without limit on the number of bytes) injected by a developer, or a script with a byte length smaller than a set value 1024, when the script runs for the first time, a compiled result can be cached on a disk, and in addition, in order to not affect the running speed for the first time, only the running script is compiled, and the storage work is put in a sub-thread, and the script is hash-determined to a file key, so that the script and a bytecode file stored on the disk can be in one-to-one correspondence, and when the script runs for the next time, the cached bytecode is directly read from the disk file.

Or, by self-research kernel, for JavaScript scripts downloaded through links or scripts (without limitation on the number of bytes) placed in a file, the compiled result is cached on a disk during first running, in order to not affect the first running speed, only the running scripts are compiled, the storage work is placed in a sub-thread, the links or the file path are taken as keys, so that the links or the file path correspond to the byte code files stored on the disk one by one, and the cached byte codes are directly read from the disk file during next running.

It should be noted that, the above listed embodiments all refer to that when the client opens the page to be exposed, the client directly obtains the bytecode locally from the client. In addition, for the H5 page or the applet of the self-maintenance server, the compiling of the byte codes can be completed at the server side.

Therefore, in an optional implementation, the client may also acquire from the server in advance, and if the client cannot acquire, the client may acquire from the local. Referring to fig. 7, the specific implementation flow is as follows:

s71: when the client opens the page to be displayed, judging whether the bytecode corresponding to the target script can be acquired from the server, if so, executing the step S74, otherwise, executing the step S72;

s72: the client acquires the byte code corresponding to the target script of the cached page to be displayed from the local;

s73: the client executes the byte codes acquired from the local and displays the page to be displayed according to the execution result;

s74: the client acquires the bytecode returned by the server;

s75: the client executes the bytecode returned by the server and displays the page to be displayed according to the execution result.

In general, if there is no network or the network status is not good, the client may determine that the client cannot acquire the bytecode from the server, and at this time, the client performs step S72 to acquire the bytecode from the local.

In another alternative embodiment, the client may also obtain the bytecode from both the local and the server, that is, the bytecode corresponding to a part of the script content of the target script is compiled locally, and the bytecode corresponding to a part of the script content is compiled at the server. Referring to fig. 8, the method specifically includes the following steps:

s81: when a page to be displayed is opened, a client acquires a bytecode corresponding to a target script of the cached page to be displayed from the local;

s82: a client sends a query request aiming at a page to be displayed to a server;

s83: the client receives the bytecode returned by the server;

s84: the client side merges the byte code returned by the server and the byte code acquired locally to obtain a merged byte code;

s85: and the client executes the merged byte codes and displays the page to be displayed according to the execution result.

Specifically, in step S81, the local fetching is also divided into many cases, and the locally-fetched bytecode may be pre-compiled in the idle state of the client, may be compiled when the client runs for the first time, may be partially pre-compiled and partially compiled when the client runs for the first time, or may be combined with the result of the pre-compiled and the result of the first run-time compiled, which is not limited herein.

It should be noted that the sequence between the steps S82-S83 and S81 may be adjustable, that is, the information may be obtained from the local and then from the server, or may be obtained from the server and then from the local. Of course, the sequence between steps S82-S83 and step S81 may not be distinguished, i.e., may be obtained simultaneously, and is not limited specifically herein.

In an optional implementation manner, before step S84, the bytecode returned by the server may be compared with the locally obtained bytecode, so as to obtain a comparison result; if the comparison result meets the merging condition, step S84 may be executed, and if the comparison result does not meet the merging condition, the bytecode returned by the server is executed, and the page to be displayed is displayed according to the execution result. Wherein, the merging conditions are as follows: the bytecode returned by the server is inconsistent with the locally acquired bytecode.

Specifically, the reason why the byte codes on the two sides are not consistent is that the cache time is earlier and the web page is updated during the period; or, the client side only caches the bytecode corresponding to part of the script, and the server side caches all bytecodes, and the like, which is not specifically limited herein. Through the judgment of the merging conditions, various page display conditions can be effectively dealt with, the loading process of the h5 page is accelerated, and the user experience is improved.

In an alternative embodiment, the client may obtain the bytecode corresponding to the target script from the server by:

the method comprises the steps that a client firstly sends a query request aiming at a page to be displayed to a server so that the server obtains byte codes corresponding to a target script according to the query request, wherein the byte codes are obtained by compiling all script contents contained in the target script by the server; if the client side does not receive the byte codes returned by the server within the set time length, determining that the server does not store the byte codes corresponding to the target script, namely, the byte codes corresponding to the target script cannot be obtained from the server; if the client receives the bytecode returned by the server within the set time length, the server is determined to store the bytecode corresponding to the target script, and the bytecode corresponding to the target script can be obtained from the server.

In the embodiment, the method can be effectively applied to various scenes, such as network, no network, poor network state and the like, is not limited by application scenes, and different implementation modes can be flexibly selected according to the application scenes, so that the page loading speed can be effectively increased. In addition, the page can be finely adjusted as time goes on, and in this case, because the bytecode in the disclosure can be compiled in combination with a plurality of ways, different compiling ways can correspond to different time nodes, so that the availability of the bytecode can be effectively ensured.

It should be noted that, in addition to the above-mentioned several manners, how to obtain the bytecode corresponding to the target script of the page to be displayed may be further determined according to the type of the page to be displayed or the type of the target script, which is specifically divided into the following manners:

in the first mode, if the page to be displayed is a page with the access times larger than a preset threshold, the byte codes obtained by pre-compiling all script contents contained in the target script are locally obtained.

For example, for a page with a large access amount, or a small program with a large startup amount, and the like, if the access times corresponding to these pages are greater than a preset threshold, the bytecodes corresponding to all script contents included in the target script of the page can be obtained locally.

In the above embodiment, pre-compilation (compilation of all contents of a script) is performed and stored in a disk when the background is idle, so that the compilation time is omitted during real operation, and the loading speed is increased.

And secondly, if the target script is a specified type script, locally acquiring a bytecode obtained by compiling part of script content running in the target script, wherein the specified type script comprises an inline script, a script with the byte length smaller than a set value and at least one of scripts injected by a developer.

For example, for an inline script, that is, a script directly embedded in the page H5, or a JavaScript script injected by a developer, or a script with a byte length smaller than the set value 1024, a bytecode obtained by compiling a part of the script content running in the target script may be locally obtained.

In addition, besides the specified types, for the JavaScript script downloaded by linking or the script placed in the file, the bytecode obtained by compiling a part of the script content run in the target script can be locally acquired.

And thirdly, if the page to be displayed is a page maintained by the server, acquiring the byte code corresponding to the target script of the page to be displayed from the server.

For example, for an H5 page of a self-maintenance server or an applet, the compiling and caching of the bytecode may be completed at the server side, and further, the bytecode corresponding to the target script of the page to be exposed may be obtained from the server.

In the above embodiment, the server end completes the compiling of the bytecode (compiling all contents of the script), when the user opens the page, the bytecode is issued to the user together, and when the script is run, the issued bytecode is directly run, so that the page loading speed is increased.

It should be noted that the enumerated several manners can be used separately, and for the JavaScript script in the page, any one of the above three manners can be used according to the situation of each page; or, the above modes may be combined two by two, or three modes may be used in combination, and the like, for example, a part of javascript usage mode one, a part of script usage mode two, a part of script usage mode three, and the like in a page, and the specific limitations are not limited herein.

Based on the implementation mode, the code cache strategy of the V8 is optimized, so that the compiling time of the JavaScript script is reduced, the loading process of the H5 page is accelerated, and the user experience is improved.

In an optional implementation manner, an embodiment of the present application further provides a page display system, where the system includes:

the client is used for sending a query request aiming at the page to be displayed to the server when the page to be displayed is opened; if the server is determined not to store the bytecode corresponding to the target script, locally acquiring the bytecode corresponding to the target script of the cached page to be displayed, and displaying the page to be displayed based on the bytecode; if the bytecode corresponding to the target script stored by the server is determined, acquiring the bytecode returned by the server; displaying the page to be displayed based on the byte code returned by the server; the locally acquired bytecode is obtained by pre-compiling all script contents contained in the target script when the client is in an idle state, or is obtained by compiling part of script contents operated in the target script when the target script is operated for the first time;

the server is used for receiving a query request aiming at the page to be displayed and sent by the client, and acquiring the bytecode corresponding to the target script of the page to be displayed according to the query request; and returning the byte codes to the client, wherein the byte codes returned by the server are obtained by compiling all script contents contained in the target script.

Optionally, the client is specifically configured to:

executing the byte codes returned by the server, and displaying the page to be displayed according to the execution result; or

Combining the byte code returned by the server with the byte code acquired locally to obtain a combined byte code; and executing the merged byte codes, and displaying the page to be displayed according to the execution result.

In the above embodiment, before acquiring the bytecode locally from the client, an inquiry request may be sent to the server to determine whether the server side stores the corresponding bytecode, and if not, the server side acquires the bytecode locally from the client, and if so, the bytecode returned by the server may be directly executed, or the bytecode returned by the server and the bytecode acquired locally are merged to obtain a merged bytecode, and the merged bytecode is executed, so that interaction between the server and the client is achieved.

The following describes the procedure of compiling and issuing bytecode based on the server in detail.

Fig. 9 is a flowchart illustrating a page display method according to an exemplary embodiment, where as shown in fig. 9, an execution subject of the method is a server, and the method specifically includes the following steps:

in step S91, the server receives a query request for the page to be displayed, which is sent by the client, and obtains the bytecode corresponding to the target script of the page to be displayed according to the query request, where the query request is sent when the client detects that the page to be displayed is opened;

in step S92, the server returns the bytecode to the client, so that the client displays the page to be displayed based on the bytecode, where the bytecode is obtained by compiling all script content included in the target script.

In the embodiment of the present disclosure, for the H5 page or the applet of the self-maintenance server, the compiling of the bytecode (compiling all contents of the script) can be completed at the server side, when the user opens the page, the bytecode is issued to the user together, and when the script is run, the issued bytecode is directly run, so that the page loading speed is increased.

In an optional implementation manner, the server may obtain a script identifier corresponding to the target script according to the query request, and further query the bytecode corresponding to the script identifier.

The script identifier is obtained by performing hash operation on the target script, or the script identifier is a network address or a file path corresponding to the target script, which is exemplified above, and repeated parts are not described again.

The following describes in detail a complete process of compiling and issuing by the server, and as shown in fig. 10, the method specifically includes the following steps:

s1001: the server acquires each script corresponding to the page to be displayed;

s1002: the server compiles all script contents contained in each script respectively to obtain byte codes corresponding to each script;

s1003: the server caches the script identification and the corresponding byte code of each script;

s1004: the method comprises the steps that a server receives a query request aiming at a page to be displayed and sent by a client, and byte codes corresponding to a target script of the page to be displayed are obtained according to the query request;

s1005: the server returns the bytecode to the client.

In the above embodiment, a server compiling and issuing mode is adopted, and when a user request is received, the pre-compiled bytecode can be issued to the user together, that is, the mode can be applied to any page opening (including the first page opening) condition, and the page loading speed can be effectively increased.

In addition, it should be noted that the server in the embodiment of the present disclosure may be a server corresponding to the client, or may be a server specially used for performing script compiling and caching, and is not limited herein.

Fig. 11 is a flowchart illustrating a page display method according to an exemplary embodiment, where an execution subject of the method is a client, and as shown in fig. 11, the method specifically includes the following steps:

in step S111, when the client opens the page to be displayed, the client sends a query request for the page to be displayed to the server, so that the server obtains a bytecode corresponding to a target script of the page to be displayed according to the query request, where the bytecode is obtained by compiling all script contents included in the target script by the server;

in step S112, the client receives the bytecode returned by the server;

in step S113, the client displays the page to be displayed based on the bytecode.

The process corresponds to the flow shown in fig. 9, that is, when the client opens the page to be displayed, the client sends a query request to the server, and obtains and executes the bytecode corresponding to the target script in a manner of issuing the bytecode by the server, and the page is displayed according to the execution result, and repeated parts are not repeated.

In an optional implementation manner, when the page to be displayed is opened, the client may also obtain the bytecode corresponding to the target script from the local, and if the bytecode cannot be obtained from the local, the client sends a query request to the server to obtain the bytecode issued by the server. The specific implementation flow is shown in fig. 12, and specifically includes the following steps:

s1201: when a page to be displayed is opened, a client judges whether a bytecode corresponding to a cached target script can be acquired from the local;

s1202: if the client determines that the bytecode corresponding to the cached target script cannot be obtained locally, sending a query request aiming at the page to be displayed to a server;

s1203: the client receives the bytecode returned by the server;

s1204: and the client displays the page to be displayed based on the byte codes.

In step S1204, the client first needs to execute the bytecode, and then displays the page based on the execution result.

In addition, it should be noted that, in addition to the manner shown in fig. 12, when the client opens the page to be displayed, the client may first send a query request to the server to obtain the bytecode issued by the server, and if the bytecode cannot be obtained from the server, then obtain the bytecode corresponding to the target script from the local, that is, the flow shown in fig. 7, and repeated details are not repeated.

The difference between the flowchart shown in fig. 12 and the flowchart shown in fig. 7 is that: the client side judges that the client side can be obtained from the local, and if the client side cannot be obtained, the client side obtains the client side from the server; the client side judges whether the client side can be obtained from the server or not, and if the client side cannot be obtained, the client side obtains the client side from the local. The method can be effectively applied to various scenes such as network, no network, poor network state and the like without limitation of application scenes.

In an optional embodiment, the client may locally obtain the bytecode corresponding to the cached target script by at least one of the following manners:

the first method is as follows: when the client is in an idle state, pre-compiling all script contents contained in the target script to obtain byte codes.

Specifically, if the page to be displayed is a page with access times greater than a preset threshold, the bytecode is obtained by pre-compiling all script contents contained in the target script when the client is in an idle state.

For example, if the page to be displayed is a page with a large access amount, or a small program with a large startup amount is started, and the corresponding access times are greater than a preset threshold value, all the contents of the JavaScript script in the page to be displayed can be pre-compiled and cached in an idle state.

The second method comprises the following steps: when the target script is operated by the client for the first time, compiling partial script contents operated in the target script to obtain byte codes.

It should be noted that, in addition to the above-mentioned first and second modes, the client may also combine the first mode and the second mode, that is, when the client runs the target script for the first time, the client compiles part of script contents running in the target script, and when the client is in an idle state, pre-compiles script contents not compiled in the target script to obtain the bytecode; or, when the client is in the idle state, pre-compiling a part of script content in the target script, and when the target script is run for the first time, compiling another part of script content, and the like, which is not specifically limited herein. In addition, the repeated points refer to the above embodiments, and the detailed description is not repeated here.

In another optional implementation manner, an embodiment of the present application further provides a page display system, where the system includes:

In the above embodiment, the interactive process between the server and the client is given in the manner of only obtaining the bytecode from the server side.

It should be noted that, in the embodiment of the present disclosure, both the method compiled locally by the client and the method compiled by the server are applicable to all scripts of all pages. However, in fact, if all scripts corresponding to all pages are compiled, a large amount of time is not needed, and a large amount of storage space is consumed, so that the method can be implemented only for scripts related to some pages or compiled and cached preferentially for scripts related to some pages based on big data statistics and other manners. For example, the script may be related to Top N pages commonly used by the user, or may be related to N pages that are run for the first time, where N is a positive integer.

The following describes in detail a page display device and an electronic device in an embodiment of the present disclosure:

FIG. 13 is a block diagram illustrating a first page showing apparatus according to an example embodiment. Referring to fig. 13, the page display apparatus 1300 includes an obtaining unit 1301 and a display unit 1302:

the obtaining unit 1301 is configured to locally obtain a bytecode corresponding to a target script of a cached page to be displayed when the page to be displayed is opened, where the bytecode is obtained by pre-compiling all script contents included in the target script when a client is in an idle state, or is obtained by compiling part of script contents running in the target script when the target script is run for the first time;

the presentation unit 1302 is configured to perform presentation of a page to be presented based on bytecode.

if the bytecode is obtained by compiling part of script content running in the target script when the target script is run for the first time, caching the bytecode into a disk.

Optionally, the bytecode is obtained by compiling a part of script content running in the target script when the target script is run for the first time; the device still includes:

the compiling unit 1303 is configured to query whether the local area includes the bytecode corresponding to the target script when the target script is run for the first time before the obtaining unit 1301 obtains the bytecode corresponding to the target script of the cached page to be displayed from the local area when the page to be displayed is opened;

Optionally, the compiling unit 1303 is specifically configured to perform:

compiling partial script contents running in the target script to obtain byte codes corresponding to compiled parts;

Optionally, the obtaining unit 1301 is specifically configured to perform:

acquiring a script identifier corresponding to a target script, wherein the script identifier is obtained by performing hash operation on the target script, or the script identifier is a network address or a file path corresponding to the target script;

and acquiring the cached byte codes corresponding to the script identifications from the local cache, wherein the byte codes and the script identifications are stored in the local cache in an associated manner.

Optionally, the obtaining unit 1301 is further configured to perform:

inquiring whether a server stores byte codes corresponding to the target scripts or not;

and if the server is determined not to store the byte codes corresponding to the target scripts, locally acquiring the cached byte codes corresponding to the target scripts of the page to be displayed.

Optionally, the obtaining unit 1301 is specifically configured to perform:

sending a query request aiming at a page to be displayed to a server so that the server acquires a byte code corresponding to a target script according to the query request, wherein the byte code is obtained by compiling all script contents contained in the target script by the server;

and if the bytecode returned by the server is not received within the set time length, determining that the server does not store the bytecode corresponding to the target script.

Optionally, the obtaining unit 1301 is further configured to perform:

if the bytecode corresponding to the target script stored by the server is determined, acquiring the bytecode returned by the server;

and executing the byte codes returned by the server, and displaying the page to be displayed according to the execution result.

Optionally, the obtaining unit 1301 is further configured to perform:

before the display unit 1302 displays the page to be displayed based on the bytecode, a query request for the page to be displayed is sent to the server, so that the server obtains the bytecode corresponding to the target script according to the query request, wherein the bytecode is obtained by compiling all script contents contained in the target script by the server;

receiving a bytecode returned by the server;

combining the byte code returned by the server with the byte code acquired locally to obtain a combined byte code;

the presentation unit 1302 is specifically configured to perform:

and executing the merged byte codes, and displaying the page to be displayed according to the execution result.

Optionally, the obtaining unit 1301 is further configured to perform:

Optionally, the presentation unit 1302 is further configured to perform:

and if the comparison result does not meet the merging condition, executing the byte codes returned by the server, and displaying the page to be displayed according to the execution result.

Optionally, the obtaining unit 1301 is specifically configured to perform:

if the page to be displayed is a page with the access times larger than a preset threshold value, locally acquiring byte codes obtained by precompiling all script contents contained in the target script;

if the target script is a specified type script, locally acquiring byte codes obtained by compiling part of script contents running in the target script, wherein the specified type script comprises an inline script, a script with the byte length smaller than a set value, and at least one of scripts injected by a developer.

Optionally, the obtaining unit 1301 is further configured to perform:

FIG. 14 is a block diagram illustrating a first page showing apparatus according to an example embodiment. Referring to fig. 14, the page presentation apparatus 1400 includes a query unit 1401 and a feedback unit 1402:

the query unit 1401 is configured to execute a query request for a page to be displayed, which is sent by a receiving client, and acquire a bytecode corresponding to a target script of the page to be displayed according to the query request, where the query request is sent when the client detects that the page to be displayed is opened;

the feedback unit 1402 is configured to perform returning the bytecode to the client, so that the client displays the page to be displayed based on the bytecode, where the bytecode is obtained by compiling all script content included in the target script.

Optionally, the querying unit 1401 is specifically configured to perform:

and acquiring the byte code corresponding to the script identifier.

FIG. 15 is a block diagram illustrating a third page displaying apparatus according to an example embodiment. Referring to fig. 15, the page showing apparatus 1500 includes an acquisition unit 1501, a receiving unit 1502, and a showing unit 1503:

the acquiring unit 1501 is configured to send a query request for the page to be displayed to the server when the page to be displayed is opened, so that the server acquires a bytecode corresponding to a target script of the page to be displayed according to the query request, wherein the bytecode is obtained by compiling all script contents included in the target script by the server;

a receiving unit 1502 configured to execute bytecode returned by the receiving server;

the presentation unit 1503 is configured to perform presentation of the page to be presented based on the bytecode.

Optionally, the obtaining unit 1501 is further configured to perform:

before a query request aiming at a page to be displayed is sent to a server, whether a bytecode corresponding to a target script is stored locally is queried;

Optionally, if determining the bytecode corresponding to the locally stored target script, the obtaining unit 1501 is further configured to perform compiling to obtain the bytecode in at least one of the following manners:

when the target script is in an idle state, pre-compiling all script contents contained in the target script to obtain byte codes;

when the target script is operated for the first time, compiling partial script contents operated in the target script to obtain byte codes.

With regard to the apparatus in the above-described embodiment, the specific manner in which each unit executes the request has been described in detail in the embodiment related to the method, and will not be elaborated here.

In some alternative embodiments, a page presentation apparatus according to the present disclosure may include at least a processor and a memory. Wherein the memory stores program code which, when executed by the processor, causes the processor to perform the steps of the page presentation method according to various exemplary embodiments of the present disclosure described in this specification. For example, the processor may perform the steps as shown in any of fig. 4 to 12.

The electronic equipment is based on the same inventive concept as the method embodiment, and the embodiment of the disclosure also provides the electronic equipment. In one embodiment, the electronic device may be a server. In this embodiment, the electronic device may be configured as shown in fig. 16, and includes a memory 1601, a communication module 1603 and one or more processors 1602.

A memory 1601 for storing computer programs executed by the processor 1602. The memory 1601 may mainly include a storage program area and a storage data area, where the storage program area may store an operating system, a program required for running an instant messaging function, and the like; the storage data area can store various instant messaging information, operation instruction sets and the like.

The memory 1601 may be a volatile memory (volatile memory), such as a RAM (random-access memory); the memory 1601 may also be a non-volatile memory, such as a read-only memory, a flash memory, a HDD (hard disk drive) or an SSD (solid-state drive); or memory 1601 is any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer, but is not limited to such. The memory 1601 may be a combination of the above.

The processor 1602, may include one or more CPUs (central processing units) or be a digital processing unit, etc. The processor 1602 is configured to implement the page display method when a computer program stored in the memory 1601 is called.

The communication module 1603 is used for communicating with terminal equipment and other servers.

The embodiment of the present disclosure does not limit the specific connection medium among the memory 1601, the communication module 1603, and the processor 1602. In fig. 16, the memory 1601 and the processor 1602 are connected by a bus 1604, the bus 1604 is depicted by a thick line in fig. 16, and the connection manner between other components is merely illustrative and not limited. The bus 1604 may be divided into an address bus, a data bus, a control bus, and so on. For ease of description, only one thick line is depicted in fig. 16, but only one bus or one type of bus is not depicted.

The memory 1601 stores therein a computer storage medium, in which computer-executable instructions are stored, and the computer-executable instructions are used for implementing the page display method of the embodiments of the present disclosure. The processor 1602 is configured to execute the page display method described above, as shown in fig. 9.

In another embodiment, the electronic device may also be other electronic devices, such as a terminal device installed with a client. In this embodiment, the structure of the electronic device may be as shown in fig. 17, including: communication component 1710, memory 1720, display unit 1730, camera 1740, sensors 1750, audio circuitry 1760, bluetooth module 1770, processor 1780, and the like.

The communication component 1710 is for communicating with a server. In some embodiments, a WiFi (Wireless Fidelity) module may be included, the WiFi module belongs to a short-distance Wireless transmission technology, and the electronic device may help the user to send and receive information through the WiFi module.

Memory 1720 may be used to store software programs and data. The processor 1780 performs various functions of the terminal device and data processing by executing software programs or data stored in the memory 1720. The memory 1720 may include high-speed random access memory and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other volatile solid-state storage device. The memory 1720 stores an operating system that enables the terminal device to operate. The memory 1720 may store an operating system and various application programs, and may also store codes for performing the page display method according to the embodiments of the present disclosure.

The display unit 1730 may also be used to display information input by the user or information provided to the user and a GUI (graphical user interface) of various menus of the terminal device. In particular, the display unit 1730 may include a display screen 1732 disposed on the front surface of the terminal device. The display screen 1732 may be configured in the form of a liquid crystal display, a light emitting diode, or the like. The display unit 1730 may be used to display a page to be displayed in the embodiment of the present disclosure, and the like.

The display unit 1730 may also be used to receive input numeric or character information, generate signal inputs related to user settings and function control of the terminal device, and particularly, the display unit 1730 may include a touch screen 1731 disposed on a front surface of the terminal device, and may collect touch operations of a user thereon or nearby, such as clicking a button, dragging a scroll box, and the like.

The touch screen 1731 may cover the display screen 1732, or the touch screen 1731 and the display screen 1732 may be integrated to implement an input and output function of the terminal device, and after the integration, the touch screen may be referred to as a touch display screen for short. The display unit 1730 in the present disclosure may display the application programs and the corresponding operation steps.

The camera 1740 may be used to capture still images, and the user may post comments on the images captured by the camera 1740 through the application. The number of the cameras 1740 may be one or plural. The object generates an optical image through the lens and projects the optical image to the photosensitive element. The photosensitive element may be a CCD (charge coupled device) or CMOS (complementary metal-oxide-semiconductor) phototransistor. The light sensing elements convert the light signals into electrical signals which are then passed to a processor 1780 for conversion into digital image signals.

The terminal device may further comprise at least one sensor 1750, such as an acceleration sensor 1751, a distance sensor 1752, a fingerprint sensor 1753, a temperature sensor 1754. The terminal device may also be configured with other sensors such as a gyroscope, barometer, hygrometer, thermometer, infrared sensor, light sensor, motion sensor, and the like.

The audio circuitry 1760, speaker 1761, microphone 1762 may provide an audio interface between the user and the terminal device. The audio circuit 1760 may transmit the electrical signal converted from the received audio data to the speaker 1761, and convert the electrical signal into an audio signal for output by the speaker 1761. The terminal device may be further provided with a volume button for adjusting the volume of the sound signal. On the other hand, the microphone 1762 converts the collected sound signals into electrical signals, which are received by the audio circuitry 1760 and converted into audio data, which are output to the communication assembly 1710 for transmission to, for example, another terminal device, or to the memory 1720 for further processing.

The bluetooth module 1770 is used for information interaction with other bluetooth devices having a bluetooth module through a bluetooth protocol. For example, the terminal device may establish a bluetooth connection with a wearable electronic device (e.g., a smart watch) that is also equipped with a bluetooth module through the bluetooth module 1770, so as to perform data interaction.

The processor 1780 is a control center of the terminal device, connects various parts of the entire terminal device using various interfaces and lines, and performs various functions of the terminal device and processes data by operating or executing software programs stored in the memory 1720 and calling data stored in the memory 1720. In some embodiments, processor 1780 may include one or more processing units; the processor 1780 may also integrate an application processor, which primarily handles operating systems, user interfaces, applications, etc., and a baseband processor, which primarily handles wireless communications. It will be appreciated that the baseband processor described above may not be integrated into the processor 1780. In the present disclosure, the processor 1780 may run an operating system, an application program, a user interface display and a touch response, and a page display method according to an embodiment of the present disclosure. Further, the processor 1780 is coupled to a display unit 1730.

The embodiment of the present disclosure further provides a computer program product, which when running on an electronic device, enables the electronic device to execute any one of the above page display methods or any one of the methods that may be involved in implementing any one of the above page display methods according to the embodiment of the present disclosure.

Other embodiments of the disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the disclosure disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of the disclosure following, in general, the principles of the disclosure and including such departures from the present disclosure as come within known or customary practice within the art to which the disclosure pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the disclosure being indicated by the following claims.

It will be understood that the present disclosure is not limited to the precise arrangements described above and shown in the drawings and that various modifications and changes may be made without departing from the scope thereof. The scope of the present disclosure is limited only by the appended claims.

Claims

1. A page display method is applied to a client side and comprises the following steps:

and displaying the page to be displayed based on the byte codes.

2. A page display method is applied to a server and comprises the following steps:

3. A page display method is applied to a client side and comprises the following steps:

receiving the bytecode returned by the server;

and displaying the page to be displayed based on the byte codes.

4. A page display device is applied to a client and comprises:

5. A page display device is applied to a server and comprises:

6. A page display device is applied to a client and comprises:

7. A page presentation system, comprising:

8. A page presentation system, comprising:

9. An electronic device, comprising:

a processor;

a memory for storing the processor-executable instructions;

wherein the processor is configured to execute the instructions to implement the page presentation method of claim 1 or the page presentation method of claim 2 or the page presentation method of claim 3.

10. A storage medium, wherein instructions in the storage medium, when executed by a processor of an electronic device, enable the electronic device to perform the page presentation method of claim 1 or the page presentation method of claim 2 or the page presentation method of claim 3.