Airport APP development system based on mobile cross-platform

Abstract

The present invention discloses an airport APP development system based on mobile cross-platform, which includes: an H5 container for running the H5 program and realizing the main process; the H5 container includes QDCWeb, JSBridgeAPI and HotLoader; the QDCWeb is a browser customized kernel, which encapsulates the native web kernel and is highly abstracted as an API, provides a Builder mode, supports custom parameters, and adds a loading state to improve execution efficiency and repair native web vulnerabilities; the JSBridgeAPI is used as an interactive bridge between the native container and the H5 container, and is encapsulated as an API by using JsBridge and queue data structures for mutual calling. The present invention can perform hot repair and hot deployment, with the best user experience and low development cost.

Description

Technical Field

[0001] The present invention relates to the field of mobile development technology in the civil aviation industry, and in particular to an airport APP development system based on a mobile cross-platform. Background Art

[0002] With the rise of cross-platform mobile app development, mobile apps are no longer a luxury but a necessity in daily life. The biggest challenge facing app developers is to create apps that work well on multiple platforms. Write code once on one platform and run it on multiple platforms. The purpose of these tools is to save programmers’ time and energy. Code can be reused and apps can be designed that work efficiently on multiple platforms including Android, iOS, etc.

[0003] In the cross-platform solution, the pure H5 framework cannot carry highly interactive pages, as well as permanent background services such as instant messaging; the RN and Weex projects have poor scalability and large version differences; self-drawn UI framework projects such as Flutter have poor readability and currently have unsolvable bugs. There are cross-platform frameworks on the market, but none of them can achieve the native experience. The pure H5 framework has the problem of long page loading time, and it cannot quickly build an APP. In addition, if the APP has new functions, it can only be updated by reinstalling the APP, and the functions of online update, hot deployment, and hot repair cannot be realized. It is also impossible to generate the APP with one-click configuration. Summary of the invention

[0004] The present invention overcomes the deficiencies of the prior art and provides an airport APP development system based on a mobile cross-platform, aiming to solve the technical problems mentioned in the background technology.

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

[0006] A mobile cross-platform airport APP development system, which includes:

[0007] H5 container, used for running H5 programs and implementing the main process; the H5 container includes QDCWeb, JSBridgeAPI and HotLoader;

[0008] The QDCWeb is a customized browser kernel that encapsulates the native web kernel and is highly abstracted as an API. It provides a Builder mode, supports custom parameters, and adds a loading state to improve execution efficiency and fix native web vulnerabilities.

[0009] The JSBridgeAPI is used as an interactive bridge between the native container and the H5 container, and is encapsulated as an API using JsBridge and queue data structures for mutual calls between them;

[0010] The HotLoader is used for hot update processing of resources in the H5 container;

[0011] Native container, used for data transfer between H5 container and system layer; the native container includes JSBridge, UrlRouter, QDCShark, NativeAPI and WebResManager;

[0012] The JSBridge is used for the code implementation of the native end of the JSBridgeAPI in the H5 container;

[0013] The UrlRouter is used to redirect all pages within the APP;

[0014] The QDCShark is used for full monitoring of abnormalities during APP operation;

[0015] The NativeAPI is used to call functions in the mobile phone environment;

[0016] The WebResManager is used to manage the web resource localization process, resource version comparison, downloading, decompression, and loading HTML pages through the file protocol.

[0017] In order to better realize the present invention, a further technical solution is:

[0018] Furthermore, the H5 container also includes:

[0019] Vant is used to build pages with a unified style to improve development efficiency.

[0020] Furthermore, the H5 container also includes:

[0021] Vue, used to integrate with third-party libraries or existing projects.

[0022] Furthermore, the web page localization is to package all web resources and place them in the APP private storage, so that there is no need to make network requests and complex parsing every time, and the local page can be directly loaded into the memory.

[0023] Furthermore, the resource hot update process includes:

[0024] Detect the APP version and start the web version comparison;

