CN117435182A

CN117435182A - Cross-end rendering frame construction method, rendering method device, equipment and medium

Info

Publication number: CN117435182A
Application number: CN202311435380.7A
Authority: CN
Inventors: 邵霁宇
Original assignee: Shenzhen Rabbit Exhibition Intelligent Technology Co ltd
Current assignee: Shenzhen Rabbit Exhibition Intelligent Technology Co ltd
Priority date: 2023-10-30
Filing date: 2023-10-30
Publication date: 2024-01-23

Abstract

The application discloses a cross-end rendering frame construction method, a cross-end rendering method, a device, electronic equipment and a storage medium, and the application carries out the following frame improvement based on a router web frame: abstract extracting the inter-terminal JS runtime specification, unifying JS runtime library based on the inter-terminal JS runtime specification to determine inter-terminal JS runtime, and repackaging related APIs by JS language to complete the butt joint of APIs and runtime at both the original terminal and browser terminal, and realizing rendering logic at both the terminals. When a rendering task is executed, a cross-end rendering library corresponding to the cross-end rendering frame is loaded in a rendering item, and rendering with the same effect can be realized at a native end and a browser end based on the library and configuration parameters.

Description

Cross-end rendering frame construction method, rendering method device, equipment and medium

Technical Field

The present disclosure relates to the field of computer technologies, and in particular, to a method for constructing a cross-end rendering frame, a method, a device, equipment, and a medium for cross-end rendering.

Background

The Fluter is a UI framework, and can quickly construct a high-quality native user interface on iOS and Android. It has cross-platform development characteristics, supporting IOS, android, web three-terminal. However, the cross-end rendering scheme for the cross-raw end and the Web browser end is still lacking at present. WebF (Flutter web) is a newly proposed rendering scheme based on Flutter, which realizes a self-drawing rendering engine (layout engine, CSS, elements, etc.) based on Flutter, realizes JavaScript Engine based on native application at an upper layer, injects BOM and DOM capabilities into the engine, and realizes a technical architecture of a browser-like. As shown in FIG. 1, the WebF framework may be simply represented as a three-tier architecture, respectively, an underlying platform capability, a framework rendering capability, and a logical running capability. The cross-end rendering mechanism in the bottom platform capability layer and the framework rendering capability layer is the original layered design of the Flutter. The WebF encapsulates the related realization of the Web API of the native terminal in the frame rendering capability layer, and expands the logic operation capability layer, wherein the layer is mainly used for the execution of JS codes and comprises the encapsulation of the Web API realization of the frame rendering capability layer during the native JS operation.

In general, the underlying platform capability of the Flutter supports cross-end rendering, while various rendering frameworks and methods including WebF only realize rendering of a native end at present, and the rendering capability of a browser end is relatively poor.

Therefore, how to provide a rendering method across a native end and a Web browser end is a problem to be solved.

Disclosure of Invention

Based on this, it is necessary to provide a cross-end rendering framework construction method, a cross-end rendering method, a device, equipment and a medium to solve the above technical problems, so as to implement cross-end rendering of a native end and a browser end.

A method for constructing a cross-end rendering frame based on a Flutter web frame, wherein the Flutter web frame comprises an embedded layer, a WebF rendering layer and a WebF logic layer, the cross-end rendering frame comprises the embedded layer, the cross-end rendering layer and the cross-end logic layer, and the construction method comprises the following steps:

determining a cross-terminal JS runtime specification;

determining a cross-terminal JS runtime at the cross-terminal logic layer based on the cross-terminal JS runtime specification; and

repackaging the Web API of the WebF logic layer by using JS language to form the Web API of the cross-terminal logic layer;

and repackaging the Web API implementation in the WebF rendering layer to obtain the Web API implementation of the cross-end rendering layer, so that the Web API implementation in the cross-end rendering layer can be in butt joint with the cross-end JS runtime.

In this embodiment of the present application, the determining the cross-end JS runtime specification includes:

abstract out the universal JS runtime base class;

defining a target runtime function of the cross-terminal JS runtime, wherein the target runtime function comprises a runtime initialization function, a code execution function and a communication function;

and constructing a cross-language communication mode of Dart language and JS language between the cross-end logic layer and the cross-end rendering layer based on the structured clone character string.

In this embodiment of the present application, the cross-end logical layer includes an implementation code of a cross-end JS runtime, where the implementation code of the cross-end JS runtime includes an implementation code of a first JS runtime applied to a native end and an implementation code of a second JS runtime applied to a browser end, and determining, based on the cross-end JS runtime specification, when the cross-end logical layer determines the cross-end JS runtime, includes:

