CN113468448A

CN113468448A - Page rendering method and device

Info

Publication number: CN113468448A
Application number: CN202010240291.7A
Authority: CN
Inventors: 杨文婷
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2020-03-31
Filing date: 2020-03-31
Publication date: 2021-10-01

Abstract

The invention provides a page rendering method, a page rendering device, electronic equipment and a computer readable storage medium; the method comprises the following steps: creating a plurality of new threads in a multi-threaded environment independent of the browser environment; correspondingly allocating a plurality of data request tasks included in the page to be rendered in the browser environment to the plurality of new threads, so that the plurality of new threads acquire page data from a server according to the respectively allocated data request tasks; and receiving page data respectively acquired by the new threads from the server, and rendering the page based on the received page data. According to the invention, the page rendering efficiency can be improved, the long-term blocking or blank of the page can be avoided, and the user experience is improved.

Description

Page rendering method and device

Technical Field

The present invention relates to the field of internet technologies, and in particular, to a page rendering method and apparatus, an electronic device, and a computer-readable storage medium.

Background

The JavaScript language running in the pages of the browser adopts a single-thread model, namely, only one JavaScript thread can be executed in each page of the browser (in the JavaScript thread, a JavaScript engine can interpret and execute JavaScript codes in the page), an additional thread cannot be created, and a parallel task cannot be carried out. That is, the front end using JavaScript can only process all tasks using a single thread, and when pulling the server data, only one uniform resource locator can be requested at a time, and the data is pulled to the front end in a serial manner for rendering. When a large file is loaded or a piece of data is requested by a JavaScript thread, the JavaScript thread and the rendering thread are mutually exclusive, and the rendering thread cannot be executed (blocked rendering) by a CPU (central processing unit) due to the fact that the JavaScript thread occupies the CPU for a long time, so that a page is blank or stuck for a long time, and user experience is seriously influenced.

Disclosure of Invention

The embodiment of the invention provides a page rendering method and device, electronic equipment and a computer readable storage medium, which can improve page rendering efficiency, avoid long-term jamming or blank of a page and improve user experience.

The technical scheme of the embodiment of the invention is realized as follows:

the embodiment of the invention provides a page rendering method, which comprises the following steps:

creating a plurality of new threads in a multi-threaded environment independent of the browser environment;

correspondingly distributing a plurality of data request tasks included in the page to be rendered in the browser environment to the plurality of new threads so as to enable the plurality of new threads to be enabled to be

The new threads acquire page data from the server according to the data request tasks respectively allocated to the new threads;

and receiving page data respectively acquired by the new threads from the server, and rendering the page to be rendered based on the received page data.

An embodiment of the present invention provides a page rendering apparatus, including:

a creation module for creating a plurality of new threads in a multi-threaded environment independent of a browser environment;

an allocation module, configured to correspondingly allocate a plurality of data request tasks included in the page to be rendered in the browser environment to the plurality of new threads, so that the multiple new threads are allocated with the data request tasks

the receiving module is used for receiving the page data respectively acquired by the plurality of new threads from the server;

a rendering module for rendering the page to be rendered based on the received page data.

In the above solution, the creating module is further configured to create a plurality of new threads in a multithreading environment independent of a browser environment in advance before parsing the page file of the page to be rendered; the page rendering device also comprises an analysis module, a data request task module and a data processing module, wherein the analysis module is used for allocating the data request tasks for acquiring the plurality of page data to the idle new threads in a one-to-one correspondence manner when analyzing the page file of the page to be rendered and sequentially analyzing a plurality of page data to be acquired; the page rendering device also comprises a storage module, which is used for storing the data request task to be executed into the queue to be executed when no idle new thread exists.

In the foregoing solution, the page rendering apparatus further includes a sending module, configured to send, for any new thread in the multiple new threads, a corresponding communication message to the any new thread through a communication interface between the browser environment and the multithreading environment; the communication message includes a task name of a data request task that needs to be executed by any new thread and a uniform resource locator corresponding to the data request task.

In the foregoing solution, the page rendering device further includes an obtaining module, configured to obtain a naming rule of the data request task, and determine task names corresponding to the data request tasks according to the naming rule.

In the above scheme, the creating module is further configured to add, to each of the communication messages, a corresponding message number; creating an object in the multi-threaded environment and defining a callback function for each of the message numbers based on the object; monitoring the execution state of the data request task distributed to each of the new threads based on the callback function; and when monitoring that a new thread which completes the data request task exists in the plurality of new threads, distributing the data request task in the queue to be executed for the new thread which completes the data request task.

In the above scheme, the page rendering apparatus further includes a processing module, configured to, when each new thread acquires page data from the server, perform cleaning, calculation, and reassembly on the acquired page data, and send the processed page data to the browser environment for rendering.

In the foregoing solution, the rendering module is further configured to render a partial page in real time based on page data acquired by any new thread of the multiple new threads when the page data acquired by any new thread is received; the receiving module is further configured to call a rendering thread in the browser environment to respond to the human-computer interaction operation when the human-computer interaction operation for the partial page is received.

In the above solution, the receiving module is further configured to terminate the data request tasks executed by the new threads when a jump operation for the page is received; the allocation module is used for correspondingly allocating a plurality of new data request tasks included in the jumped new page to the plurality of new threads so that the plurality of new threads acquire new page data from the server according to the respectively allocated new data request tasks; the receiving module is further configured to receive new page data that is obtained by the plurality of new threads from the server respectively; the rendering module is configured to render the new page based on the received new page data.

An embodiment of the present invention provides an electronic device, including:

a memory for storing executable instructions;