[0025] Update the corresponding version of web resources and overwrite local web resources;

[0026] File integrity check, save web resource version number and configuration list, start the home page; if the check fails, start the cached web resource.

[0027] Furthermore, it also includes:

[0028] The tabbar resource table is used to record global tabbarItem content display configuration and other field information, and can query the corresponding tabbar resource entity through the permission menu_code.

[0029] Furthermore, it also includes:

[0030] An APP table for storing version relationships, wherein the APP table and the web resource table are in a one-to-many relationship, so that the mobile WEB terminal is associated with the APP version to ensure the consistency of the functions of the mobile WEB version and the APP version.

[0031] Furthermore, the full abnormal monitoring is to rectify abnormal codes, solve bugs, and perform hot updates in the first place.

[0032] Furthermore, multiple sets of H5 codes are deployed in the H5 container to realize the ability of the same APP to support the access of H5 projects of multiple manufacturers.

[0033] Furthermore, the ways to connect third-party H5 components to APP include:

[0034] The project introduces cross-platform container SDK on Android and iOS, allowing the project to have cross-platform development containers;

[0035] Third-party manufacturers develop H5 applications that conform to cross-platform containers according to the cross-platform container development SDK documentation;

[0036] Third-party manufacturers compile, package, compress, deploy the product dist.zip to the APP configuration background, and configure the function entry;

[0037] Through hot update technology, the H5 versions of different manufacturers can be determined according to the component names;

[0038] Through resource localization, the latest resources are loaded locally;

[0039] Deliver HTML to QDCWeb for rendering, automatically load multiple third-party H5 resources, and realize the function of dynamically adding third-party H5 components.

[0040] Compared with the prior art, one of the beneficial effects of the present invention is:

[0041] The mobile cross-platform airport APP development system of the present invention has 1) better compatibility, best user experience and lower development cost than other cross-platform frameworks; 2) all functions of the native system can be seamlessly called; 3) page loading is faster and smoother than web page loading; 4) the container has the ability of hot repair and hot deployment that native APP development cannot do; 5) it supports one-click configuration and can dynamically build and publish APP without development. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] In order to more clearly illustrate the embodiments of the present application document or the technical solutions in the prior art, the drawings required for use in the description of the embodiments or the prior art are briefly introduced below. Obviously, the drawings described below are only references to some embodiments in the present application document. For those skilled in the art, other drawings can be obtained based on these drawings without creative work.

[0043] Figure 1 FIG. 1 is a schematic diagram of an overall framework according to an embodiment of the present invention.

[0044] Figure 2 FIG. 4 is a schematic diagram of a cross-platform container according to an embodiment of the present invention.

[0045] Figure 3 FIG. 4 is a block diagram of DCWeb related components according to an embodiment of the present invention.

[0046] Figure 4 FIG. 4 is a block diagram of QDCBridge related components according to an embodiment of the present invention.

[0047] Figure 5 The figure is a flowchart of a resource localization process according to an embodiment of the present invention.

[0048] Figure 6 The figure is a schematic diagram of an APP hot update process according to an embodiment of the present invention.

[0049] Figure 7 The figure is a schematic diagram of a file verification process according to an embodiment of the present invention.

[0050] Figure 8 The present invention is a flowchart of the principle of cross-platform APP development according to an embodiment of the present invention. DETAILED DESCRIPTION

[0051] The present invention is further described in detail below in conjunction with examples, but the embodiments of the present invention are not limited thereto.

[0052] APP fast cross-platform development framework, APP hot update, APP dynamic configuration and style customization, local loading of web resources, web and native data communication QDCBridge, cross-platform web development container, support as a mini-program development container.

[0053] The airport APP development system based on mobile cross-platform of the present invention has both native performance and underlying services, and high efficiency and dynamism in business. Developers support direct calls of all native functions. The container uses local web resource loading, without network download, to ensure interface loading speed and experience, and has the ability to dynamically update web resources. Specifically, its overall architecture is as follows Figure 1 As shown, it includes the system layer, container layer and view layer.

