CN114077423A - Airport APP development container architecture based on mobile cross-platform - Google Patents

Abstract

The invention discloses a mobile cross-platform-based airport APP development container architecture, which comprises: an H5 container for the operation of the H5 program and the implementation of the main process; the H5 container comprises QDCWeb, JSBridgeAPI and HotLoader; the QDCWeb is a browser custom kernel which encapsulates a native web kernel and is highly abstracted to api, a Builder mode is provided, custom parameters are supported, and a loading state is added to improve the execution efficiency and repair native web bugs; the JSBridge API is used for an interactive bridge of a native container and the H5 container, and is packaged into the API by virtue of a JsBridge and queue data structure, so as to be mutually called. The invention can carry out heat restoration and heat deployment, has the best user experience and low development cost.

Description

Airport APP development container architecture based on mobile cross-platform

Technical Field

The invention relates to the technical field of mobile development of civil aviation industry, in particular to an airport APP development container framework based on a mobile cross-platform.

Background

With the rise of development of cross-platform mobile applications, mobile applications are no longer luxury items and have become a necessity of daily life. The biggest challenge facing application developers is to create applications that can run well on multiple platforms. The purpose of these tools is to save programmers time and effort by writing code once on one platform and running on multiple platforms. The code can be reused, and the application program which can work efficiently on a plurality of platforms such as Android and iOS can be designed.

In the cross-platform scheme, a pure H5 frame cannot bear high-interaction pages and resident background services such as instant messaging and the like; the RN and Weex projects have poor expansibility and large version difference; the self-drawing UI frame items of Flutter and the like have poor readability, and currently, unsolvable bugs exist. The cross-platform framework in the market can not achieve the native experience. The pure H5 framework has the problem of too long page loading time, and cannot be quickly constructed to generate an APP. In addition, the APP has new functions, and the functions of online updating, hot deployment and hot repair cannot be realized only by reinstalling the APP for updating. The ability to generate APPs with one-key configuration is also not possible.

Disclosure of Invention

The invention overcomes the defects of the prior art, provides an airport APP development container architecture based on a mobile cross-platform, and aims to solve the technical problems that: .

In view of the above problems of the prior art, according to one aspect of the present invention, to solve the above technical problems, the present invention adopts the following technical solutions:

a mobile cross-platform based airport APP development container architecture, comprising:

an H5 container for the operation of the H5 program and the implementation of the main process; the H5 container comprises QDCWeb, JSBridgeAPI and HotLoader;

the QDCWeb is a browser custom kernel which encapsulates a native web kernel and is highly abstracted to api, a Builder mode is provided, custom parameters are supported, and a loading state is added to improve the execution efficiency and repair native web bugs;

the JSBridge API is used for an interactive bridge between a native container and the H5 container, and is packaged into an API by virtue of a JsBridge and queue data structure for mutual calling;

the HotLoader is used for resource hot update processing of the H5 container;

a native container for data transfer between the H5 container and the system layer; the native container comprises JSbridge, UrlrRouter, QDCShark, NativeAPI and WebResManager;

the JSB bridge is used for realizing the code of the JSB bridge API native end in the H5 container;

the Urlrouter is used for skipping all pages in the APP;

the QDCShark is used for full monitoring of the abnormity of the APP during operation;

the native API is used for calling functions in the mobile phone environment;

the WebResManager is used for managing the web resource localization process, comparing resource versions, downloading, decompressing and loading html pages through a file protocol.

In order to better realize the invention, the further technical scheme is as follows:

further, the H5 container further comprises:

vant is used for building a page with uniform style so as to improve the development efficiency.

Further, the H5 container further comprises:

vue, for integration with third party libraries or existing projects.

Furthermore, the web page localization is to pack all web resources and then place the web resources in the APP private storage, so that network requests and complex analysis are not required to be performed each time, and the local page is directly loaded into the memory.

Further, the resource heat update process includes:

detecting an APP version, and starting web version comparison;

updating the web resource of the corresponding version to cover the local web resource;

checking the integrity of the file, saving the version number and the configuration list of the web resource, and starting a homepage; and if the verification fails, starting the cached web resource.

Further, still include:

and the tabbar resource table is used for recording field information such as global tabbar item content display configuration and the like, and inquiring the corresponding tabbar resource entity through the authority menu _ code.

Further, still include:

and the APP table is in one-to-many relationship with the WEB resource table, so that the mobile WEB end is associated with the version of the APP, and the consistency of the functions of the mobile WEB version and the version of the APP is ensured.

Furthermore, the full monitoring of the exception is to modify the exception code at the first time, solve the bug and perform hot update.

Further, multiple sets of H5 codes are deployed in the H5 container, so that the capability of supporting access of multiple manufacturer H5 projects by the same APP is realized.

Further, the mode of accessing the APP by the third party H5 component includes:

introducing a cross-platform container SDK into the project android and iOS end, and enabling the project to have a cross-platform development container;

the third party manufacturer develops the SDK document according to the cross-platform container and develops the H5 application conforming to the cross-platform container;

a third party manufacturer compiles, packs and compresses a product dist.zip, deploys the product dist.zip into an APP configuration background, and configures a function inlet;

respectively judging H5 versions of different manufacturers according to component names by a thermal updating technology;

loading the latest resource to the local through resource localization;

and delivering the html to QDCWeb for rendering and presentation, realizing automatic loading of multiple third-party H5 resources, and realizing the function of dynamically adding third-party H5 components.

Compared with the prior art, the invention has the following beneficial effects:

compared with other cross-platform frameworks, the airport APP development container framework based on the mobile cross-platform is 1) better in compatibility, best in user experience and lower in development cost; 2) all functions of the native system can be seamlessly invoked; 3) the page loading is faster and smoother than the web page loading; 4) the container has the capabilities of thermal repair and thermal deployment which cannot be achieved by the development of the native APP; 5) one-key configuration is supported, and the published APP can be dynamically constructed without development.

Drawings

For a clearer explanation of the embodiments or technical solutions in the prior art of the present application, the drawings used in the description of the embodiments or prior art will be briefly described below, it is obvious that the drawings in the following description are only references to some embodiments in the present application, and other drawings can be obtained by those skilled in the art without creative efforts.

FIG. 1 is a general block diagram according to one embodiment of the invention.

FIG. 2 is a schematic view of a cross-platform container according to one embodiment of the present invention.

FIG. 3 is a block diagram of DCWeb-related components, according to one embodiment of the present invention.

Fig. 4 is a block diagram of QDCBridge-related components, according to one embodiment of the present invention.

FIG. 5 is a block diagram of a process associated with localization of resources according to an embodiment of the present invention.

FIG. 6 is a flowchart illustrating an APP hot update process according to an embodiment of the present invention.

Fig. 7 is a schematic diagram of a file verification process according to an embodiment of the present invention.

FIG. 8 is a block diagram illustrating a schematic implementation flow of cross-platform APP, according to an embodiment of the present invention.

Detailed Description

The present invention will be described in further detail with reference to examples, but the embodiments of the present invention are not limited thereto.

The system comprises an APP rapid cross-platform development framework, APP hot update, APP dynamic configuration and style customization, web resource local loading, web and native data communication QDCbridge, a cross-platform web development container and a support as an applet development container.

The airport APP development container framework based on the mobile cross-platform has the original performance and bottom layer service, and has high efficiency and dynamic performance in business. Developers support direct invocation of all native functions. The container is locally loaded by adopting the web resources, network downloading is not needed, the loading speed and experience of the interface are ensured, and the capability of dynamically updating the web resources is realized. Specifically, the general architecture is as shown in fig. 1, and includes a system layer, a container layer and a view layer.

