移动端H5组件化开发方案
目录 | 需求分析方案一:iframe元素 内存共享方案二:Vue/React组件方案三:WebComponents方案四:WebView混合开发比较统一UI规范代码复用附:移动端的应用平台一览 |
---|
- 需求分析
- 方案一:iframe元素 内存共享
- 方案二:Vue/React组件
- 方案三:WebComponents
- 方案四:WebView混合开发
- 比较
- 统一UI规范
- 代码复用
- 附:移动端的应用平台一览
需求分析
本文研究如何基于H5开发,在不需要厂家源码的前提之下,集成每个厂家开发的页面至我们开发的容器(主页面)中,同时保证容器能够与厂家页面安全通信,并且提出一套约束厂家UI样式的方案。核心问题是如何在移动端实现多方协作开发,以模块化/组件化的设计模式进行分工、整合。
方案一:iframe元素 内存共享
利用html元素iframe嵌套不同的网页,将厂家的页面嵌入到主页面中,同时保证父页面和iframe子页面同域,这样可以互通数据,互相访问内存,实现自由通讯。利用iframe也是PC端的备选方案,但是在移动端的兼容性可能不高。
缺点:JS内存互通的方式无法保证厂商之间的操作安全。
方案二:Vue/React组件
利用主流的MVVM框架提供的组件机制,将每个厂家页面封装进入组件,统一路由,通过父子组件传参机制实现通讯。该方案试图将所有厂家页面融合进一个项目,通过nodejs模块机制统一打包,优点是可以实现公共npm包复用,减少项目体积。
缺点:需要使用第三方框架。
方案三:WebComponents
利用浏览器的WebComponentsAPI提供的H5原生组件机制,实现高性能的模块组装,且性能优于第三方的mvvm框架。通讯的需求可以利用自定义元素的原型函数/属性来满足。
缺点:该API比较新,虽然理论上可行,但没有用WebComponents做模块化开发的先例。
方案四:WebView混合开发
hybrid混合开发方案,通过webview调用chromium内核,实现app内部网页跳转(类似支付宝那样的UI)。由于整个容器是Android/IOS原生的app,性能优于以H5为容器的方案。容器与厂家通过JSbridge等接口跨进程通讯。
缺点:可移植性低,需要为Android和IOS端分别开发主页。
比较
iframe | Vue组件 | WebComponents | WebView | |
---|---|---|---|---|
主页 | H5 | H5 | H5 | app |
进程数 | >1 | 1 | 1 | >1 |
组件化模式 | 网页嵌套 | 组件 | 原生组件 | WebView |
通信方式 | 内存共享 | 组件传参 | 原生接口 | 进程通讯 |
性能 | 一般 | 一般 | 高 | 高 |
部署复杂度 | 容易 | 复杂 | 复杂 | 适中 |
统一UI规范
需要一套规范来统一主题风格、操作习惯、页面布局、接口规则,针对的页面元素包括颜色、字体、按钮、边距、弹窗、动画、导航栏等。为了能够使各个业务系统厂家更好地理解和遵守统一UI规范,我们将组建UI设计师团队协助大家设计UI规范。
代码复用
基于统一的UI规范,可以将子页面公共的UI组件、业务逻辑库拎出来复用,减少系统体积,提升性能。可复用的内容包括但不限于:字体图标、主题css文件、接口调用包、Dom元素。复用的代码可以存储在CDN云端库或主页仓库,厂家的业务系统可以按需使用这些公共库。
附:移动端的应用平台一览
- 原生应用:移动端原生系统API
- 混合开发:原生应用的升级版,原生 H5【目前的主流】
- 浏览器:Web应用,寄生于移动端浏览器
- PWA:Web应用的升级版,性能接近原生应用【未来的趋势】
- 小程序:寄生于微信/支付宝等平台,性能略高于浏览器