and the processor is used for realizing the page rendering method provided by the embodiment of the invention when the executable instruction stored in the memory is executed.

The embodiment of the invention provides a computer-readable storage medium, which stores executable instructions and is used for causing a processor to execute the executable instructions so as to realize the page rendering method provided by the embodiment of the invention.

The embodiment of the invention has the following beneficial effects:

the method has the advantages that the multiple new threads are created in the multi-thread environment independent of the browser environment, the created multiple new threads are used for requesting the page data, page blocking caused when the main thread (namely the rendering thread) in the browser environment requests the page data is avoided, meanwhile, the page data can be requested in batches based on the created multiple new threads, and the application program interface does not need to be called for many times to process data, so that a back-end developer is not needed to improve the interface, and the workload of back-end development is reduced.

Drawings

Fig. 1 is a schematic diagram of an alternative implementation architecture of a page rendering method according to an embodiment of the present invention;

fig. 2 is an alternative structural diagram of a terminal according to an embodiment of the present invention;

FIG. 3 is an alternative structural diagram of a browser provided by an embodiment of the present invention;

FIG. 4 is an alternative flowchart of a page rendering method according to an embodiment of the present invention;

FIG. 5 is a schematic flow chart of another alternative page rendering method according to an embodiment of the present invention;

FIG. 6 is a schematic interface diagram of a page of an internal system according to an embodiment of the present invention;

FIG. 7 is a schematic diagram of page data required for rendering the page shown in FIG. 6 according to an embodiment of the present invention;

FIG. 8 is a schematic diagram of a data request being performed by multiple Worker threads synchronously according to an embodiment of the present invention;

fig. 9 is a schematic flowchart of yet another optional page rendering method according to an embodiment of the present invention.

Detailed Description

In order to make the objects, technical solutions and advantages of the present invention clearer, the present invention will be further described in detail with reference to the accompanying drawings, the described embodiments should not be construed as limiting the present invention, and all other embodiments obtained by a person of ordinary skill in the art without creative efforts shall fall within the protection scope of the present invention.

In the following description, reference is made to "some embodiments" which describe a subset of all possible embodiments, but it is understood that "some embodiments" may be the same subset or different subsets of all possible embodiments, and may be combined with each other without conflict.

Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. The terminology used herein is for the purpose of describing embodiments of the invention only and is not intended to be limiting of the invention.

Before further detailed description of the embodiments of the present invention, terms and expressions mentioned in the embodiments of the present invention are explained, and the terms and expressions mentioned in the embodiments of the present invention are applied to the following explanations.

1) The XMLHttpRequest belongs to a network component, can interact with a server by using an XMLHttpRequest object, acquires data from a Uniform Resource Locator (URL), and does not need to refresh the whole page, so that the local content of the page is allowed to be updated without influencing the operation of a user.

2) JavaScript, a lightweight, interpretative, or just-in-time compilation type programming language with function preference, is a scripting language belonging to the Web, has been widely applied to Web application development, and is often used to add various dynamic functions to a Web page, thereby providing a smoother and more beautiful browsing effect for users. Generally, a JavaScript script is a method of declaring JS (abbreviation of JavaScript) code embedded in HyperText markup Language (HTML) code by using < script > tag to implement the function of JS itself in a page. The < script > tag can declare the JS code location local to the front end, or the JS code location on the network.

3) The Web Worker is a JavaScript multithreading environment, allows a main thread (namely a rendering process) of a browser to create a Web Worker thread, and allocates some tasks to the Worker thread to run. And when the main thread runs, the Worker thread runs in the background, the two threads are not interfered with each other, and when the Worker thread finishes a calculation task, a result is returned to the main thread. This has the advantage that some computationally intensive or highly delayed tasks are burdened by the Worker thread and the main thread (which is typically responsible for UI interactions) is very fluid and not blocked or slowed down.

The inventor finds that the JavaScript used by the front end can only use a single thread to process all tasks at present, and when pulling the server data, only one URL can be requested at a time, and the data is pulled to the front end in a serial manner to be rendered. Even if asynchronous operations can be performed using functions such as Promise, Async/Await, etc., all tasks are completed in the main thread (i.e., the thread executing the rendering engine), and only one task (parsing HTML and CSS or interpreting JS) can be processed at the same time. If the JS thread loads a large file or requests a segment of data, and because the JS thread and the rendering thread are mutually exclusive, the JS thread occupies the CPU for a long time, which causes that the rendering thread can not be executed by the CPU (blocking rendering), thereby causing long-term blank or jamming of a page and seriously influencing user experience.

In contrast, it is considered that a plurality of new threads are created without using a main thread to request page data, and the created plurality of new threads are used to request page data, so that a plurality of new threads can be created in a multi-thread environment independent of a browser environment; correspondingly allocating a plurality of data request tasks included in a page to be rendered in a browser environment to a plurality of new threads, so that the new threads acquire page data from a server according to the data request tasks allocated to the new threads; and receiving page data respectively acquired by the plurality of new threads from the server, and rendering the page based on the received page data.

In view of this, embodiments of the present invention provide a page rendering method, an apparatus, an electronic device, and a computer-readable storage medium, which can avoid long-term jamming or blank of a page, and improve user experience.

An exemplary application of the page rendering apparatus provided by the embodiment of the present invention is described below, and the page rendering apparatus provided by the embodiment of the present invention may be implemented as various types of user terminals such as a notebook computer, a tablet computer, a desktop computer, a set-top box, a mobile device (e.g., a mobile phone, a portable music player, a personal digital assistant, a dedicated messaging device, a portable game device), and the like.