A system layer: and developing libraries for hardware equipment and framework authorities of mobile end android and iOS models, wherein the libraries comprise native view drawing, hardware calling, multimedia calling and the like.

A container layer: it is responsible for bearing vue procedure and native program, and as the bridge, coordinate the mutual calling of view layer and system layer.

H5 container: is responsible for the efficient operation and main flow realization of the H5 program.

The QDCWeb customizes a kernel for the browser, and the principle is that a native web kernel is packaged and highly abstracted to api, a Builder mode is provided, custom parameters are supported, a loading state is added, the execution efficiency is improved, and a native web vulnerability is repaired;

the JSBridge API is an interactive bridge between the native and H5, and is packaged into API by virtue of the JsBridge and queue data structures, so as to be mutually called.

And the HotLoader is an H5 resource hot update processing center.

Vant can be a set of Vue 2.0-based Mobile component libraries with complimentary sources. A page with uniform air grids can be quickly built through Vant, and development efficiency is improved.

Vue may be a set of progressive WEB frameworks for building user interfaces. Unlike other large frames, it is designed to be applied layer by layer from bottom to top. Vue, the core library only focuses on the viewing layer, not only is it easy to get on hand, but also it is easy to integrate with third party libraries or existing projects.

Primary containers: it is implemented in android and iOS versions. And the system is responsible for data transfer between the H5 container and the system layer, native method calling, page jump, exception handling and the like.

JSBridge (Java, ObjectC) supports code implementation of the native end of the JSBridge api in the H5 container, and calls native methods for the H5 code.

The UrlRouter is a page jump route and is responsible for jumping of all pages in the APP, the principle is a mapping table of < path and target page url >, addressing and route jumping are carried out, and functions of degradation strategies, data carrying, jump call-back and the like are provided.

QDCShark is APP unusual control, and the unusual full control in APP operation, and the very first time rectification exception code solves the bug to quick hot update, thereby reach and need not to send out the version, can fix a position fast and solve online problem.

The native API is a system function API and can call all functions in the mobile phone environment.

WebResManager is a web resource management center, manages the web resource localization process, compares from the resource version, downloads, decompresses, and loads the html page through the file protocol.

Viewing the image layer: the viewing layer is H5+ Native structure. According to the mixture of web page language and program language, the method is generally divided into: h5 page, Native interface, H5+ Native hybrid interface.

H5 interface: the whole page is realized by H5 carried by QDCWeb, and a native view is not used, so that the method is suitable for low-interaction pages, such as detailed details and some active pages.

Mixing pages: the page has a native view and an H5 view, and H5 carried by QDCWeb is implemented as a basic view and is embedded into the native page. The method is applicable to the case that H5 calls the native view, for example, the landing page needs to show the native popup. A single View hybrid mobile application as typified by a hundred degree search.

Native interface: the pages are all native views, and are suitable for high-interaction pages, such as message pages, dispatch pages and the like, and pages which respond to operations quickly.

As shown in FIG. 2, FIG. 2 illustrates a block diagram of a cross-platform container, cross-platform design, generally divided into an OS system layer, a native framework layer, and a presentation layer, according to an embodiment.

And an OS layer: the OS layer is a native base platform and comprises an Android base platform and an iOS base platform double ends. The function is to carry the operation of the native SDK and the H5 Framework. The functions comprise normal calling of hardware equipment such as NFC, GPS, photographing and gyroscope, current model, network state, storage state, 2D/3D drawing and the like.

Native contiiner layer: the method mainly comprises Android and iOS native API calls, and comprises the most main native Jsbridge (Java/OC), a third-party data storage SDK, an instant messaging component, a Web container component, a hypergraph SDK, a code scanning SDK, a component routing Router and other components, and supports the timely communication interaction of H5 and native.

ViewLayer: the View layer is H5+ Native structure. According to the mixture of the webpage language and the program language, the method is generally divided into two types, namely a single interface and an H5+ Native mixed interface.