inheriting the JS runtime base class at the Dart side, and butting an API exposed by a flutter_ qjs library when packaging a native application to obtain an implementation code of the first JS runtime, wherein the implementation code of the first JS runtime is used for realizing the target runtime function at a native terminal;

and inheriting the JS runtime base class at the Dart side, interfacing an API exposed in a wasm environment of a browser by packaging a quick JS-emscript when the browser application is packaged, and obtaining a quick JS running environment to obtain an implementation code of the second JS runtime, wherein the implementation code of the second JS runtime is used for realizing the target runtime function at a browser end.

In this embodiment of the present application, the repackaging the Web API of the WebF logical layer using JS language includes:

creating a JSDK item, wherein the JSDK item utilizes JS language to realize the capability of analyzing an API (application program interface) of a DOM, and exposes the API of a DOM related event;

and implementing the API of the BOM in the JSDK project by using JS language.

In an embodiment of the present application, the repackaging the Web API implementation in the WebF rendering layer includes:

based on the communication mode of the structured clone character string, a cross-language communication mode of Web API realization in the Flutter Web architecture is adjusted so as to interface the Web API realization in the Flutter Dom rendering layer with the cross-end JS runtime.

The cross-end rendering method is realized based on the cross-end rendering frame constructed by the cross-end rendering frame construction method based on the Flutter web frame, and the method comprises the following steps:

loading a cross-end rendering library in a rendering item, wherein the cross-end rendering library is a component realization library corresponding to the cross-end rendering frame;

creating a cross-end rendering master controller according to the configuration parameters and the cross-end rendering library;

executing logic corresponding to inter-program cross-language communication in a rendering task by using the master controller, and creating a view controller; the view controller is configured to execute view rendering logic corresponding to the rendering task based on the cross-terminal JS runtime.

A cross-end rendering framework construction device based on a Flutter web framework, the Flutter web framework comprising an embedded layer, a WebF rendering layer and a WebF logic layer, the cross-end rendering framework comprising the embedded layer, the cross-end rendering layer and the cross-end logic layer, the construction device comprising:

the specification extraction module is used for determining a cross-terminal JS runtime specification;

the determining module is used for determining the cross-terminal JS runtime at the cross-terminal logic layer based on the cross-terminal JS runtime specification; and

the first packaging module is used for repackaging the Web API of the WebF logic layer by utilizing JS language to form the Web API of the cross-terminal logic layer;

and the second packaging module is used for repackaging the Web API implementation in the WebF rendering layer to obtain the Web API implementation of the cross-end rendering layer, so that the Web API implementation in the cross-end rendering layer can be in butt joint with the cross-end JS runtime.

In an embodiment of the present application, the specification extraction module is further configured to:

abstract out the universal JS runtime base class;

In this embodiment of the present application, the cross-end logical layer includes a cross-end JS runtime implementation code, where the cross-end JS runtime implementation code includes a first JS runtime implementation code applied to a primary end and a second JS runtime implementation code applied to a browser end, and the determining module is further configured to:

In an embodiment of the present application, the first packaging module is further configured to:

and implementing the API of the BOM in the JSDK project by using JS language.

In an embodiment of the present application, the second packaging module is further configured to:

A cross-end rendering device, implemented based on a cross-end rendering frame constructed by the above-mentioned cross-end rendering frame construction device based on a Flutter web frame, the device comprising:

the loading module is used for loading a cross-end rendering library in the rendering items, wherein the cross-end rendering library is a component realization library corresponding to the cross-end rendering frame;

the master controller creation module is used for creating a cross-end rendering master controller according to the configuration parameters and the cross-end rendering library;

the rendering module is used for executing logic corresponding to inter-program cross-language communication in a rendering task by utilizing the master controller and creating a view controller; the view controller is configured to execute view rendering logic corresponding to the rendering task based on the cross-terminal JS runtime.

An electronic device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, the processor implementing the steps of the above-described cross-end rendering framework construction method or the steps of the above-described cross-end rendering method when the processor executes the computer program.

A computer readable storage medium having stored thereon a computer program which when executed by a processor implements the steps of the above-described cross-end rendering framework construction method or the steps of the above-described cross-end rendering method.