[0054] System layer: official development library for hardware devices and frameworks for mobile Android and iOS devices, including native view drawing, hardware calls, multimedia calls, etc.

[0055] Container layer: It is responsible for hosting Vue programs and native programs, and acts as a bridge to coordinate the mutual calls between the view layer and the system layer.

[0056] H5 container: responsible for the efficient operation of H5 programs and the implementation of the main process.

[0057] QDCWeb is a customized kernel for browsers. The principle is to encapsulate the native web kernel and highly abstract it into an API. It provides Builder mode, supports custom parameters, adds loading status, improves execution efficiency, and fixes native web vulnerabilities.

[0058] JSBridgeAPI is the interactive bridge between native and H5. It uses JsBridge and queue data structure to encapsulate it as an API for mutual calling.

[0059] HotLoader is the H5 resource hot update processing center.

[0060] Vant is a set of Vue2.0-based Mobile component libraries that Youzan has opened up. With Vant, you can quickly build pages with a unified style and improve development efficiency.

[0061] Vue can be a progressive WEB framework for building user interfaces. Unlike other large frameworks, it is designed to be applied layer by layer from the bottom up. Vue's core library only focuses on the view layer, which is not only easy to get started, but also easy to integrate with third-party libraries or existing projects.

[0062] Native Container: It is implemented in Android and iOS versions respectively. It is responsible for data transfer between the H5 container and the system layer, native method calls, page jumps, exception handling, etc.

[0063] JSBridge (Java, ObjectC) is the code implementation of the native side of the JSBridge API in the H5 container, supporting the H5 code to call native methods.

[0064] UrlRouter is the page jump router, responsible for all page jumps within the APP. The principle is a mapping table of <path, target page url> for addressing and routing jumps, with functions such as fallback strategies, data carrying, and jump callbacks.

[0065] QDCShark is for APP exception monitoring, fully monitoring runtime exceptions of the APP, rectifying exception codes in a timely manner, solving bugs, and performing quick hot updates, so as to quickly locate and solve online problems without the need for a release.

[0066] NativeAPI is the system function API, capable of calling all functions in the mobile phone environment.

[0067] WebResManager is the web resource management center, managing the localization process of web resources, resource version comparison, download, decompression, and loading html pages through the file protocol.

[0068] View layer: The view layer has an H5 + Native structure. According to the mixture of web language and programming language, it is usually divided into: H5 pages, native interfaces, and H5 + Native hybrid interfaces.

[0069] H5 interface: The entire page is implemented using H5 carried by QDCWeb without using native views, suitable for low-interaction pages, such as detailed pages and certain activity pages.

[0070] Hybrid page: The page has both native views and H5 views. The H5 carried by QDCWeb is used as a basic view to be implemented and embedded into the native page. It is suitable for situations where H5 calls native views, such as when a login page needs to display a native pop-up window. Single-View hybrid mobile applications represented by Baidu Search.

[0071] Native interface: The page is entirely composed of native views, suitable for high-interaction pages, such as message pages, dispatching pages, etc., pages with faster operation responses.

[0072] As Figure 2 shown, Figure 2 shows a block diagram of a cross-platform container according to an embodiment. The cross-platform design is generally divided into the OS system layer, native framework layer, and presentation layer.

[0073] OS layer: The OS layer is the native basic platform, including the Android basic platform and the iOS basic platform. It is used to carry the operation of the native SDK and H5 Framework. Functions include the normal call of hardware devices such as NFC, GPS, camera, gyroscope, current model, network status, storage status, 2D / 3D drawing and other function acquisition.

[0074] Native container layer: It mainly provides native API calls for Android and iOS, including the most important native Jsbridge (Java / OC), third-party data storage SDK, instant messaging components, Web container components, SuperMap SDK, QR code scanning SDK, component routing Router and other components, supporting real-time communication interaction between H5 and native.