And single interfaces, namely Native View and Web View are independently displayed and appear alternately. This application mixing logic is relatively simple. Namely, when needed, the WebView is operated as an independent View (Activity), and relevant display operation is completed in the WebView.

H5+ JSbridge + Native hybrid, namely within the same View, including both Native View and Web View. The layers are in a covering (laminated) relationship with each other. For example, a single View hybrid mobile application represented by hundred-degree search can realize sufficient flexibility and better user experience.

As shown in FIG. 3, FIG. 3 shows the structure of the related components of the QDCWeb according to an embodiment, the QDCWeb is the packaging component of the webview page, and a safe and reliable and interactive friendly webview can be easily constructed by using the builder mode, the reference decorator mode is added to the components, the page switching state is added to the components, and the difference between the issuance of different systems is compatible. In one class, ten thousand lines of codes, logic of each service line, patch codes of each version and system compatible codes are mixed together, are difficult to split and are difficult to maintain, and all the built-in browsers which can be customized for different service lines are the important part of the current project and are one of the bases of late service modularization on the basis of a high-cohesion self-owned browser kernel.

A QDCWebView highly customized native browser kernel. Before the project, a native webview is used, the project is online, some security holes appear, js injection holes appear, and Android version compatibility problems exist. There is also memory leakage of webview itself. The webview is rewritten to aim at addJavascript Interface compatible js. And (2) performing secure processing on removeSearchBoxJavaBridgejs, proxying WebChromeClient and WebViewClient, setting by using a hierarchical relationship, loading Js, injecting and repairing memory leakage of webview, and performing other security problems in authority and secure processing.

The layout creator is a web layout builder, and WebParentLayout inherits FrameLayout, carries layouts such as progress bars, empty pages, error pages and the like. QDCWebController provides and controls the actions of WebParentLayout, such as JsAlert, onMainFrameError shows an error interface, onLoading shows a loading state and the like, and WebCreator holds WebParentLayout to be responsible for customizable configuration web layout in QDCWeb. Including binding control and parentView, setting error layouts, etc.

Permissions are permission controllers that handle system Permissions required by the browser, such as photographing Permissions, positioning Permissions, and the like.

EventHandler is an event delivery and distribution center, processes event distribution by using an observer mode, and is mainly used for data delivery between pages.

The ClientWrapper is middleware and is used for redirecting a page. In the project, there is a shouldoverladerurrlloading () method, in which various logics are doped, and there is a judgment URL jump. Each function module is independent, first the middlewarcewebclientbase is inherited, then the method which the system wants to execute one by one is realized, for example, shouldoververrideurrlloading (), and finally the system calls the following xxxxwebviewclient in sequence when the shouldoververrideurrlloading method is called, so that each function is aggregated as independently as possible, and modification and expansion are facilitated.

The realization principle of the scheme can adopt the chain table idea to enable the middleware WebClientBase to be used as the node of the chain table, and the object of the next node is held in the node, so that the information transmission can be realized. Add middleware, add a header to the linked list, or add a node, and point to the next node. Calling an execution sequence: the one-way linked list obtains the intermediate WebClient, the head of the linked list is the object of the first-time useMeddlewareWebClient, each linked list node holds the next node, and the next node is obtained by using a next () method. The last two nodes of the last set linked list are mDefaultWebClient, setWebViewClient (). The QDCWebActivity is used as a page bearing container and is responsible for constructing a uniform QDCWeb and bearing a real carrier of an H5 page.

As shown in fig. 4, fig. 4 illustrates the structure of the components related to the QDCBridge, which is responsible for communication between the view layer and the APP framework layer, and the web end may invoke the functions and modules of native hardware, database storage, native api, instant messaging, flight messaging, etc. according to an embodiment. In addition, a set of qdc _ bridge _ api _ debug. js which can be adjusted on a pure browser interface of a computer without a mobile phone environment is provided for development and use.