In summary, the application provides a cross-end rendering frame construction method, a cross-end rendering method, a device, an electronic device and a storage medium, and the application performs the following frame improvement based on a Flutter web frame: abstract extracting the inter-terminal JS runtime specification, unifying JS runtime library based on the inter-terminal JS runtime specification to determine inter-terminal JS runtime, and repackaging related APIs by JS language to complete the butt joint of APIs and runtime at both the original terminal and browser terminal, and realizing rendering logic at both the terminals. When a rendering task is executed, a cross-end rendering library corresponding to the cross-end rendering frame is loaded in a rendering item, and based on the library, the rendering of the same effect can be realized at a native end and a browser end, so that a rendering method of the cross-native end and the browser end is provided.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings that are needed in the description of the embodiments of the present invention will be briefly described below, it being obvious that the drawings in the following description are only some embodiments of the present invention, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 is a schematic diagram of a Flutter web framework;

FIG. 2 is a flow chart illustrating a method of cross-end rendering framework construction according to an exemplary embodiment of the present application;

FIG. 3 is a cross-end framework diagram illustrating a cross-end rendering framework construction method according to an exemplary embodiment of the present application;

FIG. 4 is a flowchart illustrating a method of cross-end rendering framework construction, according to an exemplary embodiment of the present application;

FIG. 5 is a flowchart illustrating a method of cross-end rendering framework construction, according to an exemplary embodiment of the present application;

FIG. 6 is a flow chart illustrating a cross-end rendering method according to an exemplary embodiment of the present application;

FIG. 7 is a flow chart illustrating a cross-end rendering method according to another exemplary embodiment of the present application;

FIG. 8 is a block diagram of a cross-end rendering device, according to an exemplary embodiment of the present application;

FIG. 9 is a block diagram of a cross-end rendering framework building apparatus based on a Flutter web framework, according to an exemplary embodiment of the present application;

fig. 10 is a schematic diagram of an electronic device according to an exemplary embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is apparent that the described embodiments are some embodiments of the present application, but not all embodiments, and the embodiments described by referring to the drawings are exemplary and intended to be used for explaining the present application and not to be construed as limiting the present application. All other embodiments, which can be made by one of ordinary skill in the art based on the embodiments herein without making any inventive effort, are intended to be within the scope of the present application.

First, the noun concepts involved in the embodiments of the present application will be described:

flutter: the Flutter is a cross-platform UI framework of a google open source mobile terminal, and a high-quality native user interface can be quickly constructed on iOS and Android.

Fluter web: abbreviated as WebF, is a high performance rendering engine based on the W3C standard. The WebF bottom layer performs rendering based on the router, and multi-terminal consistency on iOS and Android is ensured through the self-drawing rendering characteristic. The upper layer is realized based on the W3C standard, and has very huge front-end developer ecology.

DOM: document Object Model, document object model, is a programming interface for representing and manipulating HTML, XML, and XHTML document structures.

BOM: browser Object Model, a browser object model, provides a set of objects and methods related to browser windows and browser environments.

Renderoject: is a core class in the router that is used to handle the logic of layout and drawing. Each Widget corresponds to a render object associated therewith in the router. The renderoject is responsible for calculating the position, size, style, etc. attributes of the Widget and drawing it onto the screen.

FIG. 2 is a flowchart illustrating a method of cross-end rendering framework construction, as shown in FIG. 2, according to an exemplary embodiment of the present application, the method of cross-end rendering framework construction comprising the steps of:

s201, determining a cross-terminal JS runtime specification.

In some embodiments, a cross-end JS runtime specification is determined for the cross-native JS runtime and the browser JS runtime.

As one possible implementation, the cross-end rendering framework of the present application is built based on a Flutter web (WebF) framework, such as the Flutter Dom hierarchical architecture shown in FIG. 3.

In fig. 1, the bottom platform capability in the WebF framework is an embedded layer, the framework rendering capability is a WebF rendering layer, and the logic running capability is a WebF logic layer. The underlying platform capability within the Flutter Dom hierarchical architecture in FIG. 3 is that the embedded layer is the same as the embedded layer in the WebF framework; the frame rendering capability is a cross-end rendering layer, and the layer is improved based on the WebF rendering layer so that the Web API can be run on a browser end and a native end; the logical operation capability is a cross-end logical layer, the native JS runtime and the browser JS runtime are determined based on the unified JS runtime specification and are realized as the cross-end JS runtime at the runtimes of different ends, and the Web API is encapsulated again at the time of the new cross-end JS runtime.

In some embodiments, when constructing the Flutter Dom hierarchical architecture, it is first necessary to analyze the WebF native JS runtime, and through analysis, design a cross-end JS runtime specification of the cross-native JS runtime and the browser JS runtime.

For example, the implementation scheme of the WebF existing JS runtime is analyzed, including the selection of the existing JS runtime and the cross-language communication mode:

Regarding JS runtime selection: the WebF directly introduces the C source code of the QuickJS library of the third party into the project, the QuickJS is built first when the project is built, and finally the product is packed, and for this reason, the WebF only supports the operation of the native environment.

Regarding the communication scheme: for better communication performance, the rendering layer (Dart) of WebF communicates with the logic layer (JS) by means of a transfer method, a memory pointer of data. The technical realization is that the cross-language interaction capability is realized by introducing a dart-ffi library.

And determining the universal capability of the cross-terminal JS in running and the Dart and JS communication mode based on the analysis, so as to determine the cross-terminal JS in running specification.

S202, determining the cross-terminal JS runtime at a cross-terminal logic layer based on the cross-terminal JS runtime specification.

And determining an API library for realizing cross-terminal JS runtime reference, and determining the cross-terminal JS runtime based on the cross-terminal runtime specification and the referenced API library.

S203, repackaging the Web API of the WebF logic layer by using JS language to form the Web API of the cross-end logic layer.

The capability of the Web API of the WebF logical layer at the new JS runtime, i.e., the cross-end JS runtime, is repackaged to obtain the Web API at the logical runtime capability layer (i.e., the cross-end logical layer) in the Flutter Dom hierarchical architecture shown in fig. 5.

S204, the Web API implementation in the WebF rendering layer is repackaged to obtain the Web API implementation of the cross-end rendering layer, so that the Web API implementation in the cross-end rendering layer can be in butt joint with the cross-end JS runtime.

And re-interfacing the repackaged Web APIs and the cross-terminal JS runtime with Web API implementations in the WebF rendering layer to determine new Web API implementations in the Flutter Dom layering architecture.

In some embodiments, the main implementation technology stack is changed into JS implementation during repackaging, so that the purpose that one Web API code runs in multi-terminal JS running is achieved.

According to the method for constructing the cross-end rendering frame, analysis is conducted on the original JS runtime in the WebF frame, a JS runtime library is extracted to unify cross-end JS runtime specifications, the WebF original JS runtime capability is replaced based on the analysis, so that the problem of cross-end consistency is solved, binding between Web API realization of the WebF and the original capability (C language) is relieved through Web API realization of repackaging, and the repackaged Web API realization can be used in the JS runtime environment of the browser. Based on the cross-end rendering framework, the rendering of the same effect can be realized at the original end and the browser end.

On the basis of the above embodiment, as shown in fig. 4, the "determination of the cross-end JS runtime specification" in step S201 described above "further includes the steps of:

S401, abstracting the general JS runtime base class.

Wherein, the base class contains general attributes and methods, and the subclass can reduce the repeated codes by inheriting the attributes and methods of the base class.

Based on the original JS runtime in the WebF framework, the universal capability of the cross-terminal JS runtime is determined, and the universal JS runtime base class is abstracted from the universal capability.

S402, defining a target runtime function of the cross-terminal JS runtime, wherein the target runtime function comprises a runtime initialization function, a code execution function and a communication function.

Define functions of runtime initialization, destruction, code execution, sending messages to the JS runtime, accepting messages from the JS runtime, turning on debug mode, etc.

S403, constructing a cross-language communication mode of Dart language and JS language between the cross-end logic layer and the cross-end rendering layer based on the structured clone character string.

Because the browser does not support direct use of dart: ffi for cross-language communication, in order to solve the problem, the application carries out cross-language communication based on a mode of structuring a cloning character string, and an existing communication scheme of WebF is modified based on the mode in frame construction.

Therefore, the application provides the specification comprising the base class, the target runtime function and the cross-language communication mode for the realization of the cross-terminal JS runtime, so that the cross-terminal JS runtime applicable to the original terminal and the browser terminal is designed based on the unified specification.

On the basis of the above embodiment, the cross-terminal logic layer includes a cross-terminal JS runtime implementation code, where the cross-terminal JS runtime implementation code includes a first JS runtime implementation code applied to the native terminal and a second JS runtime implementation code applied to the browser terminal, as shown in fig. 5, where "based on the cross-terminal JS runtime specification, the cross-terminal JS runtime is determined in the cross-terminal logic layer" in step S401 further includes the following steps:

s501, inheriting the JS runtime-based class at the Dart side, and interfacing the API exposed by the flutter_ qjs library when packaging the native application to obtain a first JS runtime implementation code, wherein the first JS runtime implementation code is used for realizing a target runtime function at the native end.

In some embodiments, because the need of communication is not met by the dart: ffi memory reference, the QuickJS and source code do not need to be directly introduced, and the reconstruction process is omitted, so that the embodiment of the application can directly select the packaged flutter_ qjs library.