Referring to fig. 1, fig. 1 is a schematic diagram of an alternative implementation architecture of the page rendering method according to the embodiment of the present invention, in which a user terminal 400 is connected to a server 200 through a network 300, and the server 200 is connected to a database 100, where the network 300 may be a wide area network or a local area network, or a combination of both.

As shown in fig. 1, a client 410 (the client 410 may be various browsers or various applications including a browser environment, such as a social network client) on a user terminal 400 creates a plurality of new threads in a multi-thread environment independent of the browser environment in advance, then parses a page file of a page to be rendered, and when a plurality of page data that needs to be obtained from the outside are sequentially parsed, allocates data request tasks for obtaining the plurality of page data to the created plurality of new threads in a one-to-one correspondence manner, so that the plurality of new threads send corresponding data obtaining requests to a server 200 through a network 300 according to the respectively allocated data request tasks. After receiving data acquisition requests respectively sent by a plurality of new threads of the client 410, the server 200 acquires page data matched with each data request task from the database 100, and returns the acquired page data to the corresponding new threads. The client 410, after receiving the page data acquired from the server 200 through the plurality of new threads, respectively, renders a page based on the received page data, and displays rendered page content in the user interface.

Referring to fig. 2, fig. 2 is a schematic structural diagram of a terminal 400 according to an embodiment of the present invention, where the terminal 400 shown in fig. 2 includes: at least one processor 410, memory 450, at least one network interface 420, and a user interface 430. The various components in the terminal 400 are coupled together by a bus system 440. It is understood that the bus system 440 is used to enable communications among the components. The bus system 440 includes a power bus, a control bus, and a status signal bus in addition to a data bus. For clarity of illustration, however, the various buses are labeled as bus system 440 in fig. 2.

The Processor 410 may be an integrated circuit chip having Signal processing capabilities, such as a general purpose Processor, a Digital Signal Processor (DSP), or other programmable logic device, discrete gate or transistor logic device, discrete hardware components, or the like, wherein the general purpose Processor may be a microprocessor or any conventional Processor, or the like.

The user interface 430 includes one or more output devices 431, including one or more speakers and/or one or more visual displays, that enable the presentation of media content. The user interface 430 also includes one or more input devices 432, including user interface components that facilitate user input, such as a keyboard, mouse, microphone, touch screen display, camera, other input buttons and controls.

The memory 450 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid state memory, hard disk drives, optical disk drives, and the like. Memory 450 optionally includes one or more storage devices physically located remote from processor 410.

The memory 450 includes either volatile memory or nonvolatile memory, and may include both volatile and nonvolatile memory. The nonvolatile memory may be a Read Only Memory (ROM), and the volatile memory may be a Random Access Memory (RAM). The memory 450 described in embodiments of the invention is intended to comprise any suitable type of memory.

In some embodiments, memory 450 is capable of storing data, examples of which include programs, modules, and data structures, or a subset or superset thereof, to support various operations, as exemplified below.

An operating system 451, including system programs for handling various basic system services and performing hardware-related tasks, such as a framework layer, a core library layer, a driver layer, etc., for implementing various basic services and handling hardware-based tasks;

a network communication module 452 for communicating to other computing devices via one or more (wired or wireless) network interfaces 420, exemplary network interfaces 420 including: bluetooth, wireless compatibility authentication (WiFi), and Universal Serial Bus (USB), etc.;

a presentation module 453 for enabling presentation of information (e.g., user interfaces for operating peripherals and displaying content and information) via one or more output devices 431 (e.g., display screens, speakers, etc.) associated with user interface 430;

an input processing module 454 for detecting one or more user inputs or interactions from one of the one or more input devices 432 and translating the detected inputs or interactions.

In some embodiments, the page rendering apparatus provided by the embodiments of the present invention may be implemented in software, and fig. 2 shows a page rendering apparatus 455 stored in a memory 450, which may be software in the form of programs and plug-ins, and includes the following software modules: a creation module 4551, an assignment module 4552, a reception module 4553 and a rendering module 4554, which are logical and thus may be arbitrarily combined or further split depending on the functions implemented. The functions of the respective modules will be explained below.

In the following, an exemplary application when the page rendering device provided by the embodiment of the present invention is implemented as a user terminal will be described by taking an example in which a client running on the user terminal implements the page rendering method provided by the embodiment of the present invention.

In order to better understand the technical solution provided by the embodiment of the present invention, before describing the page rendering method provided by the embodiment of the present invention, a structure of a browser is first described. The main function of the browser is to send a request to the server, and to show the network resources accessed by the user in a browser window. The network resource may be an HTML document, or may be a PDF, picture or other type. The location of the resource is specified by the user using a uniform resource locator.

Referring to fig. 3, fig. 3 is an alternative structural diagram of a browser according to an embodiment of the present invention. As shown in fig. 3, the main components of the browser include:

(1) a user interface including an address bar, forward/backward buttons, a bookmark menu, etc. In addition to the requested page displayed in the browser's main window, various portions of the other display belong to the user interface.

(2) A browser engine to communicate instructions between the user interface and the rendering engine.

(3) And the rendering engine is responsible for displaying the requested content. If the requested content is HTML, it is responsible for parsing the HTML and CSS content and displaying the parsed content on the screen. The HTML is used for specifying elements displayed in the page, including characters, pictures, links, even non-character elements such as music and programs; the CSS is used to specify the style in which page elements are displayed, which can make the page more aesthetically pleasing.