The API method comprises the following steps: wherein qdc _ bridge _ api. js is used as a packaging class of QDCbridge, and all interfaces api which encapsulate native and web interaction comprise log printing, network request, route skipping, data caching, media camera, hardware acquisition such as telephone making, Bluetooth positioning and the like, and normal and efficient operation of webAPP is supported by the api such as file operation and the like. The principle is that Native initializes webview and registers Handler; after loading the page, the webviewjavascript bridge.js file is injected into the page. A query is made as to whether the message queue has information to be received. H5 page initialization, register Handler, inquire whether the message queue has information to receive. Essentially, the system jsbridge is relied on for secondary development extension.

As shown in fig. 5, fig. 5 is a block diagram illustrating a related process of resource localization according to an embodiment, and a web page is opened and displayed by resource localization without waiting and parsing a white screen. And customizing a web kernel frame, and ensuring the page rendering speed, compatibility and safety. The current technology in the market is to load the web page of the server through url, and the speed is very slow. The following steps are required, and the time cost is large.

And packaging all web resources by adopting a web page localization mode, putting the packaged web resources into APP private storage, directly loading a local page into a memory without carrying out network request and complex analysis each time, and realizing the effect of opening and displaying. And meanwhile, the flow consumption is saved.

The APP hot update decompresses and checks the web latest resource; storing the resources in the data/data/package name/files/web/directory of the APP; after the QDCWeb is initialized successfully, opening a local html page through a file protocol; the html page carries out data interaction and network access through QDCWeb and QDCbridge.

As shown in fig. 6, fig. 6 shows an APP hot-update flow of an embodiment, where a conventional APP does not support hot-update hot deployment, and the APP needs to update and must download the installation apk again. The above technical problems are solved by the present invention. The method comprises the steps of firstly detecting an APP version, starting web version comparison, updating web resources of a corresponding version, covering local web resources, checking file integrity, saving a web resource version number and a configuration list, and starting a homepage. A check fails to initiate a cached web resource.

As shown in FIG. 7, FIG. 7 illustrates a file verification flow of an embodiment. File check algorithm SHA 1: SHA-is a cryptographic hash function that generates a 160-bit (20-byte) hash value called a message digest, primarily suitable for use in the Digital Signature Algorithm (Digital Signature Algorithm DSA) defined in the Digital Signature Standard (DSS). For messages that are less than a bit in length, SHA1 generates a 160-bit message digest. This message digest may be used to verify the integrity of the data when the message is received. During the transmission, the data is likely to change, and then different message digests are generated at this time.

APP configuration platform (APM): the APP corresponds to a configuration background and a configuration web page to manage the display style of the APP, web resource control and the like.

A configuration and use step:

first step, APP version control

Creating an APP, corresponding to an APP version, corresponding to a system platform, applying an address, increasing, deleting, modifying and checking and the like;

second, Web resource configuration

The APP versions and the web resource versions are in a 1: N relationship, each APP version can be configured with an unlimited number of web resource versions, after configuration is completed, the front end judges whether the web resources need to be upgraded or not, the APP resources can be automatically upgraded, and the effect that the APPs can be upgraded without being reinstalled is achieved. Besides, the theme design of APP theme color, navigation bar color, status bar color, tab bar color and the like can be configured.

Third step, homepage TAB configuration

The main interface of the APP is an application function module inlet, self definition is supported, configuration management can be carried out in the configuration center, and the control main page displays a corresponding control main button. And the theme color and the status bar color of the APP can be flexibly configured, and most importantly, the bottom navigation bar icon and the corresponding page can be configured. The number of the bottom navigation bars, the selected state and the selected page content can be configured at will. The page may be a pure web page, a native page, or a mixed page.

Fourthly, binding the user authority and the page relation

Through APP configuration backstage and APP container, need not client developer development, only need the web personnel, just can generate the APP that oneself wanted.

Configuration principle and implementation:

1) dynamic display of Tabbar content by App terminal

In the mobile cross-platform application, the number of TabbareItems of a page needs to be dynamically displayed according to the authority control after a user logs in, so a Tabbar resource table needs to be additionally added, the field information such as the overall content display configuration of the TabbareItems is recorded, and the corresponding Tabbar resource entity can be inquired through the authority menu _ code.

2) Version association of App end and mobile web end

In order to ensure the consistency of the functions of the mobile WEB version and the APP version, the mobile WEB side needs to be associated with the APP version, so that a separate table is needed to store the version relationship, and the APP table and the WEB resource table are in a one-to-many relationship.

3) Device account association

In order to quickly locate problems that occur when a user uses a device and quickly manage log-in device records (similar to WeChat log-in device management), information of the user and the device is maintained.

4) App resource management

In the service, the app resources are saved in the file server, and then the corresponding app information is saved in the corresponding database table.

APP foreground dynamic configuration implementation: foreground dynamically generates main page and style configuration, the main page of APP is the native page container + QDCbridge responsible for interaction + web page load-bearing content. Specifically, the method comprises the following steps:

1) according to the path in the tabBar array, circularly creating the sub-page in the main page

Path is used for confirming the type of the page to be jumped, which can be a pure native page, or type () of the web page QDCWeb is divided into a navigation bar with the top, no navigation bar, a side bar and the like); url is used for opening a web resource localized page path by QDCWeb through a File protocol; and generating an android end code corresponding to the page, traversing and addressing through the router to find the corresponding page, and instantiating.

2) The bottom tab column is generated from the text, textColorNormal, imgNormal, etc. fields in the tabBar array, as well as the effects of clicking and toggling.

3) The theme and color of the application are set according to the style object in json.

4) According to the webSource object in json, hot updates and localization of web resources are used.

By means of the technical scheme, functions similar to the WeChat applet can be achieved (the WeChat applet is a scheme which is developed by using a web language, calls the api of a web container and runs in the web container of the WeChat). Namely, the container support is used as a host (an aircraft carrier), so that a business party developer can rapidly develop an application (a carrier-based aircraft) and deploy the application into a host container (the aircraft carrier-level APP). And subsequently, an applet application directly issued to the APP can be developed according to the API provided by the cross-platform scheme. The applet has the capability of a user system and a permission system of the host APP. The monitoring of the whole host APP life cycle and the service calling provided by the host are also provided, for example, the calling of a flight list in the ACDM by the ACDM application support applet can be realized.

And an exception monitoring and degrading strategy is used for monitoring the exception conditions of the web container and the web resource page at any time and collecting the exception information during the operation of the APP, so that optimization and iteration are facilitated. And (3) anomaly monitoring: the container is provided with a log reporting system and supports the custom web container and the abnormal reporting logic of the VUE, the abnormal full monitoring is carried out when the APP operates, the abnormal code is rectified and changed at the first time, the bug is solved, and the quick hot updating is carried out, so that the problem that the online problem can be quickly positioned and solved without version sending is achieved. And (3) degradation strategy: in the heat deployment process, each link is abnormal, and corresponding fault-tolerant processing is performed. For example, if the new version resource fails to be downloaded, an automatic version rollback mode is adopted; and (4) enabling the page to generate crash, actively informing a developer, and re-heating the deployment code.

According to API documents, H5 can be used for rapidly developing mobile APP, the existing H5 cross-platform development technology is a pure browser technology, a server url can be accessed to display a page only by using webview, the network cannot be used, the loading speed is low, the native API cannot be used, and the page skipping cannot be performed.

An embodiment of rapid development of an APP, 1) introduction of the latest cross-platform container SDK; 2) deploying an APP configuration background to a server of the APP configuration background; 3) a product manager designs a main interface business diagram and a function entrance; 4) the front-end developer carries out service development according to the cross-platform container API and the QDCBridgeAPI; 5) testing and joint debugging are carried out by using a vconsole and adb debugging tool in the front-end development process; 6) configuring the APP, the web resources, the theme and the tab entrance in an APP configuration background; 7) and the APP is released to be on line.