[0075] ViewLayer layer: The View layer is an H5+Native structure. According to the mixture of web page language and program language, it is usually divided into two types: single interface and H5+Native mixed interface.

[0076] Single interface, that is, Native View and Web View are displayed independently and alternately. The logic of this application hybrid is relatively simple. That is, when needed, WebView is run as an independent View (Activity) and related display operations are completed in WebView.

[0077] H5+JSbridge+Native hybrid, that is, in the same View, both Native View and WebView are included. They are in a overlapping (overlapping) relationship. Single-View hybrid mobile applications, such as Baidu Search, can achieve full flexibility and a good user experience.

[0078] like Figure 3 As shown, Figure 3The structure of QDCWeb related components of an embodiment is shown. QDCWeb is an encapsulation component of the webview page. Using the builder mode, a safe, reliable, and interactive webview can be easily built. Referring to the decorator mode, the page switching state is added to the component. And the difference compatibility between different system releases. Referring to the proxy mode, QDCWeb supports multi-level processing and event isolation during page jumps. Let developers focus on business development. Tens of thousands of lines of code in a class, the logic of each business line, the patch code of each version, and the system compatible code are mixed together, which is difficult to split and even more difficult to maintain. Therefore, a built-in browser based on a highly cohesive autonomous browser kernel that can be customized for different business lines is the top priority of the current project and one of the foundations of later business componentization.

[0079] QDCWebView is a highly customized native browser kernel. The project used native webview before. When the project was online, some security vulnerabilities, js injection vulnerabilities, and Android version compatibility issues appeared. There was also a memory leak in the webview itself. The webview was rewritten to make addJavascriptInterface compatible with js. removeSearchBoxJavaBridgejs security processing, proxy WebChromeClient and WebViewClient out, use hierarchical relationships, set, load js, inject, and fix the memory leak of webview itself. Other security issues are in permissions and security processing.

[0080] LayoutCreator is a web layout builder. WebParentLayout inherits FrameLayout and carries layouts such as progress bar, empty page, error page, etc. QDCWebController provides external control over the actions of WebParentLayout, such as JsAlert, onMainFrameError to display the error interface, onLoading to display the loading status, etc. WebCreator holds WebParentLayout and is responsible for customizing the web layout in QDCWeb, including binding control and parentView, setting error layout, etc.

[0081] Permissions is a permission controller that handles the system permissions required by the browser, such as photo taking permissions, location permissions, etc.

[0082] EventHandler is the event transmission and distribution center. It uses the observer mode to handle event distribution and is mostly used for data transmission between pages.

[0083] ClientWrapper is a middleware used for page redirection. In the project, there is a shouldOverrideUrlLoading() method, which contains various logics, including URL jump judgment. To separate each functional module, you must first inherit MiddlewareWebClientBase, and then implement the methods you want to execute one by one. For example, when the system calls the shouldOverrideUrlLoading() method, it will call the following XXXWebViewClient in sequence. In this way, each function can be aggregated as independently as possible to facilitate modification and expansion.

[0084] The implementation principle of the above scheme can adopt the idea of ​​linked list, let MiddlewareWebClientBase be the node of the linked list, and hold the object of the next node in the node to realize the transmission of information. Add middleware, add a head to the linked list, or add a node, and point to the next node. Call execution order: The one-way linked list obtains the intermediate WebClient. The head of the linked list is the object of the first useMiddlewareWebClient. Each linked list node holds the next node and uses the next() method to obtain the next node. The last two nodes of the linked list set at the end are mDefaultWebClient and setWebViewClient(). QDCWebActivity, as the page carrier container, is responsible for building a unified QDCWeb and the real carrier of the H5 page.