The rendering engine is the core part of each browser, so the rendering engine, also called browser kernel, has the responsibility of rendering. By default, rendering engines can display HTML and XML documents and pictures, and browser rendering engines can display other types of content as well, through plug-ins (or browser extensions). For example, a PDF document can be displayed using a PDF viewer plug-in. The rendering engine initially obtains the content of the requested document from the network layer, typically in 8K blocks. After acquiring the document content, the rendering engine starts formal work, and the basic flow thereof comprises: building render tree-layout render tree-drawing render tree. The specific process is as follows: the rendering engine parses the HTML document and translates the tags in the document into a node-dom tree, i.e., a "content tree". At the same time, it also parses style data in external CSS files and style tags, which along with the "visible content" in HTML is used to build another tree, the render tree. The render tree consists of a number of matrices with visual properties (e.g. color, size, etc.) that will be displayed on the screen in the correct order. And after the rendering tree is constructed, entering a layout processing stage, namely distributing a screen coordinate for each node, and then drawing (painting), namely traversing the rendering tree, and drawing each node by using a UI rear-end layer.

It should be noted that the above process is completed step by step, for better user experience, the rendering engine will present the content on the screen as early as possible, and will not wait until all the HTML documents are parsed, and then build and lay out the rendering tree, which displays a part of the content after parsing a part of the content, and at the same time, may download other content through the network. Furthermore, the rendering engine employs a single thread, and almost all operations (except network operations) are performed in the single thread, for example, in Firefox and Safari, the rendering thread is the main thread of the browser.

(4) Network: for network calls, such as HTTP requests, the interface is platform independent and provides the underlying implementation for all platforms.

(5) User interface backend for drawing basic widgets, such as combo boxes and windows, discloses a platform independent generic interface, while using the operating system's user interface methods at the bottom.

(6) A JavaScript interpreter for parsing and executing JavaScript code, for example, the JavaScript interpreter of Chrome is V8.

(7) Data storage, which is a persistent layer, the browser needs to keep various data on the hard disk, such as cookies, and the new HTML specification defines a "web database," which is a complete (but lightweight) in-browser database.

Referring to fig. 4, fig. 4 is an optional flowchart of a page rendering method according to an embodiment of the present invention, and will be described with reference to the steps shown in fig. 4.

In step S401, the client creates a plurality of new threads in a multi-threaded environment independent of the browser environment.

In some embodiments, when the address bar of the client receives the website input by the user, the client sends a request to the server and receives the HTML file returned by the server. Then, the client analyzes the HTML file returned by the server. The use of tags in the HTML file indicates the page data required to render the page. The data indicated by the tag may be locally pointed (i.e. retrieved from the URL's backend server along with the HTML file) or may be pointed to an external URL (i.e. the data is not stored in the URL's backend server but stored in a third-party server), and when pointing to the external URL, the browser needs to resend the network request for retrieval. That is, when the content specified by the tag is a URL to the outside, the client creates a plurality of new threads in a multi-threaded environment independent of the browser environment, and allocates a data request task for acquiring page data to the created plurality of new threads to execute corresponding network requests.

In step S402, the client allocates a plurality of data request tasks included in the page to be rendered in the browser environment to a plurality of new threads.

Here, the client correspondingly allocates a plurality of data request tasks included in the page to be rendered in the browser environment to a plurality of new threads, which can be implemented as follows: aiming at any new thread in the multiple new threads, the main thread of the client sends a corresponding communication message to any new thread through a communication interface between the browser environment and the multithreading environment, wherein the communication message comprises a task name of a data request task to be executed by any new thread and a uniform resource locator corresponding to the data request task.

Illustratively, a main thread of a browser creates a plurality of Worker threads by calling a Worker () constructor by adopting a new command, and then the main thread calls a Worker.

It should be noted that, before the main thread sends a communication message to the new thread through the communication interface between the browser environment and the multithreading environment, a naming rule of the data request task needs to be formulated, and a task name corresponding to each of the data request tasks is determined according to the naming rule, so that the new thread can execute the corresponding task according to the task name.

For example, assuming that a task name such as user/getUserInfo is defined, worker.postmessage ('user/getUserInfo') indicates that the task to be executed by the Worker thread is the getUserInfo method in user.js.

In other embodiments, when the main thread of the client sends a communication message to the new thread through the communication interface between the browser environment and the multi-thread environment, a corresponding message number may be added to each communication message, and the message and the corresponding message number are sent to the new thread together. And then, creating an object in a multi-thread environment, and defining a callback function for each message number based on the object, so that the execution state of the data request task distributed to each of the plurality of new threads can be monitored based on the defined callback function, and when a new thread completing the data request task exists in the plurality of new threads, the data request task in the queue to be executed is distributed to the new thread completing the data request task, thereby greatly improving the efficiency of acquiring page data.

Illustratively, when a main thread of a browser sends a message to a Worker thread through a postMessage () method, a corresponding message number is added to each message, the message and the message number are sent to the Worker thread together, then, a Promise object is created, and a callback function is defined for each message number based on the created Promise object, so that data request tasks executed by a plurality of Worker threads can be monitored respectively. In addition, the tasks of different functional modules can be managed by using different JS files based on the created Promise object, and the task executed corresponding to each message is formulated by formulating the naming rule of the task in advance, so that the operation required to be executed after each task is finished can be managed independently. The Promise is a constructor, and has all, reject, resolve and other methods belonging to its own private, and also has the method then, catch and the like belonging to the instance object call on the prototype. The specific application method of the Promise is as follows: firstly, a new instance object is assigned to p, and a constructor of the Promise receives a parameter which is a function; and two parameters are imported: a reset and a reject respectively representing a callback function after the asynchronous operation is successfully executed and a callback function after the asynchronous operation is unsuccessfully executed; then a timer setTimeout is set in the reset, an asynchronous operation is started, two seconds later, the icessun is output, and a resolve method is called.