As shown in fig. 8, fig. 8 shows a principle implementation flow of cross-platform APP of an embodiment, wherein all functions of native webview are encapsulated by relying on the design of the cross-platform container and the QDCWeb design of the above embodiment, a security policy is perfected, an easy-to-use API is provided, the difficulty of the application developer is reduced, and the application developer can be quickly developed according to the cross-platform container API. And native application capabilities such as H5 page routing skip, audio and video decoding play, data storage, hardware service acquisition and the like are provided by means of the data interaction capability of the QDCbridge. The resource localization is relied on, the page loading speed and the rendering speed are greatly improved, and a user can operate without waiting for the page. And realizing dynamic update of the web resources by depending on APP hot update.

The invention supports the support of theme dynamic setting and resource dynamic updating, and realizes the configuration of the main page style by depending on the APP configuration platform and the APP foreground dynamic configuration of the embodiment.

And supporting a three-party H5 component, and performing plug-in access to the APP. The cross-platform container supports the deployment of multiple H5 component resources, namely, the same container is realized, multiple sets of H5 codes are deployed, the same APP is realized, and the access capability of multiple H5 projects is supported.

The three-party H5 component access APP main steps include:

1. the SDK of the cross-platform container is introduced into the android and iOS end of the project, so that the project has the cross-platform development container

2. And the third party manufacturer develops the SDK document according to the cross-platform container and develops the H5 application conforming to the cross-platform container.

3. And the third-party manufacturer compiles, packs and compresses the product dist.zip, deploys the product dist.zip into the APP configuration background and configures the function entrance.

4. By means of 4.5 hot update technology, H5 versions of different manufacturers are judged according to component names of H5 of different manufacturers.

5. And respectively loading the latest resources to the local through 4.4 resource localization.

6. And delivering the html to QDCWeb for rendering and presentation, realizing automatic loading of multiple third-party H5 resources, and realizing the function of dynamically adding third-party H5 components.

In summary, a developer writes a set of codes and can issue to the iOS and Android dual-end platform for operation. The method is characterized by comprising the following steps: 1) the background is simply configured and selected, and the android and iOS double-ended native APP can be automatically generated. 2) APP will have better performance than H5APP, more flexible adaptation management, support calling native functions. 3) The method has the advantages of hot deployment and hot update which cannot be achieved by native APP. Namely, the ability to update the APP content without reinstalling the APP and without the user's perception.

The Android, iOS and Javascript three-terminal easy-to-use modern cross-platform communication system. The web-side can call native APIs at will, without knowing about each other. The native system may also invoke all JavaScript functions indifferently. The advantages include: 1) with the complete functionality api, a web developer can simply and efficiently use all the functionality of the native system. 2) The native function plug-in is simple and flexible, and supports plugging and unplugging of new native function modules at any time. 3) And common message mechanisms such as synchronization, asynchronization, queue transmission and the like are supported. 4) And supporting the user-defined native function plug-in.

The embodiments are described in a progressive manner in the specification, each embodiment focuses on differences from other embodiments, and the same and similar parts among the embodiments are referred to each other.

Reference throughout this specification to "one embodiment," "another embodiment," "an embodiment," etc., means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment described generally in this application. The appearances of the same phrase in various places in the specification are not necessarily all referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with any embodiment, it is submitted that it is within the scope of the invention to effect such feature, structure, or characteristic in connection with other embodiments.

Although the invention has been described herein with reference to a number of illustrative embodiments thereof, it should be understood that numerous other modifications and embodiments can be devised by those skilled in the art that will fall within the spirit and scope of the principles of this disclosure. More specifically, various variations and modifications are possible in the component parts and/or arrangements of the subject combination arrangement within the scope of the disclosure, the drawings and the appended claims. In addition to variations and modifications in the component parts and/or arrangements, other uses will also be apparent to those skilled in the art.