[0085] like Figure 4 As shown, Figure 4 The QDCBridge related component structure of an embodiment is shown. QDCBridge is responsible for the communication between the view layer and the APP framework layer. The web end can call native hardware, database storage, native API, instant messaging, flight information and other functions and modules. In addition, a set of qdc_bridge_api_debug.js that can be adjusted in a pure browser interface on a computer without a mobile phone environment is provided for development use.

[0086] API method: qdc_bridge_api.js is a wrapper class of QDCBridge, which encapsulates all interface APIs for native and web interactions, including log printing, network requests, route jumps, data cache, media cameras, phone calls, Bluetooth positioning and other hardware acquisition, file operations and other functional APIs to support the normal and efficient operation of webAPP. The principle is that Native initializes webview and registers Handler; after loading the page, the WebViewJavascriptBridge.js file is injected into the page. Check whether there is information in the message queue that needs to be received. H5 page initialization, register Handler, and check whether there is information in the message queue that needs to be received. In essence, it relies on the system jsbridge for secondary development and expansion.

[0087] like Figure 5 As shown, Figure 5 The resource localization process flow chart of an embodiment is shown. Through resource localization, there is no need for network waiting and parsing white screen stage, and the web page can be displayed as soon as it is opened. The web kernel framework is customized to ensure page rendering speed, compatibility and security. The current technology on the market is to load the web page of the server through the URL, which is very slow. It needs to go through the following steps, which takes a long time.

[0088] By adopting the web page localization method, all web resources are packaged and placed in the private storage of the APP. No network request and complex parsing are required each time, and the local page is directly loaded into the memory, achieving the effect of displaying as soon as it is opened. At the same time, it also saves traffic consumption.

[0089] APP hot update will decompress and verify the latest web resources; save the resources to the APP's / data / data / package name / files / web / directory; after QDCWeb is initialized successfully, open the local html page through the file protocol; the html page performs data interaction and network access through QDCWeb and QDCBridge.

[0090] like Figure 6 As shown, Figure 6 The hot update process of an APP in an embodiment is shown. Traditional APP does not support hot update and hot deployment. If the APP wants to be updated, it must re-download and install the apk. The present invention solves the above technical problems. First, the APP version is detected, the web version comparison is started, the web resources of the corresponding version are updated, the local web resources are overwritten, the file integrity is checked, the web resource version number and the configuration list are saved, and the homepage is started. If the verification fails, the cached web resources are started.

[0091] like Figure 7 As shown, Figure 7The file verification process of an embodiment is shown. File verification algorithm SHA1: SHA- is a cryptographic hash function that can generate a 160-bit (20-byte) hash value called a message digest, which is mainly applicable to the Digital Signature Algorithm (DSA) defined in the Digital Signature Standard (DSS). For messages less than 100 bits in length, SHA1 will generate a 160-bit message digest. When a message is received, this message digest can be used to verify the integrity of the data. During the transmission process, the data is likely to change, and then a different message digest will be generated.

[0092] APP Configuration Platform (APM): APP corresponds to a configuration background and a configuration web page to manage the APP's display style, web resource control, etc.

[0093] Configuration steps:

[0094] Step 1: APP version control

[0095] Create APP, corresponding APP version, corresponding system platform, application address, add, delete, modify and check, etc.;

[0096] Step 2: Web resource configuration

[0097] The relationship between the APP version and the web resource version is 1:N. Each APP version can be configured with unlimited web resource versions. After the configuration is completed, the front end determines whether the web resource needs to be upgraded and automatically upgrades the APP resources, so that the APP can be upgraded without reinstalling it. In addition, you can also configure the APP theme color, navigation bar color, status bar color, tab bar color and other theme designs.

[0098] Step 3: Home page TAB configuration

[0099] The main interface of the APP is the entrance to the functional modules of the application. It supports customization. You can perform configuration management in this configuration center to control the display of the corresponding control buttons on the main page. You can also flexibly configure the theme color and status bar color of the APP. Most importantly, you can configure the bottom navigation bar icon and the corresponding page. You can arbitrarily configure the number of bottom navigation bars, the selected state, and the selected page content. The page can be a pure web page, a native page, or a hybrid page.