In implementation, the API exposed to the interface filter_ qjs may implement the first JS runtime described above by inheriting the JS runtime-based class.

S502, inheriting the JS runtime base class at the Dart side, butting an API exposed in a wasm environment of a browser by packaging a quick JS-emscript when the browser application is packaged, and obtaining a quick JS running environment to obtain a second JS runtime implementation code, wherein the second JS runtime implementation code is used for realizing a target runtime function at a browser end.

When the browser runs with JS, the eval and new functions can be used for directly executing JS codes, but the environment is a browser environment, the gap between the environment and the pure JS running environment of QuickJS is larger, and the browser has a purer rendering capability which is the same as that of an APP end, so that a quick JS-emscript library based on WebAssembley packaging is selected.

When the method is realized, because the quick JS-emscript is a JS NPM library, a JSDK project is realized firstly, the JS version runtime is realized in the project, then the JS runtime base class is integrated in Dart, the JSDK code is loaded through the self browser operation capability, and the docking is completed.

In the embodiment of the application, the original JS runtime is repackaged, and the browser JS runtime is added in the framework. The logical operation capability in the browser is complemented, and a unified JS runtime environment is provided for operating JS codes.

On the basis of the above embodiment, the "repackaging Web API of WebF logical layer using JS language" in step S203 described above may be implemented by: creating a JSDK item, realizing the capability of analyzing the API by using JS language in the JSDK item, and exposing the API of the DOM related event; and realizing the API of the BOM in the JSDK project by using the JS language.

The Web API of the WebF logical layer is implemented using the C language, which needs to be implemented using JS in the new cross-end JS runtime. Firstly, a JSDK item needs to be created, the DOM analysis related API capability is realized, and DOM related events are exposed for butting Dart rendering. In addition, the Dart is also docked with the JS self-implementing some of the BOM's APIs in the library, such as store, request, cookie, history, skip capability, etc.

On the basis of the above embodiment, the "repackaging Web API implementation in WebF rendering layer" in step S204 described above may be implemented by the following procedure: based on the communication mode of the structured clone character string, the cross-language communication mode of the Web API implementation in the Flutter Web architecture is adjusted so as to interface the Web API implementation in the Flutter Dom rendering layer with the cross-end JS runtime.

The main implementation logic of the rendering layer Web API is unchanged, so long as some methods of using the dart:ffi docking C language before are changed into a docking cross-terminal JS runtime mode.

The docking mode is to inject message monitoring when the Dart terminal initializes the JS runtime, and after the JS calls the method, send the message after structuring cloning to the Dart terminal, the Dart terminal returns the message after cloning to the JS runtime terminal, otherwise the Dart calls the JS method.

The embodiment of the application uses JS language to repackage Web API realization, and peels off the dependence of the function on the original running time, so that the original logic running capability and the logic running capability in the browser can be simultaneously docked by one code.

In addition, in some embodiments, after development is completed in the cross-terminal JS runtime, the lifecycle of the view controller of the FlutterDom library needs to be re-docked, a corresponding JS runtime needs to be created and bound for logic processing when the page view is created, and a page-related method is injected into the JS runtime call, such as refreshing, jumping, closing the current page, obtaining information of the current page, refreshing the UI of the current page, and the like.

In conclusion, the cross-end rendering framework constructed by the method can be better embodied in multi-end consistency, and a purer rendering capability which is the same as that of an APP end can be provided in a Web browser. The method has advantages in realizing the cross-terminal APP low-code editor B-terminal preview scene, such as logic capable of simulating APP rendering in a browser. A cross-end rendering framework used for a browser end and a native end is provided, and based on the framework, the rendering of the same effect can be realized on the browser end and the native end.

Fig. 6 is a flowchart illustrating a cross-end rendering method according to an exemplary embodiment of the present application, and as shown in fig. 6, the cross-end rendering method includes the steps of:

s601, loading a cross-end rendering library in the rendering items, wherein the cross-end rendering library is a component realization library corresponding to a cross-end rendering frame.

The cross-end rendering method is realized based on the cross-end rendering frame constructed by the frame construction method, and the cross-end rendering frame can be applied to any one of a native end (such as an iOS end or an Android end) and a browser end, and the same rendering effect is realized on a cross-end platform.

The cross-end rendering library is a library corresponding to the cross-end rendering frame, and can comprise realization logic such as construction and rendering of related components. If the cross-end rendering framework is regarded as the Flutter Dom layered architecture, the cross-end rendering library can be regarded as a Flutter Dom library or a Flutter Dom component of the Flutter Dom layered architecture, and the library is realized by the Flutter Widget component corresponding to the Flutter Dom layered architecture.