Claims (10)

1. A mobile cross-platform based airport APP development container architecture, comprising:

an H5 container for the operation of the H5 program and the implementation of the main process; the H5 container comprises QDCWeb, JSBridgeAPI and HotLoader;

the QDCWeb is a browser custom kernel which encapsulates a native web kernel and is highly abstracted to api, a Builder mode is provided, custom parameters are supported, and a loading state is added to improve the execution efficiency and repair native web bugs;

the JSBridge API is used for an interactive bridge between a native container and the H5 container, and is packaged into an API by virtue of a JsBridge and queue data structure for mutual calling;

the HotLoader is used for resource hot update processing of the H5 container;

a native container for data transfer between the H5 container and the system layer; the native container comprises JSbridge, UrlrRouter, QDCShark, NativeAPI and WebResManager;

the JSB bridge is used for realizing the code of the JSB bridge API native end in the H5 container;

the Urlrouter is used for skipping all pages in the APP;

the QDCShark is used for full monitoring of the abnormity of the APP during operation;

the native API is used for calling functions in the mobile phone environment;

the WebResManager is used for managing the web resource localization process, comparing resource versions, downloading, decompressing and loading html pages through a file protocol.

2. The mobile cross-platform based airport APP development container architecture of claim 1, wherein said H5 container further comprises:

vant is used for building a page with uniform style so as to improve the development efficiency.

3. The mobile cross-platform based airport APP development container architecture of claim 1, wherein said H5 container further comprises:

vue, for integration with third party libraries or existing projects.

4. The mobile cross-platform airport APP development container architecture based on claim 1, wherein web page localization is to pack all web resources and then place them in APP private storage, so that network requests and complex parsing are not required each time, and thus local pages are directly loaded into memory.

5. The mobile cross-platform based airport APP development container architecture of claim 1, wherein the resource heat update process comprises:

detecting an APP version, and starting web version comparison;

updating the web resource of the corresponding version to cover the local web resource;

checking the integrity of the file, saving the version number and the configuration list of the web resource, and starting a homepage; and if the verification fails, starting the cached web resource.

6. The mobile cross-platform based airport APP development container architecture of claim 1, further comprising:

and the tabbar resource table is used for recording field information such as global tabbar item content display configuration and the like, and inquiring the corresponding tabbar resource entity through the authority menu _ code.

7. The mobile cross-platform based airport APP development container architecture of claim 1, further comprising:

and the APP table is in one-to-many relationship with the WEB resource table, so that the mobile WEB end is associated with the version of the APP, and the consistency of the functions of the mobile WEB version and the version of the APP is ensured.

8. The mobile cross-platform based airport APP development container architecture of claim 1, wherein full anomaly monitoring is to trim exception code, resolve bugs, and perform hot updates at a first time.

9. The mobile cross-platform based airport APP development container architecture of claim 1, wherein multiple sets of H5 code are deployed within the H5 container for enabling the ability of the same APP to support access to multiple vendor H5 projects.

10. The mobile cross-platform based airport APP development container architecture of claim 1, wherein the way third party H5 components access the APP comprises:

introducing a cross-platform container SDK into the project android and iOS end, and enabling the project to have a cross-platform development container;

a third party manufacturer develops an SDK document according to a cross-platform container and develops H5 application conforming to the cross-platform container;

compiling, packaging and compressing by a third party manufacturer, deploying a product dist.zip into an APP configuration background, and configuring a function inlet;

respectively judging H5 versions of different manufacturers according to component names by a thermal updating technology;

loading the latest resource to the local through resource localization;

and delivering the html to QDCWeb for rendering and presentation, realizing automatic loading of multiple third-party H5 resources, and realizing the function of dynamically adding third-party H5 components.

Images