[0100] Step 4: Binding user permissions and page relationships

[0101] By configuring the backend and APP container through APP, there is no need for client developers to develop, only web personnel are needed to generate the APP you want.

[0102] Configuration principle and implementation:

[0103] 1) Dynamically display the Tabbar content on the App side

[0104] In mobile cross-platform applications, it is necessary to dynamically display the number of TabbarItems on the page according to the permissions after the user logs in. Therefore, it is necessary to add an additional tabbar resource table to record field information such as the global tabbarItem content display configuration, and the corresponding tabbar resource entity can be queried through the permission menu_code.

[0105] 2) Version association between the App and the mobile web

[0106] In order to ensure the functional consistency of the mobile WEB version and the APP version, it is necessary to associate the mobile WEB version with the APP version. This requires a separate table to store the version relationship. The APP table and the web resource table are a one-to-many relationship.

[0107] 3) Device account association

[0108] In order to quickly locate problems that users encounter when using devices and quickly manage login device records (similar to WeChat's login device management), it is necessary to maintain user and device information.

[0109] 4) App resource management

[0110] The mobile app needs to provide a resource download and resource management function. In business, the app resources are saved to the file server, and then the corresponding app information is saved to the corresponding database table.

[0111] APP front-end dynamic configuration implementation: The front-end dynamically generates the main page and style configuration. The homepage of the APP is a native page container + QDCBridge is responsible for interaction + web page carries content. Specifically:

[0112] 1) According to the path in the tabBar array, loop to create sub-pages in the main page

[0113] Path is used to confirm the type of page to jump to, which can be a pure native page or the type of web page QDCWeb (divided into with top navigation bar, without navigation bar, with sidebar, etc.); url is used to open the page path after localization of web resources with QDCWeb through File protocol; generate the Android code corresponding to the page, traverse and address through router to find the corresponding page, and instantiate it.

[0114] 2) Generate the bottom tab bar and the click and switch effects based on the text, textColorNormal, imgNormal and other fields in the tabBar array.

[0115] 3) Set the theme and color of the application according to the style object in json.

[0116] 4) Based on the webSource object in json, it is used for hot update and localization of web resources.

[0117] Relying on the above design of the technical solution, functions similar to WeChat applet can be realized (WeChat applet is developed in web language, calls the API of web container, and runs in WeChat's web container). That is, the container supports acting as a host, allowing business developers to quickly develop applications and deploy them to the host container. Subsequently, according to the API provided by the cross-platform solution, a mini program application can be developed and published directly on this APP. The mini program has the user system and permission system capabilities of the host APP. It also has the monitoring of the entire host APP life cycle, as well as the service calls provided by the host. For example, the ACDM application can support the mini program to call the flight list in ACDM.

[0118] Exception monitoring and downgrade strategy, always monitor the abnormal conditions of web containers and web resource pages, collect APP runtime exception information, and facilitate optimization and iteration. Exception monitoring: The container has a log reporting system, supports custom web container and VUE exception reporting logic, fully monitors APP runtime exceptions, corrects abnormal codes in the first time, solves bugs, and quickly hot updates, so that online problems can be quickly located and solved without releasing a version. Downgrade strategy: During the hot deployment process, each link has corresponding fault tolerance processing for exceptions. For example, if the new version resource download fails, the version is automatically rolled back; if the page crashes, the developer is actively notified and the code is hot redeployed.

[0119] According to the API documentation, H5 can be used to quickly develop mobile apps. The existing H5 cross-platform development technology is a pure browser technology that can only display pages by simply using webview to access the server URL. It cannot be used without a network, has a slow loading speed, cannot use native APIs, and cannot jump between pages.

[0120] An implementation example of rapid development of an APP: 1) Introduce the latest cross-platform container SDK; 2) Deploy the APP configuration background to your own server; 3) The product manager designs the main interface business diagram and function entry; 4) The front-end developer develops business based on the cross-platform container API and QDCBridgeAPI; 5) Use vconsole and adb debugging tools for testing and joint debugging during the front-end development process; 6) Configure the APP, web resources, themes and main page tab entry in the APP configuration background; 7) APP is released and launched.

