基于移动跨平台的机场APP开发容器架构的制作方法

基于移动跨平台的机场app开发容器架构
技术领域
1.本发明涉及民航业的移动开发技术领域，具体涉及一种基于移动跨平台的机场app开发容器架构。


背景技术：

2.随着跨平台移动应用开发的兴起，移动应用不再是奢侈品而已成为日常生活的必需品。应用开发人员面临的最大挑战是创建可在多个平台上运行良好的应用程序。在一个平台上编写一次代码，并在多个平台上运行，这些工具的目的是为了节省程序员的时间和精力。可以重用代码，并设计可以在包括android，ios等多个平台上高效工作的应用程序。
3.跨平台方案中，纯h5框架无法承载高交互页面，以及即时通讯等常驻后台服务；rn和weex项目扩展性差，版本差异大；flutter等自绘ui框架项目，可读性差，目前存在不可解决的bug。市面的跨平台框架，但是都无法达到原生的体验。纯h5的框架，存在页面加载时间过长的问题，也不能快速构建生成一个app。另外，app有新功能，只能通过重装app更新，无法实现在线更新，热部署，热修复的功能。也无法做到一键配置，即可生成app的能力。


技术实现要素：

4.本发明克服了现有技术的不足，提供一种基于移动跨平台的机场app开发容器架构，旨在解决的技术问题之一是：。
5.考虑到现有技术的上述问题，根据本发明的一个方面，为解决上述的技术问题，本发明采用以下技术方案：
6.一种基于移动跨平台的机场app开发容器架构，其包括：
7.h5容器，用于h5程序的运行和主流程的实现；所述h5容器包含qdcweb、jsbridgeapi和hotloader；
8.所述qdcweb为浏览器定制内核，其封装原生web内核，并高度抽象为api，提供builder模式，支持自定义参数，加入loading状态，以用于提高执行效率，修复原生web漏洞；
9.所述jsbridgeapi用于原生容器和所述h5容器的交互桥梁，借用jsbridge和队列数据结构封装为api,供彼此之间相互调用；
10.所述hotloader用于所述h5容器的资源热更新处理；
11.原生容器，用于h5容器和系统层之间的数据传递；所述原生容器包含jsbridge、urlrouter、qdcshark、nativeapi和webresmanager；
12.所述jsbridge用于所述h5容器中jsbridgeapi原生端的代码实现；
13.所述urlrouter用于app内部所有页面的跳转；
14.所述qdcshark用于app运行时的异常全监控；
15.所述nativeapi用于调用手机环境中的功能；
16.所述webresmanager用于管理web资源本地化过程，从资源版本对比，下载，解压，
通过file协议加载html页面。
17.为了更好地实现本发明，进一步的技术方案是：
18.进一步地，所述h5容器还包含：
19.vant，用于搭建出风格统一的页面，以提升开发效率。
20.进一步地，所述h5容器还包含：
21.vue，用于与第三方库或既有项目整合。
22.进一步地，所述web页面本地化是将所有web资源打包后，放于app私有存储中，使得不需要每次进行网络请求和复杂解析，从而直接加载本地页面到内存中。
23.进一步地，所述资源热更新处理包括：
24.检测app版本，启动web版本对比；
25.更新对应版本的web资源，覆盖本地web资源；
26.文件完整性校验，保存web资源版本号和配置单，启动主页；校验失败则启动缓存的web资源。
27.进一步地，还包括：
28.tabbar资源表，用于记录全局的tabbaritem内容展示配置等字段信息,并可通过权限menu_code查询到对应的tabbar资源实体。
29.进一步地，还包括：
30.用于存储版本关系的app表，所述app表与web资源表为一对多关系，使移动web端与app的版本进行关联，保证移动web版本与app版本功能的一致。
31.进一步地，所述异常全监控是在第一时间整改异常代码，解决bug，并进行热更新。
32.进一步地，所述h5容器内部署多套h5代码,用于实现同一个app支持多方厂家h5项目接入的能力。
33.进一步地，第三方h5组件接入app的方式包括：
34.项目android和ios端引入跨平台容器sdk,让项目拥有跨平台开发的容器；
35.第三方厂家,按照跨平台容器开发sdk文档,开发符合跨平台容器的h5应用；
36.第三方厂家,编译,打包,压缩，将产物dist.zip部署到app配置后台中,并配置功能入口；
37.通过热更新技术,根据组件名,分别判断不同厂家的h5版本；
38.通过资源本地化,将最新资源加载到本地；
39.将html交付给qdcweb进行渲染呈现,实现自动加载多个第三方h5资源,实现动态添加第三方h5组件的功能。
40.与现有技术相比，本发明的有益效果之一是：
41.本发明的基于移动跨平台的机场app开发容器架构，1)比其他跨平台框架，兼容性更好，用户体验最好，开发成本更低；2)可以无缝调用原生系统的所有功能；3)页面加载比web页面加载，更快，更流畅；4)容器拥有原生app开发无法做到的热修复，热部署的能力；5)支持一键配置，无需开发，即可动态构建发布app。
附图说明
42.为了更清楚的说明本技术文件实施例或现有技术中的技术方案，下面将对实施例
或现有技术的描述中所需要使用的附图作简单的介绍，显而易见地，下面描述中的附图仅是对本技术文件中一些实施例的参考，对于本领域技术人员来讲，在不付出创造性劳动的情况下，还可以根据这些附图得到其它的附图。
43.图1为根据本发明一个实施例的总体框架示意图。
44.图2为根据本发明一个实施例的跨平台容器的示意图。
45.图3为根据本发明一个实施例的dcweb相关组件的框图。
46.图4为根据本发明一个实施例的qdcbridge相关组件框图。
47.图5为根据本发明一个实施例的资源本地化相关流程框图。
48.图6为根据本发明一个实施例的app热更新流程示意图。
49.图7为根据本发明一个实施例的文件校验流程示意图。
50.图8为根据本发明一个实施例的跨平台开app的原理实现流程框图。
具体实施方式
51.下面结合实施例对本发明作进一步地详细说明，但本发明的实施方式不限于此。
52.app快速跨平台开发框架，app热更新，app动态配置和样式定制，web资源本地加载，web和原生的数据通信qdcbridge，跨平台web开发容器，支持作为小程序开发容器。
53.本发明的一种基于移动跨平台的机场app开发容器架构，既拥有原生的性能和底层服务，又拥有业务上的高效和动态。开发人员支持原生所有功能的直接调用。容器采用web资源本地化加载，无需网络下载，保证界面加载速度和体验，同时拥有动态更新web资源的能力。具体地，其总体架构如图1所示，包括系统层、容器层和视图层。
54.系统层：为移动端android和ios机型的硬件设备和framework官方开发库,包括原生的view绘制，硬件调用，多媒体调用等。
55.容器层：它负责承载vue程序和原生程序，并作为桥梁，协调视图层和系统层的相互调用。
56.h5容器：负责h5程序的高效运行和主流程实现。
57.qdcweb为浏览器定制内核，原理是封装了原生web内核，并高度抽象为api，提供builder模式，支持自定义参数，加入loading状态，提高执行效率，修复原生web漏洞；
58.jsbridgeapi为原生和h5的交互桥梁，借用jsbridge和队列数据结构封装为api,供彼此之间相互调用。
59.hotloader为h5资源热更新处理中心。
60.vant可以是有赞开源的一套基于vue2.0的mobile组件库。通过vant可以快速搭建出风格统一的页面，提升开发效率。
61.vue可以是一套用于构建用户界面的渐进式web框架。与其它大型框架不同的是，它被设计为可以自底向上逐层应用。vue的核心库只关注视图层，不仅易于上手，还便于与第三方库或既有项目整合。
62.原生容器：它分为android版本和ios版本实现。负责h5容器和系统层之间的数据传递，原生方法调用，页面跳转，异常处理等。
63.jsbridge(java,objectc)为h5容器中jsbridgeapi原生端的代码实现，支撑h5代码调用原生方法。
64.urlrouter为页面跳转路由，负责app内部所有页面的跳转，原理为《path,目标页面url》的映射表，进行寻址和路由跳转，其中有降级策略，数据携带，跳转回调等功能。
65.qdcshark为app异常监控，app运行时异常全监控，第一时间整改异常代码，解决bug，并快速热更新，从而达到无需发版，即可快速定位和解决线上问题。
66.nativeapi为系统功能api，能够调用手机环境中的所有功能。
67.webresmanager为web资源管理中心，管理web资源本地化过程，从资源版本对比，下载，解压，通过file协议加载html页面。
68.视图层：视图层为h5 native结构。按网页语言与程序语言的混合，通常分为：h5页面，原生界面，h5 native混合界面。
69.h5界面：整个页面全部使用qdcweb承载的h5实现，不使用原生的视图，适用于低交互页面，比如详细详情，某些活动页。
70.混合页面：页面存在原生视图和h5视图，将qdcweb承载的h5作为一个基础view来实现，嵌入到原生的页面中。适用于h5调用原生view的情况，比如登陆页面需要展示原生弹窗的情况。如百度搜索为代表的单view混合型移动应用。
71.原生界面：页面全部是原生视图，适用于高交互页面，比如消息页面，派工页面等等，对操作响应较快的页面。
72.如图2所示，图2示出了一实施例的跨平台容器的框图，跨平台设计，总体分为os系统层，原生框架层，表现层。
73.os层：os层为原生基础平台，包括android基础平台和ios基础平台双端。作用是承载原生sdk和h5 framework的运行。功能包括nfc，gps，拍照，陀螺仪等硬件设备的正常调用，当前机型，网络状态，存储状态，2d/3d绘制等功能获取。
74.原生container层：它主要为android和ios原生api调用，包括最主要的原生jsbridge(java/oc)，第三方数据存储sdk，即时通讯组件，web容器组件，超图sdk，扫码sdk，组件路由router等等组件，支持h5和native的及时通信交互。
75.viewlayer层：view层为h5 native结构。按网页语言与程序语言的混合，通常分为两种类型:单界面，h5 native混合界面。
76.单界面，即native view和web view独立展示，交替出现。这种应用混合逻辑相对简单。即在需要的时候，将webview当成一个独立的view(activity)运行起来，在webview内完成相关的展示操作。
77.h5 jsbridge native混合型，即在同一个view内，同时包括native view和web view。互相之间是覆盖(层叠)的关系。如百度搜索为代表的单view混合型移动应用，既可以实现充分的灵活性，又能实现较好的用户体验。
78.如图3所示，图3示出了一实施例的qdcweb相关组件的结构，qdcweb为webview页面的封装组件,用builder模式,可以轻松构建一个安全可靠,交互友好的webview.参考装饰者模式,为组件增加页面切换状态.以及不同系统颁布之间差异兼容.参考代理模式,让qdcweb支持页面跳转过程中多级处理和事件隔离.让开发者专注于业务开发。一个类中上万行代码，各个业务线的逻辑，各个版本的补丁代码，系统兼容代码，混合在一起，难以拆分,更是难以维护，所有,一个以高内聚的自主浏览器内核为基础,对不同业务线可定制化的内置浏览器是目前项目的重中之重,也是后期业务组件化的基础之一。
79.qdcwebview高度定制的原生浏览器内核。项目之前在用原生的webview,项目在线上,出现了一些安全漏洞,js注入漏洞,以及android版本兼容性问题。还有webview本身的内存泄漏。重写webview,目的是addjavascriptinterface兼容js。removesearchboxjavabridgejs安全处理，将webchromeclient和webviewclient代理出来,用层级关系,进行设定,js加载,注入、修复webview自带的内存泄漏，其他的安全问题在权限和安全处理中。
80.layoutcreator为web布局构建器，webparentlayout继承framelayout,承载进度条，空页面，错误页面等布局。qdcwebcontroller对外提供，控制webparentlayout的动作，比如jsalert,onmainframeerror展示错误界面,onloading展示加载状态等等，webcreator持有webparentlayout负责在qdcweb中可定制化的配置web布局。包括将control和parentview绑定,设置错误布局等。
81.permissions为权限控制器，处理浏览器所需的系统权限,比如拍照权限,定位权限等。
82.eventhandler为事件传递和分发中心，用观察者模式，处理事件分发，多用于页面之间的数据传递。
83.clientwrapper为中间件，用于页面重定向切面。在项目中，有一个shouldoverrideurlloading()方法,在方法中,掺杂着各种逻辑,有判断url跳转。独立出了各个功能模块，首先要继承middlewarewebclientbase,然后实现自己想要逐个执行的方法.比如shouldoverrideurlloading()，最后系统在调用shouldoverrideurlloading方法的时候,会依次调用以下xxxwebviewclient这样,将每个功能,尽可能的独立聚合起来,便于修改和扩展。
84.上述方案实现原理，可以采用链表的思想，让middlewarewebclientbase作为链表的节点,在节点中持有下一个节点的对象，就可以实现信息的传递。添加中间件，向链表中添加头,或者添加节点,并指向下一个节点。调用执行顺序：单向链表获取中间webclient，链表头为第一次usemiddlewarewebclient的对象，每个链表节点，持有下一个节点,并用next()方法，获取下一个节点。最后设置的链表的最后两个节点为mdefaultwebclient,setwebviewclient()。qdcwebactivity作为页面承载容器，负责构建统一的qdcweb,承载h5页面的真正载体。
85.如图4所示，图4示出了一实施例的qdcbridge相关组件结构，qdcbridge负责视图层和app框架层的通信，web端可以调用原生的硬件，数据库存储，原生api，即时通信，航班消息等功能和模块。除此之外,提供一套无需手机环境,在电脑纯浏览器界面可调的qdc_bridge_api_debug.js供开发使用。
86.api方法：其中qdc_bridge_api.js作为qdcbridge的包装类，封装了原生和web交互的所有接口api包括日志打印，网络请求，路由跳转，数据缓存，媒体相机，打电话、蓝牙定位等硬件获取，文件操作等等功能api支撑webapp的正常高效运行。原理是native初始化webview，注册handler；加载页面完成后，将webviewjavascriptbridge.js文件注入页面。查询消息队列是否有信息需要被接收。h5页面初始化，注册handler，查询消息队列是否有信息需要别接收。本质上是依赖系统jsbridge,进行二次开发扩展。
87.如图5所示，图5示出了一实施例的资源本地化相关流程框图，通过资源本地化，无
需网络等待和解析白屏阶段，实现打开即展示web页面。定制web内核框架，保障页面渲染速度，兼容性和安全性。当前市面的技术，是通过url加载服务器的web页面，速度非常慢。需要经过以下几个步骤，时间花费较大。
88.采用web页面本地化的方式，将所有web资源打包后，放于app私有存储中，每次不需要进行网络请求和复杂解析，直接加载本地页面到内存中，实现打开即展示的效果。同时也节省了流量消耗。
89.app热更新将web最新资源解压校验；将资源存到app的/data/data/包名/files/web/目录下；qdcweb初始化成功后,通过file协议,打开本地的html页面；html页面通过qdcweb和qdcbridge进行数据交互和网络访问。
90.如图6所示，图6示出了一实施例的app热更新流程，传统app，不支持热更新热部署，app想要更新，必须重新下载安装apk。通过本发明，解决了以上技术问题。首先检测app版本，启动web版本对比，更新对应版本的web资源，覆盖本地web资源，文件完整性校验，保存web资源版本号和配置单，启动主页。校验失败启动缓存的web资源。
91.如图7所示，图7示出了一实施例的文件校验流程。文件校验算法sha1：sha-是一种密码散列函数，可以生成一个被称为消息摘要的160位(20字节)散列值，主要适用于数字签名标准(digital signature standard dss)里面定义的数字签名算法(digital signature algorithm dsa)。对于长度小于位的消息，sha1会产生一个160位的消息摘要。当接收到消息的时候，这个消息摘要可以用来验证数据的完整性。在传输的过程中，数据很可能会发生变化，那么这时候就会产生不同的消息摘要。
92.app配置平台(apm)：app对应一个配置后台和配置web页面,来管理app的展示样式，web资源控制等。
93.配置使用步骤：
94.第一步,app版本控制
95.创建app,对应app版本,对应系统平台,应用地址,增删改查等；
96.第二步,web资源配置
97.app版本和web资源版本为1:n的关系,每个app的版本,可以配置无限个web资源版本,配置完成后,前端判断是否需要升级web资源,会自动升级app资源,达到app无需重新安装就可升级的效果。除此之外,还可以配置app主题颜色,导航栏颜色,状态栏颜色,tab栏颜色等等主题设计。
98.第三步,主页tab配置
99.app的主界面为应用的功能模块入口,支持自定义,可以在这个配置中心,进行配置管理，控制主页面展示相应控制主按钮。以及可以灵活配置app的主题色，状态栏颜色，最重要的是可以配置底部导航栏图标，以及对应的页面。可以随意配置底部导航栏的个数，选中状态，选中的页面内容。该页面可以是纯web页面，也可以是原生页面，还可以是混合页面。
100.第四步,用户权限和页面关系绑定
101.通过app配置后台和app容器，不需要客户端开发人员开发，只需要web人员，就可以生成自己想要的app。
102.配置原理和实现：
103.1)app端动态显示tabbar内容
104.在移动跨平台应用中,需要根据用户登录后根据权限控制动态展示页面tabbaritem数量.所以额外需要添加tabbar资源表,记录全局的tabbaritem内容展示配置等字段信息,并可通过权限menu_code查询到对应的tabbar资源实体。
105.2)app端与移动web端的版本关联
106.为了保证移动web版本与app版本功能的一致性,需要将移动web端与app的版本进行关联,这样就需要一个单独的表来存储版本关系，app表和web资源表为一对多关系。
107.3)设备账号关联
108.为了快速定位用户在使用设备出现的问题,并快捷管理登录设备记录(类似微信的登录设备管理),要维护用户与设备的信息。
109.4)app资源管理
110.移动端app需要提供一个资源下载及其资源管理的功能.在业务中,将app资源保存到文件服务器中,然后将其对应的app信息保存到相应的数据库表中。
111.app前台动态配置实现：前台动态生成主页面和样式配置，app的主页为原生页面容器 qdcbridge负责交互 web页面承载内容。具体地：
112.1)根据tabbar数组中的path,循环创建主页面中的子页面
113.path用于确认要跳转的页面类型,可以是纯原生页面,也可以是web页面qdcweb的类型()分为带顶部导航栏,不带导航栏,带侧边栏等等)；url用于通过file协议,用qdcweb打开web资源本地化后的页面路径；生成页面对应的android端代码，通过router进行遍历寻址找到对应页面,并实例化。
114.2)根据tabbar数组中的text,textcolornormal,imgnormal等字段,来生成底部tab栏,以及点击和切换的效果。
115.3)根据json中的style对象,设置应用的主题和颜色。
116.4)根据json中的websource对象,用于web资源的热更新和本地化。
117.依托技术方案的以上设计，可以实现类似微信小程序的功能(微信小程序就是用web语言开发，调用web容器的api，运行在微信的web容器的方案)。即容器支持作为宿主(航空母舰)，让业务方开发者，快速开发应用(舰载机)，并部署到宿主容器(本航母级app)中。后续根据该跨平台方案提供的api，即可开发出一款直接发布在本app的小程序应用。小程序拥有宿主app的用户体系，权限体系的能力。也拥有整个宿主app生命周期的监听，以及宿主的提供的service调用，比如可以实现acdm应用支持小程序调用acdm中航班列表。
118.异常监控和降级策略，时刻监控web容器和web资源页面的异常情况，收集app运行时异常信息，便于优化和迭代。异常监控：容器具有日志上报系统，支持自定义web容器和vue的异常上报逻辑，app运行时异常全监控，第一时间整改异常代码，解决bug，并快速热更新，从而达到无需发版，即可快速定位和解决线上问题。降级策略：在热部署流程途中，每个环节出现异常，都有对应的容错处理。比如，新版本资源下载失败，采用版本自动回退的方式；页面发生crash，主动通知开发人员，重新热部署代码。
119.根据api文档,可用h5快速开发移动app，现有h5跨平台开发技术中,是纯浏览器技术,只能单纯的通过使用webview,访问服务器url来展示页面，没有网络无法使用,加载速度慢,无法做到使用原生api,也无法做页面之间的跳转。
120.快速开发一app的实施例，1)引入最新跨平台容器sdk；2)部署app配置后台到自己服务器；3)产品经理设计主界面业务图和功能入口；4)前端开发人员根据跨平台容器api和qdcbridgeapi进行业务开发；5)前端开发过程中用vconsole,adb调试工具进行测试和联调；6)在app配置后台进行app,web资源,主题和主页面tab入口的配置；7)app发布上线。
121.如图8所示，图8示出一实施例的跨平台开app的原理实现流程，其中，依靠上述实施例的跨平台容器的设计和qdcweb设计,封装了原生webview的所有功能,完善安全策略,提供简单使用api,降低app开发人员的上手难度,可以根据跨平台容器api快速开发。依靠qdcbridge的数据交互能力,提供h5页面路由跳转,音视频解码播放,数据存储,硬件服务获取等等原生应用能力。依靠的资源本地化,极大提高页面加载速度和渲染速度,用户无需等待页面,即可进行操作。依靠app热更新,实现web资源动态更新。
122.本发明支持支持主题动态设置和资源动态更新，依靠上述实施例的app配置平台和app前台动态配置实现,实现配置主页面样式。
123.支持三方h5组件,插件式接入app。跨平台容器,支持部署多h5组件资源,即实现同一个容器,部署多套h5代码,实现同一个app,支持多方厂家h5项目接入的能力。
124.三方h5组件接入app主要步骤，包括:
125.1.项目android和ios端引入跨平台容器sdk,让项目拥有跨平台开发的容器
126.2.第三方厂家,按照跨平台容器开发sdk文档,开发符合跨平台容器的h5应用。
127.3.三方厂家,编译,打包,压缩.将产物dist.zip部署到app配置后台中,并配置功能入口。
128.4.通过4.5热更新技术,分别将不同厂家的h5根据组件名,分别判断不同厂家的h5版本。
129.5.通过4.4资源本地化,分别将最新资源加载到本地。
130.6.将html交付给qdcweb进行渲染呈现,实现自动加载多个第三方h5资源,实现动态添加第三方h5组件的功能。
131.综上而言，开发者编写一套代码，可发布到ios、android双端平台运行。其特点包括：1)后台进行简单配置和选择，可自动生成自己的android和ios双端原生app。2)app将拥有比h5app更优的性能，更灵活的适配管理，支持调用原生功能。3)拥有原生app无法做到的热部署，热更新。即不需重新安装app，在用户无感知下，更新app内容的能力。
132.android、ios、javascript三端易用的现代跨平台通信系统。无需彼此了解，web端可随意调用原生上万api。原生系统也可无差别调用javascript所有功能。其优势包括：1)拥有完整的功能api，web开发者可简单高效的使用原生系统的所有功能。2)原生功能插件化，支持随时插拔新的原生功能模块，简单灵活。3)支持同步，异步，队列传输等常见消息机制。4)支持自定义原生功能插件。
133.本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同相似部分相互参见即可。
134.在本说明书中所谈到的“一个实施例”、“另一个实施例”、“实施例”、等，指的是结合该实施例描述的具体特征、结构或者特点包括在本技术概括性描述的至少一个实施例中。在说明书中多个地方出现同种表述不是一定指的是同一个实施例。进一步来说，结合任一实施例描述一个具体特征、结构或者特点时，所要主张的是结合其他实施例来实现这种
特征、结构或者特点也落在本发明的范围内。
135.尽管这里参照本发明的多个解释性实施例对本发明进行了描述，但是，应该理解，本领域技术人员可以设计出很多其他的修改和实施方式，这些修改和实施方式将落在本技术公开的原则范围和精神之内。更具体地说，在本技术公开、附图和权利要求的范围内，可以对主题组合布局的组成部件和/或布局进行多种变型和改进。除了对组成部件和/或布局进行的变型和改进外，对于本领域技术人员来说，其他的用途也将是明显的。