When either one of the native terminal (such as the iOS terminal or the Android terminal) and the browser terminal executes a page rendering task, the Flutter Dom library is loaded in a rendering item, such as the Flutter item, so as to create and render widgets based on the Flutter Dom library.

S602, performing rendering tasks on the target end based on the cross-end rendering library and the configuration parameters.

In some embodiments, the developer may load the above-described cross-end rendering library in the router project and enter configuration parameters, which may include, but are not limited to, JS entry code, custom JS event processing logic, render window size, background color, whether to turn on debug mode, set HTTP request interceptor, and so on. And executing the rendering task based on the cross-end rendering library and the configuration parameters.

In summary, according to the cross-end rendering method provided by the embodiment of the application, the cross-end rendering library corresponding to the cross-end rendering frame is loaded in the rendering item, the component creation and rendering logic which can be realized at both the native end and the browser end in the library is utilized to execute the rendering task, the same rendering effect can be realized at the native end and the browser end, and the cross-end rendering of the native end and the browser end is realized.

On the basis of the above-described embodiment, as shown in fig. 7, in the above-described step S602 in the embodiment of the present application, "performing a rendering task at a target end based on a cross-end rendering library and configuration parameters" further includes the steps of:

s701, creating a cross-end rendering master controller according to the configuration parameters and the cross-end rendering library.

In some embodiments, a cross-end render master controller, such as a Fluter Dom master controller, may be initially created based on JS entry code, custom JS event processing logic, background color in configuration parameters.

S702, executing logic corresponding to inter-program cross-language communication in a rendering task by using a master controller, and creating a view controller; the view controller is used for executing view rendering logic corresponding to rendering tasks based on the cross-terminal JS runtime.

In some embodiments, cross-language communication is required when calling between programs based on different programming languages, for example, cross-language communication between JS language of the logical layer and Dart language of the rendering layer in the framework. And executing processing logic corresponding to the cross-language communication in the Flutter project by using a Flutter Dom total controller created based on the Flutter Dom framework. For example, a method for processing events by registering JS callback Dart monitors the throwing of a self-defined JS event in a JS code; executing callback parameters corresponding to the self-defined JS event; and adding the history corresponding to the current JS portal code into the history record to realize history record routing related logic.

Furthermore, the Flutter Dom view controller may also be created with an initialization of the Flutter Dom general controller, which is used to execute the view rendering logic.

In addition, a module controller can be created and registered by using the Fluter Dom master controller, which is used for realizing the following functions: including but not limited to interface requests, communication encapsulation, jump encapsulation, history routing, asynchronous storage, etc.

In some embodiments, the Fluter Dom view controller is used to execute the following view rendering logic:

creating a new JS page and adding the new JS page into a page pool, initializing the JS runtime and injecting Web API;

adding a Fluter application monitoring logic, monitoring an event and triggering a corresponding rendering logic, such as a language change event, a layout change event, a memory pressure overload event and the like;

uniformly injecting a Dart method into JS runtime call, wherein the method comprises module execution capacity, timer, frame renderer, log capacity and the like which are created by a Flutter dot master controller;

built-in HTML element creation logic is injected and Document, window nodes are automatically created. In addition, this capability would be exposed to the JS runtime, allowing the JS code to create or update elements within the runtime;

after waiting for the creation to be completed, the debug mode logic can be selected to execute the JS entry code and then start executing the JS entry code, if the debug mode is not started, the JS entry code is directly executed, and the canvas is initialized.

The JS portal code comprises some operation logic of DOM, monitoring logic for registering user operation events, asynchronous logic and the like, and initialization node creation and update logic is performed during initialization, and canvas update is triggered at the moment.

Wherein the canvas is updated by the following process:

sending a UI instruction to the Fluter Dom view controller;

the Fluter Dom view controller can perform element creation, updating and logic insertion according to the instruction, and then trigger the updating of the Fluter view;

the Render Object is acquired during view update rendering, and is regenerated according to the latest root node at this time, and then the canvas is updated.

In addition, after waiting for the user to operate the canvas or the JS asynchronous logic changes the node, the canvas update is triggered again.

In summary, according to the cross-end rendering method provided by the embodiment of the application, the cross-end rendering library corresponding to the cross-end rendering frame is loaded in the rendering item, the rendering task is executed based on the cross-end rendering library and the configuration parameters, the same rendering effect can be realized on the native end and the browser end based on the cross-end JS runtime and the rendering processing logic in the cross-end rendering library, and the cross-end rendering of the native end and the browser end is realized.

It should be understood that the sequence number of each step in the foregoing embodiment does not mean that the execution sequence of each process should be determined by the function and the internal logic of each process, and should not limit the implementation process of the embodiment of the present application in any way.

FIG. 8 is a block diagram of a cross-end rendering framework building apparatus based on a Flutter web framework, as shown in FIG. 8, the apparatus 800, according to an exemplary embodiment of the present application, includes: a specification extraction module 801, a determination module 802, a first encapsulation module 803, and a second encapsulation module 804.

A specification extraction module 801, configured to determine a cross-end JS runtime specification;

a determining module 802, configured to determine, at a cross-terminal logical layer, a cross-terminal JS runtime based on a cross-terminal JS runtime specification; and

a first packaging module 803, configured to repackage the Web API of the WebF logic layer by using JS language, so as to form a Web API of the cross-end logic layer;

the second encapsulation module 804 is configured to repackage the Web API implementation in the WebF rendering layer to obtain a Web API implementation of the cross-end rendering layer, so that the Web API implementation in the cross-end rendering layer can be docked with the cross-end JS runtime.

In this embodiment of the present application, the specification extraction module is further configured to:

Abstract out the universal JS runtime base class;

In this embodiment of the present application, the cross-end logical layer includes an implementation code of a cross-end JS runtime, where the implementation code of the cross-end JS runtime includes an implementation code of a first JS runtime applied to the originating end and an implementation code of a second JS runtime applied to the browser end, and the determining module is further configured to:

inheriting the JS runtime base class at the Dart side, and butting an API exposed by a flutter_ qjs library when packaging the native application to obtain an implementation code of the first JS runtime, wherein the implementation code of the first JS runtime is used for realizing a target runtime function at a native terminal;

and inheriting the JS runtime base class on the Dart side, and interfacing an API exposed in a wasm environment of the browser through encapsulation of the quick JS-emscript when the browser application is packaged to obtain a quick JS runtime environment so as to obtain a second JS runtime implementation code, wherein the second JS runtime implementation code is used for realizing a target runtime function on the browser side.

creating a JSDK item, realizing the capability of analyzing the API by using JS language in the JSDK item, and exposing the API of the DOM related event;

and realizing the API of the BOM in the JSDK project by using the JS language.

based on the communication mode of the structured clone character string, the cross-language communication mode of the Web API implementation in the Flutter Web architecture is adjusted so as to interface the Web API implementation in the Flutter Dom rendering layer with the cross-end JS runtime.

In summary, the cross-end rendering frame construction method provided by the application is based on the Fluter web frame for carrying out the following frame improvement: abstract extracting the inter-terminal JS runtime specification, unifying JS runtime library based on the inter-terminal JS runtime specification to determine inter-terminal JS runtime, and repackaging related APIs by JS language to complete the butt joint of APIs and runtime at both the original terminal and browser terminal, and realizing rendering logic at both the terminals. When a rendering task is executed, a cross-end rendering library corresponding to the cross-end rendering frame is loaded in a rendering item, and based on the library, the rendering of the same effect can be realized at a native end and a browser end.

Fig. 9 is a block diagram of a cross-end rendering apparatus according to an exemplary embodiment of the present application, and as shown in fig. 9, the apparatus 900 includes: a loading module 901 and a rendering module 902.

The loading module 901 is configured to load a cross-end rendering library in the rendering item, where the cross-end rendering library is a component implementation library corresponding to the cross-end rendering frame.

A rendering module 902, configured to perform a rendering task at a target end based on the cross-end rendering library and the configuration parameters.

In an embodiment of the present application, the rendering module is further configured to:

executing logic corresponding to inter-program cross-language communication in the rendering task by using the master controller, and creating a view controller;

the view controller is used for executing view rendering logic corresponding to rendering tasks based on cross-terminal JS running;

in an embodiment of the present application, the rendering logic is further to:

registering a JS callback Dart event processing method by using a master controller, and monitoring the throwing of a self-defined JS event in a JS code;

executing callback parameters corresponding to the self-defined JS event; and

and adding the history corresponding to the current JS portal code into the history record to realize history record routing correlation logic.

It should be noted that the explanation of the embodiment of the cross-end rendering method is also applicable to the cross-end rendering device of the embodiment of the present application, and the specific process is not repeated here.

The modules in the cross-end rendering device may be implemented in whole or in part by software, hardware, or a combination thereof. The above modules may be embedded in hardware or may be independent of a processor in the computer device, or may be stored in software in a memory in the computer device, so that the processor may call and execute operations corresponding to the above modules.

In order to implement the foregoing embodiments, the embodiments of the present application further provide an electronic device 1100, as shown in fig. 10, where the electronic device 1100 may specifically include: the steps of the cross-end rendering method or the cross-end rendering frame construction method as in the above embodiments are implemented by the memory 1101, the processor 1102, and a computer program stored in the memory 1101 and executable on the processor 1102, when the processor 1102 executes the program.

In summary, the application provides an electronic device, which is based on the following frame improvement of a Flutter web frame: abstract extracting the inter-terminal JS runtime specification, unifying JS runtime library based on the inter-terminal JS runtime specification to determine inter-terminal JS runtime, and repackaging related APIs by JS language to complete the butt joint of APIs and runtime at both the original terminal and browser terminal, and realizing rendering logic at both the terminals. When a rendering task is executed, a cross-end rendering library corresponding to the cross-end rendering frame is loaded in a rendering item, and based on the library, the rendering of the same effect can be realized at a native end and a browser end.

Those skilled in the art will appreciate that implementing all or part of the above described methods may be accomplished by way of a computer program stored on a non-transitory computer readable storage medium, which when executed may comprise the steps of the embodiments of the methods described above. Any reference to memory, storage, database, or other medium used in the various embodiments provided herein may include non-volatile and/or volatile memory. The nonvolatile memory can include Read Only Memory (ROM), programmable ROM (PROM), electrically Programmable ROM (EPROM), electrically Erasable Programmable ROM (EEPROM), or flash memory. Volatile memory can include Random Access Memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms such as Static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double Data Rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous Link DRAM (SLDRAM), memory bus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), among others.

It will be apparent to those skilled in the art that, for convenience and brevity of description, only the above-described division of the functional units and modules is illustrated, and in practical application, the above-described functional distribution may be performed by different functional units and modules according to needs, i.e. the internal structure of the apparatus is divided into different functional units or modules to perform all or part of the above-described functions.

The above embodiments are only for illustrating the technical solution of the present application, and are not limiting; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit and scope of the technical solutions of the embodiments of the present application, and are intended to be included in the scope of the present application.

Claims

1. The method for constructing the cross-end rendering frame based on the Flutter web frame comprises an embedded layer, a WebF rendering layer and a WebF logic layer, and is characterized in that the cross-end rendering frame comprises the embedded layer, the cross-end rendering layer and the cross-end logic layer, and the method comprises the following steps:

Determining a cross-terminal JS runtime specification;

2. The method of claim 1, wherein the determining the cross-end JS runtime specification comprises:

abstract out the universal JS runtime base class;

3. The method of claim 2, wherein the cross-peer logical layer includes cross-peer JS runtime implementation code, the cross-peer JS runtime implementation code including first JS runtime implementation code applied to a primary peer and second JS runtime implementation code applied to a browser, the determining, at the cross-peer logical layer, cross-peer JS runtime based on the cross-peer JS runtime specification comprising:

4. The method of claim 3, wherein repackaging the Web API of the WebF logical layer using JS language comprises:

and implementing the API of the BOM in the JSDK project by using JS language.

5. The method of claim 1, wherein the repackaging Web API implementations in the WebF rendering layer comprises:

6. A cross-end rendering method, characterized in that a cross-end rendering frame constructed based on the cross-end rendering frame construction method based on the Flutter web frame according to any one of claims 1 to 5 is implemented, the method comprising:

7. A cross-end rendering frame construction device based on a Flutter web frame, wherein the Flutter web frame comprises an embedded layer, a WebF rendering layer and a WebF logic layer, and the cross-end rendering frame comprises the embedded layer, the cross-end rendering layer and the cross-end logic layer, and the construction device comprises:

8. A cross-end rendering apparatus, characterized in that a cross-end rendering frame constructed based on the Flutter web frame-based cross-end rendering frame construction apparatus of claim 7 is implemented, the apparatus comprising:

9. An electronic device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, characterized in that the processor, when executing the computer program, implements the steps of the method for constructing a cross-end rendering frame based on a Flutter web frame as claimed in any one of claims 1-5 or the method for cross-end rendering as claimed in claim 6.

10. A computer-readable storage medium, on which a computer program is stored, characterized in that the program, when being executed by a processor, implements the steps of the method for constructing a cross-end rendering framework based on a Flutter web framework as claimed in any one of claims 1 to 5 or the method for cross-end rendering as claimed in claim 6.