[0121] like Figure 8 As shown, Figure 8 The principle implementation process of opening APP across platforms in one embodiment is shown. In this embodiment, relying on the design of the cross-platform container and QDCWeb design of the above embodiment, all functions of the native webview are encapsulated, the security strategy is improved, and a simple API is provided to reduce the difficulty of APP developers to get started, and they can be quickly developed according to the cross-platform container API. Relying on the data interaction capability of QDCBridge, native application capabilities such as H5 page routing jump, audio and video decoding and playback, data storage, hardware service acquisition, etc. are provided. Relying on resource localization, the page loading speed and rendering speed are greatly improved, and users can operate without waiting for the page. Relying on APP hot update, dynamic update of web resources is realized.

[0122] The present invention supports dynamic setting of themes and dynamic updating of resources, and implements configuration of the main page style by relying on the APP configuration platform and APP foreground dynamic configuration of the above-mentioned embodiment.

[0123] Support third-party H5 components and plug-in access to APP. Cross-platform container, support deployment of multiple H5 component resources, that is, to achieve the same container, deploy multiple sets of H5 codes, implement the same APP, and support the ability to access H5 projects from multiple manufacturers.

[0124] The main steps to integrate third-party H5 components into APP include:

[0125] 1. The project introduces cross-platform container SDK on Android and iOS, so that the project has a cross-platform development container

[0126] 2. Third-party manufacturers develop H5 applications that conform to cross-platform containers according to the cross-platform container development SDK documentation.

[0127] 3. Third-party manufacturers compile, package, and compress. Deploy the product dist.zip to the APP configuration background and configure the function entry.

[0128] 4. Through 4.5 hot update technology, H5 versions of different manufacturers can be determined according to component names.

[0129] 5. Through 4.4 resource localization, load the latest resources to the local computer.

[0130] 6. Deliver HTML to QDCWeb for rendering, automatically load multiple third-party H5 resources, and dynamically add third-party H5 components.

[0131] In summary, developers can write a set of codes and publish them to both iOS and Android platforms. Its features include: 1) Simple configuration and selection in the background can automatically generate your own native APP for both Android and iOS. 2) The APP will have better performance than H5APP, more flexible adaptation management, and support calling native functions. 3) It has hot deployment and hot update that native APP cannot do. That is, the ability to update APP content without reinstalling the APP and without the user's perception.

[0132] A modern cross-platform communication system that is easy to use on Android, iOS, and Javascript. Without knowing each other, the web side can call tens of thousands of native APIs at will. The native system can also call all JavaScript functions without distinction. Its advantages include: 1) With a complete functional API, web developers can use all functions of the native system simply and efficiently. 2) Native function plug-ins support plugging in new native function modules at any time, which is simple and flexible. 3) Support common message mechanisms such as synchronous, asynchronous, and queue transmission. 4) Support custom native function plug-ins.

[0133] The various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referenced to each other.

[0134] When referred to in this specification, "one embodiment", "another embodiment", "an embodiment", etc., it means that the specific features, structures or characteristics described in conjunction with the embodiment are included in at least one embodiment generally described in this application. The same expression appearing in multiple places in the specification does not necessarily refer to the same embodiment. Further, when a specific feature, structure or characteristic is described in conjunction with any embodiment, it is claimed that the realization of such feature, structure or characteristic in conjunction with other embodiments also falls within the scope of the present invention.