In some embodiments, steps S401 to S402 shown in fig. 4 may be implemented by steps S501 to S504 shown in fig. 5, which will be described in conjunction with the steps shown in fig. 5.

In step S501, the client creates a plurality of new threads in a multithread environment independent of the browser environment in advance.

In step S502, the client parses the page file of the page to be rendered.

In step S503, when the multiple page data that needs to be obtained from the outside are sequentially parsed, the client allocates the data request tasks for obtaining the multiple page data to the new idle threads in a one-to-one correspondence manner.

Here, in order to further increase the page rendering speed, the client may also create a plurality of new threads in a multithread environment independent of the browser environment in advance, and then when the client parses the HTML file returned by the server, a plurality of data request tasks corresponding to a plurality of page data that need to be obtained from the outside are sequentially parsed and allocated to the idle new threads in a one-to-one correspondence manner.

Illustratively, the main thread of the browser adopts a new command, and a plurality of Worker threads are created in advance by calling a Worker () constructor. When a user accesses a website for the first time, the browser sends a request to the server, the server returns a corresponding HTML file, then the browser starts to load an HTML code, and finds that a link tag references an external CSS and a JS file in a head tag, at the moment, the browser allocates a data request task 1 corresponding to the external CSS to an idle Worker thread 1 for execution, and allocates a data request task 2 corresponding to the external JS file to an idle Worker thread 2 for execution, so that synchronous data request is realized, and the request time is saved.

In other embodiments, in order to save system resources of the client, the new thread may be immediately turned off after the new thread completes the corresponding data request task.

Illustratively, after a Worker thread executes a data request task, a main thread in the browser terminates the Worker thread by calling a worker.terminate () method; of course, the Worker thread itself can also be closed by calling the self () method.

In step S504, when there is no idle new thread, the client stores the data request task to be executed into the queue to be executed.

In some embodiments, when the number of new threads created by the client is small, for example, the client creates 3 new threads, and the number of page data that needs to be acquired from the outside is 4, at this time, the client may store the data request tasks to be executed (i.e., the remaining 1 data request task) into the queue to be executed, and listen to the execution status of the data request tasks executed by each new thread, and when it is listened that there is a new thread that has completed the data request task, allocate the data request tasks in the queue to be executed to the new threads that have completed the tasks.

In step S403, the plurality of new threads of the client acquire page data from the server according to the data request tasks respectively assigned thereto.

Here, after receiving messages respectively sent by the main thread of the client (each message includes a task name corresponding to a data request task that the new thread needs to execute), the new threads match the task names according to the task names of the data request tasks respectively allocated to the new threads, execute the corresponding data request tasks, and acquire the matched page data from the server.

In some embodiments, after each new thread receives corresponding page data returned by the server, the received page data may be further cleaned, calculated, and reassembled (for example, combining the same types of page data together) and the processed page data is sent to the rendering thread for rendering.

In other embodiments, the page data may also be preprocessed by the server. Illustratively, when receiving data acquisition requests respectively sent by a plurality of new threads, the server queries matched page data from the database according to each data request task, performs cleaning, calculation and recombination processing on the queried page data, and returns the processed page data to the corresponding new threads, so that the workload of the new threads can be reduced.

In step S404, the client receives page data acquired by the plurality of new threads from the server, respectively, and renders a page based on the received page data.

In some embodiments, when receiving page data acquired by any one of the new threads, the rendering thread of the client may render a part of the page in real time based on the page data acquired by the any one of the new threads, that is, the rendering thread may not wait until all the new threads acquire the page data before starting rendering the page, but may perform real-time rendering according to the page data returned by each of the new threads. Therefore, when the client receives the human-computer interaction operation aiming at the partial page, the rendering thread in the browser environment can be called to respond to the human-computer interaction operation.

For example, assuming that the main thread receives the page data a acquired by the new thread 1 at the current moment, the main thread may render a partial page in real time according to the page data a acquired by the new thread 1, and then, if a human-computer interaction operation is received in the partial page, the rendering thread may be directly invoked to respond, so that the user does not need to wait, and the user experience is improved.

In other embodiments, when the main thread of the client receives a jump operation for a page, the data request tasks executed by a plurality of new threads may be terminated, and a plurality of new data request tasks corresponding to the jumped new page may be correspondingly allocated to the plurality of new threads, so that the plurality of new threads obtain new page data from the server according to the respective allocated new data request tasks, and finally, the main thread receives the new page data respectively obtained by the plurality of new threads from the server, and renders the new page according to the new page data.

For example, it is assumed that when a main thread of a client receives a jump operation from a page a to a page B, a data request task executed by a plurality of new threads is terminated, where the data request task is used to acquire page data of the page a, and a plurality of new data request tasks corresponding to the page B after the jump are correspondingly allocated to the plurality of new threads, so that the plurality of new threads acquire the page data of the page B from a server according to the respective allocated new data request tasks, and finally, the main thread receives the page data of the page B acquired by the plurality of new threads from the server, and renders the page B according to the page data of the page B.

The page rendering method provided by the embodiment of the invention avoids page jamming caused by the main thread requesting the page data by creating a plurality of new threads in a multi-thread environment independent of a browser environment and utilizing the created plurality of new threads to request the page data, and simultaneously, the page data can be requested in batches based on the created plurality of new threads without calling an application program interface for processing data for many times, so that a back-end developer is not required to improve the interface, and the workload of back-end development is also reduced.

