手机端H5组件化4种解决方案
移动端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应用的升级版，性能接近原生应用【未来的趋势】
- 小程序：寄生于微信/支付宝等平台，性能略高于浏览器