[0135] Although the present invention is described herein with reference to a number of illustrative embodiments of the present invention, it will be appreciated that those skilled in the art may devise many other modifications and implementations that fall within the scope and spirit of the principles disclosed herein. More specifically, within the scope of the present disclosure, drawings, and claims, a variety of variations and improvements may be made to the components and / or layout of the subject combination layout. In addition to variations and improvements made to the components and / or layout, other uses will also be apparent to those skilled in the art.

Claims

1. A mobile cross-platform airport APP development system, characterized by include: H5 container, used for running H5 programs and implementing the main process; the H5 container includes QDCWeb, JSBridgeAPI and HotLoader; The QDCWeb is a customized browser kernel that encapsulates the native web kernel and is highly abstracted as an API. It provides a Builder mode, supports custom parameters, and adds a loading state to improve execution efficiency and fix native web vulnerabilities. The JSBridgeAPI is used as an interactive bridge between the native container and the H5 container, and is encapsulated as an API using JsBridge and queue data structures for mutual calls between them; The HotLoader is used for hot update processing of resources in the H5 container; The resource hot update process includes: detecting the APP version, starting the web version comparison; updating the corresponding version of the web resource, overwriting the local web resource; File integrity check, save web resource version number and configuration list, start the home page; if the check fails, start the cached web resource; Native container, used for data transfer between H5 container and system layer; the native container includes JSBridge, UrlRouter, QDCShark, NativeAPI and WebResManager; the system layer is the hardware device and framework official development library of mobile Android and iOS models; The JSBridge is used for the code implementation of the native end of the JSBridgeAPI in the H5 container; The UrlRouter is used to redirect all pages within the APP; The QDCShark is used for full monitoring of abnormalities during APP operation; The NativeAPI is used to call functions in the mobile phone environment; The WebResManager is used to manage the web resource localization process, resource version comparison, downloading, decompression, and loading HTML pages through the file protocol.

2. The mobile cross-platform airport APP development system according to claim 1 is characterized in that The H5 container also contains: Vant is used to build pages with a unified style to improve development efficiency.

3. The mobile cross-platform airport APP development system according to claim 1 is characterized in that The H5 container also contains: Vue, used to integrate with third-party libraries or existing projects.

4. The mobile cross-platform airport APP development system according to claim 1 is characterized in that The web resource localization is to package all web resources and put them in the APP private storage, so that there is no need to make network requests and complex parsing every time, and the local page can be directly loaded into the memory.

5. The mobile cross-platform airport APP development system according to claim 1 is characterized in that Also includes: The tabbar resource table is used to record the global tabbarItem content display configuration information, and the corresponding tabbar resource entity can be queried through the permission menu_code.

6. The mobile cross-platform airport APP development system according to claim 1 is characterized in that Also includes: An APP table for storing version relationships, wherein the APP table and the web resource table are in a one-to-many relationship, so that the mobile WEB terminal is associated with the APP version to ensure the consistency of the functions of the mobile WEB version and the APP version.

7. The mobile cross-platform airport APP development system according to claim 1 is characterized in that The full abnormal monitoring is to rectify abnormal codes, solve bugs, and perform hot updates as soon as possible.

8. The mobile cross-platform airport APP development system according to claim 1 is characterized in that Multiple sets of H5 codes are deployed in the H5 container to realize the ability of the same APP to support the access of H5 projects of multiple manufacturers.

9. The mobile cross-platform airport APP development system according to claim 1 is characterized in that The ways to connect third-party H5 components to APP include: The project introduces cross-platform container SDK on Android and iOS, allowing the project to have cross-platform development containers; Third-party manufacturers develop H5 applications that conform to cross-platform containers according to the cross-platform container development SDK documentation; The third-party manufacturer compiles, packages and compresses, deploys the product dist.zip to the APP configuration background, and configures the function entry; Through hot update technology, the H5 versions of different manufacturers can be determined according to the component names; Through resource localization, the latest resources are loaded locally; Deliver HTML to QDCWeb for rendering, automatically load multiple third-party H5 resources, and realize the function of dynamically adding third-party H5 components.

Images