Continuing with the exemplary structure in which the page rendering device 455 provided by the embodiments of the present invention is implemented as a software module, in some embodiments, as shown in fig. 2, the software module stored in the page rendering device 555 of the memory 450 may include: a creation module 4551, an assignment module 4552, a reception module 4553 and a rendering module 4554.

A creation module 4551 for creating a plurality of new threads in a multi-threaded environment independent of a browser environment; the allocating module 4552 is configured to correspondingly allocate a plurality of data request tasks included in a page to be rendered in the browser environment to a plurality of new threads, so that the plurality of new threads obtain page data from the server according to the data request tasks allocated to the new threads; a receiving module 4553, configured to receive page data acquired by a plurality of new threads from a server respectively; a rendering module 4554 configured to render the page to be rendered based on the received page data.

In some embodiments, the creating module 4551 is further configured to create a plurality of new threads in a multi-thread environment independent of a browser environment in advance before parsing the page file of the page to be rendered; the page rendering device 455 further includes an analyzing module 4555, configured to, when a page file of a page to be rendered is analyzed and a plurality of pieces of page data to be acquired are sequentially analyzed, allocate a data request task for acquiring the plurality of pieces of page data to the idle new thread in a one-to-one correspondence manner; the page rendering device 455 further comprises a storage module 4556, which is configured to store the data request task to be executed into the queue to be executed when there is no new thread that is idle.

In some embodiments, the page rendering apparatus 455 further includes a sending module 4557, configured to send, for any new thread in the plurality of new threads, a corresponding communication message to any new thread through the communication interface between the browser environment and the multi-thread environment; the communication message includes a task name of a data request task that any new thread needs to execute, and a uniform resource locator corresponding to the data request task.

In some embodiments, the page rendering device 455 further includes an obtaining module 4558, configured to obtain a naming rule of the data request task, and determine a task name corresponding to each of the data request tasks according to the naming rule.

In some embodiments, the creating module 4551 is further configured to add, for each communication message, a corresponding message number; creating an object in a multithreading environment, and defining a callback function for each message number based on the object; monitoring the execution states of the data request tasks distributed in the new threads respectively based on the callback function; and when monitoring that a new thread completing the data request task exists in the plurality of new threads, distributing the data request task in the queue to be executed for the new thread completing the data request task.

In some embodiments, the page rendering device 455 further includes a processing module 4559, configured to perform cleaning, calculation, and reassembly processing on the acquired page data when each new thread acquires the page data from the server, and send the processed page data to the browser environment for rendering.

In some embodiments, the rendering module 4554 is further configured to, when receiving the page data acquired by any one of the plurality of new threads, render the partial page in real time based on the page data acquired by any one of the new threads; the receiving module 4553 is further configured to, when receiving the human-machine interaction operation for the partial page, invoke a rendering thread in the browser environment to respond to the human-machine interaction operation.

In some embodiments, the receiving module 4553 is further configured to terminate the data request tasks executed by the new threads when a jump operation for the page is received; the allocating module 4552 is further configured to correspondingly allocate a plurality of new data request tasks included in the skipped new page to a plurality of new threads, so that the plurality of new threads obtain new page data from the server according to the new data request tasks respectively allocated to the new threads; a receiving module 4553, further configured to receive new page data acquired by the multiple new threads from the server respectively; and a rendering module 4554 configured to render the new page based on the received new page data.

It should be noted that the description of the apparatus according to the embodiment of the present invention is similar to the description of the method embodiment, and has similar beneficial effects to the method embodiment, and therefore, the description is omitted. The inexhaustible technical details in the page rendering device provided by the embodiment of the invention can be understood according to the description of any one of the figures 4-5 and 9.

In the following, an exemplary application of the embodiment of the present invention in a browser will be described, and when the browser accesses a page, since only one JS thread can be executed in each page of the browser (in the JS thread, a JS engine will interpret and execute JS codes in the page), an additional thread cannot be created, and a parallel task cannot be performed. When the JS thread loads a large file or requests a segment of data, because the JS thread and the rendering thread are mutually exclusive, the JS thread occupies the CPU for a long time, which causes that the rendering thread can not be executed by the CPU (the rendering is blocked), thereby causing the long-term blank or jamming of the page. That is, the main thread of the browser (each tab of the browser can run with a corresponding main thread) handles all tasks, which is not only easily blocked by data request or high-density computing logic, but also some UI interactions, when the user requests data after operating, the user may be in a waiting state for a while, which is not friendly.

In view of the above problems, an embodiment of the present invention provides a page rendering method, where a Web Worker Application Program Interface (API) provided by a browser is used to create a multithreading environment for JavaScript, and based on support of the Web Worker on XMLHttpRequest, tasks of part of data requests are allocated in threads of the Web Worker to be processed, and meanwhile, a main thread (i.e., a rendering thread) of a page may process logic (e.g., parsing an HTML document or CSS, etc.) on the page, so as to achieve data preloading and speed improvement of front-end rendering data. On the basis, a callback function is added by combining with the Promise, each task in the thread can be monitored respectively, and the operation to be executed after each task is finished is managed independently. The Promise is a construction function, and has several methods such as all, reject, resolve and the like on the self, and has several methods such as the then, catch and the like on the prototype. The Promise object is used to represent the final state (completion or failure) of an asynchronous operation, and the corresponding returned value. The Promise subject has the following three states: the initial state (pending) is neither a success nor a failure state (i.e. waiting or in progress, indicating that no result has been obtained), a success (filled) and a failure (rejected). The state of the Promise object is not affected by the outside world, and only as a result of asynchronous operation, the current state can be determined, and any other operation cannot change the state. Furthermore, once the state changes, it will not change, and this result can be obtained at any time, and the change of state of the Promise object is only possible in two ways: from pending to fulfilled and from pending to rejected. As long as both of these events occur, the state solidifies and does not change, and the result is maintained, which is referred to as set.

For example, when a user wants to access a certain page of the internal system shown in fig. 6, when a directory (601) and specific information (602) in the page are exposed, a browser needs to obtain corresponding page data from the outside, that is, the page data (701, including list and info) shown in fig. 7 needs to be pulled to render the page by requesting multiple background APIs, at this time, multiple Web Worker threads may be created, the page data is requested by using a synchronous request (801) manner shown in fig. 8 based on the created multiple Web Worker threads, for example, two Web Worker threads are created, and target (list) and specific information (info) data required for requesting the page are synchronized by the two Web Worker threads, so that the total duration of the request is saved, and the page is rendered more quickly.

Referring to fig. 9, fig. 9 is a schematic flowchart of a further alternative page rendering method according to an embodiment of the present invention, which will be described with reference to the steps shown in fig. 9.

In step S901, the browser receives an operation of accessing a page by the user.

For example, when a user wants to access a page, and enters the website of the page in the address bar of the browser interface, the web component of the browser first retrieves the HTML file of the page, in which the page data required for rendering the page is indicated using the tag. The data indicated by the tag may be directed to local (i.e. retrieved from the URL's backend server along with the HTML file), or may be directed to external URLs (i.e. the data is not stored in the URL's backend server, but is stored in a third-party server), and at this time, the network request needs to be sent again for acquisition. When the content designated by the label is an external URL, the browser creates a plurality of Web Worker threads to execute the corresponding network request.

In step S902, the browser creates a plurality of Web Worker threads.

Here, the main thread of the browser uses the new command to open a new Worker thread by calling the Worker () constructor.

The parameter of the Worker () constructor is a script file that is the task that the Worker thread is going to perform. Since the Worker thread cannot read the local file, this script must come from the network, and if the download is not successful, the Worker will silently fail. After the creation of the Worker thread is completed, the main thread can call a worker.postmessage () method to send a message to the Worker thread, wherein the parameters of the worker.postmessage () method are the data transmitted to the Worker thread by the main thread. It may be of various data types, including binary data. And then, the main thread appoints a monitoring function through the Worker.

It should be noted that, by using messages of native Web Worker, worker.postmessage ('xx') and worker.postmessage ('yy'), return data is received through the same worker.onmessage, and all subsequent logic is processed in the onmessage, which results in that the returned data cannot correspond to a corresponding task, and thus data confusion is caused.

For the above problem, in some embodiments, the page rendering method provided in the embodiments of the present invention may further introduce a premium object into the Worker, so that the task and the callback function that need to be executed after the message is sent can be defined at the step of the postMessage, and the task and the callback function of each functional module are separately managed, thereby solving the problem that the returned data cannot be corresponding to the corresponding task, and avoiding confusion of the data.

The following is a description of a specific process for monitoring and managing tasks with a Promise object:

monitoring based on the Promise object:

1) firstly, assigning a message number (message ID) to each message to be used as a unique identifier, then, recombining the sent messages into a message + number (ID + message), and sending the recombined messages to a Worker thread.

Examples of assigning values to messages are as follows:

the message number is 0;

the message number is the message number + +;

the messages sent by recombination are the message plus the message serial number;

2) next, a Promise object is created, a callback function is defined for each messageID, including the handling of a message sending failure (error) and the handling of a message sending success (result), and then the postMessage method of native Web Worker is executed to send a message to the Worker thread.

An example of creating a Promise object is as follows:

creating a Promise object;

defining a callback function for each message;

if fails;

executing the processing of message sending failure;

else；

executing the processing of successful message sending;

sending a message to a Worker thread;

3) finally, the execution state of the task is monitored through a monitoring method of the native Worker, and specifically, the execution states of the tasks executed by the Worker threads are respectively monitored through an addEventListener ('message') monitoring method of the native Web Worker.

An example of listening through addEventListener is as follows, for example:

monitoring through addEventListener;

the message number is message [1 ];

failure is message [2 ];

success is message [3 ];

executing the callback function defined in the previous step;

if there is no callback function;

returning;

management based on the Promise object:

1) and dividing according to the functional modules, and managing tasks of different functional modules by using different JS files.

By way of example, the tasks of three different functional modules, user.js file, team.js file and log.js file, can be managed separately using user.js file, team.js file and log.js file, respectively.

2) And formulating the task correspondingly executed by each message by formulating the naming rule of the task in advance.

Illustratively, a task name such as user/getUserInfo is defined, then worker.postmessage ('user/getUserInfo') indicates that the task to be executed by the Worker thread is the getUserInfo method in user.js.

In step S903, the browser requests the server for page data necessary for rendering a page through the newly created multiple Web Worker threads.

Here, the main thread sends a message including the task name to be executed to each of the plurality of Web Worker threads by a postMessage () method, so that the plurality of Web Worker threads execute corresponding logic by matching the task name according to the task name assigned to each of the plurality of Web Worker threads, and acquire corresponding data from the server.

For example, assuming that a Worker thread 1 receives a task name of user/getUserInfo contained in a message sent by a main thread, the Worker thread 1 executes a getUserInfo method in user.js; assuming that the task name contained in the message sent by the main thread is team/getteam info received by the Worker thread 2, the Worker thread 2 executes the getteam info method in team.

In step S904, the plurality of Web Worker threads transmit page data each acquired from the server to the main thread.

Here, after the Worker thread acquires the page data, the acquired page data may be further processed by data filtering, data reorganization (for example, data of the same type are combined together), and the like, and then the processed data is returned to the main thread. Specifically, the Worker thread sends a message to the main thread by a postMessage () method.

In step S905, the main thread renders a page according to page data transmitted by the plurality of Web Worker threads.

The main thread receives data returned by the multiple Worker threads through the postMessage method, performs page rendering according to the received page data, and synchronizes the data to the local for caching.

The page rendering method provided by the embodiment of the invention has the following beneficial effects:

1. the method solves the performance defect of a congenital single thread of the JavaScript language, requests data of a server in a Worker thread, and avoids page jamming caused by data request in a main thread.

2. Server data is preloaded in advance through the Worker thread, so that page blank when data is lacked is avoided, and user experience is improved.

3. The workload of back-end development is reduced, the API does not need to be called for processing data for multiple times, batch requests can be made in a Worker thread, and a back-end developer does not need to modify an interface.

Embodiments of the present invention provide a computer-readable storage medium storing executable instructions, which when executed by a processor, cause the processor to perform a page rendering method provided by embodiments of the present invention, for example, the page rendering method shown in fig. 4-5 and 9.

In some embodiments, the storage medium may be memory such as FRAM, ROM, PROM, EPROM, EEPROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or may be various devices including one or any combination of the above memories.

In some embodiments, executable instructions may be written in any form of programming language (including compiled or interpreted languages), in the form of programs, software modules, scripts or code, and may be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

By way of example, executable instructions may correspond, but do not necessarily have to correspond, to files in a file system, and may be stored in a portion of a file that holds other programs or data, such as in one or more scripts stored in a hypertext Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub-programs, or portions of code).

By way of example, executable instructions may be deployed to be executed on one computing device or on multiple computing devices at one site or distributed across multiple sites and interconnected by a communication network.

In summary, the embodiment of the invention has the following beneficial effects:

1) the method solves the performance defect of a congenital single thread of the JavaScript language, and avoids page jamming caused by the main thread requesting the page data by requesting the page data through a plurality of created Worker threads.

2) The server data is preloaded in advance through the created plurality of Worker threads, so that page blank caused by data lack is avoided, and user experience is improved.

3) The page data can be requested in batch through a plurality of created Worker threads, an application program interface does not need to be called for processing data for many times, a back-end developer does not need to modify the interface, and the back-end development workload is reduced.

The above description is only an example of the present invention, and is not intended to limit the scope of the present invention. Any modification, equivalent replacement, and improvement made within the spirit and scope of the present invention are included in the protection scope of the present invention.

Claims

1. A method for rendering a page, the method comprising:

2. The method of claim 1,

the creating of the plurality of new threads in the multi-threaded environment independent of the browser environment comprises:

before analyzing a page file of the page to be rendered, creating a plurality of new threads in a multithreading environment independent of a browser environment in advance;

correspondingly allocating a plurality of data request tasks included in the page to be rendered in the browser environment to the plurality of new threads, including:

when the page file of the page to be rendered is analyzed and a plurality of page data needing to be acquired are sequentially analyzed, allocating data request tasks for acquiring the plurality of page data to the idle new threads in a one-to-one correspondence manner;

the method further comprises the following steps:

and when no idle new thread exists, storing the data request task to be executed into the queue to be executed.

3. The method according to claim 1, wherein the allocating the plurality of data request tasks included in the page to be rendered in the browser environment to the plurality of new threads correspondingly comprises:

for any new thread in the plurality of new threads, sending a corresponding communication message to the any new thread through a communication interface between the browser environment and the multi-thread environment;

the communication message includes a task name of a data request task that needs to be executed by any new thread and a uniform resource locator corresponding to the data request task.

4. The method of claim 3, wherein prior to sending a corresponding communication message to any of the new threads over the communication interface between the browser environment and the multi-threaded environment, the method further comprises:

and acquiring a naming rule of the data request task, and determining task names corresponding to the data request tasks according to the naming rule.

5. The method of claim 3, further comprising:

adding a corresponding message number for each communication message;

creating an object in the multi-threaded environment and defining a callback function for each of the message numbers based on the object;

monitoring the execution state of the data request task distributed to each of the new threads based on the callback function;

and when monitoring that a new thread which completes the data request task exists in the plurality of new threads, distributing the data request task in the queue to be executed for the new thread which completes the data request task.

6. The method of claim 1, further comprising:

when each new thread acquires page data from the server, the acquired page data is cleaned, calculated and recombined, and

and sending the processed page data to the browser environment for rendering.

7. The method of claim 1, wherein the rendering the page based on the received page data comprises:

when page data acquired by any new thread in the plurality of new threads is received, rendering a part of pages in real time based on the page data acquired by any new thread;

the method further comprises the following steps:

and when receiving the human-computer interaction operation aiming at the partial page, calling a rendering thread in the browser environment to respond to the human-computer interaction operation.

8. The method of claim 1, further comprising:

when a jump operation for the page is received, terminating the data request tasks executed by the new threads, and

correspondingly distributing a plurality of new data request tasks included in the jumped new page to the plurality of new threads so as to enable the new threads to be started to jump to the new page

The new threads acquire new page data from the server according to the respectively allocated new data request tasks;

receiving new page data respectively acquired by the new threads from the server, and rendering the new page based on the received new page data.

9. The method of claim 1, further comprising:

each new thread acquires page data corresponding to the distributed data request task from the server;

and the acquired page data is acquired by the server by querying from a database according to the data request task and cleaning, calculating and recombining a query result.

10. An apparatus for rendering a page, the apparatus comprising: